Что нужно сделать до старта проекта. Часть 1

- К чему в первую очередь сводится задача руководителя проекта? Размышляя над этим, я пришел к убеждению, что управление проектом - это снижение неопределенности в нем.

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

Определение продуктов (результатов) проекта, а также проработка требований к каждому из них - одни из самых действенных способов, которые помогают снизить неопределенность. Чем точнее проработаны эти требования, тем легче руководителю проекта и его команде спрогнозировать объемы работ, сроки и бюджет проекта.

Вторым важным инструментом для снижения неопределенности может стать работа с допущениями проекта. Мне встречалась следующая формулировка: допущение - это фактор, существенный для достижения целей проекта, на который команда исполнителей проекта не может повлиять. Это, на мой взгляд, весьма точная трактовка, которую я и буду использовать в дальнейшем.

При формулировке допущений можно использовать следующий алгоритм:

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



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



3. После составления списка гипотез определяется, можно ли их уточнить и проверить до старта проекта. Если это возможно сделать только в ходе проекта и команда проекта не может повлиять на гипотезы, то они являются допущениями.

Рассмотрим, как определить допущения на примере проекта «Внедрение в компании CRM-системы». Например, руководство компании сформулировало следующие цели проекта:

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

Заказчик проекта на основании целей определил продукты проекта:

1. Регламент, описывающий работу сотрудников с клиентами.



2. Программный продукт, автоматизирующий алгоритмы, описанные в Регламенте.



3. Обученные работе с программным продуктом сотрудники.



4. Работающий сервис поддержки пользователей программного продукта.

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

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

А вот когда мы описываем фактор, связанный с заинтересованными сторонами проекта (например, намерениями Заказчика проекта или сотрудников компании), мы не можем быть уверенными, что хорошо понимаем их намерения. Они остаются неопределенными (кроме случаев, когда зафиксированы в контракте, т.е. известны и их трудно изменить).

Как только мы сформулировали допущение, нужно поставить под сомнение его достоверность и сформулировать риски. Что, если сотрудники компании будут тратить на проект не 10% от рабочего времени, а гораздо меньше? В этом случае можно сформулировать риск: «Выделение ресурсов на проект в объеме, меньше чем планировалось, приведет к срыву сроков по задачам проекта».

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

Итак, идея работы с допущениями следующая:

1. Руководитель проекта генерирует гипотезы относительно целей и продуктов проектов, а также задач по его реализации.



2. Из гипотез отбираются допущения по проекту - по правилу, описанному выше.



3. Проводится анализ допущений с целью поиска пропущенных или неверных допущений.



4. Каждое допущение ставится под сомнение: «Что будет если оно не оправдается?» и формируется список рисков по допущениям.



5. Эти риски попадают в Реестр рисков, с ними проводится работа по антирисковому планированию. О том, как ведется работа по планирования антирисковых мероприятий, я писал в своей статье.

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

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

Продолжение следует.