Проектный менеджмент, портфель проектов: сценарии и риски - Казаков А. М.

Конец 20-го и начало 21-го века характеризуются огромным междисциплинарным влиянием смежных областей естествознания на всю систему экономических знаний и наук. Пополнение понятийной базы в экономической науке, в связи с применением методов математической экономики, выглядит робким шажком ребенка по сравнению с терминологическим бумом, привнесенным из информатики и компьютерной индустрии. Высока вероятность того, что в обозримом будущем такие экономические понятия, как корпоративные финансы и бухгалтерский учет будут использоваться в прикладном смысле в качестве синонимов торговых марок соответствующих информационных систем, например, “mySAP” и “1С-бухгалтерия”.

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

Успешными примерами консорциумов подобного рода в компьютерных дисциплинах являются: W3C.org - World Wide Web Consortium; OMG.org - разработчик стандартов UML, Corba, XML и других. В экономических дисциплинах, в частности, в управлении проектами, наряду с многочисленными национальными научными и специализированными школами успешно развивается так называемый Институт проектного управления (Project Management Institute) - PMI.org.

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

1

управления. В рамках деятельности ассоциации разработан стандарт ANSI/PMI 99-012004 PMBOK^[1] по процессам менеджмента проектами. Этот стандарт отличается от аналогичных документов большей универсальностью для практического применения и полнотой информационного охвата в рассматриваемой теме.

Общественная потребность в развитии менеджмента имеет прямые экономические корни. Во-первых, эффективность реализации проектов в любой сфере деятельности зависит от качества управления. Во-вторых, для сложных проектов, в которые вовлечены значительные материальные и людские ресурсы, эффективность использования инвестиций зависит от степени развития технологий и информационных систем поддержки процедур менеджмента (это как первая и вторая производные). В настоящее время ситуация складывается таким образом, что проще и дешевле перестроить менеджмент для обеспечения лучшего соответствия применяемым технологиям, чем вносить изменения в программные системы поддержки менеджмента, в сами технологии. Компьютерная индустрия предлагает целый “букет” новых инструментов -корпоративные информационные системы для осуществления совместной проектной деятельности, составления расписаний работ, распределения ресурсов, контроля исполнения заданий и поручений и аналитической работы. Эти новые инструменты управления проектами в соответствии с жизненным циклом создания приложений (application lifecycle management - ALM), как правило, хорошо описаны. Например:

• IBM Rational Unified Process (RUP) ^[2,3]

• Методология ARIS компании IDS Scheer AG ^[4]

• Microsoft Solutions Framework (MSF) ^[5]

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

В настоящее время компьютерная индустрия предлагает широкий выбор специализированных систем, предназначенных для решения задач в области проектного менеджмента ^[8]. К продуктам достойным серьезного внимания следует отнести такие системы, как Microsoft EPM (Enterprise Project Management), Primavera, Artemis, Open Plan, CA (Clarity), PlanView, SAP(xRPM).

Последний успех системы Primavera в значительной степени основан на производительности и предоставлении предприятиям и организациям спроектированной модели управления проектом для автоматизации процесса планирования, создания, контроля, учета и корректировки планов проекта. Программный продукт Open Plan компании Welcom имеет хорошие позиции в сегменте решений для строительных организаций. Система управления проектами Artemis предоставляет анализ портфелей проектов и может получать детализированную проектную информацию из других систем, управлять ресурсами и документами.

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

Проведем обсуждение проблемных вопросов вокруг следующих основных понятий проектного менеджмента:

• Портфель проектов (Project Portfolio) — множество проектов, объединенных для удобств управления. Они могут иметь или не иметь общую цель, и, как правило, имеют общие ограничения по ресурсам.

• Проект (Project) — целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги; разовое мероприятие, ограниченное по времени, бюджету и ресурсам.

• Жизненный цикл проекта (Project Life-Cycle) — набор последовательных фаз проекта, название и число которых определяется потребностями контроля организации или организаций, вовлеченных в проект.

