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

Некоторые стандарты по проектной деятельности

ICB IPMA

International Competence Baseline of the International Project Management Association (ICB IPMA) — стандарт, описывающий международные требования к компетентности специалистов по управлению проектами (УП), разработанные международной ассоциацией управления проектами.

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

IPMA создана в 1965 г. как форум для обмена опытом менеджерами проектов, работающих в разных странах мирах. В 1967 г. в Вене был проведен первый Международный Конгресс IPMA. Членами IPMA являются в основном национальные ассоциации по УП. В настоящее время в ассоциацию входит 55 стран.

Назначение

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

ICB создан на основе национальных требований к компетентности (National Competence Baseline, NCB, НТК) следующих национальных ассоциаций по УП: АРМ (Великобритания), VZPM (Швейцария), GPM (Германия), AFITEP (Франция).

В 1998 г. IPMA утвердила систему ратификации четырехуровневой сертификационной программы (4-LC — Four Level Certification), которая получила всемирную известность. С 1999 г. международная программа сертификации стала реализовываться.

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

Актуальная редакция ICB IPMA — 3.0, которая была введена в действие в марте 2006 г. взамен редакции 2.0, действующей с 1999 г.

Структура

В основе структуры ICB находится так называемая диаграмма компетентности «Глаз» [2], отображающая всю совокупность элементов УП, которую видит менеджер проекта (МП) при оценке определенной ситуации (рис. 1).

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

ICB содержит описание трех групп компетенций, или элементов компетентности:

Таким образом, всего в стандарте ICB описано 46 компетенций, структурированных по трем группам компетентности [2].

Краткое описание

Описание каждого из 46 элементов компетентности ICB (компетенций) содержит [2, 38]:

ICB включает 20 технических элементов компетентности (таблица 1).

Таблица 1. Технические элементы компетентности ICB

ICB включает 15 поведенческих элементов компетентности (таблица 2).

Таблица 2. Поведенческие элементы компетентности ICB

ICB включает 11 контекстуальных элементов компетентности (таблица 3).

Таблица 3. Контекстуальные элементы компетентности ICB

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

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

Практическая ценность и особенности применения

Практическая ценность стандарта ICB в том, что он является:

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

Руководство к Своду знаний по управлению проектами (A Guide to the Project Management Body of Knowledge; далее — PMBOK®) представляет собой национальный американский стандарт, который содержит профессиональные знания по процессу управления проектами. Выпуском стандарта занимается Институт управления проектами (PMI — Project Management Institute), находящийся в штате Пенсильвания, США. Официальный перевод на русский язык осуществляется представительством PMI в России.

Назначение

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

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

Первое издание PMBOK® вышло в свет в 1986 г. и выдержало несколько редакций.

В 1996 г. PMBOK® был доработан, а в 2000-м выпущено издание PMBOK® Guide 2000, считающееся вторым изданием стандарта.

В 2004 г. PMI выпустил свое очередное творение — PMBOK® Guide Third Edition, которое получило самое большое распространение свода знаний по управлению проектами PMI.

31 декабря 2008 г. вышла в свет новая версия методологии — PMBOK® Fourth Edition, которая, как предшественник, была детально переработана и стала по сути таким же революционным изданием.

Текущая (на момент написания книги) версия стандарта — PMBOK® Fifth Edition — была выпущена в январе 2013 г.

Дата выпуска PMBOK® Guide Sixth Edition еще неизвестна, но, вероятнее всего, PMI выпустит этот стандарт в 2016 г., поскольку обновляется PMBOK® регулярно, с частотой один раз в четыре года.

Структура

В пятой редакции стандарта PMBOK® выделено несколько ключевых структурных элементов.

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

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

Рис. 2. Жизненный цикл согласно пятой редакции стандарта PMBOK®

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

И наконец, в приложении к стандарту раскрыты межличностные навыки качества, которые важны для деятельности руководителя проекта. К таким навыкам отнесены [1]:

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

Краткое описание

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

Пять групп процессов затрагивают ряд областей знания. В пятой редакции PMBOK® выделены десять ключевых областей [1]:

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

Практическая ценность и особенности применения

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

Упор в стандарте PMBOK® сделан на процесс управления, который максимально унифицируется и не увязывается с конкретной предметной областью.

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

ГОСТ Р 54 869-2011 «Проектный менеджмент. Требования к управлению проектом»

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

