Проектный менеджмент и одевание детей

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

Почему так происходит? Чаще всего, руководство решает уволить менеджера проекта, реже — сменить команду. Но как правило, виноват не менеджер, не команда, а неправильно выстроенная система управления проектами.

Три расклада неработающих систем управления проектаим

Ребёнка на улицу одевает тревожная бабушка

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

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

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

Ребёнка на улицу одевает неопытный отец

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

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

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

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

Но есть еще и третий вариант, почему технология тоже не будет работать. И о нём я расскажу ниже.

Ребёнок вырос из старой одежды

Даже если научиться одевать ребёнка адекватно, оставаться в статике не получится — мелкий умудряется расти, причём довольно быстро.

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

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

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

Технология управления проектами – живой организм, который развивается вместе с организацией. Меняется организация – меняется и технология. 

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

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

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

Дальше будем разбирать детально эту гиперочевидную мысль.

Как понять, что нужно делать, а что нет?

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

В зависимости от контекста, может потребоваться, к примеру, глубокая проработка ресурсного аспекта. А может, напротив, в вашей компании важнее финансовый аспект.

Опирайтесь на здравый смысл.

Поговорим о том, как выделить важные аспекты именно в вашей компании.

Для начала определите:

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

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

• критерий успеха – приживаемость результата;
• критерии неуспеха, связанные с нарушением каких‑либо требований;
• проблему разрастания требований.

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

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

Ниже расскажу на примере аспекта сроки, он применяется чаще всего.

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

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

Ответ на эти вопросы – артефакты и события.

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

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

Итак, сроки. В зависимости от сложности структуры организации, её масштаба, специфики проектов и т. д., состав и содержание артефактов (доказательств результатов) может меняться.

Ключевые артефакты, позволяющие видеть ясную картину, что происходит со сроками на проектах:

• бизнес-кейс;
• паспорт проекта;
• план проекта / фазы / релиза;
• протокол встречи / задачи проекта;
• запрос на изменение;
• отчет по проекту;
• отчет о завершении проекта.

Этот набор артефактов может варьироваться: все зависит от масштаба организации, проектов и внутренних процессов. Далеко не всегда нужен запрос на изменение (если вы делаете строго фиксированный проект, изменений не будет), но вот отчёт по проекту – обязательно.

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

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

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

• успех проекта;
• создание ценности;
• поставка продукта;
• синхронизация команды;
• быстрое реагирование на риски и изменения.

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

• определите аспекты, которым важно уделять внимание;
• определите состав артефактов, с помощью которых вы будете понимать, что выбранным аспектам уделяется нужное внимание;
• определите необходимое и достаточное количество событий с помощью уровней управления, на которых будут рассматриваться нужные вам артефакты.

Однако нельзя просто взять и единожды создать систему управления проектами, которая будет «жить» весь жизненный цикл вашей компании. Всё меняется и все устаревает. Как сделать так, чтобы ваша система была цельной? Продолжение ниже.

Как сделать систему управления проектами, которая развивается вместе с организацией?

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

Целостную системы мы пересматриваем не реже раза в год, убираем из неё лишнее, добавляем недостающее. Помним о связях между аспектами, артефактами и событиями.

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