Для того, чтобы сделанные в статье выводы, связанные с анализом причин низкой эффективности корпоративного управления портфелем проектов, носили конструктивный характер, вначале кратко опишем систему классификации базовых понятий и процедур проектного менеджмента PMI (стандарт ANSI/PMI 99-01-2004 PMBOK) и одну из лучших к настоящему времени компьютерную систему по работе с проектами (Microsoft EPM).

Современный стандарт проектного менеджмента

Несмотря на рекомендательный характер стандартов в области описания процедур проектного управления, в определении и классификации базовых терминов и понятий деятельность PMI оказала и продолжает оказывать за последние годы существенное положительное влияние на развитие менеджмента. В соответствии с концепцией стандарта ANSI/PMI 99-01-2004 PMBOK процедуры проектного менеджмента подразделяются на 9 областей знаний (рис.1). В свою очередь эти области знаний включают основные и вспомогательные процессы проектного менеджмента, описание

которых приводится ниже.

Основные процессы

Менеджмент сроков проекта. В состав этой области входят следующие процессы: определение состава, последовательности и продолжительности работ; разработка и контроль расписания работ. Эти процессы включают в себя соответствующие процедуры: разделение полного пакета работ на элементарные работы и определение их характеристик; установление последовательности работ с учетом ограничений по видам зависимостей (жесткие, нежесткие, внешние) и ограничений по порядку выполнения (финиш-старт, финиш-финиш, старт-старт, старт-финиш, ASAP “as soon as possible”, ALAP “as late as possible”); метод итеративной оценки длительности уникальных операций

с учетом видов оценок (экспертная по методу Дельфи, по производительности, по объему,

4

аналоговая); графическое отображение диаграмм взаимосвязей между работами (стрелочная и условная, предшествования и сетевая, Ганта и контрольных точек); метод составления расписания выполнения работ с учетом зависимостей и ограничений между работами (PERT “Program Evaluation and Review Technique), критического пути, нескольких критических путей, выравнивания ресурсов, оптимального расписания, эвристический; метод сжатия срока работ проекта.

Менеджмент стоимости проекта. В состав этой области входят следующие процессы: планирование ресурсов проекта; оценка, контроль и анализ стоимости; бюджетирование. Эти процессы включают в себя соответствующие процедуры: планирование с нижнего уровня иерархической структуры проекта WBS (Work Breakdown Structure); расчет потребности в ресурсах; методы оценки стоимости проекта (по аналогу, параметрическая, “снизу-вверх”, вероятностная, PERT); оценки стоимости (порядок величины стоимости проекта, бюджетной и точной оценки стоимости); расчет базового стоимостного плана, базовых показателей (освоенный и плановый объемы, фактическая стоимость) и основных производных показателей (отклонение по стоимости и по срокам, индекс выполнения бюджета, индекс выполнения календарного плана и прогнозирующих показателей).

Менеджмент персонала проекта. В состав этой области входят следующие процессы: организационное планирование; подбор персонала; развитие команды. Эти процессы включают в себя соответствующие процедуры: планирование управления персоналом; построение диаграмм занятости ресурса, матрицы ответственностей; регламенты разрешения конфликтов при привлечении персонала функциональных подразделений в проект, при предварительных назначениях; работа с персоналом, с учетом основ мотивации исполнителей ^[11] (пирамида Маслоу, теория Херцберга); методы анализа причин и способы разрешения конфликтов; распределение полномочий в проекте.

Вспомогательные процессы

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

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

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

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

Менеджмент качества проекта. В состав этой области входят следующие процессы: планирование, обеспечение и контроль качества. Процесс планирования включает в себя соответствующие процедуры: разработка измеряемых и проверяемых показателей качества; расчет стоимости соответствия и несоответствия показателям качества; оценка оптимального качества и минимальной стоимости качества (диаграмма Ишикава, закон Парето). В управлении качеством применяется приоритет планирования и обеспечения качества над инспекциями и тестированием, обеспечивается соответствие стандартам по качеству ISO и ANSI/PMI 99-01-2004 PMBOK.

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

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

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

