Работаем с рисками на глобальном уровне В прошлой статье о проектных кейсах мы говорили о проблемах.
В одном каскадном примере необходимо было расширить границы проекта, изменить BPI и пересмотреть бюджеты.
Во втором проекте с гибкой методологией заказчик вообще не получил никакой выгоды.
В третьем случае гибридный подход позволил успешно и в срок завершить проект только потому, что команда проекта со стороны заказчика была хорошо мотивирована на результат и, понимая ограниченность ресурсов, ввела новые настройки и убрала из проекта менее приоритетные задачи.
спринты.
Мы будем ссылаться на первую статью, так что если вы ее не читали, есть смысл посмотреть хотя бы по диагонали - здесь связь .
Оглядываясь назад, легко описать эти случаи и обозначить их как успешные или неудачные.
Но в процессе работы над ними все выглядит сложнее и заранее указать на отрицательный результат невозможно.
При этом финансовые и репутационные потери на корпоративных проектах могут быть очень и очень большими.
Прежде всего, мы оцениваем риски с точки зрения нас, как организации-исполнителя проекта автоматизации:
- Определяем основные риски нового проекта и их критичность.
- Мы сравниваем цели проекта, заявленные заказчиком, с тем, что мы можем считать его реальными потребностями, исходя из нашего опыта реализации проекта.
- Определяем приоритеты сроков, бюджетов и заявленного функционала.
- Затем мы должны принять фундаментальные решения о сценариях реагирования на возникшие риски.
- Мы фиксируем для себя приемлемую сумму потерь, если все пойдет совсем плохо.
- Мы оцениваем, насколько увеличится объем рисков в целом для портфеля проектов, который сейчас ведет «Форвард», если мы возьмем новый проект.
- И в конечном итоге мы решаем, какой размер потерь или репутационного ущерба заставит нас возбудить судебное разбирательство, и сколько мы готовы потратить на юридическое сопровождение.
Более детальная оценка рисков конкретного проекта проводится в рамках самого проекта и фиксируется в проектной документации в соответствии с выбранной методологией проекта.
Теперь о рисках, находящихся вне нашего контроля, и ключевых аспектах, без которых было бы невозможно завершить работу в описанных проектах без репутационных и финансовых потерь.
Это не зависит от нас
Вот список рисков, на которые мы практически не влияем, но которые необходимо учитывать:- Потеря финансовой стабильности Клиент не может продолжать платить и замораживает/закрывает проект.
- Потеря/отсутствие интереса ключевого заказчика к проекту
Проектная команда заказчика не понимает, зачем ей пытаться.
Проекту не уделяется достаточно внимания для получения экономически значимого результата.
В результате проект приостанавливается или контракт расторгается.
Пример: договорились с генеральным директором о реализации амбициозного проекта по автоматизации.
Через некоторое время генерал ушел, и его заменили люди из кадрового резерва роты – старая гвардия.
Новый генерал не понимал, зачем вообще нужна новая система автоматизации, почему от старой отказались и проект свернули.
- Потеря/отсутствие целевой аудитории (клиентов) у заказчика
Если заказчик придумал идею, но не проработал маркетинг или продукт, велика вероятность, что со временем компания откажется от своей идеи и переключится на что-то другое.
Пример: MVNO-оператор, который еще не определился со своим позиционированием, уникальным рыночным предложением и аудиторией.
Нет понимания, какие услуги будут востребованы.
Каждый месяц, а иногда и неделю у заказчика возникает желание внедрить в информационную систему что-то новое; часть работ по ранее начатым инициативам никогда не будет завершена, потому что они были заброшены на полпути, даже не протестировав.
- Отсутствие команды клиентов
В крупных проектах должны работать обе стороны, и если между бизнесом и подрядчиком нет буферной зоны из собственных «технологов», то есть риск замедления/удорожания проекта.
Пример: У заказчика нет технических экспертов — технологов, системных аналитиков, которые смогут оценить полезность для бизнеса того или иного решения.
Выбор функциональной информационной системы для внедрения происходит очень медленно, а внедрение бизнес-решений занимает еще больше времени.
Иногда мы даже можем за свой счет сделать оценку и анализ, и подобрать конкретное решение, но не все заказчики готовы это сделать, так как у них нет компетенции проверить качество нашего выбора.
- Нормативные изменения
Например, закон Яровой.
Есть вещи, о которых вы не знаете заранее, когда начинаете работу.
Но эти изменения могут просто убить экономику проекта, вынудив заказчика отказаться от проекта.
У нас была такая ситуация, что по одному проекту регулятор заблокировал финансовые потоки и заказчик был вынужден заморозить часть нашей деятельности.
Затем сменилось руководство заказчика и была пересмотрена парадигма управления компанией; соответственно, для реализации потребовались подсистемы, отличные от первоначально запланированных.
Солому необходимо постелить заранее
А под соломинкой мы подразумеваем правильно составленные контракты и соглашения.Если по договору мы только обязаны, никаких прав не имеем, и заказчик ни за что не отвечает - такой договор ничего не стоит. Неважно, насколько хорошие личные отношения с представителями заказчика.
Даже в коротком проекте могут произойти изменения, которые радикально изменят расстановку сил в проекте.
Может смениться собственник, из организации уйдет ключевой функциональный заказчик, и компания начнет испытывать финансовые трудности.
В контракте должна быть прямо оговорена возможность изменения границ проекта по инициативе каждой стороны и при каких условиях могут быть инициированы изменения.
Нельзя экономить на юристах при составлении и заключении договора.
Более того, юристу необходимо хорошо разбираться в нашей специфике деятельности или специально потратить время на изучение вопроса, чтобы правильно расписать условия работы.
Есть ли какие-либо коммуникации? Что, если я найду это?
Переговоры – это краеугольный камень.В основе закреплены обязательства и ответственность, сформированы ожидания и такое же понимание происходящего.
Без хорошего переговорщика воронка продаж резко сокращается, потому что убедить клиента работать с нами просто не удастся.
В проекте, где сработали риски, переговорщику придется обосновывать изменения бюджета, согласовывать новые сроки или разделение функционала на несколько очередей.
В худшем случае вам придется завершить работу с клиентом на какой-нибудь нейтральной ноте, минимизировав для себя потери.
Например, во втором кейсе из предыдущей статьи мы говорили о том, как заказчик не получил готового результата, в какой-то момент отказавшись от продолжения работы и не сформировав новый спринт. Если мы понимаем, что проект забуксовал, то необходимо подвести итоги проделанной работы, представить эту информацию владельцу и попытаться реанимировать проект. Это тоже задача переговорщика.
В задачи переговорщика также входит помощь функциональным заказчикам в коммуникациях внутри проектной команды заказчика, если им не хватает собственных компетенций.
Переговорщиком с нашей стороны, в зависимости от размера проекта, его особенностей и стадии переговорного процесса, может быть продавец, менеджер проекта (ПМ), аккаунт-менеджер, директор.
Продажи проводят первичные переговоры и презентации.
В крупных проектах после успешных первичных переговоров продавец передает информацию команде проекта и больше не участвует в переговорах.
В небольших проектах продажи могут взять на себя часть коммуникаций с заказчиком, частично выполняя функции торгового представителя и менеджера по работе с клиентами.
РП часто воспринимается как чисто технический менеджер, который не может обсуждать свои бизнес-логичные решения с клиентами.
Поэтому необходимо обязательно подключить тяжелую артиллерию.
Аккаунт-менеджер – это высокая должность и аккаунт должен входить в один круг заказчика.
Тогда у нас получится открытый и предметный разговор.
В большинстве проектов именно менеджер по работе с клиентами является основным переговорщиком и обычно отвечает за устранение рисков в проекте.
При необходимости к учету привлекаются директора.
Если на начальном этапе обсуждения проекта к обсуждению критических вопросов привлекались директора, то менеджеры нижнего звена боятся нарушить договоренности и обострить проблемные ситуации, чтобы не взять на себя ответственность.
Алгоритм анализа триггерного риска примерно такой:
- Анализируем проблему и ее причины.
- Разрабатываем варианты действий по модели win-win и оформляем их в виде дорожной карты.
- Мы садимся за стол переговоров и открыто предлагаем заказчику варианты.
Нужно больше золота или что-то с мотивацией?
Есть ли правильное соглашение и переговорщики со стороны заказчика и подрядчика? Договорились ли продавцы и функциональные клиенты о том, чего они хотят, и оценили ли объем работ? Даже лица, принимающие решения, обо всем договорились? Расслабляться еще рано.
Впереди сам проект — месяцы, а иногда и годы работы со сроками, активизации работ на стадиях проекта, сдачи функционала в опытную и коммерческую эксплуатацию, обучения пользователей.
Для того чтобы работа была эффективной, необходима адекватная мотивация и заинтересованность коллективов заказчика и подрядчика.
И нам, как исполнителям, было бы полезно знать, какая мотивация у команды заказчика.
И иногда даже имеет смысл сосредоточиться на этом на начальных этапах проекта, чтобы лучше понять баланс сил и интересов.
Вы можете предложить лицу, принимающему решения у клиента, внедрить особую мотивацию для его команды.
В глобальном масштабе существует два подхода:
- Денежный
При выполнении проекта в срок с сохранением рентабельности команда получает 5-7% от стоимости работы.
На практике схема работает редко.
Большинство проектов не завершаются вовремя, поскольку в ходе реализации происходит множество изменений.
Из-за этого участники демотивируются - 6 месяцев они работали почти по ночам, чтобы уложиться в сроки, а теперь поменялась обстановка, переписан базовый план проекта, обновлен календарь и общий срок выполнения увеличился в три раза.
месяцы.
Разрыв между интересами исполнителей и бизнеса.
Исполнители рассчитывают на поощрение в течение указанного срока и выступают против изменений, влияющих на бюджет, трудозатраты и сдвиги сроков.
И бизнесу уже не нужна оригинальная постановка задачи.
Бизнес понял, что тенденция сейчас другая.
Поэтому у нас есть монетарный подход, который используется как вспомогательный, а не основной.
- Ориентированный на результат
Состоит из трех элементов.
Первая – объяснить и показать значимость проекта, практическую пользу, которую приносит работа исполнителей.
Это обеспечивает необходимый уровень вовлеченности и вовлеченности в общий результат. Создав рабочее место оператора, обслуживающее миллион абонентов, оператор чувствует себя удовлетворенным и воспринимает себя творцом.
Второй элемент – признание.
Руководство подрядчика и заказчика должно признавать индивидуальные и командные достижения проектной команды.
Продемонстрируйте свое участие и дайте обратную связь.
Третий элемент – это изначально достойный доход. Без этого невозможно набрать квалифицированную команду для проекта.
Без этого специалист будет думать не о качестве кода или корректности разрабатываемого бизнес-процесса, а о том, что ему недоплачивают.
Никаких скрытых игр, конкуренции между отделами и задержек не было.
Было активное взаимодействие и желание договориться, чтобы получить результат. И результат успех – своевременный запуск MVNO.
Заключение
Автоматизация бизнеса — это больший риск для клиента, чем для нас, исполнителей.Но в первую очередь от нас зависит, как будет развиваться ситуация, если на проекте возникнут проблемы.
Мы должны суметь довести проект до запуска без фатального ущерба для клиента и себя и не бросить клиента на произвол судьбы.
После каждого проекта мы проводим ретроспективу.
Мы вспоминаем, что у нас было на входе проекта по объемам работы, оценке, стоимости и сравниваем с тем, что получили в итоге.
Анализируем отклонения и спровоцированные риски: где мы ошиблись в оценке, где заказчик сам изменил задачу, где проблема вообще не от нас зависела.
Цель ретроспективы — повысить точность оценки затрат на рабочую силу в аналогичных будущих проектах.
Результаты ретроспективы являются учебным материалом.
Наши сотрудники видят, где отсутствие аналитической работы и недостатки технического задания приводят к неоправданным трудозатратам.
Также мы создаем репозиторий лучших решений.
И когда в новом проекте мы видим, что задачи схожи, мы обращаемся к репозиторию — используем его повторно, а не придумываем с нуля, тем самым снижая затраты заказчика.
Для себя мы вывели следующие аксиомы:
- Документируйте все решения и соглашения.
- Подходите к переговорам и формированию ожиданий как к процессу.
Целенаправленно договаривайтесь, не бросайте все и не молчите.
Постоянно получать обратную связь от клиента.
- Понять для себя важность мотивации нашей команды на проекте и объяснить лицам, принимающим решения заказчика, важность построения системы мотивации на результат в команде заказчика.
Что вызывает у вас больше всего проблем в проектах? Какие риски возникли в ваших проектах и как вы справились с последствиями? Теги: #Управление проектами #agile #Биллинговые системы #биллинг #управление проектами #технология проекта #технология проекта
-
Киевский Бизнес-Инкубатор
19 Oct, 24
