Планирование. Приступаем к планированию

Приступаем к планированию

Планы – это средство коммуникации.
Входные данные:
устав проекта
Устав подписан. Следующий наш шаг – планирование. Ему в проектном управлении отводится особое место.
Для чего нам нужны планы:
Чтобы не забыть что-то существенное во время выполнения проекта
Чтобы любой член команды сам, не спрашивая менеджера, в любой момент времени понимал, «что ему делать сейчас»
Чтобы общаться.

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

Как писать правильные планы?
План – это не «клятва», а «прогноз». Во многих сферах (в том числе и в сфере информационных технологий) невозможно совершенно точно прогнозировать продолжительность, а порой и состав работ. Может показаться, что это дискредитирует идею планирования, однако это не так. Помните – что нельзя спланировать, нельзя и сделать.
Планируйте с «диапазоном». Не выдавайте (и не требуйте) точную оценку там, где ее дать нельзя. Донесите до всех членов команды и экспертов, которые помогают вам планировать проект, что вы не просите с них клятву «уложиться к определенной дате», вам нужна реалистичная оценка и возможные отклонения от нее. Однако настаивайте на реалистичности оценок. Говоря об инициации проекта приемлемой является «грубая» оценка (с диапазоном колебания до +/-50%). В ходе планирования такая точность может не устраивать. В зависимости от того как глубоко продвинулись – приемлемым диапазоном может быть +/-10%.
Опасайтесь завышения оценок. Член команды, эксперт или менеджер, поставленный в жесткие условия («выдать реалистичные оценки») испытывает соблазн завысить свои прогнозы, чтобы подстраховаться. Чтобы противостоять этому, особенно общаясь с техническими экспертами, многократно превосходящими в своих инженерных компетенции – нужен очень серьезных навык общения и знание психологии людей.
Планы будут изменяться. На это необходимо ориентироваться сразу. В отличие от устава, единожды созданного и практически не подверженного изменениям, планы проекта – документы весьма «живые». По ходу выполнения работ, могут выявляться новые нюансы, детали, форс-мажоры. Чтобы планы оставались достоверными – придется их корректировать. Это нормально, главное, чтобы процесс корректировки был тоже заранее согласован, и в обход него никто не мог бы вносить изменения в планы.

План управления проектом
План управления проектом – это совокупность всех проектных планов.
План управления проектом – это не бумажка с перечнем шагов «нужно сделать», это общее название всех планов проекта, каждый из которых «живет» и модифицируется по мере выполнения работ.
Очевидно, что некоторые элементы плана проекта могут быть подписаны спонсором, другие – достаточно формально согласовать с командой. Какие-то элементы плана будут доступны всем заинтересованным лицам, другие – избранным, определенные разделы удобнее вести в свободном формате, для других лучше подойдет специализированное ПО.

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

Корректировка «плана управления проектом» – осуществляется в течение всего проекта, в ответ на изменившиеся внешние условия, реализовавшиеся риски и т.д. Предсказать, где и когда понадобятся изменения заранее невозможно, посему их не планируют заранее, а осуществляют при помощи механизма «контроля изменений».
Некоторые из шагов возможно отнимут достаточно много времени (такие, как планирование содержания, оценка времени и стоимости, создание расписания и бюджета), другие, возможно, удастся выполнить за несколько минут.

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

Планируем содержание
Вход:
устав проекта
состав «плана управления проектом»
Что такое «содержание проекта»?
Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт.
Для описания всех необходимых работ по проекту нужно:
определиться с требованиями и ожиданиями заказчика;
разобраться, какие из них реально выполнимы, и что для этого понадобится.
На языке нашей методологии данные шаги звучат следующим образом:
Собрать и финализировать требования
Сформировать концепцию

Сбор требований
Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе (вполне возможно, что они описаны несколькими предложениями). Теперь стоит задача конкретизировать их.
Чтобы справиться с ней – необходимо понять «кто» является источником требований на проекте и «что» конкретно он хочет получить по окончании работ.
Лучшие проектные практики гласят:
проект с неудовлетворенными ожиданиями заказчика не является успешным
проект, результаты которого не используются конечными пользователями, не является успешным

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

Выявляем заинтересованных лиц
Эту работа началась еще в фазу инициации (определив самых основных лиц), теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц».
Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.
По какому принципу мы называем того или иного человека «заинтересованным лицом»?
Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае нельзя пренебрегать их интересами в проекте).
Не бойтесь включать в реестр большое количество людей. Всегда можно классифицировать их по «степени влияния на проект» позднее и работать только с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).

