Стандарты управления проектами компаний в части методологии обычно имеют основу, определяемую документами общего характера, которые называют рамочными. К таким документам относится Project Management Body of Knowledge Американского института управления проектами, признаваемый многими международным стандартом де-факто, и стандарт 1БО 10006:1997, смысл и содержание которых состоит в их специализации и детализации.

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

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

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

Классификация проектов как первый этап создания стандарта

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

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

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

Время, Стоимость Кдяество | Риски ферсонал Коммуникации Контракты Изменения

Ж Функции управления

2

I си іа їх

Инициализации) Планирование Выполнение Контроль Закрытие

Фазы управления

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

Источник : Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия //Директор информационной службы. 2002. № 1-6.

В плане управления проектом отражены:

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

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

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

Классификация по форме оплаты и учета работ позволяет специализировать: «Контроль и отчетность», «Управление проектной документацией» на основании таких форм контрактов как «Время и материалы» и «Фиксированная цена». Таким образом, можно вести речь, например, о шаблоне «План управления проектом создания концепции (продукт) информационной системы (предметная область) стоимостью свыше 100 тыс. долл, (масштабность) с контрактом в форме “время и материалы” (форма оплаты и учета работ)», как о макрошаблоне, получаемом простой сборкой из нескольких более мелких (микро) шаблонов отдельных разделов плана.

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

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

Таблица 4.18

Специализированный микрошаблон «Содержание и границы проекта создания ИТ-инфраструктуры филиала банка»

Пункт микро	филиала банка
Обоснование проекта (Project justification)	Описываются основные характеристики продукта и их взаимосвязь с деловой необходимостью или иными стимулами	Во всех филиалах должна быть установлена унифицированная, надежная, гибкая и легко наращиваемая ИТ-инфраструктура на основе платформы, позволяющей использовать в качестве основного средства обработки бизнес-транзакций прикладное программное обеспечение
Продукт проекта (Project product)	Основные характеристики продукта и их взаимосвязь с деловой необходимостью	Доставить, установить и настроить оборудование и системное программное обеспечение во вновь создаваемый филиал банка, формирующее основу для последующего внедрения банковской информационной системы
Результаты проекта (Project deliverables)	Приводится перечень результатов (подпродуктов), достижение (полное и успешное создание) которых означает завершение проекта	Спецификации системного программного обеспечения и его конфигурация. Требования к помещению для установки оборудования. Перечень оборудования и программного обеспечения. План технического решения. Эталонные копии установки и конфигурации системного программного обеспечения. Оборудование и системное программное обеспечение, доставленное в филиал банка, установленное и подготовленное для установки банковской информационной системы
Критерии оценки результатов (Project objectives) 1	Описание количественных критериев, которые должны быть удовлетворены, чтобы проект считался успешным	Срок доставки оборудования и программного обеспечения в Москву не должен превышать XX дней. Срок наладки оборудования и программного обеспечения в Москве не должен превышать УУ дней. Срок транспортировки оборудования и программного обеспечения в филиал банка не должен превышать ЪЪ дней. Срок установки и наладки оборудования и программного обеспечения в филиале не должен превышать УУ дней

Сопоставив приведенное в примере содержание разделов «Продукт проекта» и «Результаты проекта», можно заметить, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании плана часто используют структуру декомпозиции работ (WBS - Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IВМ).

Структура декомпозиции работ

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

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

Функциональный

заказчик

	Проект П1	Проект П2	Проект ПЗ

Инвестор

Договор Д1

Исполнители

• ----Декомпозиция по содержательному признаку
• -Декомпозиция по формальному признаку (финансовые потоки)

Рис. 4.24. Декомпозиция работ по различным основаниям Источник:

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

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

План управления проектом и рамочные стандарты

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

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

Проектные отклонения. Риски, проблемы, изменения

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

Сценарии управления отклонениями. Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:

• 1) управление рисками. Неприятности еще не наступили, но существует возможность возникновения нежелательных и незапланированных событий, которые могут привести к тому, что цели проекта не будут достигнуты. Цель этой стадии - предотвратить неприятности до их возникновения;
• 2) управление проблемами. Неприятности наступили и необходимо выяснить их происхождение, степень влияния на проект, способы преодоления. Цель этой стадии - обеспечить проекту возможность идти так, как запланировано;
• 3) управление изменениями. Неприятности оказались серьезными, и справиться с ними без ущерба для проекта не удалось. Цель этого этапа (то, что у финансистов называется «зафиксировать убытки») - модификация ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов.

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

Рис. 4.25.

Источник : Товб А.С. Ципес Г.Л. Указ. соч.

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

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

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

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

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

Таблица 4.19

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

