В шапке
Что нужно сделать до старта проекта? Часть 2. Допущения проекта

Что нужно сделать до старта проекта? Часть 2. Допущения проекта

В предыдущей статье цикла я написал о том, что одна из ключевых задач руководителя проекта – это снижение неопределенности в проекте (http://project-management.zis.by/planirovanie-proekta/chto-nuzhno-sdelat-do-starta-proekta.html). И первый шаг для снижения неопределенности – эта работа надо формулированием целей проекта и необходимых для их достижения результатов проекта, а также сбор и анализ требований к результатам.

Следующий важный шаг – формулирование допущений по проекту.

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

В одном из подходов к управлению проектами, PMBOK, дано следующее определение:

Допущение проекта – это фактор в рамках процесса планирования, который считается верным, реальным или определенным без предоставления доказательств и без демонстрации.

Честно говоря, мне это определение не кажется четким и понятным. В одной из статей я увидел следующее определение:

Допущение проекта – это фактор, существенный для достижения целей проекта, на который команда исполнителей проекта не может повлиять.

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

  1. Изучаем цели проекта и формулируем важные для достижения целей гипотезы.
  2. Изучаем результаты (продукты) проекта и формулируем важные гипотезы для получения этих результатов в срок и в бюджет.
  3. Если к моменту обсуждения уже есть требования к результатам проекта, изучаем их и формулируем важные гипотезы относительно требований.
  4. Получив список гипотез, нужно уточнить, может ли команда проекта до старта проверить гипотезу. Если гипотезу можно проверить только в ходе проекта, и команда проекта не может повлиять на нее, то эта гипотеза является допущением.

Рассмотрим, как можно формулировать допущения на примере проекта внедрения в компании CRM-системы.

Напомню, что Заказчик сформулировал следующие цели для проекта:

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

И для достижения целей проекта были сформулированы следующие результаты проекта:

  1. Регламент, описывающий работу сотрудников с клиентами;
  2. Программный продукт, автоматизирующий правила работы с клиентами, описанные в Регламенте;
  3. Обученные работе в программном продукте сотрудники компании;
  4. Работающий сервис поддержки пользователей программного продукта.

Изучив цели проекта и продукты, руководитель проекта CRM сформулировал следующие гипотезы, важные для достижения целей проекта и получения результатов. После чего руководитель проекта для каждой гипотезы ответил на вопрос: «Может ли команда проекта проверить гипотезу до старта проекта?»:

Гипотеза Может ли команда проекта проверить гипотезу до старта проекта?
Компания определила конкретного сотрудника, который будет выполнять в проекте роль Заказчика, и этот сотрудник понимает, в чем заключается ответственность и полномочия Заказчика проекта Да
Заказчик проекта не изменит цели проекта в ходе его реализации Нет
Заказчик проекта не будет изменять или добавлять требования к продуктам проекта, собранные к моменту старта проекта Нет
Руководители компании понимают, какие именно процессы входят в систему CRM, и имеют согласованную точку зрения по этому вопросу Да
Заказчик проекта не готов изменять бизнес-процессы компании под алгоритмы работы, заложенные в программный продукт, автоматизирующий CRM Нет
Выбранный программный продукт можно будет без особых сложностей доработать под требования, содержащиеся в Регламенте Нет
Сотрудники компании понимают цель проекта внедрения CRM Нет
Используемый на данный момент программный продукт для CRM не устраивает руководство компании Да
До выбора программного продукта будут сформулированы бизнес-требования и нефункциональные требования к программному продукту Да
Для выбора компании-подрядчика на работы по поставке, доработке и внедрению программного продукта будут разработаны Критерии отбора поставщика услуг Да
Сотрудники компании будут тратить не менее 10% от имеющегося рабочего времени на работу в проекте Нет
Экономический кризис не усугубится и Спонсор проекта не остановит проект

Нет

 

Таким образом, все сформулированные в таблице гипотезы, по которым был получен ответ «Нет», становятся допущениями проекта.

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

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

Как только мы сформулировали допущение, его достоверность нужно поставить под сомнение и сформулировать риски.

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

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

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

Что дальше делать с допущениями? Алгоритм работы следующий:

  1. Руководитель проекта формулирует допущения по проекту по алгоритму, описанному выше;
  2. Проводится анализ допущений с целью поиска пропущенных или неверных допущений;
  3. Каждое допущение ставится под сомнение «Что будет, если допущение не оправдается?» и формируется список рисков по допущениям;
  4. Эти риски попадают в Реестр рисков, с ними проводится работа по антирисковому планированию. О том, как ведется работа по планирования антирисковых мероприятий, я писал в этой статье: http://project-management.zis.by/upravlenie-riskami/kak-antiriskovye-meroprijatija-vlijajut-na-srok-i-bjudzhet.html

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

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

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

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

Комментарии (7)
Макс Якубович2017-07-31 07:34:33
Но, как я и написал в статье, это определение мне не очень понятно. Ваше определение тоже имеет право на жизнь. Мне кажется , что в случае такого определения как у Вас, технология работы с допущениями не изменится. Или я не прав?
Макс Якубович2017-07-31 07:24:34
Ольга, приведу определение из PMBOK : "Допущение - фактор в рамках процесса планирования, который считается верным, реальным или определенным без предоставления доказательств и без демонстрации.
Ольга Виноградова2017-07-31 07:20:53
Мне кажется, что ваше определение допущений, как фактора, на который команда не может повлиять не совсем полно. В стратегии "допущение" - это предположение сделанное по поводу фактов, которых не хватает для того, чтобы планировать. Мы чего-то не знаем (и это м.б. и внутри и вне системы проекта и под нашим влиянием и вен его), но нам нужно для планирования и мы предполагаем.
ещё комментарии
Войти как