Подсчет цены факапа на этапе запуска проекта

16.06.21

Управление проектом

Поговорим о ценности каждого дня ;) а точнее о существующих паттернах оценки для 1 дня задержки, которые могут быть заимствованы из Kanban-метода. И о том, как их применение может упростить проектное управление.

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

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

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3050    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4149    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3462    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3345    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15092    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6190    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

Предыдущие мои статьи на тему управления проектами носили концептуальный характер – ради чего мы делаем проекты, почему мы не получаем поддержку от коллектива пользователей, где найти помощь и мотивацию, как победить сложного заказчика. Теперь от концепций перейдем к технологии. Первая часть будет посвящена вопросам декомпозиции проектных задач на подзадачи для выявления узких мест нашего проекта.

10.02.2023    5265    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5823    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. triviumfan 95 21.06.21 09:39 Сейчас в теме
Подсчет цены ... чего, простите?:)
3. Juliana_K 3 26.07.21 14:18 Сейчас в теме
(1) Можно было сформулировать, как "цены незавершения проекта в срок", но хотелось побольше драматизма :))) Прошу простить и понять :))
2. Olenevod 33 04.07.21 08:21 Сейчас в теме
Всякие РП и продакт менеджеры, видимо, не читают статьи инфостарта (судя по тому, что нет комментариев в теме и оценок).
Ну а так вообще интересно почитать. В особенности потому что был такой проект - в огне который.
А ссылка на телеграм канал где?
4. Juliana_K 3 26.07.21 14:25 Сейчас в теме
(2) Была в отпуске, не сразу заметила сообщение :))

Ссылка на телеграмм канал вот = https://t.me/NoWind_GetOnTheOars

Если что-то будет интересно, по чему стоило бы подготовить статью на инфостарте - говорите ;)
Оставьте свое сообщение