Портал №1 по управлению цифровыми
и информационными технологиями

Что контролировать при управлении проектами

Наверное, любой человек хоть немного знакомый с управлением проектами знает, что в рамках управления проектами необходимо контролировать большое количество параметров, аспектов. Часто этот набор формулируют в виде «треугольника/пирамиды»: сроки, затраты и получаемый результат. Жёсткость геометрической фигуры в том числе намекает на то, что при изменении одного из параметров (например, срока реализации проекта и/или какой-либо из частей проекта) будут затронуты остальные параметры (например, придётся изменить и затраты).
В методологии управления проектами PRINCE2® вышеописанный набор характеристик сформулирован в виде аспектов:

  • Сроки (Timescales);
  • Затраты (Costs);
  • Объем работ aka «Охват» – то, что должны получить как результат завершения проекта;
  • Качество (Quality) – то, каким требованиям должно соответствовать то, что сделано в рамках охвата. И с какой степенью соответствия.

Это связанные параметры. Но не всегда, «взаимозаменяемые». Хотя некоторые специалисты иногда высказываются в том духе, что имея деньги, можно решить любые задачи в любые сроки и с любым качеством. Это, очевидно, не так. В т.ч. потому, что в некоторых случаях ограничениями сроков снизу будут технологические особенности и зависимости. Например, когда строим дом, даже имея неограниченные ресурсы, мы не можем параллельно копать котлован и красить крышу. Или мы не можем одновременно разрабатывать программный модуль и тестировать его. Технология производства вынуждает нас соблюдать некоторую последовательность, что увеличивает сроки.
Похожая модель встречается не только в PRINCE2.

Но есть ещё два аспекта, рекомендуемые PRINCE2, в восприятии которых в отличие от уже упомянутых наблюдаются трудности.
Это «Выгоды» (Benefits) и «Риcк» (Risk).

«Выгоды» — это то, ради чего проект реализуется. Т.е. не то, что должно быть получено как результат завершения проекта, а то, что должно быть получено в результате использования результата проекта. Например, не внедрённая информация система (например, CRM) или выстроенные ITSM-практики/процессы, а увеличение выручки или повышение качества услуг. Знакомым с ITIL 4 ® можно вспомнить понятие «Ценность» (Value). Но нужно помнить, что выгоды, чтобы можно было управлять этим аспектом, должны быть сформулированы как нечто измеримое. Например, увеличение выручки на 15% в течение полугода с момента завершения проекта.
Из уже сказанного видно, что особенность аспекта «Выгоды» заключается в том, что достижение целей, установленных по этому параметру, не может быть ответственностью только проекта. Ведь нужный результат чаще всего мы получаем после (чаще всего много позже) окончания проекта. Тогда, когда организационная структура, создаваемая для управления и реализации проекта уже не существует. Если только мы не включили в охват проекта и получение всех выгод (что обычно не делается).

Это означает, что только механизмами управления проектом обеспечить получения выгод (benefits) невозможно. Но, верно и обратное. Если мы в рамках проектного управления не выстраиваем каких-либо механизмов, направленных на контроль выгод, то вероятность их получения после завершения проектов мала (систему-то мы внедрили, и даже в срок, в рамках бюджета и в соответствии со спецификацией; но только рыночная конъюнктура изменилась – не видать нам увеличения выручки). Именно на этот счёт и даются рекомендации в PRINCE2. Как можно выстроить такой механизм управления выгодами в рамках проекта. И чем его дополнить, чтобы повысить вероятность получения этих самых выгод, когда проект уже закончится (и все его механизмы прекратят своё существование).

С рисками ситуация кажется ещё более запутанной. Ведь риск – это возможное событие или набор событий, реализация которого, повлияет на достижение целей (objectives). Где под целями понимаются как раз цели, устанавливаемые по аспектам проекта, которые мы контролируем. Т.е. влияние может проявляться в нарушении сроков, бюджетов, охвата, качества и даже неполучения выгод.
И здесь чаще всего сложность в понимании этой конструкции заключается в том, что аспект «Риск», кажется, не является «независимым» в том смысле, в котором, например, «Затраты» независимы от «Охвата». Да, как и написано выше, меняя охват проекта, мы, возможно, будем вынуждены изменить и бюджет. Но это разные параметры. Они имеют разную природу. У нас выстроены разные процедуры измерения и учёта фактических значений по этим параметрам. А с рисками, вроде бы, всё не так. Ведь риск – это то, реализация чего может привести к отклонению фактических затрат в рамках проекта от запланированных, например. Или охвата. А эти параметры у нас уже контролируются. Зачем же тогда ещё одна характеристика, которую нам рекомендуют контролировать?

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

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

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

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

И немного ереси в самом конце. Я нигде не встречал явных указаний на то, что аспектов должно быть именно шесть (если не считать большое количество публикаций/выступлений/курсов, в которых рассказывают про PRINCE2). В исходной книге («Managing Successful Projects with PRINCE2®») даётся вышеприведённый список из шести аспектов. Но, если для нас важна какая-либо иная, дополнительная характеристика проекта и/или у нас есть (или нам нужен) какой-либо иной механизм управления этой характеристикой, мы можем выделить дополнительный аспект управления нашим(и) проект[ом/ами].

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

Комментариев: 8

  • Dinitratiy

    Доброго дня.

    нашёл небольшую описку: «Из уже сказанное видно»

  • Dinitratiy

    Не совсем понятны слудующие фразы:

    — но только рыночная конъюнктура изменилась – не видать на увеличения выручки

    — Ведь риск – то возможное событие или набор событий

    — которые могут повлиять на эти разные аспекта, одинаково

    И вопрос всем экспертам:

    Насколько, по Вашему мнению, подорожает проект после введения в него аспекта «Управление рисмками»?

    Каков этот показалель в человеко-часах или % стоимости проекта?

    • Уточните, пожалуйста, конкретные вопросы по каждой из фраз. Замечу пока, что в некоторых цитатах приведены части фраз (м.б. это ведёт к потере смысла?)

      Подорожает при построении любого элемента управления. И не только в оласти управления проектами.

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

      • Dinitratiy

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

        — не видать наМ увеличения выручки

        — Ведь риск – Это возможное событие или набор событий

        — которые могут повлиять на эти разные аспектЫ, одинаково

        • О! Понял.

          Вы указали на опечатки. Спасибо огромное! Поправил.

          И, да, смысл Вы уловили верно.

      • Dinitratiy

        Спасибо за ответ. Да, это понятно, что подорожает при добавлении какого бы то ни было дополнительного элемента управления.

        Но больше интересно на сколько оно может подорожать?

        • Оценка снизу — прямые затраты (=трудозатраты на выполнение деятельности). В небольшом-среднем проекте, на мой взгляд, это небольшие накладные расходы, поскольку PM и так думает об этом => затраты времени только на формализацию и коммуникации.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT