Работаем с рисками на глобальном уровне

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

Задним числом легко описывать эти кейсы и обозначать успешными или неуспешными. Но в процессе работы по ним, всё выглядит более сложно и заранее указать на негативный результат нельзя. При этом финансовые и репутационные потери на корпоративных проектах могут быть очень и очень большими.

В первую очередь мы оцениваем риски с точки зрения нас, как организации-исполнителя по проекту автоматизации:

Определяем основные риски нового проекта и их критичность.
Сравниваем анонсируемые заказчиком цели проекта с тем, что мы можем считать его реальными потребностями исходя из нашего проектного опыта.
Определяем приоритеты сроков, бюджетов, заявленного функционала.
Затем мы должны принять принципиальные решения о сценариях реакции на сработавшие риски.
Фиксируем для себя приемлемый объем потерь, если все пошло совсем плохо.
Оцениваем насколько увеличивается объем рисков в целом по портфелю проектов, которые сейчас ведет «Форвард», если взять новый проект.
И под конец решаем, какой объем потерь или репутационного вреда заставит нас инициировать судебное разбирательство, сколько мы готовы тратить на юридическое сопровождение.

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

Теперь о рисках, независящих от нас и ключевых аспектах, без которых нельзя было бы завершить работы в описанных проектах без репутационных и финансовых потерь.

От нас это не зависит

Вот список рисков, на которые мы влияем мало или не можем повлиять совсем, но должны учитывать:

Потеря финансовой стабильности
Заказчик не способен далее платить и морозит/расторгает проект.
Потеря/отсутствие заинтересованности ключевого заказчика в проекте
Проектная команда заказчика не понимает, ради чего ей стараться. Проекту не уделяется должного внимания, достаточного для получения экономически значимого результата. В итоге проект уходит на холд или договор расторгается.

Пример: договорились с генеральным о реализации амбициозного проекта автоматизации. Через некоторое время генеральный ушел и вместо него пришли выходцы из кадрового резерва компании — старая гвардия. Новый генеральный не понимал для чего вообще нужна новая система автоматизация, почему отказались от старой и проект свернули.
Потеря/отсутствие целевой аудитории (клиентов) у заказчика
Если заказчик придумал идею, но не проработала маркетинг, продукт, высока вероятность, что со временем компания откажется от своей идеи и переключиться на какую-то другую.

Пример: MVNO-оператор, который не определился со своим позиционированием, уникальным рыночным предложением и аудиторией. Нет понимания, какие услуги будут востребованы. Каждый месяц, а порой и неделю у заказчика возникает желание реализовать что-то новое в информационной системе, часть работ по ранее запущенным инициативам никогда не будут завершены, потому что их забросили на полпути, даже не протестировав.
Отсутствие команды Заказчика
В больших проектах должны работать обе стороны, и если между бизнесом и исполнителем не будет буферной зоны собственных «технологов», то есть риск замедления /удорожания проекта.

Пример: у заказчика нет технических экспертов — технологов, системных аналитиков, которые могут оценить полезность для бизнеса того или иного решения. Очень медленно осуществляется выбор функциональной информационной системы для внедрения, еще дольше тянется имплементация бизнес-решений в реализацию. Мы иногда можем сделать даже за свой счет оценку и анализ, подобрать конкретное решение, но не все заказчики готовы идти на это, потому что проверить качество нашего выбора у них не хватает компетенций.
Регуляторные изменения
Например, закон Яровой. Есть вещи, о которых заранее не знаешь, когда начинаешь работы. Но эти изменения могут просто убить экономику проекта, вынуждая заказчика отказаться от проекта.

Эти риски легко комбинируются в реальных проектах. У нас было такое, что на одном проекте регулятор заблокировал финансовые потоки и заказчик был вынужден часть наших активностей заморозить. Затем поменялось руководство заказчика и произошел пересмотр парадигмы управления компанией, соответственно потребовались для внедрения подсистемы, отличные от изначально запланированных.

Соломку надо стелить заранее

И под соломкой мы имеем в виду правильно составленные договора и соглашения.

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

В договоре в явном виде должны быть прописаны возможности изменения границ проекта по инициативе каждой из сторон и при каких условиях изменения могут быть инициированы. Экономить на юристах при составлении и заключении договора нельзя. Более того, надо чтобы юрист хорошо разбирался в нашей специфике деятельности или специально потратил время на изучение вопроса, чтобы корректно прописать условия работы.

Коммуникации есть? А если найду?

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

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

Например, во втором кейсе из прошлой статьи мы говорили о том, что заказчик не получил готового результата, в какой-то момент забив на продолжение работ и не формируя новый спринт. Если мы понимаем, что проект застыл, то необходимо подвести итог выполненным работам, презентовать эту информацию собственнику и попытаться реанимировать проект. Это тоже задача для переговорщика.

