Представим теперь, что в функционально построенной организации формиру­ются несколько проектов, использующих сотрудников из разных подразделений, т. е. число горизонтальных или псевдогоризонтальных связей увеличивается (рис. 2.3). Предположим, что теоретически все сотрудники функциональных подразделений данной компании доступны для выполнения работ проекта, при этом они остаются вовлеченными в свою текущую работу. Руководители проектов выделены и имеют необходимые полномочия. Их позиции могут быть введены в штатное расписание компании (при подготовке соответству­ющих приказов и должностных инструкций) или формироваться на время. Их число меняется по мере появления новых проектов и завершения старых, но они не исчезают совсем. Проектная деятельность в компании имеет боль­шое значение. Это матричная организация, или как мы увидим далее, - слабоматричная.

Рис. 2.3. Зарождение проекта в матричной организации. Слабая матрица

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

Существуют три разновидности матричной структуры организации:

1. Слабая, или мягкая, матрица. Руководитель проекта отвечает за координацию задач по проекту и имеет ограниченную власть над используемыми ресурсами. Приоритет проектов, чаще всего, ниже текущих функциональ­ных задач предприятия. Сотрудники, привлеченные руководителем про­екта, могут быть легко отозваны, если функциональные задачи требуют более срочного решения. Недостатком подхода может являться несба­лансированность между ответственностью, приданной руководителю про­екта, и недостатком необходимых полномочий. Фактически руководители проекта ниже функциональных руководителей по статусу. При такой ситуации очень важно проговорить степень полномочий и ответствен­ности у руководителя проекта с руководством компании, зафиксировав их в письменном виде. Слабая матрица определяет такую ситуацию, ког­да руководитель проекта вводится на период реализации проекта и под­чиняется руководителю более высокого уровня, а команда работает над проектом неполный рабочий день (и чаще - меньше его половины). Про­ект может иметь только одного сотрудника на полный рабочий день, на­пример руководителя проекта. Функциональные подразделения скорее не приписывают сотрудников к проекту, а дают их взаймы. Руководитель проекта может требовать техническую поддержку, особое программное обеспечение, дополнительное внешнее тестирование и пр. Приоритеты могут расставляться высшим руководством или быть результатом перего­воров между руководителем проекта и функциональным руководителем.

2. Сбалансированная матрица. Руководитель проекта координирует все работы и разделяет ответственность за достижение цели с руководите­лями функциональных подразделений, которые отвечают за содержание выполняемых их сотрудниками или подразделениями работ и их качество. Баланс ответственности может быть нарушен при усилении вла­сти той или иной стороны (проектного или функционального руковод­ства). Приоритет проекта может быть выше или ниже функциональных задач, что определяется интересами текущего момента. При существо­вании нескольких проектов в компании часть из них может управляться по схеме: «приоритет проекта ниже приоритета функциональных обла­стей», и это характерно для проектов развития или коммерчески затрат­ных проектов; другая часть - по противоположной схеме: «приоритет проекта выше приоритета функциональных областей», что присуще ин­вестиционным или коммерчески привлекательным проектам.

Рис. 2.4. Зарождение проекта в матричной организации. Сильная матрица

3. Жесткая, или сильная, матрица (рис. 2.4). Руководитель проекта несет полную ответственность за выполнение проекта, а руководители функциональных подразделений отвечают за назначение персонала на конкретные задачи проекта и качественное их выполнение. Например, к проекту могут быть «приписаны» три человека из производственного отдела на пол­ный день, сотрудник из отдела маркетинга на половину рабочего дня или сотрудник финансового отдела с 25%-ным вовлечением. Руководи­тель проекта управляет выделенной ему командой, контролируя, когда и что будут делать сотрудники, входящие в проект, контролируя, кто будет приписан к проекту и какая технология будет использоваться. Функциональных руководителей при таком подходе часто называют владельцами ресурсов, которые выделяют ресурс (персонал) в проект и одновременно поддерживают его качество в своем функциональном звене. Руководитель проекта в данном случае имеет возможность осуществлять более эффективный контроль их работы в проекте, и влияние организа­ции на результаты проекта ослабевает. Приоритет проекта выше функциональных задач, которые играют вспомогательную обеспечивающую роль. Основная проблема данного подхода связана с необходимостью оптимальной загрузки членов команды работой, соответствующей их ква­лификации, поскольку объем и содержание работ изменяются по ходу проекта. Если при выделении персонала в проект часть сотрудников в функциональных подразделениях остается невостребованной, то эти по­зиции в целях снижения затрат компании должны быть расформирова­ны, переведены в другие отделы, а может быть, и удалены. Руководи­тель проекта может быть подотчетен руководителю портфеля проектов, который осуществляет наблюдение также над другими проектами.

