Каталог решений - Подсчет цены факапа на этапе запуска проекта

При запуске проекта как-то неприятно думать о том, что что-то может пойти не так и что мы можем немного не успеть со сроками.

Однако, подсчет стоимости одного дня задержки уже на этапе запуска проекта позволяет проще маневрировать в ситуациях, когда требуется перебрасывание ресурсов между командами, а что еще интереснее — определять, какие in-house проекты стоит брать в работу в первую очередь.

Но все по порядку, и начнем с вопроса…

Зачем на этапе запуска проекта считать стоимость дня задержки?

Существует 2 основных кейса, когда информация о стоимости дня задержки важна.

Случай #1

Если один проект, выполняемый для внешнего Заказчика по fix price, начинает подгорать, и нам нужно быстро сориентироваться по тому, с какого проекта можно перекинуть ресурсы и стоит ли вообще это делать, то оперативный доступ к информации по цене задержки для рассматриваемых проектов позволяет проще принимать решение о переприоритезации работ.

Целесообразность

Интуитивно хочется сказать, что лучше всегда на этапе запуска рассчитать стоимость 1-го дня задержки и записать полученную сумму в легко доступном документе, например, в уставе проекта.

Почему так?

Потому что, когда проект в огне очень важно получить доступ к этой информации как можно быстрее, не поднимая условия договора, не перечитывая раздел пенни и т.д.

Также понимание стоимости 1го дня задержки руководителем проектов не в % от стоимости контракта, а именно в номинальном значении — это очень ценный мотивирующий параметр, который привлекает дополнительное внимание к отработке рисков.

Из практики руководства отделом внедрения с портфелем проектов из 30-40 штук я бы сказала, что целесообразность фиксирования стоимости дня задержки наступает, если:
📌 проектов больше 5 (потому что в памяти уже сложнее удержать эти данные, и лучше их записать),
или
📌 руководителей проектов больше двух человек (появляются вопросы приоритезации между двумя ответственными людьми).

Случай #2

Нам предстоить выбирать между разными возможностями и принять решение, какой проект стартовать раньше.

Целесообразность

Этот случай скорее относится к проектам, где нет внешнего заказчика с контрактом, а работы выполняются либо для внутреннего заказчика, либо как часть деятельности, связанной с продуктовым развитием.

Очевидно, целесообразность расчета стоимости дня задержки появляется в условиях:
📌 нехватки ресурсов для выполнения in-house проектов,
📌 интенсивном поступлении запросов на работы от смежных подразделений.

В чем разница между 2мя случаями?

В отличие от выполнения работ по контракту с fix price для внешнего заказчика стоимость задержки in-house проектов может сильно изменять свои значения с течением времени.

Приведу пример: предположим у нас имеется некий технический долг. До поры до времени он не сильно нам мешает жить, но с какого-то момента начинает блокировать дальнейшее развитие продукта. И мы наблюдаем резкое увеличение стоимости 1 дня в отсутствии нужного нам результата, а именно завершенного проекта.

Если мы представим, как изменяется стоимость дня задержки такого проекта, то мы будем иметь следующий график 👉

Выводы?
В ряде случаев (как правило, для in-house проектов) нам важно понимать, как стоимость задержки меняется с течением времени. И в этой истории очень помогает возможность соотнесения поведения цены задержки с одним из паттернов, которые мы можем позаимствовать из Kanban-метода.

Паттерны стоимости задержки

Итак.. Мы подобрались к 4 паттернам стоимости задержки. Их проще осознать, глядя на графики.

По оси Y у нас стоимость 1 дня задержки, по оси X — время.

📌 Expedite. Все плохо, уже теряем деньги. Дольше решаем — больше наших затрат становится. Пример проявления такого паттерна: когда у заказчика произошел останов работы системы, а у нас очень жесткие условия оказания технической поддержки.

📌 Fixed date. Затраты стартуют с какого-то события. Пример: не сдали проект вовремя, включается счетчик по пенни (удерживается часть стоимости работ за каждый день просрочки).

📌 Regular. Чем дольше ждем, тем дороже начинает нам обходиться каждый новый день, пока он не выходит на плато. Пример: проект по запуску новой фичи/продукта.

📌 Intangible. Можно очень долго и при этом безболезненно не делать, пока стоимость неделания не начнет резко расти. Классический пример: долго не делали документацию к продукту, и тут пришел клиент, который купит систему, но только с документацией.

Какой паттерн чаще всего встречается

Все зависит от специфики работы. По проектам с внешним заказчиком мне, конечно, ближе Fixed date. Expedite случались, но крайне редко. Были связаны с  появлением рекламаций от Клиентов.

У коллег, вовлеченных в продуктовую деятельность основные работы — это Regular. Expedite встречаются гораздо реже, при их возникновении все силы кидаются на разрешение этих проблем. Для Intangible выделяют регулярно время, потому что — если не выделять, то времени никогда на такие задачи не найдется.

Как можно использовать паттерны?

В общем и целом, паттерны хорошо применять при оценке целесообразности запуска новых проектов. Это отправная точка в понимании, насколько новый проект важен в горизонте планирования больше 2 недель :))
Кроме шуток, если говорить о практическом применении, то для руководителей отделов, которые отвечают за проекты, паттерны помогают выстроить правильный диалог с заказчиками из смежных подразделений. Не важно это — отдел с sales-менеджерами, или отдел тех. поддержки, или производства.

Уточнение, как может изменяться стоимость задержки в отсутствии результата по проекту, позволяет выявить ключевые события, которые существенно влияют на стоимость каждого дня.

Паттерны также защищают от ошибок, связанных с регулярным переносом Intangible-проектов. Как только применяется эта классификация, осознаются риски связанные с этими проектами, и как правило, сразу же появляются правила по бронированию времени на их реализацию.

Вот так-то. Считать стоимость проектного провала — это и полезно, и вполне увлекательно.

А как приоритезируете проекты вы?

Об авторе
Кузнецова Юлиана — product marketing manager в компании Selectel, в прошлом — руководитель отдела внедрений Центра речевых технологий. Проектная деятельность: проекты B2B, B2G длительностью от 1,5 месяцев до 2 лет.
Ведет канал в telegram “Нет ветра? Садись на весла!” про проекты, продукты и маркетинг.