Готовимся к сбору требований
По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований.
Введем два термина: «требование» и «ожидание».
Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.
Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».

Методы
Выбирая методы, необходимо тщательно взвесить потребности в информации и способности второй стороны ее предоставить.
Из наиболее распространенных можно выделить:
Интервью
Опросники
Прототипирование

Методы
Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Непосредственное общение позволяет собрать наиболее полную и достоверную информацию, а также установить конструктивный рабочий контакт с собеседником. Главный минус – трудозатраты (придется тратить свое и чужое время в больших количествах).
Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации.
Прототипирование – это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (будь то картинка, макет или какой-либо аналог). Прототипирование удобно сочетать с другими техниками (например, интервью); главное не ограничиваться только им, дабы не упустить существенные моменты, не реализованные в прототипе, но важные для продукта.

Сбор требований
Если в компании есть специалисты по сбору и описанию требований (например, аналитики), тогда все заботы в этой области перекладываются на них. Это очень неплохой сценарий, ибо требования являются самой сложной и трудоемкой для описания «гранью треугольника».
Однако, даже делегируя свои хлопоты – не выключайтесь из процесса и помните, что каждый день кто-то из членов команды (не обязательно аналитик) сталкивается с пожеланиями заинтересованных лиц, которые не были учтены раньше. Необходимо организовать работу так, чтобы каждый сотрудник в любой момент имел доступ к перечню выявленных требований – мог бы его просмотреть и дополнить.

Балансировка требований
Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.
Сначала из требований выделяют наиболее значимые, а затем отбираем к реализации те из них, которые возможно уложить в рамки проектных ограничений (стоит помнить, что некоторые требования могут оказаться взаимосвязаны и включать или исключать их можно только вместе).
На данном этапе присутствуют лишь предварительные (грубые) оценки стоимости и сроков проекта и пока не известно точно, сколько «будут стоить» и длиться выбранные работы. В текущих оценках необходимо полагаться на профессиональный опыт и чутье. Позже, когда себестоимость и продолжительность работ будет оценена, можно вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, скажем, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то нельзя выбросить подобное требование из реестра.

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

Концепция
Данный документ будет содержать как общую информацию о проекте, так и ссылки на всевозможные требования и описания продукта, так что новый сотрудник, в зависимости от характера своих вопросов – сможет самостоятельно найти максимум информации без посторонней помощи. Не менее важно и то, что «концепция» содержит описание «проектного подхода». Какие правила общения с заказчиком имеются на проекте? Как мы условились с командой проводить совещания? Где посмотреть, кто, за что отвечает на проекте? Как поступать при необходимости внести изменения в первоначальные требования или добавить новое?
Сама по себе концепция может быть немногословна, но изобиловать ссылками на внешние документы (избегайте ненужного переписывания информации из документа в документ – ограничивайтесь ссылкой; это сэкономит силы и многократно облегчит поддержание целостности и непротиворечивости информации).

Концепция
Один из возможных шаблонов «концепции» лежит в папке.
Теперь любой член команды (будь то разработчик, тестировщик или нанятый для консультаций эксперт) может максимально четко представить себе общую задачу и свою конкретную роль.
Выход:
Реестр заинтересованных лиц
Матрица требований
Концепция проекта

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

Оценка ресурсов
Обсудив принципиальное наличие ресурсов внутри организации – выясните, когда и на какой срок их можно задействовать в вашем проекте. Возможно, единственный подходящий специалист уже задействован на 120% до конца года? Или требуемый нам сервер можно получить в свое распоряжение лишь на пару дней? Все это может быть поводом для проведения закупок или привлечения подрядчиков.
Будем ли привлекать подрядчиков?
В подавляющем большинстве проектов для выполнения определенных работ можно привлечь стороннюю организацию (если это допускает специфика отрасли и нее противоречит специальным положениям контракта или политики компании).

Оценка ресурсов
Некоторые из «лучших проектных практик» рекомендуют такой подход:
Обязательно использовать субподряды:
Если это снижает риски проекта
Можно использовать субподряды:
Если мы бережем («испытываем дефицит») собственных ресурсов
Если мы пытаемся повысить управляемость проекта
Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.
Обратите внимание на пункт, касающийся «управляемости проекта». Иногда ее легче сохранить, поручив блок работ сторонней компании, чем контролировать множество собственных сотрудников, особенно если те, время от времени перемещаются на другие проекты, а к нам взамен приходят еще «не погруженные» в рабочий процесс люди.

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

