Хочу выказать свое уважение и благодарность доктору Элияху Голдрат-ту — за создание теории ограничений и концепции критической цепи в отдельно взятом проекте. Спасибо Ди Джейкобу из Института Авраама Голдратта AGI за то, что ввел меня в его стены в середине 1990-х. Также благодарю Тони Риццо за признание подхода «системного управления проектами организации» и за приглашение участвовать в самых первых опытах использования ССРМ.
Глава 1. Начнем с начала
Проекты заканчиваются крахом с пугающей частотой. По статистике, в 30% случаев работы останавливаются на полпути, и в итоге оказывается, что время, деньги и силы были потрачены впустую. Зачастую проекты завершаются с нарушением сроков, с превышением бюджета при невыполнении первоначальных целей. Причем нередко расхождения с плановыми значениями сроков и затрат могут доходить до 100%. Из-за этого ежегодно теряются миллиарды долларов. Данная проблема не связана с конкретным типом проекта или страной реализации. Она универсальна. Попытки как-то улучшить итоговые показатели по проектам создают в основном дополнительные проблемы и для людей, и для организации: исписываются горы бумаги, однако результат наблюдается минимальный, а иногда и вообще обратный. Специальность «управление проектами» отстала в своем развитии от других сфер человеческой деятельности, таких как технологии или производство. Цель данной книги — помочь вам и вашей компании радикально улучшить управление проектами.
В первых трех главах содержится общая информация об управлении проектами по методу критической цепи (CCPM). Поэтому если вам хочется получить представление о методе ССРМ в управлении отдельным проектом, можете сразу переходить к главе 4. Если же вам не терпится узнать, как правильно запустить отдельный проект, начните с главы 6, где говорится о разработке плана успешного проекта. Глава 7 расскажет о том, как планировать несколько проектов, в которых задействованы одни и те же ресурсы.
Настоящая же глава является вводной в CCPM, в ней определяется суть вопроса и на некоторых примерах показывается, что ССРМ зарекомендовала себя в качестве эффективной методики для самого широкого спектра проектов в самых различных сферах. Задача данной главы — убедить вас в том, что при использовании традиционных подходов к управлению проектами, даже работая изо всех сил, максимальных результатов не добиться. Кроме того, эта глава готовит вас к прочтению главы 2, в которой закладывается фундамент для восприятия нового подхода, коим является управление проектом по методу критической цепи.
В разработанном PMI «Руководстве к своду знаний по управлению проектами» [1]2 проект определяется как «временное предприятие, имеющее целью создание уникального товара или услуги». Характеристика «временный» призвана отличить проект от повседневных производственных процессов. Прилагательное «уникальный» показывает, что проекты отличаются друг от друга. Проект является успешным, если заказчики получают то, чего хотели, тогда, когда хотели, за заранее оговоренную цену и при этом команда проекта довольна результатом.
Главы с первой по третью написаны с учетом существующей традиционной методологии управления проектами. Хотя в проджект-менеджменте уже наметились некоторые перемены, все же в имеющейся специализированной литературе чаще всего при обсуждении вопроса разработки графика в первую очередь описывается метод критического пути (critical path method — CPM). В PMBOK упоминаются и другие методы, а в издание 2004 года должен попасть также метод критической цепи3, однако «критический путь» сейчас используется значительно шире. Большинство программных продуктов основаны именно на СРМ.
В PMBOK также рассматривается управление рисками (как способ реагирования на неопределенность) и метод освоенного объема (как способ оценки и контроля). Управление рисками и метод освоенного объема применяются при реализации многих крупных проектов, особенно тех, что делаются по заказу правительства США.
Большинство программных продуктов и абсолютно все приложения, которые мне встречались, в рамках СРМ настроены на создание графика типа «ранний старт». Это означает, что программа составит расписание работ таким образом, чтобы они начинались как можно раньше и помещались на графике как можно левее. На рис. 1.1 дан типичный план проекта, построенный таким образом.
Иногда, чтобы отличить проекты от обычного производства, смотрят на количество получаемой продукции и на относительную длительность операций. При реализации проектов обычно возникает результат в своем роде уникальный. В ходе производства же появляется значительное количество более-менее похожих единиц продукции. Некоторое пересечение есть между проектом и изготовлением под конкретные пожелания заказчика (например, сборка автомобиля на заказ). Как я обнаружил, многие считают, что стандартное производство и проекты — совершенно разные вещи. В середине 1990-х я первый раз услышал о теории ограничений систем — ТОС, впервые описанной доктором Элияху Голдраттом в книге «Цель» (The Goal) [2]. Порекомендовав роман нескольким менеджерам проектов и программ, выяснил, что никто не видел никакой связи между ТОС и управлением проектами. Впоследствии я нашел способ преодолеть власть традиционной парадигмы мышления. Показывая людям рис. 1.2, я спрашиваю: «Что это — проект или процесс производства?» Реакция аудитории очень интересная. В большинстве случаев вид у всех озадаченный. Быстрого ответа не дает никто. Затем один предполагает: «Может быть, и то, и то». Остальные сразу соглашаются. На самом деле может быть и так, и так. На этом уровне сходства очевиднее различий. Поэтому в первую очередь мы с вами проанализируем такую общую черту проектов и производства, как вариабельность длительности отдельных операций. Речь идет об операциях, преобразующих некие входные параметры в результаты на выходе; из таких операций состоят как взаимозависимые этапы производственного процесса, так и этапы реализации любого проекта.
2
A Guide to the Project Management Body of Knowledge, в дальнейшем РМВОК. (Здесь и далее — примечания редакции «Альпина Бизнес Букс».)
3
Метод критической цепи описан в руководстве PMBOK редакции 2004 года в разделе 6.5.2 «Разработка расписания: инструменты и методы», пункт 6.