Анализ ситуации

Анализ ситуации

Все мы время от времени ошибаемся. Самое неприятное в этой истории то, что главные герои упорно не хотят делать выводы из своих ошибок. Вряд ли Эрнест Бур и другие руководители на собственном опыте усвоили урок, который дает Голдратт в работе «Критическая цепь» («Critical Chain»), но хоть что-то они должны были для себя вынести из описанной ситуации. Однако из истории следует, что не было предпринято ни единой попытки проанализировать однажды принятые решения, сделать какие-то выводы. Полагаю, что очень редко из подобных ситуаций извлекаются уроки для организации в целом. Возможно, кто-то и сделал какие-то отдельные выводы для себя лично. И очень хочется надеяться, что Джим Моррисон, по-настоящему хороший менеджер проекта, получил важный урок и в следующий раз будет осторожнее. Компания же, в которой он работал, – фирма Rand – так ничему стоящему и не научилась. Яркий пример – увольнение Джима по результатам реализации проекта. Это ошибочный шаг.

Я считаю, что на ошибках учатся лишь в том случае, когда на деле получают совсем не то, что ожидали получить изначально. Неожиданность заставляет людей задуматься о причинах того или иного явления. Если мы понимаем, что ожидаемый и полученный результаты не совпадают, значит, в нашем мышлении засела модель, которую надо пересматривать. Пересмотр моделей и есть процесс обучения. Многому можно научиться, когда выявлены расхождения между планами и реальными результатами, которые были получены. В этом случае можно заняться и процессом непрерывного совершенствования.

Чему нас учит данная история? Давайте сначала найдем главные расхождения между желаемым и задуманным. Несколько целей остались нереализованными. С какой начнем?

Для начала перечислим их. Итак, где планы разошлись с реальностью? Во-первых, время, потребовавшееся на создание опытной модели системы. Сначала планировалось, что на это понадобится два с половиной года, а на деле ушло четыре с половиной. Во-вторых, коммерческая сторона дела: вместо шести удалось продать всего две системы. И это особенно плохо, если вспомнить, что бюджет проекта превысил планируемый лимит. Третья неудача – неправильный выбор технологии, который чуть было не сгубил весь проект целиком. Этой проблемы не ожидал никто.

Рассмотрим все три несоответствия по порядку. Начнем с самого неприятного и болезненного для компании – с коммерческого аспекта. Почему именно он самый болезненный? Да потому, что если бы удалось продать шесть систем, как и планировалось, то вряд ли бы Эрнест Бур назвал этот проект величайшим провалом. При этом акцент сделан именно на том, что не удалось реализовать шесть систем, а не на том, что расходы превысили плановые показатели. Чтобы получить более полную картину причин и следствий, включим в анализ и два других аспекта, по которым планы разошлись с реальностью.

Диаграмма на рис. 9.1 вкратце объясняет провал по одному из аспектов.

На вершине диаграммы мы видим несоответствие между двумя противоположными утверждениями. Причинно-следственные цепочки дают нам представление о том, на чем основывались исходные ожидания, планы и чем вызвано появление именно такого результата. Простейшие логические рассуждения приводят нас к двум причинам неудачи. Первая: серьезные задержки с разработкой системы. Если бы опытный образец был готов в середине 1993-го, то к тому времени, скорее всего, еще не было бы внедрено альтернативное решение и флоту бы потребовалось более двух систем. Размышления о том, что было бы, если бы проект завершился вовремя, отображены на рис. 9.2. Диаграмма представляет собой логическое дерево, дающее предполагаемый сценарий развития событий в нереальных обстоятельствах – «если бы… то». Вторая причина сорванных планов продаж: иная точка зрения нового командующего на вопрос о необходимости системы.

Как следует из этих рассуждений, все-таки трудно угадать, сколько бы удалось продать систем, так как на должность заступил новый командующий, который не так высоко ценит важность «Глаза крокодила». Таким образом, даже если проект и был бы завершен вовремя, это вовсе не означает, что именно шесть систем понадобилось бы заказчику.

Получается, что ошибка кроется в изначальных оценках будущих продаж. Неправильно было ожидать, что удастся продать целых шесть систем. Принимая во внимание, что командование может смениться и новые люди не обязательно будут разделять мнение предшественников, можно увидеть, что в расчет не была взята реальная ценность системы для флота – то, насколько она действительно нужна ВМС.

Но при всем при том можно утверждать, что шанс продать все шесть систем был упущен именно из-за задержек в реализации проекта. Тут мы подошли к проблеме со временем.

