В чем заключается организация управления проектами по принципу независимых команд
Организация проектов по принципу независимых команд
Рис. 8-2. Проектная команда
Взаимодействие между основной организацией и проектными командами может варьироваться. В некоторых случаях основная организация устанавливает процедуры административного и финансового контроля над проектом. В других случаях фирмы дают управляющему проектом максимальную свободу выполнить проект при выделении необходимых ресурсов. И «Apple», и IBM использовали данный подход для разработки своих новых линий персональных компьютеров в 1980 г. В корпорации Apple команда разработчиков компьютеров «Макинтош» была вообще изолирована в отдельное задание, подальше от шума и вмешательства корпорации, и получила главную установку разработать новейший компьютер, и как можно быстрее. И, наконец, некоторые организации экспериментируют с самоуправляемыми проектными командами без формального управляющего проектом.
Рис. 8-3. Структура организации проектного типа
Как и в случае функциональной организации, независимые проектные команды имеют свои сильные и слабые стороны. К сильным сторонам можно отнести следующие:
1. Это относительно простой способ выполнения проекта, который не сводится к противоречивым рутинным операциям. У функциональной организации не отбираются ресурсы на работу над проектом, функциональная организация сохраняет свою целостность, и проектная команда работает независимо от нее.
2. Эта система, в отличие от функционального подхода, концентрирует внимание на проекте.Управляющий проектом имеет полную власть над проектом. И хотя управляющий проектом подотчетен управляющим верхнего уровня основной организации, у него имеется независимая команда, единственной функцией которой является работа над проектом.
3. Независимые команды, как правило, быстрее выполняют проекты. Возможно, основная причина этого в том, что члены команды уделяют все внимание проекту и не отвлекаются на выполнение других обязанностей. Более того, в такой системе реакция на принятое управляющее решение наступает гораздо быстрее, так как информация уже не ходит по вертикалям функциональной иерархии.
4. В проектной команде существует высокий уровень мотивации и взаимопонимания.У членов команды одна цель и общая ответственность за проект.
Во многих случаях независимая команда является оптимальным решением для организации управления проектом. Однако слабые стороны данного подхода проявляются сразу же, как только принимаются во внимание потребности основной организации:
1. Создание автономных проектных команд дорого. Создается не только новая управленческая должность (управляющий проектом), но и все ресурсы проекту выделяются по отдельному рабочему штату. Это может привести к дублированию работы в разных проектах и потерям, вызванным увеличением производственных издержек.
4. Назначение штата персонала на выполнение проекта создает проблему, что с ним делать после завершения работы. Если нет других проектов, то возникают проблемы с обратным переводом специалистов в функциональные отделы, вызванные их долгим отсутствием и необходимостью вникать во все произошедшее, во все новинки и нововведения в их функциональной области.
1.2 Организация проектов по принципу независимых команд
На другом конце спектра структур управления проектом находятся независимые проектные команды. Эти команды действуют независимо от основной структуры управления. Как правило, управляющий проектом должен сформировать основную, ключевую, группу специалистов, работающих над проектом полный рабочий день. Управляющий проектом набирает необходимый персонал как внутри, так и за пределами организации. Команда физически отделена от организации и имеет четкую установку на достижение цели проекта.
Взаимодействие между основной организацией и проектными командами может варьироваться. В некоторых случаях основная организация устанавливает процедуры административного и финансового контроля над проектом. В других случаях фирмы дают управляющему проектом максимальную свободу выполнить проект при выделении необходимых ресурсов.
Рис. 3 Проектная команда
Как и в случае функциональной организации, независимые проектные команды имеют свои сильные и слабые стороны. К сильным сторонам можно отнести следующие:
1. Это относительно простой способ выполнения проекта, который не сводится к противоречивым рутинным операциям. У функциональной организации не отбираются ресурсы на работу над проектом, функциональная организация сохраняет свою целостность, и проектная команда работает независимо от нее.
2. Эта система, в отличие от функционального подхода, концентрирует внимание на проекте. Управляющий проектом имеет полную власть над проектом. И хотя управляющий проектом подотчетен управляющим верхнего уровня основной организации, у него имеется независимая команда, единственной функцией которой является работа над проектом.
3. Независимые команды, как правило, быстрее выполняют проекты. Возможно, основная причина этого в том, что члены команды уделяют все внимание проекту и не отвлекаются на выполнение других обязанностей. Более того, в такой системе реакция на принятое управляющее решение наступает гораздо быстрее, так как информация уже не ходит по вертикалям функциональной иерархии.
4. В проектной команде существует высокий уровень мотивации и взаимопонимания. У членов команды одна цель и общая ответственность за проект.
5. При том, что проектной команде выделяют необходимые ресурсы, имеет место высокий уровень кросс-функциональной интеграции. Специалисты из разных областей работают вместе и при надлежащем руководстве стараются оптимизировать проект целиком, а не только те его участки, где они являются экспертами.
Во многих случаях независимая команда является оптимальным решением для организации управления проектом. Однако слабые стороны данного подхода проявляются сразу же, как только принимаются во внимание потребности основной организации:.
1. Создание автономных проектных команд дорого. Создается не только новая управленческая должность (управляющий проектом), но и все ресурсы проекту выделяются по отдельному рабочему штату. Это может привести к дублированию работы в разных проектах и потерям, вызванным увеличением производственных издержек.
2. Иногда независимые проектные команды начинают считать себя абсолютно самостоятельными и независимыми от основной организации (см. Случай из практики). Возникает сильное противопоставление «мы-они» между проектной командой и основной организацией. Это противопоставление может не только затруднить соединение отдельных проектных результатов в единое целое, но и возвращение членов проектных команд в их функциональные отделы после завершения работы над проектом.
3.Создание автономных команд мешает профессиональному разрешению проблем, так как оно ограничивается только профессиональным уровнем специалистов, работающих над проектом. Хотя ничто не метает специалистам консультироваться с их коллегами из функциональных отделов, синдром «мы-они» и тот факт, что такие консультации формально не санкционированы организацией, препятствуют подобным контактам.
4.Назначение штата персонала на выполнение проекта создает проблему, что с ним делать после завершения работы. Если нет других проектов, то возникают проблемы с обратным переводом специалистов в функциональные отделы, вызванные их долгим отсутствием и необходимостью вникать во все произошедшее, во все новинки и нововведения в их функциональной области.
ОРГАНИЗАЦИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
В этой главе рассматривается организация предприятий с целью управления проектами. Если быть более точным, в ней рассматриваются три различные организационные структуры, задействованные в управлении проектами: функциональная организация, собственно управленческие команды и матричная структура.
В этой главе также обсуждаются преимущества и недостатки каждой из этих структур, а также факторы, диктующие фирме предпочтения одной формы перед другими и выбор.
Выберет ли фирма для работы над проектом традиционную функциональную организацию или независимые проектные команды, или какую- либо форму матричной организации — это только часть дела. Каждый, кто работал в нескольких организациях, понимает, что имеются существенные различия в подходах к управлению проектами в разных фирмах с одинаковыми структурами. Работа в матричной организации ATamp;T значительно отличается от работы в Hewlett-Packard. Многие исследователи объясняют такие отличия разной культурой организации Культура организации является отражением «личности» организации Как каждый человек имеет индивидуальные особенности, так и каждая организация имеет индивидуальную культуру. О культуре организации и ее влиянии на процесс организации и управления проектами будет рассказано подробнее в конце главы.
Как структура управления проектами, так и культура организации являются основными элементами среды, в которой разрабатываются проекты. Управляющим проектами и работникам необходимо знать «территорию», чтобы можно было избежать преград и использовать различные пути для завершения работы над проектами.
СТРУКТУРЫ УПРАВЛЕНИЯ ПРОЕКТАМИ
Система управления проектами обеспечивает каркас для запуска и разработки проектов организацией-учредителем. Хорошая система умело
сочетает нужные потребности как организации-учредителя, так и проекта через определение взаимодействия между проектом и организацией-уч- редителем относительно полномочий, распределения ресурсов и в итоге интеграции результатов проекта в основную работу.
Многие организации испытывали огромные трудности, пытаясь одновременно с созданием системы для организации проектов управлять текущей деятельностью. Одна из основных причин таких трудностей заключается в противоречиях между проектами и базовыми структурными принципами, на которых основаны традиционные организации. Во-первых, проекты являются уникальными, единичными мероприятиями с вполне определенным началом и завершением. Большинство организаций созданы для эффективного управления непрерывной деятельностью. Эффективность главным образом достигается путем разделения сложных заданий на простые повторяющиеся операции по типу сборочного производства. Проекты по своей природе не рутинны и, следовательно, являются аномалией в подобной рабочей среде.
Во-вторых, большинство проектов по своей сути являются междисциплинарными, что требует координации усилий самых разных специалистов. Например, проект разработки нового продукта наверняка потребует участия специалистов в области дизайна, маркетинга, производства и финансов. Однако большинство организаций структурированы но отделам согласно функциональной направленности, таким образом, специалисты по дизайну, маркетингу, производству и финансам работают в разных подразделениях. Многие исследователи отмечают, что различные группы специалистов вырабатывают свои собственные традиции, нормы, ценности и стиль работы, что мешает их «интеграции» и приводит к функциональному разграничению. В большинстве организаций полномочия распределяются иерархически по функциональным линиям. А так как проекты охватывают несколько функциональных областей, то выявить и назначить основного ответственного за управление проектом в целом часто очень трудно.
Организация проектов в рамках функциональной структуры
Одним из подходов к организации проектов является простое управление ими в рамках существующей функциональной иерархии организации. Когда менеджер принимает решение о разработке проекта, работа над различными частями проекта поручается соответствующим функциональным подразделениям, при этом каждое подразделение отвечает за выполнение работ над своим сегментом проекта (см.
Рис. 8-1. Функциональные организации
ектом в целом будут руководить в рамках обычной иерархии, причем проект будет одной из частей работы верхнего уровня управления.
Также функциональная организация обычно используется, когда из- за характера самого проекта одна функциональная область играет доминирующую роль в разработке проекта или особо заинтересована в успехе проекта. В этих условиях менеджер верхнего уровня становится ответственным за координацию проекта в целом. Например, переводом оборудования и персонала в новый офис будет руководить управляющий верхнего уровня из административно-хозяйственного отдела. Или же проектом, занимающимся обновлением и усовершенствованием информационной системы управления, будет заниматься отдел информационных систем. В обоих случаях большая часть проектных работ будет выполняться конкретным отделом, и координация с другими отделами будет осуществляться по обычным каналам.
Существуют как преимущества, так и недостатки использования существующих функциональных структур для разработки и руководства проектами. Главными преимуществами являются следующие: Проекты разрабатываются в рамках базовой функциональной структуры основной организации.
Наряду с преимуществами организации проектов в рамках существующей функциональной структуры, имеются и недостатки. Они особенно сильно проявляются, если масштаб проекта велик, и ни один из функциональных отделов не берет на себя смелость возглавить руководство им. У проекта часто отсутствует центр. У каждого функционального отдела своя собственная повседневная работа, из-за чего выполнением проекта иногда пренебрегают в пользу выполнения основных функциональных обязанностей. Эта проблема усугубляется, когда проект ставит разные приоритеты для разных отделов. Например, для отдела маркетинга проект может быть важным и срочным, в то время как отдел эксплуатации оборудования считает его второстепенным. Легко представить себе напряженность, которая может возникнуть, если работники отдела маркетинга будут дожидаться, пока их коллеги из другого отдела закончат свою часть работы.
Связи между функциональными отделами могут оказаться слабыми. Координация и обмен информацией, как правило, очень слабы в большинстве иерархических организаций.
Организация проектов по принципу независимых команд
На другом конце спектра структур управления проектом находятся независимые проектные команды. Эти команды действуют независимо от основной структуры управления. Как правило, управляющий проектом должен сформировать основную, ключевую, группу специалистов, работающих над проектом полный рабочий день. Управляющий проектом набирает необходимый персонал как внутри, так и за пределами организации. Команда (см. рис. 8-2) физически отделена от организации и имеет четкую установку на достижение цели проекта.
Взаимодействие между основной организацией и проектными командами может варьироваться. В некоторых случаях основная организация устанавливает процедуры административного и финансового контроля над проектом. В других случаях фирмы дают управляющему проектом максимальную свободу выполнить проект при выделении необходимых ресурсов. И «Apple», и IBM использовали данный подход для разработки своих новых линий персональных компьютеров в 1980 г.
В случае организаций, где проекты являются доминирующей формой бизнеса, таких, как строительные фирмы, консалтинговые фирмы, киностудии, вся организация поддерживает проектные команды. Вместо одно- го-двух специальных проектов организация состоит из групп квазинеза- висимых команд, работающих над конкретными проектами. Основная за-
дача традиционных функциональных организаций состоит в оказании помощи и поддержки проектным командам. Например, отдел маркетинга занимается развитием нового бизнеса, который даст новые проекты, а отдел управления персоналом и трудовыми ресурсами отвечает за решение разнообразных вопросов, связанных с персоналом, наймом и подготовкой новых работников. В литературе такой тип организации называют формой организации проектного типа, графически он представлен на рис. 8-3.
Как и в случае функциональной организации независимые проектные команды имеют свои сильные и слабые стороны К сильным сторонам можно отнести следующие: * Это относительно простой способ выполнения проекта, который не сводится к противоречивым рутинным операциям. У функциональной организации не отбираются ресурсы на работу над проектом, функциональная организация сохраняет свою целостность, и проектная команда работает независимо от нее. Эта система, в отличие от функционального подхода, концентрирует внимание на проекте. Управляющий проектом имеет полную власть над проектом. И хотя управляющий проектом подотчетен управляющим верхнего уровня основной организации, у него имеется независимая команда, единственной функцией которой является работа над проектом. Независимые команды, как правило, быстрее выполняют проекты. Возможно, основная причина этого в том, что члены команды уделяют все внимание проекту и не отвлекаются на выполнение дру
гих обязанностей. Более того, в такой системе реакция на принятое управляющее решение наступает гораздо быстрее, так как информация уже не ходит по вертикалям функциональной иерархии. В проектной команде существует высокий уровень мотивации и взаимопонимания. У членов команды одна цель и общая ответственность за проект. При том, что проектной команде выделяют необходимые ресурсы, имеет место высокий уровень кросс-функциональной интеграции. Специалисты из разных областей работают вместе и при надлежащем руководстве стараются опитмизировать проект целиком, а не только те его участки, где они являются экспертами.
Во многих случаях независимая команда является оптимальным решением для организации управления проектом. Однако слабые стороны данного подхода проявляются сразу же, как только принимаются во внимание потребности основной организации: Создание автономных проектных команд дорого. Создается не только новая управленческая должность (управляющий проектом), но и все ресурсы проекту выделяются по отдельному рабочему штату. Это может привести к дублированию работы в разных проектах и потерям, вызванным увеличением производственных издержек. Иногда независимые проектные команды начинают считать себк абсолютно самостоятельными и независимыми от основной организации (см. Случай из практики). Возникает сильное противопоставление «мы-они» между проектной командой и основной организацией. Это противопоставление может не только затруднить соединение отдельных проектных результатов в единое целое, но и возвращение членов проектных команд в их функциональные отделы после завершения работы над проектом. Создание автономных команд мешает профессиональному разрешению проблем, так как оно ограничивается только профессиональным уровнем специалистов, работающих над проектом. Хотя ничто не метает специалистам консультироваться с их коллегами из функциональных отделов, синдром «мы-они» и тот факт, что такие консультации формально не санкционированы организацией, препятствуют подобным контактам. Назначение штата персонала на выполнение проекта создает проблему, что с ним делать после завершения работы. Если нет других проектов, то возникают проблемы с обратным переводом специалистов в функциональные отделы, вызванные их долгим отсутствием и необходимостью вникать во все произошедшее, во все новинки и нововведения в их функциональной области.
СЛУЧАЙ ИЗ ПРАКТИКИ Обратная сторона проектных команд
Одним из преимуществ создания независимых проектных команд является то, что специалисты из разных функциональных областей могут сформировать гибкую рабочую команду, приверженную работе над проектом Одновременно с тем, что
такие команды готовы свернуть горы для выполнения проекта, существует отрицательный фактор, который в литературе называется «болезнью проектной независимости». Между членами проектной команды и остальной организацией может возникнуть противопоставление «мы-они». У членов проектной команды развивается высокомерие и чувство огромного и нескрываемого превосходства, вызывающее антагонизм основной организации. Люди, не работающие над проектом, начинают завидовать престижу и вниманию, оказываемому проектной команде, особенно если при этом считают, что проект финансируется за счет их тяжкого труда. Тенденция присваивать проектным командам экзотические имена, такие как «Серебряные Пули» или «Тигры», а также дополнительно их стимулировать, лишь усиливает противоречия между проектной командой и основной организацией.
Подобное произошло с крайне успешной командой разрабочиков компьютеров «Макинтош» из фирмы Apple. Стив Джобс, совмещавший в то время посты председателя «Apple» и управляющего проектом «Макинтош», щедро стимулировал свою команду, члены которой могли, например, пройти сеанс массажа прямо на работе, пили только для них свежевыжатый апельсиновый сок, могли развлечься и летали только первым классом. Ни один другой работник Apple не летал первым классом. Джобс считал свою команду элитой Apple, а всех остальных называл работниками «второго сорта». Инженеры из подразделения «Apple II», которые приносили Apple огромную прибыль от продаж, пришли в ярость от подобного отношения. Однажды в местном баре напряженность между инженерами «Apple II», сидящими за одним столом, и сидящими за другим столом представителями команды «Мае», выплеснулась наружу. Арон Голдберг, давно работающий консультантом в компании, наблюдал за усиливающейся перепалкой. «Ребята из «Мае» кричали, что они — «будущее компании». Ребята из «Apple II» кричали, что они — «деньги компании». Затем полетели ручки и карандаши. Я ждал, когда же наконец упадут бумаги, и они кинутся их собирать».
Хотя со стороны это могло показаться забавным, но драка между группами «Apple II» и «Мае» серьезно подорвала работу Apple в 1980 годах. Джон Скалли, заменивший Стива Джобса на посту председателя Apple, сказал, что корпорация превратилась в две «воюющие компании», и назвал улицу между зданиями «Apple II» и «Macintosh» «демилитаризованной зоной».
Организация проектов в матричной организации
Матричная структура управления является гибридной организационной формой, в которой структура горизонтального проектного менеджмента «накладывается» на обычную функциональную иерархию. В матричной структуре существуют два канала управления — по функциональным линиям и по проектным линиям. Части проекта не делегируются различным отделам или автономным командам, а участники проекта подотчетны одновременно функциональным [енеджерам и управляющим проектами.
Компании применяют эту очень маневренную схему управления самыми различными способами. Некоторые организации разворачивают временные матричные струтиуры для разработки конкретных проектов, в других организациях «матрица; может быть постоянной. Сначала рассмотрим общее применение структуры и затем перейдем к более подробному обсуждению ее деталей. Рассмотрим рис. 8-4. Одновременно разрабатываются три проекта: А, В и С. Все три управляющих проекта (РМ a-с) подчиняются директору проектного департамента, который руководит всеми проектами. У каждого проекта есть администратор, хотя у проекта С он работает на полставки.
Zeta Manufacturing, Inc. Президент
Рис. 8-4. Структура матричной организации
Проект А связан с дизайном и расширением существующей производственной линии по обработке новых металлических сплавов. Над проектом А будут работать 3—5 человек из производственного и 6 человек из технического отделов. Некоторые из них работают на полставки, некоторые на полную, в зависимости от потребностей на разных стадиях проекта. Проект В связан с разработкой нового продукта, здесь необходимо серьезное участие специалистов из технического, производственного отделов и отдела маркетинга. Проект С связан с прогнозированием изменений спроса. Одновременно с работой над этими, а также и другими проектами, функциональные подразделения продолжают выполнять свои основные обязанности.
Матричная структура создается для оптимального использования ресурсов, так как одновременно с разработкой многочисленных проектов организация способна выполнять свои обычные функциональные обязанности. Одновременно матричный подход нацелен на большую интеграцию проектных команд в организации через наделение управляющего проектом достаточными полномочиями. Теоретически матричный подход обеспечивает двойное внимание сразу к функциональным обязанностям и к проектным требованиям, отсутствующее в раздельных подходах к управлению проектом как по принципу независимых команд, так и по функциональному принципу. Это можно четко видеть в табл. 8-1, где представлено отношение функциональных управляющих и управляющих проектами к ключевым проектным вопросам.
В принципе каждое проектное решение и каждая операция должны обговариваться. Управляющий проектом отвечает за интеграцию функциональной информации и контроль за выполнением проекта. Функциональные управляющие отвечают за контроль функционального вклада в проект.
Таблица 8-1. РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ МЕЖДУ МЕНЕДЖЕРОМ ПРОЕКТА И ФУНКЦИОНАЛЬНЫМ МЕНЕДЖЕРОМ В МАТРИЧНОЙ СТРУКТУРЕ
Менеджер проекта Обсуждаемые вопросы Функциональный менеджер
Когда нужно выполнить задание?
Сколько денег выделено на выполнение задания?
Насколько хорошо был выполнен проект в целом?
Кто будет работать над заданием?
Где будет выполняться задание?
Почему надо выполнять задание?
Удовлетворительно ли выполнено задание?
Как будет выполняться задание?
Как работа над проектом повлияет на обычную функциональную работу? Насколько хорошо был использован функциональный вклад?
Различные матричные формы
Существуют различные виды матричных систем в зависимости от способа и глубины разграничения полномочий менеджеров проекта и функциональных управляющих. Слабая, легкая или функциональная матрица — так называют матрицы, где баланс полномочии сдвинут в сторону функциональных менеджеров. Сбалансированная, или средневзвешенная
матрица, — это традиционная матричная структура. Сильная, тяжелая или проектная матрица — это система, в которой баланс полномочий на стороне управляющего проектом.
Относительная разница в полномочиях между функциональными управляющими и управляющими проектами находит отражение в ряде взаимосвязанных параметров. Одним из таких параметров является уровень подотчетности. Управляющий проектом, подчиняющийся непосредственно генеральному директору, имеет больше полномочий, чем менеджер по маркетингу, который подотчетен вице-президенту по маркетингу. Расположение проектных операций — это не самый важный фактор. Управляющий проектом оказывает значительно большее влияние на участников проекта, если они работают в его офисе, нежели когда они выполняют свою работу над проектом в своих функциональных офисах. Аналогично количество персонала, занятого на постоянной работе по проекту, также играет существенную роль.
Итак, независимо от того, является ли матрица слабой или сильной, функциональной или проектной, ее структура определяется уровнем полномочий управляющего проектом по отношению к работникам команды проекта. Полномочия могут быть определены неформально, через оценку способностей менеджеров убеждать и очевидную важность проекта, или формально через документально оформленные полномочия управляющего проектом. Вот краткое описание трех типов матриц: I Функциональная матрица — эта форма сходна с функциональным подходом за исключением того, что есть формально назначенный управляющий проектом, ответственный за координацию проектных операций. Функциональные управляющие отвечают за управление своим сегментом проекта. Управляющий проектом распределяет обязанности работников и составляет графики и контрольные перечни, собирает информацию о статусе работы и способствует выполнению проекта. Управляющий проектом имеет непрямые полномочия ускорять и отслеживать работу над проектом. Функциональные управляющие принимают решения о том, кто какую работу будет выполнять и определяет сроки ее выполнения.
СЛУЧАЙ ИЗ ПРАКТИКИ =
Идея матричной организации созрела в фирмах, работающих в областях высоких технологий, которым необходимо было интегрировать несколько функциональных специальностей для работы над группами проектов, и из-за недостаточности ресурсов они вынуждены были распределять время работы специалистов между отдельными проектами. Одновременно технические потребности проекта потребовали более целостного системного подхода, чем это позволяла функциональная организация. Раньше, когда проект, связанный с высокими технологиями, как, например, разработка нового продукта, инициировался фирмой, он начинал свое существование в отделе исследований и разработок (R amp; D). Там разрабатывались концепции и Идеи, и результаты передавались в технический отдел, где иногда весь продукт полностью переделывали. Затем работа переходила в производственный отдел, где продукт опять-таки иногда подвергался полной переделке с целью обеспечить возможность его производства на существующем оборудовании и с применением существующих операций. Такой последовательный подход к произ
водству продукта был длительным, и зачастую конечный продукт абсолютно не соответствовал первоначальным спецификациям.
При возрастающей важности сроков выхода на рынок компании отказались от последовательного подхода к разработке продукта и применили более целостный подход, который они назвали одновременной разработкой. Он заключается в активном вовлечении всех смежных областей специализации на протяжении процесса дизайна и разработки. Например, этот подход был использован корпорацией Chrysler Corp. для проектирования новой линии автомобилей SC, в том числе и популярного седана «Неон». С самого начала специалисты из отделов маркетинга, технического, проектного, производственного, обеспечения качества и других отделов, важных для производства автомобиля, были задействованы на каждой стадии проекта. Были достигнуты не только все цели, но и сам проект был выполнен на полгода раньше намеченного срока.
Необходимо отметить, что принцип одновременной разработки может быть применен и в подразделениях, непосредственно занимающихся проектом, и в матричной структуре. Единственная разница в том, что в последнем случае персонал работает над проектом не на постоянной основе, а скорее уделяет внимание и время одновременно большому количеству проектов и своим функциональным обязаностям. Сбалансированная матрица — классический тип, когда управляющий проектом отвечает за определение того, что нужно сделать, а функциональные управляющие — за то, как это будет сделано. Более конкретно, управляющий проектом вырабатывает общий план выполнения проекта, интегрирует вклад различных отраслей знаний, составляет графики и руководит работой. Функциональные управляющие отвечают за назначение специалистов и выполнение своего сегмента проекта согласно стандартам и графикам, составленным управляющим проектом. Совмещение «что и как» требует тесного сотрудничества обеих сторон и совместного одобрения технических и операционных решений. Проектная матрица — эта форма старается создать «ощущение» проектной команды в матричной среде. Управляющий проектом контролирует большинство аспектов проекта, включая и уступки масштабу и назначение функционального персонала. Управляющий проектом контролирует, когда и что делают специалисты, и имеет решающее слово в принятии решений. Функциональный управляющий руководит специалистами из своего отдела и дает свои рекомендации, когда это необходимо. В некоторых случаях отдел функционального управляющего может играть роль «субподрядчика» для проекта, в таком случае они больше контролируют специализированную работу. Например, разработка новых серий портативных компьютеров может потребовать привлечения специалистов других служб к работе внутри структуры проектной матрицы над дизайном и техническими параметрами. Когда спецификации определены, ответственность за окончательный дизайн и производство определенных компонентов (например, источник питания) может быть возложена на соответствующие функциональные группы
В функциональной матрице управляющий проектом, как правило, не участвуе т в оценке деятельности разрабочиков проекта. Это прерогатива только функционального управляющего. В сбалансированной матрице либо
оба управляющих дают свою оценку, либо управляющий проектом дает свои рекомендации функциональному управляющему, который и несет ответственность за формальную оценку работы отдельных служащих. Иногда компании хвастаются, что они используют сильную, ориентированную на проект матрицу, хотя при внимательном рассмотрении оказывается, что управляющие проектом принимают незначительное участие в оценке деятельности персонала и его стимулировании.
Матричная структура управления и вообще, и в частности имеет уникальные слабые и сильные стороны. Можно прежде всего отметить следующие преимущества матричных структур: Ресурсами можно пользоваться совместно, выполняя как многочисленные проекты, так и функциональные обязанности. Один работник может быть занят работой над несколькими проектами одновременно. Это уменьшает дублирование, типичное для структуры чисто проектной команды. Более сильный акцент на проект обеспечивается через формальное назначение управляющего проектом, ответственного за координацию и интеграцию работы, выполняемой различными отделами. Это помогает сохранять целостный подход к решению проблемы, часто отсутствующий в функциональных организациях. Так как проектная организация накладывается на функциональную, проект имеет доступ ко всему банку технологий и специальных знаний, которым владеют функциональные отделы. Более того, в отличие от независимых проектных команд, специалисты поддерживают отношения со своими функциональными группами, поэтому им есть куда вернуться после завершения работы над проектами. Матричная структура дает возможность гибко использовать ресурсы и специалистов в рамках фирмы. В некоторых случаях функциональные отделы могут выделить специалистов, которыми затем будет руководить управляющий проектом. В других случаях руководителем может быть функциональный управляющий.
чревата конфликтами и конкурентной борьбой за обладание ограниченными ресурсами. Борьба может развернуться между управляющими проектами, которые в первую очередь беспокоятся за свой проект. Матричный менеджмент нарушает управленческий принцип единоначалия. У разработчиков проекта, по меньшей мере, два руководителя — непосредственный функциональный управляющий и управляющий (один или несколько) проектом. Работа в матричной системе может быть исключительно напряженной и приводить к стрессам. Представьте себе, каково работать, когда три разных менеджера дают вам три взаимоисключающих указания. Теоретически присутствие управляющего проектом, координирующего работу, должно способствовать выполнению проекта. На деле принятие решений может завязнуть в вынужденных согласованиях между многочисленными функциональными группами. Это особенно часто происходит в сбалансированной матрице.
При рассмотрении трех вариантов матричной организации мы видим, что преимущества и недостатки не всегда типичны для всех трех разновидностей. Проектная матрица вероятнее всего усилит проектную интеграцию, уменьшит внутреннюю борьбу за власть и в конечном итоге улучшит контроль за проектными операциями и затратами. С другой стороны, может пострадать техническое качество, так как функциональные специалисты меньше контролируют свой вклад. И, наконец, может возникать автономная самозваная команда, так как у членов проектной команды часто возникает чувство принадлежности именно к этой команде.
Функциональная матрица скорее всего улучшит техническое качество работ, а также даст лучшую систему улаживания противоречий между проектами, так как функциональный управляющий занимается распределением персонала для работы над разными проектами. Проблема состоит в том, что функциональный контроль часто осуществляется за счет слабой проектной интеграции. Сбалансированная матрица может улучшить баланс между техническими и проектными требованиями, но это очень крупная система, и ее трудно создать и трудно ею управлять, и она, очевидно, может не выдержать многие проблемы, связанные с матричным подходом.