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

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

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

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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IPMA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

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

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

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

Стандарты

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

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

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

Виды стандартов

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

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

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

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

Развитие проектной технологии управления началось в Америке в шестидесятые годы. На это повлияло множество факторов, главными среди которых стали наступление атомной эпохи, соревнования с СССР за освоение космоса и создание новых оборонных стратегий. Было время больших перемен, и необходимость наладить управление проектами и создать универсальную модель для этого была просто неоспорима. Поэтому в 1969 году в США создали первую некоммерческую организацию Project Management Institute, которая занималась разработкой стандартов. Управление проектами на основе стандарта PMI проводится по всему миру и насчитывает более трех миллионов профессионалов этой сферы.

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

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

Теория управления проектами легла в основу руководства PMBOK. Она построена на ключевых аспектах процессной модели и в ней учтены все фазы К тому же она учитывает и все функциональные области знаний касающихся зон управления и взаимодействий их на объекты исследований. Немаловажное место в стандарте занимает план управления. До того как появилось первое издание, институт двадцать лет собирал необходимые сведения и информацию. И уже в 1986 году PMI выпустило первое руководство на основании своих исследований, которое постоянно дорабатывается с учетом современных тенденций. На данный момент существует уже пять различных изданий, которые успешно помогают развитию бизнеса и представляют собой американские национальные стандарты управления проектами.

Стандарт ИСО

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

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

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

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

Основные функции этого стандарта заключаются в следующем:

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

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

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

Международная ассоциация управления проектами IPMA была создана в Швейцарии в 1965 году. Основная цель ее образования заключалась в обмене опытом между проектными менеджерами разных государств. А в 1998 году учредили концепцию профессиональных сотрудников в области проектов. То есть эта система должна была получить стандарт, на основании которого осуществлялась бы сертификация компетентности специалистов. Таким образом был разработан стандарт ICB, основанный на накопленном опыте и учитывающий национальные требования к компетентности большинства стран Европы. В то же время была утверждена четырехуровневая модель сертификации.

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

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

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

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

Стандарт PRINCE 2

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

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

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

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

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

Заключение

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

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

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

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

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

История

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

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

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

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

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

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

Подходы

Существует множество подходов к управлению проектами в зависимости от типа проекта:

· предположение о неограниченности ресурсов, критичен только срок выполнения и качество — метод PERT, метод критического пути;

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

· предположение о неизменности требований, низких рисках, жесткий срок, из этого исходят классические методы PMBOK, во многом опирающиеся на модель водопада;

· предположение о высоких рисках проекта — метод инновационных проектов.

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

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

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

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

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

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

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

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

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

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

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

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

Ориентированные на заказчика , например гибкие методологии SCRUM, частично управление программами, направленное на длительное взаимодействие, а не на один проект/контракт: «проект успешен, если заказчик удовлетворен». Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия, либо проект можно рассматривать как программу из нескольких небольших проектов. Оценка успешности рассматривается в основном с точки зрения заказчика.

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

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

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

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

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

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

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

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

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

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

· Определение среды проекта.

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

· Планирование проекта.

· Техническое выполнение проекта (за исключением планирования и контроля).

· Контроль над выполнением проекта.

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

· Основные процедуры и процессы PMI описаны в стандарте PMBOK:

· Определение требований к проекту

· Постановка чётких и достижимых целей

· Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости

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

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

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

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

· Начало проекта (SU).

· Запуск проекта (IP).

· Планирование проекта (PL).

· Управление проектом (DP).

· Контроль стадий (CS).

· Контроль границ стадий (SB).

· Управление производством продукта (MP).

· Завершение проекта (CP).

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

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

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

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

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

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

· ISO 10006:2003, Quality management systems — Guidelines for quality management in projects (вРоссииприняткакГОСТРИСО 10006-2005 Системыменеджментакачества. Руководство по менеджменту качества при проектировании )

