Согласно опросам, проведенным удаленно среди более чем 500 менеджеров проектов со всего мира, комфортный психологический допуск превышения сроков проекта для них составляет не более чем 15% от планового показателя. Ни один из менеджеров проектов не назвал цифру 0%. Виной всему — неопределенность, которая преследует менеджеров проектов и команды в течение всего жизненного цикла проекта.
Точно такую же цифру приводят в своей книге «Вальсируя с медведями» Том ДеМарко и Тимоти Листер, они пишут о том, что руководителям проекта комфортно считать, что нормальный допуск – это плюс 10 — 15% от расчетного срока проекта без учета рисков: «То, что больше, кажется неправильным, каким-то недисциплинированным. Многие руководители даже считают это признаком слабости управления».
Так что же является допустимым отклонением от безрискового срока, рассчитанным на базе опыта?
По мнению вышеупомянутых авторов, для отрасли разработки программного обеспечения диапазон допуска составляет порядка 150 — 200% от интервала с начала проекта до даты N (то есть к расчетному сроку можно смело прибавлять 150 — 200%). Этот диапазон получился на базе статистики большого количества ИТ-проектов и демонстрирует нам, насколько сильно может отличаться базовый план по срокам, не учитывавший риски, от фактического плана.
Для того чтобы повысить вероятность успеха проекта, при прогнозе сроков и бюджета проекта нужно обязательно учитывать влияние рисков на проект и пересчитывать сроки и бюджет. Ну а для того, чтобы учесть риски, их сначала нужно «увидеть». Как это можно сделать?
Инструменты работы с неопределенностью
Начнем с диаграммы Исикавы. На главной оси диаграммы откладывается потенциальная проблема – например, срыв сроков проекта. На больших «костях» диаграммы откладываются источники возникновения риска.
Затем по каждому источнику риска проводится «мозговой штурм» относительно последствий, связанных с данным источником, которые могут привести к проблеме. Последствия записываются на вертикальных «косточках». Все записи на диаграмме — это и есть риски проекта, которые, однако, надо еще правильно сформулировать. Правильная формулировка риска должна включать в себя описание условия возникновения риска и его последствия.
К примеру, на диаграмме есть запись о таком последствии как «Болезни членов команды». Как правильно сделать формулировку риска?
Можно сформулировать риск так:
«Эпидемии инфекционных заболеваний в зимний период приведут к болезням членов команды проекта»
Или так:
«Жаркое лето вызовет необходимость использования кондиционеров в офисе, что приведет к болезням участников проекта»
Как видим, последствие у рисков одно, а условия возникновения — разные.
Давайте сформулируем риски «Изменения требований» для источника «Заказчик проекта»:
- «Недостаточно глубокая проработка требований на старте проекта приведет к необходимости изменения требований по ходу проекта».
- «Сложность понимания заказчиком требований к продукту проекта приведет к частым изменениям требований по ходу получения первых результатов».
Последующая работа с рисками сводится к поиску возможности воздействовать на причину (условие) возникновения риска, поэтому, чем точнее описана причина, тем проще найти «противоядие».
Если нарисовать диаграмму Исикавы для четырех аспектов проекта: сроков, бюджета, целей и качества, получим внушительный материал для идентификации рисков. Как видим, диаграмма Исикавы является базовым инструментом для поиска причинно-следственных связей по рискам. С ее помощью мы заставляем наш разум думать о рисках и искать причины их возникновения.
Еще один простейший способ поиска рисков – изучение документов по проекту, таких как ИСР проекта, техническое задание на продукты проекта, поиск аналогичных проектов в архиве проектов компании и изучение Реестров рисков и Усвоенных уроков этих проектов. Если руководители похожих по содержанию проектов вели «Журнал проблем» в проекте или хотя бы написали «Усвоенные уроки» — это уже хороший источник для идентификации рисков.
Следующий способ – это поиск и изучение отраслевых классификаторов рисков. Это, по сути, отрефлексированный опыт отрасли. Такие классификаторы очень полезны – ничего выдумать не надо, риски из таксономии рассматриваем как риски нашего проекта.
Хорошим примером классификатора является документ, выпущенный SEI (Software Engineering Institute) под названием Taxonomy-Based Risk Identification. Документ описывает три класса рисков для софтверных проектов, каждый класс декомпозируется на элементы и атрибуты. В документе дается описание методики проведения исследований для создания классификатора и собственно, сам классификатор с пояснениями.
Стоит отметить, что таксономии рисков особенно полезны с учетом отраслевой специфики: если вы управляете проектом строительства, нужно искать таксономию отраслевых рисков.
Есть и более сложные инструменты идентификации рисков, такие как:
- анализ силового поля,
- метод номинальной группы,
- карточки Кроуфорда.
Все они используют знания экспертов для получения информации. Обнаруженные на этапе идентификации риски заносятся в документ «Реестр рисков» (он может иметь и другое название), в котором важно прописать формулировку риска и примерное время его наступления.