Процессы управления проектами: что происходит на деле

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

Пять групп процессов

PMBOK, руководство Института управления проектами, и ГОСТ Р ИСО 21500 делят работу по управлению проектом на пять групп. В таблице — что происходит в каждой и какой след она оставляет. По следу проще всего проверить, идёт ли процесс на самом деле или только описан.

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

Группы — не этапы

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

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

Неделя проекта, на которой видны все пять

В начале 2023 года наш руководитель проекта два месяца вёл три интернет-магазина digital-агентства на «1С-Битрикс». Магазины развивались по заявкам клиентов, постоянных команд не было: разработчики и дизайнеры работали в общем пуле агентства. Неделя выглядела так.

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

Инициация здесь была одна — когда агентство передало проекты. Всё остальное повторялось каждую неделю, и за два месяца на три проекта ушёл 201 час. Предупреждение о пороге мы потом взяли в свой порядок работы: ступени 50, 75, 90 и 100% лимита и отчёт к каждому акту. С таким контролем о перерасходе узнают до того, как он случился.

Что добавляется, когда проектов несколько

Пять групп описывают один проект. Когда их пять и они делят одних людей, появляются процессы, которых в учебнике нет отдельной строкой.

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

Сами правила удобно записать регламентом, а кто на каждом шаге делает и кто отвечает — матрицей RACI.

Кто отвечает за процессы

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

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

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

Как проверить, работают ли процессы

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

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

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

Частые ошибки

Процесс описан, следа нет. Регламент говорит про еженедельный статус, а последний статус — от марта.

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

Изменения на словах. Клиент попросил «ещё одну страничку», руководитель согласился, через месяц спорят о счёте. Записанное изменение с оценкой и подписью заказчика этот спор снимает.

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

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