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

Без продуманной структуры проект теряет управляемость. Задачи дублируются или зависают без владельца, решения согласуются неделями, команда не понимает, к кому идти с вопросом. По данным PMI (Project Management Institute), до 40% проектов не достигают целей именно из-за проблем с организацией работы команды.

Проект не живёт в вакууме. Он встраивается в уже существующую организационную структуру компании и зависит от неё.

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

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

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

• Спонсор (заказчик) проекта

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

• Управляющий комитет (совет проекта)

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

• Руководитель проекта (Project Manager)

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

• Проектная команда и функциональные исполнители

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

• Стейкхолдеры (заинтересованные стороны)

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

• PMO (Project Management Office)

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

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

Функциональная структура организации проекта

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

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

Подходит для небольших внутренних проектов, которые не выходят за рамки одного-двух подразделений.

Матричная структура: слабая, сбалансированная, сильная

Матричная структура сочетает функциональную организацию и проектное управление. Сотрудники подчиняются одновременно функциональному руководителю (по специализации) и руководителю проекта (по задачам).

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

Матричная структура самый распространённый вид организационной структуры управления проектом в крупных компаниях. Её главный вызов: двойное подчинение создаёт конфликты приоритетов между функциональным руководителем и менеджером проекта.

Проектно-ориентированная (выделенная) структура

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

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

По такой модели работают крупные строительные и инжиниринговые компании (Bechtel, Fluor), консалтинговые фирмы (McKinsey, BCG), студии разработки и продуктовые ИТ-компании.

Гибридная структура

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

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

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

Выбор структуры работы проектной организации зависит от нескольких факторов:

• Масштаб и сложность проекта – Чем крупнее и сложнее проект, тем больше автономии нужно проектной команде.
• Длительность проекта – Для коротких проектов (до 3 месяцев) выделять команду нецелесообразно. Для программ на 1–3 года это часто единственный вариант.
• Количество задействованных подразделений – Если проект затрагивает 5+ отделов, функциональная структура не справится с координацией.
• Стратегическая важность проекта – Приоритетные проекты требуют сильной матрицы или выделенной команды.
• Культура компании – В иерархической организации слабая матрица реалистичнее, чем проектно-ориентированная модель.
• Доступность ресурсов – Если специалистов мало и их нельзя полностью вывести из функции, работает только матрица.
• Зрелость проектного управления в компании – Компании без опыта проектной работы лучше начинать со слабой матрицы, а не с полноценной проектной структуры.

1. Определить цели и содержание проекта
Что нужно сделать, в какие сроки и с каким бюджетом.
2. Оценить масштаб и сложность
Количество участников, подразделений, внешних подрядчиков.
3. Выбрать тип структуры
Функциональная, матричная (слабая/сбалансированная/сильная), проектно-ориентированная или гибридная.
4. Назначить ключевые роли
Спонсор, руководитель проекта, состав управляющего комитета.
5. Сформировать команду проекта
Определить, кто нужен для реализации проекта, на какой процент загрузки, из каких подразделений.
6. Разработать матрицу ответственности (RACI)
Зафиксировать, кто за что отвечает по каждому блоку задач.
7. Согласовать структуру со стейкхолдерами
Убедиться, что функциональные руководители согласны с выделением ресурсов.
8. Утвердить и запустить
Оформить проект официальным документом.

RACI (Responsible, Accountable, Consulted, Informed) — это инструмент, который фиксирует роли участников по каждой задаче или решению в проекте.

Помимо RACI существуют расширенные модели: RASCI (добавляется S, Supportive — поддерживающий), DACI (Driver, Approver, Contributor, Informed — популярна в Atlassian и других ИТ-компаниях), CAIRO (добавляется O, Omitted — сознательно исключённый). Для большинства проектов достаточно классической RACI.

Как определить зоны ответственности

Для каждой крупной задачи или группы задач проекта нужно ответить на четыре вопроса: кто делает, кто отвечает за результат, кого нужно спросить до начала и кого уведомить после. Если на первые два вопроса ответ «непонятно» или «все», RACI-матрица ещё не готова.

Как избежать дублирования полномочий и «ничьих» задач

Два правила:

• У каждой задачи должен быть ровно один «A» (ответственный).
• Если у задачи нет «R» (исполнителя), она не будет сделана. Если «R» слишком много, никто не чувствует персональной ответственности.

RACI-матрицу стоит пересматривать при изменении состава команды, фазы проекта или содержания работ.

Чёткая структура ответственности в проекте даёт три конкретных эффекта.

• Скорость

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

• Качество

Когда за результат отвечает конкретный человек, а не «команда в целом», качество работы растёт. Персональная ответственность работает лучше коллективной.

• Мотивация

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

Ошибки, которые повторяются от проекта к проекту:

• Руководитель проекта без полномочий – Назначили менеджера, но не дали ему права принимать решения, распоряжаться ресурсами или эскалировать проблемы.
• Нет спонсора или формальный спонсор – Проект запущен, но на уровне руководства за него никто не отвечает. При первом же конфликте с функциональными задачами проект теряет приоритет.
• Команда собрана «по остаточному принципу» – В проект отправляют тех, кто менее загружен, а не тех, кто нужен.
• RACI не заполнена или не соблюдается – Распределение ответственности существует на бумаге, но в реальной работе решения принимаются хаотично.
• Игнорирование стейкхолдеров – Проект двигается без учёта интересов ключевых заинтересованных сторон. В результате на поздних этапах появляются блокирующие замечания.
• Копирование структуры прошлого проекта – «В прошлый раз работало» не означает, что сработает снова. Каждый проект уникален по составу участников, рисков и задач.
• Отсутствие пересмотра структуры по ходу проекта – Проект изменился (расширился scope, сменился заказчик, ушёл ключевой специалист), а структура осталась прежней.
• Структура не учитывает географию – Если команда распределена по нескольким городам или работает в гибридном формате, классическая иерархическая структура не работает. Нужны дополнительные механизмы координации: регулярные синхронизации, единые цифровые инструменты, чёткие протоколы коммуникации.

Обратите внимание на пять сигналов-маркеров:

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

Если совпадают 2–3 сигнала, оргструктуру проекта пора пересматривать.
Это нормальная практика: структура проекта может меняться при переходе между фазами (инициация → планирование → реализация → завершение).

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