Отметим сильные стороны организации проекта по принципу матричных схем:

Проекту уделяется основное внимание; руководитель проекта несет полную ответственность за управление проектом, временем и сметой (эту положительную черту матричная организация разделяет с чисто проектной, о которой речь пойдет далее);

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

Нет большой озабоченности относительно того, что будет, когда проект закончится; даже если команда проекта плотно работает над ним, члены команды все равно тесно связаны со своим функциональным «домом»;

Матричная организация очень гибко реагирует на требования заказчи­ка; подобным же образом она реагирует на требования самой компании;

Проект имеет своих представителей в руководстве организации, благо­даря чему сохраняется общность политики, практики и процедур; при всех прочих обстоятельствах эта общность создает доверие к проекту;

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

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

Слабые стороны такого подхода:

Матричная организация очень дорога в использовании и в настоящий момент невозможна без качественной корпоративной информационной системы, что приводит к дополнительным расходам; кроме того, ее внедрение в практическую деятельность - довольно долгое занятие (компания Toyota внедряла матричную структуру 10 лет);

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

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

Очень трудно отказаться от проекта, так же, как в чисто проектной организации; появляется привычка к проектной деятельности;

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

Нарушается принцип единоначалия и формируется двойной фокус принятия решений;

Присутствует сложность оценки персонала, конфликт приоритетов, а также политическая напряженность и конкуренция среди руководи­телей проектов.

Когда же выгодно использовать ту или иную матрицу, а когда это делать не надо?

Ситуационные факторы, приводящие к успешному применению матрицы:

Проекты с высокой уникальностью (вывод типовых продуктов на новые рынки; проекты с уникальными новыми контрактами, независимыми от других контрактов; проекты в сложных, быстро меняющихся условиях; проекты с уникальными продуктами, но с типовой технологией);

Проекты, сфокусированные на будущих потребителях, где ответная реакция заказчика и решение его проблем являются критичными;

Проекты с особым вниманием к минимизации времени и издержек;

Высокотехнологические проекты с привлечением высококомпетентных участников на стадии разработки и менее компетентных - в последую­щих стадиях.

Ситуационные факторы, при которых матрица не работает:

Проекты с низкой уникальностью (проекты с предсказуемыми изменениями окружающей среды);

Проекты с длительными жизненными циклами;

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

Географически разнесенные проекты, когда затруднено взаимодействие участников.

Классическая теория управления проектами и большинство известных методик базируются на том, что для успеха проекта нужно создать определенные (благоприятные) условия. А если создать их нельзя, то от проекта лучше отказаться. Но что делать, когда условия для проекта неблагоприятные, а отказаться от него невозможно? Именно для таких условий предназначены рекомендации, которые мы даем в этом цикле статей. Первая статья цикла вышла в №12/2008. Во второй части речь пойдет об организации управления проектом.

Часть 2. Организация управления проектами

Подходы к управлению проектами

Прежде всего давайте поговорим об изменении подходов к управлению проектами. На рис. 1 представлена схема типичной организации такого управления. Согласно этой схеме на стороне заказчика ключевые роли в проектном управлении играют спонсор проекта и менеджер проекта.

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

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

Со стороны исполнителя ключевые роли играют бизнес-менеджер и менеджер проекта.

Бизнес-менеджер несет ответственность за успешное выполнение проекта. Кроме того, он представляет исполнителя в договорных отношениях с заказчиком.

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

Такая схема предполагает активное участие в проекте внешней компании-исполнителя и разделение ею ответственности за успех/неудачу проекта. Однако в неблагоприятных условиях ответственность за внедрение вынужден брать на себя заказчик, то есть предложенная схема должна измениться. Прежде всего - заказчик и исполнитель должны поменяться местами. У заказчика, как правило, нет достаточного количества людей, чтобы выделить для них от­дельные роли. Поэтому роли в команде поддержки управления проектом сокращаются, а функции перераспределяются (на рис. 1 пунктирными линиями отображена передача функций и полномочий).