В задачи переговорщика входит и помощь функциональным заказчикам с коммуникациями внутри проектной команды заказчика, если у них не хватает своих компетенций.
Переговорщиком с нашей стороны в зависимости от размера проекта, его особенностей, этапа переговорного процесса могут быть сейлз, руководитель проекта (РП), аккаунт-менеджер, директор.

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

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

Аккаунт-менеджер — это высокая должность и аккаунт должен быть вхож в такие же круги у заказчика. Тогда получается открытый и предметный разговор. В большинстве проектов именно аккаунт-менеджер является основным переговорщиком и отвечает в общем за разруливание рисков на проекте. При необходимости аккаунт привлекает директоров.

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

Алгоритм разбора сработавшего риска примерно такой:

Анализируем проблему, ее причины.
Разрабатываем варианты действий по модели win-win, оформляем их в виде дорожной карты.
Садимся за стол переговоров и открыто предлагаем варианты заказчику.

Нужно больше золота или что там с мотивацией?

Есть правильный договор и переговорщики со стороны заказчика и исполнителя? Продавцы и функциональные заказчики договорились о желаемом, оценили объем работ? Даже ЛПР согласовали всё? Расслабляться всё еще рано.

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

Чтобы работы были эффективными нужна адекватная мотивация и заинтересованность команд заказчика и исполнителя. И нам, как исполнителям, хорошо бы знать, какая есть мотивация у команды заказчика. А иногда даже есть смысл акцентировать на этом внимание еще на начальных этапах проекта, чтобы лучше понимать расстановку сил и интересов. Можно предложить ЛПР заказчика ввести специальную мотивацию для его команды.

Глобально есть два подхода:

Монетарный

При выполнении проекта в срок с сохранением маржинальности, команда получает 5-7% от стоимости работ.

На практике схема редко работает. Большинство проектов в срок не делается, потому что в процессе реализации возникает много изменений. Из-за этого участники становятся демотивированы — они 6 месяцев чуть ли не по ночам работали, чтобы уложиться в сроки, а теперь постановка изменилась, базовый план проекта переписали, календарь обновили и общий срок увеличился на три месяца.

Разрыв интересов исполнителей и бизнеса. Исполнители ждут поощрения в указанный срок и против изменений, влияющих на бюджет, трудозатраты и смещение сроков. А бизнесу уже не нужна исходная постановка задачи. Бизнес понял, что сейчас тренд в другом.

Поэтому у нас монетарный подход, используется как вспомогательный, а не основной.
Ориентация на результат

Состоит из трех элементов. Первый — объяснить и показать значимость проекта, практическую пользу, которую приносит труд исполнителей. Это обеспечивает нужный уровень вовлеченности и причастности к общему результату. Создав рабочее место оператора, который обслуживает миллион абонентов исполнитель чувствует себя удовлетворенным, воспринимает себя как творца.

Второй элемент — признание. Руководство исполнителя и клиента должно признавать индивидуальные и командные заслуги проектной команды. Демонстрировать собственную вовлеченность и давать обратную связь.

Третий элемент — изначально достойный заработок. Без этого не набрать квалифицированную команду на проект. Без этого специалист не о качестве кода или правильности разрабатываемого бизнес-процесса будет думать, а о том, что ему платят мало.

В третьем кейсе с гибридной методологией у нас были жёсткие сроки запуска MVNO. Команда заказчика была высокозамотивирована на том же самом что и мы – успешном запуске. Не было подковерных игр, конкуренции между подразделениями и латентности. Были активное взаимодействие, стремление договориться для получения результата. И в результате успех — своевременный запуск MVNO.

Заключение

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

После каждого проекта мы проводим ретроспективу. Вспоминаем, что у нас было на входе проекта с точки зрения работ, оценки, стоимости и сравниваем с тем, что получилось в итоге. Анализируем отклонения и сработавшие риски: где мы ошиблись в оценке, где сам заказчик изменил задание, где проблема вообще от нас не зависела. Задача ретроспективы повысить точность оценки трудозатрат в аналогичных будущих проектах.

Результаты ретроспективы — учебный материал. Наши сотрудники видят в каких местах недостаток работы аналитика и недоработки ТЗ выливаются в лишние трудозатраты. Также мы формируем репозиторий лучших решений. И когда в новом проекте мы видим, что задачи схожие, то обращаемся к репозиторию — переиспользуем, а не придумываем с нуля — тем самым уменьшая затраты заказчика.

Для себе мы вывели следующие аксиомы:

Документировать все решения и договоренности.
Подходить к переговорам и формированию ожиданий, как к процессу. Целенаправленно договариваться, не бросать всё и не уходить в молчанку. Непрерывно получать обратную связь от заказчика.
Понимать самим важность мотивации нашей команды на проекте и объяснять ЛПР заказчика важность выстраивания системы мотивации на результат у команды заказчика.

Делитесь своим опытом в комментариях. Что вам доставляет больше всего проблем на проектах? Какие на ваших проектах срабатывали риски и как вы разбирались с последствиями?

Проектные технологии при внедрении биллинговых систем у корпоративных клиентов (часть 2)