Часто бывает так, что решив подвинуть сроки проекта всего на две недели, в итоге эти две недели превращаются в два месяца, а то и полгода. Или же разрешили увеличить бюджет всего на пару сотен тысяч, но потом… проект стал бездонной бочкой с бесконтрольным расходованием средств. А по окончании квартала вышел за рамки не на 200 тысяч, а на 2 миллиона.
Если подобные ситуации повторяются из раза в раз, а проблемы из одного проекта переходят в другой в качестве «наследства», стоит задуматься. Как долго вы еще готовы нести финансовые потери? Сколько еще готовы заплатить, лишь бы «вывезти» очередной проект, который не факт, что вообще отвечает целям бизнеса и приносит нужные экономические эффекты?..
А вот другой вопрос: кто на самом деле виноват в том, что сроки проектов постоянно растягиваются и из-за этого вам приходится постоянно переплачивать? Некомпетентные сотрудники, недобросовестные подрядчики, внешние неуправляемые обстоятельства?...
Виноваты не сотрудники. Просто ваша система управления проектами не работает. Не помогает жестко контролировать сроки и предотвращать финансовые потери. Почему так происходит и что с этим делать, подробно рассказываю в этой статье.
Три причины, почему ваша система управления проектами не работает и не предотвращает финансовые потери
Ниже разберу эти причины подробнее.
Причина 1: ваша система управления – как тревожная бабушка, одевающая ребенка на улицу.
Вы когда-нибудь видели, как бабушка собирает ребенка на улицу зимой? Сначала колготки, потом штаны, потом ещё одни, потом свитер, жилетка, пуховик, сверху еще один пуховик. Вторая пара варежек. На всякий случай. И вот, стоит ребенок как настоящий космонавт. Делает шаг – и сразу падает. Потому что в таком количестве слоев из одежды двигаться практически невозможно.
А что происходит с проектами, когда вы «одеваете» их по тому же принципу – чем больше правил, тем безопаснее? Длительные согласования, сложные запутанные процедуры, протоколирование каждого чиха… А происходит известно что: все сроки летят в пропасть из-за постоянных «спотыканий». А в итоге – финансовые потери и недовольные заказчики.
Был у нас один случай во время разработки технологии управления проектами для клиента (ИТ-дочка крупной девелоперской компании). Ему было важно формализовать стадию идеи, так как часто возникали ситуации, когда невозможно было предсказать судьбу какого-либо проекта. Например, заказчик приходит в ИТ-отдел и говорит, мол, ребята, нам надо сделать такой-то проект, ок? Ребята кивают, но… Что будет дальше – неизвестно. То ли ребята сразу же начнут прорабатывать концепцию, то ли отложат в долгий ящик и забудут. Или спустя две недели, когда заказчик опять придет и спросит «Ну что?», они ответят – а у нас уже другие приоритеты, извините.
Причины, почему нашему клиенту важно было формализовать эту стадию, очевидны. Однако нужно ли это делать с каждым проектом?…
После погружения в проекты заказчика мы выяснили, что если мы надстроим эту «бюрократию» над всеми инициативами, большинство из них превратятся в… того самого несчастного ребенка, которого одела бабушка. Ведь если проект простой, понятный или типовой, а ИТ-отдел сразу может сказать, берется за него или нет, и навскидку сделать просчет, вся эта формализация не нужна. Но вот когда заказчик приходит с нетривиальным проектом, где трудно оценить объем ресурсов, эффекты, стоимость… Здесь уже нужно прорабатывать концепцию.
Использовать слишком сложную методологию там, где это не нужно, значит тормозить проекты. А торможение проектов – всегда потеря денег: чем дольше, тем дороже. Но об этом я подробнее напишу ниже.
Причина 2: ваша система управления – как неопытный молодой отец.
Забудем про тревожную бабушку и представим, что вместо нее ребенка в садик одевает молодой отец. Накинул куртку, застегнул наполовину, про шапку забыл, носки разные, варежки вообще остались дома. Вроде бы «все нормально, не замерзнешь», но через пару дней ребенок уже кашляет. А еще через пару дней лежит с температурой дома и… в садик его отпустят еще не скоро.
Если ваша технология управления слишком минималистичная, то есть, такая же, как и этот молодой отец, решивший, что «и так сойдет», проблемы и риски не заставят себя долго ждать. Итог все тот же: пока разруливаем очередной пожар, проект буксует, сроки растягиваются. Проект превращается в бездонную бочку с бесконтрольным расходованием средств. Заказчик опять негодует.
Например, для согласованной корректировки сроков часто внедряется процедура запроса на изменение. Чтобы план всегда был актуальным и можно было заранее предвидеть проблемы со сроками.
Представим ситуацию, когда руководитель проекта Петров вдруг обнаружил, что без сдвига на пару недель ну никак. А что такое – две недели? Вообще ничего. Петров чешет голову и готовит доводы для управляющего комитета. Показывает отчет и говорит – ну давайте сдвинем, заказчику норм! Управляющий комитет дает отмашку, ведь две недели – вообще ничего. Петров довольный возвращается к своим делам.
Проходит месяц. Снова Петров на управляющем комитете просит о сдвиге сроков, напоминая о данных ему двух неделях. История повторяется несколько месяцев. Проект заканчивается, но… сроки в итоге растянулись не на две недели, а на два месяца.
Что же произошло у Петрова и как ему могла помочь процедура запроса на изменение?
А произошло вот что: в отсутствии формализованного запроса на изменение ни у кого не было понимания, как сильно один сдвиг контрольной точки всего на две недели повлияет на общий срок проекта. Ведь когда что-то сдвигается, не факт, что в течение этих двух недель будет еще одна возможность выполнить те или иные работы. Ресурсов может не быть – ни людей (кто-то в командировке, высокий сезон, загрузка ключевых экспертов, конфликт с другим проектом и т.д), ни необходимой инфраструктуры. Если не успели попасть в «окно», следующий раз можно ждать не только два месяца, но и полгода.
Проблема Петрова была в том, что пропуская согласование запроса на изменение с оценкой влияния сдвига не только на сроки, но и на доступность ресурсов и в итоге на эффект проекта… он вводил управляющий комитет в заблуждение. В итоге ни у кого не было представления, к каким последствиям может привести этот небольшой сдвиг. При наличии же ясной картины решение управляющего комитета могло бы быть совсем другим.
Выводы: слишком сложная технология управления – плохо, слишком простая – тоже. И тот, и другой вариант – источник финансовых потерь и низкой маржинальности проектов.
Но есть еще и третий вариант, почему технология тоже не будет работать. И о нем я расскажу ниже.
Причина 3: когда ваши проекты выросли из «старой одежды».
Можно ли сделать технологию управления проектами из такого набора правил и инструментов, которых будет необходимо и достаточно? Чтобы она была минималистичной, но при этом покрывала ключевые риски. Чтобы она не была как тревожная бабушка или молодой отец, отправляющий ребенка зимой на улицу без варежек.
Можно, но это не значит, что так будет всегда. Через год или два ваши проекты снова превратятся в того самого ребенка, который… просто вырос из старой одежды. Рукава короткие, пуговицы не застегиваются, штаны еле натягиваются. Он вроде бы одет, но двигаться неудобно и холодно.
Что же произошло? А вот, что: если организация или внешние обстоятельства меняются, технология управления должна меняться вместе с ними. Иначе снова риски и проблемы.
Например, раньше, когда проектов было мало, для оценки бюджета хватало экспертного мнения руководителя Петрова. Методом научного тыка и в силу богатого опыта он мог прикинуть, что с учетом всех лицензий, серверов, оплаты работ подрядчиков и т.д. ему хватит 3 млн. рублей. Принес служебку с кратким описанием проекта и бюджетом к генеральному директору, получил визу и пошел делать свое дело. Однако в ходе работ заказчик неожиданно передумал: лицензия нужна не на 10 пользователей, а на 100. Стоимость, соответственно, выросла. Петров еще раз зашел к ГД, объяснил ситуацию «на пальцах» и ему увеличили бюджет.
Однако организация и количество проектов выросли. Появилась новая система финансового учета, всякие капексы и опексы… Жить как раньше уже не получится. Никакого метода научного тыка для оценки бюджета, а детальное описание каждой строки затрат. Что для лицензии ПО нужно 200 тысяч, а для работы подрядчика 300. Технология управления становится сложнее, «бюрократичнее». Теперь вписать в паспорт «от балды» 3 млн. рублей уже не вариант, приходится готовить расшифровку каждой строки.
А если вышел за рамки… объяснить все генеральному директору уже тоже не получится (теперь такие вопросы решает управляющий комитет). Потому что количество проектов выросло, и если каждый руководитель будет приходить и просить поблажку, все это к концу квартала накопится как снежный ком. Один попросил добавить 100 тысяч, другой 200, третий еще… Вот вам и выход за рамки общего бюджета компании на несколько миллионов, а то и десятки.
То есть, если раньше решение принималось в полуручном режиме, то сейчас, с ростом организации, бюджет – это один из ключевых документов проекта, необходимых для прозрачного учета финансов по всей организации. И если его внимательно не проработать, то потом, когда он неожиданно сильно вырастет… не факт, что управляющий комитет быстро даст отмашку на продолжение проекта.
Технология управления проектами – живой организм, который развивается вместе с организацией. Меняется организация – меняется и технология. Однако вопрос в том, как сделать из технологии такую цельную систему? Как сделать так, чтобы внося изменения в одном месте, менялось все остальное?
Ниже я расскажу, какой же должна быть система управления проектами, чтобы: быть минималистичной, закрывающей ключевые проблемы проектов и бизнеса, а также развивающейся вместе с организацией.
Что нужно сделать, чтобы система управления проектами была минималистичной и не тормозила проекты?
Главное правило, чтобы ваша система управления проектами не превратилась в «тревожную бабушку» с кучей лишних правил и инструментов, которые только тормозят проекты это… делать только то, что нужно, и не делать того, что не нужно.
Как понять, что нужно делать, а что нет?
На помощь приходят аспекты – области управления, которым важно уделять внимание, чтобы достигать целей как проектов, так и бизнеса. Цели и эффекты, сроки, бюджет, ресурсы, удовлетворенность заказчиков, команда и т.д. Например, в PMBoK есть 10 областей знаний (аспекты), рекомендованных для внедрения. Однако если вы хотите создать такую систему управления проектами, где не будет ничего лишнего, бюрократичного и тормозящего, на этапе выбора аспектов нужно включать здравый смысл. Потому что в зависимости от контекста вашей организации, особенностей внутренних процессов и специфики проектов обычно нужны далеко не все аспекты.
Например, зачем нам утяжелять систему управления и создавать правила для управления ресурсами, если у нас все делается выделенными командами? Или наоборот – для масштабирования организации и успеха будущих проектов важен аспект сохранения экспертизы, чтобы избежать проблем, когда кто‑то из ключевых руководителей уйдет вместе со всеми знаниями в голове. В большинстве стандартов этого аспекта нет. А еще, как-то раз, когда мы делали диагностику проектного управления в одной девелоперской компании, то выделили дополнительный аспект, которого также нет в «учебниках» – финансирование. Потому что именно процесс финансирования девелоперских проектов (которые реализовываются на заемные средства) имеет огромное влияние на успех проектов и компании в целом.
Так что, повторюсь, определяя аспекты, нужно опираться на здравый смысл и специфику организации, а не на внешние стандарты. Только так в вашей системе управления не будет ничего лишнего, тормозящего проекты и приводящего к финансовым потерям.
А еще поделюсь с вами небольшим лайфхаком, как определить важные аспекты именно в вашей организации.
Для начала определите:
критерии успеха проектов. Это может быть высокая маржинальность, новые проекты с тем же заказчиком, высокая приживаемость результатов и т. д.
критерии неуспеха проектов. Например, нарушение сроков, требований по информационной безопасности, требований к документированию, увеличение бюджета.
причины возникающих проблем. Высокая текучка, неэффективное использование ресурсов, разрастание требований на проекте и т. д.
Объедините похожие смыслы из каждого списка и попробуйте выделить ключевые аспекты. Например, если взять:
критерий успеха – приживаемость результата
критерии неуспеха, связанные с нарушением каких‑либо требований
проблему разрастания требований
Все это про аспект содержание и качество. Очевидно, что уделять внимание ему критично важно.
Когда вы определились с аспектами, остается понять, как вы собираетесь уделять им внимание? Если вам важны сроки, бюджет, содержание и качество – как именно вы будете управлять этими аспектами, чтобы проекты были успешными с нужными результатами и бизнес‑эффектами для организации?
Ниже расскажу на примере аспекта сроки, что нужно, чтобы уделять внимание всем нужным аспектам, чтобы ваша система управления проектами закрывала возможные риски.
Что нужно сделать, чтобы система управления проектами закрывала ключевые риски?
После того, как мы выбрали, чему нам нужно уделять внимание в проектах, чтобы система управления проектами не была слишком сложной, пришла пора определиться, а как именно мы это будем делать.
Как именно мы собираемся уделять внимание важным для бизнеса и проектов аспектам? Как именно мы будем понимать, что с этими аспектами все ок и, например, сроки не улетели в пропасть? Что конкретно мы будем для этого делать?
Ответ на эти вопросы – артефакты и события.
Представьте, что вы решили начать контролировать свои расходы. Но если просто себе пообещать, что «все, с понедельника я начинаю следить за ними», вряд ли вам это поможет начать экономить.
Чтобы действительно сделать то, что вы задумали, вам нужно регулярно уделять внимание этому вопросу: завести табличку в Excel или скачать приложение, ежедневно заносить данные о каждой покупке и раз в месяц анализировать их.
Уделять внимание выбранным важным аспектам – значит создавать и использовать артефакты, подтверждающие действия или результаты (отчет за неделю, выгруженный из приложения), и анализировать их в специально выделенное для этого время. Такое выделенное время мы называем событиями – например, совещания, которые проходят по определенному расписанию или с нужной регулярностью. То есть, сами по себе артефакты не несут никакой ценности. Она появляется, когда артефакты используют во время обсуждения на совещаниях для принятия нужных решений по проекту и фиксации договоренностей.
Например, нам критично важно уделять внимание аспекту сроки. В зависимости от сложности структуры организации, ее масштаба, специфики проектов и т.д. состав и содержание артефактов (доказательств результатов) может меняться. В моем методе управления проектами Парацельс ПМ я собрал набор наиболее востребованных и полезных артефактов для управления сроками, среди которых выделил обязательные и дополнительные.
Ключевые артефакты, позволяющие видеть ясную картину, что происходит со сроками на проектах:
бизнес-кейс
паспорт проекта
план проекта / фазы / релиза
протокол встречи / задачи проекта
запрос на изменение
отчет по проекту
отчет о завершении проекта
Этот набор артефактов может варьироваться – повторюсь, все зависит от масштаба организации, проектов и внутренних процессов. Далеко не всегда нужен запрос на изменение, но вот отчет по проекту – обязательно.
Как я уже писал выше, сами по себе артефакты, доказательства результатов, не имеют никакого смысла без их использования. Поэтому нам нужно определить состав и регулярность событий, на которых этих артефакты будут использоваться для принятия нужных и своевременных решений.
Чтобы определить состав и регулярность событий (встречи, совещания) в своем методе Парацельс ПМ я предлагаю для начала выбрать уровни управления. Это связано с тем, что на событиях могут рассматриваться различные по масштабу, долгосрочности и важности вопросы: некоторые из них ориентированы на более длинный горизонт – от нескольких месяцев до года, а другие на короткий горизонт – до недели или даже дня. Чем короче горизонт, тем более детальное погружение в аспект предполагается. Стендап ежедневно, управляющий комитет – раз в месяц. Но важно и то, и другое, чтобы не упускать ни краткосрочные, ни долгосрочные цели.
Поэтому прежде чем определить состав и регулярность событий, решите, какие в вашей организации существуют уровни управления. В Парацельс ПМ описан каждый уровень, но нужно выбрать те, которые релевантны именно вашей организации – какие-то могут исключаться, а какие-то объединяться. Вот основные уровни в Парацельс ПМ – от самого верхнего к самому нижнему:
успех проекта
создание ценности
поставка продукта
синхронизация команды
быстрое реагирование на риски и изменения
Понимая, какие уровни управления есть в вашей организации, можно определить состав событий и привязать к ним нужные артефакты. Это позволяет управлять важными аспектами и принимать взвешенные и своевременные решения.
Пример набора событий и артефактов из метода Парацельс ПМ для самого верхнего уровня управления «Успех проектов»:
Событие «Управляющий комитет» и артефакты: бизнес-кейс, паспорт проекта, бюджет, матрица ответственности, запрос на изменение, отчет по проекту, план, протокол встречи, план управления изменениями, отчет о завершении проекта.
Событие «Сессия целеполагания» и артефакты: бизнес-кейс, реестр требований (бэклог), реестр заинтересованных сторон.
Событие «Сессия планирования» и артефакты: бизнес-кейс, план проекта, реестр продуктов, план ресурсов, план управления изменениями, бюджет, матрица ответственности.
Событие «Кик-офф» и артефакты: паспорт, план проекта, матрица ответственности.
Событие «Архитектурный совет» и артефакт реестр продуктов.
Событие «Итоговая встреча» и артефакты: бизнес-кейс, паспорт, план, бюджет, отчет о завершении проекта.
Выводы: чтобы создать систему управления проектами, которая будет предотвращать сдвиги сроков и финансовые потери, нужно, чтобы она была минималистичной, но при этом закрывающей ключевые риски проектов и бизнеса. Для этого:
определите ключевые области управления (аспекты), которым важно уделять внимание;
определите состав артефактов, с помощью которых вы будете понимать, что выбранным аспектам уделяется нужное внимание;
определите необходимое и достаточное количество событий с помощью уровней управления, на которых будут рассматриваться нужные вам артефакты.
Однако как я уже писал выше, нельзя просто взять и единожды создать систему управлению проектами, которая будет «жить» всю жизнь. Все меняется и все устаревает. Как сделать так, чтобы ваша система была цельной? Что, изменив что-то одно, где-то не появилась брешь, приводящая к рискам и проблемам? Продолжение ниже.
Как сделать систему управления проектами, которая развивается вместе с организацией?
Система из аспектов, артефактов и событий хороша тем, что она цельная – все эти элементы связаны друг с другом. То есть, если у нас есть артефакт, значит должно быть событие, где он используется или создается. Если мы убираем артефакт, то должны проверить, а сможем ли мы без него уделять должное внимание выбранному аспекту и при этом не нарваться на риски. Например, если мы формируем календарный план проекта, то мы его используем во время обсуждения на встречах. Если его убрать, то сможем ли мы без него обсудить состояние проекта, отклонения, зависимости, текущий прогресс? Сможем ли мы уделять достаточное внимание срокам проекта?
Когда есть целостная система из взаимосвязанных элементов, то мы можем что-то убрать и добавить более релевантное потребностям организации. Но для этого нужно хотя бы раз в год пересматривать эту систему и проверять, что для вас стало более актуальным, что менее, а что и вовсе уже не нужно.
Например, вы собрали систему управления по этому методу. Однако организация стала расти, количество и сложность проектов увеличились. Если раньше вашей главной целью было добиться стабильных результатов проектов, то сейчас – масштабироваться. И вы понимаете, что без сохранения и распространения накопленного опыта компании на всех сотрудников этого сделать не получится. Вы не ломаете систему, не переделываете ее заново. А добавляете новый аспект – сохранение экспертизы. И, как я уже описывал процесс выше, продумываете артефакты и события согласно актуальным уровням управления. Меняете что-то одно – меняется остальное.
Это необходимо делать регулярно (я рекомендую пересматривать систему не реже 1 раза в год), чтобы не допустить ситуации, когда из-за каких-то отдельно устаревших правил сотрудники начали воспринимать систему управления как бюрократию.
Коллеги, если вам интереснее ознакомиться с моим методом Парацельс ПМ, переходите в мой Телеграм канал, где в одном из закрепленных постов вы сможете бесплатно скачать руководство метода. Также вы найдете в канале много полезного для себя: проверенные инструменты, лайфхаки, кейсы, личные наработки за 25 лет управления проектами и изменениями, мысли о менеджменте. А еще в канале я регулярно публикую клиентские кейсы и записи подкастов с топовыми экспертами России. Подписывайтесь!