Попробуйте в компании, где проектов больше десятка, свести все статусы в одну таблицу. Обычно выясняется, что сводить нечего. У одного руководителя «в работе» значит «приступили», у другого — «прошли половину». Один держит проект зелёным, пока не сорван срок, другой — пока сходится бюджет. Оценки сделаны по разным правилам: где-то это диапазон, где-то обещание, где-то цифра, которую попросили назвать прямо на совещании. Портфеля в такой компании не видно — есть десять отдельных проектов, и про каждый нужно разговаривать отдельно, с переводчиком.
Это не разговор о плохих руководителях. Чаще всего в таких компаниях работают вполне сильные РП — просто каждый принёс свой способ работы с прошлого места, и никто никогда не договаривался, как правильно здесь.
Почему так получается
Управление проектами — ремесло, которое обычно осваивают в бою. Человек вырастает из аналитика, инженера или маркетолога, набивает шишки, собирает работающий лично для него набор приёмов и приходит с ним в новую компанию. Второй руководитель приходит со своим набором, третий — со своим. Все три набора рабочие. Просто они разные.
Дальше обычно случается одно из двух. Либо в компании нет никакого стандарта, и тогда разнобой считается нормой. Либо стандарт есть — написан год назад, лежит в вики на сорок страниц, и им не пользуется никто, включая автора. Второй вариант хуже первого: он создаёт иллюзию, что вопрос закрыт.
Что даёт общий подход
Первое — сопоставимость. Когда все руководители заполняют статус одинаково, руководитель направления видит портфель целиком, а не десять историй, каждую из которых нужно расшифровывать в личной беседе.
Второе — дешёвая передача проектов. Человек уходит в отпуск, увольняется, переходит на другой проект — и передача занимает день, а не три недели раскопок в чужих файлах.
Третье, и самое недооценённое, — общий словарь. Когда «риск», «изменение содержания» и «завершён» означают для всех одно и то же, из обсуждений уходит большой пласт споров, которые на самом деле были не про проект, а про терминологию.
Что стоит унифицировать
Список короче, чем кажется. Достаточно пяти вещей.
- Ответ на вопрос «зачем». Одностраничный устав или его аналог: какую задачу бизнеса проект решает, по какому признаку поймём, что решил, кто принимает результат. Это ядро: если у проектов нет сопоставимого ответа на «зачем», всё остальное — учёт ради учёта.
- Язык оценок. Не сами цифры, а то, как они получены и какую точность означают. Порядковая оценка, бюджетная и окончательная — это три разных обещания, и смешивать их нельзя. Подробнее об этом — в разборе точности оценок в проекте.
- Статус: поля и ритм. Одинаковый набор полей и одинаковая частота. Если каждый отчитывается в своём формате и в своём темпе, сравнивать по-прежнему нечего.
- Работа с рисками. Единый реестр и единый способ приоритизации. Реестр, который живёт в личном файле руководителя, для компании не существует. Как его вести — в пошаговом руководстве по управлению рисками.
- Правила изменений. Кто и на каком уровне принимает решение поменять содержание, срок или бюджет. Без этого договорённости о первых четырёх пунктах разъезжаются на первом же серьёзном проекте.
Что трогать не надо
Бюрократия начинается там, где унифицируют то, что должно отличаться. Не нужно загонять в единый формат инструменты, стиль общения внутри команды, глубину планирования и выбор подхода к разработке. Проект на три месяца с одной командой и годовая программа с пятью подрядчиками не могут вестись по одному регламенту — попытка заставить их жить одинаково заканчивается тем, что регламент обходят оба.
В PMBOK® Guide 8th Edition адаптация подхода под конкретный проект — часть самого стандарта, а не отклонение от него. Здесь же стоит держать в голове и общее направление, в котором управление проектами сдвинулось за последние годы: фокус на ценности — один из шести базовых принципов восьмой редакции, а в обновлённом экзамене PMP доля домена «Бизнес-среда» выросла с 8% до 26%. Единый подход, который следит за соблюдением процесса, но не спрашивает про ценность, — это ровно та бюрократия, ради борьбы с которой всё затевалось.
Как внедрять, чтобы прижилось
Начните с двух-трёх артефактов, а не с регламента. Одностраничный устав и общий формат статуса дают больше пользы, чем документ на сорок страниц, который никто не дочитает.
Соберите шаблоны снизу, а не спустите сверху. Почти всегда в компании уже есть руководитель, у которого статус или реестр рисков сделан хорошо. Взять его за основу дешевле и честнее, чем придумывать идеальную форму с нуля.
Договоритесь о словаре явно. Пятнадцать минут на то, чтобы записать, что считается риском, а что проблемой, и в какой момент задача становится «завершённой», экономят месяцы недопониманий.
Учите не одного человека, а группу. Это главное. Когда на курс отправляют одного руководителя, он возвращается с новым языком к коллегам, которые на нём не говорят, — и через месяц возвращается к прежним привычкам, потому что иначе его не понимают. Общий подход появляется только тогда, когда через одну программу проходят все РП сразу.
Частая ошибка
Единый подход путают с документом. Документ можно написать за неделю, а привычку — нет. Признак того, что подход прижился, простой: руководители пользуются общими шаблонами не потому, что так велено, а потому что так быстрее, чем изобретать своё. Если этого не происходит, дело не в том, что регламент недостаточно подробный.
Если вы думаете о том, чтобы привести управление проектами в компании к общему знаменателю, у нас есть корпоративный формат обучения: группа руководителей проходит одну программу по PMBOK® Guide 8th Edition, а по желанию разбирает на занятиях не учебные кейсы, а свои реальные проекты.