Цели и результаты проекта

Цель проекта - это то, чем должен завершиться проект.

• техническая цель:

О в большинстве случаев техническая цель проекта эквивалентна созданию продукта проекта Без бизнес - целей проект становится бессмысленным. Зачем тра­тить деньги на чисто технические цели. Даже для благотворительных проектов можно сформулировать бизнес-цель: участие бизнеса в соци­альном развитии общества.

В литературе также используют термин "результат проекта" в значе­нии, эквивалентном цели проекта, например, продукция, услуги. Сме­шивать два понятия не следует.

Термин "результат " следует использовать в значении сте­пень достижения цели: позитивный результат, негативный результат или как конкретное, численное описание продук­тов проекта: получена добавочная стоимость в таком-то размере.

* < точность бюджета абсолютная точность -

Низкая точность

Проектный цикл

Старт проекта финиш проекта

Рисунок 32. Жизненный цикл проекта и точность бюджета

Степень риска

Отсутствие рисков

Старт проекта

Финиш проекта

Проектный цикл

Высокий риск<

Рисунок 33. Жизненный цикл проекта и проектные риски

Динамика проектных рисков также связана с фазой жизненного цик­ла. рис. 33.

Внимание: опасность!

Следует быть чрезвычайно внимательным при использовании по­пулярных названий проектных фаз. Прямое копирование западных стандартов в практику российских компаний часто играет с компанией злую шутку. Так, стандарты IPMA и PMI вводят проектные фазы: пла­нирование и выполнение проекта. Помимо этих фаз вводится и проце­дура корректировки планов (управление изменениями). Очень часто у нас в России используют две фазы из импортного стандарта: планиро­вание и выполнение, а на процедуру внесения коррекций не обращают внимания. Такая корпоративная система управления проектами исклю­чает внесение корректировок на фазе выполнения, потому что это фаза выполнения, а не фаза планирования. В результате, вместо того, чтобы выполнить небольшую корректировку плана, продолжают выполнять морально устаревший план.

Чтобы избежать таких ошибок, следует использовать более деталь­ную трактовку жизненного цикла на основе бинарности (см. далее).

Бинарный жизненный цикл (цикл продукта и цикл управле­ния)

Указанная в предыд ущем абзаце неоднозначность трактовки термина "планирование" имеет, прежде всего, лингвистическую причину. Тер­мины "планирование" и "разработка концепции" могут трактоваться и как разработка чертежной документации (например, в строительстве), и как разработ ка собственно проектных планов: смета проекта, график проекта и т. д. Более глубокая причина заключается в существовании двух траекторий жизненного цикла проекта:

* продуктовая траектория (непосредственное выполнение работ по проекту, в частности, материальные работы)

* управленческая траектория (управление проектом), см. рис. 34.

Рисунок 34. Управленческая и продуктовая траектории проектного цикла

Каждая из траекторий имеет свои собственные этапы. Последова­тельность продуктовых этапов определяется технологией производс­тва продукта. Управленческие этапы устанавливаются в соответствии с принятой в компании моделью проектного бизнеса. Часть продуктовых и управленческих этапов могут совпадать во времени. Наряду с этим, существуют этапы, не имеющие аналогий на другой траектории. Так, управленческий этап продюсирования выполняется заведомо раньше любых продуктовых этапов, а управленческий этап закрытия проекта выполняется после любого продуктового этапа. В зависимости от тех­нологии управленческий этап "выполнение работ" может покрывать несколько продуктовых этапов.

Наличие двух траекторий позволяет избежать лингвистической пу­таницы. Так, управленческий этап "планирование" будет пониматься пониматься именно как разработка плана проекта, а продуктовый этап "разработка концепции" будет пониматься как разработка технических документов.

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

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

Чрезвычайно полезным будет создание в компании образцов продук­товых и управленческих этапов, а также архивирование документации уже выполненных проектов.

В зависимости от типа проекта, компания может вводить следую­щую последовательность продуктовых этапов:

* в строительных проектах:

О для нового строительства и реконструкции:

■ сбор исходных данных;

■ согласование и утверждение;

■ разработка концепции, ТЭО, feasibility study;

■ согласование и утверждение;

■ разработка проекта;

■ согласование и утверждение;

■ проведение строительно-монтажных работ;

■ пуско-наладочные работы;

■ проведение приемочной комиссии;

■ стартовый этап эксплуатации; о для капитального ремонта:

■ разработка концепции;

■ разработка проекта;

■ согласование и утверждение;

■ проведение строительно-монтажных работ;

■ пуско-наладочные работы;

■ проведение приемочной комиссии;

* в проектах НИОКР:

О разработка технического задания; о согласование и утверждение; о проведение НИР;

О испытания (при наличии макетных образцов) и приемка

Результатов; о проведение ОКР; о испытания и приемка результатов

О технологические работы, масштабирование; о выпуск установочной партии;

С авторский надзор за использованием и внесение изменений в документацию;

• в ИТ-проектах по использованию новых программных продуктов: о разработка технического задания;

О разработка концепции (рабочего проекта); о согласование и утверждение; о выполнение работ; о приемка; о обучение персонала. На управленческой траектории вводить жесткую регламентацию на уровне компании может оказаться опасным. Проектная уникальность проявляется именно в управлении проектом. Компания может ввести лишь рекомендуемые этапы, а проектная команда при формировании управленческого плана, используя эти рекомендации в качестве конс­трукторской базы, сформирует свою уникальную последовательность этапов. Управленческие этапы могут быть скомбинированы из следу­ющих возможных действий: в на старте проекта:

О подготовка инициативы;

О формирование пула ресурсов, переговоры с собственниками

Ресурсов; о расчет результатов проекта; о расчет обоснования проекта; с расчет осуществимости;

• установление управленческих этапов:

О установление контрольных точек для анализа исполнения проекта;

О заранее предусмотренное внесение корректив в проектные показатели;

• подготовка версий проектных планов: о подготовка первичного плана;

О оптимизация проектных показателей; о подготовка последующих версий плана;

• по способу управления проектом:

О разработка организационной структуры управления; о разработка системы взаимодействия;

О установление распределения полномочий и ответственности; о подготовка схемы документооборота; о подготовка схемы документирования действий и событий; о установление специальной системы стимулирования членов

Проектной команды; о подготовка графика отчетности;

• по управлению проектной командой:

О о

• на этапе:

О подготовка і о роспуск проектной: о выплата премий.

Шить и дилемму результатов[1] проекта: цель проекта стоимость проекта. Результатом продуктового должна быть техническая цель проекта (построенное ное оборудование и т. д.). Результатом быть і

Которые

От проекта, относятся к категории требо - Как правило, требования и ограничения форму­лируются на самом раннем этапе проекта. К числу требований и ограничений могут относиться: , проект (создать продукт) не і

Еще до расчета бюджета);

* необходимо использовать только штатный персонал компании (на­оборот, часть функций должна выполняться по аутсорсингу);

* географические условия;

* экологические условия;

* требования по конфиденциальности и т. д.

Кат егория требований и ограничений относится к описанному выше магическому треугольнику. В связи с этим должно выполняться общее условие:

Все требования и ограничения должны быть документиро­ваны в плане проекта

Все допущения должны быть документированы в плане проекта.