Всем известно, что операциям проекта свойственна изменчивость, или вариабельность, причем зачастую степень вариабельности характеризуется неопределенностью граничных условий. По определению проект – это то, чего раньше никто не делал, некая уникальная задача. В любом случае никто никогда не выполнял все те же задачи и тем же образом, как это требуется в рамках данного конкретного проекта. Чтобы успешно выполнить проект, необходимо принимать во внимание явления вариабельности и неопределенности. Способность человека точно оценить ситуацию зависит от нескольких факторов. Существует масса примеров, показывающих, что люди склонны переоценивать точность собственных прогнозов [14]. Как правило, длительность большинства проектных операций нельзя назвать с точностью выше, чем ±20 %.
На тренингах мы просим слушателей прикинуть длительность одной очень простой операции. Практически все соглашаются, что операция эта намного проще, чем большинство выполняемых по их проектам. Также все присутствующие на тренинге сходятся во мнении, что должны суметь оценить длительность данной операции не хуже, а может, и лучше, чем оценивают длительности реальных операций участники их проектов. Разброс оценок составляет до нескольких сотен процентов от средней величины, а стандартное отклонение – 30 %. На рис. 1.4 представлены суммарные результаты нескольких подобных экспериментов.
На рис. 1.5 степень точности оценки параметров отдельной операции дана как функция от количества усилий, затраченных на выработку этой оценки. Точность оценивается в процентах от средней величины оценочного значения, где абсолютно точная оценка будет иметь степень неопределенности равную нулю. Если для оценки не было приложено никаких усилий, то неопределенность составит как минимум 100 %, а может быть, и на порядки (на сотни процентов) выше. Как показывает кривая, обычно чем больше сил потрачено на выработку оценки, тем большей становится ее точность (и меньше неопределенность). Возможности улучшения ограничены нижним пределом, определяемым вариабельностью, присущей самому процессу, в рамках которого необходимо будет выполнять поставленную на проекте задачу. Это вариабельность, вызываемая так называемыми общими причинами, мы поговорим о ней далее в главе 2. Сколько бы сил вы ни прикладывали, вам никогда не сделать оценку точнее, чем позволяет характерная для данного процесса вариабельность. Снизить степень ее проявлений можно, лишь изменив что-то в соответствующем процессе.
Рассмотрим две части, на которые график на рис. 1.5 делится вертикальной пунктирной линией. Посмотрим на правую часть. Увеличение затрат на оценку не вызывает практически никакого увеличения ее точности. И чем правее находится отрезок шкалы, тем меньшая наблюдается зависимость между снижением затрат и ростом неопределенности. Слева же картина обратная – видна четкая связь между степенью неопределенности и количеством усилий, затраченных на оценку. Даже небольшое сокращение затрат повлечет за собой значительный рост неопределенности. А небольшое увеличение их вызовет радикальное улучшение качества оценки.
Если предположить, что задачи, которые вы выделили в своем проекте, уже несут информацию о результатах (четко обозначены принципы передачи работ от одного исполнителя к следующему), то влияние дальнейшей детализации на степень неопределенности по всему плану будет зависеть от того, в какую часть графика по отношению к пунктирной линии на рис. 1.5 попадает ваша ситуация. Если задействована правая часть и на оценку отдельных операций выделены фиксированные ресурсы, то увеличение количества операций (и соответственно уменьшение доли затрат на оценку каждой) может положительно повлиять на точность плана в целом. Объясняется это тем, что по мере разбиения плана на более мелкие и равноценные операции точность плана возрастет, если длительности операций определены с одинаковой точностью.
Если же количество ресурсов, которые вы можете себе позволить на проведение оценки, ближе к левой части по отношению к вертикальной линии на рис. 1.5, то более детальное разбиение плана может снизить степень его точности. Дело в том, что возросшая степень неопределенности оценки по каждой операции может превосходить статистическую выгоду от дополнительной детализации.
Добавление задач в план проекта увеличивает количество потенциальных связей между ними на порядки, превышающие число этих новых записей. Так, если вы прибавили всего одну строку в проект, в котором их уже 100, вы потенциально внесли и 200 новых связей между задачами, поскольку каждая операция, уже имеющаяся в плане, будет потенциально предшествовать новой или следовать за ней. А дополнительные взаимосвязи, возникающие при появлении новых задач, значительно увеличивают риск ошибок в сетевой диаграмме.
Из обсуждавшихся до сих пор возможных причин неудачных проектов вы могли сделать вывод, что это неопределенность вызывает проблемы при реализации. Если бы было именно так, то можно было бы предположить, что любой проект, существующий в ситуации неопределенности, обречен на провал. Основываясь же на определении проекта и нашем с вами знании жизни, можно утверждать, что неопределенность свойственна всем проектам. Следовательно, все проекты неминуемо должна постигнуть неудача. Во многих случаях это утверждение справедливо, но не во всех. Более того, есть примеры успешной реализации проектов в условиях максимальной неопределенности. В своей работе под названием «Критическая цепь» (Critical Chain) Голдратт описывает проект по созданию аэроплана, опровергающий высказанный нами ранее вывод. Разработчики сделали новую модель с непревзойденными характеристиками за 8 месяцев – вместо 10 лет, которые обычно уходят на подобные проекты. Есть и другие случаи. Соединенным Штатам удалось достичь поставленной президентом Кеннеди цели по отправке человека на Луну до конца десятилетия. Данный проект был самым неопределенным из всех, что выпадали на долю человечества. Подобным же проектом было создание атомной бомбы, завершившееся в рекордно короткие сроки.
Немалые силы брошены на то, чтобы снизить степень неопределенности при оценке параметров проекта и вариабельности при выполнении задач по проекту. Существуют прекрасные инструменты для оценки длительности проектов и составляющих задач. Они, без сомнений, помогают повысить точность оценки и, что еще важнее, собрать данные для оценки вариабельности проектных задач. Наблюдаются улучшения в сфере выполнения проектов – путем применения таких методологий, как шесть сигм. К сожалению, среди примеров неудач встречаются данные и о таких компаниях, в которых применяются подобные технологии снижения вариабельности. Говоря в общем и целом, к значительным улучшениям они не привели.
Особенность научного метода заключается в том, что ни один ученый никогда не сумеет доказать, будет ли какая-либо научная теория или закон продолжать действовать в будущем, но вот опровергнуть теорию он может, проведя всего один соответствующий эксперимент. Ряд случаев свидетельствует о том, что неопределенность сама по себе не может быть причиной неудач при реализации проектов.
Если фактор неопределенности сам по себе не объясняет, почему срываются проекты, можно ли как-нибудь подогнать существующую теорию под имеющиеся примеры? Мы знаем, что иногда при реализации проектов используются разные средства управления неопределенностью. Например, на проект «Аполлон» были приглашены три разных компании, которые предложили три разных решения по очень сложным разработкам. Выбран был один основной поставщик, а два других остались в качестве запасных – на случай, если решение первого не сработает. Была запланирована масса тестов и повторных проверок (и в ходе их проведения случился ряд весьма зрелищных срывов). Да, это затратный метод управления неопределенностью, но он работает. Руководствуясь теми же рассуждениями, Голдратт предположил, что причиной большинства неудач на проектах является отсутствие эффективного управления неопределенностью. В главе 3 мы рассмотрим эту гипотезу более тщательно. Если он прав, то решением может стать создание такой проектной системы, которая способна справиться с неопределенностью.
Здесь мы имеем в виду реализацию плана решения проблемы. Проектом является совершенствование самой проектной системы.
В очерке «Сага об улучшении производства» (My Saga to Improve Production) [15] Голдратт пишет:
«Я не сразу дошел до этого, но в конце концов простейший ответ сам бросился в глаза: трата сил на установку программного обеспечения не давала людям на заводе сосредоточиться на проведении необходимых изменений – в основополагающих концепциях, в системах измерений и в процедурах».
Похожий феномен наблюдается и при многочисленных попытках улучшить качество управления проектами, и выясняется, что бороться с ним нужно будет практически всякий раз, когда компания решает внедрить ССРМ. Многие сразу же сосредотачиваются на софте как на панацее. Однако софт сам по себе никогда не является решением, и если сфокусироваться на нем, то больших улучшений не достичь. В других случаях решения по улучшению существующей системы трактуются как требования все большей детализации и создания все новой документации. При этом часто запускается новая база данных или программа для управления проектами. Все это лишь еще больше отвлекает людей от реализации проекта. И мало что меняется в лучшую сторону. Конечно, если изо всех сил внедрять дефектную систему, больших улучшений не произойдет. В главе 10 дается эффективный план по внедрению системы ССРМ.
Мы сформулировали проблему и показали, что существующие теории нуждаются в совершенствовании. Следующим шагом должна стать разработка нового подхода к управлению проектом – ССРМ. Ожидается, что эта новая теория также будет критически осмыслена и при применении обеспечит стабильно более высокий уровень качества реализации проектов. Хотелось бы видеть улучшение не на 5, а на 50 %. Опираясь на данную теорию, мы также должны суметь объяснять причины уже имевших место успехов и неудач и делать оправдывающиеся прогнозы по готовящимся проектам. Опыт применения данного подхода демонстрирует гораздо больше преимуществ, чем обычно ожидается при внедрении новых методов. И все они тоже объясняются новой теорией. Вот перечень этих преимуществ (по сравнению с методом критического пути).
Увеличение количества успешно завершенных проектов:
• проекты всегда завершаются вовремя;
• проекты решают все поставленные задачи;
• проекты завершаются в рамках бюджета;
• проекты приводят к усилению положения компании на рынке и росту бизнеса.
Сокращение времени реализации проектов:
• работы завершаются вдвое (а иногда и более) быстрее, чем ранее при реализации подобных проектов;
• объем плана проекта сокращается как минимум на 25 %;
• значительно уменьшается длительность сложных проектов;
• снижается количество изменений на проектах;
• коммерческие проекты раньше начинают приносить прибыль;
• инвестиционные проекты окупаются быстрее.
Повышение степени удовлетворенности проектной команды:
• уменьшается путаница от возникновения множества пересекающихся задач;
• появляется возможность заниматься одновременно лишь одной задачей;
• снижается количество изменений;
• снижается количество переделок;
• снижается давление на проектную команду со стороны менеджеров отдельных проектов;
• снижается количество ситуаций типа «если не сделаешь, нам конец» (то есть задач, жестко привязанных к конкретным датам);
• исполнители пользуются информацией о буфере, чтобы определить приоритетность своих задач;
• снижается количество случаев внезапного появления новых приоритетных задач;
• упрощается система измерений;
• статус выполнения плана определяется легко и быстро;
• имеется информация о фактическом статусе проекта, то есть нет необходимости дожидаться появления финансовых отчетов;
• можно мгновенно получить статусный отчет по буферу, по цепи и по задаче;
• отчет по буферу определяет дальнейшие решения;
• отчетность по буферу вынуждает при принятии решений фокусироваться на приоритетах руководства (они видны по датам начал работ в графике).
Упрощение управления проектом:
• менеджеру проекта предельно ясно, на чем необходимо сосредоточить усилия (критическая цепь, сокращение случаев раннего старта);
О проекте
О подписке