Управление приоритетами проектов

Управление приоритетами проектов

Проект, который плохо управляется, обречен. Однако практика показала, что отсутствие управления приоритетами на сегодняшнем этапе развития ИТ часто является причиной провала даже качественно управляемых проектов.

Управление приоритетами проектов в настоящее время выделяется в самостоятельную тенденцию ИТ-менеджмента, обособляясь от управления проектами. Разница между этими двумя областями управления существенная: управление приоритетами происходит ДО, а управление проектами — ПОСЛЕ начала работы над проектом. Управление приоритетами проектов концентрируется на том, каким проектам отдать предпочтение, до того как запустить их. Управление проектами вступает в силу уже после того, как данный проект или серия проектов получили полномочия к выполнению. Выделение управления приоритетами проектов в отдельную область управления связано с тем, что для настоящего этапа развития ИТ характерно серьезное повышение роли планирования во всех областях управления. Компании, которые не уделяют этой дисциплине достаточного внимания, завалены десятками проектов, цели и задачи которых часто конфликтуют друг с другом. Неспособность компании толком приоритезировать проекты в ИТ-отделе является одной из наиболее распространенных причин неэффективности ИТ-отделов

Дарвинизм в управлении проектами

Существует негласное правило, согласно которому можно убирать из списка проектов ненужные и малозначимые. Если текущий проект вытесняется проектом с более высоким приоритетом, а общее количество проектов, ведущихся ИТ-отделом, уже достигло максимума, то это явный сигнал к остановке одного из активных проектов. Эта своеобразная форма дарвинизма в управлении проектами и приоритетами приводит к тому, что в списке текущих проектов остаются только проекты, которые невозможно обойти или пропустить.
Что такое управление приоритетами

Управление приоритетами (Demand Management and Project Prioritization, DMPP) представляет собой метапроект, выполняемый ИТ-директором с целью определить последовательность выполнения ИТ-проектов. В рамках этого метапроекта ИТ директор учитывает и инвентаризирует все текущие и планируемые проекты, оценивает усилия по выполнению проектов, доходы и расходы, легкость выполнения, риски, ожидаемые результаты и соответствие требованиям существующей системы. В конце концов ИТ-директор должен прийти к соответствующим образом приоритезированному списку проектов и решить, сколько проектов может реально находиться в одновременном выполнении.

Анализ ошибок показал, что неправильная расстановка приоритетов и некачественное управление проектом — две наиболее распространенные причины того, что проекты не завершаются. Более того, проценты проектов, потерпевших крах по этим двум причинам примерно равны.
Почему хорошего управления проектами недостаточно?

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

Проблема № 1. Превышение проектной мощности ИТ-отдела. У ИТ-отдела есть определенная проектная мощность, определенное количество проектов, с которым отдел способен справиться. До недавнего времени запросы на выполнение новых проектов просто принимались ИТ-отделом и выполнялись по мере возможности. Такая практика приводит к обилию удовлетворенных бизнес-клиентов сегодня и обилию взбешенных клиентов через несколько месяцев, потому что прием ИТ-проектов в работу при этом зависит от мощностей отдела, позволяющих их выполнять. В настоящее время в рамках управления приоритетами проектов разработаны методы управления задолженностями по проектам, приоритезации портфеля проектов. Без эффективного применения таких методов ИТ-отдел неминуемо будет брать на себя больше, чем способен выполнить. Практика показала, что количество одновременно выполняемых ИТ-отделом проектов не должно быть меньше трех, но и, в большинстве случаев, не должно превышать 12. Кроме того, эксперименты с производительностью труда в ИТ-отделах показывали существенное снижение общих показателей, когда ИТ-отдел пытался поддерживать количество проектов, превышающее первоначально определенную для него проектную мощность.

Проблема № 2. Обсуждение vs выполнение. ИТ-отделы, находясь на пределе проектной мощности, все равно вынуждены тратить время, обсуждая новые проекты, вместо того чтобы выполнять текущие. Это, разумеется, не означает, что высокоприоритетные проекты не должны рассматриваться ИТ-отделом в процессе работы над другими проектами. Управление приоритетами проектов предлагает систему оценки проектов, позволяющую убедиться в том, что данный проект достаточно важен, чтобы приостановить один из находящихся в выполнении проектов или же провести необходимые мероприятия для увеличения проектной мощности отдела. Согласно методологии после завершения каждого проекта производится реприоритезация портфеля проектов, чтобы убедиться, что проекты, находящиеся в текущем выполнении, наиболее востребованы.

