Управление ИТ-проектом "с нуля" в любой организации

Дело 4. Управлять ожиданиями заказчика
Управление ожиданиями – процесс, который длится весь проект, однако основной главный его эффект
проявляется в фазе закрытия (которой будет посвящена следующая глава).
Конечным результатом деятельности команды проекта (под вашим руководством) должна быть
успешная сдача продукта.
Идеальная картина может выглядеть следующим образом – заказчик подтверждает, что продукт
удовлетворяет всем заявленным требованиям; дружественно настроенные пользователи признают
продукт годным к эксплуатации и у вас на глазах начинают работу с ним.
Реальность, обычно, оказывается принципиально иной. Во время «приемки работ» к продукту
предъявляется внушительный список претензий (устранение которых требует много времени и
ресурсов), сама сдача растягивается на месяцы или годы. Некоторые пользователи настроены
враждебно, они официально или скрыто саботируют внедрение продукта. Доработанный
совместными усилиями продукт остается невнедренным, в организации о нем со временем забывают,
а ваша компания, с трудом закрыв проект, окончательно теряет в лице заказчика будущего клиента.
Причин, почему реальная картина, как правило, так редко похожа на «идеальную» - множество. Но
одна из наиболее вероятных – неправильная работа с требованиями.
Представляйте процесс «сдачи продукта» с самого первого дня. Используйте тот же прием, что и в
управлении рисками – спрашивайте себя «что будет, КОГДА придется сдавать проект».
Если вы использовали рекомендации данной книги и до запуска проекта сформировали качественный
устав, а после – хорошую концепцию, то ваши обязательства перед спонсором (а косвенно – и перед
заказчиком и пользователями) оказались достаточно четко зафиксированы.
Однако ожидания клиента имеют склонность меняться в ходе проекта. Люди забывают, о чем вы с
ними договорились. Они продолжают размышлять на тему проекта – и у них рождаются новые идеи.
Пользователи продукта – вообще отдельная категория. Вы работаете ради них, без их поддержки
продукт не станет полезным (а проект – успешным). Селиховкин Иван (www.pmlead.ru) 66
Работайте с заинтересованными лицами весь проект. Выявляйте их ожидания и требования.
Обрабатывайте и давайте обратную связь (см. дело 3 в настоящей главе). Требования пользователей
могут противоречить друг другу, уставу, требованиям заказчика – учитывайте это. Собирайте
заинтересованных лиц вместе – стремитесь найти компромиссный подход.
Работая с ожиданиями в ходе проекта, вы готовите себе почву для его сдачи. Явившись же на приемку
с контрактом к пользователям, с которыми ранее не смогли даже познакомиться – роете себе яму.

