Pmbok управление коммуникациями

Управление коммуникациями проекта по PMBoK

В соответствии с PMI PMBoK область знаний «Управление коммуникациями проекта» включает в себя процессы, нацеленные на получение, хранение и распространение информации, необходимой для успешной реализации проекта. Схема процессов управления коммуникациями проекта (см. рисунок 1) в соответствии с PMI PMBoK 5th Edition включает следующие отдельные процессы:

Рисунок 1. Схема управления коммуникациями проекта.

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

Схема процессов управления коммуникациями проекта (рисунок 1) в соответствии с PMI PMBoK 5th Edition включает следующие процессы.

Определение заинтересованных сторон проекта

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

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

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

Планирование коммуникаций

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

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

Распространение информации

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

Управление ожиданиями заинтересованных сторон

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

Подготовка отчетов

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

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

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

Содержание статьи

Начиная с 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 процессы областей знаний – это дискретные элементы с чёткими границами. И хотя на практике такие процессы итеративны и могут накладываться при взаимодействии между собой в «Своде знаний» такие взаимодействия не описываются.

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

Свод знаний по управлению проектами (англ. Project Management Body of Knowledge, PMBoK) представляет собой сумму профессиональных знаний по управлению проектами.

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

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

Все процессы разделяются на следующие группы:

Группа процессов инициирования

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

• Разработка устава проекта

• Определение заинтересованных сторон проекта

Группа процессов планирования

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

• Разработка плана управления проектом

• Создание иерархической структуры работ (ИСР)

• Определение состава операций

• Определение взаимосвязей операций

• Оценка длительности операций

• Разработка бюджета расходов

• Планирование человеческих ресурсов

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

• Качественный анализ рисков

• Количественный анализ рисков

• Планирование реагирования на риски

Группа процессов исполнения

Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта. В группу процессов исполнения входят следующие процессы:

• Руководство и управление исполнением проекта

• Процесс обеспечения качества

• Набор команды проекта

• Развитие команды проекта

• Запрос информации у продавцов

Группа процессов мониторинга и управления

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

• Мониторинг и управление работами проекта

• Общее управление изменениями

• Процесс контроля качества

• Управление командой проекта

• Отчетность по исполнению

• Управление участниками проекта

• Наблюдение и управление рисками

Группа завершающих процессов

Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению. Группа завершающих процессов содержит следующие процессы:

Большинство специалистов не знают, что PMBoK ® Guide целиком не является стандартом, несмотря на то, что PMI (Project Management Institute) ставят штамп стандарта ANSI на обложку. Стандартом является только «Стандарт управления проектами» (Project Management Standard for Managing a Project), брошюра размером всего в 40 страниц. Само же, привычное нам, руководство PMBoK гораздо обширнее – более шести сотен страниц (в русском издании 587).

Путём несложных подсчётов станет понятно, что стандарт, утверждённый ANSI составляет менее 10% от всего PMBoK, 93% которого написаны сотрудниками PMI, приглашёнными авторами и даже волонтёрами и никак не является стандартом. «Глава 3 – это стандарт по управлению проектами» сказано во введении четвёртого издания PMBoK. В пятом же издании, он приведён в Приложении №1. Оно так и называется: «Стандарт управления проектом». (стр. 417 русского издания PMBoK 5th Edition, 2013 год).

Рассмотрим основные бытующие мифы:

1. PMBoK это «Международный стандарт».

Эта фраза, написанная на обложке Руководства PMBоK, также вводит читателя в заблуждение.

Что есть стандарт? Это нормативный документ (!), в котором определен основной комплекс правил, норм, требований к стандартизуемому объекту, в котором подразумевается многократное использование этих требований и определяются основные характеристики продукции, правила применения и характеристики производственных процессов. А также дальнейший жизненный цикл продукта.

Какая международная организация по стандартизации объявила Руководство PMBoK стандартом – неизвестно. Первый миф был создан для продвижения PMI.

2. PMBoK содержит лучшие практики.

Другой распространённый миф был создан маркетинговыми подразделениями PMI и их партнёрами для того, чтобы активнее продвигать сертификацию и обучение по PMBoK – единственный источник дохода для большинства из них. Он состоит в том, что PMBоK продвигает лучшие практики в управлении проектами.

Поиск по ключевым словам «лучшие практики» (best practices) и «PMBоK» выдают несколько результатов, но в основном они связаны с лучшими практиками из отраслей, не из руководства, которые могут быть использованы в управлении проектами. Нигде фраза «лучшие практики» не относится к самому Руководству. Наоборот, во введении на странице 2 прямым текстом сказано, что PMBoK включает в себя «хорошие практики», а не лучшие.

Получается, что PMBoK предлагает хорошие, но всё же не лучшие практики.

Зачем был создан этот миф? Затем, что если всё лучшее уже собрано в PMBoK, зачем искать что-то новое. Второй миф – для продвижения PMI и их партнёров

3. PMBoK – это методология.

Третий миф также происходит из маркетинга, но его корни лежат в непонимании подлинной сути Руководства PMBoK, причём даже теми, кто читает по нему курсы.

Достаточно часто приходится видеть рекламу курсов или онлайн дискуссии, упоминающие методологию PMI, PMP или PMBoK® Guide. Так вот, ничего из этого не существует. PMBoK – это фреймворк, PMP – сертификат, а PMI не занимается созданием методологий.

Важно чётко понимать: Руководство PMBоK – общее, именно поэтому оно так популярно и подходит для «большинства проектов в большинстве случаев» (Руководство PMBоK, 5th edition, 2013). А методология или методика должна быть создана и адаптирована к нуждам конкретной организации и проектного окружения. Таким образом, PMBоK– это фреймворк, заготовка для методологии, а отнюдь не методология.

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

4. PMBoK не применим к практике.

Как и предыдущий миф, этот миф происходит из непонимания Руководства PMBoK.

Некоторые практикующие руководители считают, что Руководство означает Инструкция. Они думают, что в PMBoK пошагово описана работа над проектам, с шаблонами и схемами. Они не понимают, что это не Корпоративная Система Управления Проектами (КСУП). PMBoK подразумевает, что такая система в компании уже есть, с описанными процессами и жизненными циклами.

Также часто можно слышать: «Вы что, действительно хотите, чтобы мы реализовывали все 47 процессов? Для этого же нужна целая армия!». Мы обычно улыбаемся и отвечаем: «Да, вы должны их использовать, причём повторять на каждом этапе». Можете представить выражение лица. Это заблуждение, независимо от размеров необходимо реализовывать упомянутые группы процессов, в этом и заключается искусство управления проектами.

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

Институт управления проектами (PMI) выпустил 6 сентября 2017 года шестое издание Руководства к Своду знаний по управлению проектом (PMBоK Guide). Помимо традиционных стилистических и технических исправлений, новое издание PMBоK включает в себя идеи из PRINCE2, теории систем, и теорию гибких подходов к проектному управлению Agile.

Шестое издание PMBоK разделено на 3 части:

• Само Руководство PMBоK.

• Стандарт управления проектом — раньше располагался в Приложениях. Часть содержания, которое раньше входило в состав Руководства, теперь отражено только в тексте. За счет этого информация меньше дублируется.

• Приложения, глоссарий, указатели.

Новую структуру можно только приветствовать — пользоваться изданием стало удобнее.

На этот раз PMI написали однозначно – «…настоящее Руководство не является методологией». И для пущего понимания описали подробно, как использовать Руководство.

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

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

Итак, Project Management Body of Knowledge , PMBoK , является сборником методологических норм, призванных стандартизировать управление проектами организации. Применение этих методик передвигает процесс управления проектом из «зоны искусства» в «зону ремесла», со всеми вытекающими последствиями. Сам человек, руководитель проекта, перестает быть уникальным, делается унифицированным (в известных пределах), и, соответственно, заменяемым. Работает ли это? Необходимо ли? Наверное, если проектный офис компании ведет полсотни проектов одновременно – это необходимо, если же проект уникален, и за ним стоит конкретная личность – вопрос спорный.

Routes to finance

PMBOK за 10 минут – живая запись! (Март 2020).

Table of Contents:

Вам предстоит многому научиться как менеджер проекта! Руководство для Группы знаний по управлению проектами (Руководство PMBOK®) – Пятое издание раскрывает то, что руководители проектов должны знать, чтобы успешно пройти экзамен PMP®, а также быть эффективным в этой роли.

Есть 10 областей знаний по управлению проектами, охватываемых PMBOK® Guide . Они охватывают каждый из 47 процессов управления проектами. В этой статье вы найдете представление на высоком уровне каждой из этих областей относительно того, что вам нужно знать и выполнять как менеджер проекта.