Проектный офис

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

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

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

7

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

Стандарт ANSI/PMI 99-01-2004 PMBOK достаточно подробно описывает функциональные обязанности специальных организационных структур внутри компании, создаваемых исключительно для ведения проектной деятельности. К таким структурам относятся: Проектный офис (PMO); Управляющий (Проектный) комитет; Комитет по управлению изменениями проектов. Кроме структурных подразделений отдельно определяются роли ключевых участников (субъектов) проекта: руководитель, спонсор и заказчик проекта.

На ролевом описании субъектов проекта, унифицированных по функциональным обязанностям, на описании специализированных организационных структур и комитетов, обеспечивающих в компании ведение проектной деятельности, базируется детальное построение процедур проектного управления в стандарте ANSI/PMI 99-01-2004 PMBOK. Такой подход обеспечил возможность конструктивного изложения реализации основных принципов стандарта в проектном менеджменте: тщательное планирование, организующая и координирующая роль руководителя проекта, контроль изменений, накопление опыта и передача его другим руководителям проектов компании. Все это, в свою очередь, позволяет обеспечить независимость ведения бизнеса от уникальности специалистов, принимающих в нем участие.

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

Автоматизация управления проектами

По неоднократным публикациям фирмы Gartner, Inc.^[6,7], одной из наиболее авторитетных и объективных среди компаний, проводящих маркетинговые исследования на рынках высоких технологий- система Microsoft EPM в настоящее время является лидирующим программным продуктом в сфере автоматизации процессов управления проектами (“Project and Portfolio Management Applications”).

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

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

Рис.2 Компонентная архитектура типовой EPM системы.

Из компонентной архитектуры системы Microsoft EPM (рис.2) следует, что она представляет собой сложное интеграционное решение, в котором задействован десяток основных информационных продуктов компании Microsoft. Каждый компонент системы отвечает за выполнение своих функций и может применяться независимо от остальных: обслуживание электронной почты, поддержка функций Интернет, работа с базами

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

Система Microsoft EPM ^[13] предоставляет возможности планирования и контроля хода выполнения задач, совместной работы в проектной группе и доступа через Интернет к проектной информации за счет интеграции следующих продуктов и технологий:

• MS Office System (MS Outlook) - настольная система, используемая для обеспечения решения стандартных офисных задач, включая почтовую службу.

• MS Office Project Professional - специализированная персональная система для планирования и управления отдельными проектами (“клиент” для Microsoft EPM).

• MS Project Web Site - технология, предоставляющая членам проектной группы доступ к версиям проектных документов и средства коммуникации между участниками.

• MS Project Web Access - технология на основе MS Project Server, обеспечивающая поддержку функций управления корпоративными проектами и ресурсами, управления рисками в проектах и правами доступа пользователей, а также позволяющая готовить сводную отчетность по проектам (“сервер” для Microsoft EPM).

Для реализации всех возможностей управления проектами и ресурсами требуется использовать MS SQL Server в качестве сервера базы данных и MS SharePoint Service для доступа к проектным документам и поддержки различных способов коммуникации.

Распределение функций в Microsoft EPM

Персональная система планирования предоставляет пользователю инструменты и возможности для выполнения следующих процедур: составление плана работ (задач) проекта и контроль хода их выполнения; формирование автоматизированных правил обновления проекта; проведение анализа бюджета проекта, в том числе - по методике освоенного объема; учет использования материальных и трудовых ресурсов. Доступ к информации имеет гибкие настройки представления данных, их группировки и сортировки, а так же графические индикаторы, сигнализирующие о проблемах и отклонениях от плана. Планирование возможно с учетом приоритетов задач в проекте и проведением расчета критического пути при выполнении задач проекта для анализа. Система планирования MS Office Project Professional используется в качестве интерфейса при управлении ресурсами проектов, в том числе для работы с общим пулом корпоративных ресурсов. В настоящее время эта система, из-за своей распространенности, “де факто” является отраслевым стандартом в менеджменте проектов.

