Выбор технологии управления проектом: между гибкостью и формализацией
Ключевая проблема: выбор методологии управления нельзя сводить к оценке по одному параметру. Бинарный подход здесь не работает. Решение о применимости той или иной технологии требует комплексного анализа в нескольких разрезах одновременно.
Оценка по параметрам «Размер клиента» и «Глубина модификации»
Эти две характеристики следует рассматривать в связке.
•
Слабые модификации (или их отсутствие):
Технология быстрого результата (ТБР) успешно масштабируется и работает на проектах любого размера, включая крупные внедрения.
•
Глубокие модификации (вплоть до уникальной разработки): Даже на малых проектах возникает потребность в использовании
формальной технологии корпоративного внедрения. Здесь необходим массив мероприятий, направленных на снятие архитектурных и других рисков.
•
Исключение: Если размер клиента велик, но скорость принятия решений в проекте высокая, технология быстрого результата сохраняет свою эффективность почти на любом масштабе.
Оценка по параметрам «Коммуникации» и «Глубина модификации»
Уровень коммуникации и скорость принятия решений критически влияют на выбор подхода.
•
Низкое качество коммуникаций: Признаки — коллективная безответственность, длительные цепочки согласования (15 подписей на документе), размытие зон ответственности. В таких условиях спасти проект от провала могут только
формальные методы. Без внушительного массива документации добиться результата не получится.
•
Сильные модификации при высоком уровне коммуникаций: Если предстоит глубокая разработка или переработка отраслевого решения, но заказчик работает в тесной связке с командой (творческая коллаборация без бюрократических препон), технология быстрого результата находит свое применение даже в проектах с большим объемом кода.
•
Слабые модификации при низком уровне коммуникаций: Здесь вновь работают только формальные подходы: скрупулезное документирование, подписание актов и жесткий документооборот. Игнорирование этого правила ведет к неуспешному завершению проекта.
Оценка проекта одновременно по этим характеристикам позволяет наиболее точно принять решение о технологии управления в конкретном кейсе. Универсальных рецептов не существует.
Анализ рисков: избыточность против потери контроля
Ошибка в выборе технологии управления в общем случае приводит к двум проблемам: «перестраховались» или «недостраховались».
1.
Избыточное страхование (Перестраховались). Эта ситуация не является критичной для судьбы проекта. Проект все равно будет выполнен, и цель будет достигнута. Негативное последствие — потеря операционной эффективности:
o Управленческие процессы занимают больше времени, чем объективно требуется.
o Возможно небольшое удорожание или снижение рентабельности.
Однако результат достигнут: деньги получены, заказчик доволен, а команда зарабатывает репутацию надежного исполнителя. В последующих проектах можно скорректировать подход и повысить экономическую эффективность.
2.
Недостаточное страхование (Недостраховались). Это гораздо более опасный сценарий, который ведет к
потере управления. Это означает выход проекта из-под контроля. Часто это происходит при слепом применении «стандартного внедрения» там, где требуется большая формализация.
o Если команда не смогла адекватно оценить потребность в регламентах и документах, проект сталкивается со срывом сроков и превышением бюджета.
o Использование более формализованной технологии (или ТБР, в зависимости от контекста) на старте позволило бы сохранить контроль.
Практический вывод: Если существует неопределенность в оценке, безопаснее выбрать более формальную технологию. Это гарантирует управляемость проекта. Взяв неформальный подход по ошибке, можно потерять проект целиком.
Резюме подхода к выбору
Оценка должна быть коллегиальной и многомерной. К анализу необходимо привлекать:
• Продавцов (знают внутренние механизмы клиента и скорость его реакции);
• Руководителя проекта;
• Потенциальную будущую команду проекта.
Только совместный анализ всех факторов позволяет принять наиболее верное решение.
Краткие итоги
Перед нами раскрывается фундаментальная дилемма проектного управления, лежащая в плоскости выбора между скоростью и надежностью. Авторская концепция отходит от упрощенного взгляда на методологии как на догмы и переводит фокус на ситуационный анализ. В основе принятия решений лежит не слепое следование модным трендам (будь то жесткий Waterfall или гибкие Agile-практики), а холодная оценка трехмерной системы координат: сложности продукта, масштаба организации и, что наиболее важно, качества человеческих коммуникаций.
Главная аналитическая ценность изложенного заключается в выявлении взаимосвязи между бюрократической инерцией заказчика и требуемой глубиной проработки документации. Низкая скорость принятия решений и размытая ответственность на стороне клиента выступают не просто раздражающим фактором, а объективным основанием для отказа от гибких подходов в пользу жесткой формализации. И наоборот, технически сложная разработка, подкрепленная высокой коллаборацией и доверием, освобождает проект от избыточных бюрократических оков.
Особую практическую значмость приобретает асимметричная оценка рисков. Тезис о том, что «перестраховаться» (допустить избыток процессов) экономически безопаснее, чем «недостраховаться» (потерять контроль), формирует базовый принцип управления неопределенностью. Это обоснование консервативного выбора в сторону предсказуемости: потеря маржинальности здесь рассматривается как приемлемая плата за сохранение статуса надежного партнера, в то время как хаос и срыв сроков ведут к необратимым репутационным потерям. По существу, выбор методологии перестает быть техническим вопросом и становится стратегическим актом балансировки между экономией на управлении и вероятностью полного обесценивания результатов труда.
1. Для выбора технологии управления проектом недостаточно одного критерия — необходим многомерный анализ.
2. Технология быстрого результата применима на крупных проектах только при низкой потребности в модификациях или высокой скорости принятия решений.
3. Глубокая модификация типового решения требует формальной технологии внедрения даже на проектах малого масштаба.
4. Признаки плохих коммуникаций: коллективная безответственность, длительные цепочки согласования и отсутствие персональной ответственности за результат.
5. В условиях низкого качества коммуникаций только скрупулезное документирование и формальные методы могут спасти проект от провала.
6. Высокий уровень коллаборации и быстрая обратная связь от заказчика позволяют использовать гибкие подходы даже в проектах с глубокой кастомизацией.
7. Универсального метода управления, подходящего для всех проектов, не существует.
8. Ошибка «избыточного страхования» (overinsurance) ведет лишь к временному снижению рентабельности, но сохраняет проект под контролем.
9. Ошибка «недостаточного страхования» (underinsurance) приводит к потере управления, срыву сроков и провалу бюджета.
10. В ситуации неопределенности безопаснее выбрать более формализованную методологию, чем полагаться на самоорганизацию при отсутствии на то оснований.
11. Анализ следует проводить коллегиально с участием продавцов, руководителей и исполнителей для сложения всех внутренних факторов.
12. Репутация надежного исполнителя стоит дороже сиюминутной экономии на управленческих процедурах.
1. Почему при выборе методологии нельзя опираться исключительно на размер бюджета или масштаб компании-заказчика?
2. При каком сочетании факторов «глубина модификации — масштаб» технология быстрого результата перестает быть эффективной?
3. Какие признаки в поведении заказчика указывают на критическую необходимость применения формальной технологии внедрения?
4. В чем разница влияния сильных и слабых коммуникаций на проект с большим объемом уникальной разработки?
5. В каком случае формальные подходы становятся единственным способом избежать провала?
6. Опишите суть проблемы «перестраховались». Является ли она фатальной для проекта и почему?
7. Каковы реальные последствия потери управления в проекте при использовании недостаточно формализованной методологии?
8. Почему стратегия «недостраховаться» считается более опасной, чем применение избыточных управленческих процедур?
9. Кто именно должен участвовать в коллегиальной оценке проекта для выбора технологии управления?
10. Почему знание внутренних механизмов и скорости реакции клиента важны для выбора методологии?
11. Как соотносится понятие «формальная технология» с документооборотом и архитектурными рисками?
12. Можно ли считать технологию быстрого результата универсально неприменимой для больших корпоративных проектов? Обоснуйте.