Управление интеграцией проектов

Это описано в руководстве PMBOK® Guide , но это связано с объединением всего, что вы знаете, чтобы вы управляли своим проектом целостно, а не в отдельные куски процесса. Из-за этого легче изучить эту область знаний. Пропустите этот раздел книги и вернитесь к нему позже!

Управление областью проекта

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

Управление временем проекта

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

Здесь вы также составляете график своего проекта.

Управление стоимостью проекта

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

И, конечно же, он охватывает отслеживание расходов проекта на этот бюджет и обеспечение того, чтобы вы все еще были на пути, чтобы не перерасход.

Управление качеством проекта

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

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

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

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

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

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

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

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

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

Управление закупками проектов

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

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

Управление заинтересованными сторонами проекта

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

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

Мнение и комментарии ведущих российских специалистов по управлению проектами об основных новшествах стандарта PMI PMBoK Guide 20

Уважаемые коллеги, мы, как и все российское сообщество по управлению проектами, с нетерпением ждем выхода переработанной новой версии стандарта PMI – PMBoK Guide 2004 .

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

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

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

Итак, по официальной информации PMI, в PMBoK 2004 внесены следующие основные изменения по сравнению с версией 2000:

Более подробную информацию обо всех изменениях и новшествах в PMBoK 2004 вы можете найти на страницах web-сайта: .

Мнения ведущих специалистов по Управлению Проектами в России по представленному драфту 2004 версии стандарта

Алексей Полковников

PMP, Вице-президент Московского отделения PMI, Вице-президент Российской ассоциации управления проектами СОВНЕТ

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

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

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

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

PMBoK увеличился в объеме (примерно на 50 страниц). В основном это произошло за счет развития раздела, описывающего последовательность управленческих процессов (Глава 3 выросла с 9 до 27 страниц). По существу, появилось достаточно хорошо структурированное руководство по последовательности управленческих процедур с описанием входов и выходов, которое имеет самостоятельную ценность для читателя. В предыдущей версии PMBoK процессы делились на основные и вспомогательные, причем только основные процессы были взаимосвязаны, а вспомогательные были представлены несвязанным подмножеством. Спорным являлось выделение организационного планирования и планирования коммуникаций из основных процедур разработки плана проекта, а также разрыв в процедурах планирования рисков и др. Приходилось объяснять это общим характером документа, предусматривающим высокую степень гибкости при описании процедур управления конкретным проектом. В новой версии схемы, отображающие последовательность процессов, значительно переработаны – все процессы объединены в единую последовательность, добавлены основные результаты. Процесс инициации проекта теперь, кроме разработки устава проекта, включает и процедуру разработки предварительного определения проекта (scope statement).

Результаты процессов управления (outputs, deliverables)

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

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

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

Менее значительные изменения управленческих процессов есть почти во всех остальных разделах знаний. Я бы обратил Ваше внимание на новые процессы «Управление заинтересованными сторонами» (Manage Stakeholders) и «Оценка потребности задачи в ресурсах» (Activity Resource Estimating). Еще одним приятным новшеством являются схемы взаимосвязи процессов внутри областей знаний, что позволяет получать более целостную картину по каждой области. Считаю, что с выходом новой версии PMBoK 2004 будет сделан серьезный шаг как в развитии стандарта, так и в улучшении его восприятия. Естественно, что любое значительное изменение связано с появлением спорных моментов и шероховатостей (на которых я не стал акцентировать внимание). Но для их устранения еще есть время.

Сергей Вратенков

PMP, Вице-президент Московского отделения PMI

Первые впечатления от знакомства с новой версией стандарта PMBOK Guide:

Александр Кутузов

В новой версии стандарта (а точнее пока только в его драфте), заметно дальнейшее движение к его рациональности, конкретности и прагматичности, исключению двусмысленности и упрощению. С другой стороны, уделено большее внимание к так называемым“soft skills”; управлению командой проекта, управлению ожиданиями заинтересованных сторон (стейкхолдеров) проекта (добавлен отдельный процесс Manage Stakeholders), которые, на мой взгляд, являются одними из самых важных компетенций и навыков руководителей проектов (и которые так часто ими в проектах игнорируются!).

Порадовало то, что, более тщательно проработана инициация проекта – наконец-то наведен порядок в понятиях Project Charter, Scope Statement, (detailed& preliminary), Project management Plan.

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

