Вовремя и в рамках бюджета - Лоуренс Лич

Устав проекта — краткое письменное заявление о запуске проекта, дающее основание для создания соответствующей проектной команды и начала планирования. Это определение намного шире приведенного в РМВОК и предполагает также, что в устав включаются ответы на шесть вопросов, необходимых для создания плана проекта, — кто делает, что делает, когда, где, как и зачем. Как правило, в уставе должны быть освещены все перечисленные ниже пункты, обозначенные авторами из CH2MHILL [2] как обязательные:

Главное различие между уставом и планом проекта в том, что устав уполномочивает команду приступать к планированию.

В РМВОК дается следующее определение участников проекта:

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

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

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

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

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

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

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

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

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

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

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

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

Есть ряд полезных стандартов, которые помогут вам с разработкой ИСР. Один из них сравнительно недавно выпущен PMI [5], а наиболее полный предложен министерством обороны США [6]. Харольд Керцер приводит следующие критерии хорошей ИСР [7]: «Менеджер проекта должен разбить работу на мелкие элементы, которые: