Некоторые подходы к управлению портфелем проектов в ИТ-службе предприятия

Ежов М.О.
выпускник группы MBA CIO-38
Школы IT-менеджмента
РАНХиГС при Президенте РФ

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

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

1. Распределение ресурсов по задачам портфеля проектов.
2. Оптимальное заблаговременное планирование резерва времени (далее «подстраховка» или «буфер»), которое позволяет распределить подстраховку, только в тех точках, где она необходима, и исключить ненужную подстраховку там, где она бессмысленна.
3. Экономия времени и средств, за счет определения единичных критических ресурсов, усиление которых сокращает сроки реализации всего портфеля проектов.

Методологической основой данной статьи является применение теории ограничений (ТОС) к задаче управления портфелем проектов.  Данная статья,  за рамки которой выходит подробное описание ТОС,  содержит практические рекомендации по применению ТОС к портфелю проектов. Для более подробного ознакомления с ТОС можно обратиться к работам Э. Голдратта.

В основе ТОС лежит представление о том, что для получения улучшения работы всей организации в целом, надо выявить одно, самое слабое звено (далее «критическое звено»), которое задерживает работу всей системы, и усилить его. Этот процесс  является циклическим. После усиления одного звена, при необходимости, можно повторить работу по поиску следующего критического звена и его усилению. Данный итерационный процесс может повторяться: либо до того момента, когда будет достигнут требуемый уровень производительности; либо, когда затраты на усиление звеньев подойдут к допустимому порогу; либо, когда критическим звеном станет такое звено, ограничением которого проще управлять.

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

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

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

Как избежать описанных проблем?

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

Предположим, даны сетевые графики каждого проекта. Известны:

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

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

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

На рис. 1 и 2 представлены сетевые диаграммы проектов, составленные без учета критической цепи (конкуренции за ресурсы).

рис. 1

рис. 2

На рис.3. представлен пул ресурсов.

рис. 3

На данном этапе, перед установкой буферов, можно рассмотреть существующую загрузку ресурсов с точки зрения ТОС.  ТОС утверждает, что в каждый момент времени, есть всего один, наиболее загруженный ресурс, который задерживает работу всей системы. Очевидно, что в данном случае это ресурс №6. В одно и то же время этот ресурс должен выполнять 2ю и 4ю задачи проекта №2 и 6ю задачу проекта №1.

Если выровнить ресурсы сейчас, то дата завершения портфеля будет 16.04.2015, усилив ресурс в 2 раза, дата завершения сдвигается на 13.04.2015, такой же результат будет, если усилить ресурс в 3 раза (данную «быструю» оценку, нельзя считать окончательной, здесь есть тонкость, которая будет упомянута далее).

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

На рис.4 представлен выровненный пул ресурсов, с усиленным в 2 раза ресурсом №6.

рис. 4

В данный момент, конкуренция за ресурсы отсутствует. Однако, полученные сетевые графики подвержены всем проблемам, описанным в начале статьи. Задержка исполнения одной из задач, приведет к нарушению графиков работы всех ресурсов. В конкретных учебных примерах, с этим будет легко разобраться. Задайте себе вопрос: возможно ли легко разобраться если портфель состоит из нескольких проектов, приведенных на рис.5 ?
рис. 5.

Что сделано на данный момент?

1. Составлен сетевой график для каждого проекта;
2. Каждой задачи назначен ресурс;
3. Определен наиболее загруженный ресурс;
4. Проведен анализ целесообразности усиления ресурса (пункты 3 и 4 могут повторяться циклически, до достижения оптимальных результатов);
5. Ресурсы выровнены (в MS Project это может быть сделано автоматически командой «Выровнять все»/«Level All»);

Для снижения вероятности описанных проблем необходимо провести еще ряд процедур. Ниже их описание, а так же дополнительные рекомендации:

1. Определить критические пути каждого проекта.
2. Последовательно для каждого проекта определить позиции буферов и «их ресурсы». В условиях конкуренции за ресурсы, буфер, устанавливаемый в одном проекте, выполняет сразу 2 функции:     
   а) Функция защиты задач проекта - защищает следующую за собой  задачу от превышения времени исполнения предшествующей задачи.      
   б) Функция защиты ресурса - обеспечивает  готовность ресурса принять следующую за собой задачу, даже если ресурс задерживается с выполнением предыдущей задачи.
   Задачи пункта «а» и пункта «б», скорее всего, будут разные.
