Как адекватно оценивать руководителей проектов и почему многие это делают неправильно?

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

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

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

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

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

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

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

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

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

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

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

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

Друзья, согласны с тем, что я написал? Обсудим в комментариях?

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