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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие записи