Корпоративная система управления проектами (рис.3), построенная на основе MS Project Server, предоставляет интерфейс для совместной работы членов команды по

отдельному плану проекта и, в том числе, обеспечивает управление портфелем проектов.

10





MS Office Project Prof



• Создание проектных библиотек документов

• Работа с версиями проектных документов

• Автоматическое оповещение по email участников проекта об изменениях на сайте

• Коммуникации участников

• Internet / Intranet WEB доступ

• Календарное планирование состава задач в плане проекта

• «Контракт» между ресурсами проекта и задачами

• Расчет бюджета проекта

• Контроллинг, отслеживание за ходом выполнения

• Отчеты о ходе выполнения и изменениях

—I WEB-портфель проектов



MS Office Outlook

• Хранение и работа с персональной перепиской по проекту

• Ведение списка контактов

• Персональное планирование работ

• Получение автоматически генерируемых

e-mail извещений по проекту

• Имеется WEB доступ

• Бюджетное управление, анализ и моделирование портфеля проектов

• Корпоративное ресурсное планирование

• Контроллинг, распределенное отслеживание и управление ходом выполнения проектов

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

• Internet / Intranet WEB доступ, отчеты

Рис.3 Распределение функций по основным интерфейсам в типовой EPM системе

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

К сильным сторонам системы Microsoft EPM можно отнести:

• Доступность информации. Сведения о портфеле проектов по всей компании доступны через Internet для анализа и эффективного процесса принятия решений. Вместе с тем, обеспечены процедуры повышенной безопасности доступа к информации.

• Управление производственным процессом (Task Tracking). Имеется встроенный механизм оповещений и напоминаний о наступлении запланированных событий (диспетчеризация расписания для выполнения задач плана проекта).

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

• Гибкость настроек системы. Обмен информацией с другими системами и масштабирование системы по мере роста объемов данных. Система представляет разнообразные возможности по интеграции, например, интеграция с Microsoft Business Scorecard Accelerator для анализа сбалансированных показателей деятельности компании.

• Администрирование. Возможность для назначения прав доступа членов проектной группы к информационным объектам, процедурам, формам отчетности и другим настройкам в системе. Возможность выбора содержимого и внешнего интерфейса для пользователей Web-сайтов проектов.

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

К недостаткам системы Microsoft EPM можно отнести следующие: ограниченные возможности управления рисками; ограниченные возможности управления бюджетами; недостаточность возможностей планирования «сверху - вниз».

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

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

Методология корпоративного проектного управления может быть определена в соответствии с рекомендациями стандарта ANSI/PMI 99-01-2004 PMBOK. Следует отметить, что не все так называемые области знаний стандарта должным образом покрываются функциональностью системы Microsoft EPM, в частности - процедуры инициации проектов, процедуры менеджмента персонала, качества и снабжения.

Накопление и передача опыта или в соответствии с теорией принятия решений -передача знаний, может быть условно разделено на два типа ^[14]: накопление фактов (декларативное знание) и умение решать задачи (процедурное знание). Если знания первого типа аккумулируются в системе, то знания второго - остаются вне её рамок.

Модели жизненного цикла проектов

Принято классифицировать модели Жизненного Цикла проекта в сфере высоких технологий на два типа: прогнозирующий и адаптивный ^[15]. К прогнозирующему типу моделей относятся проекты с детальным планом достижения декларируемых целей и подцелей. К моделям осуществления плана работ с адаптивным Жизненным Циклом относятся проекты с заранее предусмотренными возможностями изменений в ходе процесса достижения целей проекта, проекты в которых заранее отвергается детальное планирование работ. Первые упоминания о моделях Жизненного Цикла прогнозирующего типа относятся к началу 70-х прошлого века ^[10]. Теоретическое обоснование применения модели базировалось на экономических предпосылках о полноте достижения подцелей проекта и возможности их оптимального упорядочивания.

