Как не надо бюджетировать проекты?

PDCA (plan, do, check, act) – методология принятия решений, которую я регулярно использовала при управлении проектами. К ней же я обратилась в одном из своих кейсов, где бюджетирование человеческих ресурсов стало главным источником зла.

На этот проект я пришла где-то посередине. С чем я столкнулась.

PLAN (понять актуальную ситуацию) – Компания все время задерживала сдачу функционала как по графику из контракта, так и в рамках договоренностей с заказчиком; – Чтобы загладить свою вину перед заказчиком, компания брала дополнительные задачи за рамками контракта; – Несмотря на то, что по договору выполнили лишь 1/3, бюджет бы потрачен уже примерно на 2/3; – Заказчик всегда недоволен; – Команда демотивирована.

PLAN (определить проблему и ее источник) – Срок выполнения задачи предполагался из оценок специалистов. При этом не учитывались часы сотрудников на созвоны с командой для синхронизации по задачам, обсуждения реализации задач. Да и просто перерывы на кофе; – Не учитывались также и риски, что с уточнением требований могут увеличиться затраты; – Для минимизации недовольства заказчика из-за регулярного сдвига сроков, брали много дополнительных задач. Из-за этого увеличивался бюджет, сроки растягивались еще больше, качество реализации падало, были постоянные переработки, задачи переделывались, снова увеличивались сроки и бюджет. Следовательно недовольство заказчика нарастало снежным комом.

Можно было и дальше ходить кругами, но как сказал один из моих экс-руководителей: «Ирина у нас эксперт по проектам из категории “Миссия невыполнима”». Так и действовала.

DO (реализовать решение) – Мы отказались от выполнения дополнительных задач от заказчика. Он был доволен только тогда, когда ставил нам задачу. А потом всё сначала: мы берем в работу, сроки сдвигаются, заказчик злится; – Переделали план с учетом рисков и затрат команды на организационные вопросы; – Согласовали с заказчиком новый график и после практически не сдвигали сроки.

CHECK (проанализировать и скорректировать) – Да, заказчик был очень зол на меня из-за моих нововведений; – Да, был риск, что заказчик подаст на нас в суд; – Да, был риск, что мы потеряем заказчика навсегда.

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

ACT (оптимизировать и создать новую стратегию решения задач) – Мы сдали проект позже срока по контракту и оплатили пеню за срыв; – Убрали из бюджета проекта затраты на доп.задачи; – Заключили новый договор на список доп.хотелок от заказчика; – И, как можно понять из предыдущего пункта, заказчик все еще был с нами.

Выводы: – Быть руководителем проекта – не всегда значит быть другом заказчику; – Сиюминутное удовлетворение желаний заказчика – не значит высокий уровень его удовлетворенности в долгосрочной перспективе; – Тщательное бюджетирование проекта – значит маржинальный проект для вас и достигнутые цели проекта для заказчика. В общем, MUST DO; – Не бояться говорить НЕТ.

И про эти самые «НЕТ» я скоро поделюсь инсайтами из одного занимательного интервью в своем канале https://t.me/startup_woman

А здесь анонсирую следующий пост про то, а как применять цикл Деминга не только в проектах, но и при запуске стартапа.