
Как-то раз ко мне пришла крупная инвестиционная компания с запросом на оценку компетенций проектного персонала. Чтобы провести отсев и попрощаться с теми, кто только тормозит работу. А тем, кто не так уж и плох… Подсветить зоны роста, отправить на обучение и т.д. Дать шанс на исправление.
Несмотря на то, что у меня большой опыт в обучении сотрудников управлению проектами… Я отказался это делать. И не потому что мне не хотелось помочь клиенту. А потому что я понимал, что результаты такой оценки будут для него бесполезными – то есть, не отражающими реальное положение дел.
В этой статье я расскажу, почему нельзя просто взять и оценить компетенции руководителей проектов. А также поделюсь четырьмя методами адекватной оценки, которая реально покажет, кто у вас самое слабое звено.
Четыре кита адекватной оценки проектного персонала
1️⃣ Выровнять терминологию и инструменты
Если вы решили провести оценку, первое, с чего нужно начать, – убедиться, что все ваши сотрудники используют единую терминологию и умеют применять стандартные инструменты. Например, декомпозировать план проекта на продукты, а дальше преобразовывать продукты в контрольные точки, календарные планы и т.д.
Часто оценить компетенции просто через тестирование невозможно, потому что кто-то говорит на языке PMBoK, кто-то на ГОСТ, а кто-то опирается на терминологию внутренней проектной методологии компании.
Так что, чтобы проверить реальные знания сотрудников, прежде всего, нужно привести их к общему знаменателю по части терминологии и инструментов: ведь у всех язык разный, а незнание языка не равно отсутствие необходимых компетенций. И только после этого «выравнивания», например, с помощью базового обучения, можно либо дать домашнее задание и проверить его, либо… Посмотреть, как ваши сотрудники применяют те или иные инструменты проектного управления на практике. И только после этого оценить, насколько они компетентны.
2️⃣ Проверить соблюдение внутреннего стандарта управления проектами
Понятно, что не всегда в компании есть полноценный стандарт или его описание. А еще он может быть устаревшим и уже не работающим, излишне бюрократичным или наоборот – представленным в виде отдельных шаблонов и правил. Однако нужно выбрать те инструменты, требования и правила, которые считаются важными для реализации проектов в компании. И проверить проекты ваших менеджеров на «вшивость» – то есть, соответствие этим правилам.
Конечно, если некоторые правила не доносились как требования, то часто даже самые компетентные менеджеры могут такие правила обходить и не выполнять. В этом случае после оценки перед сотрудником ставится задача устранить найденные замечания. И если по истечении согласованного времени они не были устранены… То это уже красный флаг.
3️⃣ Оценить результативность проектов
Нет никакого смысла оценивать компетентность тех менеджеров, которые неуспешно управляют проектами. Поэтому оценивайте реальные результаты: достижение целей, выполнение бюджета, сроков, удовлетворенность заказчиков и т.д. Оценивать можно и в конце проекта, и по этапам, и в произвольный момент – например, в середине. Здесь можно применить метод оценки 360: отрейтинговать руководителей проектов и, как это делают в некоторых компаниях, 10% самых некомпетентных уволить. А также внедрить систему мотивации в привязке к результату.
При этом нужно быть аккуратными, поскольку неуспешность проектов не всегда связана с компетенциями конкретных сотрудников и требует исследования причин. Например, если руководитель принял «неблагополучный» проект у другого сотрудника, здесь нужно оценивать не успех проекта, а влияние менеджера на результаты после его назначения. То есть неуспех проекта не всегда равен эффективности конкретного менеджера, если у него было несколько предшественников или внешние неуправляемые им факторы.
Тем не менее, для сотрудников, которые давно работают в компании, оценка по результатам вполне работает.
4️⃣ Оценить софт скиллс
Это проверка на умение анализировать и презентовать информацию, решать конфликты, вести убеждающие диалоги и переговоры. И проверяются такие навыки не проектной оценкой: есть управленческие ассесмент центры и деловые игры, которых вполне достаточно. К слову, проверку софт скиллс больше рекомендуется проводить для новичков, а для тех, кто уже успешно показал себя в работе (и в результативности, и в соблюдении методологии), такая оценка часто будет лишней.
Что в итоге?
Чтобы проверить компетенции вашего проектного персонала, по своему опыту я не рекомендую прибегать к классическому проектному ассесменту с вопросами и кейсами. Придерживайтесь вышеописанных четырех методов, чтобы провести адекватную оценку и оставить в компании самых компетентных руководителей.
Добавлю еще, что знание публичных фреймворков (Prince2, Scrum и т.д.) не равно эффективности работы сотрудников, так как это всего лишь набор практик и правил, исчерпывающее знание которых не влияет на успешность проектов. Потому что в реальной работе использование фреймворков зависит от контекста организации и важно не досконально знать теорию, а анализировать и применять наиболее полезные инструменты именно там, где они нужны.
Подписывайтесь на мой Телеграм канал Андрей Малахов | От проектов к изменениям, где я делюсь проверенными инструментами управления проектами и изменениями, мыслями о менеджменте и полезными гайдами. Также в канале я регулярно публикую клиентские кейсы, записи подкастов с топовыми экспертами России и свои авторские наработки. Много полезного и интересного!
Комментарии (16)
K0styan
11.09.2025 13:43Грубая оценка софтов может быть интегрирована в 360. Если со всех сторон на человека идут комментарии, что с ним не договориться или его не понять - уже звоночек.
PMLogix Автор
11.09.2025 13:43Да, полностью согласен. Можно задать вопросы типа:
Насколько РП был конструктивен и предлагал конкретные решения?
Насколько РП проявлял инициативу и проактивность?
Насколько РП учитывал ожидания заказчика и других стейкхолдеров?
Насколько РП помогал команде выполнять свою работу? и т.д.
Беда в том, что всего вопросов в 360 оценке должно быть минимум, ну и быть уверенным, что опросили всех кого нужно не так просто.
Oeaoo
11.09.2025 13:43Вот это тема сложная. Оно-то вроде бы и так, но. Часто, в компаниях большинство в упор не видит проблем. И на тех самых 360 они или не могут или не хотят давать негативный фидбэк на кого-то. Помните, мы живем во времена "токсичной позитивности". Вот это одна из ее отвратительных изнанок. Вы получаете смазанный симптом, где объективно (статистически) все не так, как на самом деле. Я в этих случаях рекомендую использовать контакты со зрелыми и доверенными коллегами внутри системы отношений, кто может понимать происходящее изнутри, руководствуясь собственным разумом и опытом, а не эмоциями или выгодами, и кто не боится указать на проблемы внутри системы. Или вообще привлекать внешних консультантов. Иногда, ошибки нужно признать еще на уровне найма или последующего управления, результатом которых стали проблемы с как-бы "неправильным сотрудником", который может быть лишь индикатором более глубоких проблем. Разматывать причины - так же непросто как и брать ответственность за последствия бездарного управления.
PMLogix Автор
11.09.2025 13:43Я помню, как-то мне делалали в банке 360 (я был руководителем проектного офиса, начальником управления), пару месяцев обрабатывали, но я уволился, так и не дождался результатов.
GordonFreemann
11.09.2025 13:43Не увидел способность правильно делегировать задания, распределяй и властвуй
PMLogix Автор
11.09.2025 13:43Способность делегировать можно проверить через оценку 360 или через качество планирования и проведения встреч на проекте, хоть и косвенно.
Mari_Cool
11.09.2025 13:43Очень откликнулось про необходимость "выравнивания" терминологии перед оценкой. Мы у себя столкнулись с тем, что даже внутри одной компании сотрудники по-разному понимают одни и те же термины. В итоге мы сначала провели короткий курс через моякоманда, чтобы дать общий язык проектному персоналу. И только после этого оценка компетенций стала более объективной. А до этого результаты сильно плавали, и оценка была вообще не объективной.
PMLogix Автор
11.09.2025 13:43Спасибо, в точку! Помню как то я наблар 4 из 10 баллов в тесте по УП для обычных специалистов, имея сданный PMP и более чем 10 летний опыт работы РП и РПО за спиной.
Терминология имеет значение!
FrankNStein
11.09.2025 13:43Если руководитель не способен оценить эффективность работы своих прямых подчиненных, значит, начать увольнения нужно с этого руководителя.
PMLogix Автор
11.09.2025 13:43Я не думаю, что есть такие руководители. Тем не менее, руководитель чаще всего не может объективно и всесторонне оценить компетенции сотрудника, его навыки взаимодействия с различными стейкхолдерами внутри организации, соблюдение методологии управления проектами просто так "на глазок".
Pabloritas
11.09.2025 13:43Совершенно упущены факторы "это стратегический проект и мы должны его реализовать вотчтотбы то ни стало" и"это стратегический партнер, мы не можем себе позволить... " не раз наблюдал и даже участвовал в таких проектах и оценка показателей тут не работает. Оценка обратной связи тоже не роляет если заказчик в роли "я начальник, а все дураки"
Очень верно про терминологию, но явно не до конца сама тема со стандартизацией. Нужно для начала привести к общему знаменателю подходы к принятию проектов и проектных решений, т.е. если проект инициируется из разных точек, то зачастую это будет означать разность подходов к реализации и целям, при возможной идентичности по остальным параметрам.
Кроме того важно отладить околопроектные процессы, которые в разных компаниях разные, но тем не менее, если пул ресурсов для рядя проектов один, а послестаровая приоритезация создает дефициты приводящие к срывам сроков, бюджетным дефицитам и увеличению управленческо-бюрокартической нагрузки, то сравнения тут будут очень осложнены.
PMLogix Автор
11.09.2025 13:43Вы любых правилах есть исключения. Не понял в чем сотоит ваше предложение? Что оценку в принципе нельзя провести?
Oeaoo
Мой опыт говорит, что внешние критерии не выявляют скрытые разрушительные процессы. Именно вшивая категория сотрудников выстраивает множество линий обороны и "выглаживает воротничек" как можно лучше всех.
PMLogix Автор
Да, но уши то торчат все равно. Самый большой вред не от злого умысла, а от примитивного разгильдяйства и недальновидности.