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

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

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

И, наконец, упомянем, тот факт, что практика создания собственных методик и руководств по управлению проектами широко распространена в крупнейших западных компаниях, таких как 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. Классификация проектов как первый этап создания стандарта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При построении специализированного микрошаблона "Содержание и границы проекта" мы использовали рекомендации PMBoK PMI (Табл. 1).

В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ.

Описание количественных критериев, которые должны быть удовлетворены, чтобы проект считался успешным

Срок доставки оборудования и программного обеспечения в Москву не должен превышать ХХ дней.

Срок наладки оборудования и программного обеспечения в Москве не должен превышать YY дней.

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

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

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

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

Провести декомпозицию и составить структуру декомпозиции работ (WBS – Work Breakdown Structure) по утверждению некоторых авторов очень легко: "Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации" (Цитируем по статье М. Ньюэлла "Структура декомпозиции работ" в мартовском номере журнала "Директор информационной службы" за 2001 г.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4. Общая схема управления отклонениями

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

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

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

И все это в результате привело к необходимости внесения изменений в план проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начальник отдела и руководитель проекта

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

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

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

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

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

Табл. 3. Разделение ответственности при административном управлении и управлении проектами

Исполнитель

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

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

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

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

Команда проекта

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

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

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

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

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

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

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

Рис. 7. Схема формирования команды проекта

6. Обеспечение качества и служба управления проектами

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

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

Планирование и контроль качества в проекте

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

Планирование качества осуществляется как часть процесса планирования проекта в целом. Результаты планирования качества проекта (план по качеству проекта) должны отражаться в Плане управления проектом.

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

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

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

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

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

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

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

Рис. 8. Диаграмма текущего статуса управления проектом

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

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

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

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

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

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

Рис. 9. Структура и функции служб, отвечающих за качество исполнения проектов

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

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

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

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

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

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

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

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

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

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

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

Основные этапы создания стандарта управления проектами

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

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

Рис. 10 . Этапы создания стандарта управления проектами

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

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

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

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

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

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

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

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

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

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

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

Информационные технологии в управлении проектами

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

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

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

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

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

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

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

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

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

Автоматизация управления проектами не является темой этого доклада. Поэтому здесь мы ограничимся констатацией того, что средства автоматизации управления проектами необходимо связывать с другими информационными системами предприятия (например, с системой управления персоналом, с ERP-системой и т.д.). А это, в свою очередь, приведет к необходимости установления интерфейсов между базовыми пакетами прикладных программ, использованных для создания связываемых элементов интегрированной системы предприятия. . В последнее время модули управления проектами всё чаще становятся частью таких прикладных систем как ERP , например модуль Project System в SAP R /3 и CRM , например, модуль Eventix Engagement в SalesLogix .

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

8. Глоссарий управления проектами

Начнем этот раздел с рассказа об одном забавном эпизоде. Однажды, в нашей компании проходили практику студенты-дипломники, специализирующиеся по управлению проектами. Выдавая им задание, руководитель практики (один из авторов этого доклада) попросил описать scope проекта (он так и сказал – скоуп). ”А что такое scope?” – осторожно уточнила одна девушка. ”О, scope – это…” – ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. “Понятно, - грустно сказала девушка. – Нам в институте также объясняли”.

Ситуация очень характерная и довольно опасная. Есть некий термин, употребляемый в англоязычных источниках и не имеющий очевидного и однозначного перевода на русский язык в контексте управления проектами. На профессиональном жаргоне мы привыкли пользоваться этим термином на языке оригинала. Действительно, гораздо удобнее сказать scope , чем какое-нибудь достаточно громоздкое “содержание и границы”. Если кому-то непонятно, то всегда можно объяснить, хотя бы с помощью жестов. А приводит все это к тому, что некоторое время спустя точного значения термина никто уже не помнит, каждый трактует его по-своему, и при этом все думают, что понимают друг друга!

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

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

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

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

Краткий глоссарий

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

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

Проект – целенаправленная деятельность временного характера, предназначенная для создания уникального продукта или услуги [НТК].

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

Управление проектом включает планирование, организацию, мониторинг и контроль всех аспектов проекта в ходе непрерывного процесса достижения его целей [ ISO].

Управление проектом – процесс применения знаний, навыков, методов и средств и технологий к проектной деятельности с целью достижения или превышения ожиданий участников проекта [ PMBOK].

План управления проектом (Project Management Plan) - основополагающий документ (baseline document), с которого должен начинаться любой проект. Содержит согласованное всеми участниками документально зафиксированное представление о проекте. В инвестиционных проектах – Мастер-план проекта (Project Master Plan) (УП).

Устав Проекта ( Project Charter) - документ, разработанный вышестоящей администрацией, который предоставляет менеджеру проекта право использовать ресурсы организации для выполнения работ проекта [ PMBOK].

Определение Проекта ( Project Definition Report) - документ, определяющий проект, в том числе: каковы цели и результаты проекта; в чём его необходимость; что должно быть сделано; как, когда, и где это должно быть сделано; что для этого нужно; сколько это будет стоить; какие необходимо привлечь внешние ресурсы и организации; какие стандарты и процедуры подлежат соблюдению при осуществлении проекта [НТК].

Базис (Project Baseline) - Основополагающие параметры и фиксирующие их согласованное понимание всеми участниками документы проекта – «точка опоры» для всего последующего развития проекта.

Базовый план (Baseline) - Первоначальный план проекта с утвержденными изменениями. Базовый план бывает также и по составляющим проекта - стоимости, расписанию и т.д. [ОУП].

Предметная область ( Scope) – совокупность продуктов и услуг, производство которых должно быть обеспечено в рамках осуществляемого проекта [ PMBOK].

Цели ( Scope) - совокупность продуктов и услуг, намеченных к производству в проекте [ОУП].

Ключевые вехи проекта (Project Milestones) - ключевые события проекта, свершение которых является необходимым и достаточным условием, определяющим достижение результатов проекта. Обычно представляются в виде схемы или таблицы с взаимосвязями и сроками свершения, образуя План по Вехам (Milestone Plan, Milestone Schedule, Master Schedule).

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

Другие варианты – ключевое событие [УП], контрольная точка [УП].

Структура декомпозиции работ (Work Breakdown Structure), СДР (WBS) - представление проекта, в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

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

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

Структура разбиения работ – иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня пакеты детальных работ [УП],

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

Отклонение ( Deviation) – выход за пределы установленных требований. К отклонениям относятся случаи, когда результат работы не удовлетворяет требованиям или необоснованно их превышает[ QMPP].

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

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

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

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

Проблемные ситуации ( Problem situations) – возникающие при осуществлении проекта ситуации, для выхода из которых необходимо находить оптимальные решения [НТК].

Решение проблем ( Problem Solving) – определение последовательных систематических процедур, с помощью которых анализируются и решаются проблемные ситуации [НТК].

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

Изменения – Увеличение или уменьшение характеристик элементов проекта. Пересмотр базового плана проекта. Подразумевает документально оформленные и утвержденные изменения [УП].

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

Расписание проекта - плановые даты для выполнения работ и плановые даты для наступления контрольных (ключевых) событий («вех») проекта [НТК].

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

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

Руководитель проекта (Project manager) - менеджер, отвечающий за успешную реализацию проекта, взаимодействие с Заказчиком, субподрядчиками и подразделениями Компании, организацию подготовки и предоставление отчетности по проекту.

Менеджер проекта - лицо, ответственное за управление проектом [ PMBOK].

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

Бюджет проекта – сметная стоимость, распределенная по периодам выполнения проекта [НТК].

Заинтересованные лица (Stakeholders) – физические и юридические лица, как непосредственно участвующие в проекте, так и те, чьи интересы могут быть затронуты процессами осуществления проекта и его результатами.

Участники проекта – физические лица и организации, которые непосредственно вовлечены в проект или чьи интересы могут быть затронуты при осуществлении проекта [ PMBOK].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Литература:

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

2 Товб А.С. Ципес Г.Л. Метод и опыт создания предприятия по управлению ИТ-проектами. В сб. Трудов 2-ой Всероссийской практической конференции «Стандарты в проектах современных информационных систем», М., 2002. – с.42-47.

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

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

5 C. William Ibbs, Young-Hoon Kwak. The benefits of Project Management: financial and organizational rewards to corporations. - Project Management Institute Education Foundation, 1997

11. Источники, по которым цитируются определения:

Британский стандартBS 6079-2:2000 Project management Part 2 Vocabulary. (перевод авт.).

ISO/TR 10006: 1997 (E). Quality Management – Guidelines to quality in project management (используется перевод Г.Е. Герасимовой).

Wideman Comparative Glossary of Project Management Terms. PMForum, 2000 (www.maxwideman.com).

A Guide to the Project Management Body of Knowledge. PMI Standards Committee.1996 Edition (используется перевод М. Грашиной).

Quality Management for Projects and Programs, Lew Ireland, Project Management Institute , Newtown Square, PA, 1991. (Цитируется по , перевод авт.)

[НТК] Основы Профессиональных Знаний и Национальные Требования к Компетентности специалистов по управлению проектами. Под ред. В.И. Воропаева, 2001.

[ОУП] Основы управления проектами. В.И. Либерзон.

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

[УПП] Управление программами и проектами. 17-модульная программа для менеджеров «Управление развитием организации». Модуль 8. М.Л. Разу, В.И. Воропаев и другие, 1999. Ссылки

В отличии от PM BoK PMI в методологии MITP(PMM) IBM термин Project objectives означает задачи проекта, решение которых, т.е. достижение соответствующих подцелей может быть оценено по количественным критериям.

Например, в различных материалах, основанных на методологии MITP компании IBM, проектные риски не всегда включаются в состав отклонений.

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

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

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

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

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

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

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

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

1. Международные стандарты.
2. Национальные стандарты.
3. Отраслевые решения.
4. Корпоративные стандарты.

(нажмите для увеличения)

Институт PMI и его стандарты

60-е годы двадцатого века для США и всего Мира принято считать прорывными в развитии проектной технологии управления. Революция в аэрокосмической отрасли, новые оборонные стратегии, связанные с наступлением атомной эпохи, новейшие технологии строительства и логистики. План управления проектом Polaris, логистические проекты под военную кампанию во Вьетнаме, соревнование с СССР за лидерство в Лунной программе. Все это породило массу исследований в области построения универсальной модели управления в проектной области.

В 1969 году в штате Джорджия США при Технологическом институте была создана некоммерческая организация PMI (Project Management Institute), которая за чуть менее полувековую историю создала группу стандартов, получивших общемировое признание. В настоящее время методология управления проектами PMI объединяет около 3 млн. профессиональных РМ со всего мира. Штаб-квартира института находится сейчас в Пенсильвании. Более 60% членов PMI находится в Северной Америке, остальные 40% достаточно равномерно распределены по Евразии, Южной Америке и Тихоокеанскому региону.

Методы управления проектами как система обобщенного опыта реализации успешных проектов в результате регулярно проводимых исследований находит свое отражение в основном стандарте PMI ANSI PMBoK Guide (Свод знаний по управлению проектами, упрощенно именуемом PMBOK). Руководство является национальным американским стандартом в сфере PM. Тем не менее, границы его применения значительно шире американского континента. Он находится в активном международном использовании и признан большинством компаний в мире. Лучшие практики, самый передовой опыт и глубокое теоретическое обобщение регулярно ложатся в основу новых версий стандарта.

Модель взаимодействия процессов управления проектом. Источник: Руководство PMBOK, Издание 5
(нажмите для увеличения)

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

Структурная модель управления строительным проектом по методологии PMI. Источник: Руководство PMBOK 5
(нажмите для увеличения)

Прежде чем возникло Руководство PMBOK как национальный стандарт ANSI в США, прошло два десятилетия с момента учреждения PMI. За 70-е и 80-е годы институт PMI провел гигантскую работу по обобщению накопленного опыта в проектной сфере. Первое издание стандарта появилось в 1986 году, которое за 10 лет претерпело ряд доработок. Всего по сегодняшний день выпущено пять изданий Руководства к Своду знаний PMBOK.

1. 1986-1996 гг. – первое издание.
2. 2000 г. – второе издание.
3. 2003 г. – третья версия Руководства вышла в свет.
4. 2008 г. – четвертое издание.
5. 2013 г. – пятая, действующая по настоящее время, версия.
6. 2017 г. – ожидается шестое издание стандарта.

Отличие ISO 21500:2012 от PMBOK

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

ISO (ИСО) – это старейшая и самая мощная международная организация по стандартизации, охватывающая 21 тысячу международных стандартов практически во всех сферах бизнеса и технологии. Как лидер стандартизации мирового уровня ИСО способна интегрировать любой свой новый стандарт в общую систему стандартов ISO. В этом состоит ее ключевое преимущество перед другими системам стандартов в принципе. Действуя в активном сотрудничестве с высшей бюрократией практически всех государств, организация обеспечивает себе безупречный канал продвижения. Это является основной причиной того, что изданный ISO 21500:2012 «Руководство по управлению проектами» имеет все шансы на успех и перспективное лидерство.

Следует заметить, что еще в 2003 году ИСО издало свой первый стандарт в сфере управления качеством проекта ISO 10006:2003. В стандарте были сформулированы основные руководящие принципы по обеспечению надлежащего качества исполнения проектов. Документ должен был получить широкое распространение, но этого не произошло. В сентябре 2012 года, в сотрудничестве с Институтом PMI, ИСО издало во многом повторяющий PMBOK стандарт ISO 21500:2012. Считается, что изданный документ, сохраняя системность и полноту продукта PMI, обладает большим соответствием прикладным потребностям в профессиональной сфере. Стандарт призван:

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

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

(нажмите для увеличения)

Направление стандартизации ICB IPMA

В 1965 году в Швейцарии была учреждена IPMA (Международная ассоциация управления проектами), ее начальной целью являлся обмен опытом проект-менеджеров из разных стран. В 1998 году была утверждена концепция системы сертификации профессионалов в проектной области. Под эту систему должен был возникнуть стандарт, на основе которого можно было бы устанавливать уровень компетентности специалистов для их сертификации. На основании обобщения накопленного опыта, с учетом национальных требований к компетентности, действующих в ряде Европейских стран, был создан стандарт ICB (International Competence Baseline). Тогда же утвердилась четырехуровневая модель сертификации профессионалов.

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

1. Техническая компетентность.
2. Поведенческая компетентность.
3. Консенсуальная компетентность, выражающаяся в умении PM строить эффективные коммуникации со всеми заинтересованными сторонами.

Диаграмма компетентности ICB IPMA «Глаз»

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

Мы с вами видим, что по своей направленности стандарты управления проектами ANSI PMBOK Guide и ICB IPMA отличаются диаметрально, поэтому разнятся и подходы к сертификации. PMI осуществляет сертификацию на звание Project Management Professional (PMP). Требования к сертификации одинаковы во всем мире. В России действуют два сертификационных центра в Москве и Санкт-Петербурге. Сертификация проходит через три этапа, включая предварительную квалификацию, экзамен и собеседование. Экзамен в нашей стране может быть сдан по желанию заявителя на английском или русском языке.

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

Особенности стандарта PRINCE 2

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

1. IT-проекты по разработке и внедрению новых информационных технологий и продуктов.
2. Разработка и вывод на рынок новых продуктов.
3. Жилищная сфера.
4. Инженерные нововведения.
5. Общественный сектор проектной деятельности.

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

Структура методологической системы PRINCE 2

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

Состав принципов, тем и процессов метода PRINCE 2

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

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

В нашем повествовании мы практически не коснулись российских национальных стандартов в области проектного управления. Стоит заметить, что Российской ассоциации управления проектами (СОВНЕТ) и национальным требованиям к компетентности специалистов (НТК) на нашем сайте уже был посвящен . В целом в России многие компании, инициируя инвестиции, создавая план управления проектом и реализуя уникальные задачи развития, часто используют те же PMBOK, IBC IPMA, PRINCE 2. Это связано с тем, что в международных стандартах (а PRINCE 2 также используется в международной практике) присутствует системность первоисточника, и доверие к ним выше.

В качестве адаптированных реплик международных стандартов в России принят ряд ГОСТов, касающихся вопросов управления проектами и их качества:

• ГОСТ Р ИСО/МЭК ТО 16326–2002;
• ГОСТ Р ИСО 10006–2005;
• ГОСТ Р 52806–2007;
• ГОСТ Р 52807–2007;
• ГОСТ Р 53892-2010;
• ГОСТ Р 54 869-2011;
• ГОСТ Р 54 870-2011;
• ГОСТ Р 54 871-2011;
• ГОСТ Р ИСО 21500-2014.

Стандарты управления проектами разрабатываются также и на уровне компании. В отдельной статье мы намерены рассмотреть пример такого стандарта. Зададимся вопросом, каким вспомогательным ресурсом в форме международного стандарта можно воспользоваться при проектировании стандарта управления проектами на уровне предприятия? Среди распространенных методик выделяются PMBOK, ISO 21500, ICB IPMA, PRINCE 2. IPMA исключим из этой обоймы, поскольку он нацелен в большей степени на квалификационные требования к PM. Для ответа на данный вопрос неплохо подходят рекомендации компании AXELOS, управляющей Британским «Портфелем Best practice» (включая ITIL и PRINCE 2).

Пирамида задействованных компонент в стандартах.

К каким выводам пришли исследователи, при анализе самых популярных стандартов?

1. Организация, руководители проектов которой используют PRINCE 2, так или иначе нуждаются дополнительно в более обширной методологии, такой, как, например, PMBOK Guide.
2. В то же время применение Руководства PMBOK требует локализованного метода под национальную и отраслевую специфику, тот же PRINCE 2 или иной специализированный стандарт.
3. ISO 21500:2012 или аналогичный ему ГОСТ Р ИСО 21500-2014 устанавливает более лаконичные требования, в соответствии с которыми проще разработать адаптированный корпоративный стандарт. При этом ни PMBOK, ни PRINCE 2 ИСО не противоречат.
4. Для применения PRINCE 2 и PMBOK Guide на корпоративном уровне эти стандарты нуждаются в процедуре адаптации к реальным условиям и сложившейся культуре управления.

В настоящей статье мы разобрали общую совокупность стандартов, присутствующих на современной рыночной площадке как на международном уровне, так и на национальном. Естественно, что тон задает американский PMI, европейский PM ICB IPMA и активно действующая организация ISO. К сожалению, ГОСТ Р пока развивается в «фарватере» копирования западных образцов с несущественной адаптацией под особенности отечественной школы управления. Остается надеяться, что и в России со временем возникнут сильные решения, но для этого требуется практический прецедент непревзойденной проектной практики, инвестиции в науку и мощное методологическое обобщение.

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

1) применимые к отдельным объектам управления (проект, программа, портфель проектов) и регламентирующие соответствующие процессы управления;

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

