Управление проектами: начало

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

Так можно начать администрирование задач. Но это еще не управление проектами.

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

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

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

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

Что такое проект

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

В этом определении важны три части.

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

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

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

Зачем компании проектное управление

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

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

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

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

Что нужно до назначения руководителя проекта

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

Зачем. Какую управленческую ценность дает проектная деятельность: скорость вывода изменений, снижение потерь, выполнение клиентских обязательств, управляемость ресурсов, прозрачность рисков.
Каким образом. Какие правила планирования, контроля, изменения сроков и приемки используются. Кто утверждает план и кто имеет право его менять.
Границы ответственности. Что руководитель проекта решает сам, что согласует с владельцем проекта, а что выносит на уровень руководства.
Ресурсы. Чье время он может привлекать, на каких основаниях и как это время защищается от постоянного вытеснения текущими задачами.
Конфликты. Как решаются споры между проектом и операционной работой: приоритеты, сроки, качество результата, состав команды, изменение требований.
Приемка. Кто признает результат достаточным и по каким критериям. Без приемки проект может бесконечно оставаться «почти готовым».

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

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

Почему инструменты не заменяют систему

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

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

Поэтому вопрос «в чем вести проекты» должен идти после вопроса «как мы ими управляем». Иначе компания автоматизирует хаос, а не проектную работу.

Где обычно теряется управляемость

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

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

Все это не лечится одним совещанием или новым шаблоном отчета. Нужна управленческая рамка, пусть сначала и очень простая.

Как запускать проектную функцию спокойно

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

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

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

Вывод

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

Хороший руководитель проекта не спасает неясную систему управления. Он делает видимыми решения, риски, ограничения и последствия. Если компания готова с этим работать, проектное управление становится способом доводить изменения до результата. Если не готова, оно превращается в еще один слой отчетности.

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

Если проект нужно поставить под управление

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