Прогнозирующие модели жизненного цикла:

• Водопад, или "традиционная", или "сверху вниз" ^[3]. Модель характеризуется линейным упорядочиванием фаз, которые могут быть строго последовательными или в некоторой степени перекрываться, ни одна из фаз обычно не повторяется.

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

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

• Спираль ^[5]. Модель характеризуется тем, что повторяется один и тот же набор фаз жизненного цикла, таких как планирование, проектирование, построение и оценивание, до тех пор, пока разработка продукта не будет завершена.

Модели с адаптивными Жизненными Циклами:

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

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

• SCRUM. Эта модель подобна модели адаптивной разработки. Реализация проекта выполняется на итеративной основе. Итерации носят название "спринтов", которые имеют длительность порядка 30 дней (типовое значение). Каждый "спринт" должен дать на выходе определенную степень функциональности продукта,

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

Портфель проектов

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

Портфель проектов

Определение инициатив Оценка инициатив Определение Обеспечение приоритетов ресурсами Управление портфелем Проект Инициирование проекта Планирование проекта Реализация проекта Завершение проекта

Рис.4 Управление проектами в соответствии с моделью Жизненного Цикла.

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

Работа с портфелем проектов в системе Microsoft EPM начинается после того, как планы проектов подготовлены и загружены в систему. Имеющиеся в системе процедуры анализа, фактически являются средствами агрегирования проектов для упрощения контроля сводных значений по стоимости и по использованию ресурсов. Для анализа портфеля проектов имеется широкий набор заранее подготовленных форм отчетов, а также OLAP средства оперативного анализа, так называемый гиперкуб ^[13,15].

Достаточно ли имеющихся в системе Microsoft EPM средств и процедур для управления портфелем проектов - ответ положительный в том смысле, что этих процедур достаточно в той же степени, насколько достаточно возможностей, заложенных в системе MS Office Word для того, чтобы быть использованной при написании произведения типа «Война и мир». Естественно, без каких-либо рекомендаций автору о том, как этот проект реализовать на практике.

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

Логическое и временное взаимодействие групп процессов управления портфелем проектов, в соответствии с моделью Жизненного Цикла (рис.4), в настоящее время в системе Microsoft EPM отсутствует. Деятельность по инициированию нового проекта в ряде компаний условно относится к проектной деятельности (т.н. организационный проект), в других компаниях эти задачи решают при помощи специальных корпоративных регламентов. Компаниям - пользователям системы Microsoft EPM в обеспечение этой цели рекомендовано самостоятельно разрабатывать или интегрироваться с имеющимися корпоративными системами делопроизводства, с одной стороны, и аналитическими системами оптимизации портфеля проектов, с другой стороны, предлагаемыми на рынке информационных систем независимыми производителями.

Корпоративный проект

Рассмотрим отдельный экземпляр корпоративного проекта. В соответствии с моделью Жизненного Цикла проект содержит пять групп процессов управления: инициации, планирования, исполнения, контроля, завершения (рис.5). Вместе с тем, следует отметить отсутствие формального определения для термина - “корпоративный проект”.

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

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

Инициирование Планирование Исполнение Контроль Завершение проекта проекта проекта проекта проекта

Рис.5 Модель бизнеса при управлении проектом в проекции на ресурсы.

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

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

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

Технологические риски

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





WEB-сайт проекта

• Отсутствие единого стандарта делопроизводства у Исполнителя и Заказчика ограничивает процедуры утверждения документов, согласования вопросов и принятия решений

• Не все участники процесса участвуют в проекте

• Наличие внешних Исполнителей не позволяет интегрировать EPM систему с корпоративной почтой и информационными ресурсами

• Наличие инструмента для составления плана, но отсутствие единой методики