^"""-"----^Вероятность события Влияние на проект	Низкая (менее 20%)	Средняя (от 20 до 60%)	Высокая (более 60%)
Слабое. Возможно появление вопросов или проблем в проекте, но это вряд ли приведет к нарушению календарного графика, бюджета или ухудшению качества продукта
Среднее. Возможно нарушение графика, увеличение стоимости или ухудшение качества продукта
Сильное. Возможно значительное нарушение графика, увеличение стоимости или ухудшение качества продукта

Источник". Товб А.С. Ципес Г.Л. Указ. соч.

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

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

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

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

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

Матрица приоритетов решения проблем

Таблица 4.20

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

Источник

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

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

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

Область недопустимых потерь

А Ресурсы

Продукты

Рис. 4.26. Области потерь Источник: Товб А., Ципес Г. Указ. соч.

Так, если известно, что заказчик ориентирован на соблюдение запланированного уровня качества продукта, то должны быть предусмотрены варианты изменений, связанных с манипулированием ресурсами и сроками (стратегия «Упрямый заказчик»). В других случаях могут потребоваться иные стратегии, например, «Жесткие сроки» или «Ограниченный бюджет», когда в области запланированных потерь должны быть зафиксированы, соответственно, изменения по срокам и ресурсам. На диаграмме могут быть показаны и желаемая, и возможные альтернативные стратегии изменений (рис. 4.27).

Рис. 4.27.

Источник : Товб А., Ципес Г. Указ. соч.

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

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

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

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

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

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

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

Таблица 4.21

Разделение ответственности при административном управлении

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

Сфера ответ-отвенности Область управления	Ответственность начальника подразделения (административное управление)	Ответственность руководителя проекта (управление проектами)
Планирование и контроль	Формирование бизнес-плана. Планирование бюджета отдела. Контроль «по вехам». Отчетность перед руководством предприятия	Детальный календарный план проекта. Планирование бюджета проекта. Оперативный контроль хода проекта. Отчетность перед руководством
Человеческие	Прием на работу и увольнение. Централизованное выделение ресурсов. Контроль ДИСЦИПЛИНЫ. Организация обучения	Формирование команды проекта. Анализ и оценка работы сотрудников. Применение санкций и поощрений. Регулирование конфликтов
Реализуемые продукты (на примере информационных систем ИС)	Методология создания ИС.	Проектирование ИС. Разработка ИС. Внедрение ИС

Источник : Товб А., Ципес Г. Указ. соч.

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

Включение специалистов в команду проекта О Взаимодействие команды проекта со смежными службами

Рис. 4.28. Схема формирования команды проекта Источник : Товб А., Ципес Г. Указ. соч.

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

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

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

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

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

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

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

Управление коммуникациями Управление рисками Управление содержанием и границами Проектное планирование Управление качеством Финансовое и контрактное управление Управление ресурсами Управление изменениями ИНТЕГРАЛЬНАЯ ОЦЕНКА ПО ПРОЕКТУ 7

Рис. 4.29. Диаграмма текущего статуса управления проектом Источник : Товб А., Ципес Г. Указ. соч.

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

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

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

Служба управления качеством в части управления проектами обеспечивает:

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

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

Рис. 4.30.

исполнения проектов

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

В 1986 году институтом Software Engineering Institute (SEI) начинается разработка системы оценки возможностей компаний по разработке программного обеспечения «Capability Maturity Model» (CMM) на основе техник описанных Филиппом Б. Гросби, специалистом и известным лектором в области управления качеством, в его книге «Quality is Free» . Разработка была инициирована запросом от ВВС США, обусловленным острой необходимостью иметь возможность оценивать профессиональность подрядных организаций.

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

1. Начальный – процесс разработки не находится под статистическим контролем, прогресс в совершенствовании процессов отсутствует.
2. Повторяемый – устойчивый процесс с возобновляемым уровнем статистического контроля достигаемого путем применения скрупулезного управления проектами в области трудозатрат, издержек, сроков и изменений.
3. Установившийся – наблюдается налаженный процесс разработки, внутренние стандарты качества, менеджмент понимает недостатки применяемых практик. Возможно успешное внедрение передовых технологий.
4. Управляемый – после определенного этапа, можно инициировать процесс анализа. Менеджмент в состояние управлять качеством при помощи выработанных техник.
5. Оптимизированный – организация находится в постоянном процессе совершенствования.

Как система оценки CMM представляла собой опросник из 85 процессных и 16 технологических вопросов, сам стандарт стал доступен общественности в 1988 году, полное описание CMM как совокупности процессов и практик, соответствующих каждому уровню было выпущено в 1991 году, в 1995 он был выпущен в книжном варианте . Позднее CMM был доработан до набора методологий совершенствования процессов в организациях: «Capability Maturity Model Integration» (CMMI), последняя (по состоянию на конец 2014 года) версия CMMI-DEV, V1.3. вышла в 2010 году, далее перечислены процессные области которым уделяется внимание в данном стандарте :

• Анализ причин и разрешение (CAR)
• Конфигурационный менеджмент (CM)
• Анализ решений и разрешение (DAR)
• Менеджмент интеграции проектов (IPM)
• Измерение и анализ (MA)
• Описание процессов организации (OPD)
• Фокусирование на процессах организации (OPF)
• Управление эффективностью деятельности (OPM)
• Производительный организационный процесс (OPP)
• Организационный тренинг (OT)
• Интеграция продукта (PI)
• Мониторинг и контроль проекта (PMC)
• Планирование проекта (PP)
• Обеспечение качества продуктов и процессов (PPQA)
• Количественный менеджмент проекта (QPM)
• Разработка требований (RD)
• Менеджмент требований (REQM)
• Менеджмент рисков (RSKM)
• Менеджмент договоров с поставщиками (SAM)
• Разработка технического решения (TS)
• Валидация (VAL)
• Верификация (VER)

В 1989 году «Центральное компьютерное и коммуникационное агентство» Великобритании (CCTA), позднее переименованное в «Управление государственной торговли» (OGC), создает структурированную систему управления проектами PRINCE (PRojects IN Controlled Environments) на основе метода управления проектами PROMPT разработанного «Simpact Systems Ltd» в 1975 году и одобренным CCTA, как стандарт для всех государственных проектов информационных систем в Великобритании. После своего появления PRINCE эффективно заменил PROMPT. Позднее, в 1996 году, была опубликована обновленная версия методологии PRINCE2, чему поспособствовал консорциум состоящий в общей сложности из порядка 150 Европейских организаций .

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

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

• Продолжительное бизнес-обоснование
• Учиться на опыте
• Распределение ролей и обязанностей
• Поэтапное управление
• Управление по отклонениям
• Фокусировка на продукте
• Адаптация к особенностям проекта

Темы PRINCE2 представляют те аспекты управления проектами которые должны решаться на протяжении всего жизненного цикла проекта, они определяют как должны обрабатываться процессы:

• Экономическое обоснование
• Организация
• Качество
• Планы
• Риски
• Изменения
• Прогресс

Модель процессов состоит из комплекса мероприятий, которых стоит придерживаться для направления, управления и завершения проекта:

• Запуск проекта
• Управление проектом
• Инициация проекта
• Управление границами стадий
• Контроль стадий
• Управление поставкой продукта
• Закрытие проекта

В феврале 1999 году, международная ассоциация управления проектами «International Project Management Association» (IPMA), основанная в 1965 году, как некоммерческая профессиональная ассоциация, призванная объединить специалистов в области управления проектами, публикует стандарт управления проектами «IPMA Competence Baseline» (ICB) . В данном стандарте содержатся требования к компетенциям, предъявляемые менеджерам проектов и членам команд по управлению проектами, программами и портфелями .

В России IPMA появилась в 1990 году как СОВНЕТ. На данный момент ассоциация занимается обучением профессиональному управлению проектами, аккредитацией учебных программ по управлению проектами и международной сертификацией специалистов на основе собственной четырехступенчатой системы :

А – сертифицированный директор проектов;
B – сертифицированный старший менеджер проектов;
C – сертифицированный менеджер проектов;
D – сертифицированный специалист по управлению проектами.

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

НТК рассматривает системную модель управления проектами состоящей из трех основных компонентов:

1. Объекты управления – проекты, программы и портфели;
2. Субъекты управления – инвестор, заказчик, команда, руководитель и прочие заинтересованные лица.
3. Процессы управления – рассматриваются как совокупность задач и процедур управления и представлены в разрезах: стадий процесса управления, функциональной области управления, временному интервалу, объекту и субъекту управления. В НТК различаются следующие стадии процесса управления:

• инициация (запуск) проекта,
• планирование работ проекта,
• организация и контроль выполнения работ проекта,
• анализ и регулирование хода работ проекта,
• закрытие проекта.

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

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

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

В 1996 году институтом управления проектами США (Project Management Institute, Inc., сокращенно PMI), публикуется руководство «A Guide to the Project Management Body of Knowledge» (PMBOK Guide) , в которой описывается стандарт управления проектами PMBOK. Данный стандарт совместим с международным стандартом управления проектами ISO 9000. PMBOK объединяет в себе обширный набор знаний и практик в области управления проектами, а также целыми программами и портфелями проектов. В нем уделяется внимание жизненному циклу проекта, влиянию организации, в том числе ее внутренней культуры, на управление проектом.

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

• Группа процессов управления проектами
• Группа процессов инициации (2 процесса)
• Группа процессов планирования (20 процессов)
• Группа процессов исполнения (8 процессов)
• Группа процессов мониторинга и управления (10 процессов)
• Группа процессов завершения (2 процесса)

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

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

Взаимодействие процессов управления показано в приложение А, стоит отметить что согласно исследованию проведенному доктором философии С. Гашиком процессы PMBOK на 95 процентов аналогичны описанным в международном стандарте по управлению проектами ISO 21500 .
В ноябре 2001 года Центр сертификации специалистов в области управления проектами (Project Management Professionals Certification Center, сокращенно PMCC) Японии, позднее переименованный в Ассоциацию управления проектами Японии (Project Management Association of Japan, сокращенно PMAJ) публикует стандарт управления проектами P2M. В контексте методологии рассматриваются управленцы призванные для достижения миссии проекта, которые должны обладать знаниями из смежных областей и делятся на три уровня профессионализма:

• менеджер-специалист (PMS),
• менеджер-зарегистрированный (PMR) и
• менеджер-архитектор (PMA).

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

• Стратегическое управление проектом
• Управление финансами проекта
• Управление системами проектами
• Организационный менеджмент проекта
• Управление целями проекта
• Управление ресурсами проекта
• Управление рисками
• Информационный менеджмент
• Управление взаимосвязями проекта
• Управление стоимостью проекта
• Управление коммуникациями в проекте

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

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

• CMMI – Software Engineering Institute (США)
• PRINCE – Central Computer and Telecommunications Agency (Великобритания)
• ICB – International Project Management Association (Швейцария)
• НТК – СОВНЕТ (национальное представительство IPMA в России)
• PMBOK – Project Management Institute (США)
• ISO 21500 – International Organization for Standardization
• P2M – Project Management Association of Japan (Япония)

Список литературы

1. Crosby P.B., Quality is Free. New York: New American Library, 1979 – ISBN 0-451-62247-2
2. Humphrey W.S., Characterizing the Software Process. A maturity Framework [Электронный ресурс] / Software Engineering Institute, 1987 – Режим доступа: www.sei.cmu.edu/reports/87tr011.pdf
3. Paulk M.C., The Capability Maturity Model: Guidelines for Improving the Software Process. Mass.: Addison-Wesley Pub. Co., 1995 – ISBN 0-201-54664-7
4. CMMI® for Development, Version 1.3 [Электронный ресурс] / Software Engineering Institute, 2010 – Режим доступа: www.sei.cmu.edu/reports/10tr033.pdf (дата обращения: 03.11.2014).
5. What is PRINCE2? [Электронный ресурс] / Office of Government Commerce, UK – Режим доступа: www.prince2.com/what-is-prince2 (дата обращения: 03.11.2014).
6. Межгосударственный стандарт ГОСТ Р ИСО 21500. Руководство по управлению проектами, 2012
7. PRINCE2® in one thousand words [Электронный ресурс] / Andy Murray and Director of Outperform UK Ltd, 2009 – Режим доступа: www.best-management-practice.com/gempdf/PRINCE2_in_One_Thousand_Words.pdf (дата обращения: 03.11.2014).
8. ICB - IPMA Competence Baseline, Version 3.0 [Электронный ресурс] / International Project Management Association, 2006 – Режим доступа: (дата обращения: 03.11.2014).
9. Сооляттэ А.Ю., Управление проектами в компании: методология, технологии, практика. М.: МФПУ «Синергия», 2012
10. Certify Individuals [Электронный ресурс] / International Project Management Association – Режим доступа: ipma.ch/certification/certify-individuals (дата обращения: 03.11.2014).
11. Управление проектами. Основы профессиональных знаний, Национальные требования к компетентности специалистов / под научной ред. д.т.н. Воропаева В.И., М.: ЗАО «Проектная ПРАКТИКА», 2010
12. A Guide to the project management body of knowledge / PMI Standards Committee. USA: Project Management Institute, 1996
13. Руководство к своду знаний по управлению проектами (Руководство PMBOK®) - четвертое издание / PMI Standards Committee. USA: Project Management Institute, 2008 – ISBN: 978-1-933890-51-7
14. Gasik S., PhD, Comparison of ISO 21500 and PMBOK®. Guide Version improved after comments of Jesus Guardiola and Francesca Montanari [Интернет источник] – Режим доступа: www.sybena.pl/dokumenty/ISO-21500-and-PMBoK-Guide.pdf (дата обращения: 03.11.2014).
15. A Guidebook of Project & Program Management for Enterprise Innovation [Интернет источник] / Project Management Association of Japan, Revision 3, 2005 – Режим доступа: Добавить метки

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

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

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

1. Project Management Body of Knowledge (PMВОК) Американского института управления проектами (Project Management Institute – PMI). Этот стандарт обновляется приблизительно один раз в четыре года. Одна из наиболее распространенных редакций датируется 2000 г., а самая актуальная, четвертая, версия стандарта – The Guide to the PMBOK, 4th Edition – вышла в конце 2008 г. Стандарт был первоначально принят Американским национальным институтом стандартов (ANSI) в качестве национального стандарта в США, а в настоящее время обрел мировое признание.

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

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

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

• – управление интеграцией проекта (Project Integration Management);
• – управление содержанием проекта (Project Scope Management);
• – управление сроками проекта (Project time Management);
• – управление стоимостью проекта (Project Cost Management);
• – управление качеством проекта (Project Quality Management);
• – управление человеческими ресурсами проекта (Project Human Resource Management);
• – управление взаимодействием в проекте (Project Communications Management);
• – управление рисками проекта (Project Risk Management);
• – управление контрактами проекта (Project Procurement Management).

Рис. 1.2.

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

2. IPMA Competence Baseline (ICB) является международным нормативным документом, определяющим систему международных требований к компетентности менеджеров проектов. Этот стандарт разработан международной ассоциацией IРМЛ (International Project Managers Association). На его основе производится разработка национальных систем требований к компетентности специалистов в странах, являющихся членами IPMA. Национальные системы требований должны соответствовать ICB IPMA и официально утверждаться (ратифицироваться) соответствующими уполномоченными органами IPMA. Для 32 стран – членов IPMA он является основой для разработки национальных сводов знаний; в настоящее время утвержденные национальные своды знаний, соответствующие ICB, имеют 16 стран.

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

ICB издан на английском, немецком и французском языках. Основой для него послужило несколько национальных разработок: Body of" Knowledge of АРМ (Великобритания); Beurteilungsstruktur, VZPM (Швейцария); PM-Kanon, PM-ZERT/GPM (Германия); Criteres d"analyse, AFITEP (Франция).

Каждая входящая в IPMA национальная ассоциация ответственна за разработку и утверждение собственных Национальных требований по компетентности (National Competence Baseline – NCB) со ссылкой на ICB и в соответствии с ним, а также с учетом национальных особенностей и культуры. Национальные требования оцениваются специальным Комитетом IPMA на соответствие ICB и основным критериям сертификации согласно стандарту EN 45013.

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

Стандарт ISO 10006 является основополагающим документом из серии стандартов рассматриваемого профиля, подготовленным техническим комитетом ISO/TC 176 "Управление качеством и обеспечение качества" Всемирной федерации национальных органов стандартизации (члены ISO).

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

В этой серии стандартов процессы сгруппированы в две категории. К первой категории отнесены процессы, связанные с обеспечением продукта проекта (проектирование, производство, проверка). Описанию последних посвящен стандарт ISO 9004–1. Вторая категория охватывает непосредственно процессы управления проектом и представлена стандартом ISO 10006.

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

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

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

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

На основе международных стандартов разрабатываются и национальные стандарты управления проектами. Отметим, что в России национальный стандарт отсутствует. Однако Ассоциация по управлению проектами России (SOVNET) разработала в 2001 г. на основе стандарта IPMA "Основы профессиональных знаний. Национальные требования к компетентности специалистов". Перевод стандарта ИСО 10006:2003 зарегистрирован, стандарт PMI распространяется в России частным порядком и часто используется как основа для корпоративных стандартов.

Наконец, нужно осветить и стандарты зрелости управления проектами, тоже приобретающие функции международных. В 2004 г. PMI был выпущен стандарт оценки уровня зрелости организации по управлению проектами ОРМЗ (Organization Project Management Maturity Model ), содержащий методологию определения состояния управления проектами в организации.

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

Общая характеристика уровней зрелости организации по отношению к управлению проектами приведена в табл. 1.3.

Таблица 1.3

Общая характеристика уровней зрелости организации

Уровень зрелости (оценка, балл)	Характеристика уровня
Уровень 1	Начальный, нулевой уровень. Работники действуют, исходя из своих личных представлений о целях работы. Отсутствуют внутренние регулирующие документы. Действия не документируются, бизнес-знания не отделены от работников (знания пропадают при увольнении работников). Бизнес-процессы в организации не описаны и, соответственно, не классифицированы. Деятельность комании непрозрачна даже для основного персонала
Уровень 2	Уровень осознания. Руководство компании решило превзойти начальный уровень. Появляются внутренние стандарты, описывающие основные бизнес-процессы компании. Возникает повторяемость – выполнение новых проектов основывается на опыте выполнения предыдущих проектов
Уровень 3	Уровень управляемости. В организации задокументированы и стандартизированы все бизнес-процессы. Система управления оказывается отделенной от всего персонала организации, т.е. появляется внутренний "свод законов". Этим законам следует весь персонал организации, включая топ-менеджмент
Уровень 4	Уровень измеряемости. В компании вводится количественная система оценки эффективности бизнес-процессов (используются как финансовые, так и натуральные показатели). Одновременно используется та или иная система оценки работы персонала, например, система ключевых показателей. Обе системы, описание бизнес-процессов и оценки персонала синхронизированы между собой – эффективная деятельность компании приводит к стимулированию персонала
Уровень 5	Уровень совершенствования. На основе анализа количественных показателей в компании проводится корректировка (реинжиниринг) бизнес-процессов. Коррекции отражаются во внутренних документах. Важно то, что процесс коррекции носит постоянный, системный характер

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

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

Основное назначение ОРМЗ – быть стандартом для корпоративного управления проектами и организационной зрелости по управлению проектами.

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

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

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

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

Управление проектами является частью системы менеджмента предприятия.

История

В основе современных методов управления проектами лежат методики структуризации работ и сетевого планирования, разработанные в конце 50-х годов XX века в США.

Классическая форма Тройственной Ограниченности

• Предположение о неограниченности ресурсов, критичен только срок выполнения и качество. Метод PERT , Метод критического пути ,
• Предположение о критичности качества, при этом требования к сроку и ресурсам достаточно гибки (под качеством здесь понимается полнота удовлетворения потребностей, как известных, так и неизвестных заранее, часто создаваемых выходом нового продукта). Гибкая методология разработки
• Предположение о неизменности требований, низких рисках, жесткий срок. Классические методы PMBOK , во многом опирающийся на модель водопада
• Предположение о высоких рисках проекта. Метод Инновационные проекты (стартапы)
• Варианты нейтральных (сбалансированных) подходов:
  • Акцент на взаимодействие исполнителей. Метод PRINCE2
  • Акцент на взаимодействие процессов . Метод Process-based management

Роли в проекте

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

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

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

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

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

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

Цель управления проектом и успешность проекта

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

Группы оценок успешности:

• Ориентированные на контракт, например традиционные методологии, в том числе PMBOK : «Проект успешен, если выполнен согласно утвержденным критериям: объему, сроку, качеству» . То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем (вне зависимости от того, являлся ли он юридическим документом в случае внешних проектов или определялся как-то иначе в случае внутренних проектов). При этом оценка успешности единая как для заказчика так и для исполнителя.
• Ориентированные на заказчика, например гибкие методологии SCRUM , частично управление программами , направленное на длительное взаимодействие, а не на один проект/контракт: «Проект успешен, если заказчик удовлетворен» . Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия, либо проект можно рассматривать как программу из нескольких небольших проектов. Оценка успешности рассматривается в основном с точки зрения заказчика.
• Сбалансированные, например PRINCE2 : «Проект успешен при сбалансированности по крайней мере по трем категориям - бизнеса, ориентации на пользователя и технологической зрелости» . Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии (косвенная польза для самого исполнителя). Оценка успешности может различаться с точки зрения бизнеса, пользователя и исполнителя. Такие методики оценки чаще используются для внутренних проектов, когда заказчик и исполнитель находятся в одной организации.

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

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

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

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

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

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

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

Международный стандарт управления проектами ISO 21500:2012

В сентябре 2012 года Россия, США и страны Евросоюза на государственном уровне через International Standard Organization ISO ввели в действие стандарт ISO 21500 , который был построен на базе модели PMBOK . Принятие стандарта ISO 21500 в действие сопровождалось фактически передачей приоритета стандартизации от PMI к ISO.

В соответствии с гражданским законодательством большинства стран Евросоюза, а также России, все остальные стандарты на территории Европы являются подчиненными относительно ISO 21500:2012 и в случае любых разночтений с официальным стандартом, подчиненные стандарты в указанных различиях являются "ничтожными". В России указанное правило закреплено в Статье 7 Гражданского Кодекса Российской Федерации.

• Определение требований к проекту
• Постановка чётких и достижимых целей
• Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости
• Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)

IPMA

• Системное представление Управления проектами IPMA

Процедуры управления проектом по методологии PRINCE2

• Начало проекта (SU).
• Запуск проекта (IP).
• Планирование проекта (PL).
• Управление проектом (DP).
• Контроль стадий (CS).
• Контроль границ стадий (SB).
• Управление производством продукта (MP).
• Завершение проекта (CP).

Прочие процедуры (управление командой, контрактами и тп) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Case), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.

Процедуры управления проектами по методологии MSF

Microsoft Solutions Framework (MSF) разработан корпорацией Microsoft как методология ведения IT-проектов. MSF представляет каждую фазу проекта как:

• Выработка концепции (Envisioning)
• Планирование (Planning)
• Разработка (Developing)
• Стабилизация (Stabilizing)
• Внедрение (Deploying)

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

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

В Плане управления проектом должно быть отражено:

• Содержание и границы проекта
• Ключевые вехи проекта
• Плановый бюджет проекта
• Предположения и ограничения
• Требования и стандарты

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

Международные стандарты управления (менеджмента) проектами:

Национальные стандарты управления проектами:

• ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» (Россия)
• ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (Россия)
• ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой» (Россия)
• NASA Project Management (США)
• BSI BS 6079 (Великобритания)
• APM Body of Knowledge (Великобритания)
• DIN 69901 (Германия)
• Hermes method (Швейцария)
• CAN/CSA-ISO 10006-98 (Канада)
• South African NQF4 (ЮАР)
• CEPM (Индия)
• PROMAT (Южная Корея)

Стандарты с расширенной географией применения:

• PRINCE2 (PRojects IN a Controlled Environment)
• ISEB Project Management Syllabus
• Oracle Application Implementation Method (AIM)

Стандарты оценки компетенции менеджера проекта:

• ICB IPMA Competence Baseline (IPMA)
• НТК (Национальные требования к компетентности специалистов) (Ассоциация управления проектами «СОВНЕТ», Россия)
• NCB UA (National Competence Baseline, Version 3.0) (Украина)

Программное обеспечение для управления проектами

• продукты, ориентированные на автоматизацию услуг:
  • ARTA Software - система ARTA Synergy
  • Epicor Software
• системы управления проектами и задачами:
  • Bontq - система управление проектами и отслеживания ошибок.
  • Cerebro - система управления проектами в аудиовизуальной сфере.
  • Easy Projects .NET - система для управления проектами, написанная на .NET .
  • eGroupWare - бесплатное ПО для управления проектами.
  • GanttProject - маленькая бесплатная программка с диаграммой Ганта и ресурсами. [значимость факта? ]
  • Kommandcore - платный многопользовательский веб-сервис по управлению проектами, предназначен в первую очередь для руководителей проектами, основан на методологии гибкой разработки.
  • OpenProj - бесплатная, открытая альтернатива Microsoft Project.
  • Clarizen - облачная система управления проектами, персоналом, бюджетом
  • PayDox - система управления документами, задачами и совместной работой сотрудников.
  • Project Kaiser - веб-ориентированная система управления проектами и задачами с поддержкой wiki и развитыми средствами взаимодействия пользователей.
  • ProjectMate - Российская PSA-система автоматизации профессиональной деятельности. Помимо модуля управления проектами имеет массу функций, востребованных в компаниях сферы консультационных услуг - начиная от учета времени и заканчивая выставлением счетов (биллингом).
  • Redmine - бесплатный многопользовательский веб-сервис, ориентированный на специфику IT-проектов и разработчиков.
  • TeamLab - система для управления проектами, документами и совместной работы.
  • TrackStudio Enterprise - система управления задачами. Есть экспорт в MS Project.
  • Trac - инструмент управления проектами и отслеживания ошибок в программном обеспечении.
  • Web2Project - открытое бесплатное веб-приложение для управления проектами (проект основан на коде dotProject).

Методологии управления проектами

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

Методология IW URM (Unique Reliable Method), разрабатывалась и оттачивалась с тем, чтобы в любом проекте был гарантирован успех - цели клиента достигнуты в оговоренный срок, в рамках определенного бюджета и с необходимым качеством. Для реализации разных типов проектов используется набор различных процедур, документов и технологий, наиболее подходящих для конкретного типа проекта.

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

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

Литература

• Стэнли Э. Портни. Управление проектами для "чайников" = Project Management For Dummies. - М .: «Диалектика», 2006. - С. 368. - ISBN 0-7645-5283-X
• Рассел Д. Арчибальд. Управление высокотехнологичными программами и проектами = Managing High Technology Programs and Projects. - М .: «Академия АйТи», 2004. - С. 472. - ISBN 5-98463-002-3
• Ньюэлл Майкл В. Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена. - «КУДИЦ-ПРЕСС» , 2008. - С. 416. - ISBN 978-5-91136-009-2
• Том ДеМарко. Deadline. Роман об управлении проектами. - «ВЕРШИНА» «М» , 2006. - С. 143. - ISBN 5-9626-0132-7
• Ашманов Игорь Станиславович Жизнь внутри пузыря . - М .: Манн, Иванов и Фербер, 2008. - С. 208. - ISBN 978-5-902862-79-6
• Ким Хелдман. Профессиональное управление проектами. - «Бином» «Москва» , 2005. - С. 517. - ISBN 5-94774-234-9
• Лапыгин Ю. Н. Управление проектами: от планирования до оценки эффективности. - Омега-Л «Москва» , 2008. - С. 252. - ISBN 978-5-370-00985-3

Заренков В. А. Управление проектами. СПб., 2010.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Государственное бюджетное образовательное учреждение высшего профессионального образования

"Челябинский государственный университет"

К урсовая работа

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

• Введение
• 1. Общие соображения по созданию стандарта. Специализация и детализация
• 2. Классификация проектов как первый этап создания стандарта
• 2.1 Что должно быть отражено в плане управления проектом
• 2.2 План управления проектом и рамочные стандарты
• 3. Проектные отклонения. Риски, проблемы, изменения
• 3.1 Управление рисками
• 3.2 Управление проблемами
• 3.3 Управление изменениями
• 4. Организационные структуры в проектах
• 5. Тактика и стратегия внедрения стандарта управления проектами
• 6. Дополнительные преимущества от внедрения стандарта
• Заключение
• Список используемой литературы

Введение

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

Сошлемся также на результаты всероссийских конференций "Стандарты в проектах современных информационных систем", где тема стандартов управления проектами была представлена достаточно широко и вызвала живой интерес и дискуссии, как в зале заседаний, так и в кулуарах. В решениях конференций было "признание роли стандартов в организации выполнения отдельных проектов и в постановке проектного дела в целом на предприятиях". И, наконец, упомянем, тот факт, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как Oracle, IBM, PricewaterhouseCoopers, Andersen Consulting, SAP AG, Siemens и др. Все эти соображения и позволяют нам предположить, что тема стандарта управления проектами должна вызвать интерес.

1. Общие соображения по созданию стандарта. Специализация и детализация

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Структура стандарта управления проектами

2. Классификация проектов как первый этап создания стандарта

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

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

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

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

2.1 Что должно быть отражено в плане управления проектом

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

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

Плановый бюджет проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 План управления проектом и рамочные стандарты

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

Проиллюстрируем это на примере не самого сложного раздела плана "Организационная структура проекта". В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации не достаточно!

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

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

3. Проектные отклонения. Риски, проблемы, изменения

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

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

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

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

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

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

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

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

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

3.1 Управление рисками

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

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

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

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

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

3.2 Управление проблемами

Прежде всего, поясним, что мы называем проблемами и почему проблемами можно (и нужно) управлять. В ходе реальной работы по созданию и внедрению стандарта управления проектами на предприятии авторам пришлось столкнуться с тем, что словосочетание "управление проблемами" вызывает недоумение у коллег, не имевших опыта знакомства с англоязычными стандартами управления проектами. Многим кажутся более привычными укоренившиеся в русскоязычной литературе термины "решение" или "разрешение проблем", которые соответствуют определениям "problem solving" или "problem resolution", принятым в упоминавшихся выше так называемых "рамочных" стандартах.

Авторы в этом вопросе предпочитают следовать духу и букве таких стандартов управления проектами как MITP/PMM/WISDDM корпорации IBM, в которых этот процесс называется "problems/issues management", что в русском переводе лучше всего, на наш взгляд, выглядит именно как "управление проблемами".

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

Обычно проблемы делят на две категории - на проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом - problems, и эскалируемые проблемы - issues, которые для их разрешения требуется поднять на верхние уровни управления, в том числе, внешние по отношению к проекту.

В стандарте должна быть отражена формальная сторона управления проблемами:

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

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

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

3.3 Управление изменениями

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

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

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

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

Плановые потери (учтены в плане управления проектом).

Допустимые потери (незначительные незапланированные затраты).

Нежелательные потери (значительные незапланированные затраты).

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

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

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

Часто стратегия изменений определяется тем, что, по крайней мере, по одной из осей изменения не должны приводить к выходу из области плановых потерь. А это означает необходимость смещения в одном или сразу в двух других измерениях. Так если известно, что заказчик ориентирован, прежде всего, на соблюдение запланированного уровня качества продукта, то должны быть предусмотрены варианты изменений, связанных с манипулированием ресурсами и/или сроками (стратегия "Упрямый заказчик"). менеджер проектный управление бизнес

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

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

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

Рис. 5. Области потерь

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

4. Организационные структуры в проектах

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

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

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

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

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

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

· проектная структура. Данный подход предполагает, что комплекс работ проекта разрабатывается независимо от иерархической структуры организации;

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

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

5. Тактика и стратегия внедрения стандарта управления проектами

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

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

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

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

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

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

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

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

Рис. 11. Стандарт управления проектами в системе управления предприятием

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

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

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

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

6. Дополнительные преимущества от внедрения стандарта

Стандарт управления проектами и человеческие ресурсы.

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

Стандарт не заменит этой литературы, но роль его в целенаправленном обучении персонала компании может быть весьма значительной. Здесь, на наш взгляд, будет уместной следующая параллель. В части процессов управления проектами стандарт предприятия специализирует и детализирует требования рамочных стандартов (таких как ISO 10006 или PMBOK PMI). Точно также в части квалификации управленческого персонала стандарт предприятия специализирует и детализирует требования нормативных документов рамочного характера в этой области (таких как ICB или НТК).

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

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

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

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

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

В качестве другого примера приведем пятиуровневую модель (PM) - Project Management Process Maturity Model .

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

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

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

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

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

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

Заключение

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

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

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

Очень часто для того, чтобы получить выгодный контракт, компания должна показать, что знает, как управлять проектами и умеет это делать. Собственно, практически в любом крупном тендере на разработку информационных систем обязательно содержатся требования в части управления проектами. Иногда эти требования носят конкретный характер, например, "Как будет организована проектная группа с учетом участия в проекте многочисленных сторон? Каким образом будут поддерживаться отношения с различными партнерами?". Чаще они формулируются в самом общем виде: "Предоставьте информацию по процессам управления Вашей компании, позволяющим отслеживать и контролировать все аспекты, относящиеся к проекту, включая …".

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

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

Список используемой литературы

1. Михеев В.Н., Товб А.С. "Международные и национальные стандарты по управлению проектами, менеджменту проектов и профессиональной компетентности менеджеров проектов." М., 2002. - с.33-37.

2. Товб А.С. Ципес Г.Л. "Стандарты в проектах современных информационных систем", М., 2002. - с.42-47.

3. Товб А.С. Ципес Г.Л. Стандарт управления проектами уровня предприятия. "Директор информационной службы" № 1-6, 2001 и №№ 1-6, 2002.

4. Баженов Р.А. "Стандарты и правила проектного мышления" (интернет-ресурс)

5. Управление проектами. Справочник для профессионалов. Под ред. И.И. Мазура и В.Д. Шапиро, 2001.

6. "Директор информационной службы" №5, 2001.

Размещено на Allbest.ru

...

Подобные документы

Специализация и детализация при создании проектов. План управления проектом и рамочные стандарты. Проектные отклонения: управление рисками, проблемами и изменениями. Организационные структуры в проектах. Тактика и стратегия внедрения стандарта управления.

курсовая работа , добавлен 12.01.2015


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

реферат , добавлен 19.05.2014


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

практическая работа , добавлен 07.04.2015


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

контрольная работа , добавлен 13.06.2013


Понятие и функции управления качеством. Международные стандарты семейства ISO 9000:2000. Разработка и процессы системы менеджмента качества, проверка ее работоспособности. Экономика и правовое обеспечение качества. Некоторые методы обеспечения качества.

учебное пособие , добавлен 28.11.2009


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

дипломная работа , добавлен 20.08.2017


Система управления рисками как неотъемлемый компонент корпоративного управления предприятием. Международные стандарты управления рисками предприятия и концепция стандарта COSO ERM. Анализ состояния систем управления рисками в казахстанских компаниях.

реферат , добавлен 21.12.2011


Понятие качества продукции в Российской Федерации. Стандарты серии ISO 9000. Методика разработки и построения системы управления качеством. Требования к терминологии, символике, упаковке, маркировке или этикеткам. Российские версии стандартов ISO.

презентация , добавлен 08.12.2013


Виды и структура инвестиционных проектов компании. Теоретические основы управления проектами. Анализ и исследование компании ООО «ВИСТрейд». Определение инвестиционных возможностей данной компании. Этапы управления проектом на прединвестиционной фазе.

дипломная работа , добавлен 26.06.2009


Понятие, состав и виды проектов. Этапы управления проектами на предприятии. Организационно-экономическая характеристика ТОО "Казцинктех". Анализ экономических показателей работы предприятия. Основные проблемы в управления проектами и пути их решения.