Слабая матрица, или почему «Управление проектом» как проект совершенно необходимо

Напившись пива и вместе с Шуриком успешно завершив прохождение Army of Two 2, погрузился в такси и отбыл к дому. В планах было спокойно почитать на сон грядущий про природу экономических кризисов и отвалиться спать. Вместо этого пришлось заехать забрать хорошую знакомую, чтобы подставить жилетку по поводу факапа ее проекта. Знакомую знаю добрых лет 5, и в ее отменных менеджерских качествах убедился наблюдая 3 больших проекта, которые она вела. Ее текущий проект наблюдаю в течение полугода, и его факап мог не произойти только в одном случае — если случится BFM (большое фантастическое чудо). Что самое прикольное — она ничего не могла сделать чтобы это изменить. Причины этого насквозь просты, но для многих неочевидны — и как следствие куча реально талантливых прожект менеджеров мучается сознанием собственной неполноценности, не имея на то никаких причин. Осознание этого мрачного факта породило желание нанести им добро, следствием чего стала эта статья.

Множество прожект менеджеров воспитано в духе «Project manager is ultimately responsible for project success…» — практически как советское «пионер, ты в овете за все!». И эта точка зрения абсолютна правильная, менеджер проекта действительно отвечает за все, иначе зачем он такой нужен.

Однако большая ответственность вовсе не гарантирует ему успеха в достижении результата. Более того, есть ситуации, в которых «ultimately responsible = назначен виноватым». Отчего так получается? Открываем любой букварь по менеджменту и читаем — если тебя назначают ответственным, значит тебе полагаются полномочия. Нет полномочий — ты не можешь реализовать ответственность, но если ответственность с тебя не сняли, а полномочий не дали — ты по факту назначен виноватым, потому что сделать ты ничего не сможешь. Если культура и полиси компании, в для которой ты делаешь проект не предполагает наделения тебя полномочиями — твой проект обречен.

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

Это написано даже в PM BoKе — внимательно перечитай статью про «слабые матрицы». В слабой матрице прожект менеджер — это такой чувак, который между всеми бегает и уговаривает «детки, давайте кушать кашку коллеги, давайте поработаем, ну давайте, а?». И все его посылают нафиг — потому что у каждого есть прямой начальник — функциональный менеджер, который определяет зарплату и бонусы, и если этому начальнику проект нафиг не нужен (а он ему как правило нафиг не нужен) — то роль прожект менеджера незавидна. Безусловно, иногда встречаются исключения — например, в функциональной структуре присутствует управление по целям, и постановщик целей в интересах проекта жОстко завязывает на сотрудничество с менеджером проекта функциональных менеджеров — например, «господа Алекс, Питер и Крисчен — если будет хоть один complaint на вашу готовность сотрудничать от Дженни — каждому из вас 25% бонуса офф». Но это — скорее исключение из правила, чем правило.

Так вот, дружище, слабых матриц в жизни — пруд пруди. Например, есть компании, которые имеют по сути функциональную структуру, периодески пытаясь изобразить «проектные» телодвижения. Классический пример — тебя подписывают менеджером внедрения системы автоматизации какого-то предприятия. «Ваша задача — сделать функциональных менеджеров своими союзниками, пусть они увидят пользу и сотрудничают с вами». Ага, пусть начальник склада увидит пользу в том, что обнаружено что у него крайне неоптимально используются складские площади, а начальник производства обнаружит, что можно было поднять эффективность на 20% без дополнительных вложений, которые он потребовал — и они оба сразу станут вашими союзниками. Молодец, начинай этот проект. Единственный вариант в таком раскладе — это жесткая проектная организация с прямым завязыванием этих людей на менеджера проекта, например через гендира. Слабая матрица = через 3 года система так и не работает, а ты уволен.

Другой вариант — внутри компании с сильной матричной организацией бывают части, которые являются слабой матрицей. Классика жанра — в аутсорсинге есть «продакшн» (ресурсы, которые продают за деньги) и есть «администрация» (службы, которые нужны чтоб продакшн работал). Так вот ресурсный пул и проекты — это сбалансированная или сильная матрица, а администрация — чисто функциональная структура или слабая матрица. И проекты, которые там делаются, обладают всеми чертами слабоматричных проектов — включая минимальные полномочия менеджеров проектов. Единственная возможность там сделать проект — это сесть на его бюджет, в котором есть и бонусная часть для исполнителей, или продавить включение соотв. Целей на сотрудничество с тобой в MBO-планы.

Еще два вопроса заслуживают специального обсуждения. Первый — это миф о том, что все вокруг умные вменяемые люди, которые заинтересованы в том, чтобы компания процветала, «ведь если компания умрет, то они останутся без работы». Ну и основываясь на этом мифе, мы уверенно заключаем, что даже в слабой матрице у менеджера будут «полномочия», так как все вменяемые люди его поддержат.  

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

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

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

Что можно посоветовать Пмам, чтобы не попадать в описанную выше ситуацию?

