Выживаем или растём? Влияние кризисов на реализацию портфеля проектов

Меня зовут Алексей Ермаков. Я работаю в компании PARMA Technology Group. Расскажу о том, как выживать и расти в современных кризисных условиях

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

Ситуация неопределенности возникает из-за того, что привычные средства, методы и окружение меняются. Эти изменения могут быть как незначительными, так и глобальными.

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

В таких условиях мы осознаем, что чего-то не понимаем, и эта неопределенность вызывает ощущение опасности.

Однако кризис – это не только угроза. Китайцы описывают слово «кризис» двумя иероглифами. Один из них – это «опасность», второй – это «возможность».

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

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

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

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

Психологи выделяют три основные реакции на кризисные стрессовые ситуации: бей, беги, замри.

• Но если бить, нам надо понимать кого и как – может быть, лучше не бить, а наоборот, приласкать.

• Если бежать – то куда и зачем.

• И замереть – на какое время.

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

• либо улучшить ситуацию и привести к сверхрезультатам;

• либо проект придется вообще закрыть;

• либо мы можем оставаться в некоем застое, ожидая, что все вернется на круги своя, но, скорее всего, не вернется, потому что ситуация поменялась, вероятность возврата низкая.

Мой доклад посвящен опыту принятия решений в критических точках проекта – я расскажу, в связи с чем возникали эти критические точки, какие решения мы принимали, и к чему это привело.

Как принимать решения в критических точках в проекте. На примере компонента «Реестр государственного и муниципального имущества»

Когда проект стартует, возникает множество вопросов – множество критических точек, в рамках которых нужно принять решения:

• Нужно выбрать способ управления проектом – Agile или Waterfal.

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

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

С подобным кризисом инициации мы столкнулись в проекте по разработке компонента «Реестра государственных служащих». Этот проект для нас не первый, скорее, один из последних, но очень яркий и показательный.

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

Тогда мы приняли решение провести ретроспективу проектного управления. Вся ретроспектива была построена на трех вопросах:

1. Команда проекта понимает содержание работ?

2. Как осуществляется коммуникация между сторонами проекта?

3. Знает ли каждый член команды текущую задачу и срок исполнения?

В реальности вопросов было гораздо больше, поскольку для ответа на вопрос «Как осуществляется коммуникация внутри проекта» нужно вообще понимать, с кем мы коммуницируем – знать заказчика, его заинтересованные стороны, участников команды, специфику проекта и так далее. Но три эти ключевых вопроса – это три вектора, на которые мы сделали акцент.

Мы собрали команду, провели ретроспективу, и в результате у нас получился довольно объемный отчет, в котором мы выявили много интересных и важных для себя аспектов.

• Мы сформулировали вопросы, по которым нужно было принять решения на этапе инициации проекта.

• Посмотрели, были ли приняты эти решения.

• Оценили, что это были за решения, и насколько они были эффективны.

Например, в блоке взаимодействия с заказчиком у нас были выявлены полярные результаты:

• С одной стороны, мы знали, кто наш заказчик, и что ему нужно.

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

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

Как принимать решения в критических точках в портфеле проектов. На примере Цифровой платформы Пермского края

Проекты объединяются в портфели. При работе с портфелем проектов ситуация по принятию решений усложняется, потому что появляются множество дополнительных вопросов:

• дополнительные взаимодействия с заказчиками;

• конфликты за ресурсы;

• конфликты за решения;

• пересечение этих решений – использование одного решения для другого и так далее.

Про критические точки в портфеле проектов я хочу рассказать на примере Цифровой платформы Пермского края.

В начале расскажу, что это за платформа, какие заказчики ей пользуются и в чем специфика.

• Цифровая платформа Пермского края – это информационная система, в которой автоматизирована вся финансово-хозяйственная деятельность региона.

• Система охватывает 100% муниципального и регионального уровней, обеспечивая работу пользователей 2500 организаций на одной платформе.

• В пиковые моменты во время отчетных периодов количество активных пользователей системы может достигать 13 тысяч.

• В состав цифровой платформы входит восемь компонентов.

• Множество интеграций – как внутренних, так и с различными федеральными и региональными системами.

• Основной технологический стек – это 1С. Используется:

  • стандартная конфигурация 1С;

  • партнерская конфигурация 1С;

  • и конфигурация, разработанная нашей компанией.

• Но стек 1С не единственный – существуют еще и другие технологические стеки.

Слайд сложно читаемый, но демонстрирует масштаб: много компонент, много функциональных заказчиков. Между этими функциональными заказчиками огромное количество взаимодействий.

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

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

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

• Еще есть множество функциональных заказчиков, которые объединены в две большие группы:

  • блок «Финансы»;

  • блок «Управление кадровой службой государственных служащих».

Повторюсь, взаимодействие нелинейное, и это накладывает существенный отпечаток на реализацию проекта.

История формирования портфеля проектов:

• Сам проект мы стартовали в 2018 году: была создана ЕИС, определен пилот (менее 1% общего объема с точки зрения пользователей, около 20-30% с точки зрения целевой функциональности), и началась разработка. На тот момент в портфеле был один проект, проектная команда и руководитель.

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

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

И наступил кризис роста.

У этого кризиса роста было несколько характерных особенностей:

• Начались конфликты в командах – все сотрудники в командах очень тесно пересекались, но часто были сложности с делением на проекты. Возникали такие заявления: «Я работаю в проекте А, поэтому в соседнем проекте ничего делать не буду». Либо другая сторона – когда есть интересная задача и за нее возникает спор. В итоге все эти споры и трения окрашиваются эмоциональной составляющей и приводят к конфликтам, вплоть до личностных.

• Результата нет, заказчик недоволен, работа выполняется неэффективно, но ресурсы мы в любом случае тратим, и эти ресурсы конечны.

• Бюджет начинает трещать, финансовые показатели не выполняются.

• Целевых результатов мы не достигаем, либо достигаем с серьезным нарушением сроков.

Кризисная ситуация, что делать? Нужно принимать решения.

Решения мы базировали на трех китах – это команда, бюджет, коммуникации.

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

Расскажу о решениях, которые мы приняли для команды:

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

• Команда портфеля, а не проекта. Все сотрудники работают в одном портфеле. Мы постарались искоренить эту местечковость: «Я в проекте А, а не в проекте Б». Было непросто, потому что это сидело достаточно глубоко. Но множество формальных и неформальных действий привели к пониманию сотрудниками, что они работают в чем-то общем, а не в частном.

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

• Мы стали проводить регулярные совместные ретроспективы на которых мы анализировали ошибки и рассказывали о том, что сделано и как сделано.

• Стали обмениваться опытом и проводить внутренние конференции, рассказывая о решениях, которые можно переприменить, либо о решениях, которые привели к положительным результатам.

• Создали базу знаний по портфелю – единый ресурс, на котором хранится вся информация, куда каждый может зайти и посмотреть.

• И самое важное – это истинная личная вовлеченность руководителей. Руководитель портфеля, руководитель проекта и тимлиды должны не просто говорить: «Чтобы успешно завершить проект, вы должны активно работать» и включать какого-нибудь классического администратора. Нет, они должны при любом обращении оказывать помощь и поддержку своей команде. Причем они должны быть действительно вовлечены в работу над проектом – тогда у человека возникает понимание, что он член единой команды, и ему действительно в сложной ситуации помогут.

Решения, которые мы приняли по коммуникациям:

• Прежде чем выстраивать коммуникации, надо понять, кто у нас в проектах участвует. Портфель проектов очень сложный. Первый шаг – это идентификация заинтересованных сторон. Заинтересованные стороны – это не обязательно заказчики, это не обязательно пользователи. Это люди, каким-то образом влияющие на итоговый результат. Они могут нигде не быть именованы в проектной документации и не засвечены во всяческих проектах, но они такие и есть. Причем их нужно не просто идентифицировать, но еще и классифицировать, потому что множественность заказчиков и историю их взаимодействия желательно замечать и фиксировать, чтобы учитывать эти особенности при планировании коммуникаций. Например, представителя службы А нежелательно приглашать на одно совещание с представителем службы Б, потому что они между собой не очень хорошо общаются. Мы понимаем, что история у них негативная, и вероятнее всего эта встреча пройдет с отрицательным результатом. В лучшем случае – ничем не закончится, а в худшем случае – мы все поругаемся.

