В 4м издании все очень сильно изменилось !
Вместо эпиграфа:
PMI не несет ответственность за любые травмы, повреждения, нанесенные собственности,
или любые другие убытки, будь то реальные, косвенные или компенсаторные,
произошедшие непосредственно или косвенно
вследствие издания, применения или использования данного документа.
(PMBOK, 3е издание 2004г)
Оглавление
О чем этот документ
Что такое PMBOK
Основная концепция PMBOK
Что еще есть в PMBOK
Много базовых определений
Определение места PMBOK относительно управления проектами
Определение жизненного цикла проекта
Классификация участников проекта
Место проектов в организациях различных типов
Группы процессов
Области знаний
Управление интеграцией проекта
Управление содержанием проекта
Управление сроками проекта
Управление стоимостью проекта
Управление качеством проекта
Управление человеческими ресурсами проекта
Управление коммуникациями проекта
Управление рисками проекта
Управление поставками проекта
Распределение процессов по группам и областям знаний
Основные документы проекта
Описание процессов PMBOK на примере процессов планирования качества
Входы
Инструменты и методы
Выходы
Развитие PMBOK
О чем этот документ
Данный документ не пытается заменить собой PMBOK , путем пересказа его своими словами. Вместо этого он пытается дать ответ на вопрос — что такое PMBOK, какова основная концепция данного стандарта и какова структура документа, стандарт описывающего. Далее приводится краткое описание 5ти групп процессов и 9ти областей знаний.
Наконец, в качестве примера разбирается несколько процессов. Цель примера — дать представления о способе подачи информации о процессе и о соотношении между такими базовыми для PMBOK понятиями как процесс, группа процессов и область знаний.
Цель документа — дать общее представление о стандарте и отправную точку для его изучения.
Что такое PMBOK
PMBOK - есть попытка объединить и описать все известные знания человечества в области PM. С одной стороны, это приближает данный документ к энциклопедии, и гарантирует сохранность важных практических знаний. С другой — несколько размывает документ, мешая его непосредственному использованию в качестве руководства к практическому действию (хотя PMBOK никогда и не позиционировался как практическое руководство).
Характерным является такое наблюдение: на официальных сайтах практически всех методологий управления проектами (RUP, PRINCE2, MSF и т п) в обязательном порядке присутствует статься «Наша методология и PMBOK». В статье сравнивается PMBOK с соответствующей методологией и делается один и тот же вывод — наша методология и PMBOK ни в коей мере не противоречат друг другу.
Таким образом, PMBOK — наиболее полное изложение знаний, признаваемых сообществом менеджеров проектов. Он задает некоторые рамки для более практических и узконаправленных методологий, но сам методологией пригодной к непосредственному практическому применению не является. Является основой для создания практических методологий.
Отдельно замечу наличие большого количества «воды» , что, видимо, является побочным эффектом желания охватить все аспекты(например, «Участники проекта могут оказывать положительное или отрицательное влияние на проект») а также очень осторожного подхода авторов, заставляющего их постоянно вносить в текст оговорки вроде «Существует также множество других приемов, которые могут быть полезны в конкретных проектах или в некоторых областях приложения»
Основная концепция PMBOK
PMBOK выделяет 44 основных процесса, которые происходят при управлении проектами. Эти процессы с одной стороны распределяются по 5ти группам процессов (например группа процессов планирования или группа процессов исполнения) а с другой, каждый из них относится ровно к одной из 9ти, определяемых PMBOK областей знаний. (например — управление сроками или управление качеством).
Каждый из процессов подробно описан. Описания процессов и составляют основной объем 400 страничного мануала. Описания хорошо структурированы. В частности, каждое из описаний процессов обязательно включает 3 основные части:
Входы
Выходы
Инструменты и методы
Входами процесса являются либо артефакты, полученные при выполнении другого процесса, либо некоторые знания из внешней по отношению к проекту среды.
Выходами процесса являются некоторые артефакты. Это или документы, или части создаваемого продукта ну или сам продукт.
Надо заметить, что говоря об артефактах-документах, PMBOK довольно четко описывает их цель и смысл, а также говорит что должно в них входить, однако PMBOK НЕ задает шаблонов для своих документов, оставляя это на усмотрение менеджеров проектов, либо разработчиков методологий, основанных на PMBOK.
Наиболее ценным содержимым PMBOK является часть «инструменты и методы» в которой собраны все известные авторам практики, относящиеся к данному процессу. Стремление включить именно ВСЕ практики иногда приводит к появлению в этой части описания процесса забавных по своей банальности утверждений. Однако, возможно, такое восприятие является следствием личного опыта, и, возможно, для кого-то столь же банальными покажутся совсем другие части. При этом, многие из предлагаемых практик оказались лично для меня новыми и интересными.
Эту часть имеет смысл читать для повышения образования, для расширения своего личного арсенала методик. Однако, поскольку описывается множество практик, в том числе и взаимоисключающих, невозможно напрямую начать пользоваться этими указаниями, не спроецировав предварительно эти знания на конкретный проект с использованием личного опыта.
Хотя все процессы очевидным образом связаны — поскольку четко определены выходы каких процессов являются для каких процессов входами, PMBOK несколько раз акцентирует внимание на том, что в реальности процессы не идут последовательно один за другим, а происходят параллельно и являются взаимосвязанными.
Цитата:
Процессы управления проектом представлены в виде отдельных элементов с точно определенным интерфейсом. Однако на практике они накладываются друг на друга и взаимодействуют друг с другом; характер этого взаимодействия полностью здесь не описан.
PMBOK отказывается устанавливать эти связи между процессами, заявляя, что они слишком сложны, разнообразны и зависимы от конкретного наполнения проекта и ситуации. Вместо установления таких связей, PMBOK определяет в качестве одной из своих девяти областей знаний «управление интеграцией проекта». Именно этот аспект призван установить и поддерживать нужные связи в актуальном состоянии. На мой взгляд, среди девяти определенных PMBOK областей знаний, управление интеграцией занимает особое место. Это, например, подтверждается тем фактом, что план проекта, согласно PMBOK, состоит из 8ми документов, каждый из которых прямо соответствует планированию активностей в одной из областей знаний. Всех, кроме управления интеграцией. Этим PMBOK как бы хочет сказать, что управление интеграцией не поддается планированию :-). Таким образом, фактически, управление интеграцией выглядит как область «мета-знаний» и находится «над» остальными областями. (эти утверждения — мое личное мнение)
Характерно, что в методологиях (вроде PRINCE2) связи между процессами заданы четко.
Что еще есть в PMBOK
Кроме основной концепции и описания процессов, PMBOK содержит множество дополнительной информации. Здесь перечисляю наиболее значимую.
Много базовых определений
Будучи «энциклопедией», PMBOK включает такие базовые определения, как определение проекта, результатов проекта, управления проектом, последовательной разработки а также описывает отличия проектной деятельности от операционной.
Определение места PMBOK относительно управления проектами
Утверждается, что кроме всего прочего, в каждом проекте должны участвовать эксперты из как минимум 5ти областей знаний
• Свод знаний по управлению проектами
• Знания, стандарты и нормативные акты, относящиеся к данной области
приложения
• Понимание окружения проекта
• Знания и навыки в области общего менеджмента
• Навыки межличностных отношений.
Далее показывается место PMBOK в этих знаниях:
Потом рассказывается о каждой из этих экспертных областей. Что она такое и что в нее входит. На уровне определений.
Определение жизненного цикла проекта
Далее дается определение жизненного цикла проекта. Говорится, что проект можно бить на фазы.
Много тщательно детализированной информации о том, какие бывают жизненные циклы, что у них общего и чем различаются. Дается определение участников проекта и уровней ответственности. Дается несколько наблюдений, связанных с ЖЦ. Например, как обычно потребляются ресурсы в течение проекта или как меняется стоимость внесения изменений. Вся эта информация довольно очевидна.
Классификация участников проекта
К ключевым участникам любого проекта относятся:
• Менеджер проекта. Лицо, ответственное за управление проектом.
• Заказчик/пользователь. Лицо или организация, которые будут использовать продукт проекта. Может существовать множество уровней заказчиков.
• Исполняющая организация. Предприятие, чьи сотрудники непосредственно участвуют в исполнении проекта.
• Члены команды проекта. Группа, которая выполняет работы по проекту.
• Команда управления проектом. Члены команды проекта, непосредственно занятые в управлении его операциями.
• Спонсор. Лицо или группа лиц, предоставляющая финансовые ресурсы – деньгами или в натуральном выражении – для проекта.
• Источники влияния. Лица или группы, которые напрямую не связаны с получением или использованием продукта проекта, но которые, в связи с их положением в организации-заказчике или исполняющей организации, могут положительно или отрицательно повлиять на ход выполнения проекта. Сюда иногда вносят внешние источники, например, зеленых, не дающих построить дом в центре заповедного болота.
• Офис управления проектом (PMO). Если в исполняющей организации имеется этот офис, он может быть участником проекта, если он несет прямую или непрямую ответственность за результаты проекта.
Отдельно отмечается, что участники проекта имеют различные ожидания, и управление ожиданиями — одна из обязанностей менеджера
Место проектов в организациях различных типов
Здесь подробно описывается влияние организации, в рамках которой выполняется проект на сам проект. Рассматриваются типы организаций - функциональные и проектные организации, а также промежуточные (называемые матричными). Матричные делятся еще на три группы по степени приближенности к функциональным (слабо матричные) или проектным (жестко матричные). Третья группа называется матричной сбалансированной.
Рассматривается роль Project Management Office в управлении проектами и в частности в создании и поддержании корпоративной системы управления проектами, под которой понимаются «набор инструментов, методов, методологий, ресурсов и процедур, используемых для управления проектом.»
Группы процессов
Все процессы разделены на пять групп
Группа процессов инициации. Определяет и авторизует проект или фазу проекта.
Группа процессов планирования. Определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект.
Группа процессов исполнения. Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта.
Группа процессов мониторинга и управления. Регулярно оценивает прогресс проекта и осуществляет мониторинг, чтобы обнаружить отклонения от плана управления проектом, и, в случае необходимости, провести корректирующие действия для достижения целей проекта.
Группа завершающих процессов. Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению.
Говорится о переходе от простейшего взгляда на процесс как контур управления к «интеграционному пониманию процессов»
Области знаний
PMBOK определяет и описывает девять областей знаний и распределяет по ним 44 процесса управления проектами.
Управление интеграцией проекта
Как уже отмечалось — интеграция — это магический термин для определения всего непонятного и непрогнозируемого :-)
А вот так определяет управление интеграцией сам PMBOK:
В контексте управления проектом интеграция – это принятие решений о том, где концентрировать ресурсы на каждую конкретную дату, предугадывание потенциальных проблем, и их решение до того, как эти проблемы станут критическими, и хорошая координация работа проекта в целом. Интеграция также подразумевает нахождение компромиссов между пересекающимися целями и альтернативами.
Процессы управления проектами обычно представляются в виде дискретных элементов с хорошо разработанными интерфейсами, в то время как на практике они накладываются друг на друга и взаимодействуют между собой такими путями, которые не могут быть достаточно подробно описаны в Руководстве PMBOK®
Управление содержанием проекта
Процессы по включению в план проекта всех необходимых и только необходимых работ для
успешного выполнения проекта. Эта область знаний содержит следующие процессы управления проектами:
планирование содержания проекта,
определение содержания,
создание ИСР,
подтверждение содержания
управление содержанием.
Управление сроками проекта
процессы, касающиеся выполнения проекта в установленные сроки. Эта область знаний содержит следующие процессы управления проектами:
определение состава операций,
определение взаимосвязей операций,
оценка ресурсов операций,
оценка длительности операций,
разработка расписания и управление расписанием.
Интересно, что среди процессов нет подхода к оцениванию проекта сверху вниз, которое так любят специалисты по 6 сигм
Управление стоимостью проекта
процессы, касающиеся планирования, оценки, разработки бюджета и контролирования
затрат, так чтобы проект был завершен в пределах одобренного бюджета. Эта область знаний содержит следующие процессы управления проектами:
стоимостная оценка,
разработка бюджета расходов и
управление стоимостью.
Управление качеством проекта
процессы по выполнению целей проекта. Эта область знаний содержит следующие процессы
управления проектами:
планирование качества,
процесс обеспечения качества и
процесс контроля качества.
Управление человеческими ресурсами проекта
процессы по организации и управлению командой проекта. Эта область знаний содержит
следующие процессы управления проектами:
планирование человеческих ресурсов,
набор команды проекта,
развитие команды проекта и
управление командой проекта.
Управление коммуникациями проекта
процессы, касающиеся своевременного и достоверного составления, сбора, распределения,
хранения и использования информации по проекту. Эта область знаний содержит следующие процессы управления проектами:
планирование коммуникаций,
распространение информации,
отчетность по исполнению и
управление участниками проекта.
Управление рисками проекта
процессы, касающиеся управления рисками проекта. Эта область знаний содержит следующие
процессы управления проектами:
планирование управления рисками,
идентификация рисков,
качественный анализ рисков,
количественный анализ рисков,
планирование реагирования на риски,
мониторинг и управление рисками.
Управление поставками проекта
приобретения или получения продуктов, услуг и результатов, а также процессы
управления контрактами. Эта область знаний содержит следующие процессы управления
проектами:
планирование покупок и приобретений,
планирование контрактов,
запрос информации у продавцов,
выбор продавцов,
администрирование контрактов и
закрытие контрактов.
Распределение процессов по группам и областям знаний
В таблице показано распределение 44 процессов управления проектами на пять групп процессов управления проектом и девять областей знаний по управлению проектами. Каждый из необходимых процессов управления проектами помещен в ту группу процессов, в которой проходит большая часть его операций.
Таблицу привожу исключительно для любопытных. Без полного изучения PMBOK толку от нее никакого.
Основные документы проекта
В Руководстве PMBOK® описываются три основных документа, каждый из которых имеет определенное назначение:
• Устав проекта. Является официальной авторизацией проекта.
• Описание содержания проекта. Содержит описание работы, которую предстоит выполнить, и результатов поставки, которые надлежит произвести.
• План управления проектом. Содержит описание того, как работа будет выполняться.
Последний документ (план управления проектом) делится на 8 кусочков в соответствии с областями знаний. На самом деле областей знаний 9, но мы планируем только 8, не планируя управление интеграцией проекта. Видимо потому, что управление интеграцией не поддаётся планированию и не является самостоятельным аспектом проекта. Управление интеграцией — это понимание того, что все процессы в проекте взаимосвязаны и действие в соответствии с этой установкой.
Описание процессов PMBOK на примере процессов планирования качества
В область знаний «Управление качеством» входит три процесса. Процесс планирования качества, процесс обеспечения качества и процесс контроля качества. Здесь рассмотрим только процесс планирования качества. Цель — иллюстрировать метод подачи материала в PMBOK.
Как и во всех других случаях, для процессов планирования качеством описываются входы, выхода а также инструменты и методы. Я даю их в сокращенном варианте, достаточном для того чтобы понять о чем идет речь.
Входы
.1 Факторы внешней среды предприятия
На проект могут оказывать влияние нормативные акты правительственных организаций, правила, стандарты и предписания, свойственные определенным областям приложения
.2 Активы организационного процесса
На проект могут влиять политика в области качества, принятая на предприятии и накопленные знания из предыдущих проектов.
Политика в области качества – это общее стремление и нацеленность исполняющей организации в отношении качества, которое имеет формальное одобрение со стороны высшего руководства.
.3 Описание содержания проекта
Описание содержания проекта является ключевым входом для планирования качества, так как оно содержит описание главных результатов поставки проекта, целей проекта.
В состав описания содержания проекта могут входить допустимые пороговые величины, критерии приемки проекта. Также могут быть описаны потенциальные проблемы и откуда можно их ждать.
План управления проектом
Инструменты и методы
.1 Анализ прибыли и затрат
При планировании качества необходимо принимать во внимание соотношение прибыли и затрат. Основная выгода от выполнения требований к качеству заключается в уменьшении числа доработок.
Основные затраты на выполнение требований к качеству – это затраты, связанные с деятельностью по управлению качеством проекта.
.2 Бенчмаркинг
Бенчмаркинг включает в себя сопоставление действующего или планируемого проекта с другими проектами с целью выработать идеи для усовершенствования и критерии оценки исполнения.
.3 Планирование экспериментов
Планирование экспериментов (ПЭ) – это статистический метод, помогающий определить факторы, способные оказывать влияние на определенные переменные величины продукта или процесса в ходе разработки или производства.
Наиболее важным аспектом данного метода является статистическая система, предназначенная для анализа систематических изменений всех важных факторов, в отличие от системы, при которой происходит изменение одного фактора в единицу времени.
Анализ экспериментальных данных должен способствовать разработке оптимальных условий для продукта или процесса, обнаружению факторов, оказывающих влияние на результат, и выявлению взаимодействий и синергизма этих факторов.
Очень похоже на методы, пропагандируемые в 6 сигмах.
.4 Стоимость качества (СК)
Стоимость качества – это совокупная стоимость всех действий, направленных на повышение качества продукта или услуги и обеспечение их соответствия определенным требованиям, а также на предупреждение факторов, способных вызвать снижение качества продукта или услуги и их несоответствие требованиям (доработка). Издержки вследствие отказа часто подразделяются на внутренние и внешние. Такие издержки иначе называют "стоимостью низкого качества".
.5 Дополнительные инструменты планирования качества
Для определения ситуации и планирования эффективных операций по управлению качеством также часто используются другие инструменты планирования качества. К таким инструментам относятся: мозговой штурм, диаграммы родственности процессов, анализ силовых полей, методы
номинальных групп, матричные диаграммы, диаграммы зависимостей и матрицы назначения приоритетов.
Выходы
.1 План управления качеством
План управления качеством описывает, каким образом команда управления проектом будет претворять политику исполняющей организации в области качества. План управления качеством содержит описания процессов контроля качества (КК), обеспечения качества (ОК) и постоянного улучшения качества проекта.
Результаты оценки качества
На мой взгляд термин результаты не удачен, поскольку речь идет не о результатах процесса, а о выборе величин, которые мы будем контролировать и на основе которых будем судить о качестве. И выборе способа измерений этих величин.
Например, недостаточно указать, что критерием для управления качеством проекта является выполнение запланированных сроков. Команда управления проектом должна определить, должна ли каждая работа непременно начинаться в определенное время или только завершиться не позже определенного срока, а также, все ли операции должны контролироваться или только отдельные
результаты поставки, и если так, то какие именно. В качестве примеров результатов оценки качества можно привести: плотность вероятности дефектов, частота отказов, степень готовности, надежность и тестовое покрытие (неисправностей).
.3 Контрольные списки процедур контроля качества
Контрольный список – это структурированный документ, обычно относящийся к определенным элементам, который используется для подтверждения выполнения всех намеченных операций. Контрольные списки могут быть простыми или сложными. Они обычно формулируются в повелительном наклонении ("Сделайте ... !") или вопросом ("Сделали ли Вы ... ?").
.4 План совершенствования процессов
План совершенствования процессов содержит подробные описания шагов аналитического процесса, способствующего идентификации избыточных или не приносящих результатов операций, повышающих стоимость продукта для заказчика.
.5 Базовый план по качеству
В базовом плане по качеству содержатся требования к качеству данного проекта. Служит
основой для оценки и составления отчетов по исполнению требований качества.
.6 План управления проектом (обновления)
Обновление плана управления проектом происходит вследствие добавления к нему вспомогательного плана управления качеством и плана улучшения процесса. Запрошенные изменения в план управления проектом во вспомогательные планы (добавления, изменения, удаления) подвергаются экспертной оценке и вносятся в соответствующие планы в процессе общего управления изменениями
Здесь речь идет о том, что в процессе управления качеством затрагиваются некоторые проектные документы и их нужно менять, согласно процессу управления изменениями.
Развитие PMBOK
Важно отметить, что в последнюю версию PMBOK внесли agile методы, как имеющие право на жизнь, наряду с водопадами.
4 комментария:
Спасибо за материал. Хотелось бы обратить внимание на несколько моментов.
Не уверен, что данный свод знаний задумывался как "всеобъемлющий". Наоборот он достаточно узко охватывает дисциплину управления проектами. Причем только одной "школы" - школы планиварования. Это заментно по перекосу в сторону подробного разностороннего планирования - там почти половина процессов управлния по мнению PMBoK.
Спасибо, за комментарий.
Разумеется "всеобъемлющий" - в рамках знаний об управлении проектами. Собственно, я об этом и написал во введении.
Про планирование, думаю, это не было сделано сознательно, а скорее отражает личный опыт авторов. Возможно, это исправится в четвертом издании, в котором, как говорят, много внимания уделено agile-методам.
Доброго времени суток.
Просьба подсказать какое либо программное обеспечение, позволяющего выполнять работы по заинтересованным сторонам (партнерам).
Замечания, высказывания, предложения
Познакомился с принятым национальным стандартом по управлению проектом –это по сути продукт из США. Отношение двоякое.
Данный документ является декомпозированным, универсальным материалом для регламентации, представления и действий по блокам и процедурам управления проектами.
Положительное документа: в унификации понятий и действий, в регламентации и раскрытии содержания документов подсистем и задач, в структуризации системы управления проектом на уровнях блоков, процедур, элементов.
Отрицательное документа (в продолжении достоинств ): в отсутствии формулировки цели и стратегии, принятой концепции по проекту, в применении новых нетрадиционных определений понятий, в универсализации процедур для разных проектов в существенно отличающих сферах, в отсутствие увязки подсистем проект-менеджмента.
Один из ведущих отечественных учёных теории менеджмента Фатхутдинов Р
сказал, что зарубежная теория менеджмента неприемлема для нашей страны без существенной адаптации.
В период социализма была проведена огромная работа по созданию АСУ. Проектировалась государственная система ОГАС, отраслевые АСУ, АСУП и т.д. В стране были мощные электронные машины серий УРАЛ, МИНСК, ЕС. Решались задачи глобальной оптимизации. Результат мизерный. Американцы идею АСУ нам подкинули, а сами тем временем перешли на ПК и решение частных задач. Был анекдот «АСУ – это самое большое, что смогли сделать американцы для подрыва нашей экономики». Так, и с методологией проект-менеджмента. Не наступаем ли мы вторично на грабли? Концепция, которую мы приняли от американцев или якобы с ними – это прошлый двадцатый век. У них уже другая концепция.
В концепции PMBOK, ESO- 21500 за основу принято положение по достижению требуемого результата- получению заданного продукта с продвижениям по критериям: обеспечения сроков, соблюдения бюджета, обеспечения качества. Но цель и результат могут беспрерывно улучшаться. Например, разрабатывая новый нано материал, по ходу развития проекта мы находим лучшее чем ранее принятое решения по технологии, комплектующим, конструкциям , т.е. потребительскому качеств продукции. Меняются и сроки и стоимость. А как оценить целесообразность решений?.
Ну а определения? Понятие проекта размытое, под него можно подвести любую деятельность. (проект – это уникальная совокупность процессов, состоящая из контролируемых и управляемых видов деятельностей с датами начала и завершения, предназначенная для достижения определенных целей).
В процедурах управления проектом дана ещё внутренняя процедура «управление и контроль(или мониторинг)» . Но управление уже включает планирование, организацию, контроль, регулирование. («масло масляное!») И т.д.
А в блоках. например. управления сроками решается вопрос по отставаниям времени . Да, но в управлении стоимостью есть своё отклонение времени.
Какая между ними связь? Да и методы ПЕРТ ГОЛДРАТА вызывают сомнения. А почему отсутствует подход к решению многокритериальности сроки - стоимость – качество?. Какой объединяющий
критерий выбора?. А как оценивать эффективность при их выборе проектов и завершении? Почему отсутствует финансовый анализ проекта?
Итак, «управление проектом» – гениальная система . Но необходимо, чтобы
предлагаемая национальная методология была бы адаптирована для страны,
принятый стандарт рекомендовался лишь как процедурный, был бы настольной книгой менеджеров, а не тормозом в развитии и применении.
Моё высказывание – это не амбициозная претензия. Уменя своё видение концепции проектов и я не претендую на монополию. Корпоративная методика проект -менеджмента может быть разной по методам и подходам в рамках стандарта, но не в его «оковах».
В части своей причастности к проблеме : к.э.н. ,читал курсУП, занимаюсь
НИР по механизмам УП, работал главным постановщиком задач АСУ,
участвую как автор в конкурсе по инновационным проектам РФ.
Ефименко И.Б.
Отправить комментарий