Управление портфелем ИТ-проектов

31.05.2008 16:48:12

Алексей Субботин

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

1. ВВЕДЕНИЕ

Для реализации любой управленческой методики необходимы:

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

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

2. ОБЛАСТЬ ПРИМЕНЕНИЯ УПРАВЛЕНИЯ ИТ-ПРОЕКТАМИ

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

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

Из определения видно, что для того, чтобы определить портфель проектов, необходимо:

1. Определить проекты.
2. Определить пул ресурсов.
3. Определить центр ответственности (руководителя или руководящий орган).

Примеры определения области применения УП приведены в таблице.

Основным критерием выделения проектов является необходимость в обособлении некоторой деятельности в виде отдельного объекта управления.

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

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

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

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

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

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

3. ОРГАНИЗАЦИОННАЯ СТРУКТУРА
При управлении портфелем проектов целесообразно выделять роли, приведенные в таблице.

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

Рис. 1 – Постоянная часть оргструктуры портфеля проектов

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

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

Рис. 2 - Примеры оргструктуры портфелей проектов

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

4. СТРУКТУРА ИНФОРМАЦИИ

Структура информации по портфелю может быть разделена на информацию по проектам и информацию по портфелю проектов в целом.

Проектная информация включает:

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

Информация портфеля проектов включает:

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

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

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

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

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

Структура затрат проекта состоит из:

• статей прямых затрат, структурируемых по WBS (для ИТ-проектов это обычно стоимость рабочего времени сотрудников, субподряды, закупки);
• статей «общепроектных» прямых затрат (например, специальные офисные помещения, командировки, коммерческие расходы);
• статей распределяемых на проект накладных расходов портфеля и расходов организации в целом (в большинстве ИТ-проектов, где основной категорией затрат являются трудозатраты, производственные накладные расходы могут распределяться на человеко-час, а непроизводственные накладные – на единицу производственных расходов).

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

5. ПРОЦЕССЫ УПРАВЛЕНИЯ

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

• Прогнозирование портфеля.
• Открытие проекта.
• Закрытие проекта.
• Периодическое планирование и периодический контроль портфеля.

Прогнозирование портфеля

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

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

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

• Обновить бюджеты проектов, которые переходят через границу года.
• Разработать ориентировочные бюджеты для проектов, которые могут быть более или менее точно оценены.
• Сделать грубые оценки для проектов, про которые еще ничего неизвестно – например, исходя из исторической информации о загрузке мощностей (специалистов) компании (например, на уровне 80%) и выручке по проектам на единицу мощности (человеко-час). Включить их в бюджет как один или несколько проектов.

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

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

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

Открытие проекта

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

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

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

Закрытие проекта

При закрытии проекта актуализируется вся информация и интегрируется в отчетную информацию по портфелю проектов. Проект с момента закрытия перестает существовать.

Периодическое планирование и периодический контроль
Периодически (например, раз в месяц) осуществляется контроль проектов на уровне директора проектов.

При этом:

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

Директор проектов отчитывается руководству в установленном в организации порядке.

6. МОТИВАЦИЯ

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

Мотивация – процесс стимулирования сотрудников к определенному поведению.
Из этого определения следует, что для мотивирования сотрудников необходимо:

1. определить желательное поведение сотрудников;
2. определить процесс стимулирования, т.е. систему правил, процедур, механизмов стимулирования.

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

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

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

Определение желательного поведения сотрудников

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

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

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

Оценка поведения сотрудников

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

Пример – Действительно, если рассмотреть двух сотрудников, одинаковой квалификации, которые показали одинаковую эффективность и уровень качества, но один участвовал в проекте 2 чч, а другой – 120 чч, то их вклад в выполнение проекта, скорее всего, различен.

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

Формирование и распределение премиальных фондов

Премиальные фонды участникам проектов могут формироваться из следующих источников:

• бюджеты программ мотивации;
• бюджеты проектов (например, из экономии затрат, или как доля от прибыли).

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

Пример – На рисунке ниже приведен пример схемы распределения премиальных фондов. Премиальный фонд проекта формируется из экономии резервов и фиксированного премиального фонда, предусмотренного программой мотивации «ПМ1». Этот фонд распределяется между участниками проекта по некоторым правилам. Кроме того участники проекта получают премии из бюджета программы мотивации «ПМ2», на основе оценки руководителя проектов, а руководитель проекта – на основе оценки директора проектов.

Рис. 3 – Пример схемы формирования и распределения премиального фонда

Подробный пример программы мотивации для проектно-ориентированной компании приведен в [2].

7. ВНЕДРЕНИЕ УПРАВЛЕНИЯ ПРОЕКТАМИ

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

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

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

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

8. ЗАКЛЮЧЕНИЕ

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

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

9. СПИСОК ЛИТЕРАТУРЫ

1. Субботин А.В. Трудозатраты и стоимость //Директор информационной службы, №7-8, 2002 – c. 29-33.
2. Субботин А.В. Программы мотивации в проектно-ориентированной компании //Директор информационной службы, №9, 2002 – c. 20-25.

Об авторе

Алексей Субботин

·         Сертифицированный профессионал по управлению проектами (категория R в системе сертификации IPMA)  

·         Кандидат физико-математических наук  

·         Многолетний опыт работы в управленческом и ИТ-консалтинге