Для достижения максимальной эффективности управления в условиях большого количества одновременно реализуемых проектов в нашей компании мы применяем принцип декомпозиции и создания иерархической структуры:
Портфель проектов -> Программа проектов -> Проект.
Подобная декомпозиция позволяет сбалансировать управленческие ресурсы и виды деятельности по тем или иным характеристикам и определить простые и понятные организационные структуры управления, полномочия и уровни ответственности.
В качестве компонентов иерархической структуры используются:
• Проект – временная деятельность, направленная на создание уникальных продуктов, услуг или получение результатов с надлежащим качеством, в рамках ограничений на сроки и бюджет;
• Программа – совокупность взаимосвязанных проектов, объединенных общей целью, выделенными ресурсами, временем на ее выполнение, технологией и условиями выполнения, сформированная для достижения большей степени управляемости;
• Портфель – набор проектов и программ, объединенных вместе с целью эффективного управления для достижения стратегических целей.
С целью определения наиболее оптимальной и эффективной организационной структуры управления проектом проводится классификация проекта по категориям. Классификация проекта позволяет:
• оптимизировать затраты, необходимые для управления проектом соответствующей категории;
• оптимизировать затраты, необходимые для управления проектом соответствующей категории;
• установить соответствующую организационную структуру управления проектом;
• установить перечень процессов и процедур управления проектом, выполнение которых в строгом соответствии с регламентом обязательно для проекта данной категории;
• установить единую форму, состав и содержание документов по управлению проектом при одновременном сокращении трудозатрат на их разработку;
• установить систему показателей качества управления проектом в соответствии с его категорией.
Все наши проекты условно можно подразделить на 4 категории:
• Мега-проект – масштабный проект, в котором задействовано большое количество участников (внешние организации, например, госорганы, заказчик, исполнитель, иные заинтересованные организации, чьи интересы могут затронуть результаты проекта). Как правило, такой проект является приоритетным и инновационным. Эта категория проектов требует непрерывного комплексного управления. К такому проекту предъявляются высокие требования в части управления: сложная организационная структура управления (максимальное количество уровней управления, максимальное количество ролей, участников, задействованных в проекте), большое количество процессов (охвачены все возможные функциональные области знаний управления проектами) и документов управления, постоянный мониторинг и управление сроками, ресурсами и стоимостью.
• Мульти-проект – масштабный, сложный проект, не несущий высоких идентифицированных рисков. Эта категория проектов требует постоянного управления сроками, ресурсами и стоимостью.
• Моно-проект – проект, направленный на достижение определенного результата, как правило, с привлечением трудовых ресурсов одного подразделения компании. К такому проекту предъявляются упрощенные требования в части управления: планирование и учет ресурсов на их выполнение, управление по контрольным точкам, контроль завершения в срок и в рамках бюджета.
• Проектная задача – проект, направленный на достижение четко определенного результата с минимальным привлечением трудовых ресурсов. К такому проекту не предъявляются требования в части планирования и управления, но необходим учет ресурсов на выполнение и контроль завершения в срок.
Разумеется, другие организации и предприятия в ходе формализации проектной деятельности разрабатывают собственные критерии отнесения проекта к той или иной категории (количественные и качественные).
Организационная структура команды проекта — это иерархически организованное изображение организации проектной деятельности, устроенное таким образом, чтобы соотносить программы, проекты, пакеты работ с управляющими и исполняющими организационными единицами. В проектах мы применяем несколько типов организационных структур команд проекта. Эти структуры отличаются числом уровней иерархии управления, обязательными ролями участников проектов и организацией управления Исполнителями.
В проектной деятельности используются следующие уровни управления:
• стратегический уровень управления: уровень управления стратегией;
• оперативный уровень управления: уровень управления портфелями проектов (Руководители портфелей проектов);
• операционный уровень управления: управления программами и проектами (Управляющие советы проектов, Кураторы проектов, Руководители программ, Руководители проектов);
• уровень управления исполнением: управление пакетами работ (Руководители рабочих групп, Архитекторы, Исполнители).
Схема организационной иерархии по уровням управления в мега-проекте приведена на рисунке 1.
Рис.1 Пример схемы организационной иерархии в мега-проекте
При такой организационной структуре участники одного уровня управления в проекте непосредственно коммуницируют с участниками только следующего уровня иерархии. Направления коммуникаций, которые можно охарактеризовать как «снизу-вверх» и «сверху-вниз» между уровнями, показывают, в каком виде будет происходить обмен информацией, когда и где будут иметь место коммуникации (критические связи между людьми и информацией), а также кто несет ответственность за обеспечение каждого типа коммуникаций.
Процедура эскалации построена через призму уровней управления таким образом, что каждый участник на своем уровне управления принимает решение в рамках своей компетенции и полномочий, определенных в конкретном проекте. Процедура эскалации применяется для принятия решений по проблемам и/или конфликтам (включая мероприятия по предотвращению рисков, мероприятия по реагированию на риски, реализацию запросов на изменения) в случае, если решение или компромисс не были найдены на более низком уровне управления проектом.
В больших и сложных проектах часто возникают коммуникации между участниками минуя промежуточные уровни управления, причем это может как отрицательно, так и положительно сказываться на реализации проекта.
Пример взаимосвязей вне уровней управления в проекте приведен на рисунке 2.
Рис.2 Пример взаимосвязей вне уровней управления в проекте
В качестве причин возникновения коммуникаций вне уровней управления можно выделить следующие:
1. Предыдущий опыт совместной работы участников проекта, которые теперь находятся на разных уровнях управления.
2. Недостаточные знания менеджера на определенном уровне в предметной области проекта, которые заставляют участника с более высокого уровня обращаться на нижний уровень иерархии, либо наоборот, когда Исполнитель обращается на уровень представителя заказчика.
3. Внутренняя корпоративная культура управления проектами в конкретной организации, которая задействована в проекте.
Однако, не всегда попытки Руководителя проекта пресечь подобные коммуникации и выстроить их по общепринятой «классической схеме» приводят к успеху. При возникновении коммуникаций вне уровней управления Руководителю проекта крайне важно разобраться, насколько эти коммуникации влияют на принятие решений на каждом из уровней управления, а также инициируют ли данные коммуникации изменения основных параметров проекта. Если решения по-прежнему принимают лица, в рамках полномочий которых определена данная функция, коммуникации следует наоборот формализовать, дополнив План управления коммуникациями проекта (Руководитель проекта на этапе планирования проекта готовит План управления коммуникациями, содержащий описание источников информации в проекте и методов ее получения; план распределения информации, в котором определяются потребители информации и способы ее доставки; детальное описание результирующих документов в проекте, которые должны быть получены или переданы, включая их формат и содержание).
Выстраивание дополнительных взаимосвязей вне уровней управления приводит к положительным результатам. Только выработав правила внутри конкретного проекта, учитывая специфику проекта и опыт участников возможно выстроить взаимосвязи наиболее оптимальным образом.
Комментарии (6)
S_A
15.07.2015 05:47Для каждой компании свои критерии «правильности», что для одной компании правильно, для другой может быть неприемлемо. Для нашей компании в состав критериев входит по несколько критериев в каждой функциональной области знаний по управлению проектами.
Да ладно… если организация коммерческая, то критерий «правильности» вполне один (и даже не для коммерческих он почти такой же — эффективность, только не финансовая). Что касается критериев из каждой области знания… то это непонятное применение практик.
Из сказанного же вытекает, раз главный критерий — финансовая эффективность (проекта, программы, портфеля), то вот эти все три варианта (доход и две экономии) есть один. И то, что вы называете «неявными издержками», и «экономией» на них — это не экономия, и не неявные издержки. Нельзя называть экономией (затрат на УП) наличие регламента, которые различает проекты и налагает разные требования к управлению. Иначе выходит что вы экономите на том, что не делаете того, что не нужно делать. Это не экономия, это (в лучшем случае) оптимизация. И кстати косвенные затраты (а не «неявные» — затраты на УП вполне себе явные), которые лежат в продукте и сформированы не затратами на то, из чего состоит продукт (в отличие от прямых), не столько предмет оптимизации при проектном управлении, сколько предмет конкретного планирования, как и все остальное в проекте.
Я к чему это все пишу. То что вы описали в статье и в комментарии, несмотря на то что вполне по шаблонам практик PMI, с точки зрения прибыльного проектно-портфельного управления, не очень эффективно, или по-крайней мере, взаимосвязи исходя из сказанного вами, нет.
Полагаю, и думаю не очень ошибусь, что ген. директора не особо волнует, какие области знаний будут углубленно управляться в каком-то конкретно проекте, а в каком-то нет. Декомпозиция как раз подразумевает разный подход к управлению разными видами организации деятельности (в смысле портфелем, программой, проектом). В моём понимании, для ИТ-компании вполне подходит
- Проект — деятельность, ключевые показатели которой: сроки, затраты, трудозатраты (в ч/ч и в разбивке по типу исполнителей), риски,
- Программа — совокупность связанных одним результатом, продуктом или клиентом проектов. Ключевые показатели: чистые денежные потоки в разбивке по времени, риски,
- Портфель — совокупность программ, ключевые показатели: интегральные финансовые показатели эффективности, количественно измеренные риски.
Таким образом менеджер проекта — оптимизирует эффект по затратам и срокам, менеджер программы — оптимизирует эффект от проектов и продаж, менеджер портфеля — оптимизирует портфель по составу программ (обычно в рамках бюджета). Это то, о чем бы я писал, если бы говорил про декомпозицию проектной деятельности в ИТ. То, что проекты бывают большие и маленькие, и ими вполне можно управлять по-разному, как-то очевидно.
Для проектного бизнеса, к коему можно отнести подавляющее большинство интеграторов (да и ИТ-компаний), переход от конкретных проектов к уровню управления компанией — самое больное место, и лечение этого места — как раз портфельное управление.
maria_kovaleva Автор
16.07.2015 10:16Раскрою более подробно, что подразумевалось под сутью экономического эффекта на примере организации из финансовй отрасли — допустим рассмотрим какой-нибудь абстрактный банк.
Возможные условия достижения эффекта:
1. Получение дополнительного дохода
— выполнение заявленного плана продаж;
— повышение доходности операций;
— привлечение новых клиентов;
— рост объема и повышение качества портфеля (корпоративные клиенты, малый и средний бизнес, розничные клиенты и т.д.
2. Экономия на явных затратах
— снижение затрат на оплату труда сотрудников банка;
— снижение текущих затрат на аренду помещений;
— снижение затрат на закупку бумаги для печати и картриджей для принтеров и т.д.
3. Экономия на неявных затратах
— высвобождение рабочего времени сотрудников банка;
— рост производительности труда сотрудников банка;
— ускорение и оптимизация бизнес-процессов в банке.
теперь давайте попробуем само по себе проектное управление рассмотреть как «проект». Если руководитель организации принимает решение использовать практики проектного управления и вообще рассматривает это как внутренний продукт (допустим корпоративная система управления проектами), то в какую часть экономического эффекта попадет эффект от его внедрения/использования проектного управления? экономия на неявных затратах естественно.
maria_kovaleva Автор
16.07.2015 10:47То, что проекты бывают большие и маленькие, и ими вполне можно управлять по-разному, как-то очевидно.
совершенно не для всех организаций это очевидно. Если бы это было очевидно, тот же PMI не придумал бы стандарт по модели зрелости организации в области управления проектами (OPM3 я имею ввиду). в зависимости от стадии зрелости в организации формируется понимание, что проектами «большими и маленькими» можно управлять по-разному.S_A
16.07.2015 12:06Уровень зрелости нужны не для того, чтобы управлять по-разному разными проектами, они не обязывают (и я даже по памяти не могу сказать что рекомендуют, вот по-моему в самом начале PMBoK что-то было про это). Они нужны для того, чтобы проектная деятельность организации была эффективной — в том смысле что была бы органично встроена в умы, процессы и практики так, чтобы не мешать ничему в организации с одной стороны, и улучшать все в ней вокруг и снаружи — с другой. С ростом уровня зрелости (при соответствующем согласовании уровней зрелости других видов деятельности) проектной деятельности организация легче достигает своих целей. Вот OPM3 о чем.
Что касается понимания — то оно есть везде, а вот регламентов на все случаи — от малого до великого — не всегда есть. Нужны они только там, где размеры проектов и действительно сильно плавают, например в ТНК.
По поводу проектной деятельности как проекта… внедрение УП и УПП — проект, а вот сама деятельность нет. И вот это вот «высвобождение рабочего времени», «рост производительности труда», «ускорение бизнес-процессов»… это что ли задачи УП/ОУП (для банка и вообще)? Может быть конечно задачами, но в жизни не видел чтобы проектные офисы внедряли (или хотя бы регламентировали УП) с такими целями.
Я даже понял мысль, что и как именно можно рассмотреть как проект, но не так чуть ли не всё можно рассматривать как проект. Хотя… и действительно, давайте рассмотрим внедрение КСУП как инвестиционный проект. Их эффективность оценивается для ситуаций «с проектом» и «без проекта». Экономическим эффектом от наличия КСУП (в любом виде) будет не эффект от проектов, которые так и так бы были реализованы (тяп-ляп пошагово, по единой проектной методике, или по стильному регламенту в котором на все есть ответы), а эффект от того, что проекты будут сделаны правильно, и будут сделаны правильные проекты. Ближе всего это возможно выразить в повышении ROI.
S_A
Ии?.. Какой из этого следует вывод?.. Что вы в курсе хороших практик от PMI?
Кладезь мудрости на все случаи жизни просто…
Если честно, я рад что по УП хоть что-то, но хотелось бы более дельного, раз «Компания Центр ИТ обладает исчерпывающим набором компетенций по системной интеграции и управлению проектами. » (из профиля инфа).
Как «делать проекты правильно» уже столько всего понаписано, этот PMBoK и прочее, расскажите о том как делать «правильные проекты», раз у вас есть УПП.
Статье все равно кстати плюс :) Я когда организовывал УПП в одной из ИТ-компаний, тот же подход использовал (ну как иначе-то:)) — портфель-программа-проект. Но там не системная интеграция была, там свои продукты пилили, что хорошо согласовывало проект с программой (а уже для портфеля там без особой разницы, поскольку в основном финансовые показатели использовались для анализа).
Ну и раз такая реклама:
Весьма любопытно было бы узнать каким образом категории оптимизируют затраты, да и вообще какие они.
maria_kovaleva Автор
Для каждой компании свои критерии «правильности», что для одной компании правильно, для другой может быть неприемлемо. Для нашей компании в состав критериев входит по несколько критериев в каждой функциональной области знаний по управлению проектами.
Эффект от результатов любого проекта можно классифицировать на три варианта:
— получение дохода
— Экономия на явных издержках
— экономия на неявных издержках
Тоже самое, если говорить о проектном управлении, само по себе применение методов проектного управления несет эффект в виде «экономии на неявных издержках» (трудозатраты руководителя проекта на выполнение определенных операций). Если рассматривать категории проектов от большого и сложного до простого, то для каждой категории от самого сложного до простого идет уменьшение количества методов и технологий применяемых руководителем проекта, увеличение количества «шаблонных» операций, отсюда и эффект, убираем лишние трудозатраты, получаем экономию на неявных издержках.