Балансировка матрицы: технический документ

Этот технический документ является частью колонки "Вести с передовой". В нем описаны проблемы, возникающие при внедрении корпоративной системы управления проектами в организации с матричной средой управления проектами.

Чтобы загрузить этот технический документ в формате Word, воспользуйтесь ссылкой Балансировка матрицы: технический документ.

Вы также можете ознакомиться с другими техническими документами колонки "Вести с передовой".

Балансировка матрицы

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

Идея матричного управления зародилась на основе представлений об управлении, существовавших в начале 70-х гг. прошлого века. Дж. Р. Гелбрейт (J.R. Galbraith) опубликовал в 1971 г. одну из первых работ по этой теме, посвященную комбинированию организационных и функциональных обязанностей. В то время преобладали среды управления с иерархической структурой.

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

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

Обязанности по управлению проектами распределены между отделами

Почему имеет смысл говорить об этом при обсуждении управления корпоративными проектами? Причина в том, что эта модель стала фундаментом практически каждого развертывания решений EPM корпорации Майкрософт. Если сейчас вы работаете над развертыванием Project Server, то неизбежно столкнетесь с ней. Модель матричного управления имеет исключения, которые мы обязательно обсудим, но пока достаточно сказать, что для организаций, ориентированных на технологии, она почти универсальна.

Если вы сейчас работаете над развертыванием решения EPM корпорации Майкрософт в какой-либо организации, то обнаружите, что она находится в одном из описанных ниже состояний.

  1. Матрица отсутствует.

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

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

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

    В такой ситуации вполне вероятно наличие не одного, а нескольких офисов управления проектами (по одному на каждый отдел), которые слабо сотрудничают друг с другом.

    При развертывании решения EPM корпорации Майкрософт в такой ситуации необходимо продумать, какие корректировки следует внести в структуру организации по ходу работы. Подобные компании часто обращаются к нам с просьбами о невозможном: обучить сотни или даже тысячи пользователей, установить Project Server и запустить систему в рабочей среде за пару недель. Они ожидают, что раз уж приобрели систему централизованного управления корпоративными проектами, то смогут немедленно перестроиться и организовать централизованную матричную среду. Такое заблуждение может дорого стоить. Нам неизбежно приходится говорить со высшим руководством о том, как придется изменить структуру организации. Эта новость обычно не вызывает радости у руководителей, которые надеялись, что приобретения программного обеспечения будет достаточно для перестройки всей работы.

    Мы начинаем такие проекты с разработки планов для отдела централизованного управления проектами и процедур централизованного управления проектами. Внедрение Project Server осуществляется постепенно, от центра к периферии. Такие проекты нередко длятся от 12 до 24 месяцев, пока вся организация, наконец, не будет вовлечена в процесс. Недавно мы возобновили работу над одним из таких проектов после перерыва длительностью два с половиной года, который потребовался компании для создания отдела управления проектами.

  2. Имеется сбалансированная матрица.

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

  3. Матрица имеется, но она не сбалансирована.

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

    Развертывание решения EPM корпорации Майкрософт в таких средах требует некоторых усилий по инвентаризации и анализу. В каких областях процессы были внедрены успешно? В каких областях процессы неэффективны? Какие имеющиеся процессы на уровне централизованного управления проектами достаточно эффективны для того, чтобы их можно было использовать при развертывании Project Server, а какие нет?

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

Проблема, присущая матричной модели

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

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

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

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

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

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

Отказ от матрицы?

Далеко не все являются приверженцами матричной структуры организации. В последние годы некоторые лидеры делового мира озвучивали мысль, что, возможно, матричная организация — не самый оптимальный вариант. По их мнению, эффективнее разделять персонал на специализированные проектные группы или организовывать проекты так, чтобы они выполнялись конкретными отделами и ответственность за них лежала на руководителях отделов. Чтобы подробнее ознакомиться с аргументами в пользу отказа от матричной модели, прочитайте эту статью Роба Эндерле (Rob Enderle).

В ряде организаций, которые я посетил недавно, в матричной модели наблюдались перекосы в ту или иную сторону, из-за чего в каждой конкретной ситуации мне приходилось давать разные рекомендации по поводу развертывания Project Server и решения EPM корпорации Майкрософт. Если нет отдела централизованного управления проектами, то его создание становится моей первой рекомендацией. Некоторые обращавшиеся ко мне компании заявляли, что хотят использовать Project Server только для снижения затрат на лицензии, но не намерены организовывать совместную работу. Это практически лишено смысла. Сама идея системы централизованного управления корпоративными проектами состоит в объединении данных для анализа и представления, что позволяет управлять всеми проектами в одном месте. Если у вас нет подобных намерений, то продолжайте пользоваться отдельными лицензиями на рабочие места.

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