· ISO 21500:2012 Guidance on project management (в России принят как ГОСТ Р ИСО 21500 - 2014 «Руководство по проектному менеджменту»)

Национальные стандарты с расширенной географией применения:

· ANSI PMI PMBOK 5th Edition - A Guide to the Project Management Body of Knowledge (PMBOK Guide)

· PRINCE2 (PRojects IN a Controlled Environment)

· ISEB Project Management Syllabus

· Oracle Application Implementation Method (AIM)

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

· ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом» (Россия)

· ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (Россия)

· ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой» (Россия)

NASA Project Management (США )

· BSI BS 6079 (Великобритания)

· APM Body of Knowledge (Великобритания)

· OSCEng (Великобритания)

· DIN 69901 (Германия)

· V-Modell (Германия)

· VZPM (Швейцария)

· AFITEP (Франция)

· Hermes method (Швейцария)

· ANCSPM (Австралия)

· CAN /CSA -ISO 10006-98 (Канада)

· P 2M (Япония)

· C-PMBOK (Китай)

· South African NQF4 (ЮАР)

CEPM (Индия )

PROMAT (Южная Корея)

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

· ICB IPMA Competence Baseline (IPMA)

· НТК (Национальные требования к компетентности специалистов) (Ассоциация управления проектами «СОВНЕТ», Россия)

PMCDF (США )

NCB UA (National Competence Baseline, Version 3.0) (Украина)

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

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

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

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

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

Программное обеспечение

Существует программное обеспечение как для управления проектами, так и управления портфелем проектов.

Регламент управления проектами (корпоративный стандарт управления проектами) - это внутренний нормативный документ в организации, который определяет подход к управлению проектами , программами и портфелем. Основная часть регламента посвящена описанию процесса, ролей, ответственностей и результатов (промежуточных и окончательных). Регламенты обычно пишутся на основании различных мировых или локальных стандартов (PMBoK , PRINCE2, ISO 21500, ГОСТ 54 и т.д.). Любой регламент содержит в основе процессы, описанные на основе стандартов, про которые писалось ранее и по большому счету мало отличаются друг от друга. Специфика по областям деятельности (ИТ, Строительство и т.д.) достигается выпуском дополнительных приложений, уточняющих детали той или иной области, специфики работы.

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

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

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

Описание

Цель регламента управления проектами по направлениям ИТО в ООО «ДОЧЕРНЯЯ КОМПАНИЯ» (далее - Регламент) - сформировать единый подход к управлению проектами по направлениям информационно-технологического обеспечения (далее - проектами), оператором по которым является ООО «ДОЧЕРНЯЯ КОМПАНИЯ».

Задачи Регламента:

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

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

Регламент процесса управления проектами
по направлениям ИТО в
ООО «ДОЧЕРНЯЯ КОМПАНИЯ»

1. Общие положения

1.1. Введение

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

Например:

Цель Регламента процесса управления проектами - сформировать единый подход к управлению проектами по направлениям информационно-технологического обеспечения (далее - проектами), оператором по которым является ООО «ДОЧЕРНЯЯ КОМПАНИЯ».

Задачи Регламента:

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

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

Задачи совершенствования процесса управления проектами:

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

1.2. Область применения

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

Например:

Действие настоящего Регламента распространяется на все структурные подразделения аппарата управления ООО «ДОЧЕРНЯЯ КОМПАНИЯ» и филиалы в части деятельности по управлению реализацией проектов ИТО.

В филиалах ООО «ДОЧЕРНЯЯ КОМПАНИЯ» управление проектами и портфелями проектов филиалов осуществляется в соответствии с настоящим Регламентом и нормативно-регламентными документами, разрабатываемыми в филиалах и отражающими особенности процессов управления в условиях конкретной организации.

1.3. Нормативные документы

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

Например:

Настоящий Регламент разработан на основании следующих документов:

  • Инвестиционная политика Группы «PME», утвержденная решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--;
  • Положение об управлении инвестиционной деятельностью в Группе «PME», утвержденное решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--;
  • Методика оценки эффективности проектов в области информационно-технологического обеспечения, утвержденная решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--;
  • Бюджетный регламент Группы «PME», утвержденный решением Правления ОАО «ГОЛОВНАЯ КОМПАНИЯ» от --.--.--.

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

  • The Standard for Portfolio Management (PMI 2006);
  • ANSI/PMI 99-001-2008. Project Management Body of Knowledge (PMBOK);
  • Information Technology Infrastructure Library (ITIL);
  • ISO/IEC 20000 Information Technology – Service Management;
  • ГОСТ Р ИСО/МЭК 12207. «Информационная технология. Процессы жизненного цикла программных средств»;
  • ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
  • ГОСТ Р ИСО 9000:2000;
  • ГОСТ 54869-2011 «Проектный менеджмент. Требования к управлению проектом»;
  • ГОСТ 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов»;
  • ИСО/ТО 10006:1997 (Е). «Менеджмент качества. Руководство качеством при управлении проектами».

1.4 Термины, определения и принятые сокращения

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

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

2. Требования к объектам управления

2.1 Определение объектов управления

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

Например:

Объектами управления являются:

  • портфель проектов;
  • проект/инвестиционное мероприятие;
  • подпроект;
  • работа.

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

2.3. Классификация проектов

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

Например:

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

  • принадлежность к Бизнес-сегменту организации – пользователю/общекорпоративному проекту;
  • принадлежность к Бизнес-сегменту организации – балансодержателю результатов проекта ИТО;
  • принадлежность к направлению деятельности ИТО;
  • категория проектов;
  • объемы инвестиций в проект;
  • наличие оцениваемого экономического эффекта;
  • организации-пользователи / Функциональные заказчики проектов ИТО;
  • организации – балансодержатели результатов проекта ИТО;
  • кураторы проектов;
  • структурные подразделения ООО «ДОЧЕРНЯЯ КОМПАНИЯ», реализующие проект.

2.4. Жизненный цикл проекта

В данном разделе перечисляются стадии жизненного цикла проекта.

Например:

Для целей настоящего Регламента в рамках жизненного цикла проекта выделяются следующие стадии:

  • стадия запуска;
  • стадия планирования;
  • стадия исполнения;
  • стадия завершения.

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

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

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

Например:

Основными участниками процесса управления проектами в ООО «ДОЧЕРНЯЯ КОМПАНИЯ» являются:

  • Совет по управлению проектами;
  • Отдел организации управления проектами;
  • Отдел управления портфелем программ и проектов;
  • Куратор проекта;
  • Куратор проекта от ЦАУ (по проекту 3-й категории, реализуемому филиалом);
  • Руководитель Проектного офиса (Проектной группы);
  • Администратор Проектного офиса (Проектной группы);
  • Владелец ресурса;
  • Менеджер проектных рисков;
  • Владелец риска.

3.2. Функции по управлению проектами

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

Например:

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

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

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

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

Владелец ресурса:

  • Согласование Ресурсного плана;
  • Принятие решений о привлечении к работе в Проектном офисе (Проектной группе) конкретных сотрудников;
  • Рассмотрение представленной Руководителем Проектного офиса (Проектной группы) информации об эффективности работы сотрудников для проведения аттестации проектного персонала.

3.3. Требования к организационной структуре проектов

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

4. Описание процессов управления проектом

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

Процессами управления проектом являются:

  • запуск (соответствует стадии запуска в жизненном цикле проекта);
    • назначение Кураторов проектов, категорирование и формирование графика запуска проектов;
    • подготовка и издание приказов о запуске и реализации проекта;
    • разработка и утверждение Устава проекта;
    • ввод данных о проекте в Реестр проектов ИАС.
  • планирование (соответствует стадии планирования в жизненном цикле проекта);
    • Формирование Плана проекта (после запуска проекта) в первом годовом цикле;
    • Формирование Детализированного Календарного плана, Ресурсного плана, Бюджета проекта и Плана расходов по инвестиционному проекту ИТО на планируемые годовые периоды, следующие за годом запуска проекта;
    • Формирование Бюджета проекта и Плана расходов по инвестиционному проекту ИТО на планируемый квартал/ месяц;
    • Заключение договоров.
  • мониторинг и управление (соответствует стадии исполнения в жизненном цикле проекта);
    • мониторинг параметров проекта;
    • управление изменениями параметров проекта;
    • мониторинг рисков по проекту;
    • мониторинг устранения недостатков по результатам опытно-промышленной эксплуатации;
    • управление трудовыми ресурсами.
  • управление изменениями (соответствует любой стадии жизненного цикла проекта);
    • завершение договора;
    • завершение этапа;
    • завершение проекта.
  • завершение (соответствует стадиям исполнения и завершения в жизненном цикле проекта).

Например:

5. Описание процессов управления портфелем проектов

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

В основном ограничиваются следующими процессами управления портфелем проектов:

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

6. Документирование и хранение Регламента

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

Например:

Контрольный экземпляр настоящего Регламента хранится в ООУП. Электронная версия настоящего Регламента находится на внутреннем корпоративном Портале и доступна для чтения всем пользователям.

7. Внесение изменений в Регламент

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

8. Распределение Регламента

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

9. Организация изучения Регламента

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

Приложения к регламенту

  • Приложение 1. Порядок выполнения процедур запуска проектов
  • Приложение 2. Приказ ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
  • Приложение 3. Приказ ОАО «ГОЛОВНАЯ КОМПАНИЯ»
  • Приложение 4. Приказ ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
  • Приложение 5. Приказ о реализации проекта
  • Приложение 6. Приказ ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
  • Приложение 7. Реестр проектов ИТО ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
  • Приложение 8. Приказ ОАО «ГОЛОВНАЯ КОМПАНИЯ»
  • Приложение 9. Типовой Устав проекта
  • Приложение 10. Типовой Устав проекта (упрощенный)
  • Приложение 11. Порядок выполнения процедур планирования проектов
  • Приложение 12. Приказ о завершении проекта ООО «ДОЧЕРНЯЯ КОМПАНИЯ»
  • Приложение 13. План по вехам
  • Приложение 14. Укрупненный календарный план
  • Приложение 15. Детализированный календарный план
  • Приложение 16. Бюджет проекта
  • Приложение 17. Ресурсный план (форма УП-13-1)
  • Приложение 17. Ресурсный план (форма УП-13-2)
  • Приложение 17. Ресурсный план (форма УП-13-3)
  • Приложение 17. Требования к определению ставки работника
  • Приложение 18. План коммуникаций
  • Приложение 19. План управления рисками
  • Приложение 20. Методические указания по календарному планированию и учету фактического исполнения календарных планов
  • Приложение 21. Реестр рисков
  • Приложение 22. Методические указания по управлению рисками
  • Приложение 23. Матрица назначений на проектные роли
  • Приложение 24. Ролевые профили
  • Приложение 25. Порядок выполнения процессов мониторинга и управления
  • Приложение 26. Запрос на изменения
  • Приложение 27. Реестр запросов на изменения
  • Приложение 28. Итоговый отчет
  • Приложение 29. Приказ о завершении проекта
  • Приложение 30. Реестр Руководителей Проектных офисов \ Проектных групп (Руководителей проектов)
  • Приложение 31. Аналитическая записка
  • Приложение 32. Порядок выполнения процедур завершения проекта
  • Приложение 33. Содержание раздела «Техническая поддержка» руководства пользователей ИС
Поддержите проект — поделитесь ссылкой, спасибо!
Читайте также
Стручковая фасоль в сметане Стручковая фасоль в сметане Простые рецепты своими руками Простые рецепты своими руками Происхождение восточного гороскопа Происхождение восточного гороскопа