Что и зачем вы делаете на проекте, или История одного провала
Я расскажу вам историю большого провала. История основана на реальных событиях — это наш проектный опыт.
Итак, все началось со звонка CIO довольно крупного ретейлера на мобильный телефон одному из руководителей проектов нашей компании. Монолог был непродолжительным и заключался в том, что необходимо внедрить продукт «Управление корпоративными финансами». Довольно распространенная история, и такой запрос у руководителя проектов не вызвал ни каких сомнений. Обращение было передано корпоративному продавцу, и вот уже вооруженный презентацией и в сопровождении РП он мчится на переговоры с предложением предпроектного обследования для внедрения «Управления корпоративными финансами».
Все участники процесса — люди профессиональные и без обследования в проект не идут, что полностью по науке. Предпроектное обследование продано! Команда начинает рисовать будущую архитектуру системы, планировать перенос данных и обучение, опытно-промышленную эксплуатацию (далее — ОПЭ) и продумывать все детали. Конечно, в рабочей группе ключевой бизнес-заказчик — CFO, и защитник — CIO. В ходе обследования принято совместное решение о смене программного продукта на «Управление производственным предприятием». Обследование закончено тоже по науке, и все документы сделаны как надо: и бюджет, и график, и отчет — все по уму. Цель проекта: внедрить описанный в отчете функционал на платформе «Управление производственным предприятием». Контракт на проект подписан, и работа кипит.
Позади пять месяцев совместного труда, освоена половина бюджета, закончено техническое задание и технический проект. Акты подписываются, деньги платятся. Ничто не предвещает беды, и нам уже кажется, что это рекламный рассказ о том, какие мы молодцы и как умеем делать проекты. Однако... куда же без «однако»! Однако в глубинах компании-заказчика зрел конфликт собственников и CIO, вылившийся в уход последнего. Проект потерял защитника. Не беда, ведь есть бизнес-заказчик. Приходит новый CIO, и работа с его участием становится не такой ритмичной. Он задает вопросы CFO о целесообразности проекта, и разгорается новый конфликт. В итоге уходит CFO — бизнес-заказчик проекта. Нам шах! Однако, нас голыми руками не возьмешь, мы профессионалы, у нас технология, контракт, документы, акты и все по науке... Исполняющая обязанности CFO очень толковая девушка продолжает активно работать в проекте, и процесс идет. Надежда жива. Заканчивается этап реализации функционала, и тестирование проходит успешно, надо подписывать акты и переходить в ОПЭ. Нам снова кажется, что это рассказ о классном проекте. Прекрасная девушка отправляет нас с актами к вышестоящему руководству. CIO нам больше не помощник — значит, к CEO/собственнику идти самим. В животе что-то сжалось, предвещая неладное. Доброжелательный и конструктивный собственник очень быстро переходит к делу: «Первое: кто вы? Второе: я вообще не представляю, что за проект вы делаете и для чего он нужен мне. Я управляю компанией, используя вот эту таблицу Excel (он указал на экран своего ноутбука), которую мне обновляют ежедневно, и меня это полностью устраивает. Платить за вашу работу я больше не намерен, хотя уже уплаченные деньги назад требовать не буду». Нам мат! Финал истории я расскажу чуть позже.
Сейчас самое время раскрыть тему, которую я хотел освятить в этой статье: «Цели и ценность проекта для первого лица (далее — ПЛ) компании-заказчика». Целью проекта никогда не может быть: внедрить продукт, реализовать функционал, создать ландшафт и т. д. и т. п. Целью обязательно должно быть решение ценной для бизнеса задачи. Эту ценность обязательно должно разделять ПЛ заказчика. Представим, что можно вернуться в начало нашего проекта. Как можно было бы сделать этот проект почти без проблем? Очень просто. В процессе проведения предпроектного обследования надо было организовать интервью с ПЛ заказчика и с ним же проводить презентацию отчета о предпроектном обследовании. В этом случае ценность создаваемой и внедряемой системы разделял бы собственник. Скорее всего, проект был бы другой, но ценный для ПЛ. Уход руководителей из команды заказчика все равно не прошел бы без проблем, однако достаточно высокий уровень операционного менеджмента проекта позволил бы решить эти проблемы.
Итак, первый вывод: выявление и фиксация целей и контакт с ПЛ заказчика. Что это может быть? Задачи/проблемы бизнеса. Что-то наболевшее, мешающее развиваться, зарабатывать деньги, не позволяющее экономить деньги.
Решая эту задачу, часто приходится сталкиваться со стереотипом: «большой босс» точно в 1С работать не будет! И да и нет. ПЛ не должно работать там, где ему неудобно. Функционал должен быть нужный, удобный именно ПЛ. Мы — профессионалы, и не надо забывать об этом, общаясь с ПЛ. Предлагайте именно управленческий функционал: системы поддержки принятия решений, мониторы результативности, панели, графики, диаграммы, таблицы, светофоры, веб-интерфейс с феерическим дизайном, мобильные приложения для отображения нужной ПЛ информации. Ломайте стереотипы. Работа ПЛ с данными непосредственно из ИС в разы повышает значимость ИС для компании и, как следствие, качество данных в ИС.
А теперь вернемся к началу нашей истории, мы договорились с собственником, что информационная система будет позволять формировать для него полностью достоверный монитор с необходимой и удобной для него информацией. Бинго, проект успешный и все хорошо. Не тут-то было. Через пять месяцев работы над проектом ПЛ уже не помнит ни о вас, ни тем более о том, какой функционал и интерфейс он получит еще спустя пять месяцев. Более того, за 10 месяцев проекта в компании заказчика, на рынке и в голове ПЛ все поменяется, и это нормально. При этом есть ТЗ, ТП, проектные комитеты и много других правильных документов и процедур. С каждым месяцем мы все больше рискуем попасть в ситуацию «Кто вы, что и зачем вы делаете?». Что же делать?
1. Минимизация периода подготовки первого релиза для ПЛ.
2. Регулярное информирование ПЛ о ходе работ и промежуточных результатах. Например, на управляющих советах проекта.
3. Оперативное управление изменениями в проекте.
Ну и кульминация. Какие задачи нужно решать в отношении ПЛ заказчика:
1. Формирование у ПЛ уверенности в том, что для нас является ключевой задачей — ценность создаваемого продукта для ПЛ и компании-заказчика на любом этапе проекта.
2. Оценка удовлетворенности ПЛ результатами сотрудничества. Готов ли он рекомендовать сотрудничество с нами своим партнерам и знакомым?
Чем закончилась наша история? Одним из принципов проектного офиса в Санкт-Петербурге является 100%-ный запуск проектов в промышленную эксплуатацию. Это сложно, но возможно, расскажу об этом в отдельной истории. Получив доступ к ПЛ заказчика, мы выяснили, что в проекте все-таки есть ценность и для него. Это оперативный обмен данными с розничными точками и специализированной складской системой. «Оседлав» эту ценность, мы смогли согласовать запуск проекта в эксплуатацию. Мы передали систему в ОПЭ без актов и оплаты. Через несколько месяцев работы ИС нам заплатили часть денег и подписали часть актов. Мы потеряли порядка 20% бюджета, но приобрели бесценный опыт, которым я с удовольствием делюсь с вами.
Опубликовано 05.02.2018