Вовремя и в рамках бюджета

«...Лица или организации, активно вовлеченные в проект, или те, чьи интересы могут быть затронуты — в положительном или отрицательном смысле — в ходе или по результатам выполнения проекта; они также могут оказывать влияние на проект и его результаты» (с. 16)¹⁴.

Всем нам хорошо известен пример активного и пассивного участия. Представьте себе яичницу с беконом. Курица — опосредованный, пассивный участник процесса, свинья — непосредственный, активный. Суть определения лиц, заинтересованных в проекте, заключается в том, чтобы все, кто может так или иначе повлиять на проект, с самого начала были активно вовлечены и выразили согласие с планом. Уж слишком часто такие участники проекта, как заказчик или руководство, имеющие непосредственное отношение к успеху всего начинания, ставят себя на позицию судей, а не сподвижников, считая, что не должны играть активной роли в самом процессе достижения результата. Такой путь, вероятнее всего, приведет к провалу. Задача команды — заручиться поддержкой всех, кто потенциально может повлиять на успех проекта, в той степени, что обеспечит достижение результата. Для этого есть много способов. И в первую очередь — удостовериться, что вы определили все заинтересованные стороны и выявили их потребности. Как правило, нужно получить формальное согласие участников как с уставом, так и с планом проекта. В некоторых случаях в роли устава или плана может выступать контракт на выполнение проекта.

5.4. Иерархическая структура работ (ИСР)

ИСР — общая схема, по которой можно будет планировать и контролировать выполнение проектных работ. Это систематизированный способ представления обобщенной информации с возможностью дальнейшей ее детализации, а также вид отчетности перед заказчиками и руководством. ИСР создается последовательным разбиением результатов проекта на составляющие более низкого уровня. При такой декомпозиции мы получаем более управляемые элементы, с которыми удобнее работать и которые легче контролировать.

Хотя идея ИСР проста, я обнаружил, что многие испытывают трудности при составлении этого дерева работ. Думаю, проблема отчасти заключается в склонности человека мыслить в категориях конкретных операций, а не результатов этих операций. Результаты проекта — это все товары и услуги, производимые/появляющиеся в ходе проекта. Чрезвычайно важно, чтобы с самого начала был ясен перечень объектов, оборудования и услуг, которые будут созданы в рамках проекта. (Также очень важно указать, что именно не будет получено в этом проекте, а что появится в результате других, но об этом мы еще поговорим в разделе 5.7.) ИСР — ваш инструмент для систематизации содержания проекта и назначения ответственных за каждый из ожидаемых результатов.

5.4.1. ПОДХОД ТЕОРИИ ОГРАНИЧЕНИЙ

Сторонники ТОС предлагают два способа построения сетевой диаграммы проекта. Большинство опускают этап разработки иерархической структуры работ. Один из способов — дерево перехода (ДП) — можно условно назвать ИСР. Идея заключается в том, чтобы взять конечный или промежуточный результат и спросить участников команды: «Что мешает нам получить этот результат?» Как только составлен список препятствий, вы просите команду перечислить условия преодоления этих препятствий. Затем эти условия выстраиваются в логическую цепочку. Такой метод представляет последовательную стратегию и согласованную тактику преодоления проблем, выявленных командой. Для больших проектов можно создавать ДП разных уровней — по аналогии с уровнями иерархии в ИСР.

К сожалению, упрощенный метод построения ДП, описанный Голдраттом в романе «Дело не в везенье!» [3], не подходит для разработки ИСР проектов. Дело в том, что ДП позволяет только обеспечить выполнение условий преодоления препятствий, выявленных командой. Этот метод не отслеживает достижение всех промежуточных результатов, необходимых для получения конечного продукта проекта. Детмер [4] модифицировал метод так, чтобы он охватывал и необходимые, и достаточные условия успешного завершения проекта.

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

У обратного планирования есть несколько недостатков:

• не всем удобно думать «задом наперед», из конца в начало;

• компьютерные программы спроектированы по логике «сверху вниз и слева направо» (прямое планирование). Построить правильную диаграмму проекта методом обратного планирования в таких программах будет непросто. (Я предпочитаю помогать команде с разработкой подобных диаграмм, отображая процесс с помощью компьютера и проектора);

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