Первое. Помнить элементарную вещь — люди работают на того, кто им все дает. Если это не вы — они будут работать на вас постольку поскольку (поскольку сказал работать на вас тот все дает).

Второе. Если вы отвечаете за результат — то вы должны отвечать за выбор средств его достижения. Иначе начинается — «нет, ты давай попади в мишень, стоя на голове, с завязанными глазами, ну и лука мы тебе не дадим. Не можешь? Так ты плохой менджер, лузер!».

Из этого вы легко выведете остальные правила:

  • 1. Не полагайтесь на «здравый смысл работающих здесь» и «они должны с вами сотрудничать, ведь так задумано» — если у вас нет ответа на вопрос «если он будет хорошо работать, то я конкретная_вещь; а если плохо, то я КОНКРЕТНАЯ_ВЕЩЬ» — то у вас нет механизма воздействия на человека (примечание: «пожалуюсь на него — это не конкретная вещь). Нет механизма — он это быстро поймет и пошлет вас нафиг, а вы ничего не сможете сделать.
  • 2. Избегайте работы в слабых матрицах. В слабой матрице по определению полномочия — слабые. Результаты — изложены выше. Когда нанимаетесь на работу и берете проект, задайте прямой вопрос — «какие у меня полномочия в отношении членов проектной команды? Могу я уволить того, кто плохо работает? Могу я дать премию тому, кто хорошо работает? Будет ли у меня бюджет и авторизован ли я его тратить — например, чтобы отказаться от нашей ублюдочной системы управления требованиями? Это могу сделать Я, или мне надо пройти 5 кругов согласований?»
  • 3. Избегайте работы в компаниях, где слабая матрица наложена на явный идиотизм руководства. Да, такие компании есть. Есть бизнес-модели, которые практически невозможно испортить. Например, осваивание бюджетов. Да, благодаря тупости и идиотизму менеджеров прибыльность не 1000%, как могла быть, а всего 250% — но и 250% для многих других это недостижимая мечта. Менеджеры всех уровней в таких компаниях обычно заняты обсуждением собственной офигенности, а вовсе не тех вещей, которые надо улучшить. Любая попытка сделать что-то толковая обычно пресекается с вопросом «так, я тут мега-менеджер, а ты кто такой?». Любая попытка критиковать — вопросом «а ты смотри какая у нас прибыльность, видишь какие мы крутые?»
  • 4. Оформляйте свое исполнение управления проектом как проект — и продавайте своему работодателю. Никому в башку не приходит делать проекты для Заказчиков, не оговорив бюджет, ответственность и полномочия, состав работ, критерии приемки и успеха и вознаграждение. Так какого рожна вы запускаете свой проект по созданию успешного результата, не обговорив все эти условия? Не думали про это, нет?

