При запуске проекта как-то неприятно думать о том, что что-то может пойти не так и что мы можем немного не успеть со сроками.
Однако, подсчет стоимости одного дня задержки уже на этапе запуска проекта позволяет проще маневрировать в ситуациях, когда требуется перебрасывание ресурсов между командами, а что еще интереснее - определять, какие 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 “Нет ветра? Садись на весла!” про проекты, продукты и маркетинг.