3) применимые к системе УП и организации в целом и позволяющие оценить уровень зрелости организационной системы менеджмента.

На рис. 3.1 представлены наиболее популярные стандарты в области проектного менеджмента, включая следующие:

ISO 10006. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов ;

PMBOK Guide. А Guide to the Project Management Body of Knowledge. Руководство к своду знаний по управлению проектами, PMI ;

Рис. 3.1. Наиболее известные стандарты в области проектного менеджмента

PMBOK Guide Government Extension. Руководство к своду знаний по управлению проектами для правительственных организаций, PMI ;

WBS. Руководство по разработке иерархической структуры работ проекта, PMI ;

Earned Value. Руководство по применению методики освоенного объема, PMI ;

PRINCE2. Стандарт управления проектами, OGC (Office of Government Commerce), Великобритания ;

The Standard for Portfolio Management, PMI. Стандарт управления портфелем проектов, PMI ;

The Standard for Program Management, PMI. Стандарт управления программой, PMI ;

Managing Successful Programmes, OGC UK. Стандарт управления программой, OGC (Office of Government Commerce), Великобритания ;

P2M Japan. Стандарт управления проектами и программами в организации, Япония ;

OPM3. Модель зрелости организации в области проектного менеджмента, PMI ;

IPMA Competence Baseline (ICB). Международные требования к компетенции менеджеров проектов, IPMA ;

