Как адекватно оценить руководителей проектов?

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

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

Способ 1: сделать «выравнивание» по терминологии и инструментам и проверить, как это применяется

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

 Часто оценить компетенции через тестирование невозможно, потому что кто-то из менеджеров говорит на языке PMBoK, кто-то на ГОСТ, а кто-то опирается на терминологию внутренней проектной методологии компании. И чтобы проверить знания менеджеров, прежде всего, нужно привести их к общему знаменателю по части терминологии и инструментов: у всех язык разный, а незнание языка не равно отсутствие необходимых компетенций. 

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

Способ 2: проверить соблюдение методологии

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

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

Способ 3: оценить результативность проектов

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

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

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

Способ 4: проверить софт скиллс

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

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

Читайте наш кейс, как мы разработали проектную методологию для зрелой ИТ-компании, используя её внутренний опыт.

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