Назначение

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

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

Структура

ГОСТ Р 54 869 представляет собой общее описание рекомендованных требований к управлению проектами. Они сгруппированы по процессам управления, среди которых выделяют процессы [14]:

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

Краткое описание

ГОСТ Р 54 869 содержит ряд ключевых разделов, каждый из которых описывает требования к отдельным процессам управления:

Помимо указанных разделов, ГОСТ [14] описывает ключевые роли:

Практическая ценность и особенности применения

ГОСТ Р 54 869-2011 может использоваться с целью оценки соответствия управления проектом установленным в стандарте требованиям.

При этом в стандарте нет требований, обязательных для какого-то определенного вида проектов; нет требований к методам реализации процессов управления проектами, а также требований к предпроектной и послепроектной деятельности. Основным объектом для стандартизации должны выступать, по версии ГОСТа, результаты («выходы») процессов управления проектом.

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

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

Российская национальная ассоциация управления проектами (СОВНЕТ) была создана в конце 1990 г., а в феврале 1991 г. вошла в состав IPMA.

Назначение

СОВНЕТ, как и другие национальные ассоциации, на основании двусторонних соглашений с IPMA получила право самостоятельно осуществлять сертификацию проектных менеджеров под эгидой IPMA. При этом СОВНЕТ разработала и утвердила собственную детальную документацию для сертификационной программы и Национальные требования к компетентности (НТК, NCB). При разработке НТК национальным ассоциациям предоставляется определенная свобода действий для учета особенностей национальной культуры и достижений в области управления проектами [38].

Итак, назначение стандарта НТК в том, что он, так же как и ICB, определяет международные требования к компетентности специалистов по УП и является основой для их профессиональной сертификации. НТК — основа сертификационной программы России, которая реализуется сертификационным центром СОВНЕТ-СЕРТ в рамках национальной ассоциации УП.

Актуальная редакция НТК — 3.0, которая была введена в действие в сентябре 2010 г. взамен редакции 2.0, действующей с 1999 г.

Структура

На базе разработок и опыта СОВНЕТ совокупность возможных процессов управления проектами рассматривается в рамках активной комплексной кибернетической системы, включающей объекты, субъекты и процессы управления, получившей название «системная модель управления проектами» [13].

Системная модель представляет собой свернутые структуры («деревья»), включающие все элементы проектного управления, сгруппированные по трем блокам: объекты управления, субъекты управления, процесс управления. Все элементы модели «Глаз» ICB соотносятся с названными блоками системной модели управления проектами [38].

В НТК все элементы компетентности сгруппированы в соответствии с системной моделью и ICB в следующие четыре группы:

Визуализация полученной модели может быть сделана по аналогии с диаграммой компетентности «Глаз» ICB (рис. 3) и в дальнейшем будет называться «диаграмма компетентности «Глаз» НТК» [38].

Общее количество элементов компетентности (компетенций) в НТК равно 55. Соотношение содержания описания элементов компетентности в ICB и НТК сведены в таблицу 4.

Таблица 4. Соотношение содержания описания компетенций в ICB и НТК

Из дополнительных элементов компетентности четыре компетенции выделены в отдельную группу компетенций под названием «Базовая (общая) компетентность», которая в диаграмме компетентности «Глаз» НТК представлена «Зрачком» (рис. 3).

Рис. 3. Диаграмма компетентности «Глаз» НТК

Краткое описание

В НТК описаны 55 элементов компетентности (компетенций). Описание каждого элемента включает [38]:

НТК включает 10 элементов компетентности, входящих в группу «Объекты управления и контекстуальная компетентность» (таблица 5).

Таблица 5. Элементы, входящие в группу «Объекты управления и контекстуальная компетентность»

НТК включает 24 элемента компетентности, входящих в группу «Субъекты управления и поведенческая компетентность» (таблица 6).

Таблица 6. Элементы, входящие в группу «Субъекты управления и поведенческая компетентность»

НТК включает 17 элементов компетентности, входящих в группу «Процессы управления и техническая компетентность» (таблица 7).

Таблица 7. Элементы, входящие в группу «Процессы управления и техническая компетентность»

НТК включает четыре элемента компетентности, входящих в группу «Общая компетентность» (таблица 8).

Таблица 8. Элементы, входящие в группу «Общая компетентность»

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

Практическая ценность и особенности применения

