Нужны ли KPI по качеству управления ИТ-проектом для руководителя и команды?24.03.2025 16:01

Мы привыкли, что каждый ИТ-проект имеет конкретные ожидания и KPI. Корректно сформулированные показатели отлично подходят для мониторинга прогресса, статуса, эффективности и оценки успешности проекта. В крупных компаниях с развитой системой проектного управления мониторинг и контроль таких показателей автоматизированы — здоровье всех проектов можно проверить, взглянув на экран монитора. Однако реализация проектов без команды и руководителя невозможна.

Меня заинтересовала тема индивидуальных KPI, которые устанавливаются для руководителей ИТ-проектов и членов команд. По личному опыту управления проектами могу сказать, что чаще всего такие KPI связаны исключительно с результатами самого проекта, дублируют его календарный план, привязаны к конкретным показателям бюджета или к финансовым результатам. На первый взгляд это звучит разумно, но есть нюанс. Сегодня поговорим про KPI, связанные с качеством проектного управления. 

Дисклеймер.
Статья не является научным исследованием, выражает личное мнение автора. Требует погружения и знаний в области методологии проектного управления. Статья актуальна для руководителей ИТ-проектов и участников проектной деятельности крупных IT- и Fintech-компаний, в которых приняты стандарты разработки ПО и внедрены системами управления ИТ-проектами. Под проектами в статье подразумевается проектные активности с бюджетом от 20 млн руб. и трудозатратами от 1000 чел./дней. Статья находится вне зоны интересов участников стартапов, небольших частных инициатив, компаний реализующих проекты без стандартов проектного управления, фриланса или pet-проектов. Автор призывает с должной осторожностью внедрять и устанавливать любые KPI в проектной деятельности.

Примеры из жизни

Пример 1. Сразу приведу пример из практики. Я проводил аудит реализованного ИТ-проекта и узнал следующее. Команда создавала новый банковский продукт, его MVP, формировала необходимую функциональную обвязку, дорабатывала ИТ-системы и выводила новый продукт на рынок. С точки зрения выполненных работ всё получилось: продукт готов и доступен клиенту, системы доработаны, техдолг минимален, бюджет и сроки соблюдены, поддержка продукта и процессов налажена. Но есть нюанс. Продукт, вопреки исследованиям маркетологов и прогнозам владельца продукта и руководства, не «взлетел». Высокого отклика от клиентов нет, спрос ниже ожиданий, цели проекта по продажам не выполнены, финансовая модель рушится, и проект становится неокупаемым.

Вопросы. Следует ли в данном случае признать проект и работу команды неуспешными? Имеет ли смысл дополнительно оценить работу руководителя проекта и членов команды с точки зрения их функций, а не только результатов проекта? Какую систему оценки использовать?

Пример 2. Еще один пример. Ко мне обратилась часть команды ИТ-проекта с просьбой перейти на другую активность. Команда работала над продолжением ранее успешно реализованного проекта, который был закрыт несколько месяцев назад и достиг всех финансовых целей. Новый проект хорошо продвигался, были отличные промежуточные результаты, и руководство компании сделало на него большие ставки. Из неприятного: проект имеет ряд небольших отклонений технического характера — затянули с утверждением архитектуры, пропустили несколько контрольных точек с бюрократическими задачами по документации. С удивлением выяснилось, что есть проблемы в атмосфере внутри проекта. Часть команды имела существенные разногласия с руководителем проекта в вопросах организации работ, соблюдения внутренних требований компании и графиков работы. Разногласия тянулись еще с прошлого, успешного проекта. Дополнительно выяснилось, что смежные команды связанных проектов также имеют вопросы и претензии к управлению новым и уже реализованным проектом.

Вопросы. Можно ли признать работу руководителя проекта и команды успешной? Перекрывает ли финансовый успех проекта низкий уровень удовлетворенности команды от взаимодействия с руководителем проекта? Следует ли вообще обращать на это внимание?

О чем говорит теория

Все известные мне стандарты проектного управления сходятся в одном: руководитель проекта — лицо, ответственное в первую очередь за результаты проекта. При этом любой стандарт (в т.ч. ГОСТ Р 54869–2011) содержит требования к качеству управления проектами, которые заключаются в конкретных требованиях к процессам управления и проектной документации. Более подробно тема раскрыта в разделе №7 «Критерии успешности проекта» НТК 3.0. Требования предполагают не только оценку успешности самого проекта, но и оценку компетенции руководителя и команды проекта через оценку качества управления этим проектом.

Критерии успешности проекта — совокупность показателей, которые дают возможность судить о степени успешности выполнения проекта.

Критерии успешности управления проектом — показатели эффективности управления проектом.

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

НТК 3.0

PMBOK более скромен в этом вопросе. Со свойственным ему рекомендательным подходом он говорит о том, что использование инструментов, методов и процессов проектного управления — это «хорошая», но необязательная во всех случаях практика. В зависимости от ситуации и специфики проекта команда управления проектом самостоятельно определяет применимость и целесообразность использования навыков, методов и инструментов проектного управления. При этом PMBOK уточняет высокие требования к Hard и Soft Skills проектного менеджера, которые могут предполагать наличие соответствующих индивидуальных KPI.

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

