Роль менеджера проекта является критической и самой важной среди участников проекта для успешной реализации проекта, а эффективность модели EPAI Ицхака Адизеса в применении к командам управления проектами подтверждена неоднократно. Согласно учению профессора Ицхака Адизеса, чтобы быть успешным, менеджеру просто необходимо совмещать и хорошо выполнять четыре роли:
- Роль «Entepreneur» (E) обозначает предприимчивость, новые идеи, новые направления, новые возможности.
- Роль «Purpose» (P) обозначает целеустремленность, исполнительность, ориентированность на выполнение задач и достижение результата.
- Роль «Administer» (А) обозначает хорошее ведение дел, прозрачность и организованность процессов.
- Роль «Integrate» (I) обозначает ориентацию на людей, интеграцию людей, исполнитель этой роли чувствует и объединяет людей.
Так как менеджмент проектов является частью общего менеджмента, то это учение применимо и к управлению проектами тоже. Схематично это выглядит следующим образом:
Необходимость хорошего выполнения ролей (P) и (А) при управлении проектом, наверное, ни у кого не вызывает сомнения. Этому посвящено множество книг. Целеустремленность, исполнительность, ориентированность на выполнение задач – самые очевидные качества менеджера проектов, необходимые для достижения результатов. За них отвечает роль (Р). Без выполнения этой роли невозможно успешно завершить проект! Администрирование, связанное с ролью (А), позволяет четко планировать, координировать работы и отслеживать их состояние. При хорошем выполнении этой роли все работы на проекте ведутся в соответствии с формализованными процессами, участники проекта понимают, кто чем должен заниматься и в какой последовательности.
Менеджеру очень трудно выполнять одновременно эти две роли. Роль (Р) будет стремиться достичь результата максимально быстро, она не склона тратить время на формализацию, описание, у нее все в голове. Администрирование для роли «Purpose» – пустая трата времени! У роли (А) другая склонность – прежде чем что-то делать, это должно быть максимально формализовано, согласовано. Среди груды неудачных проектов множество тех, где хорошо выполнялась функция (Р) и плохо выполнялась роль (А). Такой дисбаланс приводит к тому, что участники проекта напряженно работают, но их работа взаимно не согласована, в итоге могут потратить много сил впустую, превышая сроки и бюджет. Такая ситуация обычно происходит из-за того что руководить проектом назначают самого трудолюбивого и компетентного с точки зрения предметной области специалиста. У него очень хорошо развита роль (Р), но плохо с ролью (А). И если на небольших краткосрочных проектах (до трех участников и длительностью до одного месяца) этот дисбаланс не сильно сказывается, то чем больше проект, чем он дольше, тем сильнее возрастает потребность роли (А). Не зря самый главныйстандарт по управлению проектами PMBoK посвящен роли (А).
Почему недостаточно ролей (А) и (Р) для успешного выполнения проектов? Потому что этой паре недостает гибкости. Нельзя изначально учесть все варианты развития проекта, все риски. Даже с высоким уровнем администрирования в проекте постоянно будут возникать нештатные ситуации, на которые необходимо быстро реагировать. За время выполнения проекта может измениться бизнес-среда для заказчика, законодательство, стратегические цели заказчика. Возможно, что в такой ситуации необходимо переформулировать цели и задачи проекта.
Если бюджет зафиксирован и нет возможности его увеличить, то в таком случае придется уменьшить объем проекта. Или увеличить бюджет проекта, чтобы включить в него новые условия. Необходимо принять новые риски, посмотреть на проект новым взглядом. Что в этом случае произойдет с проектом, в котором выполняются только роли (Р) и (А)? Они либо не учтут этих изменений и будут продолжать ориентироваться на старые цели, в итоге получив ненужный заказчику результат, который останется на полке или выбросят в мусорку. Либо они остановят проект. Чтобы этого не произошло и необходима роль (Е), способная на инициирование изменений, гибкость в решениях, принятии на себя рисков.
Часто можно встретить проекты, в которых хорошо выполняется роль (Е) и (Р), но плохо выполняется (или не выполняется) роль (А). В таких проектах постоянно меняются цели и задачи, происходят множество итераций получения промежуточных результатов, много работы, но она никогда не заканчивается. Это такой производственный хаос, который назвали проектом. Роль (А) необходима для организации всего этого хаоса. Роли (А) и (Е) – антагонистичны! Одна обязательно вытесняют другую. В одном человеке им не ужиться, только разным людям.
Проекты, в которых хорошо выполняются только эти две роли, недолго существуют. Стороны обычно жестко разрывают отношения. Чтобы этот менеджерский конфликт не перерос в разрыв отношений, нужна роль «Integrate», которая объединяет все остальные. Эта роль умеет слушать и слышать остальных. Она пытается найти компромисс, сбалансировать участников: ограничивает (Е) вносить много изменений в проект, ограничивает (Р) в погоне за быстрым результатом, ограничивает (А) слишком увлечься администрированием. Но это не значит, что роль (I) самая важная, далее будет показано несколько примеров проектов, в которых не хватает исполнения хотя бы одной из ролей, и к каким проблемам это может привести.
Управленческая команда
Давайте рассмотрим для примера менеджмент проекта по автоматизации бизнеса организации заказчика (далее «Заказчик») с привлечением для выполнения работ подрядной организации (далее «Исполнитель»). Для управления таким проектом создают управляющий комитет (УК) проекта, куда включают представителей руководства заказчика и исполнителя, а также оперативных руководителей проекта с обеих сторон. К сожалению, наличия УК с четко прописанными функциями участников и периодического проведения совещаний недостаточно для успешного выполнения проектов. Успех выполнения проекта, как мы показали ранее, зависит от грамотного менеджмента, построенного на хорошем выполнении четырех ролей.
Итак, один человек не способен выполнять все четыре менеджерские ролиодинаково хорошо, ведь они конфликтны между собой. И даже две роли с большим трудом даются одному менеджеру. В связи с этим успешный менеджмент – это работа целой команды. Если УК рассмотреть как менеджерскую команду, то какие роли должны выполнять его участники, чтобы она была успешной? Из моей практики для этого роли должны быть распределены следующим образом:
Обоснованию такого правила можно посвятить отдельный труд. Сейчас хотел бы показать, что выполнение участником УК несоответствующей роли приводит к проблемам в управлении проектом. Давайте рассмотрим четыре типовых ситуаций, их возможные причины и последствия.
Ситуация 1. Роль менеджера проекта от исполнителя — Purpose
Причины (возможные). На роль менеджера проекта исполнитель поставил самого трудолюбивого и знающего систему или предметную область специалиста, думая, что это самая важная черта, необходимая для успеха проектом.
Описание и последствия
Одна из самых распространенных ошибок исполнителя. Это приводит к тому, что при выполнении такого проекта никто не понимает, в каком состоянии комплексно находится проект и куда движется. При этом все при деле и вообще очень много работы на проекте. Появляется множество промежуточных результатов, несогласованных между собой, множество ситуативных решений, принимаемых в надежде, что это, наконец, должно привести к цели. В связи с невыполнением исполнителем административной роли, ему нечем защищать содержание, сроки «плывут» и бюджет проекта «тает на глазах». Деньги заканчиваются, и исполнитель начинает думать, как бы ему «соскочить», минимизировав затраты. Заказчика злит отсутствие результата, несмотря на то, что он проявляет достаточное участие в работах и гибкость в принятии решений. В итоге кто-то первым сорвется, разорвав отношения.
Ситуация 2. Роль менеджера проекта от заказчика — Administer
Причины (возможные). На роль менеджера проекта от заказчика назначен менеджер с сильным административным подходом. Это может быть руководитель подразделения, в котором такой стиль менеджмента необходим, либо руководитель проекта, ранее успешно работавший у исполнителя.
Описание и последствия
В отличие от предыдущей ситуации, состояние на проекте прозрачно. Но так как каждый из оперативных руководителей проекта по-разному заинтересован в проекте, то и администрирует в свою сторону. В итоге на совещаниях УК они цепляются в схватке, каждый доказывает (и достаточно убедительно) свою правду. Если вдруг будет принято решение внести изменения, то они долго будут вырабатывать и согласовывать между собой новые процедуры. Учитывая, что изначально нельзя предусмотреть все нюансы, особенно в проектах по автоматизации бизнеса, и часто требуются корректировки, в этой комбинации менеджмент проекта будет очень неэффективным. Хорошо если бюджет позволяет такой подход, иначе он может быть легко растрачен, а «воз останется и ныне там». Приоритет процедур над результативностью может превратить проект в процесс.
Ситуация 3. Роль куратора проекта от заказчика — Purpose
Причины (возможные). Куратор от заказчика не является инициатором проекта. Он не фантазировал о пользе итоговых результатов, не предвкушал выгоды от планируемых в компании изменений, как это делают предприниматели. Проект был навязан ему извне, и он на него согласился.
Описание и последствия
На совещании УК всегда звучит главный тезис от заказчика к исполнителю: «Надо лучше работать! Цели и задачи были выбраны в начале проекта, теперь главное их реализовать. А вы прикрываетесь бумажками. Дайте быстрей результаты. Никаких изменений. Сами ошиблись, теперь расхлебывайте!». В итоге эти совещания быстро завершаются без утверждения необходимых корректирующих действий. Исполнитель, конечно, защищен с помощью хорошего администрирования, но не факт, что когда выяснится об отсутствии результата в назначенный срок, заказчик не придет в бешенство и не свалит все «шишки» на исполнителя.
Ситуация 4. Роль куратора проекта от исполнителя — Administer
Причины (возможные). Куратор проекта от исполнителя – административный управленец, в прошлом сам очень успешный руководитель проектов, решил курировать «зеленого» руководителя проекта.
Описание и последствия
Заказчик давит на исполнителя, требует изменений и эффективной работы, а исполнитель жестко защищается (у него все задокументировано). Исполнитель утверждает: «мы изначально договорились о таких задачах, а теперь вы просите изменений. Мы не пойдем на изменения, только если делать рестарт проекта». Заказчик все больше и больше злится, но интегрирующая роль отсутствует, никто не может примирить стороны. Конфликт в таком проекте очень выражен и легко может привести к разрыву отношений, при этом исполнитель будет утверждать, что во всем был виноват заказчик.
На этих примерах можно увидеть, что нарушение в выполнении одной из ролей приводит к серьезным проблемам. Поэтому в самом начале проекта важно оценить, насколько назначенные в УК люди смогут справиться с выполнением соответствующих им ролей. И если есть нарушения, то необходимо заранее предпринять корректирующие действия.
Конечно, наличие менеджерской команды с хорошим выполнением ролей является необходимым, но недостаточным условием успешного выполнения проекта.
Олег Павлич,
IT-менеджер в «Первый БИТ»