Кроме того, несколько изменяется понимание ключевых ролей в управлении проектом. В нашем понимании менеджер проекта - это не роль, а специальность (project ma­nager - специалист по управлению проектами). В России существует приблизительный аналог - главный инженер проектов. Гораздо шире становятся функции координатора проекта (наименование роли остается таким же): это специалист по управлению проектами. Координатор осуществляет оперативное управление ходом проекта согласно проектным документам, которые приняты управляющим советом или руководителем проекта. Функция координатора исключительно важна, но объективно конфликтна, поскольку по одну сторону от него находится высшее руководство, которое, как правило, недовольно ходом проекта, а по другую - пользователи и средний менеджмент, которых заставляют выполнять дополнительную работу (особенно на этапе опытной эксплуатации, когда необходим двойной ввод), менять привычную методологию, приемы и вообще нарушают сложившийся уклад жизни.

Менеджер проекта (со стороны исполнителя) в нашем понимании - это руководитель группы внешних консультантов. Далее мы будем рассматривать схему организации проектов силами заказчика (рис. 2) с указанным выше изменением терминов.

Организационные структуры управления проектами

Согласно PMBOK выделяются следующие виды организационных структур управления проектами:

• линейно-функциональная;
• проектная;
• матричная.

В области ИТ линейно-функциональная схема используется для мини-проектов, связанных с модернизацией автоматизированных систем и внесением в них изменений. Проектная структура применяется разработчиками ПО, к которым службу АСУ предприятия можно отнести с большой натяжкой. Матричная структура отражает закрепление в механизме проектного управления двух направлений руководства:

• вертикальное направление - управление функциональными и линейными структурными подразделениями компании;
• горизонтальное направление - управление отдельными проектами, программами, для реализации которых привлекаются человеческие и иные ресурсы различных подразделений компании.

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

В табл. 1 приводятся принципы выбора организационных структур проекта и соответствующие примеры из об­­ласти ИТ.

Сильный и слабый руководители проекта

Для структурирования типов управления проектами в неблагоприятных условиях имеет смысл ввести понятие «сильного» и «слабого» руководителя . Надо сказать, что в PMBOK есть понятие «полномочия менеджера проекта», но оно недостаточно конкретно. По моему опыту в реальной жизни наблюдается два ярко выраженных случая, которые мы и называем «сильным» и «слабым» руководителем проекта.

Наименования «слабый» и «сильный» руководитель не относятся к личным качествам руководителя, а определяют уровень его полномочий. У сильного руководителя есть мощный административный ресурс, а у слабого его нет. Кроме того, особенностью сильного руководителя является, как правило, заинтересованность в результатах проекта (проект находится в сфере его деятельности), а также возможность влиять на его финансирование. Соответственно у слабого руководителя эти возможности отсутствуют. Типичным представителем слабого руководителя является начальник ИТ-службы или высокопоставленный, но незаинтересованный руководитель.

На рис. 3, 4, 5 изображены схемы матричных оргструктур, причем выделяются две формы управления слабой матрицей. В случае «слабого» руководителя проекта (рис. 3) управление членами проектной команды осуществляется не напрямую, а через функциональных менеджеров. Обычно это происходит, когда в качестве руководителя проекта выступает руководитель одного из функциональных подразделений или главный специалист. «Сильный» же руководитель проекта (рис. 4) имеет право давать задания сотрудникам функциональных подразделений напрямую. Обычно это человек, имеющий высокий статус в организационной иерархии (либо первое лицо, либо его заместитель).

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

Органы управления проектом

В крупных проектах предлагается создавать коллективные органы управления, например:

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

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

• управляющий совет - по функциям заменяет комитет по управлению;
• методический совет - заменяет комитеты по контролю за изменениями и по анализу спорных вопросов;
• координационный комитет - это управляющий плюс методический совет.

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

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

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

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

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

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

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

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

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

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

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

Алексей Головин
Заместитель исполнительного директора
по бизнес-процессам и информационным технологиям
ОАО «Калужский завод “Ремпутьмаш”»
[email protected]

Рассмотрим в качестве примера ситуацию, когда в чисто иерархической организации

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

большего числа людей, чем большее количество уровней иерархии требуется

Рис. 4. Функциональная структура.

Матричная структура

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

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

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

Основной недостаток матричной структурынарушение принципа единоначалия в организации. Члены проектной команды порой не могут решить, кому они прежде всего подчиняются - своему линейному руководителю или менеджеру проекта. Двойственность положения участников и двоевластие нередко порождают конфликты внутри фирмы по таким важным вопросам, как выделение специалистов и распределение ресурсов.

Упрощенная матричная структура

Рис. 5. Упрощенная матричная структура организации.

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

Сбалансированная матричная структура

Рис. 6. Сбалансированная матричная структура организации

При таком подходе (Рис.6) из числа служащих одного из функциональных подразделений назначается менеджер проекта. Оставаясь в составе своего подразделения, этот человек, тем не менее, почти все свое время тратит только на управление проектом. При этом ему передаются некоторые полномочия по управлению вовлеченным в проект персоналом из других подразделений.