- В реальном плане около 10002000 задач

- В календарном плане (Диаграмма Ганнта) число связей в несколько раз больше

• У внешних исполнителей нет доступа к базе данных корпоративных ресурсов Заказчика

• Отсутствие базы данных нормативов

• Варианты планов Исполнителя и Заказчика

MS Office Outlook

• Самостоятельное конфигурирование MS Outlook для совместной работы с EPM системой на прием информационных сообщений по проекту

- Добавление в «Контакты» и «Списки адресов» участников проекта и проч.

• Корпоративные требования безопасности на подключение к внешнему почтовому сервису

• Произвольное составление и кодирование задач лишь одного плана проекта исключает свод бюджета «портфеля»

• Различный учёт затрат ресурсов у внешнего Исполнителя и у Заказчика

• Недоступность внешнему Исполнителю централизованных проектных ресурсов и корпоративной регламентной базы

Рис.6 Риски в типовой Microsoft EPM системе

Выводы

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

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

• современные направления развития проектного менеджмента;

• описание стандарта ANSI/PMI 99-01-2004 PMBOK в качестве модели ”To Be”;

• описание системы Microsoft EPM в качестве модели “As Is”;

• описание практики применения процедур по модели Жизненного Цикла;

• анализ предметной области и формулирование проблемных вопросов.

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

Стоит подчеркнуть, что стоимость лишь управления проектом в подавляющем большинстве случаев составляет 2-10% в общей стоимости прямых затрат на проект. Управление портфелем проектов, в связи с этим фактом, является важной и конкретной экономической задачей. Результат проведенного анализа состоит в констатации того факта, что ожидания от применения новых и достаточно сложных технологий менеджмента остаются до конца не оправданными. Достигаемые практические результаты в управлении портфелями корпоративных проектов несопоставимы с прилагаемыми усилиями и затратами.

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

Литература

1. A Guide to the Project Management Body of Knowledge. ANSI/PMI 99-01-2004 PMBOK Guide. Third Edition., 2004

2. Кролл П., Крачтен Ф. Rational Unified Process - это легко. Руководство по RUP для практиков; М.: Кудиц-Образ, 2004

3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения; СПб.: Питер, 2002

4. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. Практическое руководство; М.: Весть-МетаТехнология, 2001

5. Microsoft Corporation. Анализ требований и создание архитектуры решений в среде Microsoft .NET; М.: ИТД "Русская Редакция", 2004

6. Gartner, Inc. Microsoft/UMT Deal Will Make Portfolio Optimization Mainstream; Jan., 2006

7. Gartner, Inc. Market Share: Project and Portfolio Management Software, Worldwide (Executive Summary); Jul., 2005

8. Gartner, Inc. Magic Quadrant for IT Project and Portfolio Management Applications; Jun., 2006

9. Казаков А.М. Особенности современного менеджмента; Всероссийская научнопрактическая конференция "Стратегия и тактика развития России". - Труды вольного экономического общества России; М.-СПб., 2006

10. Боэм Б. Инженерное проектирование программного обеспечения; М.: «Радио и связь», 1985

11. Karlof B., Lovingsson F. Rollinsford The A-Z of Management Concepts and Models; NH: Thorogood, 2005

12. Смирнов Э.А. Основы Теории организации; М.: ЮНИТИ, 1998.

13. Мармел Э. Microsoft Office Project 2003. Библия пользователя; М.; Издательский дом «Вильямс», 2004

14. Ларичев О.И. Теория и методы принятия решений; М.: Логос, 2003

15. Гультяев А.К. Microsoft Office. Project Server 2003. Project Professional 2003. Управление корпоративными проектами: Самоучитель; СПб: КОРОНА принт: Бином пресс, 2005

16. Рассел А. Модели жизненного цикла высокотехнологичных проектов; Российская Ассоциация Управления Проектами "СОВНЕТ", 2005

19

Содержание раздела

---