Разбор ситуации(кейса) 5 для ПМа. Коммуникация о проблемах на проекте
Продолжая разбор кейсов для ПМа. Пятый кейс будет про то, как сообщать клиенту о проблемах на проекте.
Вот ссылка на предыдущие разборы кейсов
- Разбор кейса 1. Начало проекта.
- Разбор кейса 2. Риски.
- Разбор кейса 3. Оценка даты завершения и размера команды.
- Разбор кейса 4. Коммерческое предложение (Proposal)
Условие кейса
В процессе выполнения проекта, ваша команда говорит вам, что техническое или архитектурное решение, которое они планировали использовать в проекте — не сработает. Хотели сделать быстро, просто и дешево, но не сработало. В итоге внедрение нового решения приведет к увеличению длительности проекта на 5% (пускай это будет 1 месяц, например) и стоимости проекта на 10% (надо привлекать дополнительных специалистов).
Как вы будете сообщать об этой ситуации клиенту и что будете предлагать?
Рассмотрите отдельно несколько вариантов контекста:
1) вы внесли эту возможность в реестр рисков, клиент знал о вероятности того, что это может произойти и у вас есть план действия в случае этого риска
2) команда не предупредила вас об этом риске (из-за недостатка опыта вообще или в данной технологии, например) и в итоге это событие стало сюрпризом как для вас, как менеджера, так и для клиента.
Решение
Прежде чем перейти к вариантам решения кейса, давайте обсудим, какие бывают варианты реагирования на подобные случаи.
Когда проект начинает отклоняться от базового плана, необходимо предпринять корректирующие действия для того, чтобы вернуться на прежнюю траекторию. В английской литературе указывают 2 основных способа, без изменения сроков и обьема работ — Crashing и Fast-tracking. Ниже указаны все действия и к какой из терминов они описывают. Если проект начинает опаздывать по срокам, то мы можем:
- добавить больше ресурсов (разработчиков) на те этапы проекта, которые можно распараллелить, чтобы выполнить эти этапы быстрее. Сильно зависит от наличия ресурсов и наличия буфера бюджета на это. (crashing)
- изменить дату старта некоторых работ. Например мы можем начать разработку раньше, не дожидаясь пока дизайн будет закончен полностью. Это несет риск того, что позже нам придется что-то переделать из-за того, что дизайн изменился. (fast-tracking)
- перенести срок сдачи проекта.
- уменьшить обьем работ, то есть просто исключить какой то функционал из списка работ или изменить содержание какого то пакета работ на другой, более короткий.
Какой из способов стоит применить в каждом конкретном случае решается исходя из условий проекта. Например, насколько гибкая наша дата, есть ли у нас дополнительные ресурсы, есть ли запас по бюджету или можно ли получить дополнительный бюджет, что более приоритетно для клиента — сроки или бюджет, был ли у вас реестр рисков с планом реагирования или нет, и так далее.
Корректирующие действия будут отличаться исходя из типа отклонения от плана — разовое или систематическое.
В первом случае чаще всего ничего корректировать не надо, необходимо проанализировать причину и постараться исключить возникновение подобных отклонений в дальнейшем. Например, разработчик слег на несколько дней с температурой.
Во втором случае необходимо скорректировать план, согласно ситуации. Например, разработчик делает всегда медленнее, чем оценено — скорректируйте оценку исходя из производительности этого разработчика.
Другой пример — клиент постоянно вносит изменения в проект, которые отвлекают разработчиков, увеличивают тех долг, ведут к переделкам, удорожанию проекта и сдвигу сроков.Скорректируйте соответствующие параметры проекта, на которые влияет такое поведение заказчика и введите понятную процедур внесения изменений и давайте понятную обратную связь клиенту о влиянии подобных изменений на проект.
Алгоритм изменения плана в общем виде такой:
- предложение по изменению четко сформулировано, в письменном виде ИЛИ вам известно, какое систематическое действие влияет на план проекта
- оцените влияние этого изменения или действия на план проекта. Например: бюджет увеличится на Х, сроки проекта сдвинутся на Y дней и так далее
- доведите эту информацию до спонсоров проекта и утвердите с ними изменения в план
- если утвердили, то сообщите об изменении всем, кого это касается, объясните, чем обоснованно изменение
- перед внесением изменений, составьте план, как эти изменения будут реализованы в текущей работе над проектом
- внесите изменения в необходимые документы, такие как график работ, календарный план, спецификации и так далее
Отдельно хотелось бы упомянуть такой частный случай как неконтролируемое расширение объема работ проекта (Scope creep). В этом случае большой объем и частота вносимых извне изменений в изначальные условия проекта ставит под угрозу весь проект или превращает его в бесконечный.
Пример письма
Возвращаясь к условиям нашего кейса, я приведу пример одного из вариантов письма клиенту по каждому из 2х вариантов, но это не единственно возможный вариант реагирования, как видно из описания выше. Вариант конкретно вашего проекте будет зависеть от условий вашего проекта и коммуникаций с клиентом. Тем не менее, примеры позволят вам понять общую структуру ответа, которой стоит придерживаться.
1.
В первом варианте контекста из условий кейса вы — большой молодец и разделили ответственность за риск с клиентом ещё в начале проекта. У клиента теперь нет возможности попробовать каким то образом взыскать полностью все возможно убытки с вашей компании.
Ваши действия в этом контексте достаточно просты — информировать клиента сразу при наступлении события риска и одновременно с этим предоставить план дальнейших действий по уменьшению последствий этого события на дальнейший ход проекта. Клиенту надо предоставить достаточно информации для аргументированного решения продолжать или нет дальше проект, исходя из бизнес преимуществ/результатов проекта относительно инвестиций в его реализацию.
В редких случаях дальнейшая реализация проекта не будет иметь смысла. Например, технология, на основе которой строился проект — имеет неявные недостатки: вы писали приложение для синхронизации данных между телефоном и умными часами для плавания, но оказалось, что технология с низким потреблением батареи — BLE (Bluetooth Low Energy), имеет ограничения по размеру передаваемых пакетов, которые приводят к тому, что одна синхронизация после плавания может занимать до часа, поскольку данных за одну сессию собирается достаточно много. Таким образом приложение теряет большое количество своей ценности для пользователя и компания заказчик может принять решение остановить на данный момент дальнейшую разработку такого приложения.
Письмо клиенту из кейса в первом случае будет выглядеть примерно так:
Hello John,
During our work on the task related to the feature X we have found that our chosen technical solution to implement this would not be effective as expected.Our estimate for this task had increased substantially as a result.
We had a risk of this happening listed in our Risk registry and so we are ready to proceed with pre-defined plan of actions as discussed with you. The plan in the registry was to develop our own component instead of originally planned 3rd party component. This would result in estimated 10% budget increase and would cause our scheduled release date to shift for one month forward.
As an alternative we can spend 1-2 days researching for the alternative 3rd party components that can be used. This can potentially lower the impact but we would again have the same risk related to the 3rd party components
Please let me know if we should proceed with this plan or if you would like to suggest any changes or different course of actions. We can have a call with the team at your earliest convenience to discuss details.
Regards,
Подчеркну важные моменты, которые обязательно указать:
- опишите что случилось
- в чем это выражается
- какие последствия для проекта
- план дальнейших действий
- по возможности альтернативы, но не более одной-двух
- обязательно предложите обсудить это голосом. Это важно потому что это стресс для клиента и вам нужно будет снижать уровень его тревоги. У него может появиться много дополнительных вопросов, которые будут относиться в первую очередь к тому, что для него приоритетнее всего: сроки, бюджет, возросшие риски проекта, тревога что всё пропало и так далее.
Отдельным письмом поставьте в известность ваше руководство. Не пытайтесь спрятать этот факт, надеясь его быстро “разрулить”. Это приводит к неприятным ситуациям, когда клиент эскалирует ситуацию вашему руководству, а оно не в курсе происходящего. В итоге непрофессионально выглядит не только ПМ, но и вся компания в целом, повышая градус возмущения клиента, часто до точки кипения. Накопление именно таких ситуаций часто приводит к разрыву отношений с заказчиком.
2.
Во втором варианте из условий кейса, когда такое событие не внесено в реестр рисков, ответственность лежит целиком и полностью на команде проекта и ПМе, как ответственном за проект в целом. Общий план коммуникации остается похожим с первым вариантом. Однако, вы в менее выгодной ситуации и вам придется дополнительно посыпать голову пеплом и указывать не только план действий по этой ситуации, но и план действий для того, чтобы подобные ситуации не повторялись в будущем. Например, какие дополнительные проверки или чеклисты вы можете добавить, экспертизу каких более опытных людей в компании можете привлечь, чтобы улучшить качество технических решений и снизить беспокойство клиента о технической компетенции вашей команды.
Письмо клиенту в этом случае будет выглядеть так:
Hello John,
During our work on the task related to the feature X we have found that our chosen technical solution to implement this would not be effective as expected. Our estimate for this task had increased substantially as a result.
Our plan to resolve this is to develop our own component instead of originally planned 3rd party component. This would result in estimated 10% budget increase and would cause our scheduled release date to shift for one month forward.
As an alternative we can spend 1-2 days researching for the alternative 3rd party components that can be used. This can potentially lower new estimate for this feature.
We would involve additional senior technical expert to do an additional review of the technical architecture.
Please let me know if we should proceed with this plan or if you would like to suggest any changes or different course of actions. We can have a call with the team at your earliest convenience to discuss details.
Regards,
