При формировании организационных структур проектов должны соблюдаться два основных принципа — разделение уровней ответственности и разделение областей ответственности. В этом смысле решения напрямую связаны с комплексностью и сложностью проектов.
Для простых проектов обычно бывает достаточно двух уровней управления. Руководитель проекта осуществляет оперативное управление ходом проекта, обеспечивает выполнение запланированных работ, готовит предложения по изменениям в планах, координирует технические и людские ресурсы и т. д. Полномочия по изменению сроков, бюджета, содержания и границ проекта относятся к верхнему уровню управления и принадлежат высшему руководителю, называемому спонсором, куратором или патроном проекта. Взятая за основу, эта схема может развиваться как вниз (руководители по подпроектам), так и вверх (управляющие комитеты мультипроектов или программ).
Похоже выглядит ситуация и с точки зрения областей ответственности. В простых проектах привычной является ситуация, когда руководитель проекта сам выполняет все функции управления проектами (в том числе управление рисками, конфигурацией, качеством и т. д.). В сложных проектах руководитель проекта вынужден создавать собственный штат, распределяя отдельные функции управления между своими сотрудниками.
Распределение ответственности в части содержательных решений по продуктам проекта обычно закрепляется на уровне рабочих групп. При этом если в простых проектах руководитель проекта может играть по совместительству и роль системного архитектора (если речь идет об ИТ-проектах), то для сложных проектов это вряд ли целесообразно.
Таким образом, важным элементом стандарта является описание типовых организационных структур для различных видов проектов, например, в соответствии с принятой классификацией и шаблоны инструкции персонала проекта на уровне проектных ролей.
Кроме того, предметом описания в стандарте могут быть и самые различные стороны функционирования команды проекта — от процессов ее формирования и роспуска до процедур учета и отчетности, упомянутых выше.
Формирование команды проекта
Пример: Процесс формирования команды проекта в компании, организационная структура которой построена по матричному типу
Напомним, матричная организационная структура предполагает существование в компании функциональных (ресурсных) подразделений, которые предоставляют персонал, необходимый для реализации проектов. Интересы проекта в рассматриваемом процессе представляет менеджер проекта, интересы ресурсного подразделения— его руководитель. Интересы компании в целом представляет спонсор проекта, являющийся, как правило, и топ-менеджером компании.
Этап 1. Менеджер проекта формирует календарный план проекта, определяя роли и квалификацию участников проекта, а также их занятость в проекте. Эта информация фиксируется в системе календарно-ресурсного планирования. Затем эти сведения передаются в корпоративную систему управления персоналом, которая предоставляет менеджеру проекта информацию о доступных ресурсах, удовлетворяющих требованиям проекта.
Этап 2. Менеджер проекта готовит заявку на персонал проекта, которая согласуется руководителями соответствующих ресурсных подразделений. При возникновении конфликта ресурсов проблемы эскалируются на уровень спонсора проекта. Возникающая переписка регистрируется на формальном уровне в корпоративной системе управления документооборотом. Продвижение документов обеспечивается корпоративной системой управления бизнес-процессами (workflow).
Этап 3. После того как ресурсы выделены, менеджер проекта формирует задания исполнителям и фиксирует их в системе календарно-ресурсного планирования, а руководители ресурсных подразделений вносят соответствующие изменения в статусы выделенных в проект сотрудников.
Очевидно, эти процесс и процедуры не могут замыкаться внутри проекта и должны затрагивать более обший контекст корпоративных отношений. Например, часто в силу сложившейся на предприятии практики не все функции управления проектом могут быть отчуждены от специализированных подразделений предприятия и переданы команде проекта путем делегирования в ее состав соответствующих специалистов. Для таких случаев должны быть предусмотрены и регламентированы процедуры взаимодействия команды проекта с этими подразделениями (например, с финансовым департаментом, планово-экономическим департаментом, службой логистики и т. д.).
На рисунке 3.2 приведена схема формирования команды проекта и ее взаимодействия со смежными службами, характерная для компании — системного интегратора.
Для предприятий, заказывающих выполнение ИТ-проектов сторонним организациям, схема формирования команд проектов базируется на распределении ролей заказчика и исполнителя в проекте. В качестве примера рассмотрим проект внедрения отраслевых и корпоративных информационных систем.
Внедрение таких систем неизбежно нарушает сложившийся баланс интересов различных заинтересованных сторон в компании, внедряющей систему, и в силу этого требует применения специальных методов управления. Функция руководства созданием (внедрением) корпоративной информационной системы (КИС) не может быть делегирована какому-либо одному, даже специализированному ИТ-подразделению. Роль такого подразделения должна состоять прежде всего в общей организации и координации процесса, в согласовании позиций участвующих в процессе сторон, но не в руководстве процессом (см. рис. 3.3).
Команда проекта формируется в этом случае должно проводиться с включением в ее состав представителей всех заинтересованных сторон (см. рис. 3.4) на разных уровнях управления. А для сложных проектов, какими являются проекты внедрения КИС, обычно требуется использование многоуровневой структуры управления проектами. Описание этой структуры и функций органов управления проектами приведено в табл. 3.3.