Практическая ценность стандарта НТК в том, что он является:

«По своему содержанию и информационной насыщенности НТК в настоящем его виде представляет собой российский свод знаний, информационных материалов по управлению проектами и может служить путеводителем в мир управления проектами, а также основой для последующей подготовки национальных стандартов и нормативных документов по управлению проектами» [38].

Источник

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

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

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

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

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

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.

Можно ориентироваться на один стандарт или совмещать сразу несколько.

Методология управления — это набор методов и практик. Это подробный план действий, в отличие от стандарта, который просто задает направление.

Вопросы, которые помогут различать стандарт и методологию

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

Три основных отличия стандарта управления от методологии

Чтобы не путать стандарт и методологию, запомните три отличия.

Первое отличие: правила

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

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

Например, так выглядят общие принципы гибких методологий.

12 принципов Agile

У agile-фреймворка Scrum есть специальный гид, которому нужно следовать.

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

Второе отличие: последовательность действий

У стандарта нет последовательных шагов, а в методологии всегда понятно, что и за чем делать.

Например, основа методологии Waterfall — это последовательность, каскадность шагов. Их нельзя менять местами или отменять.

Жизненный цикл разработки ПО при использовании каскадной модели — это пять этапов.

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

Третье отличие: роли

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

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

Источник

Как выбрать методологию для управления проектами? Обзор популярных методологий УП. Методы управления проектами

Елена Филипова, руководитель корпоративного проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»:

Когда я училась в университете, мне повезло бывать на лекциях академика Габдулхаева. Не имея понятия об управлении проектами, он учил нас гибкости применения наших знаний, выбору оптимального метода. Его любимый вопрос на экзамене: «Какой метод приближения лучший?». А правильный ответ гласил: «Лучшего нет, в каждой ситуации лучший метод свой». Тоже самое можно сказать и о проектном менеджменте: в каждом проекте, и даже в каждой фазе проекта, может быть свой, лучший подход, своя методология. Как выбрать то, что подходит? Чем отличаются популярные методы управления проектами​, и в каких проектах их лучше применять?

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

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

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

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

В мире не так уж и много «официальных» (признанных) методологий, из которых можно выбирать:

При этом большинство (ISO 21500, ГОСТ Р 54869-2011, APMBOK, C-PMBOK) ориентированы на старейший стандарт PMBoK (USA), а другие (P2M, PRINCE2, ICB IPMA) используют собственные подходы.

Что такое методология? Для ее существования необходимо несколько принципиальных моментов:

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

Смотрите, как все просто: берете план, вводите в информационную систему статус работ и поставляете результаты. И чего только все так с проектами мучаются? Методология как бы концентрируется на внешнем контуре, а специфику исполнения работ отдает на откуп конкретному руководителю проекта. Но в именно специфике почти всегда и кроется «корень зла», именно из-за особенностей компании, ее инфраструктуры, культуры людей и просто характеров участников проекты либо успешны, либо нет.

А где же Agile?

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

Сильные и слабые стороны разных подходов

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

«Классический» (PMBoK и его модификации)

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

«PRINCE2»

Первая редакция британского стандарта PRINCE2 вышла в свет в 1989 г. и была направлена на управление правительственными проектами по созданию информационных систем. Это объясняет более строгое отношение PRINCE2 к окупаемости и применению продукта.

«Гибкие подходы» (SCRUM)

Более гибкие подходы к управлению проектами стали активно развиваться с прогрессом компьютеризации и программирования. Существующие стандарты тормозили проекты по разработке программного обеспечения, требовались совершенно новые подходы. Поэтому в 2001 году в США встретились передовые 17 разработчиков и сформулировали контур движения Agile. Одним из наиболее популярных фреймворков стал SCRUM.

Как выбрать то, что подходит?

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

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

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

Иногда в ходе практики мы находили очень эффективные собственные способы, а затем я отыскивала их прообразы в других стандартах. Так, будучи уверенной, что вношу небольшие корректировки в PMBoK, я начала на уровне методологии использовать регулярные частые и короткие совещания с командой (прообраз Daily Scrum Meeting), применять для фаз и ключевых результатов критерии успеха (аналог Scrum Acceptance Criteria) и многое другое.

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

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

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

Чтобы дойти до цели, человеку нужно только одно. Идти.
Оноре де Бальзак

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

Источник