НТК Россия. Основы профессиональных знаний и Национальные требования к компетентности (НТК) специалистов по управлению проектами, СОВНЕТ ;

PMCDF PMI. Структура развития компетенций в проектном менеджменте (Project Management Competence Development Framework), PMI ;

GPBSPM. Общий стандарт оценки проектного персонала на основе опыта (Global Performance Based Standards for Project Management Personnel), GPBSPM Initiative.

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

Основной стандарт, разработанный IPMA, - ICB (IPMA Competence Baseline, 3-я версия выпущена в 2006 г.). Этот стандарт определяет требования к квалификации специалистов в области УП и является основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всем мире.

Другая авторитетная организация в области проектного менеджмента - Институт управления проектами, США (PMI) с индивидуальной системой членства: насчитывается более 200 тыс. человек в 125 странах мира. PMI имеет наиболее активную и широкую стратегию в области разработки стандартов.

Кроме того, разработано множество национальных стандартов УП, представленных национальными ассоциациями менеджеров проектов: АРМ (Великобритания), VZPM (Швейцария), GPM (Германия), AFITEP (Франция), CEPM (Индия), PROMAT (Южная Корея) и др.

Рассмотрим основные стандарты по группам.

3.1.1. Группа стандартов, применимых к отдельным объектам управления (проект, программа, портфель проектов)

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

