Аудит проектного управления

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

Оценка результативности и эффективности

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

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

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

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

Оценка результативности может проводиться как на уровне метрик (выполнение KPI, ROI, NPV), так и через опросы ключевых стейкхолдеров: насколько они удовлетворены результатами. Очень важно опрашивать не только руководство заказчика, но и конечных пользователей, считают ли они разработанное ПО хорошим и удобным. Так можно получить общую картину.

Оценка препятствий

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

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

Оценка зрелости процессов

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

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

Поэтому надо оценивать в два этапа:

1. Есть ли регламенты (с этим обычно проблем не возникает).
2. Как регламенты применяются (применение должно оставлять следы)

Хорошая практика — оценивать зрелость не в отрыве, а вместе с управляемостью. В противном случае высокий уровень зрелости может показать, что «всё описано», но будет непонятно, пользуются ли всем этим на практике.

Оценка управляемости

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

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

Диагностировать можно измеряшками. Сколько проходит от принятия решения руководством проектной группы до окончательного внедрения в жизнь.

Оценка зрелости автоматизации

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

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

С разработчиками «старой школы» внедрять подобные системы было сложно. «Я здесь, чтобы работу работать, а не карточки в таск-трекере двигать», можно было частенько услышать. С молодёжью проще, они обычно сразу стартуют с каким-то настроенным таск-трекером и добиться от неё дисциплины вполне реально.

Оценка зрелости отчетности

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

Хорошая практика — наличие интерактивных дашбордов. Чтобы они в реальном времени извлекали данные из корпоративных ИС и отображали в красивой форме. Вот к этому надо стремиться.

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

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

Оценка зрелости совещаний

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

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

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

Оценка зрелости органов управления

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

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

Оценка проектного офиса

Роль проектного офиса (PMO — Project Management Office) может варьироваться: он может быть поддерживающим, контролирующим и управляющим. Важно понять, какие функции он выполняет, насколько он влиятелен и востребован. Почитайте мою статью о ПМО.

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

Оценивать ПМО надо через анализ функций, которые на него навешаны и какие реально выполняются. Ну и насколько он фактически полезен для реализации проектов.

Оценка компетенций персонала

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

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

Оценка контроля качества процессов

Тут скорее, речь о постфакт-анализе внедрённых процессов. Должен быть механизм контроля качества внедрения процессов, иначе на эти процессы персонал может начать забивать.

Хорошая практика — аудит процессов через месяц после изменений.

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

Оценка поведенческих изменений

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

Исследуется при помощи фокус-групп, наблюдений, интервью.

Резюме

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

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