Шаг 5. Планирование реагирования на риск
Определив самые значимые из выявленных на данный момент рисков, мы приступаем к построению
планов. Наша задача – для каждого риска постараться найти ответы на два вопроса:
1. «Как изменить уровень риска на проекте (увеличить / уменьшить)?»
2. «Что делать, если мероприятия пункта 1 окажутся неэффективными, и риск все-таки
произойдет?» Селиховкин Иван (www.pmlead.ru) 55
Содержимое пункта 1 будем называть «Планом А» (общепринятые названия – «план реагирования на
непредвиденные ситуации» или contingency plan).
Содержимое пункта 2 назовем «Планом Б» (в методологиях он часто называется «планом
отступления» или fallback plan).
Создаем «План А» (contingency plan)
Главный элемент «Плана А» для каждого риска – это стратегия. Выделяют четыре вида стратегии для
положительных и отрицательных рисков:
Отрицательный риск Положительный риск
Нивелирование Использование
Ослабление Усиление
Перенос Разделение
Принятие
Стратегия «Нивелирование» / «Использование» устраняет корневую причину риска (или наоборот,
гарантирует ее сохранение). Это самый лучший вид стратегии, если он приемлем по цене и прочим
параметрам – стремитесь использовать именно его.
Пример для негативного риска: неопытный член команды может завалить работу. План А –
заменить сотрудника на более опытного.
Пример для позитивного риска: закупаемое для проекта лицензионное ПО, может достаться нам
со скидкой, если все закупки будут проведены до конца года. План А – провести закупки ПО до конца
года.
Стратегия «Ослабление» / «Усиление» нацелена на изменение вероятности или влияния рисков.
Пример для негативного риска: неопытный член команды может завалить работу. План А –
заранее провести тренинг для сотрудника.
Пример позитивного риска: закупаемое для проекта лицензионное ПО может достаться нам со
скидкой, если все закупки будут проведены до конца года. План А – уведомить о возможных рисках
заинтересованных и ответственных за закупки лиц.
Стратегия «Перенос» / «Разделение» нацелена на то, чтобы либо переложить бремя риска на третью
сторону (например, субподрядчика или страховую компанию); либо наоборот, поделиться
возможностями с теми же субподрядчиками, если это принесет удачу проекту в целом.
Пример негативного риска: неопытный член команды может завалить работу. План А – нанять
субподрядчиков для выполнения этих работ.
Пример позитивного риска: Результаты проекта будут знаковыми не только для нашей
организации, но и для потенциальных поставщиков лицензионного ПО (они смогут гордиться, что
именно на их платформах создана столь масштабная система). План А – провести переговоры с Селиховкин Иван (www.pmlead.ru) 56
поставщиками (возможно, кто-то из них, заинтересовавшись, предложит нам льготные условия
поставки или иную помощь)
Стратегия «Принятие» предполагает бездействие, «смирение» с обстоятельствами. Это наиболее
пассивная из всех стратегий. Она может быть использована для неснижаемых рисков, предотвратить
которые дороже, чем дождаться их наступления. Остерегайтесь применения такой стратегии, следите,
чтобы такой тип реагирования применялся не более чем для 10% рисков на любом проекте, а по
возможности – стремился к нулю.
Пример: неопытный член команды может быть уволен из организации за провал на другом
проекте (при этом он покинет и ваш проект). План А – уточняем риски у «хозяина ресурсов» и
бездействуем.
Зафиксируйте выбранную стратегию в реестре – опишите ее вид и действия «Плана А». Определение
вида стратегии очень важно для самоконтроля. Классифицируя намеченный «план действий» -
проверьте себя. Зная, что наилучшим сценарием будет нивелирование / использование риска, а
худшим – принятие, убедитесь, что выбран был действительно наилучший способ реагирования из
доступных.
Помимо стратегии, важнейшая задача данного шага – определить «хозяина риска», если таковой не
был назначен в ходе идентификации (шаг 2). По умолчанию, хозяином всех рисков является ПМ –
избегайте такой ситуации.
Общее правило – хозяином становится тот, кто находится «на передовой» (т.к. именно он будет
проверять, что определенные действия в рамках Плана А выполнены).
В работе «хозяина» крайне важны правильно определенные «триггеры риска».
Триггеры риска – признаки, по которым «хозяин риска» поймет, что превентивные действия не
сработали и пора «отступать» (использовать План Б). Это еще один резон не становиться хозяином
всех рисков – пусть хозяином будет тот, кто первым заметит триггер.
Создаем «План Б» (fallback plan)
План Б будет использоваться «хозяевами рисков», если План А окажется недостаточно эффективен.
Для негативных рисков это будет означать, что превентивные меры не помогли, и риск все же начал
реализовываться, для положительных - что, не смотря на приложенные усилия, мы все же упускаем
удачную возможность.
Заполняя данный раздел реестра, используйте эффективный прием: задавайтесь вопросом не «что
делать, если…», а «что делать, КОГДА риск произойдет». Таким образом, можно сделать
гипотетическую картинку на много ярче и реалистичнее.

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