ISO 10006:2003. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов;

PMI. А Guide to the Project Management Body of Knowledge. (РМВОК Guide). Руководство к своду знаний по управлению проектами. Третье издание.

ISO 10006:2003. Системы менеджмента качества. Руководящие указания по менеджменту качества проектов.

Данный международный стандарт сам по себе не является руководством по УП. В нем приведены руководящие указания по качеству процессов УП.

В стандарте приводятся основные принципы и практические методики, которые влияют на качество разработки и реализации проектов. В нем процессы по проекту сгруппированы в две категории: процессы УП и процессы, связанные с продуктом проекта (т.е. такие, как проектирование, производство, проверка). Руководящие указания по качеству процессов, относящихся к продукту проекта, рассматриваются в стандарте ISO 9004-1.

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

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

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

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

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

Стратегические (определение направления проекта);

Относящиеся к ресурсам и персоналу;

Касающиеся взаимосвязей;

Касающиеся области применения;

Касающиеся времени;

Связанные с затратами;

Связанные с передачей информации;

Касающиеся рисков;

Связанные с закупками.

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

В основе руководящих указаний по менеджменту качества при проектировании, содержащихся в данном международном стандарте, лежат восемь принципов менеджмента качества (см. ISO 9000:2000, 0.2):

1) ориентация на потребителя;