Давайте разберемся, в чем же причины постоянных переносов сроков. Начнем с двух общих предположений и, опираясь на имеющиеся данные, посмотрим, к какому выводу мы придем. Возможны несколько объяснений несоответствия планов и результатов. Каждая версия нуждается в дополнительной проверке, так как лишь одна из них верная.

Версия первая: исходно ошибочные ожидания, неправильное планирование с самого начала – объясняет неожиданность и несоответствие реального результата тому, что было задумано.

Версия вторая: слабое управление проектом (плохой менеджер). Но это очень общее утверждение, которое необходимо рассмотреть более детально.

На рис. 9.3 даны весьма приблизительные оценки, причинноследственные отношения здесь выстроены не так строго, как того обычно требует ТОС. Например, утверждение «Разработка платформы заняла гораздо больше времени, чем планировалось сначала» влечет за собой следствие «Проект завершился лишь в июле 1995 г.». Но при этом исходное утверждение (причину) следовало бы объединить эллипсом с еще одним, говорящим, что на других этапах проекта подобных задержек не наблюдалось. Мы знаем, что так оно и было, поэтому строгое логическое построение не отражено в диаграмме. Есть еще одна причина, действующая независимо: «Результаты подпроекта 2 не подошли под новую конфигурацию системы». Поэтому две стрелки, идущие к результату, между собой не объединены.

Всегда, когда речь заходит о конкретных цифрах и датах, необходимы более детальные объяснения каждого факта. Почему изначально считалось, что проект завершится в июле 1993 г.? Одно из объяснений – прогнозы были слишком оптимистичны. Конечно, это предположение не объясняет нам появление в планах той или иной даты, а лишь указывает, откуда в итоге появилось такое серьезное расхождение между фактическим и ожидаемым завершением проекта. Полагаю, что и этого достаточно. Кажется излишним добавлять, что дата «июль 1993-го» появилась после того, как были определены все работы по проекту, установлена длительность каждой и затем общая длительность всего проекта.

Мы видим два противоположных утверждения на верхушке диаграммы. Элементы ниже объясняют появление каждого из них. И планы, и реальность обусловлены тем, что изначально все строилось на слишком оптимистических прогнозах.

Мой опыт показывает, что первоначальный анализ можно начинать, изложив на бумаге самые общие предположения. Далее следует развивать основную мысль, отталкиваясь от исходных постулатов. Анализ – процесс нелинейный, скорее циклический. Проведя первый «круг» размышлений, необходимо вернуться в самое начало и детализировать исходные данные. Процесс заканчивается лишь тогда, когда нам удается добраться до истинных причин, которые вызвали к жизни наблюдаемые негативные явления.

Рассмотрим сначала те положения, которые объясняют появление неверных планов (рис. 9.4).

Исходно завышенная планка ожиданий объясняет расхождение плана и реальности. Она также объясняет и некоторые другие описанные события. Вновь на схеме отражены не все необходимые условия, которые надо было бы включить, если подходить к построению логического дерева по всем правилам и со всей строгостью. Например, если бы повезло, первоначально выбранная технология вполне могла бы оказаться подходящей. То есть можно бы добавить в диаграмму утверждение о том, что знаний о возможностях выбранной технологии недостаточно, и соединить его с элементом «Технология, на которую сделали ставку, не отвечала поставленным задачам». В то же время слова Джима о стандартной продолжительности подобных проектов вообще можно логически истолковать как оправдание и не включать в диаграмму. Но наша гипотеза свидетельствует, что это утверждение имеет под собой основание, хотя бы отчасти. Итак, представленная схема доказывает, что данная гипотеза имеет право на существование, так как она объясняет появление нескольких событий, которые наблюдались в ходе реализации проекта.

Не всегда можно подобрать достаточное количество фактов в поддержку каждого предположения. Так, те наблюдения, которые мы предлагаем в качестве доказательства верности второй гипотезы, не выглядят столь же убедительно (рис. 9.5). На диаграмме утверждение о плохом управлении проектом заменено на «Джим и Мортон – плохие менеджеры проекта». Это сделано умышленно, чтобы обозначить человеческий фактор и избежать соблазна свести к «плохому управлению» любые неудачи в работе. Итак, мы должны доказать, что Джим и Мортон – никудышные менеджеры и можно было найти специалистов, способных справиться с управлением подобным проектом лучше.

Как следует из рассуждений, отображенных на рис. 9.5, если бы Джим и Мортон были действительно плохими менеджерами, то почти на всех этапах работ случались бы срывы по срокам. Этим же можно было бы объяснить запоздалое выявление несовместимости результатов подпроекта 2 и измененной платформы, а также ошибку в выборе основной технологии. Но два из этих трех аспектов скорее связаны и с первым предположением о слишком оптимистичных прогнозах. Только оплошность с результатами второго подпроекта однозначно вызвана недосмотром менеджера проекта. Но вряд ли это можно рассматривать как серьезный аргумент при выборе основной версии провала.