Список ресурсов
Список ресурсов – совокупность договоренностей о выделении ресурсов на проект (обычно – в виде единого документа).
Когда при формировании списка выясняется, что предоставить достаточные ресурсы на проект невозможно – обращайтесь к спонсору. Правильно написанный устав уполномочил вас не только общаться с «хозяевами ресурсов», но распределил ответственность между вами и спонсором.
Все сотрудники, которые включены в список ресурсов автоматически войдут в состав команды проекта. Кто-то из них, возможно, уже поработал в составе команды (поучаствовав в сборе требований).

Включая сотрудника в список, прописывайте условия его привлечения настолько конкретно, насколько это возможно. Не забудьте указать:
Фамилию и имя сотрудника (избегайте указывать только должность)
Период и объем занятости (например, «доступен с 1 сентября по 31 декабря 2015 года, занятость – 50%» – если речь идет о привлечении сотрудника, который будет делить время между вашим и другим проектом).
Все, кто оказался в списке ресурсов, автоматически становятся членами команды проекта.
Пример перечня ресурсов также представлен в папке.
Выходы:
Решение «что покупаем».
Список ресурсов

Планируем время и стоимость с использованием специализированного ПО
Входы:
Концепция проекта
Матрица требований
Список ресурсов
Команда проекта (ключевые сотрудники по списку ресурсов)
Специализированный софт для управления проектом.
Конкретный программный продукт не имеет значения. В настоящий момент на рынке существует множество платных и бесплатных решений, самые распространенные из них: MS Project, Spider Project, Primavera, Prince.

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

Распределение ответственности
Помимо самих работ – следует обратить внимание на распределение ответственностей. Необходимо найти способ договориться с командой о распределении ответственностей такого рода.
Фиксируйте договоренности. Сделайте это для каждой области знаний или для каждой роли вашей команды.
Можно закрепить обязательства по областям знаний. Например, описав «главного» и «вспомогательного» ответственных за какую-то задачу. Для этого удобно использовать простейшие таблицы, которые иногда называют «матрицами ответственности».

Матрица ответственности

Планируем коммуникации
Этот аспект управления проектом, по некоторым данным, отнимает до 90% его рабочего времени. Правильно спланированные коммуникации помогут серьезно снизить собственные трудозатраты.
Наиболее существенные аспекты коммуникаций, которые всегда стоит оговаривать в любом проекте это:
Отчеты команды о выполненных работах
Методы коммуникаций с представителями заказчика и пользователями
Коммуникации со спонсором

Коммуникации
Плохой практикой является обсуждение статуса работ на совещаниях. Не нужно делать так (если только это не продиктовано методологией разработки или особой производственной необходимостью). Руководителю и команде и так есть, чем заняться. Лучше присылать информацию в электронном виде. Пусть каждый создает отчет тогда, когда ему это будет удобно, и изучать их тоже – когда это удобно.
Не заставляйте людей без нужды много писать. Отчет о результатах должен разумно соотноситься по трудоемкости с самим результатом. Подавляющее большинство технических специалистов не любят писать и сочинять документы. Для них это может использоваться как «наказание». Если нужна цифра (сколько тебе осталось для выполнения этого этапа?) – лучше попросить цифру и все. Если нужны комментарии – позвонить, или оставить их на усмотрение разработчика. Не все одинаково относятся к созданию даже коротких текстов.

Методы коммуникаций с заказчиком
Правила таких коммуникаций важны не только для «фиксации договоренностей», но и для соблюдения субординации.
Аналитику понадобилось съездить на объект и еще раз переговорить с пользователем – можно ли ехать сразу? Или позвонить пользователю и уточнить удобное время? Или обязательно каждый раз договариваться с его начальником? А что если возникли вопросы к самому заказчику (скажем, директору крупного завода)? Удобно ли ему позвонить на мобильник? Или через секретаря? Или послать вопрос почтой? Или по всем вопросам за заказчика решения принимает его заместитель, и директора лучше вовсе не беспокоить?
Нарушение гласных и негласных правил предприятия – в долгосрочной перспективе ни к чему хорошему вас не приведет. Необходимо определить «правила игры» на поле заказчика и донести их до всей команды. Это существенно снизит количество и уровень потенциальных конфликтов.

Коммуникации со спонсором
Главное, что интересует спонсора в ходе выполнения проекта – укладывается ли тот в треугольник сейчас и сохранится ли это по окончании проекта? Как правило, нюансы хода работ спонсора не очень волнуют. Оговорите со спонсором до фазы исполнения – как именно вы будете держать его в курсе
Выходы:
Дополнительные документы, описывающие ответственность (матрица ответственности / текстовые описания)
Договоренности об отчетах (устно или письменно)