2) лидерство руководителя;

3) вовлечение работников;

4) процессный подход;

5) системный подход к менеджменту;

6) постоянное улучшение;

7) принятие решений, основанное на фактах;

8) взаимовыгодные отношения с поставщиками.

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

РМВОК Guide. Руководство к своду знаний по управлению проектами. Институт управления проектами, США.

PMBOK Guide является американским национальным стандартом УП и широко используется в мире. В основу стандарта положена процессная модель описания деятельности по УП.

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

В Руководстве определяются:

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

Стандарт УП (часть 2) включает описание пяти групп управленческих процессов: 1) инициация, 2) планирование, 3) организация исполнения, 4) контроль и 5) завершение. В рамках данных групп процессов описываются 44 базовых управленческих процесса и взаимосвязи между ними;

Области знаний по УП (часть 3) состоят из девяти областей знаний: управление 1) интеграцией, 2) содержанием, 3) сроками,

4)стоимостью, 5) качеством, 6) человеческими ресурсами, 7)коммуникациями, 8) рисками, 9) поставками проекта. В данной части приводится детальное описание для каждого из 44 управленческих процессов, включая общее описание процесса, входной и выходной информации, а также перечисление рекомендуемых методов и инструментов.

В PMBОK Guide включено описание перечисленных ниже управленческих процессов.

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

