Балансировка матрицы
Эта статья является частью нашей коллекции "Из окопов". В ней описаны проблемы, с которыми сталкиваются пользователи, реализующие корпоративное управление проектами (EPM) в организации, которая использует матричную среду управления проектами.
Чтобы скачать версию этой статьи в Word, см. раздел Балансировка матрицы: технический документ.
Дополнительные статьи см. в технических документах "Из окопов".
Балансировка матрицы
В кругах управления проектами мы часто говорим о матричной среде управления. Управление матрицами не является чем-то новым. Он стал стандартом де-факто для управления практически во всех высокотехнологичных организациях.
Идея матричного управления возникла из управленческого мышления в начале 70-х годов. J.R. Гэлбрейт дает нам одну из первых опубликованных работ по этой теме в 1971 году, говоря о том, как сочетать организационные и функциональные обязанности. Преобладающая среда управления в то время была иерархической.
Организации были огромными разрозненными отделами, управляемыми сильными руководителями отделов. Это отлично работает до тех пор, пока не будет несколько проектов, которые должны охватывать несколько отделов для завершения. Понятие "проектизированной" матрицы продвигается руководителями проектов и ассоциациями, такими как Институт управления проектами, уже более 30 лет.
В проецируемой матрице мы устанавливаем вторую ось для нашей организации и даем определенную ответственность той части организации, которая управляет проектами. Результатом являются отделы организации, расположенные на одной стороне дисплея, и руководители проектов, предоставляющие проекты или продукты с другой стороны.
Зачем говорить об этом, когда речь идет об управлении корпоративными проектами? Поскольку эта модель стала краеугольным камнем практически каждого развертывания Решения Microsoft EPM. Если вы сейчас работаете над развертыванием Project Server, вы обязательно запустите эту модель в своих путешествиях. Существуют исключения из модели управления матрицами, которые я обсудим, прежде чем я буду делать здесь, но достаточно сказать, что она близка к универсальной, если мы рассмотрим технологические организации.
Если вы сейчас работаете над развертыванием Решения Microsoft EPM, организация будет находиться в одном из нескольких штатов:
Матрица отсутствует
Организация полностью основана на хранилище. Каждый руководитель отдела управляет своим отделом, как если бы он был дочерним подразделением более крупной организации. Бюджеты суммируются вверх по отделам иерархическим образом (представьте себе органиграмму). Когда проект инициируется, он выполняется в каждом отделе, даже если для завершения проекта могут потребоваться ресурсы из других отделов. Если проект не может быть завершен с ресурсами отдела, который управляет им, внешние ресурсы согласовываются как запросы между отделами.
Это на самом деле не звучит слишком плохо, пока вы не попытаетесь управлять таким проектом. Если почти каждый проект требует межведомственных ресурсов, то выяснить приоритеты между группами невозможно. Нет никаких стимулов для того, чтобы ни один руководитель отдела отказаться от контроля над приоритетом своих собственных ресурсов. Это нелогично отказаться от такой власти, поэтому любой проект, который не может быть завершен в одном отделе, страдает.
Более того, когда мы говорим с руководителями, которые на один уровень выше, чем руководители отделов, универсальный плач заключается в том, что они не могут получить никакого планирования ресурсов. В этом есть смысл. Не существует структуры между отделами для агрегирования информации, необходимой для планирования ресурсов, и не существует стимулов для каждого руководителя отдела, чтобы они отправлялись в централизованные приоритеты, необходимые для такого анализа.
Вполне вероятно, что в этой ситуации мы найдем не один, а несколько проектных офисов — по одному на каждый отдел, которые очень мало сотрудничают друг с другом.
Развертывание решения Microsoft EPM в этом сценарии требует некоторого подумать о том, как одновременно настроить организацию. Часто мы получаем звонки от таких компаний с просьбой сделать невозможное. Обучить сотни или даже тысячи пользователей, установить Project Server и выйти в рабочую среду через пару недель. Ожидается, что, поскольку компания приобрела централизованную корпоративную систему управления проектами, организация сразу же выстроится и будет работать как централизованная матричная среда. Это дорогая фантазия. Неизбежно нам придется поговорить со старшим руководством о том, как организация должна быть изменена. Это, как правило, не большие новости для руководства, которые надеялись, что только приобретение программного обеспечения будет достаточно обязательства, чтобы все изменились.
Мы начинаем такие проекты с работы над планами для централизованного офиса управления проектами и централизованных процедур управления проектами. Project Server вводится медленно из середины. Такие проекты нередко занимают от 12 до 24 месяцев, пока вся организация, наконец, не будет вовлечена. Мы только что повторно начали такой проект после 21/2-летней задержки, в то время как они работали самостоятельно, чтобы создать PMO.
Существует сбалансированная матрица
Это здорово, когда это происходит, но это, к сожалению, довольно необычно. Поддержание сбалансированной матрицы требует постоянной корректировки и ухода. Но когда мы найдем сбалансированную матрицу, мы также, скорее всего, найдем сильно развитый набор процедур, определенных ролей и процесс, который хорошо понимается всем участникам. Развертывание решения Microsoft EPM в организации такого рода является оптимальным сценарием.
Существует матрица, но она несбалансирована
Это, безусловно, самый распространенный сценарий, с которым мы сталкиваемся, и он имеет смысл. Модель матрицы несет в себе некоторые присущие конфликты, поэтому мы часто находим матрицу либо взвешенных по отношению к отделу со слабым PMO, либо взвешенных по отношению к PMO со слабыми руководителями отделов. Или (и это, безусловно, самая сложная задача), мы находим матрицу взвешеной по отношению к некоторым отделам, но не к другим, и некоторые руководители проектов, но не другие, поэтому центр тяжести в организации трудно найти.
Развертывание решения Microsoft EPM в этих средах означает выполнение некоторых операций инвентаризации и обнаружения. Где были установлены успешные процессы? Где произошел сбой процессов? Что работает на уровне централизованного управления проектами, который можно использовать для развертывания Project Server, а что нет?
В таких типах развертываний нам нужно быть очень осторожным, чтобы выбрать элементы решения EPM, которое нужно развернуть первым, и кому их следует развернуть. Развертывание в поэтапном подходе в этом сценарии имеет решающее значение, так как подход с большим взрывом здесь почти никогда не бывает успешным.
Задача матрицы
Для тех, кто вырос, зная только матричные структурированные организации, вы можете даже не думать, является ли это хорошей или плохой структурой, или думать о том, что сильно или слабо в таком управлении. Существует фундаментальная проблема с матричной организацией, которую многие даже не ставит под сомнение: это конфликт по проектированию. Структура создает две противоположные силы: руководители отделов и руководители проектов. Мы бы никогда не говорили об этом вслух, конечно, но просто глядя на структуру делает это самоочевидным.
Цель руководителя отдела заключается в том, чтобы следить за сотрудниками отдела. Они хотят убедиться, что их сотрудники являются продуктивными, квалифицированными, довольными сотрудниками. Если бы мы оставили организацию только до руководителей отделов, мы бы в конечном итоге с радостными сотрудниками, которые были хорошо обучены, не слишком перегружены и хорошо компенсированы, но которые не производят много.
Цель руководителя проекта — следить за доставкой проекта. Они хотят убедиться, что их проект выполняется как можно быстрее и дешево, сохраняя при этом область и качество, которые были определены на момент начала проекта. Если бы мы оставили организацию только до руководителей проектов, мы бы в конечном итоге с некоторыми проектами были бы выполнены быстро, но огромная текучесть персонала, так как мы выгорели сотрудников во имя завершения проекта.
Идея матричной организации заключается в том, что создание конфликта между этими двумя силами будет счастливо балансировать организацию между производительностью и удовлетворенностью сотрудников. Предпосылка, однако, заключается в том, что руководители отделов и руководители проектов в конечном итоге все в значительной степени так же мощны, как друг друга. Проблема, конечно, заключается в том, что люди не созданы равными. Всегда будет один руководитель проекта, который более опытен, чем другой; некоторый руководитель отдела, который более квалифицированный, чем следующий.
Это отсутствие равенства выкидывает Матрицу из равновесия в первый день. Просто понимая, что исключение является сбалансированной матричной организацией, часто достаточно, чтобы pmos и организаторы думали о том, как поддерживать порядок, и это может быть хорошо.
Получить идеальный баланс не так важно, как убедиться, что есть некоторые усилия для определения того, где застряют проекты организации и люди. Средства для работы матричной среды всегда одинаковы: процессы и взаимодействие. Квалифицированный разработчик может определить процессы и процедуры, которые определяют, что важно для организации.
Отказ от матрицы?
Не все являются поклонниками Matrix Organization. В последние несколько лет ряд бизнес-лидеров высказывали мысль о том, что, возможно, матричная организация мышления не лучший план. "Разделите персонал на специализированные проектные группы", они говорят: "и вы будете счастливее за это" или "Организуйте проекты для работы в каждом отделе и предоставить их руководителям отделов". Дополнительные сведения об этом см. в этой статье Роба Эндерла, чтобы увидеть кого-то, кто считает, что модель Матрицы должна быть прекращена.
В ряде организаций, которые я посетил в последнее время, я видел матричные модели, которые были перемещены в ту или иную сторону, и каждая ситуация заставляет меня делать рекомендации, которые немного отличаются в том, как развернуть Project Server и решение Microsoft EPM. Если нет централизованного PMO на всех, то это становится моей первой рекомендацией. Некоторые организации обращаются ко мне и говорят, что они хотят использовать Project Server только для снижения затрат на лицензии, но не намерены работать вместе. Это не имеет большого смысла. Вся идея централизованной корпоративной системы проектов заключается в том, чтобы объединить данные для анализа и отображения, чтобы обеспечить совместное управление проектами. Если у вас нет намерения делать это, придерживайтесь отдельных лицензий на настольные компьютеры.
В некоторых организациях модель Матрицы была вытеснена возвращением к силосомышлению. Такого рода вещи могут произойти, когда есть большие организационные изменения или внешние стимулы, скажем, большие изменения в экономике. При давлении, некоторые менеджеры будут бороться за выживание любыми возможными способами. В последнее время я видел несколько крупных организаций, где руководители отделов успешно описали PMO и их персонал как "избыточные ресурсы проекта" и лоббировали, чтобы вернуть контроль руководителям отделов.
Результат таких изменений может иметь совершенно противоположный эффект от предполагаемого. Правда, затраты падают на короткий период, но потеря эффективности людей, чья работа заключалась в том, чтобы генерировать эффективность за счет более коротких, более дешевых проектов часто несет отскок некоторое время спустя. Тем не менее, в крупных организациях может потребоваться месяцы или даже год или два, прежде чем эти последствия будут реализованы. Тем временем матрица сворачивается, и возможности Project Server могут быть заблокированы.
В более прогрессивной организации новый акцент может быть сделан на PMO с вновь обретенным уважением к его возможностям и, возможно, даже новый уровень власти перед лицом сложной экономики.
Восстановление (или установка) баланса
Для тех, кто работает над развертываниями EPM, ниже приведено несколько вещей, которые следует подумать о среде управления матрицами, с которой вы столкнетесь:
Прежде всего, найдите процессы и определения ролей для каждой оси матрицы. Проводя собеседования, ищите, где процессы делают организацию более продуктивной, а не более бюрократической. При взгляде на роли следите за классической проблемой "ответственность без полномочий", о которой так часто говорят в кругах управления проектами.
Если вы начинаете с нуля, вы по-прежнему можете найти процессы в иерархической структуре, которые могут быть приняты, и они вполне могут стоить вам многого. Если вы можете найти существующий процесс или процедуру в отделе, которые могут быть приняты всем предприятием, то, признавая источник процесса, вы сразу получите две вещи: во-первых, у вас есть один процесс в одном отделе, который не требуется развертывать. Он уже принят. Во-вторых, вы можете в конечном итоге с большим союзником в ваших усилиях по созданию второй оси матрицы, где руководитель отдела может видеть доказательства того, что вы не намерены выбрасывать все, что уже было сделано департаментами.
Если вы создаете процессы, которые проходят по отделам, и вам придется это сделать, подумайте о привлечении тех людей, которые могут чувствовать себя бесправными. Например, недавно я помогала организации, которой пришлось создать процесс планирования ресурсов между отделами. Излишне говорить, что руководители отделов не были слишком обрадованы этой идеей, так как они чувствовали, что они потеряют некоторую степень контроля над управлением своим собственным персоналом. Я рекомендовал создать портфельный руководящий комитет (в том числе среди его членов руководители департаментов), который бы устанавливал приоритеты проектов. Руководители департаментов не чувствовали, что у них отнимают полномочия; вместо этого они будут включены в новую структуру полномочий для принятия решений между отделами. Работа таким образом отклонила сложный аспект развертывания EPM, включив тех самых людей, которые в противном случае выступают против него.
Наконец, подумайте о том, чтобы "осветить" развертывание и установить централизованные процедуры без чрезмерного вмешательства, работая в слоях. Например, мы работаем над проектом, в котором матрица очень сильна в организационном отношении. PMO находится в зачаточном состоянии, и настаивать на организационной структуре не идеально. Мы не рекомендуем работать до отдельного уровня, чтобы начать управление ресурсами. Вместо этого организация будет развертывать управление ресурсами как централизованный процесс с очень небольшим числом пользователей, присоединенных напрямую или в качестве эмиссаров из отделов к PMO. Все ресурсы будут определены как универсальные, и цель не будет в том, чтобы вывести на отдельный уровень задач для каждого сотрудника, чтобы начать работу. Вместо этого pmo начнет планирование ресурсов, выявляя совокупные проблемы с ресурсами в предстоящие периоды, а затем передаст проблему руководителям отделов для управления. Мы ожидаем, что со временем от самих руководителей отделов потребуется расширить развертывание EPM, чтобы упростить работу по управлению конфликтами ресурсов.
Заключение
Независимо от того, развертываете ли вы управление корпоративными проектами в качестве консультанта для других пользователей или развертываете собственный EPM в своей организации, вам почти наверняка придется решать проблемы матричной организации. Обеспечение сбалансированности матрицы является одной из ключевых задач EPM и систем EPM, таких как Решение Microsoft EPM, чтобы сделать их успешными.
Об авторе
Крис Вандерслуис (Chris Vandersluis) — президент и основатель канадской компании HMS Software( Монреаль), сертифицированного партнера Майкрософт. Он имеет степень экономики в Университете Макгилла и более 30 лет опыта в автоматизации систем управления проектами. Он является давним членом Института управления проектами (PMI) и помог основать отделения Монреаля, Торонто и Квебека группы пользователей проекта (MPUG). Публикации, для которых Крис написал, включают Fortune, Heavy Construction News, Computing Canada magazine, PMNetwork PMI, и он является регулярным обозревателем Project Times. Он преподает расширенное управление проектами в Университете Макгилла и часто выступает в функциях ассоциации по управлению проектами в Северная Америка и по всему миру. HMS Software является издателем системы хронометрирования, ориентированной на проекты TimeControl, и с 1995 года является партнером по решению проектов Майкрософт.
С Крисом Вандерслуисом можно связаться по электронной почте по адресу: chris.vandersluis@hms.ca
Если вы хотите прочитать дополнительные статьи Криса Вандерслуиса, связанные с EPM, см. на сайте руководства по EPM HMS (https://www.epmguidance.com/?page_id=39).