Результат таких изменений может быть прямо противоположен ожидаемому. Действительно, затраты могут сократиться на короткий период, но потеря эффективности сотрудников, чьей задачей была реализация проектов за кратчайшее время и с минимальными расходами, скоро приведет к обратному эффекту. Однако на то, чтобы ощутить этот эффект, крупным организациям могут потребоваться месяцы и даже один или два года. Тем временем матрица разрушается, и возможности Project Server могут использоваться не в полном объеме.

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

Восстановление (или обеспечение) баланса

Тем, кто работает над развертыванием системы EPM или собирается к нему приступить, я рекомендую учесть несколько моментов, касающихся матричной среды управления.

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

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

Если вы создаете процессы, которые охватывают несколько отделов, а вам придется это делать, то подумайте о том, чтобы привлечь людей, которые могут чувствовать себя лишенными права голоса. Например, недавно я помогал организации, которой необходимо было создать процесс планирования емкости ресурсов, охватывающий различные отделы. Само собой разумеется, главы отделов не пришли в восторг от мысли, что они, возможно, в некоторой степени утратят контроль над собственным персоналом. Я порекомендовал создать руководящий комитет, который будет определять приоритеты проектов, и включить в его состав руководителей отделов. В этом случае главам отделов не будет казаться, что их лишают полномочий; вместо этого они будут включены в новую структуру управления, отвечающую за принятие решений, которые затрагивают все отделы. Такой прием помог избежать одной из проблем развертывания систем EPM за счет вовлечения в процесс лиц, которые могли бы стать его противниками.

Наконец, рекомендую не форсировать развертывание и реализовывать централизованные процедуры без излишнего вмешательства, используя поуровневый подход. Например, мы работаем над проектом в компании, в которой матрица имеет эффективную организационную структуру. Отдел управления проектами находится на начальной стадии развития, поэтому перегибать палку, вмешиваясь в структуру организации, не стоит. Мы порекомендовали для начала не доводить управление ресурсами до уровня отдельных сотрудников. Вместо этого организация должна развернуть систему управления ресурсами в виде централизованного процесса, в который будет вовлечено лишь небольшое число пользователей либо напрямую, либо в качестве представителей отделов в отделе управления проектами. Ресурсы будут определены на самом общем уровне, т. е. не ставится цель сразу обеспечить сопоставление отдельных сотрудников и задач. Вместо этого отдел управления проектами будет планировать емкость ресурсов, определяя совокупные потребности в ресурсах в предстоящие периоды, а затем передавать полученные данные главам отделов для принятия мер. Мы рассчитываем, что со временем главы отделов сами почувствуют необходимость в расширении развертывания системы EPM с целью упрощения работы по управлению конфликтами ресурсов.

Заключение

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

Об авторе

Крис Вандерслуис (Chris Vandersluis) — основатель и президент компании HMS Software, расположенной в Монреале, Канада, и являющейся партнером Майкрософт со статусом Microsoft Certified Partner. Он получил степень по экономике в университете Макгилла и имеет более чем 30-летний опыт работы в области автоматизации систем управления проектами. Он много лет является членом Института управления проектами (PMI) и оказывал содействие в основании местных отделений группы Microsoft Project Users Group (MPUG) в Монреале, Торонто и Квебеке. Крис публиковался в таких изданиях, как Fortune, Heavy Construction News, журнал Computing Canada и PMI PMNetwork, а также ведет колонку в Project Times. Он преподает углубленный курс управления проектами в университете Макгилла и часто выступает на специальных мероприятиях ассоциации управления проектами в Северной Америке и по всему миру. Компания HMS Software является разработчиком системы TimeControl, предназначенной для учета рабочего времени в рамках проектов, и с 1995 г. является партнером со статусом Microsoft Project Solution Partner.

Вы можете написать Крису Вандерслуису по следующему адресу электронной почты: chris.vandersluis@hms.ca

Если вы хотите прочитать другие статьи Криса Вандерслуиса, посвященные управлению корпоративными проектами, посетите сайт EPM Guidance компании HMS (http://www.epmguidance.com/?page_id=39).

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединиться к программе предварительной оценки Office

Были ли сведения полезными?

Спасибо за ваш отзыв!

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

×