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

Фреймворк от американского Института управления проектами (PMI) называется «A Guide to the Project Management Body of Knowledge» – сокращённо  PMBoK. «Руководство к своду знаний по управлению проектами» начало выпускаться с 1986 года и с тех пор выдержало 5 изданий (на 2016 год было запланировано 6-ое), в каждом из которых вносились изменения и дополнения. В последнем на сегодня издании «Руководства» насчитывается 6 сотен страниц.

PMBoKНачиная с 1994 года руководство PMBoK включает официальный «Стандарт управления проектом». В нём сформулированы нормы и процессы, которые в среде профессиональных проектных менеджеров, входящих в PMI бизнес-лигу, считаются признанным ориентиром в проектном менеджменте, что подтверждает статусная оценка Американского института стандартов (ANSI). В пятом издании 40-страничный «Стандарт управления проектом» приведён в Приложении №1.

Из всех изданий руководства от предыдущих значительно отличалась версия 2008 года, в которой были внесены новые структурированные модели (методики PMBoK):

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

В пятом издании описывается уже 10 областей знаний (в предыдущей версии было 9), поскольку одна из областей знаний была разделена на две самостоятельные. На эту пока самую актуальную версию и следует ориентироваться при рассмотрении свода знаний по проектному управлению.

Уточнение, которое поможет лучше понять PMBoK

PMBoK – это общее руководство, в котором:

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

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

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

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

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

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

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

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

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

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

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

Области знаний PMBoK

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

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

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

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

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

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

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

6. Человеческие ресурсы. Процессы управления командой проекта предполагают распределение ролей и ответственности даже с учётом изменения в составе команды по ходу проекта. Имеет значение и момент привлечения специалиста – стадия проекта.

7. Коммуникации. Эффективность коммуникации зависит от того, насколько грамотно будут объединены интересы заинтересованных сторон с разнообразными культурными и организационными особенностями. Здесь должен быть консолидирован накопленный опыт, сопоставлены различные взгляды. Поэтому Схема управления коммуникациями предполагает Определение заинтересованных сторон и Управление их ожиданиями, Планирование, Распространение информации, Отчёты об исполнении.

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

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

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

В PMBoK процессы областей знаний – это дискретные элементы с чёткими границами. И хотя на практике такие процессы итеративны и могут накладываться при взаимодействии между собой в «Своде знаний» такие взаимодействия не описываются.

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