УПРАВЛЕНИЕ ОЖИДАНИЯМИ ЗАКАЗЧИКА – НЕОБХОДИМОЕ УСЛОВИЕ УСПЕШНОСТИ ПРОЕКТА
Ряд стандартов по управлению проектами выделяют процессы организации взаимодействия с заинтересованными сторонами (стейкхолдерами) в качестве отдельной группы, тем самым подчеркивая их важность. В описании таких процессов уделяется отдельное внимание управлению ожиданиями заказчика – как бы странно это не звучало, ожидания могут разительно отличаться от того, что написано в ТЗ (особенно когда дело касается интеллектуальных услуг).
Как успешно реализовать крупный проект, учитывая ожидания заказчика читайте в статье директора Практики PM Excellence Александра Кочетова PMP, РМЕ далее:
"Работая несколько лет назад на проекте по развитию корпоративной системы управления, я получил хороший урок того, что на всем протяжении проекта необходимо управлять ожиданиями заказчика.
Перед началом работы наша команда тщательно изучила техническое задание, сформированное заказчиком, выдала к нему свои комментарии (большая часть которых была согласована), максимально детализировала ТЗ и осуществила детальное планирование проекта, пытаясь исключить возможности всевозможных неправильных толкований. В ходе реализации были выстроены все основные процессы управления проектом. В частности, в рамках управления коммуникациями регулярно проводились совещания с куратором со стороны заказчика с целью подтвердить корректность выполнения пунктов ТЗ.
За 3 месяца до окончания сроков проекта, руководитель проекта со стороны исполнителя стал ходить на прием к генеральному директору заказчика для демонстрации промежуточных результатов. Директор выделял на такие приемы не более 15 минут и, выслушав краткий доклад, каждый раз говорил что-то вроде: «Я понял. У нас же все идет по плану, так? Ну и отлично». Мы (как команда исполнителя) были довольны, что у генерального директора нет замечаний.
Однако, во время сдачи финального результата генеральный директор стал задавать вопросы, из которых стало понятно, что он видел результат не таким, каким мы его представили. И я, как куратор услуги со стороны исполнителя, не нашел ничего умнее, чем достать детальное техническое задание и календарно-сетевую модель со словами: «Мы сделали все в соответствии с изначальными договоренностями, которые Вы также подписали».
После этих моих слов генеральный директор дал поручение своим подчиненным убедиться, что пункты ТЗ действительно выполнены, а затем заявил, что подтверждает нам оплату выполненных работ, но иметь дело с нашей компанией он больше не хочет. Да, мы получили оплату за работу в полном объеме, но с данным клиентом больше не работали.
Поначалу наша команда чувствовала за собой стопроцентную правоту – ведь мы действительно успешно реализовали процессы управления данным проектом, добуквенно выполнили ТЗ, не получали до последнего момента никаких критичных замечаний. Однако, впоследствии, проанализировав произошедшее с холодной головой, мы пришли к выводу, что не до конца доработали очень важный процесс управления проектом – управление заинтересованными сторонами.
Ряд стандартов по управлению проектами выделяют процессы организации взаимодействия с заинтересованными сторонами (стейкхолдерами) в качестве отдельной группы, тем самым подчеркивая их важность. В описании таких процессов уделяется отдельное внимание управлению ожиданиями заказчика – как бы странно это не звучало, ожидания могут разительно отличаться от того, что написано в ТЗ (особенно когда дело касается интеллектуальных услуг).
Что же мы сделали не так в ходе реализации вышеописанного проекта?
- Во-первых, мы явно недостаточно вовлекали генерального директора в ход работы по проекту. Понятно, что он очень занят, и времени у него на нас было бы немного. Но тем не менее, необходимо было с получения первых промежуточных результатов демонстрировать ему их, объяснять полезность и считывать обратную связь. Идеальная ситуация – формальное согласование промежуточных результатов после их демонстрации.
- Во-вторых, в ходе общения с генеральным директором мы не уточняли пожелания и ожидания от будущих результатов. Даже в случае отличия этих ожиданий от формального ТЗ, можно было бы заранее сманеврировать и поуправлять рисками финального недовольства. Также возможно команда могла бы заранее заменить часть работ и результатов другими – ожидаемыми – и переподписать ТЗ. Впоследствии можно было бы скорректировать некоторые процессы управления проектом под новую реальность.
- В-третьих, даже если б в финале остались бы вопросы, нужно было не ссылаться на подписанный документ, сразу переводя разговор в формальную плоскость, а уточнить появившиеся вопросы и проанализировать возможность реализации. Часто выгоды от реализованных пожеланий заказчика превышают затраты на их выполнение.
В случае реализации вышеописанных шагов и уделению нами большего внимания процессу управления ключевыми стейкхолдерами, нашей команде удалось бы более качественно управлять ожиданиями заказчика (и учитывать их), а также повысить вероятность продолжения работы с данным клиентом.
Приведенный пример демонстрирует, что фиксация исключительно на «треугольнике проектных ограничений» (сроки, бюджет, качество) не является стопроцентной гарантией успеха. Необходимо уделять внимание большинству процессов управления проектом – особенно связанным с ключевыми заинтересованными сторонами."