Знание pmbok что это
PMBoK
Прежде чем перейти к предмету статьи, мы хотели бы сказать, что вы не должны рассматривать ее в качестве всеобъемлющего пособия по управлению проектами. Мы лишь хотим простым языком познакомить вас со сводом соответствующих знаний, который и называется PMBoK (Project Management Body of Knowledge).
Из нашей статьи вы узнаете, что вообще представляет собой PMBoK, в чем состоит основная концепция этого Стандарта, каковы основные процессы управления проектами. Также мы расскажем, зачем нужен сертификат PMP (Project Management Professional) и как получить его.
Таким образом, цель материала в том, чтобы дать вам представление о PMBoK и помочь понять, с чего нужно начинать его изучение. В конце мы предложим несколько полезных ссылок на тематические ресурсы.
Что такое PMBoK?
Итак, PMBoK представляет собой попытку объединения и описания всех знаний в сфере управления проектами, которыми сегодня обладают люди. По сути, его можно назвать своеобразной энциклопедией, однако в качестве практического руководства его рассматривать не следует. В нем содержится лишь информация для изучения, описания методов и рекомендации к работе.
Несмотря на то, что на большинстве официальных сайтов методологий проект-менеджмента, в том числе и связанных с PMI (Project Management Institute), имеются статьи об индивидуальной методологи организаций, всегда указывается, что они (эти методологии) никогда не идут вразрез с PMBoK вообще.
Отсюда можно сделать вывод, что PMBoK – это максимально полное изложение знаний по управлению проектами, которое признается всеми специалистами данной области. Это изложение является основной для более узких и практических методологий, но вот сам PMBoK назвать методологией, подходящей для практического применения, нельзя. Основная его ценность заключается в концепции, пригодной для создания других методологий.
Концепция PMBoK
В PMBoK выделяются 44 главных процесса, происходящих при управлении проектами. Эти процессы разделены на пять основных групп:
Каждый из этих процессов относится к одной из девяти (в некоторых случаях – десяти) областей знаний, определяемых PMBoK:
По этим девяти направлениями распределяются все 44 процесса проект-менеджмента. PMBoK подробно и структурированно описывает все процессы, и в общей сложности они составляют довольно объемный мануал, т.е. руководство (где скачать, мы расскажем ниже). Кроме того, каждое описание процессов в обязательном порядке состоит из трех основных частей:
В качестве входов процесса могут выступать какие-то сведения из внешней для проекта среды, либо артефакты (документы), которые были получены при выполнении других процессов. В качестве выходов выступают документы, части разрабатываемого продукта или его рабочая версия.
И здесь важно заметить, что PMBoK предельно ясно описывает смысл и цель артефактов-документов и перечисляет их составляющие. Но в то же время в своде знаний нет никаких шаблонов для создания такой документации – этим занимаются менеджеры или разработчики PMBoK-проектов.
К области наиболее важного содержимого PMBoK относится раздел «Инструменты и методы», включающий в себя все созданные сегодня практики, имеющие отношение к тому или иному процессу. О них мы расскажем чуть позже, а пока отметим, что именно эта часть рекомендуется к изучению и позволяет специалисту повысить свое образование и расширить личный арсенал методов и практик. Но предлагаемые PMBoK указания всегда должны быть изначально спроецированы на конкретный проект и сопоставлены с личным опытом.
Невзирая на то, что все процессы взаимосвязаны между собой (можно четко установить: выход какого процесса будет является входом для другого процесса). В PMBoK не раз говорится, что на практике процессы не всегда последовательны, а значит, могут быть параллельными и взаимосвязанными. Учитывая сложность, разнообразие и зависимость этих связей в каждом отдельном случае, PMBoK их (эти связи) не устанавливает.
Установление связей заменяется в PMBoK специальной областью знаний «Управление интеграцией проекта». Благодаря интеграции устанавливаются и поддерживаются в актуальном состоянии необходимые связи. Чтобы у вас сформировалось целостное понимание вышесказанного, предлагаем посмотреть 10-минутное видео от специалиста по проект-менеджменту Михаила Софонова.
Также вы должны знать, что помимо описания процессов и основной концепции в PMBoK содержится немало и другой дополнительной информации. Обо всем мы, конечно, не расскажем, но укажем на то, что имеет наибольшее значение.
Основные элементы PMBoK
Как мы и сказали, PMBoK – это своеобразная энциклопедия знаний по управлению проектами. В ее состав входит огромное количество базовых определений и всевозможных описаний отличий между проектной и операционной деятельностью.
Также PMBoK говорит, что в дополнение ко всему остальному в любом проекте должны принимать участие специалисты как минимум из пяти областей знаний:
PMBoK рассказывает о каждой из этих областей, объясняет ее суть и описывает составляющие, а также указывает на место самого стандарта относительно проектного управления вообще.
После этого приводится определение жизненного цикла проекта, и описываются его фазы. Жизненный цикл проекта – это набор последовательных и иногда перекрывающихся фаз. В большинстве случаев он выглядит так:
Воздействовать на цикл могут особенности (свойства) организации и отрасли, в которой она работает, применяемые подходы. Причем, исходя из уникальности каждого проекта и его временной ограниченности, входящие в него процессы и результаты могут меняться. Через жизненный цикл можно выстроить базовую структуру управления PMBoK-проектом, независимо от его содержания.
Помимо стандартного жизненного цикла, PMBoK рассматривает и другие циклы, а также их общие признаки и различия, дает определения участников проекта и уровней их ответственности. И как раз об участниках, как о важнейшем элементе проектной деятельности, следует сказать подробнее.
Участники проекта
Согласно PMBoK, классификация участников проекта такова:
Заметим, что PMBoK говорит как об ответственности участников проекта, так и об их ожиданиях. Управление ожиданиями входит в число прямых обязанностей проект-менеджера.
Говоря о концепции PMBoK, мы упомянули также о проектной документации. Она составляет не менее важную часть всего Стандарта, по причине чего есть смысл немного углубиться и в эту тему.
Главные проектные документы
Всего PMBoK указывает на три основных документа. Каждый из них выполняет свою конкретную функцию:
План управления проектом всегда разделяют на отдельные части, исходя из областей знаний. Не входит в него только управление интеграцией, т.к., будучи самостоятельной единицей, планированию она не поддается. Управление интеграцией предполагает взаимосвязь всех процессов в проекте и работу, основанную на этой взаимосвязи.
И, естественно, мы не могли не сказать еще об одном аспекте управления проектами, которому PMBoK уделяет огромнейшее внимание – это инструменты и методы работы. Но повторимся: чтобы понять, что именно подходит для конкретного проекта более всего, необходимо тщательно изучить сам Стандарт.
Инструменты и методы PMBoK
Ниже мы приведем лишь перечень основных инструментов и методов PMBoK (о некоторых из них мы рассказывали на нашем сайте, поэтому переходите по ссылкам и разбирайтесь).
В дополнение к этим методам в последней версии PMBoK (пятое издание) присутствуют также методы гибкой системы управления проектами Agile. Каждый из них подробно изучается и осваивается при исследовании PMBoK. Множество материалов на эту тему вы можете найти на сайте Московского отделения Института проект-менеджмента (PMI) и официальном сайте PMI (на английском языке).
Собственно, в полной мере овладеть PMBoK должен любой человек, планирующий или уже профессионально занимающийся проектами и их управлением. PMBoK – это основа основ в проектном менеджменте. И по этому поводу будет к месту немного поговорить о том, зачем нужен сертификат профессионала по управлению проектами (PMP), как его получить и как сдать экзамен.
Сертификат PMP
В настоящее время по всему миру работает свыше 470 тысяч сертифицированных специалистов по проект-менеджменту. Получить сертификат PMP может любой специалист, независимо от отрасли, в которой он работает.
Зачем нужен этот сертификат? Все очень просто – с ним у вас появится возможность стать членом крупнейшего и самого престижного сообщества профессионалов по управлению проектами, а это сулит прекрасные перспективы, карьерный рост и высокооплачиваемые должности. Сертификат доказывает, что вы знаете, что такое проекты, и понимаете, как ими управлять.
Однако для получения такого документа необходимо, во-первых, соответствовать определенным профессиональным требованиям, во-вторых, иметь достаточный стаж работы, и, в-третьих, сдать экзамен.
Есть несколько важных дополнений:
Что же касается требований к кандидату, то они таковы:
При подаче заявки на экзамен вам придется в деталях расписать весь свой опыт – указать компанию, название и стадии проекта, а также контакты организации. На заполнение и отправление заявки отводится 90 дней. Все данные должны быть достоверными, т.к. PMI регулярно проверяет поступившие заявки.
Экзамен будет проходить на компьютере. Он включает в себя 200 вопросов. На выполнение всех заданий отводится 4 часа. После успешной сдачи экзамена выдается сертификат PMP. Он действителен в течение трех лет, однако для подтверждения своего статуса и его окончательного утверждения нужно будет за указанный срок набрать 60 баллов PDU (Professional Development Units). Но об этом читайте на сайте PMI.
Мы же подводим итог нашему обзору. Надеемся, теперь вам стало понятнее, что такое PMBoK, как сдать экзамен PMP, и зачем нужен сертификат. Не теряйте драгоценного времени, и начинайте изучать PMBoK. Существенную поддержку в этом вам окажет наш курс «Управление проектами», где есть много полезной информации, которая пригодится вам в вашей работе, и отличный видеокурс по проектному управлению.
Методология, фреймворк или стандарт проектного управления
В продолжение статьи о классическом PRINCE2 по запросу из комментариев попробовала сравнить ключевые методики управления проектами. Надеюсь, что получилось что-то полезное и при выборе подхода управления у читающих часть вопросов будут снята.
Краткие вводные:
PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.
PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.
Как можно заметить, первое главное отличие – собственное позиционирование в проектном управлении. Остальные основные отличия с некоторыми субъективными выводами приведены в таблице.
PRINCE2
PMBoK (6 издание, 2017г.)
ISO 21500:20112
Определение проекта
Временная организация, которая создается с целью предоставления одного или нескольких бизнес-продуктов в соответствии с утвержденным экономическим обоснованием проекта.
Временное предприятие, направленное на создание уникального продукта, услуги или результата.
Уникальная совокупность процессов, состоящая из контролируемых и управляемых видов деятельностей с датами начала и завершения, предназначенная для достижения определенных целей.
Процессы
7 процессов: Начало проекта, руководство проектом, инициация проекта, контроль стадии, управление границами стадии, управление созданием продукта, закрытие проекта.
49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.
39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.
Предметные темы / группы (курсивом отмечены различающиеся темы)
7 тем:
1. Экономическое обоснование,
3. Управление качеством,
5. Анализ и управление рисками,
6. Управление изменениями содержания,
7. Принятие решений.
10 областей знаний:
1. Управление интеграцией проекта,
2. Управление содержанием,
3. Управление сроками,
4. Управление стоимостью,
5. Управление качеством,
6. Управление человеческими ресурсами,
7. Управление коммуникациями,
8. Управления рисками,
10. Управление заинтересованными сторонами.
10 предметных групп:
2. Заинтересованные стороны,
Жизненный цикл проекта
Структура стадий проекта:
1. Стадия инициации,
2. Последующие стадии (создание продуктов, соответствующих требованием),
3. Финальная стадия (приемка результатов, подведение итогов проекта).
Минимальное количество стадий в проекте – 2 (инициация и финальная).
Все проекты могут иметь следующую структуру жизненного цикла:
2. организация и подготовка;
3. выполнение работ проекта;
4. завершение проекта.
В стандарте отсутствуют четкие требования/пояснения по стадиям проекта, стандарт определяет, что проект должен подразделяться на фазы, состав и содержание которых должно определяться потребностями управления и контроля.
Принципы
7 принципов (универсальны и не требуют обоснования):
1. Постоянная оценка целесообразности,
2. Учет предыдущего опыта,
3. Определенные роли и обязанности,
4. Управление по стадиям,
5. Управление по исключениям,
6. Фокус на продукте,
7. Адаптация к внешним условиям.
Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.
Ожидается, что новое седьмое издание будет ориентировано на принципы.
ISO 21500 по аналогии с PMBoK основан на процессной составляющей.
Ответственность за результат проекта
Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.
Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.
Руководитель проекта = единый ответственный за результат.
Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.
Инструменты управления
В методологии отсутствуют примеры инструментов, данная область отдается на откуп Руководителю проектов.
Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.
Стандарт не описывает конкретных инструментов для реализации процессов управления.
Возможность гибкого применения
Допускает использование минимального количества документов с минимальным требуемым содержанием, гибкое использование метода с соблюдением всех 7 принципов позволяет подготавливать упрощенную отчетность и минимизировать процессы управления (с учетом целей и задач, которые соответствуют процессам PRINCE2).
Так как PMBoK является не методологией или стандартом, а фреймворком, его создатели рекомендуют использовать PMBoK для создания собственной методологии управления проектами в компании. При этом созданная методология должна учитывать особенности каждого отдельного проекта и позволять руководителю проектов изменять процессы управления в определенных пределах.
Описанные в стандарте процессы не должны применяться без изменений ко всем проектам или фазам жизненного цикла проекта. Руководитель проекта должен корректировать состав процессов управления конкретным проектом или фазой, отбирая подходящие процессы и условия их реализации. Такая адаптация должна выполняться в соответствии с существующими политиками организации.
Возможность использования в программе проектов
Возможность использования в портфеле проектов
Сертификат PMI(PMBOK) или IPMA для управленцев ИТ проектов. Нужен ли?
Что такое PMI&IPMI&PMBOK?
PMI (Project Management Institute) – институт по управлению проектами, разработавший систему комплексного подхода к проектированию и организации процессов для успешной реализации проектов. Он предлагает универсальную схему построения работ при начальном планировании, предлагая, возможно даже, исчерпывающую схему этапности, учит правильно строить организационную структуру проекта и контролировать ход его выполнения.
PMBOK (Project Management Body of Knowledge) — Свод знаний по управлению проектами представляет собой сумму профессиональных знаний по управлению проектами. Руководство PMBOK фиксирует части Свода знаний по управлению проектами, которая обычно считается хорошей практикой. PMI использует этот документ в качестве основного справочного материала для своих программ по профессиональному развитию. Является Американским национальным стандартом.
IPMA — Международная Ассоциация Управления Проектами (Щвейцария) (англ. International Project Managment Organization, IPMA) — ассоциация, созданная в 1965 году и призванная объединить специалистов в области управления проектами (Project Management), а так же внедрившая собственную четерыхступенчатую систему сертификации.
В России представлена Ассоциацией Управления проектами (СОВНЕТ). Основана в 1990 году и представляет собой добровольный некомерческий союз профессионалов, осуществляющих научные исследования и разработки, обучение и сертификацию специалистов в области Управления проектами; обоснование, подготовку, выполнение и управление проектами в различных сферах деятельности.
Как Вы считаете изучение по PMBOK и сертификация PMI может пригодится человеку, который занимается Web-проектами? Насколько мне известно, подход к управлению проектами по PMBOK является базой и не имеет значение каким проектом вы будете управлять, будь это строительство объектов или ИТ проекты. Знаю нескольких человек в строительстве, которые владеют таким сертификатом и такие люди ценятся больше, чем такие же специалисты не имеющие данного сертификата — соответственно и зарплата больше.
Может кто-то из хабралюдей владеет таким сертификатом? Поделитесь информацией. Насколько данная методика полезна для управления ИТ/Веб проектами? Влияет ли наличие данного сертификата на трудоустройство и вознаграждение?
Управление проектами по PmBok
Руководство PMI PMBoK® – это стандарт для управления проектами. Данный стандарт описывает процессы управления проектами, инструменты и методы, используемые для управления проектом в целях достижения успешного результата.
PMI PMBOK был разработан и поддерживается Институтом управления проектами (PMI®, Project Management Institute) — это ведущая международная некоммерческая ассоциация профессионалов в управлении проектами, объединяющая более 200 000 членов в 125 странах. Получить степень PMP можно здесь.
Разберем свод правил по этой книге с помощью методологии Ивана Селиховкина.
ЧАСТЬ 1.СТРУКТУРА PMBOK
10 областей знаний:
Области знаний разбиты на группы и состоят из 47 процессов управления проектом, объединенных в 5 групп:
Процесс — это задача, к примеру, создать расписание.
Пример: область знаний «управление сроками» на этапах «ПЛАНИРОВАНИЕ» и «МОНИТОРИНГ»:
Исключение: процессы из областей знания «интеграция» и «управление HR»:
Примечание. Область знаний «Управление интеграцией» — в книге эта глава первая, но никогда не стоит начинать чтение книги с этой главы, потому что она абстрактна и не даем применимых знаний.
ЧАСТЬ 2.
ПРИНЦИПЫ ПРОЕКТНОГО УПРАВЛЕНИЯ
Фундаментальные принципы PMI :
Разберем каждый принцип подробнее.
1. Принцип яйца
«Скорлупа яйца» — Устав проекта, который пишется в начале проекта
«Внутреннее содержимое яйца»:
2. Принцип удава
Жизненный цикл проекта:
Начало проекта — «инициация» > Середина проекта — «цикл Деминга» > Конец проекта — «закрытие»
Если представить этапы в виде удава, то получается следующая картинка (этого в книге нет, это разработал И.Селиховкин):
3. Принцип командности и проактивности
ЧАСТЬ 3. ОБЛАСТИ ЗНАНИЙ
1. УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА
ROI-return of investment — (возврат инвестиций)
internal rate of return — (внутренняя ставка возврата)
discounted cash flow — (дисконтированный денежный поток)
net present value — (чистый дисконтированный доход)
4.1. Разработка устава проекта
Устав фиксирует цели и ограничения проекта
Должен быть неизменным
4.2. Разработка плана управления проектом
Как будем измерять выполнение планов, как закрывать проект.
4.3. Мониторинг и контроль работ проекта
Проверка хода проекта относительно всех планов: нужно сверить «план» и «факт» (укладываем в сроки?, укладываемся в бюджет? и т.п.)
4.4. Интегрированный контроль изменений
4.5. Руководство и управление работами проекта
Это координация команды, действия по планам, работа с отчета и т.п.
4.6. Закрытие фазы или проекта
Все проекты и фазы должны быть закрыты все зависимости завершился он триумфом или провалом.
2. УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА
Определить, какие работы необходимы, а потом что только они выполняются. 
5.1. Планирование управлением содержанием
Связать все планы воедино
5.2. Сбор требований
Сбор требований происходит посредством опроса заинтересонных лиц — интервью, анкеты и т.п.
5.3. Определение содержания
Делаем концепцию (техническое задание): детальное описание продукта и проекта
Определяем: что делаем и чего НЕ делаем в ходе проекта
5.4. Создание иерархической структуры работ
Разделяй и властвуй!
Перед тем как представить иерархическую структуру работ желательно представить иерархическую структуру продукта
Иерархическая структура продукта (PBS — Product Breakdown Structure):
Иерархическая структура работ (WBS — Work Breakdown Structure):
Существенным является не способ представления, а иерархичность: декомпозиция любого результата на его составляющие.
От сложного – к простому.
5.5. Контроль содержания
Если понимаем, что не учли какой-то элемент, то вносим изменения в планы
5.6. Подтверждение содержания
3. УПРАВЛЕНИЕ ВРЕМЕНЕМ (СРОКАМИ) ПРОЕКТА
Вот как это выглядит на «Карте процессов»: 
6.1. Управление расписанием
Как создать расписание и сопоставление содержания с расписанием
6.2. Определение операций
Декомпозиция технического задания в ДЕЙСТВИЯ!
Берем иерархическую структуру работ и переводим ее в «глаголы» — как добьем результата обозначенного в ИСР.
6.3. Определение последовательности операций
Перестраиваем ИСР в Сетевую диаграмму (PDM — Precedence Diagramming Method, Метод «операции в узлах» (метод предшествования).
Сетевая диаграмма проекта показывает набор операций и логику их последовательностей – кто за кем. Заметьте, что в этой диаграмме нет никаких характеристик самих операций, например, сроков или длительностей – только логика: что и в какой последовательности должно делаться в проекте. Эта диаграмма является важнейшим промежуточным шагом на пути к значимой цели – расписание проекта
6.4. Оценка ресурсов операций
Ресурсы делятся на:
6.5. Оценка длительности операций
Способ оценки по аналогии с предыдущей похожей деятельностью.
Пример такой оценки: мы уже исполняли подобные работы и по опыту знаем, что на исполнение требуется 5 дней. Или не исполняли подобного, но погуглили или опросили экспертов.
Среди аналоговых методов оценки есть один метод, который люди используют чаще всего – оценка из своего опыта. Это предполагает простой алгоритм:
опытный человек чешет затылок и сообщает: — ну, я это не раз делал, понадобится столько-то деньков.
Такой оценки имеет существенную особенность – оценки получаются заниженными, то есть оптимистичными.
Это оценка такого типа:
я не знаю, сколько понадобится времени на эту операцию, но могу сказать, что если все пойдет хорошо, то уложимся в 5 дней (оптимистичная оценка), в худшем варианте понадобится 10 дней (пессимистичная оценка), а скорее всего, потребуется 7 дней (наиболее вероятная оценка).
В результате нужно усреднить способом «оценка PERT» (PERT – Program Evaluation and Review Technique):
Ожидаемая оценка = (Оптимистичная + 4 * Наиболее вероятная + Пессимистичная) / 6
Обращаю внимание, что делим на 6 потому, что взяли 4 наиболее вероятных оценок и по одной оптимистичной и пессимистичной – всего шесть оценок.
Пример: Оценка по трем точкам.
Некоторая работа исполнялась 10 раз. Статистика длительностей:
Посчитаем разные средние значения:
Средняя (арифм) = (4 * 2 + 5 * 7 + 9 * 1) / 10 = 5,2 дней
Ожидаемая (PERT) = (4 + 4 * 5 + 9) / 6 = 5,5 дней
6.6. Разработка расписания
Используйте программное обеспечение — диаграммы Ганта и т.п.
Метод критического пути для составления расписания
Метод критического пути является основным способом расчета расписания проекта.
Операции могут иметь резервы, вызванные наличием параллельных цепочек:
Резерв (Float, Total Float, Slack) – время, на которое операция может быть задержана, без увеличения длительности проекта:
Свободный резерв (Free Float) – время, на которое операция может быть задержана, не влияя на раннее начало любой последующей операции
В прямом проходе, от начала к концу проекта, рассчитываются ранние даты операций. А в обратном проходе, от конца проекта к началу, все наоборот – рассчитываются поздние даты каждой операции.
Результатом расчета является таблица с ранними датами и резевами каждой операции:. 
Операции без резервов являются основным фокусом внимания менеджера и команды проекта:
Критический путь — все работы, у которых нет резервов. Критический путь определяет длительность проекта.
6.7. Контроль расписания
Делаем прогнозы отклонений и отслеживаем укладываемся ли в в график.
4. УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА
7.1. Планирование управлением стоимостью
Как будем держать под контролем наш план
7.2. Оценка стоимости
Считаем себестоимость на основе временных зарат.
Стоимость проекта = стоимость всех работ проекта
Стоимость работы = стоимость израсходованных ресурсов.
Стоимость проекта = Сумма стоимостей израсходованных ресурсов.
7.3. Определение бюджета
Бюджет проекта – это распределение стоимости проекта по времени.
Базовый план стоимости (cost baseline)= себестоимость работ + резервы работ + резервы пакетов работ
Бюджет проекта (project budget) = Базовый план стоимости + управленческие резервы
Управленческие резервы — это деньги, который спонсор проекта отложил на «всякий случай»
«План по стоимости» — это бюджет проекта.
Стоимости делят на две важные группы:
«Резерв управления» – это превышение бюджета, вызванное выявленными рисками.
7.4. Контроль стоимости
Собираем все вместе и контролируем календарный план проекта (MS Project):
7. УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ
Заинтересованные стороны проекта – это лица и организации, например заказчики, спонсоры, исполняющая организация и общественность, которые активно участвуют в проекте, или интересы которых могут быть затронуты как положительно, так и отрицательно в ходе исполнения или в результате завершения проекта. Они также могут оказывать влияние на проект или на его результаты. Заинтересованные стороны проекта могут находиться на различных уровнях внутри организации и иметь разные уровни полномочий либо могут являться внешними по отношению к исполняющей организации проекта.
В процессе планирования коммуникаций определяются информация и взаимодействия, необходимые заинтересованным сторонам проекта, например: каким лицам какая информация нужна, когда она им понадобится, кто и каким образом должен им эту информацию предоставить.
Это процесс предоставления необходимой информации заинтересованным сторонам проекта в соответствии с планом.
Это процесс общения и работы с заинтересованными сторонами проекта для удовлетворения их потребностей и решения возникающих проблем.
Это процесс сбора и распространения информации об исполнении, включая отчеты о состоянии, результаты измерения исполнения и прогнозы. Процесс подготовки отчетов об исполнении включает периодический сбор фактических данных и их сопоставление с базовым планом для оценки продвижения проекта и его исполнения, передачи данной информации, а также прогнозирования результатов проекта.