• Собрав всю информацию, классифицировав, мы разработали коммуникационную модель – свод знаний о заинтересованных сторонах: кто с кем, как и зачем.

  • Кому лучше писать электронные письма, потому что он не воспринимает по-другому;

  • кому лучше звонить;

  • к кому лучше лично приходить;

  • какие группы заказчиков в каком составе собирать;

  • с какой периодичностью – кому-то надо чаще, а кому-то реже;

  • какую информацию и какому из заказчиков выдавать.

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

• «Единые» окна. Термин немного нестандартный, потому что в основном все привыкли к термину «Единое окно», но мы решили, что в нашем случае название «Единые окна» будет наиболее оптимальным.

  • Да, у нас есть Service Desk, куда все пользователи могут позвонить, задать вопрос и его решат, но это для массового спроса.

  • А пользователи нашего заказчика разнородны по потребностям к скорости реакции. Например, есть ключевые пользователи, которые принимают те или иные решения для изменения функции – для них нужны окна по тематикам. Например, есть тематика «Регламентированный учет и зарплата», и ключевые пользователи могут обратиться к нашему эксперту через это окно. Под окнами здесь, в основном, подразумеваются группы в Telegram.

  • И есть люди, которые не работают с системой, но являются заказчиками, они ставят задачу – это наши спонсоры. Спонсор может напрямую позвонить руководителю портфеля или руководителю проекта и решить достаточно сложный вопрос, требующий вовлечения многих.

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

И, наконец, решения, которые мы приняли по бюджетам проектов:

• Когда появились проекты, их было много, они как грибы выросли, у некоторых руководителей проектов возникла такая история, что факт бюджета всегда должен соответствовать плану – какие-либо отклонения невозможны. Если Иванов в проекте забюджетирован на 50%, а поработал он на 55%, эти 5% трудозатрат в бюджет не пойдут. Логика с одной стороны понятна, с другой стороны необъяснима. Зачем таким путем идти? План не всегда должен соответствовать факту. Поэтому мы приняли решение реализовать для портфеля проектов иерархию бюджетов – когда бюджет портфеля и бюджеты проектов друг с другом связаны.

• И мы приняли решение вести единое бюджетирование ресурсов.

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

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

• Еще одно направление принятия решений по бюджетам проектов – это повышение объективности оценки осваиваемого объема. Мы над ним работали, работаем и, я думаю, еще долго будем работать, потому что 100% объективность нами еще не достигнута.

Я некоторое время работал не в IT-сфере, а на объектах компании «Транснефть» и занимался монтажом магистральных нефтепроводов. Там все было просто – я знал, сколько метров мы выкопали, сколько тонн трубы достали, сколько кубов засыпали и так далее. Можно было посчитать оценку бюджета максимально точно – мы знали точные объемы. Но в IT этого пока достичь не удалось.

Что мы делаем для повышения объективности оценки освоенного объема?

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

• Полученные задачи дробим на этапы – формирование ТЗ, разработка, функциональное тестирование. В разных задачах может быть разное количество этапов.

• И ищем источники внешних подтверждений – привлекаем заказчика, чтобы он подтвердил нам на более ранних этапах, что этот объем действительно выполнен. Это решает сразу два вопроса:

  • мы сами понимаем, что действительно это сделали;

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

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

Как принимать решения в критических точках в портфеле проектов

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

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

Тем не менее у нас возникли новые вызовы:

• В портфеле появились новые проекты.

• Появился тренд на цифровую трансформацию, который, в том числе, продвигается государственной программой. Предполагается, что автоматизация уже закончена, но, к сожалению, это не везде так.

• И про изменение экономики я уже сказал.

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

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

• Мы должны были заниматься проактивным продвижением услуг, но данные были разрозненные и неупорядоченные.

