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