«Менеджерский квартет», или Кому отдать управление проектом?

Учение Адизеса

Согласно учению профессора Ицхака Адизеса, чтобы быть успешным, менеджменту необходимо хорошо выполнять четыре роли:

1) Роль «Entepreneur» (E) обозначает предприимчивость, новые идеи, новые направления, новые возможности.

2) Роль «Purpose» (P) обозначает целеустремленность, исполнительность, ориентированность на выполнение задач и достижение результата.

3) Роль «Administer» (А) обозначает хорошее ведение дел, прозрачность и организованность процессов.

4) Роль «Integrate» (I) обозначает ориентацию на людей, интеграцию людей, исполнитель этой роли чувствует и объединяет людей.

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

Давайте рассмотрим подробнее.

Необходимость хорошего выполнения ролей (P) и (А) при управлении проектом, наверное, ни у кого не вызывает сомнения. Этому посвящено множество книг. Целеустремленность, исполнительность, ориентированность на выполнение задач – самые очевидные качества менеджера проектов, необходимые для достижения результатов. За них отвечает роль (Р). Без выполнения этой роли невозможно успешно завершить проект! Администрирование, связанное с ролью (А), позволяет четко планировать, координировать работы и отслеживать их состояние. При хорошем выполнении этой роли все работы на проекте ведутся в соответствии с формализованными процессами, участники проекта понимают, кто чем должен заниматься и в какой последовательности.

Менеджеру очень трудно выполнять одновременно эти две роли. Роль (Р) будет стремиться достичь результата максимально быстро, она не склона тратить время на формализацию, описание, у нее все в голове. Администрирование для роли «Purpose» – пустая трата времени! У роли (А) другая склонность – прежде чем что-то делать, это должно быть максимально формализовано, согласовано. Среди груды неудачных проектов множество тех, где хорошо выполнялась функция (Р) и плохо выполнялась роль (А). Такой дисбаланс приводит к тому, что участники проекта напряженно работают, но их работа взаимно не согласована, в итоге могут потратить много сил впустую, превышая сроки и бюджет. Такая ситуация обычно происходит из-за того что руководить проектом назначают самого трудолюбивого и компетентного с точки зрения предметной области специалиста. У него очень хорошо развита роль (Р), но плохо с ролью (А). И если на небольших краткосрочных проектах (до трех участников и длительностью до одного месяца) этот дисбаланс не сильно сказывается, то чем больше проект, чем он дольше, тем сильнее возрастает потребность роли (А). Не зря самый главный стандарт по управлению проектами PMBoK посвящен роли (А).

Почему недостаточно ролей (А) и (Р) для успешного выполнения проектов? Потому что этой паре недостает гибкости. Нельзя изначально учесть все варианты развития проекта, все риски. Даже с высоким уровнем администрирования в проекте постоянно будут возникать нештатные ситуации, на которые необходимо быстро реагировать. За время выполнения проекта может измениться бизнес-среда для заказчика, законодательство, стратегические цели заказчика. Возможно, что в такой ситуации необходимо переформулировать цели и задачи проекта.

Если бюджет зафиксирован и нет возможности его увеличить, то в таком случае придется уменьшить объем проекта. Или увеличить бюджет проекта, чтобы включить в него новые условия. Необходимо принять новые риски, посмотреть на проект новым взглядом. Что в этом случае произойдет с проектом, в котором выполняются только роли (Р) и (А)? Они либо не учтут этих изменений и будут продолжать ориентироваться на старые цели, в итоге получив ненужный заказчику результат, который останется на полке или выбросят в мусорку. Либо они остановят проект. Чтобы этого не произошло и необходима роль (Е), способная на инициирование изменений, гибкость в решениях, принятии на себя рисков.

Часто можно встретить проекты, в которых хорошо выполняется роль (Е) и (Р), но плохо выполняется (или не выполняется) роль (А). В таких проектах постоянно меняются цели и задачи, происходят множество итераций получения промежуточных результатов, много работы, но она никогда не заканчивается. Это такой производственный хаос, который назвали проектом. Роль (А) необходима для организации всего этого хаоса. Роли (А) и (Е) – антагонистичны! Одна обязательно вытесняют другую. В одном человеке им не ужиться, только разным людям.

