Во время проекта закончились деньги. Что делать?
Когда начинается новый проект, хороший менеджер проекта старается сделать все для того, чтобы проект прошел гладко: пишет уставы, организует команду, контрактуется с подрядчиком, резервирует бюджет, старается предусмотреть риски. На планирование проекта может уходить до одного года.
И вот проект стартовал, команда подрядчика и заказчика мобилизована, мотивация согласована. Прошел kick-off, стадии интервью, моделирования, проектирования, возможно даже разработки, все шло хорошо – хорошо…
И ничего не предвещало…
И вот на очередном тестировании, интегротесте, обучении или опытной эксплуатации пользователи выкатывают пул требований, которые не были учтены. Разобрав требования, обнаруживается, что ничего такого близко не было в ТЗ, и данные требования увеличивают объем проекта. И соответственно бюджет. Что делать?
Варианты развития событий в проекте зависят от:
- адекватности заказчика,
- ценовой модели,
- опытности со стороны проектного менеджера подрядчика.
Давайте рассмотрим возможные сценарии (все они взяты из жизни, то есть были реализованы):
1.В договоре заложена ценовая модель full fix price. Заказчик требует, чтобы вы доделали проект за свой счет.
Все мы понимаем, что цена проекта всегда дается против объема, и если объем меняется, то цена должна измениться тоже. Но не всегда удается донести это до Заказчика, часто встречаются аргументы из серии «мы вам говорили, хоть это нигде и не записано», «вы нас сами не спросили», «вы нас плохо обследовали».
В этом случае у Исполнителя два пути:
1.1.Работать в ущерб своей маржинальности (хорошо, если были предусмотрены в оценке проекта резервы).
Пример
Как-то у нас случился проект перехода на 1С Общепит. У нас был зафиксирован FFP в договоре, но обнаружилось, что мы сильно недооценили проект. В процессе мы принесли изменения клиенту, но договор на увеличение бюджета не был подписан, его согласование затянулось, а мы, желая не допустить срыва сроков, работали по изменениям, в надежде что договор будет подписан. В результате, когда договор дошел до ЛПР, выяснилось, что заказчик не может себе позволить такой бюджет проекта.
Дело осложнялось тем, что у нас были очень долгие отношения с этим клиентом, у нас с ним широкий бизнес, много совместных активностей. В этой ситуации клиент занял жесткую позицию, в том числе и от того, что бизнес клиента так же финансово страдал в пандемию, как и многие другие. Мы же, со своей стороны, допустили типичные ошибки управления проектом – плохо управляли объемом и ожиданиями клиента.
В данной ситуацией было принято решение дотянуть проект на морально – волевых качествах, мы завершили проект в убыток, но партнера не подвели, сохранив тем самым сотрудничество и возможность в будущем скомпенсировать убытки. Надо отметить, что хороший заказчик в таких случаях обычно понимает ситуацию другой стороны и предлагает какие-то варианты дополнительных работ или проектов, чтобы подрядчик в целом на клиенте хотя бы не нес убыток, несмотря на убыток в конкретном проекте.
1.2. Завершить проект, потеряв, возможно, какие-то работы не заактированными и репутацию.
Пример
Очень сложный кейс случился, когда мы пытались перевести одну торговую компанию на 1С УТ. До этого компания имела ряд филиалов, у каждого свои правила, регламенты, оформления, принципы ценообразования, своя какая-то система автоматизации, то есть исторически филиалы развивались по-разному. Этим проектом мы выполняли несколько задач: причесывание всех филиалов в одинаковые бизнес-процессы, перенос существующих процессов и их корректировка в единый формат, попытка учесть многовариантность событий, чтобы максимально сохранить пользователям возможность привычных принципов работы в системе.
Дело еще осложнялось тем, что компания работала в чувствительной к срокам реализации отрасли пищевой промышленности. Мы провели несколько тестов одного дня, и на каждом выяснялось, что мы не все учли, чтобы снизить риски потери отгрузки. Оказалось, что заказчик обладал нулевой терпимостью к рискам просадки в отгрузке, и откладывание старта несколько раз так в очередной раз не состоялось. Система все время была не готова, и все баги по мнению заказчика были критическими.
Через какое-то время оказалось, что команда полностью выгорела, работа без результата привела к тому, что риск развала команды стал очень явным. Мы поменяли проектного менеджера и договорились, что команда постепенно выходит из проекта. Сделали список функциональности, которую нужно доделать. Договорились о критериях приемки и постепенно вышли с проекта, предоставив заказчику самостоятельно решать вопрос о его готовности к старту.
Через пару лет они все-таки дошлифовали проект и стартовали. Но уже без нас. Репутационно это было сложное решение, но мы вздохнули с облегчением, а команда нуждалась в моральной реабилитации еще какое- то время. Многих членов команды мы потеряли, для себя сделали важные выводы.
2. Заказчик признает, что данные требования не входили в первоначальную оценку, и подрядчик справедливо приносит увеличение бюджета на изменения. Тогда все зависит от того, насколько в компании вес данного проекта существенен.
Пример
На интегротесте одного проекта выяснилось, что заложенная схема давальческой переработки не соответствует представлением о формирующихся цепочках документов у главного бухгалтера, то есть внутри компании было разное представление, какие документы и в какой срок должны рождаться.
Схема была полностью подвергнута реинжинирингу, переосмыслению, но это добавило времени и модификаций в систему. Работа по изменениям системы была оплачена подрядчику за счет имеющихся резервов на непредвиденные риски. Проектный менеджер этой компании был опытным, он учел этот риск при планировании.
Как правило, у заказчика есть следующий алгоритм.
2.1. Взвешиваются оставшиеся требования и вновь поступившие, сравнивается критичность между собой, выстраиваются приоритеты. Возможно часть предыдущих требований можно отложить на постпроектное развитие, отдав предпочтение новым требованиям, как более критичным.
Пример
На проекте после дизайна было описано большое количество требований, потому что пользователи стремились включить в автоматизацию не только процессы как есть, но и процессы как будет. Естественно, после оцифровки всех требований бюджет представлял собой х3 от того, что первоначально компания планировала потратить. Совместными усилиями управляющего комитета получившийся объем был классифицирован на as is и to be, на критичные и некритичные требования.
Критичные были проранжированы на несколько приоритетов:
- нужны к старту,
- нужны к закрытию,
- хорошо бы иметь (облегчает работу пользователей) и прочее.
Исходя из наличия ресурса подрядчика определили, какой потенциальный объем может быть выполнен, и исходя из всей полученной информации сделали несколько очередей разработки, часть из которой еще долго дорабатывалась, когда пользователи уже вовсю работали в новой системе. От некоторых требований заказчик отказался за ненадобностью, например, от ряда отчетов, потому что научился пользоваться стандартными.
2.2. если уже все требования, которые остались к реализации, очищены от «бантиков» и являются критичными, и вновь поступившие требования так же критичны, или невыполнения доработок ставят под риски текущий бизнес, то ищем пути снижения стоимости.
Хорошие пути:
2.2.1. Если проект выполняется силами подрядчика, но при этом в команде заказчика есть разработчики, занятые текущей поддержкой или другими проектами, ресурс можно перебалансировать, часть задач может быть передана на них за счет перераспределения приоритетов текущей работы.
Это поможет удержаться в рамках бюджета проекта, потому что как правило, зарплата сотрудников — это оперативные расходы компании, но повлияет на другие проекты или отодвинет текущие задачи. Аналогично, можно забрать часть работы на себя по проверке остатков.
Пример
На одном из проектов работы по проверке остатков переложили на бухгалтеров – подрядчик подготовил подробную инструкцию, как и что нужно проверять. Так как объем для проверки остатков ТМЦ был распределен на несколько бухгалтеров, нагрузка на каждого выросла не так заметно, но позволила высвободить ресурс аналитика для работы с изменениями.
На другом проекте проектный менеджер посчитал, что доплатить за экстра работы своему сотруднику дешевле, чем подрядчику. Все остались довольны, и сотрудник, и проектный менеджер, и работа сделалась.
2.2.2. Перераспределение расходов за счет других этапов. Возможно, можно сократить бюджет этапов внедрения, отказавшись от части работ. Стоит хорошо проанализировать, что будет, если мы откажемся, например, от написания бумажных инструкций? Возможно, достаточно будет записанных уроков для обучения или демонстраций при юнит – тестировании. Сюда же можно добавить пересмотр ценовой модели – возможно, если у вас решение не является критичным, то какие-либо принятые ограничения на этапе поддержки можно расслабить.
Пример
В условиях ограниченного бюджета на одном из проектов долго брейнштормили, на чем можно сэкономить. Все работы разумные, нельзя ни от чего отказаться. В итоге решили попробовать изменить модель активной поддержки, перевести ее почасовой формат в надежде уменьшить стоимость.
Надо понимать, что почасовой формат имеет риски неоперативного отклика в сравнении с форматом с выделенным ресурсом. То есть может случиться ситуация, что какая-то ошибка блокирует работу, но решена будет чуть позже, потому что в данное время сотрудники поддержи заняты на других проектах.
Подумав, заказчик выбрал такой вариант, потому что он позволял ему иметь достаточную экономию, а внедренная система не имела критичных функциональных областей, блокирующих текущую работу.
2.2.3. Проработка закрытия критики без увеличения бюджета. Например, интеграция с существующими решениями может быть дешевле, чем создание новой функциональности внутри конфигурации.
Пример
Лет десять или больше назад внедряли в одной компании УПП. Компания представляла собой холдинг по производству и продаже строительных материалов.
В процессе проекта было обнаружено, что процессы на двух производственных площадках предприятия настолько разный, что если их унифицировать и делать изменения в системе, то это получается очень дорого и очень долго.
Риски проекта были взвешены, в результате чего было принято решение оставить систему со складским учетом, которая удовлетворяла на тот момент заказчика, и сделать интеграцию с 1С в части передачи документов и записей по регистрам, настроив интеграционные потоки. Нужно быть готовым в таком варианте, что поддерживать интеграцию всегда достаточно сложная задача, но пришлось выбирать заказчику из двух зол.
Плохие пути:
2.2.4. Отказ от этапов тестирования, обучения, поддержки. Все это может сказаться на качестве проектного решения. Уменьшение тестирования непременно приведет к бо́льшему количеству багов. Отказ от Теста Одного Дня повысит риски на стыке функциональности для смежных бизнес-процессов. Отказ от обучения – пользователи будут недостаточно квалифицированные, в результате возрастет нагрузка на поддержку на старте работы. Еще мы встречались с требованием от Заказчика тратить меньше времени на анализ запроса, «что там анализировать». Такой подход несет на себе риски, что будет принято костыльное решение, либо последствия данного «недоанализа» вылезут потом в необходимости исправления в другом месте.
Пример
Дорабатывали внедренное решение по требованиям пользователей. Бюджет проекта ограничен, а требования пользователей фонтанируют, как из рога изобилия. KPI местного ИТ заточен на правильные вещи: удовлетворенность пользователей и попадание в плановые цифры.
Исполнение этого KPI вылилось на просьбу к подрядчикам меньше тратить времени на проработку решения (и, соответственно, меньше выставлять денег), не делать сложные решения, а точечно, с меньшими трудозатратами выполнять конкретную просьбу пользователя.
Очень долго приходилось убеждать заказчика избегать костыльных решений, потому что это в дальнейшем даст отложенный эффект на стоимость и трудоемкость процесса поддержки и обновления.
2.2.5. Заморозка проекта до следующего бюджетного цикла. Такие действия приведут, как минимум, к тому, что потом нужно будет вспоминать зачем мы вносим все эти изменения. А подрядчику выдергивать назад команду, которую потом не всегда получится в полном составе собрать.
Пример
Получив переоценку после дизайна с увеличением текущего бюджета, заказчик надолго погрузился в задумчивость. Подержав некоторое время, проектный менеджер разобрал команду во избежание простоя.
Через полгода заказчик очнулся, работы попытался возобновить срочно, но что произошло с командой за это время? Половина была занята в других проектах, кто-то уволился, кого-то смогли собрать. Но, когда приступили к выполнению, оказалась, что и жизнь ушла достаточно далеко, и часть модификаций уже не актуальна. Заказчик не смог дождаться автоматизации процесса и реализовал бизнес-процесс иначе, чем обсуждалось в связи с техническим трудностями.
В результате, первая работа на 50% выброшена в корзину, затем заказчик снова решил отложить проект, теперь уже на неопределенный срок, потому что уже поменялись менеджеры бизнеса, и соответственно, требования.
2.3. Если же резервы снижения стоимости исчерпали себя, но денег все равно не хватает – требуется перезащита бюджета. Если проект значим для компании и выявлены действительно критические требования, то разумным будет обосновать это перед высшим руководством или акционерами, попросив увеличения размера инвестиций.
Мудрый проектный менеджер обязательно добавит к оценке подрядчика не мене 20% стоимости. Перед защитой нужно подготовить апгрейд плана проекта по срокам. Добавление объема работ, как правило, сместит сроки вправо, и если вехи смещаются критично, то стоит продумать дополнительно План Б. Например, добавить ресурс (не всегда хороший путь, потому что увеличение ресурса несет ухудшение коммуникации и управляемости, что может еще сдвинуть план проекта дополнительно) или перенос срока старта.
Иногда перезащита бюджета – единственно возможный способ завершения проекта. Не нужно его боятся, ведь не ошибается тот, кто ничего не делает, а дорогу осилит идущий.
Выводы
Подводя итог всему вышесказанному, можно только пожелать так управлять проектом, чтобы денег хватило на проект.
Нужно соблюдать простые шаги:
- Адекватная оценка проекта. На стадии выбора подрядчика низкий бюджет проекта скорее должен насторожить.
- Закладывайте резервы. Как правило, бывает достаточно 30%.
- Соблюдайте правило проектного треугольника.
- Управляйте приоритетам и требованиям, регулярно проводите ревизию поступивших требований.
- Привлекайте подрядчика, которому доверяете.
- Регулярно отслеживайте прогресс по изменениям объема и влиянию на бюджет, не тяните до конца этапа.