Содержание
Сегодня достаточно большой редкостью являются случаи, когда организационная структура проекта совпадает с организационной структурой предприятия или какой-либо ее частью.
Гораздо чаще сотрудники, в соответствии со штатным расписанием, распределены по функциональным подразделениям предприятия, а для выполнения проекта формируются специальные временные организационные структуры, называемые командами проекта и включающие представителей различных подразделений.
Для создания и функционирования команды проекта применяются определенные рецепты, которые обеспечивают эффективность выполнения этих процессов. Рецепты эти не являются универсальными и должны учитывать специфику предприятия — от его организационной структуры до производимого продукта.
Среди первых проблем, которые возникают при формировании организационных структур проекта и которые должны быть решены на уровне стандарта управления проектами, отметим проблемы, связанные с пересечениями функций административного управления и управления проектами.
Начальник отдела и руководитель проекта
Административное управление на предприятии реализуется через систему менеджмента. Ее ключевым звеном являются менеджеры среднего звена — начальники подразделений, в непосредственном подчинении которых находятся сотрудники предприятий. На проектно-ориентированных предприятиях смысл деятельности начальника подразделения состоит в том, чтобы «раздать», а точнее «продать» всех своих сотрудников в проекты.
Управление предприятием по проектам предполагает реализацию всей коммерческой, а может быть, и иной деятельности в форме проектов и получение прибыли через исполнение этих проектов. Соответственно смысл деятельности руководителя проекта состоит в том, чтобы «купить» необходимые ресурсы у начальников подразделений и с их помощью выполнить проект.
Исходя из ограничений бюджета проекта руководитель проекта будет стремиться получить специалиста более высокой квалификации и по минимальной цене. Для начальника подразделения приоритетом является бюджет его подразделения, и поэтому он, наоборот, постарается поднять цену и предложит менее квалифицированный ресурс. Для того чтобы обеспечить соблюдение общекорпоративных интересов, необходимо выстроить систему отношений, которая помогла бы избежать конфликтов или по крайней мере предусматривала бы формальные механизмы их разрешения.
При этом возникает целый ряд обязательств как со стороны начальника подразделений по отношению к проектам, так и со стороны руководителей проектов к ресурсным подразделениям. Эти обязательства должны быть зафиксированы в соответствующих положениях и должностных инструкциях, а особые случаи могут описываться дополнительно в планах управления проектами.
Часто возникает путаница, какие функции относятся к компетенции начальника подразделения, а какие — к компетенции руководителя проекта. Особенно это характерно для случаев, когда «руководитель проекта» — не должность в штатном расписании предприятия, а только проектная роль, которую может исполнять, в том числе и начальник подразделения. В таблице приведено несколько примеров, иллюстрирующих эти различия в некоторых областях, где административное и проектное управление имеют наиболее очевидные точки соприкосновения.
Разделение ответственности при административном управлении и управлении проектами
| Сфера ответственности Область управления | Ответственность начальника подразделения(административное управление) | Ответственность руководителя проекта (управление проектами) |
| Планирование и контроль | Формирование бизнес-плана отдела Планирование бюджета отдела Контроль «по вехам» Отчетность перед руководством предприятия |
Детальный календарный план проекта Планирование бюджета проекта Оперативный контроль кода проекта Отчетность перед руководством |
| Человеческие ресурсы | Прием на работу и увольнение Централизованное выделение ресурсов Контроль дисциплины Организация обучения |
Формирование команды проекта Анализ и оценка работы сотрудников Применение санкций и поощрений Регулирование конфликтов |
| Реализуемые продукты (на примере информационных систем) | Методология создания ИС Инструментарий разработки ИС Авторский надзор |
Проектирование ИС Разработка ИС Внедрение ИС |
(Безусловно, приведенные в таблице примеры надо воспринимать только как толчок к более детальному планированию оргструктурных отношений. Так, приписывание функции «Применение санкций и поощрений» только к руководителю проекта (равно как и только к руководителю подразделения) вызывает законные протесты «другой стороны», в то же время установление эффективного баланса прав и ответственности в этой области производится весьма непросто. Аналогично права и ответственность в областях «Прием на работу и увольнение» или «Инструментарий разработки ИС», закрепленные только за руководителем подразделения, могут мешать руководителю проекта привлекать внешних сотрудников или выбирать специфический инструментарий для нетипичных разработок (конечно, все это нужно делать только в оправданных случаях). В связи с этим надо учитывать, что и при создании реальных оргструктур говорится о нескольких «типовых организационных структурах» в нормативных документах предприятия (см., в частности, далее эту заметку), причем «для различных видов проектов, например, в соответствии с принятой классификацией». Однако при возникновении нетипичного — для данного предприятия — проекта вполне естествен пересмотр или уточнение типовых положений, например, расширение полномочий руководителя проекта.
Исполнитель
Но управление — управлением, а для выполнения работ по проектам нужны исполнители, и эти исполнители набираются из состава сотрудников функциональных подразделений. Таким образом, рабочее время каждого сотрудника проектно-ориентированного предприятия делится на проектное время и непроектное. Непроектным временем сотрудника распоряжается начальник подразделения, проектным — руководители проектов, в которых задействован сотрудник. Следовательно, сотрудник единовременно имеет не одного, а двух, а то и больше непосредственных начальников, распоряжения которых он должен выполнять и перед которыми он должен отчитываться о выполнении работ.
Оптимальный период отчетности в проектно-ориентированных организациях составляет одну неделю. Задания по проектам, включая изменения, уточнения, дополнения, могут поступать исполнителю по нескольку раз в день. Даже элементарные учет и отчетность в этих условиях могут вырасти для сотрудника в самостоятельную и часто трудноразрешимую проблему.
Для того чтобы эта ситуация не стала источником конфликтов и стрессов, должны быть созданы четкие и простые в исполнении правила, закрепленные в стандарте на уровне проектных процедур. Эти правила должны регламентировать порядок выдачи и согласования заданий, учета затрат рабочего времени, разрешения конфликтных ситуаций и т. д.
Одним из главных критериев качества проектных процедур должно служить время, необходимое сотруднику для их исполнения. Если это время превышает один час в неделю, процедуры должны быть усовершенствованы. Путей совершенствования более чем достаточно. Это и изменение учетной политики, и создание специальных административных единиц (как в штатном расписании, так и в командах проектов), и, наконец, использование соответствующих информационных технологий (управление документами и управление работами).
Команда проекта
При формировании организационных структур проектов должны соблюдаться два основных принципа — разделение уровней ответственности и разделение областей ответственности. В этом смысле решения напрямую связаны с комплексностью и сложностью проектов.
Для простых проектов обычно бывает достаточно двух уровней управления. Руководитель проекта осуществляет оперативное управление ходом проекта, обеспечивает выполнение запланированных работ, готовит предложения по изменениям в планах, координирует технические и людские ресурсы и т. д. Полномочия по изменению сроков, бюджета, содержания и границ проекта относятся к верхнему уровню управления и принадлежат спонсору или куратору проекта. Взятая за основу, эта схема может развиваться как вниз (руководители по подпроектам), так и вверх (управляющие комитеты мультипроектов или проектных программ).
Похоже выглядит ситуация и с точки зрения областей ответственности. В простых проектах привычной является ситуация, когда руководитель проекта сам выполняет все функции управления проектами (в том числе управление рисками, конфигурацией, качеством и т. д.). В сложных проектах руководитель проекта вынужден создавать собственный штат, распределяя отдельные функции управления между своими сотрудниками.
Распределение ответственности в части содержательных решений по продуктам проекта обычно закрепляется на уровне рабочих групп. При этом если в простых проектах руководитель проекта может играть по совместительству и роль системного архитектора (если речь идет об ИТ-проектах), то для сложных проектов это вряд ли целесообразно.
Таким образом, важными элементами стандарта являются описание типовых организационных структур для различных видов проектов, например в соответствии с принятой классификацией, и шаблоны и инструкции персонала проекта на уровне проектных ролей.
Кроме того, предметом описания в стандарте предприятия могут быть и самые различные стороны функционирования команды проекта — от процессов ее формирования и роспуска до процедур учета и отчетности, упомянутых выше. Очевидно, эти процессы и процедуры не могут замыкаться внутри проекта и должны затрагивать более общий контекст корпоративных отношений.
Например, часто, в силу сложившейся на предприятии практики, не все функции управления проектом могут быть отчуждены от ряда специализированных подразделений предприятия и переданы команде проекта путем делегирования в ее состав соответствующих специалистов. Для таких случаев должны быть предусмотрены и регламентированы процедуры взаимодействия команды проекта с этими подразделениями (например, с финансовым департаментом, планово-экономическим департаментом, службой логистики и т. д.).
Источник: материалы сайта training-partner.ru
Автор: Ципес Григорий, Товб Александр