• Логики в хранении данных никакой не было – они хранились во множестве электронных систем. А иногда вообще нигде не хранились – просто лежали где-то в столе, оформленные на бумаге.

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

Но были и положительные моменты:

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

• Было доступно хорошее аппаратное обеспечение – большой ЦОД, рабочие станции на местах.

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

И у заказчика были ожидания.

• Заказчик ожидал проактивное предложение услуг. Он не просто хотел, чтобы люди вбивали информацию в какую-то систему. Он хотел, чтобы потребители двух основных сервисов этой системы – услуг по приватизации имущества (выкуп из государственной собственности) и сдаче в аренду – получали предложения. Допустим, я занимаюсь выпечкой пирогов, у государства есть помещение для предоставления в аренду, и мне приходит предложение: «Помещение готово, подпиши договор и пользуйся. Можно никуда не ходить, а подписать все в электронном виде». Вот такие ожидания.

• Аналитика данных. Так как система регионального уровня, хотели видеть всю информацию по объектам имущества в регионе – например, хотели видеть, что на содержание дома культуры в городе А тратится N рублей, в городе Б – M рублей. Почему разница? Дома культуры типовые, построены одинаково.

• И, конечно же, заказчик хотел получить экономические эффекты от предоставления услуг. Основная цель – это пополнение бюджета при помощи двух этих каналов.

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

• Конечным результатом мы определили разработку механизма проактивного предложения услуг.

• А первым этапом предложили создать базу для автоматизации

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

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

• И запланировали использовать технологию 1С:Элемент для создания личных кабинетов учреждений – чтобы они могли в них работать со своим имуществом.

Заключение

Чтобы быть готовыми к кризисам и преодолевать их, важно работать в четырех направлениях:

• повышать сплоченность команды;

• улучшать эффективность коммуникаций;

• делать бюджет действительно рабочим механизмом;

• и искать возможности в любой кризисной ситуации – когда что-то меняется, использовать изменения для развития.

В конце хочу сказать словами классика: «Вот как иногда поворачивается жизнь: то тень беспросветная, то снова улыбается солнце». Кризисы есть, но они приходят и уходят, а нам нужно искать в них возможности.

Вопросы и ответы

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

В докладе я рассказывал о двух окнах.

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

• А окна в Telegram применяются только для ключевых пользователей, список которых ограничен. Если бы ключевых пользователей были сотни, то да, все бы умерло.

На слайде «Команда» был представлен список пунктов, которые надо выполнить, чтобы улучшить взаимодействие между проектами в портфеле проектов. Но если выполнить все эти пункты, получится, что команда работает над одним большим проектом. В чем тогда термин «портфель проектов» заключается?

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

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

У заказчика всегда будет возникать желание получать услуги за бесплатно. Мы с вами договорились сделать такой объем, а я потом постоянно добавляю, добавляю, добавляю. Но не деньги.

С этим нужно работать. Это одна из основных функций руководителя проекта – управлять требованиями. Требования формулирует заказчик, но ими нужно управлять. А управление – это не просто сказать: «Да, я понял, что нужно делать» и пойти делать. Нужно сказать, на каких условиях сделаем, когда сделаем, включим ли в состав работ этого проекта, либо это не относится к этому проекту.

Может ли быть ситуация, когда проект просто закрывается, потому что мы не можем его обеспечивать?

Может. Если мы вошли в проект, начинаем его реализовывать, и понимаем, что конечный результат не тот, зачем его достигать?

А что с бюджетом? Или эти ресурсы потеряны?

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

Если риск не покрыл потребности, нужно либо увеличение бюджета, либо закрытие проекта – такое тоже не исключается. А бюджет – да, потратили.

Вы упомянули, что хорошей практикой может быть объединение команды в команду портфеля. Какие есть индикаторы и красные флаги того, что команда уже не работает эффективно по проектам, и их нужно объединять в общую команду портфеля?

У нас первым индикатором того, что команды надо объединять, были конфликты – вплоть до того, что вы садитесь обедать вместе, и прямо видно, как искры летят между участниками команды.

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

Поэтому индикатором в нашем случае было взаимодействие сотрудников различных команд.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022 Saint Petersburg.