Как выявить дефицит компетенций в проектной команде до старта

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

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

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

Ниже разберу этот подход на условном проекте внедрения новой CRM в двенадцати филиалах. Все роли и ситуации вымышлены, пример нужен для демонстрации методики.

Почему список участников почти ничего не говорит о готовности команды

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

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

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

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

Шаг 1. Начать с критических задач

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

Для внедрения CRM список может выглядеть так:

• согласовать единые требования двенадцати филиалов;

• определить, какие процессы придётся изменить;

• перенести данные без потери критичной информации;

• подготовить руководителей филиалов к переходу;

• провести запуск и разобрать первые сбои;

• не дать участникам вернуться к старым таблицам через две недели.

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

Для каждой критической задачи нужно зафиксировать ожидаемый результат и цену ошибки. Формулировка «отвечает за коммуникацию» слишком широкая. «Добиться согласования новых правил работы директорами двенадцати филиалов до 15 октября» уже позволяет обсуждать требования к исполнителю.

Шаг 2. Описать проектные роли, а не должности

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

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

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

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

Шаг 3. Выбрать несколько критичных компетенций для каждой роли

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

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

Например, руководителю проекта внедрения CRM могут потребоваться:

• системность мышления, чтобы видеть связи между процессами, данными и решениями филиалов;

• делегирование, потому что лично контролировать все направления невозможно;

• ответственность, чтобы спорные вопросы получали владельца и срок;

• управление конфликтами, поскольку интересы центрального офиса и филиалов неизбежно разойдутся;

• работа со сложной информацией, чтобы принимать решения на неполных и противоречивых данных.

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

Порог тоже лучше описывать через поведение. «Делегирование на уровне 7 из 10» сложно обсуждать с руководителем. «Передаёт задачу вместе с результатом, полномочиями и контрольной точкой, не забирает её после первой ошибки» звучит гораздо конкретнее.

Шаг 4. Не верить одному источнику данных

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

Для каждой критической компетенции стоит собрать несколько подтверждений:

• результаты оценки;

• примеры поведения в прошлых проектах;

• наблюдения непосредственного руководителя;

• структурированное интервью по рабочим ситуациям;

• небольшую пробную задачу из будущего проекта.

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

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

Шаг 5. Собрать карту покрытия проекта

Карта покрытия связывает критические задачи, роли и людей. Для каждой задачи в ней фиксируются:

• ответственный за результат;

• компетенции, без которых задача не будет выполнена;

• подтверждения по каждой компетенции;

• основной исполнитель и возможный дублёр;

• текущий статус;

• действие, если обнаружен разрыв.

Четырёх статусов достаточно: задача покрыта, покрыта с условием, не покрыта, данных недостаточно.

«Покрыта с условием» означает, что человек справится при конкретной поддержке. Например, владелец процесса хорошо разбирается в работе филиалов, но избегает конфликтных переговоров. Задачу можно оставить за ним, если встречи с директорами будет вести руководитель проекта. Условие должно быть записано вместе с фамилией и сроком. Иначе через месяц о нём никто не вспомнит.

У карты есть неприятное свойство. Она показывает, что некоторые сильные сотрудники не подходят для назначенной роли. Разговор быстро уходит в защиту статуса: «Он десять лет в компании», «Она лучший эксперт», «Других людей всё равно нет». Ни один из этих аргументов не закрывает задачу.

Какие разрывы чаще всего путают между собой

Первый вариант очевиден: нужной компетенции в команде нет. Никто не готов вести сложные переговоры с филиалами или принимать решение при нехватке данных.

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

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

Четвёртый связан с качеством информации. В профиле стоит высокий результат, но оценка проводилась два года назад для другой должности. Формально ячейка заполнена. Использовать её как подтверждение текущей готовности рискованно.

Эти ситуации требуют разных решений. Обучение поможет только в первой и иногда во второй. Перегруженному сотруднику нужен пересмотр задач. Единственной точке отказа нужен дублёр. Устаревшим данным нужна проверка.

Что обнаружилось в проекте внедрения CRM

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

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

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

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

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

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

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

Что делать с найденным дефицитом

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

У руководителя и HR есть несколько рабочих вариантов:

• изменить распределение задач;

• собрать тандем из двух участников с дополняющими профилями;

• назначить дублёра на критический участок;

• привлечь человека из другого подразделения на ограниченный срок;

• сократить масштаб первого этапа;

• принять риск и назначить дату повторной проверки.

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

Где помогает автоматизация

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

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

Автоматический отчёт способен подсветить разрыв. Решение о перестановке людей, снижении масштаба или переносе старта останется за теми, кто отвечает за проект.

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