Разработка устава проекта;

Разработка предварительного описания содержания проекта;

Разработка плана УП;

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

Мониторинг и управление работами проекта;

Общее управление изменениями;

Закрытие проекта.

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

Планирование содержания;

Определение содержания;

Создание иерархической структуры работ (ИСР);

Подтверждение содержания;

Управление содержанием.

Управление сроками проекта включает процессы управления по временным параметрам для формирования календарного плана проекта в целях соблюдения сроков:

Определение состава операций;

Определение взаимосвязей операций;

Оценку ресурсов операций;

Оценку длительности операций;

Разработку календарного плана;

Управление календарным планом.

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

Разработку бюджета расходов;

Управление стоимостью.

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

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

Идентификацию рисков;

Качественный анализ рисков;

Количественный анализ рисков;

Планирование реагирования на риски;

Мониторинг и управление рисками.

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

Планирование качества;

Процесс обеспечения качества;

Процесс контроля качества.

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

Планирование человеческих ресурсов;

Набор команды проекта;

Развитие команды проекта;

Управление командой проекта.

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

Рис. 3.2. Структура процессов РМВОК Guide

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

Планирование коммуникаций;

Распространение информации;

Отчетность по исполнению;

Управление участниками проекта.

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

Планирование покупок и приобретений;

Планирование контрактов;

Запрос информации у продавцов;

Выбор продавцов;

Администрирование контрактов;

Закрытие контрактов.

Одним из направлений развития стандарта PMBOK Guide стала его адаптация к отраслевой специфике. В настоящее время выпущены расширения стандарта для правительственных и строительных проектов (Government Extension to the PMBOK Guide, Construction Extension to the PMBOK Guide).

Кроме того, PMI разрабатывает стандарты, связанные с отдельными методиками УП. На сегодняшний день выпущены стандарты, регламентирующие методы разработки иерархической структуры работ проекта и контроля по методу освоенного объема (Practice Standard for Work Breakdown Structures, Practice Standard for Earned Value Management).

Еще один интересный стандарт, регламентирующий управление отдельными проектами, разработан в Государственном департаменте коммерции в Великобритании - PRINCE2 (Projects in Controlled Environments). Данный стандарт регламентирует также процессы управления и параметры контроля на уровне отдельного проекта. В стандарте хорошо прописана связь управленческих процессов с требованиями к структуре и характеристиками создаваемого в рамках проекта продукта. Стандарт широко используется в государственном и частном секторе в Великобритании и все чаще применяется на международном уровне.

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

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

Однако стандартов международного уровня в данной области до последнего времени не существовало. На роль общепризнанных могут претендовать стандарты, выпущенные PMI в 2006 г.: The Standard for Program Management и The Standard for Portfolio Management. Данные стандарты также построены по процессному принципу.

The Standard for Portfolio Management. Стандарт управления портфелем проектов. Институт управления проектами, США.

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

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

Выравнивание компонентов в соответствии со стратегией;

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

Оценка стоимости и взаимосвязей компонентов портфеля;

Определение доступности ресурсов и расстановка приоритетов;

Включение и исключение портфельных компонентов.

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

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

Расстановка приоритетов и выравнивание компонентов управления портфелем в соответствии со стратегическими целями;

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

Измерение стоимости организации с помощью инвестиционных инструментов, таких как ROI, NPV, PP.

Процессы управления портфелем представлены двумя группами:

1) группа процессов формирования портфеля включает процессы управления им, обеспечивающие достижение сбалансированности портфеля проектов со стратегическими целями организации. Группа включает следующие процессы: идентификация проектов, категоризация, оценка, отбор, расстановка приоритетов, балансировка портфеля, авторизация;

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

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

Среди стандартов, определяющих требования к компетенции менеджера проекта, можно выделить Международные требования к компетенции специалистов по УП (ICB), разработанные Международной ассоциацией управления проектами IPMA (Швейцария), и Руководство по развитию компетенций менеджера проекта (Project Manager Competency Development Framework), разработанное PMI на базе структуры и процессов PMBOK Guide.

В настоящее время международной инициативной группой профессионалов в области проектного менеджмента завершается разработка еще одного стандарта оценки квалификации менеджеров проектов на основании достигнутых результатов - Global Performance Based Standards for Project Management Personnel.

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

1) специалист по проектному менеджменту;

2) менеджер проекта;

3) ведущий менеджер проекта;

4) директор программы.

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

1) 20 технических элементов знаний, относящихся к содержанию проектного менеджмента;

