4.2.2 Разработка плана управления проектом: инструменты и методы

.1 Экспертные оценки

При разработке плана управления проектом экспертные оценки используются для:

• адаптации процесса для удовлетворения требований проекта;

• разработки технических и управленческих деталей, которые будут включены в план управления проектом;

• определения ресурсов и уровней развития навыков, необходимых для выполнения работ по проекту;

• определения уровня управления конфигурацией, который будет применяться в проекте;

• определения того, какие документы проекта будут подвержены процессу формального управления изменениями.

4.2.3 Разработка плана управления проектом: выходы

.1 План управления проектом

План управления проектом интегрирует и консолидирует все вспомогательные планы управления и базовые планы, полученные в результате процессов планирования, и включает в себя, среди прочего:

• выбранный для проекта жизненный цикл и процессы, которые будут применяться в каждой фазе;

• результаты адаптации, полученные от команды управления проектом, а именно:

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

o   уровень реализации каждого выбранного процесса;

o   описания инструментов и методов, которые будут использованы для выполнения данных процессов;

o   порядок использования выбранных процессов для управления конкретным проектом, включая зависимости и взаимодействия между данными процессами, а также необходимые входы и выходы;

• порядок выполнения работ для достижения целей проекта;

• • план управления изменениями, документирующий порядок мониторинга и контроля изменений;

• план управления конфигурацией, документирующий порядок управления конфигурацией;

• порядок поддержания целостности базовых планов исполнения;

• потребности в коммуникации между заинтересованными сторонами проекта и методы ее реализации;

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

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

Базовые планы проекта включают в себя, среди прочего:

• базовое расписание;

• базовый план выполнения стоимости;

• базовый план по содержанию. 

Вспомогательные планы включают в себя, среди прочего:

• план управления содержанием (введение к главе 5);

• план управления требованиями (раздел 5.1.3.2);

• план управления расписанием (введение к главе 6);

• план управления стоимостью (введение к главе 7);

• план управления качеством (раздел 8.1.3.1);

• план усовершенствования процессов (раздел 8.1.3.4);

• план управления человеческими ресурсами (раздел 9.1.3.1);

• план управления коммуникациями (раздел 10.2.3.1);

• план управления рисками (раздел 11.1.3.1);

• план управления закупками (раздел 12.1.3.1). 

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

14. Сбор требований

«Поздравляем, вы будете делать этот проект» – говорит начальник и вы понимаете, что ничего не понимаете. «Что делать? Как делать? C кем делать? Когда делать?» – вот список вопросов, которые начинают крутится у вас в голове. Из этого списка ключевым безусловно является вопрос «Что делать?». Только ответив на него можно думать о «как, с кем, когда, …». Ответ на вопрос «Что делать?» прост – собирать требования заказчиков. Я не описался, практически не бывает случая, когда у проекта один заказчик. Как правило, проект афектит несколько областей, которые  курируются несколькими отделами/организациями/людьми. Простейший пример – установка новой бухгалтерской программы по начислению зарплаты затронет:

1. Бухгалтерию, которая будет его использовать

2. IT отдел который будет ее сопровождать

3. Финансовый отдел, который выделяет на нее деньги

4. Отдел по работе с персоналом, который ведет учет персонала

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

Итак, как же собирать требования?

1. Определите список различных аспектов (основных бизнес процессов, которые будут заафекчены) проекта

2. Узнайте кто отвечает  за эти процессы

3. Определите, кто с вашей стороны будет заниматься формированием требований по данному аспекту.

4. Уточните кто со стороны заказчика будет заниматься формированием требований по данному аспекту

5. Определите сроки и формат в котором будет происходить обсуждение требований

6. Определите список документов которые должны быть созданы как результат формирования требований и их формат

7. Определите дату когда эти документы будут подписаны заказчиком

8. Определите как будет заафекчен проект, если заказчик не сможет вовремя выдать ту или иную информацию

Определите  какие стандарты существуют в данной области (например, если вы создаете бухгалтерскую программу, то ищите бухгалтерские стандарты). Если возможно – используйте их. Ведь стандарт – это как минимум собранный за вас список требований.  Сославшись на стандарт вы сможете убедить заказчика, что его предложение или требование необоснованно, например.

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

Что же вам делать? Учить заказчика!  Учить, но не навязчиво! Кстати не забывайте при этом учиться у заказчика и подстраиваться под его процессы!

1. Расскажите ему, как у вас обычно проходят проекты

2. Спросите как у него обычно проходят проекты

3. Как выглядят ваши документы, как их понимать

4. Как выглядят ваши документы, как их понимать

5. Что вы ждете от него

6. Узнайте что он ждет от вас

7. Расскажите что обычно вы делаете в рамках проекта (что умеет делать стандартная бухгалтерская программа с примера сверху)

Следующий шаг на который нужно обратить внимание – как проводить 1 встречу по сбору требований. Но об этом в следующий раз.

15. Определение содержания

Определение содержания проекта - это процесс, в рамках которого происходит детальное описание проекта и его продукта.

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

Для более точного поманиния проекта его содержание может содержать в явном виде исключения из содержания.

Исключения из содержания приводятся для того, чтобы суть проекта понималась однозначно всеми заинтересованными лицами проекта.

  Обычно содержание проекта включает в себя:

• описание содержания продукта;

• критерии приемки продукта;   

• результаты проекта;  

• исключения проекта;

• ограничения проекта;

• допущения проекта.

16.Создание ИСР