Декомпозиция при управлении масштабными проектами в ИТ отрасли


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

    Портфель проектов -> Программа проектов -> Проект.

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

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

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

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

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

    Все наши проекты условно можно подразделить на 4 категории:

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

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

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

    В проектной деятельности используются следующие уровни управления:

    • стратегический уровень управления: уровень управления стратегией;
    • оперативный уровень управления: уровень управления портфелями проектов (Руководители портфелей проектов);
    • операционный уровень управления: управления программами и проектами (Управляющие советы проектов, Кураторы проектов, Руководители программ, Руководители проектов);
    • уровень управления исполнением: управление пакетами работ (Руководители рабочих групп, Архитекторы, Исполнители).

    Схема организационной иерархии по уровням управления в мега-проекте приведена на рисунке 1.

    image

    Рис.1 Пример схемы организационной иерархии в мега-проекте

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

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

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

    Пример взаимосвязей вне уровней управления в проекте приведен на рисунке 2.



    Рис.2 Пример взаимосвязей вне уровней управления в проекте

    В качестве причин возникновения коммуникаций вне уровней управления можно выделить следующие:

    1. Предыдущий опыт совместной работы участников проекта, которые теперь находятся на разных уровнях управления.
    2. Недостаточные знания менеджера на определенном уровне в предметной области проекта, которые заставляют участника с более высокого уровня обращаться на нижний уровень иерархии, либо наоборот, когда Исполнитель обращается на уровень представителя заказчика.
    3. Внутренняя корпоративная культура управления проектами в конкретной организации, которая задействована в проекте.

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

    Выстраивание дополнительных взаимосвязей вне уровней управления приводит к положительным результатам. Только выработав правила внутри конкретного проекта, учитывая специфику проекта и опыт участников возможно выстроить взаимосвязи наиболее оптимальным образом.
    • +10
    • 4,2k
    • 6

    ООО «ЦИТ»

    52,00

    ИКТ-решения и сервисы для органов власти и бизнеса

    Поделиться публикацией
    Комментарии 6
      +1
      Ии?.. Какой из этого следует вывод?.. Что вы в курсе хороших практик от PMI?

      это может как отрицательно, так и положительно сказываться

      Однако, не всегда

      учитывая специфику проекта и опыт участников возможно

      Кладезь мудрости на все случаи жизни просто…

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

      Как «делать проекты правильно» уже столько всего понаписано, этот PMBoK и прочее, расскажите о том как делать «правильные проекты», раз у вас есть УПП.

      Статье все равно кстати плюс :) Я когда организовывал УПП в одной из ИТ-компаний, тот же подход использовал (ну как иначе-то:)) — портфель-программа-проект. Но там не системная интеграция была, там свои продукты пилили, что хорошо согласовывало проект с программой (а уже для портфеля там без особой разницы, поскольку в основном финансовые показатели использовались для анализа).

      Ну и раз такая реклама:
      С целью определения наиболее оптимальной и эффективной организационной структуры управления проектом проводится классификация проекта по категориям. Классификация проекта позволяет:

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

      Весьма любопытно было бы узнать каким образом категории оптимизируют затраты, да и вообще какие они.
        0
        расскажите о том как делать «правильные проекты», раз у вас есть УПП

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

        каким образом категории оптимизируют затраты, да и вообще какие они

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

        Тоже самое, если говорить о проектном управлении, само по себе применение методов проектного управления несет эффект в виде «экономии на неявных издержках» (трудозатраты руководителя проекта на выполнение определенных операций). Если рассматривать категории проектов от большого и сложного до простого, то для каждой категории от самого сложного до простого идет уменьшение количества методов и технологий применяемых руководителем проекта, увеличение количества «шаблонных» операций, отсюда и эффект, убираем лишние трудозатраты, получаем экономию на неявных издержках.
        0
        Для каждой компании свои критерии «правильности», что для одной компании правильно, для другой может быть неприемлемо. Для нашей компании в состав критериев входит по несколько критериев в каждой функциональной области знаний по управлению проектами.
        Да ладно… если организация коммерческая, то критерий «правильности» вполне один (и даже не для коммерческих он почти такой же — эффективность, только не финансовая). Что касается критериев из каждой области знания… то это непонятное применение практик.

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

        Я к чему это все пишу. То что вы описали в статье и в комментарии, несмотря на то что вполне по шаблонам практик PMI, с точки зрения прибыльного проектно-портфельного управления, не очень эффективно, или по-крайней мере, взаимосвязи исходя из сказанного вами, нет.

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


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

        Для проектного бизнеса, к коему можно отнести подавляющее большинство интеграторов (да и ИТ-компаний), переход от конкретных проектов к уровню управления компанией — самое больное место, и лечение этого места — как раз портфельное управление.
          0
          Раскрою более подробно, что подразумевалось под сутью экономического эффекта на примере организации из финансовй отрасли — допустим рассмотрим какой-нибудь абстрактный банк.
          Возможные условия достижения эффекта:
          1. Получение дополнительного дохода
          — выполнение заявленного плана продаж;
          — повышение доходности операций;
          — привлечение новых клиентов;
          — рост объема и повышение качества портфеля (корпоративные клиенты, малый и средний бизнес, розничные клиенты и т.д.
          2. Экономия на явных затратах
          — снижение затрат на оплату труда сотрудников банка;
          — снижение текущих затрат на аренду помещений;
          — снижение затрат на закупку бумаги для печати и картриджей для принтеров и т.д.
          3. Экономия на неявных затратах
          — высвобождение рабочего времени сотрудников банка;
          — рост производительности труда сотрудников банка;
          — ускорение и оптимизация бизнес-процессов в банке.

          теперь давайте попробуем само по себе проектное управление рассмотреть как «проект». Если руководитель организации принимает решение использовать практики проектного управления и вообще рассматривает это как внутренний продукт (допустим корпоративная система управления проектами), то в какую часть экономического эффекта попадет эффект от его внедрения/использования проектного управления? экономия на неявных затратах естественно.

            0
            То, что проекты бывают большие и маленькие, и ими вполне можно управлять по-разному, как-то очевидно.

            совершенно не для всех организаций это очевидно. Если бы это было очевидно, тот же PMI не придумал бы стандарт по модели зрелости организации в области управления проектами (OPM3 я имею ввиду). в зависимости от стадии зрелости в организации формируется понимание, что проектами «большими и маленькими» можно управлять по-разному.
              0
              Уровень зрелости нужны не для того, чтобы управлять по-разному разными проектами, они не обязывают (и я даже по памяти не могу сказать что рекомендуют, вот по-моему в самом начале PMBoK что-то было про это). Они нужны для того, чтобы проектная деятельность организации была эффективной — в том смысле что была бы органично встроена в умы, процессы и практики так, чтобы не мешать ничему в организации с одной стороны, и улучшать все в ней вокруг и снаружи — с другой. С ростом уровня зрелости (при соответствующем согласовании уровней зрелости других видов деятельности) проектной деятельности организация легче достигает своих целей. Вот OPM3 о чем.

              Что касается понимания — то оно есть везде, а вот регламентов на все случаи — от малого до великого — не всегда есть. Нужны они только там, где размеры проектов и действительно сильно плавают, например в ТНК.

              По поводу проектной деятельности как проекта… внедрение УП и УПП — проект, а вот сама деятельность нет. И вот это вот «высвобождение рабочего времени», «рост производительности труда», «ускорение бизнес-процессов»… это что ли задачи УП/ОУП (для банка и вообще)? Может быть конечно задачами, но в жизни не видел чтобы проектные офисы внедряли (или хотя бы регламентировали УП) с такими целями.

              Я даже понял мысль, что и как именно можно рассмотреть как проект, но не так чуть ли не всё можно рассматривать как проект. Хотя… и действительно, давайте рассмотрим внедрение КСУП как инвестиционный проект. Их эффективность оценивается для ситуаций «с проектом» и «без проекта». Экономическим эффектом от наличия КСУП (в любом виде) будет не эффект от проектов, которые так и так бы были реализованы (тяп-ляп пошагово, по единой проектной методике, или по стильному регламенту в котором на все есть ответы), а эффект от того, что проекты будут сделаны правильно, и будут сделаны правильные проекты. Ближе всего это возможно выразить в повышении ROI.

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

          Самое читаемое