Введем определение термина «проект» – основного понятия, на базе которого сформированы дальнейшие теоретические построения в этой книге. Под словом «проект» будем понимать общепринятое определение этого понятия (сформулировано на базе Project Management Institute[1]), для которого характерны два главных признака:
1. Обязательная ограниченность во времени;
2. Результатом является конкретный продукт (не обязательно осязаемый).
В виде проекта можно представить любое целенаправленное уникальное изменение в организации, начиная от закупки оборудования (целью проекта может быть, например, реализация новой схемы взаимодействия с поставщиком) и заканчивая запуском нового продукта на рынок или внедрения ИТ-системы в компанию. Основная задача, стоящая перед руководителем проекта, – определить четкие границы начала и завершения проекта и зафиксировать конечный результат в виде полученного уникального продукта или решения, не имеющего аналогов в данной организации.
На практике каждая компания по своему усмотрению выстраивает подход к проектной работе в зависимости от актуальных целей и своего представления о понятии «проект». Можно сформулировать жесткие критерии (например, потребность в финансировании, уровень трудоемкости и т. д.), при соответствии которым продукт должен быть реализован в качестве отдельного проекта. А можно большинство изменений рассматривать как проект с одним критерием – если в результате изменений формируется уникальный продукт или решение. В первом варианте ограниченный набор проектов позволяет компании сконцентрировать ресурсы на действительно важных инициативах и задачах, но многие изменения, происходящие за рамками проектной деятельности, выпадают из фокуса зрения руководства. При втором подходе можно повысить прозрачность управления (при условии что процесс системно выстроен) за счет единого реестра изменений всех элементов организации с понятным статусом этих элементов и их этапностью. Основные минусы второй стратегии – слабоуправляемый рост числа проектов, а также возникновение регулярных конфликтов по приоритетам. Возникающие по ходу работы изменения часто непоследовательны, носят локальный или противоречивый характер.
Поиск баланса между проектной (касается системных изменений) и операционной (относится к регулярным повторяющимся процессам) деятельностью – управленческий ребус для многих компаний. Любая операционная активность когда-то была результатом реализации проекта или проектов. Соответственно, качество проектной деятельности в конечном итоге определяет качество и глубину рутинных процессов компании, другими словами, определяет ее устойчивость на рынке и конкурентоспособность. Независимо от сформировавшихся подходов, принципов и правил проектного менеджмента в данной организации проект всегда является инструментом внедрения изменений и не может существовать в отрыве от системы управления, внутренних и внешних ограничений, с учетом которых организация функционирует и развивается.
Кого считать руководителем проекта – наверное, ключевой вопрос при внедрении изменений в организации. Так как основная задача этой книги заключается в ориентации на практическое использование и сопровождение проекта в реальных организационных условиях, мы не будем подробно останавливаться на сопоставлении различных определений, которые даются в деловой литературе для понятия «руководитель проекта» (менеджер проекта, проджект-менеджер, проектный менеджер). Суть этих определений тождественна. В качестве отправной точки воспользуемся определением, которое дает PMI: руководитель проекта – это назначенное организацией лицо, возглавляющее команду и ответственное за достижение целей проекта.
Функции проектного менеджера могут выполнять различные сотрудники в организации; вовсе не обязательно занимать должность руководителя проекта, чтобы управлять проектом, можно находиться на различных должностях в компании. Масштаб проекта, глубина внедряемых изменений и степень влияния этого проекта на другие процессы в организации – все эти аспекты определяют перечень и необходимый уровень компетенций руководителя проекта. Его роль непросто определить однозначно, она зависит от специфики проекта, состава команды и решаемых задач. Невозможно провести универсальную аналогию, пытаясь осознать роль руководителя и оценить потенциальную пользу от его деятельности. Нельзя сделать глобальное обобщение и во всех случаях сравнить руководителя проекта с дирижером оркестра или тренером футбольной команды – конечно, на основании некоторых задач и функций подобные параллели возможны, но такие аналогии всегда должны быть привязаны к конкретной роли и организационной специфике; универсальные сравнения не отражают реального функционала проектного менеджера, работающего над реализацией конкретного проекта.
Посмотрим на вопрос с другой стороны: выделим те роли и задачи, которые не относятся к функциям руководителя проекта и не должны формировать его круг обязанностей. Например, он не обязан заниматься организацией встреч с командой и собирать информацию по стадии готовности проекта. Если участие сводится к формальному отслеживанию динамики работ без какого-либо влияния на процесс и к поверхностному обновлению проектной документации, данная роль не является ролью руководителя проекта (на практике это значит, что функции проектного менеджера взяли на себя другие участники проектной команды – функциональные специалисты, эксперты и т. д.). Такое случается, если у руководителя проекта нет достаточных компетенций для погружения в специфику задач, а также в том случае если внутри команды начинаются конфликты или ролевая модель проекта изначально выстроена неверно (последний из этих вариантов самый опасный, так как представляет изначально заложенный риск провала проекта). В крупных проектах задача организации встреч и сбора статуса готовности без какого-либо погружения в суть процесса может поручаться администратору или другим сотрудникам, осуществляющим организационное сопровождение.
Проектный менеджер – всегда исследователь. В среднем не менее десяти процентов рабочего времени, особенно на начальных этапах, он должен тратить на исследование сферы бизнеса или функциональной области, к которой относится проект. Это может быть изучение внешних источников информации, опросы экспертов, анализ опыта смежных проектов, которые были реализованы данной организацией или другими компаниями. Без понимания основных определений и процессов, которые проект должен доработать или изменить, начинать его реализацию не имеет смысла. Умение выстроить информацию в понятную структуру, не являясь глубоким экспертом в этой области знаний, во многом определяет уровень и квалификацию проджект-менеджера.
Руководитель проекта не должен полностью фокусироваться на технических аспектах реализации проекта. В этом случае теряется главная функция проектного менеджера – регулярная коммуникация для вовлечения всех участников, в противном случае у руководителя попросту не хватает времени на общение с коллегами или в обсуждениях принимают участие только некоторые технические эксперты. При полном погружении в техническую специфику теряется непредвзятый взгляд на проблему со стороны (притом что в некоторых случаях такой взгляд абсолютно необходим), решения начинают приниматься для реализации отдельных технических задач; общие цели самого проекта, как правило, при этом уходят на второй план. Задача руководителя проекта состоит в том, чтобы с учетом проблематики, жизненного цикла и коммуникативного фона проекта самостоятельно принимать решения о личной степени погруженности в функциональные вопросы, но никогда при этом не терять контекст внешней среды, находящейся за рамками проекта. Подобный взгляд вовне часто позволяет своевременно предупредить возникновение острых технических проблем (например, возможность рассмотрения правительством нового закона, который может повлиять на проект, или появление заказчика, который предъявляет новые требования) и заранее заложить резерв для усиления команды экспертами и техническими специалистами.