Проекты, в которых хорошо выполняются только эти две роли, недолго существуют. Стороны обычно жестко разрывают отношения. Чтобы этот менеджерский конфликт не перерос в разрыв отношений, нужна роль «Integrate», которая объединяет все остальные. Эта роль умеет слушать и слышать остальных. Она пытается найти компромисс, сбалансировать участников: ограничивает (Е) вносить много изменений в проект, ограничивает (Р) в погоне за быстрым результатом, ограничивает (А) слишком увлечься администрированием. Но это не значит, что роль (I) самая важная, далее будет показано несколько примеров проектов, в которых не хватает исполнения хотя бы одной из ролей, и к каким проблемам это может привести.

Управленческая команда

Давайте рассмотрим для примера менеджмент проекта по автоматизации бизнеса организации заказчика (далее «Заказчик») с привлечением для выполнения работ подрядной организации (далее «Исполнитель»). Для управления таким проектом создают управляющий комитет (УК) проекта, куда включают представителей руководства заказчика и исполнителя, а также оперативных руководителей проекта с обеих сторон. К сожалению, наличия УК с четко прописанными функциями участников и периодического проведения совещаний недостаточно для успешного выполнения проектов. Успех выполнения проекта, как мы показали ранее, зависит от грамотного менеджмента, построенного на хорошем выполнении четырех ролей.

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

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

Ситуация 1. Причины (возможные)

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

Описание и последствия

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

Ситуация 2. Причины (возможные)

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

Описание и последствия

В отличие от предыдущей ситуации, состояние на проекте прозрачно. Но так как каждый из оперативных руководителей проекта по-разному заинтересован в проекте, то и администрирует в свою сторону. В итоге на совещаниях УК они цепляются в схватке, каждый доказывает (и достаточно убедительно) свою правду. Если вдруг будет принято решение внести изменения, то они долго будут вырабатывать и согласовывать между собой новые процедуры. Учитывая, что изначально нельзя предусмотреть все нюансы, особенно в проектах по автоматизации бизнеса, и часто требуются корректировки, в этой комбинации менеджмент проекта будет очень неэффективным. Хорошо если бюджет позволяет такой подход, иначе он может быть легко растрачен, а «воз останется и ныне там». Приоритет процедур над результативностью может превратить проект в процесс.

Ситуация 3. Причины (возможные)

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

Описание и последствия

На совещании УК всегда звучит главный тезис от заказчика к исполнителю: «Надо лучше работать! Цели и задачи были выбраны в начале проекта, теперь главное их реализовать. А вы прикрываетесь бумажками. Дайте быстрей результаты. Никаких изменений. Сами ошиблись, теперь расхлебывайте!». В итоге эти совещания быстро завершаются без утверждения необходимых корректирующих действий. Исполнитель, конечно, защищен с помощью хорошего администрирования, но не факт, что когда выяснится об отсутствии результата в назначенный срок, заказчик не придет в бешенство и не свалит все «шишки» на исполнителя.

Ситуация 4. Причины (возможные)

Куратор проекта от исполнителя – административный управленец, в прошлом сам очень успешный руководитель проектов, решил курировать «зеленого» руководителя проекта.

Описание и последствия

Заказчик давит на исполнителя, требует изменений и эффективной работы, а исполнитель жестко защищается (у него все задокументировано). Исполнитель утверждает: «мы изначально договорились о таких задачах, а теперь вы просите изменений. Мы не пойдем на изменения, только если делать рестарт проекта». Заказчик все больше и больше злится, но интегрирующая роль отсутствует, никто не может примирить стороны. Конфликт в таком проекте очень выражен и легко может привести к разрыву отношений, при этом исполнитель будет утверждать, что во всем был виноват заказчик.

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

Конечно, наличие менеджерской команды с хорошим выполнением ролей является необходимым, но недостаточным условием успешного выполнения проекта.