2) 15 поведенческих элементов знаний, относящихся к межличностным отношениям между индивидуумами и группами, участвующими в проектах, программах и портфелях;

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

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

Элементы технической компетенции:

Успешность УП;

Заинтересованные стороны;

Требования и задачи проекта;

Проектный риск и возможности;

Качество;

Проектная организация;

Работа команды;

Разрешение проблем;

Структура проекта;

Замысел и итоговый продукт проекта;

Время и фазы проекта;

Ресурсы;

Затраты и финансы;

Закупки и контракты;

Изменения;

Контроль и отчетность;

Информация и документация;

Коммуникация;

Старт проекта;

Закрытие проекта.

Элементы поведенческой компетенции:

Лидерство;

Участие и мотивация;

Самоконтроль;

Уверенность в себе;

Разрядка;

Открытость;

Творчество;

Ориентация на результат;

Продуктивность;

Согласование;

Переговоры;

Конфликты и кризисы;

Надежность;

Понимание ценностей;

Элементы контекстуальной компетенции:

Проектно-ориентированное управление;

Программно-ориентированное управление;

Портфельно-ориентированное управление;

Осуществление проектов, программ и портфелей (ППП);

Постоянная организация;

Предпринимательская деятельность;

Системы, продукты и технология;

Управление персоналом;

Здоровье, безопасность, охрана труда и окружающая среда;

Финансы;

Юридические аспекты.

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

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

Пионером в этой области является стандарт, разработанный Ассоциацией инновационного развития и управления проектами Японии, - P2M (Program and Project Management for Innovation of Enterprises).

Наибольшую же популярность в мире сегодня приобретает стандарт OPM3® (Organizational Project Management Maturity Model), разработанный PMI.

P2M. Program and Project Management for Innovation of Enterprises. P2M - один из наиболее авторитетных современных стандартов в области управления проектами и программами, рекомендованный специалистами в качестве международного. Его положениями руководствуются в управленческой практике множество национальных и интернациональных корпораций.

Исходная идея концепции стандарта P2M заключается в представлении проектов и программ в качестве основополагающих элементов стратегического управления организацией.

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

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

Из методологии управления отдельными проектами;

Интегрального менеджмента (интеграция проектов и программ друг с другом и с окружением);

Управления по сегментам;

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

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

Стратегическое;

Финансами;

Системами;

Организационной структурой;

Достижением целей и показателей;

Ресурсами;

Рисками;

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

Взаимоотношениями участников проекта;

Коммуникациями;

А также управление проектом, направленное на совершенствование.

OPM3® Organizational Project Management Maturity Model. В конце 2003 г. PMI выпустил модель зрелости организационного управления проектами OPM3 (Organizational Project Management Maturity Model), которая изначально позиционировалась как международный стандарт в данной области.

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

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

Основное назначение OPM 3:

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

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

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

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

Инструментальная составляющая стандарта состоит из трех взаимосвязанных элементов:

1) элемент знание (Knowledge) представляет базу лучших практик по УП (около 600 практик, относящихся к разным объектам управления: портфель проектов, программа и проект, и к разной степени зрелости описания процессов);

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

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

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

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

Управление проектами - в соответствии с 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.

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

Общепринятые методы и подходы к управлению проектами описаны в стандартах международных и национальных профессиональных организаций, объединяющих специалистов по управлению проектами, таких как PMI, IPMA, OGC1, ISO, GAPPS, APM, PMAJ и десятки других национальных ассоциаций разных стран.

Project Management Institute — это старейшая и наиболее авторитетная некоммерческая профессиональная ассоциация, основанная в США в 1969 г. и объединяющая в своих рядах свыше 285000 специалистов в области управления проектами из более, чем 170 стран мира через отделения (Chapters), действующие на локальном уровне, а также сообщества: Коллегии (Colleges) и Группы по интересам (SIGs — Special Interest Groups).

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

Базовый стандарт PMI по управлению проектами — Руководство PMBOK во втором от 1996 г. и в третьем издании от 2004 г. был признан Американским национальным институтом по стандартам (ANSI) национальным стандартом в США. В данном стандарте управление проектами описано на основе процессного подхода и модели жизненного цикла проекта. Наиболее важные области управления проектами отраженные в данном стандарте управление рисками, управление расписанием, управление конфигурацией, управление командой и т.д.

International Project Management Association (IPMA) была основана в 1965 г. в Цюрихе ЕС, как некоммерческая профессиональная ассоциация. В настоящее время IPMA объединяет 50 национальных ассоциаций по управлению проектами со всех континентов. Россия в IPMA представлена национальной ассоциацией управления проектами СОВНЕТ.

Основным стандартом IPMA по управлению проектами является ICB - IPMA Competence Baseline, Version 3.0, описывающий требования к компетенциям, необходимым менеджерам проектов и членам проектных команд для управления проектами, программами и портфелем проектов. Для оценки компетенций используется четырехуровневая система сертификации IPMA:

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