Усиленная матричная структура

К имеющимся функциональным подразделениям добавляется отдел менеджеров проекта (рис.7). Служащие этого подразделения занимаются исключительно управлением вверенными им проектами и не имеют других функциональных обязанностей. При этом менеджер проекта обладает существенными полномочиями при распределени ресурсов.

Рис.7. Усиленная матричная структура организации

Проектная структура

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

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

Такая структура наиболее эффективна при наличии больших проектов с жизненным циклом более 2 лет.

Организация управления проектами

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

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

Куратор проекта — представитель руководства (обычно член координационного совета), курирующий работы по проекту.

Менеджер проекта — индивидуум, отвечающий за управление проектом.

Команда проекта — люди, прямо или косвенно отчитывающиеся по проекту.

Команда управления проектом — члены команды проекта, непосредственно участвующие в процессах управления проектом.

Функциональная структура

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

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

Проектная структура

Прямой противоположностью функциональной является проектная структура управления, в которой у каждого члена команды проекта также один непосредственный руководитель, но подразделения организованы по проектному принципу: команды управления проектами образуют собственные подразделения (рис. 2), возглавляемые менеджерами соответствующих проектов. Такие структуры обычно используются проектно-ориентированными организациями, выполняющими проекты для других, — например, консалтинговыми компаниями.

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

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

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

2. После завершения проекта возникают проблемы с трудоустройством персонала проектных подразделений: их места в функциональных подразделениях могут быть заняты.

3. Специалисты вырываются из своей профессиональной среды, что препятствует их профессиональному росту.

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

Матричные структуры

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

Матричные структуры управления обычно используются, когда проекты повторяются, но не являются рутинными.

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

Экспедитор проекта

Экспедитор проекта — это сотрудник одного из функциональных подразделений, которому поручается координировать потоки информации между членами команды проекта (рис. 4). У него нет иных полномочий, кроме права давать рекомендации. Такая система работает, только если у экспедитора имеется достаточное влияние (часто неформальное), и применима только для не слишком важных, небольших и коротких проектов.

Координатор проекта

Координатор проекта подчиняется непосредственно руководству предприятия и часто является и куратором проекта. У него есть право давать задания сотрудникам функциональных подразделений, хотя официальными полномочиями он не наделен. Обычно у координатора проекта высокий статус в функциональной организации (заместитель директора, главный специалист). В наших проектных институтах существует институт ГИПов, которые фактически являются координаторами проектов.

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

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

Сильная матрица

В сильной матричной структуре присутствует позиция менеджера проекта, наделенного полномочиями напрямую отдавать распоряжения и требовать отчетности от сотрудников функциональных подразделений, входящих в состав команды управления проектом. Менеджеры проектов в такой структуре не входят в функциональные подразделения, если не считать таковым проектный офис (отдел управления проектами, службу управления проектами, аналитический центр — названия могут быть разными). Члены команды управления проектом не выводятся из состава своих функциональных подразделений, но «откомандировываются» в команду проекта. С этого момента эти сотрудники обязаны своевременно и качественно выполнять задания менеджера проекта, причем качество их работы контролируется и руководителем соответствующего функционального подразделения (рис. 6).

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

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

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

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

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

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

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

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

3. Длительность. Для коротких проектов подойдет и функциональная структура, для проектов средней длительности лучше использовать матричную, для длительных проектов — проектную.

4. Число участников. Для проектов с небольшим числом участников можно использовать функциональную или слабую матричную структуру, для среднего числа участников — сильную матрицу, для проектов с большим числом участников — проектную структуру.

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

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

Проектный офис

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

Типичными подразделениями проектного офиса являются:

— аналитический центр, в котором ведутся компьютерные модели проектов;

— архив, в котором ведутся архивы проектной документации;

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

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

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

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

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

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

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

Организация проектного офиса — важный элемент и показатель зрелости системы управления проектами в организац

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

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

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

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

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

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

Другая форма матричной организации - слабая матричная организация (см. рис. 1.5). Как вы можете предположить, в этой структуре полную власть имеет функциональный менеджер. Руководители проектов в действительности являются координаторами или экспедиторами проектов с частичной ответственностью за их выполнение в слабой матричной организации. Руководители проектов имеют мало или почти не имеют власти, так же как в функциональной организации. С другой стороны функциональные менеджеры имеют большую власть и выполняют всю необходимую работу по распределению ресурсов. Руководитель проекта просто следит за его выполнением.

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

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

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

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