Планируем и работаем с рисками
Входы:
Расписание
Оценки предельной цены проекта
Список ресурсов проекта
Управление рисками призвано экономить деньги и время проекта. В «лучших проектных практиках» на управление рисками делается особый акцент.
Работая с рисками, всерьез повышаются шансы проекта «удержаться в треугольнике». Кроме того, он получает возможность проиллюстрировать спонсору эффективность своей работы.

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

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

Работа с рисками
Шаг 2. Идентификация рисков
Кто выявляет риски?
Идентификация рисков отчасти схожа с процессом сбора требований. Необходимо приложить массу усилий, чтобы выявить и описать в формате таблицы все разнообразие «неопределенных» событий проекта.
Не стоит искать риски в одиночку и не ограничивайтесь помощью команды. Попробуйте привлечь спонсора, заказчика (если это допустимо), пользователей, приглашенных экспертов и т.д. Пусть каждый вносит свой вклад.

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

Реестр рисков
Информацию о рисках удобно хранить в формате таблицы. Назовем ее «реестр рисков». Один из возможных форматов документа представлен в папке.
Данная таблица мы заполняется в течение управления рисками (вплоть до закрытия проекта).
Сейчас, на втором шаге планирования интересуют только поля «описание риска» и «хозяин». Их необходимо заполнить для каждого выявленного рискового события.
Хозяин риска – персона, которой поручено обрабатывать риск (контролировать, какие меры предприняты, а в случае наступления риска – реагировать на него).
Хозяином риска может быть любой из членов команды, в редких случаях хозяином можно назначить кого-то из представителей заказчика.

Шаг 3. Качественный анализ
Риски собраны и внесены в реестр. Время приступить к их оценке и сортировке.
Качественный анализ – это субъективная оценка выявленных рисков. Необходимо определить – как сильно тот или иной риск угрожает проекту.
Один из самых широко распространенных способов – оценить каждый риск по двум параметрам «вероятность» и «влияние», задав для каждого значение из диапазона «высокое»/ «среднее» / «низкое».
По результатам качественного анализа можно разделить все риски на те, что требуют дальнейшего контроля и те, которыми можно пока пренебречь.
По завершении текущего шага также появится возможность оценить общий уровень рисков проекта в терминологии качественной оценки (проект высоко- / умеренно- / низко- рискованный). Такая оценка будет субъективной (вы сами можете определить, при каком количестве, например, «красных» уровней – будете считать свой проект «высоко-рисковым») , однако ее очень полезно зафиксировать на будущее. Запишите оценку отдельно – ее динамика в будущем будет, в том числе, и отражением качества вашей работы.

Шаг 4. Количественный анализ
Количественный анализ – это форма объективной оценки риска. Этому подвергаются только «значимые» риски, отобранные в ходе предыдущего шага.
Следует сразу оговориться – количественный анализ нужен не для всех рисков (а только для тех, уровень которых признаны значимыми).
Среди методов количественного анализа выделяют:
Сбор экспертных мнений
Анализ Монте-Карло
Оценку стоимости риска (оценивается как произведение количественной оценки вероятности риска на его влияние).
Остановимся подробнее на последнем методе.
Стоимость риска оценивается как произведение количественной оценки вероятности риска на его влияние. К такому методу прибегают, например, при сравнении между собой нескольких альтернативных сценариев, каждый из которых сопряжен с рисками.

Пример
Например, вы можете потратить 1500 долларов на лицензионный софт, и эту трату придется понести с вероятностью 100%. Или использовать «пиратское ПО» бесплатно, однако тогда с вероятностью 5% вас поймают и выпишут штраф на 100.000 долларов. Что предпочесть?
Сравниваем стоимость риска по каждому из сценариев:
Для сценария 1 = 1500 * 1 = 1500 долларов
Для сценария 2 = 100.000 * 0,05 = 5000 долларов.
Вывод – сценарий 1 выгоднее для проекта (т.к. его стоимость риска ниже).

Шаг 5. Планирование реагирования на риск
Определив самые значимые из выявленных на данный момент рисков, приступаем к построению планов. Наша задача – для каждого риска постараться найти ответы на два вопроса:
«Как изменить уровень риска на проекте (увеличить / уменьшить)?»
«Что делать, если мероприятия пункта 1 окажутся неэффективными, и риск все-таки произойдет?»
Содержимое пункта 1 будем называть «Планом А» (общепринятые названия – «план реагирования на непредвиденные ситуации»).
Содержимое пункта 2 назовем «Планом Б» (в методологиях он часто называется «планом отступления»).

