Корпоративное управление проектами в России

Либерзон В.И., генеральный директор «Технологии управления Спайдер»

Введение

Внедрение технологий управления проектами в России переживает период бурного роста,

начавшегося примерно в 1996 году и на время приостановленного кризисом 1998 года. Все

новые и новые отрасли начинают применять и технологии, и программные средства

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

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

В 1993-1994 годах управление проектами применялось в отдельных проектах Газпрома и Стройтрансгаза, однако в качестве корпоративной методологии оно принято не было и попытки применения были больше связаны с энтузиазмом отдельных людей, чем с политикой корпорации.

В 1996 – 1997 годах удалось запустить управление проектами в строительстве благодаря наглядному уроку, преподанному при строительстве Олимпийской деревни для Всемирных Юношеских Игр 1997 года. Проект был признан важнейшей Московской стройкой года, в нем принимало участие 17 крупных подрядчиков, а сама Деревня была построена в рекордно короткие для такой стройки сроки. Управление строительством осуществлялось с помощью пакета управления проектами Spider Project, а преимущества применения методологии и программы управления проектами были столь наглядны, что начался бум внедрения управления проектами на Московских строительных предприятиях, остановленный лишь кризисом года. В прошлом году этот бум возобновился и теперь захватил и другие города вплоть до Владивостока.

В 2000 году «проснулись» телекоммуникационные компании. Достаточно сказать, что в 2000 – 2001 годах на курсах Московского отделения PMI прошли обучение представители Билайн, Центрального Телеграфа, Combellga, Ericsson, Глобал один, Телесофт, Сеть-проект и целого ряда других компаний.

К концу 2000 года подтянулись и производители программного обеспечения, системные интеграторы, Интернет компании, у которых интерес к управлению проектами сейчас развивается особенно бурно. Так, например, в компании АйТи в корпоративной сети 35 рабочих мест, оснащенных программой Spider Project и использующихся для корпоративного управления проектами, включая мультипроектное управление.

В 2001 году к миру управления проектами подтянулись банки – сначала подразделения АйТи, а теперь уже и другие подразделения крупных Московских банков осознали преимущества использования этой методологии и начали внедрять ее у себя. В качестве примеров приведу Альфа банк и Московский Кредитный банк.

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

С 1998 года управление проектами применяется и в Министерстве Обороны РФ.

Общепринятые методики предлагают использовать для планирования и управления сроками и стоимостью проектов стандартные западные программные средства (MS Project, Primavera Project Planner, Open Plan). Однако попытки использовать такие средства выявили серьезные противоречия с принятыми в России подходами к планированию и учету исполнения работ проектов. В частности, серьезно мешало отсутствие возможности планирования и учета не только длительности, но и объемов выполненных работ, слабые возможности моделирования работы ресурсов и требуемых затрат, ограничения по моделированию проектных рисков.

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

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

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

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

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

Особенности используемого программного обеспечения управления проектами Особенности технологии управления проектами в России связаны с особенностями и возможностями применяемых программных средств – в России наиболее популярным профессиональным пакетом управления проектами является пакет Spider Poject. Мы перечислим некоторые из его свойств, которые активно используются в управлении проектами в России и которые отсутствуют, либо недостаточно развиты в известных американских пакетах:

1) Использование объемов работ наряду с длительностью при задании характеристик операции. Если объем работ и производительность назначенных ресурсов задается в качестве исходной информации, то длительность операции вычисляется в процессе составления расписания работ, 2) Возможность задания пулов ресурсов для операции. Пул ресурсов на операции – это совокупность ресурсов, способных исполнять операцию, хотя и с разной производительностью, 3) Возможность создания и использования во всех проектах баз данных характеристик элементов проектов – производительности ресурсов на типичных операциях, длительности типичных операций, единичных затратах на типовых операциях и т.д.

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

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

6) Встроенный анализ рисков, который позволяет рассчитать вероятность исполнения директивных сроков и бюджета проекта, а также определить те резервы характеристик проекта (длительности, стоимости, потребности в материалах и оборудовании), которые следует заложить в план, чтобы выполнить запланированные в проекте показатели с заданной вероятностью. Рассчитанные резервы являются аналогами Project buffers теории Critical Chain.

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

Офис сопровождения проектов Офис сопровождения проектов состоит из трех секторов 1) Аналитический сектор, 2) Методологический сектор, 3) Архивы.

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

Методологический сектор:

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

Архивный сектор:

- ведет архивы проектов, - совместно с методологическим сектором разрабатывает case studies, которые служат для обучения менеджеров проектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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