Организационная структура проекта и его внешнее окружение
Помимо системы взаимоотношений участников и содержания проекта, на его организационную структуру накладывает определенные требования внешнее окружение. Чем оно динамичнее, тем более гибкой и адаптивной должна быть организационная структура проекта. Чем стабильнее и прогнозируемее внешняя среда, тем эффективнее в применении «жесткие», механистические, бюрократические организации.
Любая организационная структура может быть реализована в различных по возможности адаптации вариантах. Здесь все зависит от степени регламентированности деятельности сотрудников, т.е., количества и детальности существующих правил и процедур выполнения работ, а также той степени, в которой сотрудники придерживаются этого документированного порядка. Это свойство можно обозначить как «уровень структуризации». В принципе, может существовать функциональная структура, которая по уровню структуризации значительно ниже, чем матричная структура, имеющая высокий уровень формализации внутренней деятельности.
Таким образом, по степени структуризации организационные структуры можно разделить на механистические и органистические.
Таблица 2.
Сравнительная характеристика механистических и органистических структур
| Механистические | Органистические |
| Общие характеристики | |
| Узкий фронт работ исполнителей | Широко определенные должностные обязанности |
| Большое количество подробных правил и процедур | Небольшое количество общих указаний |
| Четкая ответственность | Размытая ответственность |
| Иерархический принцип организации | Организация с перекрестными связями |
| Объективная система вознаграждения | Субъективная система вознаграждения |
| Объективные, формальные критерии отбора сотрудников | Субъективные критерии отбора сотрудников |
| Официальность и обезличенность | Неформальность |
| Условия применения | |
| Низкий уровень неопределенности и динамичности внешней среды | Высокий уровень неопределенности и динамичности внешней среды |
| Цели заранее известны и неизменны | Цели размыты и динамично меняются |
| Структурированность задач и проблем | Низкий уровень структурированности задач и проблем |
| Возможность использовать четкие измерители достигнутых результатов | Невозможность использовать четкие измерители достигнутых результатов |
| Работники реагируют на материальное поощрение | Работники мотивированы сложными потребностями |
| Власть понимается юридически | Власть подвергается сомнению, требует подтверждения со стороны подчиненных |
Команда проекта
Сегодня достаточно большой редкостью являются случаи, когда организационная структура проекта совпадает с организационной структурой предприятия или ее частью. Гораздо чаще сотрудники, в соответствии со штатным расписанием, распределены по функциональным подразделениям предприятия, а для выполнения проекта формируются специальные временные организационные структуры, называемые командами проекта. Эти структуры включают представителей различных подразделений предприятия.
Для создания и функционирования команды проекта применяются специальные методики. Они не являются универсальными и должны учитывать специфику предприятия – от его организационной структуры до производимого продукта.
Под формированием команды понимается процесс целенаправленного «построения» особого способа взаимодействия людей в группе (называемой командой), позволяющего эффективно реализовать их профессиональный, интеллектуальный и творческий потенциал в соответствии со стратегическими целями данной группы (команды). Команда в этом случае определяется как группа людей, взаимодополняющих и взаимозаменяющих друг друга в ходе достижения поставленных целей.
Одна из первых проблем, возникающих при формировании команды проекта – пересечение функций административного управления и функций управления проектами.
Административное управление на предприятии реализуется через систему менеджмента, ключевым звеном которого являются менеджеры среднего звена – начальники подразделений, в непосредственном подчинении которых находятся сотрудники предприятий. На проектно-ориентированных предприятиях смысл деятельности начальника подразделения состоит в том, чтобы «раздать», а точнее, «продать» всех своих сотрудников в проекты.
Управление предприятием по проектам предполагает реализацию коммерческой и иной деятельности в форме проектов и получение прибыли через исполнение этих проектов. Соответственно, смысл деятельности руководителя проекта состоит в том, чтобы «купить» необходимые ресурсы у начальников подразделений и с их помощью выполнить проект.
Исходя из ограничений бюджета проекта, руководитель проекта будет стремиться получить специалиста более высокой квалификации по минимальной цене. Для начальника подразделения основным приоритетом является бюджет его подразделения, поэтому он, наоборот, постарается поднять цену и предложит менее квалифицированный ресурс. Для того чтобы обеспечить соблюдение общекорпоративных интересов, необходимо выстроить систему отношений, которая помогала бы избежать конфликтов или, по крайней мере, предусматривала бы формальные механизмы их разрешения.
При этом возникает целый ряд обязательств как со стороны начальника подразделения по отношению к проектам, так и со стороны руководителей проектов к ресурсным подразделениям. Эти обязательства должны быть зафиксированы в соответствующих положениях и должностных инструкциях.
Часто возникает путаница, какие функции относятся к компетенции начальника подразделения, а какие – к компетенции руководителя проекта. Особенно это характерно для случаев, когда «руководитель проекта» - не должность в штатном расписании предприятия, а только проектная роль, которую может исполнять и начальник подразделения.
Таблица 2.
Разделение ответственности при административном управлении и управлении проектами
| Область управления | Сфера ответственности | |
| Ответственность начальника подразделения (административное управление) | Ответственность руководителя проекта (управление проектами) | |
| Человеческие ресурсы | Прием на работу и увольнение Выделение ресурсов Контроль дисциплины Организация обучения | Формирование команды проекта Анализ и оценка работы сотрудников Применение санкций и поощрений Урегулирование конфликтов |
| Планирование и контроль | Формирование бизнес-плана отдела Планирование бюджета отдела Контроль «по вехам» Отчетность перед руководством предприятия | Формирование календарного плана проекта Планирование бюджета проекта Оперативный контроль хода проекта Отчетность перед руководством |
Но управление – управлением, а для выполнения работ по проектам нужны исполнители, и эти исполнители набираются из состава сотрудников функциональных подразделений. Таким образом, рабочее время каждого сотрудника проектно-ориентированного предприятия делится на проектное время и непроектное. Непроектным временем сотрудника распоряжается начальник подразделения, а проектным – руководители проектов, в которых задействован сотрудник. Следовательно, сотрудник одновременно подчиняется не одному, а двум или более непосредственным начальникам, распоряжения которых он должен выполнять и перед которыми он должен отчитываться.
Оптимальный период отчетности в проектно-ориентированных организациях составляет одну неделю. Задания по проектам, включая изменения, уточнения, дополнения, могут поступать исполнителю по несколько раз в день. Даже элементарный учет и отчетность в этих условиях могут вырасти для сотрудника в самостоятельную и трудноразрешимую проблему.
Для того чтобы эта ситуация не стала источником конфликтов и стрессов, должны быть созданы четкие и простые в исполнении правила, закрепленные в стандарте на уровне проектных процедур. Эти правила должны регламентировать порядок выдачи и согласования заданий, учета затрат рабочего времени, разрешения конфликтных ситуаций.
Одним из главных критериев качества проектных процедур должно служить время, необходимое сотруднику для их исполнения. Если это время превышает один час в неделю, процедуры должны быть усовершенствованы.
Пути усовершенствования процедур отчетности:
· изменение учетной политики;
· создание специальных административных единиц (проектных офисов);
· использование информационных технологий (управление документами и управление работами).
При формировании организационных структур проектов должны соблюдаться два основных принципа – разделение уровней ответственности (по вертикали) и разделение областей ответственности (по горизонтали). В этом смысле решения напрямую связаны со сложностью и комплексностью проектов.
Для простых проектов обычно бывает достаточно двух уровней управления. Руководитель проекта осуществляет оперативное управление ходом проекта, обеспечивает выполнение запланированных работ, готовит предложения по изменениям в планах, координирует технические и людские ресурсы. Полномочия по изменению сроков, бюджета, содержания и границ проекта относятся к верхнему уровню управления и принадлежат высшему руководителю, называемому спонсором, куратором или патроном проекта. Взятая за основу, эта схема может развиваться как вниз (руководители по подпроектам), так и вверх (управляющие комитеты мультипроектов или программ).
Похоже выглядит ситуация и с точки зрения областей ответственности. В простых проектах привычной выглядит ситуация, когда руководитель проекта сам выполняет все функции управления проектом (в том числе управление рисками, качеством, конфигурацией). В сложных проектах руководитель вынужден создавать собственный штат, распределяя отдельные функции управления между своими сотрудниками.
Очевидно, процедуры формирования команды проекта и процессы учета и отчетности не могут замыкаться внутри проекта и должны затрагивать более общий контекст корпоративных отношений. Например, в силу сложившейся на предприятии практики не все функции управления проектом могут быть отчуждены от специализированных подразделений предприятия и переданы команде проекта путем делегирования специалистов. Для таких случаев должны быть предусмотрены и регламентированы процедуры взаимодействия команды проекта с этими подразделениями (например, с финансовым департаментом, планово-экономическим, службой логистики и др.).
На рис. Приведена схема формирования команды проекта и ее взаимодействия со смежными службами, характерная для компании – системного интегратора.
Пример формирования команды проекта
Рассмотрим на примере, как формируется команда проекта в компании, организационная структура которой построена по матричному типу, т.е., предполагает существование функциональных подразделений, которые предоставляют персонал, необходимый для реализации проектов.
Этап 1. Менеджер проекта формирует календарный план проекта, определяя роли и квалификацию участников проекта, а также их занятость в проекте. Эта информация фиксируется в системе календарно-ресурсного планирования. Затем эти сведения передаются в корпоративную систему управления персоналом, которая предоставляет менеджеру информацию о доступных ресурсах, удовлетворяющих требованиям проекта.
Этап 2. Менеджер проекта готовит заявку на персонал проекта, которая согласуется руководителями соответствующих ресурсных подразделений. При возникновении конфликта ресурсов проблемы передаются на уровень спонсора проекта. Возникающая переписка регистрируется на формальном уровне в корпоративной системе управления документооборотом. Продвижение документов обеспечивается корпоративной системой управления бизнес-процессами.
Этап 3. После того как ресурсы выделены, менеджер проекта формирует задания исполнителям и фиксирует их в системе календарного планирования, а руководители ресурсных подразделений вносят соответствующие изменения в статусы выделенных в проект сотрудников.
Стадии существования КМП
Период существования КМП всегда связан с началом и окончанием проекта. Поэтому выделяют пять стадий существования КМП.
§ Образование (forming) – члены команды объединяются со стремлением к сотрудничеству.
§ Интенсивное формирование (storming) – после начала совместной работы оказывается, что мнения членов команды относительно способов достижения целей проекта и подходов к его осуществлению различны, что может приводить к спорам и даже к конфликтам.
§ Нормализация деятельности (normalizing) – члены команды приходят к взаимному согласию в результате переговоров и нахождения компромиссов и разрабатывают нормы, на основании которых будет построена их дальнейшая работа.
§ Исполнение планов по выполнению проекта (performing) – после того, как мотивация членов команды и эффективность ее работы возрастают, процесс осуществления проекта стабилизируется, и команда проекта может работать с высокой эффективностью на протяжении всего периода его осуществления.
§ Трансформация команды или ее расформирование (transforming) – завершение работы команды по мере завершения работы над проектом требует решения вопроса о будущей работе ее членов. К окончанию проекта эффективность его выполнения может либо возрасти (члены команды концентрируют усилия на завершении задачи, имея достаточно четкую перспективу своего будущего), либо понизиться (члены команды испытывают сожаление по поводу окончания их совместной работы, особенно если их будущее не определено).
На практике все эти стадии проявляются в разных формах, и очень часто Команды «разваливаются», так и не дойдя не только до эффективного исполнения проекта, но и до стадии нормализации деятельности. Это зависит от общего уровня управленческой профессиональной культуры как в организации, так и вокруг нее. Искусство управляющего (руководителя, лидера) Команды состоит в том, чтобы обеспечить конструктивный переход команды проекта из одной жизненной фазы (стадии) проекта в другую в рамках проектной деятельности и довести проект до успешного завершения.
Особо следует учитывать при формировании команды то, что эффективная КМП не может быть создана «вообще» под любые проекты. Под каждый конкретный проект нужно создавать КМП, наиболее адекватную именно для него. Причем речь идет не о замене персонального состава, а о перераспределении управленческих ролей, взаимосвязей между членами КМП, ответственности и т. п. Иначе – возложение исполнения нового проекта на команду другого проекта без ее «технологической настройки» на выполнение иных уникальных задач (напомню: любой проект уникален по своему определению) почти всегда приводит к неадекватности и неэффективности командных действий по отношению к новому проекту.
Следует также учитывать, что КМП изменяется по мере перехода проекта от одной его фазы к другой. Изменения касаются не столько персональных участников проекта, сколько перераспределения ролей, функций и ответственности среди членов КМП. А это означает, что по мере развития проекта одни люди, имеющие «вес» и значимость на одной фазе проекта, при переходе в другую фазу будут терять свой «вес» в нем. Конфликт интересов очевиден, но разрешается такой конфликт с большим трудом и часто с большими потерями для проекта. Искусство управляющего проекта в том и состоит, чтобы конфликт перевести в конструктивное русло.