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