Слабая матрица, или почему «Управление проектом» как проект совершенно необходимо: 15 комментариев

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

    1. Дык.
      Просто многие не понимают происходящего, пытаясь «сделать как лучше для компании».
      А то что в определенных ситуациях «интересы компании» не равно «интересы менеджеров сотрудников» — это не доходит.

  2. «Оформляйте свое исполнение управления проектом как проект — и продавайте своему работодателю.»

    Это просто супер мысль.

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

  3. Вы писали: «миф о том, что все вокруг умные вменяемые люди, которые заинтересованы в том, чтобы компания процветала, «ведь если компания умрет, то они останутся без работы».»
    В большинстве своем так и есть, ведь есть множество способов достижения процветания, а человек в первую очередь думает о себе. Потому этот принцип в большинстве своем работает (для себя и для себя в компании). Но иногда он может приводить к развалу компании, но тут уж «Се Ля ви» 🙂

    Цель менеджера проекта, которому дали обязанности, но не дали полномочий, в том что бы стать камикадзе. И показать руководству, что это был безнадежный проект, в итоге он конечно будет уволенным, но следующий кто придет за ним будет ему благодарен (возможно он сможет получить большие полномочия). Ведь руководство уже увидит что за проблемы бывают когда нет полномочий в этом конкретном проекте. А если руководство не увидит, то и черт с ним.

    А приведенные вами правила очень сильно зависят От. Иногда надо побарахтаться в безнадежном проекте, для общего развития. Ведь свои «шишки» намного лучше помогают, чем чужие 🙂

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

  4. Очень интересная статья. Я работал в 3-х компаниях и ни в одной из них «менеджеры проектов» не обладали всей полнотой полномочий. С другой стороны, надо признать, что и ответственность они обычно несут весьма ограниченную.

    Денис, интересно было бы узнать, а каким ты видишь оптимальное решение противоречия, описанного в статье? Двигаемся от слабой матрицы к проектной структуре? Или, скажем, переименовываем «менеджеров проектов» в scrum masters, а ответственность возлагаем на самоорганизующиеся scrum-команды? 🙂

  5. To: intr13
    Ну насчет того чтобы становиться камикадзе — это конечно личное дело каждого, но я бы например не взялся 🙂 ну типа по молодости разок-другой можно, чисто чтоб набраться опыта — но как системный подход такое лучше не практиковать 🙂
    Кстати, Йордон в свое книжке и в своем семинаре отдельно оговаривал «управление проектом как проект» — типа уж если подписался как камикадзе, то четко оговори что это deathmarch и что ты за это ожидаешь и что тебе надо чтоб взяться.

  6. To: Konstantin Razumovsky
    Ну на самом деле как и в каждом конкретном случае — надо смотреть по ситуации.
    Например, если ты нацелен на результат — типа выпуск продукта или выполнение fixed bid проекта, то приоритеты у тебя такие: результат, быстрее, лучше, дешевле. Соотвественно лучше строить структуру нацеленную на результат, с конкретным ответственным, нацеленным на достижение этого результата, умеющим организовать его достижение — в данном случае менеджера лучше всего описывает слово «драйвер». Соответственно его надо наделять его всей полнотой ответственности И власти .
    Если же у тебя например time&material аутсорсинговый проект, то приоритеты у тебя другие: стабильная (не высокоскоростная, а предсказуемая по времени) поставка, низкая текучка, воспроизводимый доход. Ну и соответственно тебе нужен совсем другой человек — умеющий создать комфортную обстановку, взять на себя нудную часть работы, быть громоотводом. Никаких особых полномочий ему не нужно, потому как если назвать его по адизесу — он чистой воды «интегратор», и его личные качества типа обаяния решают гораздо больше, чем понимание процесса разработки или умение формулировать цели.

    Что характерно, в аутсорсинговой компании обычно присутствуют проекты обоих типов. На каждый тип нужно ставить менеджера определенного вида. При этом надо отчетливо понимать, что менеджмент в стиле «интегратор» в большинстве случаев не подходит для проекта типа «result-driven». Через это кстати мы и видим такое количество зафакапленных fixed priceпродуктовых проектов — именно по тому что люди по инерции пытаются интегрировать, а надо драйвать.

  7. Денис, я согласен, что нужны разные типы менеджеров. Вопрос был — а какой тип организационной структуры эффективно поддержит оба типа проектов? Разве сможет нормально работать менеджер типа «драйвер» в слабой матрице? То есть, на самом деле, я хотел выпытать твое мнение про оптимальную организационную структуру для типичной ауторсинговой компании :).

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

  8. Камрад, я думаю так — литературу надо читать с опаской. Потому что литература — она норовит снабдить тебя готовыми рецептами с минимальными объяснениями почему рецепт такой, а не иной.
    А руководствоваться при выборе порядка действий нужно своим пониманием того, как система устроена, какое у нее текущее состояние и к какому конечному ты хочешь ее приблизить. Через это становится понятным, какие методы и практики нужны и сработают, а какие — не нужны, вредны или не сработают.
    Так же и с орг. структурой компании. «Правильный» ответ — это сбалансированная матрица. В большинстве случаев — это полная хрень, вы это наблюдаете каждый день — несовпадение менеджеров и типов проектов, несовпадение сотрудников и менеджеров, underperformance & confusion. Имхо, оптимальная структура — это микс функциональной (каждый T&MODC проект — это орг юнит) и проектной (каждый fixed bid — это проект с deliverables и полномочным драйвером) структуры.
    Почему каждый ODC — это орг юнит? Потому что по факту ресурсный и проектный менеджер здесь — это одно и то же, их задачи про одно и то же (см. выше). Тащить сдвоенную оргструктуру нет смысла — чисто лишние расходы и конфьюжн. Почему fixed bid — это проект? Потому что только fixed bid является полноценным проектом, достаточно посмотреть на текст контракта.
    У предложенной организации можно назвать только один недостаток — непонятно, кто будет заниматься бенчем. Ну типа проект закончился — что делать с людьми, куда их девать, кто им ищет проект? Но любой, кто даст себе труд подумать — легко определит, что вопрос высосан из пальца и выход на самом деле есть, причем простой.

  9. ola, камрад!
    5 лет управляю проектами в ФУНКЦИОНАЛЬНОЙ структуре (это даже на «слабая» матрица, где у РМ-а есть хоть какие -то полномочия) и могу подтвердить — это жутко сложно. Когд ген дир говорит тебе — у тебя есть все права «жаловаться мне на тех, кто не сдает таски во время», а все сотрудники проекта заняты в оперативной деятельности на 99% ))
    Ну и каковы результаты? Из 9-ти проектов 8 были признаны успешными Заказчиком. Эт была кровь и слезы ))) но шрамы быстро заживают и нарастает броня! ))
    я даже статью — крик души написал в журнал про РМ в функц структурах ))

  10. спасибо.
    Кстати, ты на конфе SEF 2010 (www.sef.by) выступать планируешь?
    Я думаю почитать доклад связь стратегии с проектами и про формирование портфеля проектов на базе BSC )

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *