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

22.09.2019

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопрос соответствия деятельности каким-то общепринятым нормам возникает всегда, когда появляется задача оптимизации такой практики. Это в полной мере следует потребностям бизнеса, который активно применяет методы . В признании своего профессионального опыта в сообществе коллег и перед потенциальным работодателем заинтересован и . Он мотивирован интересом к монетизации своих знаний и навыков, а также намерением подтвердить свой статус как профессионала-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. К сожалению, ГОСТ Р пока развивается в «фарватере» копирования западных образцов с несущественной адаптацией под особенности отечественной школы управления. Остается надеяться, что и в России со временем возникнут сильные решения, но для этого требуется практический прецедент непревзойденной проектной практики, инвестиции в науку и мощное методологическое обобщение.

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1.3

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

Уровень зрелости (оценка, балл)

Характеристика уровня

Уровень 1

Начальный, нулевой уровень.

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

Уровень 2

Уровень осознания.

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

Уровень 3

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

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

Уровень 4

Уровень измеряемости.

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

Уровень 5

Уровень совершенствования.

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

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

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

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

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

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

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

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

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

1. Project Management Body of Knowledge (PMВОК) Американского института управления проектами.

Данный стандарт подлежит обновлению примерно один раз в четыре года. Одной из самых распространенных редакций является редакция 2000 г., а самой актуальной, четвертая версия стандарта, вышла в конце 2008 г.– The Guide to the PMBOK, 4th Edition. Стандарт был принят первоначально Американским национальным институтом стандартов (ANSI) как национальный стандарт в США, а на сегодняшний день имеет мировое признание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Второй группой охвачено управление взаимосвязями процессов.

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

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

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

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

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

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

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

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

Уровень зрелости Характеристика уровня
Уровень 1

Начальный, нулевой уровень.

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

Уровень 2

Уровень осознания.

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

Уровень 3

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

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

Уровень 4

Уровень измеряемости.

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

Уровень 5

Уровень совершенствования.

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

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

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

элемент "оценка" (assessment) - инструмент, помогающий компаниям оценить уровень текущей зрелости управления проектами и установить области улучшения;

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

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

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

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

Если вы заметили ошибку в тексте, пожалуйста, выделите её и нажмите Ctrl+Enter



© dagexpo.ru, 2024
Стоматологический сайт