Каждая национальная ассоциация, входящая в состав IPMA, отвечает за разработку собственных национальных требований к компетентности специалистов — National Competence Baseline (NCB), которые затем ратифицируются IPMA. В России СОВНЕТ разработан соответствующий стандарт для сертификации российских специалистов — Основы профессиональных знаний и Национальные требования к компетентности специалистов по управлению проектами (последнее издание НТК 3.0 вышло в 2010 г.).

Стандарты The Office of Government Commerce (OGC)

The Office of Government Commerce (OGC) — Офис государственной торговли — входит в состав Группы по эффективности и реформированию (Efficiency and Reform Group) в рамках Офиса кабинета министров Соединенного Королевства и создан для того, что помогать правительству в получении большей отдачи от государственных расходов через достижение следующих целей.

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

Основным стандартом OGC для управления проектами является PRINCE2 (PRojects IN Controlled Environments — Проекты в управляемой окружающей среде).

Первая редакция стандарта PRINCE была разработана в 1989 г. В Великобритании.

Основными особенностями PRINCE2 являются:

Фокус на обоснование проекта с точки зрения бизнеса;

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

Продукто-ориентированный подход к планированию проекта;

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

OGC разработаны еще несколько стандартов для управления проектами.

Стандарты Project Management Association of Japan (PMAJ)

Project Management Association of Japan (PMAJ) — Ассоциация по управлению проектами Японии — была создана в 2005 г. в результате слияния Japan Project Management Forum (JPMF)12и Project Management Professionals Certification Center (PMCC).

Стандарт по управлению проектами — The Guidebook for Project and Program Management for Enterprise Innovation (P2M) — Руководство по управлению проектами и программами для внедрения инноваций на предприятиях..

Ключевая идея - это создание ценности предприятием, независимо от того, коммерческое оно или нет, проходит через последовательную цепочку от его миссии через стратегию, которая воплощает миссию, к программам и проектам, которые являются инструментом реализации стратегии. В стандарте делается особый акцент на целостном, гибком и модульном подходе к управлению проектами и программами, ориентированном на создание ценности. Методология Р2М строится на базе «трилеммы», трех основополагающих понятий — сложность, ценность и сопротивление (Complexity, Value and Resistance).

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

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

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

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

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

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

В Австралии AIPM предусматривает 7 уровней компетентности , и оценка проводится в несколько этапов. PMI (США) предусматривает один уровень компетентности, а экзамен проводится в течение нескольких часов одного дня. С 2000 года сертификационные испытания не требуют личного присутствия кандидата и осуществляются посредством дистанционной сдачи экзаменов через Internet в уполномоченной организации. Для допуска к экзамену надо пройти отбор на основании отправленных ранее документов; основной критерий отбора - наличие достаточного опыта профессиональной деятельности по PM.

Ни одна из систем сертификационных испытаний не свободна от недостатков. Главное же их различие заключается в концептуальном подходе к проекту. При преобладании процессного подхода наиболее адекватная модель PMI, при главенстве системного подхода - модель AIPM, если же в основу положен «менеджерский» подход, целесообразно использование модели IPMA, APM, GPM и др.

Требования к знаниям определяются так называемыми «Сводами знаний» (Body of Knowledge). Они образуют систему требований к знаниям, опыту, мастерству менеджеров проектов и специалистов по PM.

Своды знаний поддерживаются и развиваются международными и национальными профессиональными ассоциациями. В настоящее время ассоциации более чем в 20 странах имеют официальные национальные Body of Knowledge on Project Management (PMBoK) и национальные системы сертификации. Эти Своды знаний представлены в виде национальных систем требований к профессиональной компетентности или национальных стандартов по отдельным вопросам PM.

В области PM международным нормативным документом, определяющим систему международных требований к компетентности менеджеров проектов, является ICB IPMA. На его основе производится разработка национальных систем требований к компетентности специалистов в странах, являющихся членами IPMA. Национальные системы требований должны соответствовать ICB IPMA и официально утверждаться (ратифицироваться) соответствующими уполномоченными органами IPMA. Ряд не входящих в IPMA стран (в том числе США, Австралия и Япония) имеет собственные Своды знаний и системы сертификации.

Правила и нормы работы специалистов по проектному менеджменту согласно требованиям IPMA отражены в документе под названием International Competence Baseline (ICB) - международных требованиях к компетенции специалистов в области управления проектами.

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

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

International Competence Baseline содержит 42 элемента, определяющие знания и опыт в управлении проектами (28 основных и 14 дополнительных элементов), а так же 8 аспектов, касающихся личных качеств кандидата и 10 аспектов, определяющих общее впечатление о сертифицируемом. IPMA требует, чтобы в NCB были включены все 28 основных элементов и, по крайней мере, 6 дополнительных элементов, выбранных на усмотрение национальной ассоциации.

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

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

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

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