Создаем «План А»
Главный элемент «Плана А» для каждого риска – это стратегия. Выделяют четыре вида стратегии для положительных и отрицательных рисков:

Стратегия «Нивелирование» / «Использование»
Стратегия «Нивелирование» / «Использование» устраняет корневую причину риска (или наоборот, гарантирует ее сохранение). Это самый лучший вид стратегии, если он приемлем по цене и прочим параметрам – стремитесь использовать именно его.
Пример для негативного риска: неопытный член команды может завалить работу. План А – заменить сотрудника на более опытного.
Пример для позитивного риска: закупаемое для проекта лицензионное ПО, может достаться нам со скидкой, если все закупки будут проведены до конца года. План А – провести закупки ПО до конца года.

Стратегия «Ослабление» / «Усиление»
Стратегия «Ослабление» / «Усиление» нацелена на изменение вероятности или влияния рисков.
Пример для негативного риска: неопытный член команды может завалить работу. План А – заранее провести тренинг для сотрудника.
Пример позитивного риска: закупаемое для проекта лицензионное ПО может достаться нам со скидкой, если все закупки будут проведены до конца года. План А – уведомить о возможных рисках заинтересованных и ответственных за закупки лиц.

Стратегия «Перенос» / «Разделение»
Стратегия «Перенос» / «Разделение» нацелена на то, чтобы либо переложить бремя риска на третью сторону (например, субподрядчика или страховую компанию); либо наоборот, поделиться возможностями с теми же субподрядчиками, если это принесет удачу проекту в целом.
Пример негативного риска: неопытный член команды может завалить работу. План А – нанять субподрядчиков для выполнения этих работ.
Пример позитивного риска: Результаты проекта будут знаковыми не только для нашей организации, но и для потенциальных поставщиков лицензионного ПО (они смогут гордиться, что именно на их платформах создана столь масштабная система). План А – провести переговоры с поставщиками (возможно, кто-то из них, заинтересовавшись, предложит нам льготные условия поставки или иную помощь)

Стратегия «Принятие»
Стратегия «Принятие» предполагает бездействие, «смирение» с обстоятельствами. Это наиболее пассивная из всех стратегий. Она может быть использована для неснижаемых рисков, предотвратить которые дороже, чем дождаться их наступления. Остерегайтесь применения такой стратегии, следите, чтобы такой тип реагирования применялся не более чем для 10% рисков на любом проекте, а по возможности – стремился к нулю.
Пример: неопытный член команды может быть уволен из организации за провал на другом проекте (при этом он покинет и ваш проект). План А – уточняем риски у «хозяина ресурсов» и бездействуем.
Зафиксируйте выбранную стратегию в реестре – опишите ее вид и действия «Плана А».

Создаем «План Б»
План Б будет использоваться если План А окажется недостаточно эффективен.
Для негативных рисков это будет означать, что первичные меры не помогли, и риск все же начал реализовываться, для положительных – что, не смотря на приложенные усилия, мы все же упускаем удачную возможность.
Заполняя данный раздел реестра, используйте эффективный прием: задавайтесь вопросом не «что делать, если…», а «что делать, когда риск произойдет».

Шаг 6. Изменяем планы и определяем резервы
Оба плана (в особенности «План А») в зависимости от выбранной стратегии – предполагают какие-то действия с нашей стороны.
Иногда, можно ограничиться внесением изменений в планы: корректировка расписания или состава работ сама по себе, порой, способна понизить уровень риска, скажем, с «красного» на «зеленый».
В других случаях потребуются определенные ресурсы – для найма сотрудников или проведения тренингов, для привлечения субподрядчиков и так далее. Для их обозначения обычно используется термин «резервы на непредвиденные случаи». Такие резервы являются неотъемлемым компонентом «предельной цены контракта».
Управление рисками в целом имеет единственной целью сэкономить время и деньги проекта. Пренебрежение управлением рисками с огромной вероятностью потребует затрат, превышающих все возможные резервы.
Выходы:
Реестр рисков
Запросы на изменения

Другие элементы плана
«План управления проектом» не ограничивается перечисленными выше элементами.
Все существенные моменты должны быть документированы, нельзя оставлять их только «в своей голове». Помните, план – средство коммуникаций вас с командой, членов команды друг с другом, вас со спонсором.
Планируйте все, что считаете значимым (определитесь, будут ли это устные или письменные договоренности).

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