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

Содержание:

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- по предметным областям позволит специализировать разделы Содержание и границы, Ключевые вехи, Требования и стандарты

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

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

Рассмотренные выше примеры классификаций проектов подобраны для иллюстрации возможности сборки шаблона из относительно независимых стандартных фрагментов. Однако в реальной жизни встречаются и другие ситуации. Например, классификация комплексности проектов по сложности. В связи с этим проекты делятся на обычный бизнес (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) и того, что получается в действительности, и называются обычно отклонениями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве другого примера приведем пятиуровневую модель (ПМ) - модель зрелости процесса управления проектами.

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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