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

Поэтому когда руководство говорит «Теперь будем делать проекты по-другому, системно и правильно, вот вам новый регламент», у них возникает вопрос – а нам оно надо? Зачем нам все эти новые правила управления, как делать проекты? Почему мы должны полагаться на них, а не на свой опыт, который спасал десятки раз?

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

Почему высокой квалификации и опыта сотрудников недостаточно для успеха проектов

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

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

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

Однако такой подход, с опорой на знания «в голове», постоянно приводит к авральным ситуациям, когда сроки уже горят. Потому что каждый руководитель вывозит по 2-3 сложных проекта одновременно, а возможности хотя бы частично «разгрузиться» нет. Почему? Менее опытные сотрудники не могут сразу встать на подхвате, так как из-за сложной специфики проектов и особенностей внутренних процессов им приходится по несколько месяцев вникать в курс дел.

Но компания растет – проектов становится все больше и вместе с их количеством растет их сложность и масштаб. И управлять ими по старой схеме уже не получается. 

За решением этой проблемы ко мне и обратился генеральный директор (он же собственник) компании – помочь создать систему из единых правил управления проектами, чтобы:

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

• делать проекты с более предсказуемыми сроками и маржинальностью;

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

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

Почему нельзя просто взять и навязать новые правила игры

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

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

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

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

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

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

В 90% случаев внедряемые правила воспринимаются как бесполезная бюрократия, которую можно и нужно игнорировать. Главная причина, почему так происходит, это то, что сотрудники не понимают её ценности и эффективности (либо её не донесли, либо пользы от ее использования реально нет).

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

Новые правила и требования к управлению должны однозначно давать ответ на вопрос: а зачем мы делаем то, что мы делаем? Так что в нашем кейсе, как и во многих других, при создании каркаса методологии мы выделили ключевые области внимания (аспекты), которыми критически важно управлять как для успеха проектов, так и для достижения целей компании. В большинстве организаций к таким аспектам относятся сроки и бюджет, но в каждом конкретном случае есть свои «больные места». Например, в этом кейсе была проблема с сохранением и передачей экспертизы, из-за чего онбординг новичков мог занимать несколько месяцев. 

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

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

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

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

Третий принцип – правила управления должны опираться на имеющийся успешный опыт компании.

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

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

• собрать инструменты и практики, которые уже показали свою эффективность и хорошо работают; 

• проанализировать то, что не сработало, чтобы понять – этот инструмент или практика бесполезны на всех проектах или только на некоторых (каких именно?); 

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

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

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

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

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

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

Как это делать? Мы используем артефакты и события. Артефакт – подтверждение выполненного результата (отчет, план, след в информационной системе), а событие – любой вид встречи для обсуждения данного артефакта и принятия решений. Если мы говорим об аспекте сохранение и передача экспертизы, то уделять внимание ему важно в середине и конце проекта – сохранять итоги каждого этапа в базе знаний (артефакт), проводить ретроспективы с участием новичков (событие) и т.д. 

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

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

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

Главные мысли и выводы

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

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

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

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

Коллеги, приглашаю вас в свой телеграм канал Андрей Малахов | От проектов к изменениям, где я регулярно провожу методологические экскурсии на примере кейсов моих клиентов. Кроме этого, в канале вы найдете много полезного для себя: проверенные инструменты, лайфхаки, кейсы, личные наработки за 20+ лет управления проектами и изменениями. А еще я там рассказываю про собственные разработки: мой авторский гибридный метод управления проектами Парацельс ПМ и ИТ-инструмент ресурсного планирования. Подписывайтесь!