Проектная структура управления (Project-Based Structure)

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

Происхождение и исследовательская база

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

Академическую основу под выбор структуры под тип деятельности заложила британский социолог Джоан Вудворд в книге «Industrial Organization: Theory and Practice» (1965) — изучив более 100 британских промышленных предприятий, она показала, что не существует единственной «лучшей» организационной структуры: оптимальная форма зависит от типа производства. Мелкосерийное и единичное производство (уникальные, не повторяющиеся изделия) статистически тяготело к более органичным, гибким структурам — тому самому типу организации, из которого позже выросла именно проектная форма, тогда как крупносерийное и массовое производство успешнее работало по строгой функциональной иерархии. Это первое эмпирическое подтверждение того же принципа, который позже сформулировали применительно к самой проектной структуре: форма организации должна соответствовать природе деятельности, а не выбираться по моде.

Один из самых наглядных реальных примеров чисто проектной организации — подразделение Lockheed Skunk Works под руководством главного инженера Кларенса «Келли» Джонсона. В 1943 году Военное министерство США поставило задачу спроектировать и построить рабочий прототип реактивного истребителя за 180 дней. Джонсон организовал отдельную от основной функциональной структуры Lockheed проектную команду — 23 инженера и около 30 механиков (штат вырос до 81 человека) — с полными полномочиями над решениями по проекту и минимумом бюрократических согласований. Прототип XP-80 был спроектирован и построен за 143 дня — на семь дней раньше срока. Позже Джонсон формализовал этот подход в знаменитые «14 правил Skunk Works», включая требование о том, что руководитель проекта должен обладать практически полной властью над проектом при минимальном количестве отчётов, — по сути ранняя формулировка именно того принципа полных управленческих полномочий руководителя проекта, который определяет проектную структуру.

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

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

Ключевые идеи и принципы

1. Принцип: руководитель проекта обладает полными управленческими полномочиями над командой на период проекта.

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

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

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

3. Принцип: потеря постоянной функциональной базы требует компенсирующих механизмов накопления экспертизы.

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

Ограничения, слепые зоны и критика

Типовые ошибки

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

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

   Как избежать

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

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

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

   Как избежать

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

3. Ошибка 3: не сохраняют институциональную память и накопленный командный опыт между расформировываемыми проектными командами.

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

   Как избежать

   внедрять формальные механизмы фиксации и передачи извлечённых уроков (lessons learned) между завершающимися и новыми проектными командами.

4. Ошибка 4: не определяют явно объём ресурсных полномочий руководителя проекта над распределением сотрудников между несколькими проектами.

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

   Как избежать

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

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

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

   Как избежать

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

План внедрения

1. Неделя 1: определить, соответствует ли характер деятельности организации критериям проектной структуры

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

2. Неделя 2: спроектировать полномочия и подотчётность руководителей проектов

   Определить объём управленческих полномочий руководителя проекта над командой на весь период проекта.

3. Неделя 3: внедрить компенсирующие механизмы накопления функциональной экспертизы

   Настроить сообщества практики или менторские программы для поддержания профессионального развития сотрудников.

4. Неделя 4: разработать процесс передачи извлечённых уроков между проектными командами

   Формализовать механизм фиксации и передачи накопленного опыта при расформировании команд.

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

Как реализовать этот план с помощью фрейма «Проектная оргструктура (Project-Based Structure)» в OrgDevTools

Фрейм состоит из четырёх карточек на вкладке «Карточки», каждая соответствует одной неделе плана внедрения выше.

Неделя 1 — карточка «Соответствие природе деятельности». Применение чисто проектной структуры к организации с преимущественно непрерывной операционной деятельностью прямо повторяет ошибку 1.

Неделя 2 — карточка «Полномочия руководителя проекта». Сюда вносится прямая линия подчинения команды на весь период проекта.

Неделя 3 — карточка «Сохранение функциональной экспертизы». Отсутствие компенсирующих механизмов накопления экспертизы вне проектных команд прямо повторяет ошибку 2.

Неделя 4 — карточка «Передача извлечённых уроков». Отсутствие формального механизма фиксации опыта при расформировании команды прямо повторяет ошибку 3.

Вкладка «Итоги» явно предупреждает, если механизмы сохранения экспертизы или передачи уроков не заполнены.

Книги по теме

Гарольд Керцнер — «Project Management: A Systems Approach to Planning, Scheduling, and Controlling» (изд. с 1979). Классическое систематическое изложение организационных структур управления проектами, включая проектную и матричную формы.