Выделяют несколько процессов, связанных с начальной фазой и инициацией проекта.
Делается это для возможности применения принципа последовательной разработки проекта, при которой каждый последующий шаг в проекте может уточнять и дополнять решения и документы, согласованные на предыдущем шаге.
Набор процессов, реализуемых менеджером при инициации проекта, может быть различным.
В общем виде процессы инициации изображены на рисунке 1.
Рисунок 1 – Процессы инициации проекта
Как видно из этого рисунка, основными задачами в ходе инициации проекта являются:
1) понимание основных заинтересованных сторон проекта, их интересов и ожиданий от проекта и его результатов;
2) сбор требований от заказчика и иных заинтересованных сторон;
3) формальный авторизованный старт проекта путем выпуска документа «Устав проекта» и проведения стартового совещания по проекту.
Изображенная на рисунке последовательность процессов является условной. В реальности все перечисленные процессы выполняются параллельно. Невозможно выпустить Устав проекта, не понимая заинтересованных сторон и их требований к проекту. Невозможно собрать требования, не понимая состава заинтересованных сторон, которые эти требования и определяют. Исключением является стартовое совещание по проекту, которое проводится в специально определенное время.
Процессы организации стартового совещания будут рассмотрены далее.
Рассмотрим процесс разработки Устава проекта.
Устав проекта – документ, формально авторизующий проект или его фазу, содержащий исходные требования, которые удовлетворят нужды и ожидания заинтересованных сторон проекта.
Устав содержит бизнес-потребности, обоснование проекта, текущее понимание потребностей заказчика, а также описание продукта, услуги или результата, который должен быть достигнут в ходе проекта.
Целью его разработки является авторизация и формализация проекта путем четкого очерчивания границ проекта, документирования его целей и результатов, определения менеджера проекта, зоны его ответственности и полномочий.
Устав создается вышестоящей администрацией, и предоставляет менеджеру проекта полномочия привлекать ресурсы организации для выполнения работ проекта.
Документ определения проекта может называться по-разному: «Устав», «Паспорт», «Декларация» или «Определение проекта».
Но цель его как исходного интеграционного документа – обеспечить однозначное понимание и зафиксировать:
1) обоснование инициации проекта;
2) цели и результаты проекта;
3) описание и структуру продукта проекта;
4) ожидания ключевых участников проекта;
5) критерии успеха проекта;
6) фамилию менеджера проекта и зону его ответственности в проекте;
7) основные принципы организации проекта и управления им.
Устав проекта – документ, разработка которого направлена на обеспечение следующих результатов:
1) авторизацию проекта;
2) определение проекта;
3) назначение менеджера проекта и распределения ролей основных участников проекта.
Во многих компаниях началом проекта считается дата утверждения Устава проекта. Однако сама разработка, уточнение и согласование Устава проекта часто занимают значительное время. Устав разрабатывается в несколько итераций и может уточняться походу выполнения проекта.
Поэтому иногда на практике перед началом разработки «Устава проекта» выпускается Приказ о запуске проекта.
Выпуск Приказа о запуске проекта преследует в меньшей степени задачу продекларировать «волеизъявление» руководства компании: «мы повелеваем начать проект».
В гораздо большей степени он преследует цели наведения управленческого порядка в начинающемся проекте:
- фиксация даты, с которой проект считается начавшимся;
- определение названия (иногда еще и краткого названия) проекта;
- присвоение определенных классификационных характеристик: тип проекта, приоритет, принадлежность к портфелю или программе и т.п.;
- назначение руководителя проекта, куратора и ответственных за отдельные блоки функциональных задач;
- определение планов и сроков последующих шагов проработки проекта.
Пример шаблона Приказа о запуске проекта дан на рисунке 2.
Рисунок 2 – Приказ о запуске проекта (шаблон)
Устав проекта дисциплинирует.
Если есть проект, должен быть Устав проекта.
В Уставе описаны цели, определены критерии успеха. Участники проекта теперь не могут понимать их по-разному.
Устав утвержден в определенный момент времени. Этот момент можно считать днем начала проекта.
Высшая инстанция (заказчик проекта, инвестор, руководитель организации, внутри которой реализуется проект), утверждая Устав, авторизует проект именно в таком виде, объеме, структуре и санкционирует его выполнение.
Менеджер проекта, согласовывая Устав, четко фиксирует зону собственной ответственности за проект. Устав определяет, как будет измеряться успех или неудача проекта, и объем полномочий, делегируемых менеджеру.
Результаты процесса
Результатами процесса разработки Устава проекта являются однозначное понимание содержания проекта всеми его участниками и авторизация начала проекта лицами, принимающими решение.
Выходным документом процесса является Устав проекта.
Пример шаблона Устава проекта дан на рисунке 3.
Рисунок 3 – Устав проекта (шаблон)
Устав – один из первых, а часто – первый документ, который возникает в проекте.
В его разработке должны участвовать различные участники проекта. Он должен свести воедино все интересы и видения проекта. Поэтому на практике подготовить Устав проекта с первого раза обычно не получается.
Принцип последовательной разработки в полной мере относится и к разработке Устава проекта.
Разработка Устава происходит в несколько итераций.
На первых порах, пока цели проекта не ясны, видны лишь замысел и идея. Инициатор (заказчик, куратор или спонсор) набрасывает первую версию документа, в котором укрупненно формирует цели и ожидаемые результаты. Эта версия документа передается менеджеру проекта как исходное задание на проект.
Назначенный менеджер проекта собирает дополнительную информацию, детализирует и уточняет документ. В ходе доработки могут подвергаться коррекции многие разделы документа, так как появляется новая информация, подтверждаются или опровергаются первоначальные предположения, согласуются спорные вопросы. А версия, которая будет утверждена, скорее всего претерпит еще несколько уточнений и дополнений.
Обойтись без Устава проекта при реализации внутреннего проекта в организации невозможно. Он играет роль договора между внутренним заказчиком и внутренним исполнителем в организации.
Устав может разрабатываться и для контрактного проекта в ситуации, когда существует договор, четко описывающий взаимоотношения заказчика и исполнителя.
Устав охватывает большое число вопросов, которые в контракте не затрагиваются. А в случае, когда в проекте участвуют несколько исполнителей, ценность Устава как управленческого документа значительно возрастает. Каждый контракт с отдельным исполнителем охватывает отдельный блок работ по проекту. Каждый подрядчик видит свои работы и выполняет их. Весь проект видит лишь менеджер проекта или заказчик. А иногда полностью проект не представляет никто.
Устав проекта – это интеграционный документ, охватывающий весь проект целиком.
Устав проекта должен определить проект, сделать его прозрачным и понятным для всех участников, а также учесть их интересы и ожидания.
Перейдем к анализу заинтересованных сторон.
Целью этого процесса является понимание возможных зон воздействия на проект со стороны его участников и внешних заинтересованных сторон путем выявления основных лиц, групп и организаций, имеющих прямые или косвенные интересы в проекте.
Заинтересованные стороны (стейкхолдеры) в проекте существуют независимо от нашего желания. Если бы их не было, проект никогда бы не состоялся. При этом их интересы весьма различаются. Одни заинтересованные стороны проект запускают, продвигают к успеху, другие стороны имеют иные интересы.
Интересы по отношению к проекту могут быть:
- положительными или отрицательными;
- прямыми или косвенными;
- явными и неявными (скрытыми).
Действия заинтересованных сторон иногда способствуют успеху проекта, а иногда – нет.
Заинтересованные стороны будут влиять на окружение проекта (см. рисунок 4), создавая для менеджера проекта либо позитивные условия, либо серьезные препятствия для успеха проекта.
Выделяют ближнее и дальнее окружение проекта. В ближнем окружении основными заинтересованными сторонами являются руководство организации, представители функциональных подразделений, сотрудники, в дальнем – конкуренты, органы власти, представители общественных организаций.
Рисунок 4 – Окружение проекта
В ходе анализа заинтересованных сторон в проекте рекомендуется выделить основные группы заинтересованных сторон и понять их интересы для:
- назначения явных заинтересованных сторон (участников проекта) на роли, соответствующие их интересам;
- согласования с ключевыми внутренними (а иногда и внешними) заинтересованными сторонами целей и результатов проекта;
- выявления угроз и зон риска со стороны заинтересованных сторон, негативно настроенных по отношению к проекту;
- определения потенциальных возможностей (в т.ч. дополнительных), возникающих в случае активного привлечения соответствующих заинтересованных сторон;
- установления информационных потребностей заинтересованных сторон и дальнейшего включения их в коммуникационное поле проекта.
Обратная связь процесса
Результаты анализа заинтересованных сторон могут значительно повлиять на содержание Устава проекта и процесс сбора требований (см. рисунок 1).
Результаты процесса
Результатами процесса анализа заинтересованных сторон являются готовность менеджера и команды проекта к влиянию, оказываемому на проект различными заинтересованными сторонами, и минимизация негативных эффектов этого влияния.
Заинтересованные стороны и их интересы могут быть отражены в Реестре заинтересованных сторон.
Для каждой заинтересованной стороны в этом документе полезно зафиксировать:
- имя человека или название группы, представляющих заинтересованную сторону;
- отношение заинтересованной стороны к проекту (положительное, отрицательное, нейтральное);
- силу возможного влияния на проект;
- степень информированности о проекте, его целях и текущем состоянии;
- дополнительные условия, при которых отношение к проекту может измениться.
По итогам анализа заинтересованных сторон проекта могут быть внесены изменения в существующие проектные документы: Устав, План проекта и другие.
Рассмотрим процесс сбора требований к проекту.
Целью данного процесса является достижение более полного, четкого и однозначного понимания целей и результатов проекта, а также ожиданий заказчика и иных заинтересованных сторон в части, касающейся функциональных, технических, пользовательских и иных характеристик продукта проекта.
Необходимо получить, понять, проанализировать и документально зафиксировать требования основных заинтересованных сторон, которые могут повлиять на содержание проекта и организацию его выполнения.
Требования могут относиться к любым аспектам проекта:
- целям и результатам;
- продукту проекта и его характеристикам;
- жизненному циклу проекта, этапам или составным элементам проекта;
- условиям реализации проекта и правилам выполнения отдельных работ;
- схемам финансирования или привлечения средств;
- условиям взаимодействия между участниками;
- правилам приемки продукта или сдачи результатов промежуточных этапов и т.п.
Чаще всего требования распространяются на цели и результаты, а также на продукт проекта. Основную роль в определении требований играют ключевые заинтересованные стороны, в первую очередь заказчик.
Кроме того, при определении требований к продукту проекта важным является понимание таких заинтересованных сторон, как пользователи, будущие покупатели (клиенты), эксплуатирующая организация.
Обратная связь процесса
Процесс сбора требований может сильно повлиять на содержание Устава проекта. При более детальном и подробном описании требований заказчика, пользователей и других заинтересованных сторон проекта может оказаться, что первоначально сформулированные цели и результаты проекта должны быть скорректированы.
Результаты процесса
Результатом процесса сбора требований должна стать минимизация дополнительных требований и пожеланий заказчика по отношению к продукту проекта и проекту в целом, возникающих в ходе его реализации. В идеальной ситуации их не должно быть совсем. Как следствие, это должно привести к минимизации внесения изменений в проект на более поздних этапах.
Иногда по итогам процесса сбора требований создается документ Требования к продукту или Технические требования к проекту. В зависимости от содержания проекта название документа может изменяться.
Рассмотрим теперь процесс организации стартового совещания по проекту.
Целью стартового совещания по проекту является информирование всех заинтересованных сторон проекта об основных решениях, принятых в ходе инициации проекта, и согласование с ними утверждаемых проектных документов.
Эффективно проведенное стартовое совещание может дать мощный импульс всему проекту и задать верное направление работе команды проекта.
В повестку дня стартового совещания по проекту рекомендуется включить следующие пункты:
- представление менеджера проекта, куратора и заказчика;
- знакомство участников;
- идея и замысел проекта, предпосылки и обоснование его запуска;
- основные положения Устава проекта;
- распределение ролей в команде проекта и степени загрузки участников в проекте;
- принципы организации и взаимодействия в проекте.
Присутствие на стартовом совещании по проекту куратора, заказчика и иных важных участников поднимет статус проекта и статус менеджера проекта в глазах членов проектной команды.
Согласование с командой целей и результатов, принципов работы и взаимодействия позволит вовлечь участников в процесс управления и принятия решений по проекту, что должно повысить их ответственность и мотивацию.
Результаты процесса
Результатом стартового совещания по проекту должно стать четкое, общее и одинаковое понимание участниками проекта его целей и задач, текущего статуса, системы организации проекта и своего места в команде начинающегося проекта.
Рассмотрим основные риски фазы инициации проектов.
Анализируя основные причины и факторы неудач проектов, основа которых была заложена на начальных фазах проекта, можно прийти к выводу о том, что среди них часто встречаются следующие:
1) нечеткое понимание целей и границ проекта;
2) неформализованный подход к запуску проекта;
3) необоснованный запуск проекта.
Нечеткое понимание целей и границ проекта
Проект всегда направлен на достижение определенных целей. Число участников проекта может быть очень большим. И каждый из них может иметь свое понимание целей.
Кажущееся ощущение, что все участники проекта одинаково понимают его цели и результаты, ошибочно (особенно опасно исходить из подобного предположения на начальных фазах проекта, а именно в ходе целеполагания, определения проекта и очерчивания его границ). Видение, понимание, осознание проекта у разных его участников очень сильно различаются.
Прежде всего, необходимо помнить, что различные участники и заинтересованные стороны проекта имеют в нем различные интересы. Через призму этих интересов они видят цели и результаты проекта.
Например,
Опытная девелоперская компания, начиная амбициозный проект строительства небоскреба, который попадет в список 10 самых высоких зданий мира, предполагает, что цены апартаментов и офисов в подобном здании будут очень высоки. Это позволит повысить прибыльность проекта, что, собственно, и является одной из главных целей проекта с точки зрения инвестора.
С другой стороны, власти мегаполиса, выдавая разрешение на строительство такого небоскреба-рекордсмена в деловой части города, в первую очередь преследуют имиджевые цели. Если рыночная обстановка вынудит девелопера отказаться от строительства именно такого здания на этом месте, может возникнуть конфликт с властями, ожидающими исполнения первоначального замысла.
Иногда заказчик проекта не находит времени или вообще не считает нужным довести до сведения команды цели проекта. Как следствие, участники проекта пытаются понимать цели самостоятельно. Получается это неточно и неполно. Затем неточно и неполно понятые цели преломляются сквозь призму собственных интересов участника. В итоге цели, которые достигаются в проекте, порой кардинально отличны от тех, которые задумывали инициаторы проекта.
Например,
Компания-производитель заказывает организацию делового обучения для своих дилеров в целях доведения до их сведения своей новой маркетинговой стратегии и знакомства с модельным рядом следующего года. Для повышения эффективности обучения и полного отрыва от производства сотрудников обучение организуется на выезде, в другой стране. При этом цели и результаты мероприятия определяются для исполнителя в общих чертах, без деталей.
Компания-организатор конференций и семинаров, предполагая, что обычно выездное обучение имеет своей целью во многом мотивирующую функцию, предлагает сделать ее в Стамбуле. Это якобы совпадает с ожиданиями заказчика, желающего провести обучение с отрывом от производства и полным погружением в учебную программу. Подрядчик подбирает живописную площадку с изумительными видами на море, тщательно готовит культурную программу.
В итоге сотрудники компаний-дилеров после обучения в анкетах обратной связи отмечают, что был слишком напряженный график, совершенно не было времени отдохнуть и отвлечься. Вместо обучающего эффекта достигнут эффект демотивации участников обучения.
В некоторых случаях, информирование всех участников проекта о реальных целях просто невозможно в силу конфиденциальности информации, необходимости сохранить коммерческую тайну. Порой проект содержит целый ряд дополнительных «политических», зачастую скрытых неявных целей, посвящать в которые исполнителей нецелесообразно.
Но необходимо трезво отдавать себе отчет, что чем меньше участники проекта понимают цели проекта, тем более далеки будут полученные результаты от ожидаемых заказчиком. Кроме того, в таких «политизированных» проектах дополнительные и скрытые цели часто оказываются самыми главными и важными.
При любых условиях ясное и четкое понимание целей проекта его участниками значительно повышает вероятность их достижения и, как следствие, вероятность завершения проекта высокая.
Неформализованный подход к запуску проекта
Зачастую начальная фаза проекта выполняется на основании устных распоряжений вышестоящего руководства. Нередкой является ситуация, когда руководитель департамента, вызвав начальника подотчетного ему отдела или конкретного менеджера, дает ему задание «проработать вопрос», «проанализировать возможность» или «подготовить проект». В половине случаев это является текущей задачей и действительно не требует дополнительной формализации. Но в половине случаев подобные работы затем переходят в серьезный проект, т.е. они являются частью работ по инициации и запуску проекта.
Указанные работы обязательно должны быть формализованы и документально оформлены.
Неформальный подход к инициации проекта порождает большое число рисков:
1) исполнитель, не наделенный необходимыми формальными полномочиями, не сможет привлечь специалистов требуемой квалификации. Выполнение работ своими силами может оказаться более низкого качества, а иногда даже невозможным;
2) неформальная задача не будет отражена в стандартных учетных документах (отчетах, табелях и т.п.), информация о сроках и трудозатратах будет утеряна;
3) цели и результаты неформально поставленной задачи могут быть искажены исполнителем, и, как следствие, будет получен некорректный результат;
4) неформализованная задача, возможно, породит такой же результат. Не факт, что исполнитель для такой работы посчитает необходимым готовить какие-либо строгие отчетные документы. Сотрудники, которые будут вовлечены в проект на последующих этапах, не обладая всей полнотой информации, будут вынуждены часть работы выполнить повторно.
Необоснованный запуск проекта
Любой проект, запускаемый организацией, должен иметь четкую направленность на достижение стратегических целей компании или подготовку условий для этого достижения. К сожалению, во многих компаниях довольно большое число проектов запускается без должного обоснования их соответствия стратегии компании. Часто запуск проекта происходит на основании устных распоряжений высшего руководства, базирующихся на их «ощущениях» или «чутье». Также при расстановке приоритетов проектов в портфеле проектов компании часто выбор падает на проекты, удовлетворяющие разнообразные политические или «клановые» интересы.
Например,
Проект строительства нового мини-завода в Твери как филиала деревообрабатывающей фабрики из Нижнего Новгорода на первый взгляд является абсолютно обоснованным и разумным. Ведь в результате осуществления проекта появится возможность выйти на новый рынок, производить больше продукции и, соответственно, получить дополнительную прибыль.
Однако, внимательно ознакомившись со стратегией компании, узнаем, что ее важнейшими стратегическими целями являются «повышение качества выпускаемой продукции за счет внедрения современных стандартов качества» и «удержание рынка путем предоставления более качественной и конкурентоспособной продукции по более низким ценам».
Если экспансия и захват рынка других регионов не входят в число стратегических целей компании на данном этапе развития, значит, проект не должен запускаться. Он должен уступить место другому, более соответствующему стратегии компании, например проекту внедрения системы менеджмента качества и сертификации компании по стандартам ISO.