Из мелочей, удивление вызвало то, что из оценки длительности работы продолжительности и из количественного анализа рисков исчезло упоминание о методе PERT , но остался почему-то метод составления расписания на дугах (AOA), который уже давно активно не используется. Конечно, более стало разумным упоминание о Earned Value Analysis в управлении стоимостями (а не в управлении коммуникациями, как в PMBOK 2000).

Руководителям проекта сделан подарок в их общении с аудиторами или проектным офисом – в самом начале 3-й главы жирным шрифтов выделено, что в каждом конкретном проекте должны использоваться не все 46 процессов описанных в стандарте, а только те, которые сочтет нужным руководитель проекта вместе со своей командой (ответственность за выбор процессов управления накладывается на того же руководителя проекта). Это, конечно, представляет лазейку менеджерам проекта, поэтому, я считаю, что должны быть определен набор обязательных процессов (и возможно документов) для всех проектов (такие, как например Scope Definition) и вспомогательных, которые выбираются самим руководителем проекта. Хотя, конечно, при корпоративном управлении проектами это может быть определено в методологии управления проектами компании.

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

Алексей Субботин

член Правления СОВНЕТ

PMBoK сделал большой шаг вперед к “процессному” подходу. На сегодняшний день этот подход реализован в стандартах серии 9000, в современных стандартам по ИТ и такое усовершенствование PMBoK несомненно упростит его применение. Особо хочется отметить появление процессных диаграмм – в прошлых версиях их практически не было и приходилось тратить время и восстанавливать их по тексту своими силами.

Радует и внимание уделенное структуризации – разработка WBS вынесена в отдельный процесс, в стандарте наконец появилась Risk breakdown Structure.

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

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

Андрей Белозеров

СPMP, Вице-президент Московского отделения PMI

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

Если PMBoK 2000 была полностью нацелена на управление отдельным проектом и на главное действующее лицо – менеджера проекта, то в новом издании PMBoK сделан существенно больший акцент на управление портфелем. Тем не менее, PMI в своем своде знаний все еще относит такие области знания как управление программой, управление портфелем, проектный офис к «смежным областям» (related endeavors), что позволяет говорить о том, что PMBoK 2004 по прежнему главным образом ориентирована на управление отдельным проектом.

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

Еще одним важным аспектом, который хотелось бы отметить, является критерий включения информации в PMBoK2004. Если ранее в стандарт включалось описание подходов и практик УП, которые являлись общепринятыми (generally accepted), то теперь в PMBoK включаются общепризнанные (generally recognized as good practice) практики.

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

Артем Терпугов

директор направления Московского отделения PMI

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

Претерпело сильное изменение Иинтеграция проекта, что еще раз подтверждает жизненную необходимость этих процессов. В данном разделе следует отметить появление таких жизненно необходимых процессов УП как Direct and Manage Project Execution, Monitoring and Control Project Work.

В новой версии усиленно внимание важности команды проекта и здесь мы уже можем найти требования к компетенции команды проекта, чего ранее не было. Мы можем увидеть новые процессы, акцентирующие свое внимание на команде проекта: управление командой проекта (manage project team) и управление ожиданиями заказчика (manage stakeholders).

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

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

Если верить исследованиям, то 90% времени руководителя проекта уходит на коммуникации. Если верить практике – может, чуть меньше, 70-80%, но это точно бОльшая часть времени в проекте. Обидно, когда время на коммуникации тратится неэффективно, поэтому давайте сегодня обсудим управление коммуникациями в проекте.

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

Управление коммуникациями проекта традиционно состоит из 3х процессов: планирование коммуникаций проекта, выполнение запланированного и контроль за тем, что все идет по плану.

1. Планирование коммуникаций проекта

Цель планирования коммуникаций – разработать план коммуникаций ,документ, в котором будет отражено то, кто, как, когда и какую информацию будет узнать о вашем проекте.

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

Кстати, по ссылке вы можете найти шаблон плана коммуникаций.

Что нужно для планирования коммуникаций проекта?

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

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

Проще говоря – планировать коммуникации желательно не в самом начале, а тогда, когда у вас уже более-менее картинка проекта сложилась, т.к. коммуницировать “то не пойми что” не есть хорошо и профессионально.

В какой момент разрабатывается план коммуникаций проекта?

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

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

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

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

