Внедрение ИСУП (Jira, Coda.io, Fibery.io и тд): выбираем проекты и подбираем менеджеров

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

Но давайте по порядку.

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

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

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

На мой взгляд, главный критерий выбора менеджера проекта — это насколько ему вообще интересно внедрение ИСУП. Менеджер должен быть лоялен идее внедрения нововведений. Плохо, если он воспринимает их как дополнительную нагрузку. А вот если он уже ранее сам пытался настроить систему управления, например, в таблицах Exсel, то думаю, это тот кандидат, который вам нужен.

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

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

Проекты на завершающей стадии (не больше двух месяцев до завершения) тоже не подойдут, и вот почему. Если проект, который вы берете в пилот, закончится до конца внедрения вашего решения по управлению проектами, то мотивация руководителя проекта будет крайне низкой. Он попросту не успеет внедрить большинство изменений. Поэтому выбирайте такой проект, чтобы было время на внедрение ИСУП.

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

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

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

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

При этом всегда есть риск, что модель ИСУП, оптимальная для какого-то определенного проекта, не подойдет для другого, со своей спецификой. Поэтому при выборе проекта нам необходимо обращать внимание на то, чтобы он обладал определенными типовыми чертами. А именно:

• наличие подрядчика;
• наличие внутренней команды;
• наличие как минимум одного заказчика.

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

Также стоит избегать имиджевых проектов, то есть таких, у которых есть именитые руководители, которые не готовы менять свои подходы к управлению. У их менеджеров подобных проектов на первый план часто выходит нежелание выполнять определённые правила, требования и использовать ИСУП. При этом у них всегда есть в арсенале аргумент, почему не нужно этого делать. Например, потому, что они подчиняются непосредственно руководителю или собственнику.

Важно отделять репутацию проекта и репутацию ИСУП, потому что если внедренная система не будет использоваться по назначению, ее репутация может пострадать.

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

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

Не стоит брать второстепенные проекты, которые не имеют четко определённой важности для руководства подразделения или компании. Они часто не находятся в фокусе внимания и слабо контролируются. Из-за этого сложнее показать эффективность и качественный результат работы системы и тем самым добиться признания. Это тоже влечет за собой определенные репутационные риски для ИСУП.

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

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

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

Для управления изменениями важно показать, что разработанная модель идеально подходит, система работает, а руководители проектов ее поддерживают и активно используют.