bigpo.ru
добавить свой файл
1

Секция “Стандарты и управление проектами”


Метод и опыт создания стандарта предприятия по управлению ИТ-проектами


Товб Александр Самуилович

A_Tovb@ibs.ru

Ципес Григорий Львович

Gtsipes@ibs.ru

IBS, Москва


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

Основные темы доклада:

  1. Основные подходы к созданию стандарта уровня предприятия.

  2. Конкретное наполнение стандарта.

  3. Пути превращения стандарта предприятия в работающий инструмент управления проектами.

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

Специализация и детализация

Ключевыми для построения стандарта предприятия понятиями являются специализация и детализация.

Стандарты управления проектами уровня предприятия в части методологии обычно имеют основу, определяемую документами достаточно общего характера (иногда эти документы называют "рамочными"). К таким документам относится Project Management Body of Knowledge (PMBoK) Американского института управления проектами (PMI), признаваемый международным стандартом де-факто, и стандарт ISO 10006:1997, придавший ряду наиболее важных положений PMBoK статус стандарта де-юре. Смысл и содержание перехода от рамочных стандартов (какими являются и PMBoK, и в еще большей степени ISO 10006) к стандарту предприятия состоит в их специализации и детализации.

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

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

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

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

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




Рис. . Пространство процессов управления

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

Классификации и шаблоны

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

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

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

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

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

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

Классификация по форме оплаты и, следовательно, учета работ позволяет специализировать Контроль и отчетность, Управление проектной документацией на основании таких форм контрактов, как "Время и материалы" и "Фиксированная цена".

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

Таблицы решений

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

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

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

Табл. . Матрица степени угрозы риска

Вероятность события

Влияние на проект

Низкая

менее 20%

Средняя

от 20 до 60%

Высокая

более 60%

Слабое

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

Низкая

Средняя

Средняя

Среднее

Возможно нарушение графика, увеличение стоимости или ухудшение качества продукта

Низкая

Высокая

Высокая

Сильное

Возможно значительное нарушение графика, увеличение стоимости или ухудшение качества продукта

Средняя

Высокая

Критическая





Рис. . Стратегии изменений в проекте


Организационные структуры

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

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

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

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


Информационные технологии

Остановимся на двух основных направлениях – автоматизация стандарта управления проектами и автоматизация функций управления проектами.

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

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

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

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

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

Заключение

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

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

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

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

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


- -