При планировании коммуникаций проекта важно помнить:

• Что коммуникация – не только для вас, но и для других участников проекта. И нужды этих участников необходимо проанализировать и учесть. Например, даже если вся команда проекта в курсе о ходе внедрения ERP-системы – нужно подумать о будущих пользователях, понять, что им плохо и страшно в ожидании неизвестности и предусмотреть какую-то регулярную коммуникацию для них.
• Что надо учитывать специфику и культуру компании. Например, даже если очень хочется вписать “все приходят на встречи вовремя”, но в компании это в принципе не принято, и опоздание на 5-10 минут считается нормой – то писать это бесполезно и даже вредно. Толку все равно не будет, а людей против себя восстановите.
• Что много коммуникации – тоже плохо. Часто при планировании случается перекос, и от почти полного отсутствия коммуникации в проекте руководитель проекта приходит к ее избытку, так как хочется все формализовать. Однако встречи ежедневно (сегодня по объему, завтра по срокам, послезавтра для подготовки к управляющему комитету и проч.) – это зло, которое не даст ни вам ни команде сосредоточиться на работе по проекту, стратегии и проч. Это, конечно, уже скорее аспект личной эффективности руководителя проекта, но все-таки тоже надо учитывать.
• Что информация бывает разной степени срочности. И в зависимости от этого можно и нужно выбирать способ ее коммуникации, чтобы не тонуть потом в письмах и мессенджерах.
• Что отвечает за коммуникацию в проекте РМ (как и за весь проект в целом), но это не значит (совсем не значит!), что он получает или готовит всю коммуникацию. Делегирование и команда управления проектом – наше все.
• Что важно не только написать, как вы будете коммуницировать, но и то, как вы будете контролировать то, что получатель коммуникации ее не только получил, но и понял. Надо не забывать, что за то, чтобы коммуникация была понята, отвечаете именно вы (или другой отправитель коммуникации), а не получатель. Смысл тратить время на статьи про ERP, если они будут написаны нечитаемым для большинства складского персонала техническим языком?
• Что технические вещи типа графика работы, разницы часовых поясов и менталитетов имеют значение. Особенно если у вас международный проект.
• Что важно не забывать о коллегах-РМах. И важно вовремя узнавать о новостях в их проектах, которые как-то могут повлиять на ваш проект, и ставить их в известность о происходящем на вашем проекте.
• Что отчеты – это здорово, но не они не заменяют личного общения. Ну и что отчеты должны соответствовать той аудитории, которая их получает, и что переизьыток информации в них – это даже хуже, чем недостаток, и вызывает слишком много вопросов.

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

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

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

3. Контроль коммуникаций проекта

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

Поэтому нестареющей классикой остаются следующие способы контроля коммуникаций проекта:

1. Инструментальный – в любой более-менее современной системе можно отследить многие действия – как много пользователей заходит на FAQ проекта, открывал ли спонсор хоть раз ваши отчеты, сохраняет ли команда документы в согласованном формате и проч. Если нет – это повод подумать “а почему” и что-то предпринять, а не обижаться, что ваш такой замечательный план эти незамечательные люди не выполняют.
2. Личный – просто поговорить, спросить об удобстве формата или (завуалированно) о проекте, чтобы понять, что человек вообще понимает и выносит из ваших коммуникаций.
3. Аналитический – в большинстве случаев проблемы на проекте возникают именно от недостатка или низкого качества коммуникации по какому-то из направлений. Поэтому любую проблему стоит проанализировать на предмет того “была ли здесь какая-то поломка в коммуникациях и что сделать, чтобы она не повторилась”, внести соответствующие изменения в план коммуникаций и не забыть их тоже прокоммуницировать тем, кого это касается.

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

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

Источники:

http://forpm.ru/%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D0%BC%D0%BC%D1%83%D0%BD%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F%D0%BC%D0%B8-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0-%D0%BF/
http://finswin.com/projects/metody/pmbok.html
http://upr-proektom.ru/svod-znaniy-po-upravleniyu-proektami-pmbok
http://ru.routestofinance.com/10-project-management-knowledge-areas
http://hr-portal.ru/article/mnenie-i-kommentarii-vedushchih-rossiyskih-specialistov-po-upravleniyu-proektami-ob-osnovnyh
http://upravlenie-proektami.ru/upravlenie-kommunikaciyami-proekta