Проблема № 3. Отсутствие четких критериев старта проекта. Если нет критериев, четко определяющих, в каком случае ИТ-проект будет начат, то очень скоро в стадии выполнения появляются проекты с нечеткими целями, недоработанной документацией, непросчитанными сроками и прочими недостатками, ведущими к еще большим проблемам управления на разных стадиях выполнения проектов. Методологии приоритезации проектов дают в руки ИТ-директору строгие критерии отбора проектов и добавления их к списку текущих проектов. Далее в статье мы опишем процесс добавления ИТ-проектов в список активных проектов. Пока же вкратце упомянем, что данный процесс должен включать в себя детальное понимание стоимости проекта, преимуществ для бизнеса, масштаба и рамок проекта, а также предварительную оценку времени выполнения и затрат.

Проблема № 4. Гибкость в осуществлении проектов. Увы, но нередки случаи изменения целей ИТ-проекта по мере выполнения проекта. И это не вопрос плохой организации управления проектами. Это насущная необходимость, связанная с изменениями в бизнесе компании по ходу ИТ-проекта. В течение этого времени многие факторы изменяются и начинают влиять на значимость и жизнеспособность данного проекта. Бизнес-ситуация, технологии, набор сотрудников, управление компанией — все может поменяться, изменив и значимость проекта. Проблему эту пытались решить самыми разными способами. На сегодняшний день практика показала, что можно добиться качественного выполнения проектов и в то же время сохранить определенную гибкость и чувствительность к переменам. Однако это связано с изменением приоритетов ИТ-проекта и соответственно с практикой управления приоритетами проектов.
Симптомы отсутствия управления приоритетами

Перечислим основные симптомы, на основании которых ИТ-директор может сделать вывод о необходимости концентрироваться на управлении приоритетами проектов.
Симптом № 1. ИТ-отдел состоит из профессионалов высокого уровня, которые действительно заинтересованы в завершении проектов, но проекты «парадоксальным образом» остаются незавершенными. Сотрудники ИТ-отдела находятся в постоянном состоянии полной занятости без какого-либо существенного результата.
Симптом № 2. Списка текущих ИТ-проектов либо вообще не существует, либо он состоит из десятков проектов в состоянии полуготовности. Масштабы проектов здесь сильно различаются, «заменить модем» и «внедрить CRM» — в одном и том же списке задач.
Симптом № 3. Количество одновременно выполняемых ИТ-проектов слишком велико, и это затрудняет управление самими проектами. Проекты тормозятся в связи с недостатками управления, сроки не соблюдаются, бюджеты перерасходуются.
Симптом № 4. Отделы компаний из собственных бюджетов выделяют деньги на ИТ-проекты, с связи с тем что ИТ-отдел неспособен адекватно организовать работу над приоритетными для данных отделов проектами.
Симптом № 5. Ресурсы и сотрудники распределяются одинаково как для проектов с низким приоритетом для компании, так и для высокоприоритетных проектов. Некоторые высокоприоритетные проекты недоукомплектованы штатом.
Симптом № 6. Увеличивается гетерогенность ИТ в связи с множеством разрозненных проектов, что в свою очередь ведет к удорожанию стоимости ИТ-проектов.
Симптом № 7. Процесс принятия на работу сконцентрирован на том, чтобы заполнить позиции в низкоприоритетных проектах. Это приводит к недостатку квалифицированного персонала на основных проектах и требует выделения дополнительных средств.
Этапы управления приоритетами проектов

Рассмотрим основные этапы в процессе управления приоритетами проектов.

Этап № 1. Список всех потенциальных проектов. Первый шаг в практике управления приоритетами проектов состоит в том, чтобы описать все потенциальные проекты, которые должны поступить в работу в ИТ-отдел. Чаще всего это длинный список, который не так просто составить, ведь запросы на проекты поступают из огромного количества источников, разбросанных по компании. Хорошим началом будет создание реестра проектов ИТ-отдела. Все проекты, включая любые текущие задачи апгрейдов оборудования или ПО, должны быть собраны и добавлены в один мастер-список проектов. Как правило, ИТ-отделы имеют один или более списков проектов, находящихся в работе или в состоянии рассмотрения в настоящее время. Интервью с менеджерами отделов компании и топ-менеджментом компании помогают выяснить, какие еще проекты могут требовать выполнения.

После того как данный список создан, его надо оптимизировать, совмещая маленькие проекты с более крупными. Опыт показывает, что большинство первоначальных списков содержат более не спонсируемые или уже не соответствующие запросам компании проекты. Эти реликты тоже надо удалить из списка. Как это ни парадоксально, но для ИТ-отделов типична ситуация, когда проект держится в списке активных, даже если никто уже и не помнит, почему он туда попал. Такая оптимизация списка, как правило, уменьшает его на 60-70%.

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

