Как долго мы будем молчать о том, что популярные стандарты по управлению проектами не работают? Почему в организациях продолжают бездумно внедрять PMBoK и прочие «фреймворки», которые только тормозят проекты? Сколько еще вы готовы потерять времени и денег только потому, что выбрали привычный процессный подход вместо реально работающего?
Вот уже 20 лет я настраиваю системы управления проектами как в небольших компаниях, так и в крупнейших российских организациях, таких как Сибур, Новабев, Сбербанк, Hoff, Рулог и пр. Лично управлял портфелями проектами стоимостью свыше 70 млн. евро. В прошлом году моя команда разработала методологию управления программой ИТ‑трансформации в компании с годовым оборотом свыше 1 триллиона рублей. Так что, в управлении проектами меня уже ничем не удивить. Кроме одного: почему до сих пор многие компании внедряют стандарты с фокусом на процессы, которые красиво описаны, но не адаптированы к реальным проектам.
В этой статье я подробно расскажу, почему ваши проектные регламенты всего лишь бесполезная бюрократия. А также, как это исправить, чтобы начать реально управлять проектами и получать нужные результаты.
Также разберу:
почему PMBoK и другие «фреймворки» напрочь оторваны от реальности;
почему единственный способ создать работающую систему управления проектами это внедрить результатоориентированный подход; почему именно этот подход позволяет достигать нужных результатов даже в условиях высокой неопределенности;
как устроен мой метод управления проектами Парацельс ПМ с результатоориентированным подходом, который я успешно применяю во всех своих консалтинговых кейсах.
Обо всем это читайте ниже в статье.
Сколько стоит ошибка при выборе подхода в управлении проектами?
Начну с того, что технология управления (методология, фреймворк) может быть источником как выгод, так и огромных финансовых потерь. Все зависит от того, какой подход вы выберете.
Если вы допустили ошибку при выборе подхода и внедрили технологию, которая не подходит вашим проекамв, масштабу и особенностям процессов организации, вы получите:
Трудоемкость при использовании. Чтобы выполнить все процедуры, заполнить документы, все со всеми согласовать… Могут уходить недели и даже месяцы. Например, в одной организации во время диагностики проектного управления мы выяснили, что на подготовку отчетов, который примет проектный офис, у каждого руководителя уходило до 25% рабочего времени! Но даже это оказалось не самым критичным. Изучая содержание такого «вымученного» отчета, мы обнаружили, что там нет самой важной информации — данных об отклонениях по срокам. Получается, время, потраченное на его создание, было выброшено впустую.
Непокрытие ключевых рисков. Например, одним из ключевых рисков в вашей организации является некачественное документирование результатов проектов, приводящее к потере экспертизы в случае ухода ключевого сотрудника. Если в вашей методологии не заложены меры по профилактике такого риска… Восстановление потерянной информации потребует существенных затрат. А если ее восстановить не удастся, то такая потеря приведет к ущербу в десятки или даже сотни миллионов.
Высокие затраты менеджмента на управление. Если методология не позволяет предотвращать риски, то руководству организации приходится постоянно вникать, что происходит в проектах. Точечно опрашивать всех участников, разруливать пожарные ситуации. То есть, в итоге тратить свое дорогостоящее время на работу рядового руководителя проекта. А все почему? Потому что вы внедрили методологию, которая работает по принципу фар ближнего света: видно только ближайшие 30 метров, а что там дальше — неизвестно.
Негибкость и торможение проектов. Когда технология содержит огромное количество сложных форм и длительных процедур согласования, запуск каждого проекта превращается в муку. И во многих компаниях такое торможение может длиться по несколько месяцев, а то и лет. И тут уже делайте выводы сами: во сколько вам обходится каждая неделя откладывания запуска важного, стратегического проекта?
А еще есть и другие потери. Не так давно я видел живой пример, как компания потеряла на разработке корпоративной ИТ‑системы десятки миллионов рублей. Как так вышло? Внедрили готовое «коробочное» решение, которое не отвечает критическим требованиям. В итоге компания отказалась от системы вовсе. А все потому, что требования к системе собирались по изначально «кривой» методологии, не покрывающей ключевые риски.
Кроме неудачи с дорогостоящими ИТ‑инструментами, вы также можете понести убытки в результате внедрения методологии. Поддержка сотрудников при переходе на новые процессы, сбор обратной связи, инструктажи и тренинги, преодоление сопротивления и т. д. — все это время и нервы руководства и ключевых сотрудников. И если вы внедряете неработающую методологию, считайте, что инвестиции, вложенные в ее внедрение, потрачены впустую.
Так что, ошибка при выборе технологии управления проектами может быть очень дорогой: в виде неуспешных проектов, высоких трудозатрат, потери времени руководства, длительности процедур и дорогостоящих бесполезных инструментов.
Откуда берутся эти ошибки? Почему технология управления так часто превращается в источник огромных финансовых потерь? Причем, даже без осознания, что их причина именно в ней?
Потому что вы выбираете процессный подход, вместо результатоориентированного.
Почему процессный подход в управлении проектами это худший выбор для организации и безнадежно устаревшая конструкция, которую невозможно адаптировать к реальности, поясню ниже на примере известных стандартов.
Что такое процессный подход в управлении проектами и почему его нельзя внедрять, если вы хотите получать нужные результаты в нужные сроки
Что такое процесс? Это линейная последовательность шагов. Простой бытовой пример: человек проснулся, встал с кровати, выключил будильник, оделся, поставил чайник. Ежедневный процесс, который состоит из предсказуемых действий. В управлении проектами к таким процессам можно отнести выполнение рутинных действий — например, процедуру согласования документов, которая состоит в основном из последовательных шагов.
И хотя предсказать шаги отдельных процедур мы можем, но чего мы точно не можем, так это выстроить систему из предсказуемых действий для управления проектом в целом. Почему?
Если рутинный линейный процесс можно назвать процессом здорового человека, то управление проектами — это процесс курильщика, где есть цикличность действий, параллельное прохождение шагов, пропуск шагов, а также добавление новых, внеплановых шагов и т. д. И вот именно здесь и начинаются сложности с применением популярных стандартов — все они представлены в виде описания процессов: сделай А, сделай Б и придешь в точку С (но чаще в Ж).
Разберем PMBoK – схему управления рисками:
Схема разбита на несколько процессов: планирование, идентификация и качественный анализ. Однако внутри этих процессов мы видим набор инструментов и практик, который не дает ни малейшего представления, как именно их нужно применять. Нужно ли их применять все или выборочно в зависимости от специфики конкретного проекта? В каком порядке? В какой момент времени? Как их комбинировать? Здесь нет ответа ни на один из этих вопросов. Получается, руководитель проекта должен взять этот стандарт и как‑то сам решить, что он из этого берет, а что нет. А в итоге приходим либо к большому количеству ненужны инструментов, что тормозит проекты и делает процессы трудоемкими, либо к игнорированию критичных рисков. И в том, и другом случае финансовые потери неизбежны.
PMBoK хорош также, как хорош строительный магазин Леруа Мерлен — тут есть все. Но если вы хотите построить дом своей мечты, вряд ли вы будете покупать все, что есть, или же покупать что‑либо «вслепую». Вам нужен набор конкретных инструментов и материалов с точной инструкцией, как и когда их нужно применять, чтобы построить качественный и красивый дом.
Теперь возьмем другой стандарт – Prince2
На мой взгляд, он чуть конкретнее, но все равно сильно оторван от реальности.
Рассмотрим такой процесс, как обновление проектного плана:
Из плюсов предлагаемого подхода — здесь мы хотя бы понимаем, какие артефакты (результаты) должны быть на выходе: план проекта, реестр рисков, реестр открытых вопросов. Однако что и в какой последовательности нужно делать также непонятно.
Однако по сравнению с PMBoK, который делает упор на описание процессов, в Prince2 все же есть грубая структура в виде унифицированного жизненного цикла: инициация, планирование, реализация и завершение. И для каждой фазы здесь определены процессы с описанием инструментов, как на схеме выше. Грубо говоря, если PMBoK это как Леруа Мерлен, где есть миллион инструментов и материалов на выбор… То Prince2 это как тот же магазин, но уже со специальными отделами под каждый этап строительства: вот здесь все для закладки фундамента, здесь для возведения коробки, а здесь для чистового ремонта.
Но никакой инструкции, что, кому, как и когда нужно делать здесь, само собой, тоже не прилагается.
Ну и напоследок разберем еще один популярный в России «фреймворк» P3Express
Возьмем описание процесса по планированию цикла:
Вот тут уже не просто набор действий, а вроде бы понятная последовательность шагов. Однако есть нюансы.
Давайте приземлим данный процесс планирования на практику и представим, что у нас идет не первый, а уже n‑ый цикл планирования. Главный вопрос: сможем ли мы обновить и детализировать планы до того, как проведем ежемесячное ревью со всеми выводами и корректировками? Точно нет.
Другой вопрос: можем ли мы принять решение остановить проект (шаг Go/No‑Go) без какого‑либо обоснования? То есть просто взять и сказать — проект дальше не идет. Тоже нет. Этому шагу должны предшествовать другие шаги, которые включают подготовку обоснования, почему проект нужно остановить. Здесь этого также нет.
А что насчет шага «Провести стартовую встречу»? Когда именно ее нужно проводить и можно ли ее совместить с ежемесячным ревью, чтобы сэкономить время? Ответа на этот вопрос не найти.
И хотя создатели фреймворка решили определить последовательные шаги для каждого процесса, следовать им в реальности невозможно. Точнее, можно, но если проект максимально простой и делается выделенной командой. То есть, для приготовления пюре — ок, но если нужно приготовить сложное блюдо мишленовского уровня — ничего не получится. А ведь технология управления проектами нужна именно для таких «блюд».
Да, когда читаешь все эти стандарты, не возникает никакого сопротивления — все по делу, все инструменты толковые. Я не говорю, что все это бесполезно. Полезно для понимания ассортимента инструментов, теоретической последовательности шагов, но не для создания работающей технологии управления. Потому что фундамент реального управления проектами это, в первую очередь, создание ясной картины всего происходящего на проектах для всех участников. А ясность это понимание, что, кому и когда нужно делать, чтобы минимизировать риски и добиваться нужных результатов в нужные сроки.
Как же добиться этой ясности?
Только с помощью доказательств реальных действий. Доказательств того, что:
руководителем проекта назначили именно того, кого нужно, с необходимой квалификацией; его назначили именно так, как нужно — с достаточными полномочиями и закреплением ответственности;
цель проекта, от которой зависит требования к результату и объем работ, внезапно не поменяется; что она железно согласована с нужными стейкхолдерами и зафиксирована в нужном виде;
команда проекта сформирована таким образом, что каждый участник четко понимает, какая ответственность за ним закреплена и каких результатов от него ожидают в каждой значимой точке проекта и т,д.
Так что, главный вопрос, который нужно задать, это не «Какие шаги нам нужно пройти?», а «Как быть уверенными, что то, что должно быть сделано, реально сделано?». Или, как говорил главный герой фильма «Красная жара» — какие ваши доказательства?
Если у нас есть доказательство в виде документа об официальном назначении руководителя проекта нужной квалификации, мы понимаем, что все сделано как надо и важный проект передан в руки опытного спеца. А если этого доказательства нет, то… Ну что ж. Тут результаты проекта, которые напрямую зависят от квалификации руководителя, можно будет спрогнозировать с такой же точностью, как и результаты игры в русскую рулетку.
Так что, чтобы быть уверенными, что все делается как надо, необходимо создать систему, опирающуюся на доказательства нужных действий.
И ниже я расскажу, как это сделать. А именно: поделюсь идеологией своего метода управления проектами Парацельс ПМ с результаториентированным подходом.
Что такое результатоориентированный подход. Почему это единственный способ управлять проектами на практике, а не в теории, и получать предсказуемые результаты
Когда‑то я работал с заказчиками в своей консалтинговой практике, используя те стандарты и фреймворки, что есть на рынке — как международные, так и российские. Однако часто мне приходилось сталкиваться с ситуациями, когда система управления проектами, построенная на базе этих стандартов, практически не работает (в начале статьи я уже описал, почему).
Идея создать Парацельс ПМ пришла мне в голову в 2018 году в связи с моим интересом к гибридным методам управления и попыткой сделать компактный, целостный и практичный метод. Спустя семь лет и опробирования Парацельс ПМ на всех моих клиентских проектах, я понял, что получилось именно то, что нужно — метод управления проектами с результатоориентированным подходом. При этом я не изобретал каких‑то новых инструментов. Но взял все лучшее и проверенное, собрав метод Парацельс ПМ, который легко приземлить на практику.
Главная выгода метода: с его помощью можно всего за месяц собрать собственную технологию управления, которая:
дает ясную картину всего происходящего в проектах, благодаря чему можно с максимальной точностью прогнозировать результаты и заранее выявлять и устранять возможные угрозы;
закрывает важные потребности организации и решает конкретные проблемы;
легко встраивается в днк организации и учитывает имеющийся опыт, что позволяет быстро внедрить и преодолеть сопротивление.
Самое главное, если вы создаете свою технологию управления на базе этого метода, вы можете реально проверить, что все делается так, как нужно делать. Либо же использовать готовое решение Парацельс ПМ с минимальной адаптацией под себя.
Ниже вкратце опишу, из чего он состоит.
Парацельс ПМ – фундамент работающей технологии управления проектами
Определение аспектов управления — первое, с чего мы начинаем сборку своей технологии по Парацельс ПМ. Это то, о чем нужно договориться как на уровне менеджмента, так и на уровне исполнителей — чему нам реально важно уделять внимание, чтобы достигать целей как проектов, так и организации? Нужно выбрать только то, что действительно важно, потому что уделять достаточное внимание всем аспектам невозможно.
Вот в PMBoK есть 10 областей знаний, но в зависимости от специфики организации и ее проектов обычно нужны далеко не все. Например, зачем нам утяжелять методологию и создавать правила для управления ресурсами, если у нас все делается выделенными командами? Или наоборот — для организации и успеха будущих проектов важен аспект сохранения экспертизы, чтобы избежать проблем, когда кто‑то из ключевых руководителей уйдет вместе со всеми знаниями в голове. В большинстве стандартов этого аспекта нет. Так что, определяя аспекты, нужно опираться, в первую очередь, на здравый смысл и специфику организации, а не на внешние стандарты.
Как понять, что действительно важно? В методе Парацельс ПМ у нас есть набор аспектов, которые чаще всего важны. И тут нужно понять, что из этого набора важно именно в вашей организации и нужно ли добавить свои уникальные аспекты.
Ниже поделюсь небольшим лайфхаком, как определить важные аспекты.
Для начала определите:
критерии успеха проектов. Это может быть высокая маржинальность, новые проекты с тем же заказчиком, высокая приживаемость результатов и т. д.
критерии неуспеха проектов. Например, нарушение сроков, требований по информационной безопасности, требований к документированию, увеличение бюджета.
причины возникающих проблем. Высокая текучка, неэффективное использование ресурсов, разрастание требований на проекте и т. д.
Объедините похожие смыслы из каждого списка и попробуйте выделить ключевые аспекты. Например, если взять:
критерий успеха — приживаемость результата
критерии неуспеха, связанные с нарушением каких‑либо требований
проблему разрастание требований
Все это про аспект содержание и качество. Очевидно, что уделять внимание ему критично важно.
Когда вы определились с аспектами, остается понять, как вы собираетесь уделять им внимание? Если вам важны сроки, бюджет, содержание и качество, сохранение экспертизы — как именно вы будете управлять этими аспектами, чтобы проекты были успешными с нужными результатами и бизнес‑эффектами для организации?
Ниже расскажу, почему аретефакты и события — главные инструменты, чтобы уделять внимание выбранным аспектам.
Где ваши доказательства? Артефакты и события
Приведу простой бытовой пример. Представьте, что вы решили начать контролировать свои расходы. Но если просто себе пообещать, что «все, с понедельника я начинаю следить за ним», вряд ли вам это поможет начать экономить.
Чтобы действительно сделать то, что вы задумали, вам нужно регулярно уделять внимание этому вопросу: завести табличку в Excel или скачать приложение, ежедневно заносить данные о каждой покупке и раз в МЕСЯЦ анализировать их.
Уделять внимание — значит создавать и использовать артефакты, подтверждающие действия или результаты (отчет за неделю, выгруженный из приложения), и анализировать их в специально выделенное для этого время. Такое выделенное время мы называем событиями — например, совещания, которые проходят по определенному расписанию или с нужной регулярностью. То есть, сами по себе артефакты не несут никакой ценности. Она появляется, когда артефакты используют во время обсуждения на совещаниях для принятия нужных решений по проекту и фиксации договоренностей.
То, в каком виде представлен артефакт для обсуждения, также имеет большое значение — если отчет по проекту наглядный и удобный и сразу дает понимание, какие есть отклонения и в чем их причина, то решения принимаются быстро и точно. А если нужно тратить время, чтобы докопаться до сути отчета… Форму этого артефакта точно нужно менять.
Так что, основными инструментами, которые позволяют управлять важными для организации и проектов аспектами, это артефакты (доказательства) и события.
Но это, конечно, не все.
Как я уже писал ранее, любой метод или технология должны давать четкий ответ на следующие вопросы:
зачем мы это делаем?
кто делает?
что делает?
как делает?
когда делает?
И если аспекты отвечают на вопрос «Зачем мы это делаем?», а артефакты и события на вопрос «Что мы делаем для получения нужного результата?», то:
на вопрос «Кто делает?» отвечают назначенные роли и закрепленная ответственность;
на вопрос «Когда делает?» отвечает жизненный цикл проекта, к которому привязаны артефакты и события;
на вопрос «Как делаем?» отвечают шаблоны и инструкции по подготовке артефактов и событий, где реально описать последовательность шагов.
Если мы знаем ответ на каждый из этих вопросов и можем проверить в любой точке жизненного цикла проекта, действительно ли все делается правильно (что надо, кем надо, как надо и когда надо), то все, что остается, это упаковать ответы на эти вопросы в правила, а правила в регламент.
Этот метод — единственный способ сделать управление максимально понятным. А когда у вас есть четкое понимание, как именно вы приходите к нужному результату, у вас есть ясность, что происходит в любой момент времени, А значит, есть возможность предпринимать нужные и своевременные действия, чтобы заранее устранять возможные проблемы.
Прозрачность‑предсказуемость‑результат — только в такой связке и никак иначе.
Ещё советую почитать эту статью, где я рассказываю про создание кастомной технологии с опорой на уже имеющийся опыт организации.
Подписывайтесь на мой Телеграм канал Андрей Малахов | От проектов к изменениям, где я делюсь проверенными инструментами управления проектами и изменениями, мыслями о менеджменте и полезными гайдами. Также в канале я регулярно публикую клиентские кейсы, записи подкастов с топовыми экспертами России и свои авторские наработки. А в ближайшее время проведу вебинар, на котором подробно расскажу, как легко внедрить Парацельс ПМ в вашу организацию.