1. Знания. Это относится к тому, что менеджер знает об управлении проектами

2. Результативность. Это относится к тому, что менеджер способен сделать или достичь, применяя знания об управлении проектами.

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

PMBOK

О чем говорит практика

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

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

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

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

Что будет, если добавить KPI. Плюсы и минусы

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

1. Руководитель проекта и все участники четко понимают, какие установлены требования к качеству управления конкретным проектом и что от них ожидают.

2. Методы и инструменты оценки качества управления проектом прозрачны и понятны, оговорены заранее.

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

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

В теории все звучит замечательно: установили KPI — и готово. На деле не все так просто, есть моменты, которые следует учитывать. Вот минусы:

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

2. Для установки KPI по управлению проектами потребуется развитая система проектного менеджмента внутри компании: нужны утвержденные процессы, стандарты и шаблоны проектного управления.

3. Для мониторинга, контроля и оценки выполнения KPI потребуются ресурсы и системы учета результатов.

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

Поэтому, обратите внимание, что процесс внедрение KPI по качеству управления ИТ-проектами требует детального предварительного анализа и проработанного плана для старта.

Перечень KPI по качеству управления ИТ-проектом

Если все нюансы и аспекты учтены и есть уверенность, что установка KPI по управлению проектами уместна и принесет пользу компании, то можно перейти непосредственно к перечню самих показателей.

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

KPI для руководителя проектов (PM):

• Цели и задачи проекта определены, сформулированы по SMART, утверждены и актуальны на всем сроке реализации.

• Объем проекта и ожидаемые результаты определены, утверждены и актуальны на всем сроке реализации.

• График реализации проекта, ресурсы, бюджет и закупки определены, утверждены и актуальны на всем сроке реализации.

• Ключевые роли, распределение ответственности внутри проекта (RACI), а также риски проекта определены, утверждены и актуальны на всем сроке реализации.

• Изменения внутренних и внешних факторов интегрированы в проект на всем сроке реализации.

• По итогам реализации проекта подготовлены и своевременно утверждены закрывающие документы.

• Уровень удовлетворенности команды от взаимодействия с руководителем проекта выше Х%.

• Уровень удовлетворенности заказчиков проекта от взаимодействия с руководителем проекта выше Х%.

• Уровень удовлетворенности связанных проектов и функциональных подразделений от взаимодействия с руководителем проекта выше Х%.

KPI для администратора проекта (PA):

• Все регулярные собрания и церемонии проекта запланированы, организованы и проведены в установленные сроки.

• Все запросы на командировки оформлены, а закрывающие документы по ним сформированы в установленные сроки.

• Внешние и внутренние коммуникации организованы, проведены и задокументированы.

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

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

• Уровень удовлетворенности команды от взаимодействия с администратором проекта выше Х%.

• Уровень удовлетворенности руководителя проекта от взаимодействия с администратором проекта выше Х%.

• Уровень удовлетворенности связанных проектов и функциональных подразделений от взаимодействия с администратором проекта выше Х%.

KPI для координатора проекта (PMO):

• График реализации проекта поддерживается в актуальном состоянии на всем сроке реализации.

• Все документы и отчеты о статусе проекта подготовлены в соответствии с календарным планом.

• Работы по проекту синхронизированы с другими проектами и инициативами портфеля проектов и программ.

• Используемые инструменты (шаблоны, фреймворки, ИС) проектного управления применяются корректно и эффективно на всем сроке реализации.

• Запросы проекта на разрешение сложных ситуаций и устранение шоу-стопперов исполняются в течение 48 часов после поступления запроса.

• Все извлеченные уроки из проекта добавляются в общую базу знаний PMO и учитываются при реализации других проектов.

• Уровень удовлетворенности руководителей проектов и их команд от взаимодействия с координатором проекта выше Х%.

• Уровень удовлетворенности заказчиков проекта от взаимодействия с координатором проекта выше Х%.

• Уровень удовлетворенности связанных проектов и функциональных подразделений от взаимодействия с координатором проекта выше Х%.

Вывод

Считаю, что вопрос внедрения KPI по качеству управления ИТ-проектами должен решаться индивидуально для каждой компании с учётом особенностей используемых инструментов и сложившейся культуры проектного управления. В крупных IT- и FinTech-компаниях с развитыми стандартами разработки ПО и системами управления проектами наличие таких показателей у участников проектной деятельности представляется целесообразным. Внедрение KPI может выступать катализатором развития культуры проектного управления, а также инструментом оценки и мотивации проектных команд. При этом для успешного внедрения показателей потребуется соответствующая инфраструктура и ресурсы. Данный подход следует применять с осторожностью: он требует детального предварительного анализа процессов и тщательно проработанного плана реализации.