Источник фото: vk.com

Расскажите коллегам:
Комментарии
IT-консультант, Москва

При всем уважении к Ицхаку Адизесу, а также понимая вероятную цель этой публикации как упрощенное знакомство с EPAI, включая описание некоторых возможных рисков, не могу не отметить, что такой подход, а именно написание статьи БЕЗ указания некоторых важнейших ограничений по ее пониманию, не просто не полезен, а вреден.
1. По поводу подхода EPAI сразу хочу сказать, что между стратегией и операционной деятельностью всегда лежит тактика, которая здесь просто отсутствует. К сожалению, именно такой подход часто встречается на практике. То есть, переводить с языка стратегического видения на язык операционной деятельности просто некому. На моей практике это встречается часто и требует ''хирургического'' вмешательства.
2. В реальной жизни не всегда (то есть очень редко) удается выбрать или назначить людей на четыре рассматриваемые позиции, исходя из идеальной ситуации. То есть, надо быть готовыми не переназначать тех, кто не соответствует подходу EPAI, а работать с теми, кто есть, что требует совершенно других знаний и навыков. Отмечу, что часто не все позиции присутствуют в реальном проекте, роли зачастую совмещаются, что еще больше превращает этот подход в некую абстрактную теорию, полезную только на стадии обучения дисциплине управления проектами.
3. Ну и самое главное: нельзя рассматривать управление отдельно взятым проектом от той среды, где все это ''живет и дышит''. Это - еще один упущенный в статье аспект, требующий максимального внимания даже в процессе создания команды проекта. Давайте посмотрим на описание ситуации:
а) что, если заказчик - международная или зарубежная компания, исполнитель - локальная компания, работающая в том же городе (или в той же стране, но в другом городе), а подрядчик - в другой стране?
б) что, если мы имеем дело не с отдельно взятым проектом, а с проектом, входящим в программу. При этом люди уже назначены и работают, а нам надо добавить кого-то в уже существующую команду программы?
в) что, если команда проекта работает дистанционно?
г) и т.д.
То есть, стоило бы четче указать ограничения для статьи, чтобы читатели понимали степень ее применимости.

Генеральный директор, Челябинск

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

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

IT-менеджер, Москва

Александр, спасибо за положительный отзыв! Ваш отзыв вдохновляет на продолжение публикаций и развитие темы.

Татьяна, спасибо за конструктивную критику! Попробую отдельно описать указанные вами ситуации в рамках концепции EPAI. Теме, когда стили менеджеров не соответствуют необходимым, планировал посвятить отдельную публикацию, особенно, когда это выясняется в ходе проекта. И отдельное спасибо за подсказку в части разрыва между стратегическим и операционным менеджментом, посмотрю под этим углом.

Главный инженер, Тольятти

Интегратор в качестве куратора от исполнителя - это нонсенс. Интегратор всегда и под всех будет прогибаться в итоге предприниматель будет гнуть свою линию. На оперативном уровне я бы поменял местами администратора и производителя местами. А лучше всего:

Предприниматель - заказчик - он знает чего хочет.
Администратор - исполнитель - он будет сдерживать его ''хотелки''.
Производитель - оперативный исполнитель - он будет пахать под неусыпным оком администратора.
Интегратор - оперативный заказчик - он будет согласовывать желания предпринимателя и возможности производителя.

Но всё же многое зависит от людей. Если кто-то сможет тянуть 2 роли или не дотягивать даже до одной - ситуация в корне изменится.

Спасибо за статью! Дала пищу для размышлений.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Средняя зарплата в Москве превысит 200 тыс. руб. в 2027 году, по мнению властей Москвы

Власти Москвы также ожидают умеренный рост потребительского сектора.

Руководители российских компаний не доверяют нейросетям

Больше половины опрошенных считают, что ИИ – не лучший помощник для решения задач.

«Ашан» начал трудоустраивать людей с ментальными особенностями

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

Каждый пятый россиянин не получал повышение уже более 5 лет

Для 20% опрошенных толчком для карьерного роста стало увольнение с прежнего места работы.