В схему не включены факты, которые косвенно свидетельствуют о профессиональных качествах Джима. Например, если бы он действительно был плохим специалистом, разве смог бы он так быстро найти новую работу? Еще одно опровержение: в ходе реализации проекта был накоплен ценный опыт, который затем нашел применение в других проектах компании. Достаточно ли этого, чтобы доказать несостоятельность данного предположения? На мой взгляд, вполне, но, конечно, каждый вправе сам решать.

Поскольку до сих пор не все еще ясно, давайте соберем вместе все основные явления и попытаемся найти их общую причину. Учтем также тот факт, что не существовало стопроцентной вероятности продать все шесть систем, даже если работы и завершились бы по плану. И здесь мы подбираемся к основной причине неудач: пренебрежительное отношение к важности формально строгой оценки рисков. И как следствие – перед нами открывается конфликт интересов: целей сторонников проекта Джима и Мортона и интересов руководства компании. Джим и Мортон были по-настоящему захвачены идеей и скрыли информацию о возможных рисках от Эрнеста Бура (рис. 9.6).

Ключевая проблема в том, что не применялись методы контроля в условиях неопределенности, методы управления рисками, которые неизбежны при реализации большинства проектов. Всегда есть риск ошибиться с технологией или спецификацией продукта. Существуют риски, связанные со своевременностью исполнения проекта в рамках заданного бюджета. Метод управления проектами по ТОС большое внимание уделяет составлению графика работ. Мы также рискуем, если не предусматриваем при планировании определенных временных буферов – запасов по времени. В рассматриваемом случае задержки могли быть вызваны и неким ограничением в ресурсах, на что указывает спор, возникший между Джимом и Мортоном из-за программиста.

Обозначенная нами ключевая проблема усугубляется еще и тем, что перед Джимом и Эрнестом стоят совершенно разные задачи – классическое и распространенное противостояние интересов: достижение коммерческого успеха или же оптимального технического решения. На рис. 9.7 представлена «Грозовая туча» такого конфликта.

Итак, проблема – неумение управлять в ситуации изменчивости, контролировать неопределенность. Для работы с техническими и коммерческими рисками можно использовать в несколько измененном виде такие понятия ТОС, как «буфер», «резерв», «управление при помощи резервов».

Оставляю вам, читатели, определение исходных предположений, обусловивших появление стрелок диаграммы на рис. 9.7. А вот по поводу конфликта несколько слов еще добавлю. Конечно, уместно предположить, что любую новейшую технологию рискованно применять до апробирования на конкретных проектах. При этом необходимо удостовериться, что риски, связанные с работами с новейшими технологиями, в числе прочих включены в блок D?. Рассмотренные нами обстоятельства провала «Глаза крокодила» только подтверждают эту мысль. У нас есть явный пример, когда непроработанные технологии ставят под угрозу коммерческую целесообразность проекта.

Какой урок следует извлечь Эрнесту? Во-первых, нужно озаботиться вопросом управления рисками проектов. На практике можно просто потребовать от каждого руководителя проекта предоставлять наихудший сценарий развития событий при реализации планов. Осознание важности оценки рисков приведет к укреплению системы контроля организации в ситуации неопределенности. Некоторые нежелательные события и соответствующий план действий должны быть четко отражены при планировании сложных проектов, должны также заранее устанавливаться некие показатели, которые позволят определить, что события начинают принимать нежелательный оборот. К примеру, если бы Джим заранее предполагал, что новый командующий может не разделять точку зрения своего предшественника, то он, возможно, организовал бы специальную встречу, где были бы озвучены все вопросы, интересующие обе стороны.

Во-вторых, разобравшись с рисками, следует более внимательно присматриваться к работе исследователей-энтузиастов и оценивать все «светлые идеи» с точки зрения увеличения производительности Т. Особенно осторожно нужно относиться к использованию новейших технологий.

Я предложил вам еще один пример в подкрепление своей теории: неудачи и неожиданности можно использовать для того, чтобы глубже разобраться в причинах и следствиях явлений, происходящих вокруг нас. Управление проектами – это сфера, на примере которой стоит систематически извлекать уроки для всей организации в целом. При реализации проектов всегда существует некая неопределенность и множество проблем, вытекающих из этой неопределенности. Здесь же иногда скрывается конфликт между профессиональными интересами и интересами организации – еще одна ключевая проблема наряду с неумением контролировать ситуацию неопределенности.

Данный текст является ознакомительным фрагментом.