3. Выявить задачи предшествующие каждому буферу. Определить возможную задержку на этом пути. Установить соответствующий размер буфера.
4. Вручную скорректировать позицию буфера. Почему вручную? После установки размера (длительности) буфера, в планировщике может появиться конкуренция за ресурсы. Применительно к MS Project данное выравнивание лучше выполнить вручную, так как автоматическое выравнивание не следит за позицией задачи и, скорее всего, не поставит буфер перед той задачей, которую тот должен защищать.
5.  Пункты 6, 7, 8, 9 делаются последовательно для каждого проекта портфеля. Сначала все 4 пункта выполняются для 1го проекта, затем для 2го и т.д.
6. После того, как буферы расставлены, их длительности определены, и ресурсы выровнены, расписание ресурсов можно считать окончательным.
7. Установка общего буфера проектов. Эти буферы могут быть рассчитаны исходя из максимальных ожиданий задержек каждой задачи каждого проекта. В связи с тем, что вероятность максимальной задержки одновременно во всех задачах всех проектов стремится к нулю, вероятность выполнить проект в срок стремится к ∞.

Определение позиции буферов
Э. Голдратт, создатель ТОС, рекомендует установку буферов в местах, где некритическая цепь соединяется с критической. Это логично, т.к. задачи критической цепи больше всех нуждаются в своевременном начале.  Далее, в статье вводится дополнительный термин «питающая цепь». Этот термин определяет последовательность связанных задач, следующих от начала, до соединения с критическим путем проекта. Демонстрируемые в данной работе проекты позволяют человеку распределить буферы вручную. Однако, данный процесс может быть автоматизирован, что исключит вероятность ошибки и позволит выполнять данную работу в проектах с большим количеством задач. Автором данной статьи написан комплекс макросов, который выполняет данный функционал в программе MS Project.

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

рис.6

рис.7.

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

Определение длительностей буферов связана с:

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

Данные вопросы заслуживают отдельного внимания, и в данной статье не рассматриваются.
На данном этапе необходимо устранить псевдо-конкуренцию. В проекте № 1 буфер в строке №5 достаточно сдвинуть на 2 дня раньше. Проект №2 более интересный. В нем наблюдается конкуренция буферов и задачи № 9 первого проекта за ресурс №6. Так же, есть 2 буфера выходящих из одной задачи. Благодаря тому, что ресурс №6 усилен, для устранения конкуренции достаточно сдвинуть буфер в строке 7 на 2 дня раньше. Что же касается буферов в строках 4 и 5, это произошло из-за того, что каждый буфер страхует свою задачу со своим ресурсом на критическом пути. Результат выравнивания представлен на рис. 8, 9, 10.

рис.8

рис.9

рис.10

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

Для удобства, каждая критическая задача имеет префикс «Crit». По рекомендациям Э. Голдратта в сетевых графиках проектов буферы расставлены перед  заданиями критического пути. Есть так же критическая цепь, критические задания которой тоже должны быть застрахованы.  Рассмотрим пул ресурсов, приведенный на рис. 10, с целью поиска критических задач, нуждающихся в страховке. Такая задача есть в проекте № 1, она носит название «Crit_Задача_5». До плановой даты начала этой задачи, выполняющий ее Ресурс №1, полностью загружен. В случае задержек предшествующих задач, это приведет к задержке критического пути проекта №1. Данная задача должна быть застрахована. Предшествующая ей задача №3 проекта 2 разделена на 2 части (это еще одна тонкость составления сетевых графиков, за которой нужно следить, т.к. в реальной жизни, могут быть процессы которые нельзя делить на части), первая ее часть предшествует критической задаче. Если запас в один день достаточен для страховки, достаточно перенести начало задачи №3 на 6 апреля. Предположим, нужен запас времени 2 дня. В этом случае вводится дополнительный страховочный буфер как показано на рис. 11.

рис.11

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

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

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

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

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

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