Этап № 2. Описание проектов. Следующий этап в процессе управления приоритетами проектов требует определить параметры проектов на таком уровне, чтобы менеджмент компании (или комитет по управлению ИТ, о чем мы писали в № 5 за 2005 год) мог дать предварительное одобрение на внесение проекта в список активных проектов. Параметры, которые необходимо представить на рассмотрение, должны включать в себя четкие цели ИТ-проекта, предварительные оценки трудозатрат, временные рамки, доходы и расходы. Эти параметры позволяют быстро провести предварительную оценку относительной ценности проектов. Пункты, которые необходимо включить в документ, представляемый на рассмотрение топ-менеджменту компании, следующие:

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

Этап № 3. Утверждение проектов. Каждый проект, определенный согласно вышеизложенной схеме, должен быть представлен для предварительного одобрения менеджменту компании, которому подчинен ИТ-отдел. Данное одобрение не означает, что проект сразу же запускается в дело. Оно только показывает, что проект одобрен для детального анализа и участия в процессе управления приоритетами. Именно на этом этапе определяется количество ИТ-проектов, которые будут находиться в одновременной разработке в ИТ-отделе. В связи с тем, что процессы приоритезации достаточно затратны по объему работ, окончательно принятое количество ИТ-проектов, к которому придет ИТ-директор, должно быть очень серьезно продумано. Только действительно важные и неотложные проекты должны попасть в список одобренных. Количество и размер проектов, которые могут находиться в одновременной работе в ИТ-отделе, называется проектной мощностью ИТ-отдела. Вдумчивый анализ проектной мощности ИТ-отдела гарантирует, что число проектов, находящихся в одновременной работе, будет соответствовать как возможностям ИТ-отдела, так и способности организации адаптировать перемены.

ИТ директор должен поставить дело так, чтобы менеджмент компании мог добавлять ИТ-проекты в список одобренных. Но при этом непосредственно процесс приоритезации ИТ-проектов начинался бы только тогда, когда в ИТ-отделе высвобождались бы проектные мощности в связи с окончанием работы над предыдущим проектом или с приходом в команду ИТ-отдела новых сотрудников.
Проектная мощность

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

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

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

  1. Когда существующий проект завершен, и высвобождается проектная мощность ИТ-отдела.
  2. Когда в ИТ-отдел добавлены новые проектные мощности или сокращены существующие, то есть изменено общее количество одновременно разрабатываемых ИТ-проектов.
  3. Если выявлен высокоприоритетный проект, который по важности перевешивает имеющиеся в разработке в настоящее время. Это случай исключительный и редко встречающийся, но иногда он имеет место, например, если ключевые заказчики требуют изменений в связи с правительственными регулированием.

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

Как правило, единственным и наилучшим мерилом ценности проекта является его финансовая ценность для компании. Существует много методов подсчета финансовой ценности проектов, как то: ROI, время самоокупаемости, NPV, коэффициент возврата и прочие. Независимо от того, как в той или иной компании принято измерять финансовую ценность проекта, предпочтительнее простая оценка доходов и расходов, четкая документация главных расходов и описание источников прибыли. Затраты проекта обычно делятся на две части: однократные затраты на проект и постоянные затраты, возникающие в связи с поддержанием проекта. Аналогичным образом рассматриваются и доходы.

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

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

Риски проекта

Оценка воздействия рисков на приоритеты проектов является следующим шагом в процессе приоритезации. Как правило, категории рисков ИТ-проекта включают в себя риски, связанные со сложностью проекта, готовностью пользователей и технологиями, которые будут использоваться. Таблица 2 показывает, какие типовые риски надо оценить. В зависимости от проекта в риски проекта могут быть выделены и другие факторы. В любом случае проекту должен быть приписан некий уровень риска относительно других проектов.

Стратегическая ценность проекта

Стратегическая ценность проекта определяется как влияние, которое проект окажет на клиентов и поставщиков компании. Стратегическая ценность проекта дает представление о том, что данный проект дает компании, каковы новые возможности, которые улучшат способность компании работать с клиентами или поставщиками, а также насколько легко конкуренты смогут повторить данный проект. Таблица 3 показывает типовые категории, по которым оценивается стратегическая ценность проекта. Результатом анализа должен быть коэффициент стратегической ценности проекта по сравнению с конкурирующими проектами.

Приоритезация проектов

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

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

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

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

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

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

В среднем менеджеры проектов могут управлять только определенным количеством проектов в одно и то же время. Это число различается в разных компаниях. Принимаются во внимание такие факторы, как размер компании, культура, географическая распределенность, бизнес-цикл. Хотя число разнится, но в компаниях среднего размера рекомендуется вести не более двух крупных и четырех-семи мелких проектов единовременно. Возможности и способности каждого менеджера проекта по отношению к ведомому им проекту должны быть тщательно взвешены.
В ходе выполнения проектов

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

http://www.iemag.ru/

1905
Комментарии (1)
  • 29 марта 2012 в 13:40 • #
    Сергей Павлов

    жаль что практика отстает от наработок.


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008