Проблемы в Управлении Программами
Часто программа, которой необходимо управлять представляет собой нечто большее, чем просто сумма составляющих ее проектов. Это более крупная, сложная система проектов, приоритетов, правил и практик, которые определяют поведение менеджеров и ресурсов и требуют постоянной координации с целью достижения максимума эффективности.
В стремлении реализовать все возможности, мульти проектные организации зачастую начинают проекты сразу, как только осознают их необходимость, параллельно с другими существующими и начинающимися проектами, и, к сожалению, часто без достаточного понимания возможностей организации. Распространенным является, когда ответственность за расстановку приоритетов между конфликтующими проектами ложится на менеджеров программ. Одна из проблем, вытекающих из этого, состоит в том, что итоговые приоритеты не могут быть синхронизированы друг с другом, и особенно с целями всей организации. Одним из методов борьбы с подобной ситуацией является практика решения многих задач – распределение ресурсов на более чем одну важную задачу во время определенного отрезка времени для того, чтобы попытаться двигать все проекты одновременно.
Вопрос, однако, заключается в том, дает ли такая практика желаемых результатов. Когда происходит решение многих задач одновременно, то тактика «чем быстрее начнешь, тем быстрее закончишь» ставится под вопрос. Настоящий прогресс происходит там, где работа, завершенная одним ресурсом, позволяет этому ресурсу начать другую работу. Практика решения нескольких задач одновременно замедляет прогресс проектов (см. рисунок):
На примере видно, что проекты А и В завершаются не вовремя, при этом без какого-либо выигрыша для проекта С.
Проблемы программ муниципальных образований:
Анализ программ развития муниципальных образований демонстрирует, что программы в основном ограничены описанием целей, задач, кратких формулировок мероприятий проектов. К сожалению, программы зачастую не дают ответы на практические вопросы, реально возникающие при ее реализации:
- кто и как принимают решения в процессе реализации программы;
- как происходит наполнение программы реальным содержанием, ее адаптация к изменяющимся условиям;
- кто являются основными игроками процесса реализации программы;
- как процесс управления развернут во времени;
- как привлекаются ресурсы для реализации программы и каков механизм финансового менеджмента;
- как осуществляется оценка и мониторинг программы;
- как и какими документами регламентируется управление программы;
- как должна быть структурирована программа для того, чтобы эффективно организовать ее управления и до какой степени должны быть проработаны все перечисленные вопросы до того, чтобы говорить о реальном старте (начале ее реализации).
Департамент Обороны США выделяет следующие проблемы в управлении своими программами:
Большое количество требований
Большое количество требований может перенапрячь всю систему, повышая ее сложность. Поэтому уменьшение требований до нескольких ключевых является распространенной целью. Проекты в Департаменте Обороны США предусматривают множество различных требований, и попытки их сократить успешны только частично.
Например, в армии США программа по ракетоносцам предусматривала пять основных требований (называемых ключевыми показателями). Но после завершения проектирования системы, стало известно, что эти пять параметров зависят от 500 других, которые были определены до того, как начался процесс проектирования.
Нестабильность требований
Изменение требований в конце цикла разработки приводит к различным проблемам с бюджетом и расписанием, инженерам приходится изменять дизайн или даже линии производства. Проблема нестабильности требований достаточна распространена среди программ Департамента Обороны США и возникает на всех стадиях разработки. Например, предназначение F/A-22 менялось несколько раз, от бомбардировщика до многофункционального бомбардировщика. F/A-18 – еще один пример изменения требований в системе на последних стадиях разработки. В этой программе было увеличение стоимости на 42%, что частично было вызвано поздними техническими изменениями. Основная причина нестабильности требований в оборонных программах – политизированность решений заказчиков. Для того, чтобы довести продукт до стадии реализации, необходимо сформировать коалицию сторонников. Но из-за длительности разработки, состав коалиции может меняться.
Другая причина нестабильности требований – смена менеджеров программы. Это приводит к изменению требований и целей программы. В Департаменте Обороны США, руководители программ сменяются, как правило, каждые 18 месяцев, в то время как сами программы могут длиться годами.
Способность исполнителя выполнять требования
В некоторых случаях способности исполнителей не учитываются в программе, что может приводить к задержкам в разработке, превышению бюджета и сроков.
Изменение требований без изменения в ресурсах
Когда такие ресурсы, как финансирование, сокращены, то изменение требований к продуктам является одним из способов решения ситуации. Изменения требований, которые подразумевают улучшение качества или сокращение сроков могут потребовать увеличения ресурсов. В большинстве случаев, увеличение ожиданий без увеличения в ресурсах только повышает вероятность провала.
Неточность условий контракта
Проектирование системы является критичным и должно осуществляться либо главным исполнителем, либо Департаментом Обороны. Но так как Департамент Обороны часто меняет политику своих закупок, может возникать неясность кто несет ответственность за все аспекты проектирования системы. Как следствие, необходимая проектировка системы может быть не завершена вовремя.
Недостаток авторитета у менеджера программы
Эта проблема особенно характерна для оборонных программ (и государственных). Все решения требуют одобрения несколькими «организациями» прежде чем могут быть осуществлены изменения программы. Процесс построен так, что достаточно желания одной из этих организаций, чтобы остановить изменения, однако, это редкость, когда достаточно согласия только одной организации для внесения изменений. Это подразумевает, что сложно вносить какие-либо изменения в программу.
Одновременное осуществление нескольких этапов
Процесс выполнения программы делится на несколько этапов. Когда цели одного из этапов еще не достигнуты, а программа продвигается уже на следующий этап, то возникают дополнительные риски относительно ограничений по бюджету и расписанию.
К примеру, если участники программы не хотят ее провала, даже когда она превышает все сроки и бюджет, то возникает желание хоть как-то продвигать программу, затрачивая больше ресурсов. Чем больше ресурсов затрачено, тем менее вероятно прекращение программы.
Недостаточное финансирование проектирования систем (
systems engineering) – для сложных технологических проектов
Проектирование систем – междисциплинарная сфера, изучающая то, как управлять сложными технологическими проектами. При работе со сложными технологическими проектами становится сложнее управлять вопросами логистики, координировать работу различных групп и автоматически контролировать работу техники. Проектирование систем помогает решить, как лучше выстраивать рабочие процессы и учитывать их при управлении проектами внутри программы.
Недостаточность информации о статусе программы
Отсутствие сведений о статусе программы затрудняет возможность быстрой реакции на проблемы. Информация часто поступает частями на протяжении всей программы, однако, она не всегда отслеживается.
Отсутствие возможности или желания делать взаимоуступки между проектами программы
Взаимоуступки и компромиссы между проектами программы очень важны для того, чтобы вписываться в ограничения по времени и бюджету.
Множественность целей
Менеджеры программ координируют работу многих людей, много проектов и их результаты. Они должны отлично владеть приемами ведения переговоров. Менеджеры программ должны достаточно понимать про продукт для того, чтобы технические решения не влияли негативно на стратегию компании. (Если решения по одному из проектов предотвращают реализацию другого проекта – это негативное влияние). Менеджеры программ должны также применять технологии управления программами: работать со всеми подразделениями организации, разрешать проблемы вне совещаний и встреч, координировать работу проектной команды, уметь создавать настоящую проектную команду.
Департамент Обороны США также выделяет институциональные риски, влияющие на управление программами: недостаточная институционализация и высокие уровни протекции, несоответствие ожиданий имеющимся ресурсам, разнородность целей стейкхолдеров, сопротивление реформам, отсутствие быстрого эффективного решения поставленных задач («серебряной пули»).
По материалам:
http://www.focusedperformance.com/articles/multipm.html
http://www.jrothman.com/weblog/2004/03/program-management-multiple-projects.html
http://en.wikipedia.org/wiki/Systems_engineering
http://www.rustowns.com/print.php?id=003041115073
http://stinet.dtic.mil/cgi-bin/GetTRDoc?AD=ADA428243&Location=U2&doc=GetTRDoc.pdf
http://eric.ed.gov/ERICDocs/data/ericdocs2sql/content_storage_01/0000019b/80/28/07/26.pdf
