Процессы Проектного менеджмента по областям знаний

В любом проекте есть пять фаз: Инициация, Планирование, Исполнение, Контроль и мониторинг, Закрытие; фазы эти не строго последовательны, а в той или иной степени налагаются друг на друга, смотря от подхода к исполнению проекта (Plan-driven или какой-либо вариант Change-driven подхода).

Также, любой проект предполагает наличие десяти областей знаний: Интеграция, Содержание, Расписание, Бюджет, Качество, Ресурсы, Коммуникации, Риски, Закупки, Заинтересованные стороны. Каждая из областей знаний в той или иной степени прорабатывается в каждой фазе проекта.

Проекция областей знаний на фазы - этот процессы проектного менеджмента, их 49 в последней редакции PMBoK. Рассмотрим.
Инициация.

1. Управление интеграцией
• (I-01) Разработка Устава проекта
• Входы: Бизнес-кейс, План управления выгодами, Реестр предположений, Соглашения и контракты
• Выходы: Устав проекта
2. Управление содержанием
3. Управление расписанием
4. Управление бюджетом
5. Управление качеством
6. Управление ресурсами
7. Управление коммуникациями
8. Управление рисками
9. Управление закупками
10. Управление заинтересованными сторонами
• (I-02) Выявление заинтересованных сторон
• Входы: Устав проекта, Закупочная документация, Факторы среды компании, Процессные активы компании
• Выходы: Реестр заинтересованных сторон

Планирование.

1. Управление интеграцией
• (P-03) Разработка Плана управления проектом
• Входы: Бизнес-кейс, Соглашения, Факторы среды компании, Процессные активы компании
2. Управление содержанием
• (P-04) Планирование управления содержанием
• Входы: Устав проекта, Жизненный цикл проекта, Процессные активы компании, Реестр вынесенных уроков
• Выходы: План управления содержанием, План управления требованиями
• (P-05) Сбор требований
• Входы: Устав проекта, Реестр предположений, Реестр заинтересованных сторон, Соглашения, Процессные активы компании
• Выходы: Документация на требования, Матрица трассировки требований
• (P-06) Определение содержания
• Входы: Устав проекта, План управления содержанием, Документация на требования, Реестр рисков
• Выходы: Описание содержания проекта, Обновления проектной документации
• (P-07) Разработка ИСР
• Входы: План управления содержанием, Описание содержания проекта, Документация на требования, Факторы среды компании, Процессные активы компании
• Выходы: ИСР, Словарь ИСР
3. Управление расписанием
• (P-08) Планирование управления расписанием
• Входы: План управления проектом, Устав проекта, Факторы среды компании, Процессные активы компании
• Выходы: План управления расписанием
• (P-09) Определение активностей
• Входы: План управления расписанием, Базовые значения содержания, Запросы на изменения, Факторы среды компании, Процессные активы компании
• Выходы: Список активностей (с их атрибутами), Список вех проекта
• (P-10) Упорядочивание активностей
• Входы: Реестр предположений, Список активностей (с их атрибутами), Список вех проекта, Описание содержания проекта, Факторы среды компании, Процессные активы компании
• Выходы: Сетевая диаграмма, Обновления Списка активностей (с их атрибутами), Обновления Списка вех проекта, Обновления Реестра предположений, Обновления Реестра рисков
• (P-11) Оценка продолжительности активностей
• Входы: План управления расписанием, Список активностей (с их атрибутами), Требования к ресурсам, Ресурсные календари, Описание содержания проекта, Реестр рисков, Иерархическая структура ресурсов, Факторы среды компании, Процессные активы компании
• Выходы: Оценки продолжительности активностей, Базис оценок, Резервы расписания, Обновление списка активностей или их атрибутов, Обновление реестра предположений, Обновление реестра вынесенных уроков
• (P-12) Разработка расписания
• Входы: План управления расписанием, Список активностей (с их атрибутами), Оценка продолжительности активностей, Список вех, Сетевая диаграмма, Требования к ресурсам, Ресурсные календари, Описание содержания, Реестр рисков, Назначение ресурсов, Иерархическая структура ресурсов, Реестр предположений, Реестр рисков, Реестр вынесенных уроков, Факторы среды компании, Процессные активы компании
• Выходы: Расписание проекта, Базовые значения расписания, Запросы на изменения, Обновления проектной документации
4. Управление бюджетом
• (P-13) Планирование управления бюджетом
• Входы: Устав проекта, План управления проектом, Факторы среды компании, Процессные активы компании
• Выходы: План управления бюджетом
• (P-14) Оценка затрат
• Входы: План управления бюджетом, План управления качеством, Базовые значения содержания, Реестр вынесенных уроков, Расписание проекта, Требования к ресурсам, Реестр рисков, Факторы среды компании, Процессные активы компании
• Выходы: Оценка стоимости активностей, Базис оценок, Резервы бюджета, Обновление списка активностей или их атрибутов, Обновление реестра предположений, Обновление реестра вынесенных уроков
• (P-15) Определение бюджета
• Входы: План управления бюджетом, Базовый план по содержанию, Оценка стоимости активностей, Базис для оценок, Расписание проекта, Календари ресурсов, Соглашения, Реестр рисков, Процессные активы компании
• Выходы: Базовый план бюджета
5. Управление качеством
• (P-16) Планирование управления качеством
• Входы: Устав проекта, Реестр предположений, Реестр заинтересованных сторон, План вовлечения заинтересованных сторон, Реестр рисков, Документация на требования, Матрица трассировки требований
• Выходы: План управления качеством, Метрики качества, Обновления плана управления проектом, Обновления проектной документации
6. Управление ресурсами
• (P-17) Планирование управления ресурсами
• Входы: Устав проекта, План управления проектом, Расписание проекта, Реестр рисков, Реестр заинтересованных сторон, Факторы среды компании, Процессные активы компании
• Выходы: План управления ресурсами, Реестр предположений, Реестр рисков
• (P-18) Оценка активностей ресурсов
• Входы: Базовый план по содержанию, Список активностей (с их атрибутами), План управления ресурсами, Ресурсные календари, Реестр рисков, Процессные активы компании
• Выходы: Иерархическая структура ресурсов, Назначение ресурсов на активности проекта
7. Управление коммуникациями
• (P-19) Планирование управления коммуникациями
• Входы: План управления проектом, Реестр заинтересованных сторон, Факторы среды компании, Процессные активы компании
• Выходы: План управления коммуникациями
8. Управление рисками
• (P-20) Планирование управления рисками
• Входы: Устав проекта, План управления проектом, Реестр заинтересованных сторон, Факторы среды компании, Процессные активы компании
• Выходы: План управления рисками
• (P-21) Выявление рисков
• Входы: План управления требованиями, План управления расписанием, План управления затратами, План управления ресурсами, План управления рисками, План управления качеством, Факторы среды компании, Процессные активы компании
• Выходы: Реестр рисков, Отчет по рискам
• (P-22) Проведение качественного анализа рисков
• Входы: Реестр заинтересованных сторон, Реестр предположений, Реестр рисков, Прогнозы бюджета, Прогнозы расписания, Список вех проекта, Факторы среды компании, Процессные активы компании
• Выходы: Обновления Реестра рисков, Реестр проблем
• (P-23) Проведение количественного анализа рисков
• Входы: План управления проектом, Базовые значения содержания, Базовые значения расписания, Базовые значения бюджета, Реестр предположений, Требования к ресурсам, Реестр рисков, Отчет по рискам, Факторы среды компании, Процессные активы компании
• Выходы: Обновления Реестра рисков, Резервы времени и бюджета, Оцифрованная вероятность достижения целей проекта, Рекомендованные ответы на риски
• (P-24) Планирование реагирования на риски
• Входы: Реестр рисков, Реестр заинтересованных сторон, Реестр вынесенных уроков, Календарь ресурсов, Отчет по рискам, Расписание проекта, Назначения ресурсов на активности проекта
• Выходы: Обновления Плана управления проектом, Реестр предположений, Прогноз бюджета, Реестр вынесенных уроков, Обновление расписания проекта, Назначения ресурсов на активности проекта, Реестр рисков, Отчет по рискам
9. Управление закупками
• (P-25) Планирование управления закупками
• Входы: Устав проекта, Бизнес-Кейс, План управления выгодами, Назначения ресурсов на активности проекта, Документация по требованиям, Требования к ресурсам, Реестр рисков, Реестр стейкхолдеров, Факторы среды компании, Предварительно согласованный список поставщиков
• Выходы: План управления закупками, Закупочная документация, Критерии выбора поставщика, Решения "производить или покупать", Критерии выбора поставщика, Запросы на изменения, Обновления проектной документации
10. Управление заинтересованными сторонами
• (P-26) Планирование вовлечения заинтересованных сторон
• Входы: План управления ресурсами, План управления коммуникациями, Реестр заинтересованных сторон, Процессные активы компании, Факторы среды компании
• Выходы: План управления заинтересованными сторонами

Исполнение.

1. Управление интеграцией
• (E-27) Ведение и управление проектной работой
• Входы: План управления проектом, Одобренные изменения, Факторы среды компании, Процессные активы компании
• Выходы: Поставки продуктов, Данные по перфомансу работ, Реестр проблем, Результаты имплементации одобренных запросов на изменения, Новые запросы на изменения, Обновления Плана управления проектом и проектной документации
• (E-28) Управление знаниями проекта
• Входы: План управления проектом
• Выходы:
2. Управление содержанием
3. Управление расписанием
4. Управление бюджетом
5. Управление качеством
• (E-29) Управление качеством
• Входы: План управления качеством, Метрики качества, Результаты измерения в ходе Контроля качества
• Выходы: Документация по тестированию и приемке, Отчеты по качеству, Запросы на изменения, Обновления Плана управления проектом, Обновления Проектной документации, Обновления Процессных активов компании
6. Управление ресурсами
• (E-30) Приобретение ресурсов
• Входы: План управления ресурсами, Расписание проекта, Бюджет проекта
• Выходы: Назначение ресурсов на активности проекта, Ресурсные календари, Обновления Плана управления проектом
• (E-31) Развитие команды
• Входы: План управления ресурсами, Назначения ресурсов на активности проекта, Ресурсные календари
• Выходы: Оценки персонала
• (E-32) Управление командой
• Входы: План управления ресурсами, Назначения ресурсов на активности проекта, Оценки персонала, Реестр проблем, Отчеты об исполнении работ, Процессные активы компании
• Выходы: Запросы на изменения, Обновления Плана управления проектом, Обновления проектной документации
7. Управление коммуникациями
• (E-33) Управление коммуникациями
• Входы: План управления коммуникациями, План управления ресурсами, План управления заинтересованными сторонами, Отчеты об исполнении работ
• Выходы: Обновления Плана управления проектом, Обновления проектной документации, Обновления процессных активов компании
8. Управление рисками
• (E-34) Имплементация реагирования на риски
• Входы: План управления рисками
• Выходы: Отчет по рискам, Реестр рисков, Реестр вынесенных уроков, Реестр проблем
9. Управление закупками
• (E-35) Проведение закупок
• Входы: План управления закупками, Закупочная документация, Критерии выбора поставщиков, Коммерческие предложения, Проектная документация, ТЗ на работы, Процессные активы компании
• Выходы: Выбранные поставщики, Запросы на изменения, Обновления Плана управления проектом, Обновления проектной документации
10. Управление заинтересованными сторонами
• (E-36) Управление вовлечением заинтересованных сторон
• Входы: План управления заинтересованными сторонами, План управления проектом, Реестр заинтересованных сторон, Реестр проблем, Реестр изменений, План управления коммуникациями
• Выходы: Обновления содержания, Обновления Плана управления заинтересованными сторонами, Обновления Плана управления коммуникациями, Обновления Реестра изменений, Обновления Реестра заинтересованных сторон, Обновления Реестра проблем, Обновления Реестра вынесенных уроков

Контроль и мониторинг.

1. Управление интеграцией
• (M&C-37) Контроль и мониторинг проектной работы
• (M&C-38) Проведение интегрированного контроля изменений
• Входы: План управления проектом, Отчетность по перфомансу работ, Запросы на изменения, Факторы среды компании, Процессные активы компании
• Выходы: Одобренные запросы на изменения, Реестр изменений, Обновления Плана управления проектом, Обновления проектной документации
2. Управление содержанием
• (M&C-39) Валидация содержания
• Входы: Продукты проекта (после проведения процесса Контроля качества), План управления содержанием, Базовый план по содержанию, План управления требованиями, Документация на требования, Матрица трассировки требований, Отчеты по качеству, Реестр вынесенных уроков, Данные об исполнении работ
• Выходы: Информация об исполнении работ, Запросы на изменения, Обновления плана управления проектом, Обновления проектной документации, Обновления процессных активов компании 
• (M&C-40) Контроль содержания
• Входы: План управления проектом, Документация на требования, Матрица трассировки требований, Данные об исполнении работ, Процессные активы компании
• Выходы: Информация об исполнении работ, Запросы на изменения, Обновления Плана управления проектом, Обновления проектной документации, Обновления Процессных активов компании
3. Управление расписанием
• (M&C-41) Контроль расписания
• Входы: План управления проектом, Расписание проекта, Данные об исполнении работ
• Выходы: Данные по исполнению работ, Прогнозы расписания, Запросы на изменения, Обновления Плана управления проектом, Изменения базовых значений, Обновления Реестра предположений, Обновления Реестра рисков, Обновления Реестра вынесенных уроков
4. Управление бюджетом
• (M&C-42) Контроль бюджета
• Входы: План управления проектом, Данные об исполнении работ, Процессные активы компании
• Выходы: Информация об исполнении работ, Прогнозы стоимости, Запросы на изменения, Обновления плана управления проектом, Обновления проектной документации, Обновления Процессных активов компании 
5. Управление качеством
• (M&C-43) Контроль качества
• Входы: План управления качеством, Метрики качества, Документация по тестированию и приемке, Данные по исполнению работ и поставок, Одобренные запросы на изменения, Обновления проектной документации
• Выходы: Данные измерений, Подтвержденные запросы на изменения, Информация по исполнению работ, Обновления Плана управления проектом, Обновления Проектной документации
6. Управление ресурсами
• (M&C-44) Контроль ресурсов
• Входы: Соглашения, Данные об исполнении работ, Реестр проблем, Реестр рисков, Реестр вынесенных уроков, Назначения ресурсов на активности проекта, Расписание проекта, Требования к ресурсам, Иерархическая структура ресурсов
• Выходы: Данные по исполнению работ, Обновления Плана управления проектом, Обновления проектной документации
7. Управление коммуникациями
• (M&C-45) Мониторинг коммуникаций
• Входы: План управления проектом, Коммуникации проекта, Данные об исполнении работ, Реестр проблем, Процессные активы компании
• Выходы: Информация об исполнении работ, Запросы на изменения, Обновления Плана управления проектом, Обновления проектной документации
8. Управление рисками
• (M&C-46) Мониторинг рисков
• Входы: План управления проектом, Реестр рисков, Данные об исполнении работ, Отчеты об исполнении работ
• Выходы: Отчет по рискам, Информация об исполнении работ, Обновления Реестра рисков, Запросы на изменения, Обновления Плана управления проектом, Обновления Процессных активов компании
9. Управление закупками
• (M&C-47) Контроль закупок
• Входы: План управления проектом, Документация на требования, Отчеты по качеству, Данные об исполнении работ, Соглашения, Одобренные запросы на изменения
• Выходы: Запросы на изменения, Обновления проектной документации, Закрытие контрактов
10. Управление заинтересованными сторонами
• (M&C-48) Мониторинг вовлеченности заинтересованных сторон
• Входы: План управления ресурсами, План управления коммуникациями, План управления заинтересованными сторонами, Реестр рисков, Реестр проблем, Реестр вынесенных уроков
• Выходы: Данные по исполнению работ, Обновления Плана управления проектом, Обновления Реестра заинтересованных сторон, Обновления Реестра рисков, Обновления Реестра вынесенных уроков

Закрытие.

1. Управление интеграцией
• (C-49) Закрытие проекта или фазы
• Входы: Данные об исполнении работ, Отчеты по проекту, Информация по коммуникациям, Обновления в ходе проекта в части Устава, Бизнес-кейса, Плана выгод, Плана управления проектом, Продукта, Реестра вынесенных уроков, Отчета по рискам, Реестра рисков, Соглашений, и закупочной документации
• Выходы:
2. Управление содержанием
3. Управление расписанием
4. Управление бюджетом
5. Управление качеством
6. Управление ресурсами
7. Управление коммуникациями
8. Управление рисками
9. Управление закупками
10. Управление заинтересованными сторонами

Процесс Мониторинга вовлечения заинтересованных сторон

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

1. План управления ресурсами (все участники команды это также заинтересованные стороны)
2. План управления коммуникациями
3. План управления заинтересованными сторонами
4. Реестр проблем, по части проблем в интересах, несогласиях, непонимании и нерешенных вопросах - это как раз дает прямую информацию о вовлечении заинтересованных сторон
5. Реестр вынесенных уроков
6. Реестр рисков (важно что это именно вход - поскольку недостаток вовлечения заинтересованных сторон это крайне серьезный риск проекта, им нужно управлять)

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

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

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

Мониторинг вовлеченности заинтересованных сторон выливается в:

1. Данные по исполнению работ
2. вероятные обновления Плана управления проектом и проектной документации, как то Реестр проблем, Реестр заинтересованных сторон, Реестр рисков, и Реестр вынесенных уроков

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

Процесс Планирования вовлечения заинтересованных сторон

Управление вкладом, отношениями, и вовлечением заинтересованных сторон крайне важно для успеха проекта, но может занимать много времени. Так что тут особенно важно заранее все продумать.
Заинтересованные стороны могут быть как активом, так и проблемой проекта. Для эффективного управления отношениями со многими людьми, важно проработать план их вовлечения. Нужно думать о заинтересованных сторонах заранее, нужно понимать как команда проекта будет с ними работать, как мы будем привлекать их к принятию решений, как будем управлять их ожиданиями и сделаем их довольными. В общем, как мы сделаем их активом проекта.
По вовлечению заинтересованных сторон должна быть стратегия и конкретные планы. То есть, мы должны зарезервировать время на выявление заинтересованных сторон, и проверку их в течение всего проекта. Если у вас сотни заинтересованных сторон по всему миру - то без плана вам уж точно не обойтись. Да, с каждым отношения не поддержишь, но с ключевыми - можно. Нельзя забывать и о заинтересованных сторонах за пределами команды.
Помним, что чем ближе мы с заинтересованными сторонами, тем легче они проникаются нашими интересами, и тем проще вам в общении с ними понять, что что-то идет не так. Это - система раннего предупреждения проблем! И единственный способ такое построить, это проводить с заинтересованными сторонами больше времени.
Характеристики хороших отношений с заинтересованными сторонами: доверие, честность, открытые коммуникации, искренность, уважение, эмпатия.
Во время планирования вовлечения, определяем, какие из заинтересованных сторон более всего нуждаются в вашем внимании и усилиях. Для этого нужно понимать роль каждого, среду в которой он работает, и специфические потребности проекта. Если предполагаются закупки, то нужно подумать и о вовлечении применительно к контрактации.
Входами для планирования вовлечения заинтересованных сторон будут:

1. План управления ресурсами
2. План управления коммуникациями
3. Реестр заинтересованных сторон
4. Любая релевантная информация с прошлых проектов

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

Входы в процесс Контроля закупок

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

1. Список вех, и базовые значения по бюджету, расписанию, и содержанию, чтобы проверять, что проект идет как запланировано
2. Сверяясь с документацией по требованиям, мы понимаем, что сделали то, что необходимо
3. Отчеты по качеству показывают, что исполненная работа соответствует метрикам
4. Данные об исполнении работ в процессе Ведения и управления проектной работой дают РМ информацию по затратам и статусу проектных активностей, и используются для оценки перфоманса поставщика

Помним, что контроль и мониторинг повторяется в течение всего проекта. РМ постоянно измеряет прогресс проекта, сравнивая его с контрактом, закупочной документацией, и планом управления. Это можно делать многими способами, далее мы все их рассмотрим. Если возникают отклонения, то они анализируются, и возможно управляются через интегрированный контроль изменений. Одобренные изменения включаются в план управления, либо в контракт. С изменениями контракта работаем через систему управления договорами компании. Все изменения контрактов должны быть формальны.
Иногда, вопросы экзамена проверяют особенности работы в среде закупок. Например:

1. у компании поставщика - совершенно иная культура и иные процедуры, нежели у компании покупателя
2. у поставщика и покупателя разные цели. Цель поставщика заработать денег, цель покупателя, получить исполненную работу
3. сложно понимать проблемы проектов, когда контрактная работа исполняется в разных локациях
4. для определения проблем, нужно много работать с отчетностью, и информация в них должна быть достоверной
5. между РМ поставщика и покупателя должно быть большое доверие, чтобы хорошо решать те проблемы, что не покрыты буквой договора

Процесс Проведения закупок

Процесс Проведения закупок включает:

1. передачу закупочных документов, включая ТЗ и иные доки, разработанные при Планировании управления закупками, потенциальным поставщикам
2. ответы на вопросы поставщиков
3. получение ответов поставщиков и их обработку
4. выбор конкретного поставщика по критериям подбора, указанным в плане управления закупками
5. переговоры по заключению контракта

РМ и команда используют как входы много ранее подготовленных документов по этому процессу:

1. план управления закупками дает направление, как работу по закупкам исполнять
2. иные планы говорят, как будет делаться работа по проекту, включая, какие работы мы отдадим на сторону
3. также базовые значения затрат дают понять, каков наш бюджет на закупку
4. расписание дает даты исполнения закупок
5. собственно закупочная документация

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

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

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

Бизнес-документация. Это:

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

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

Проектная документация. Как минимум смотрим список вех, матрицу требований, расписание; а также полезно:

1. Назначения ресурсов на активности проекта, так мы понимаем, кто из команды помогает с закупками. Если никто не умеет в закупки, то вероятно потребуется тренинг, либо привлечение внешних ресурсов
2. Документация по требованиям, это позволит нам понять конечный продукт, услугу, либо результат, нужный от поставщика. Также эта документация может включать требования по комплаенсу, безопасности, коммуникациям, практикам проектного менеджмента, отчетности, качеству, и управлению рисками, что оказывает влияние на закупки
3. Требования к ресурсам. Это навыки, количество, и требования к типам ресурсов проекта. Если нужные материалы сервисы, продукты, сотрудники не могут быть найдены в компании, их надо закупить
4. Реестр рисков. Дает понимание выявленных на момент индивидуальных рисков проекта и общего риска, а также тех ответов на риски, что потребуют закупок. Помним, что анализ рисков нужно проводить до подписания контрактов
5. Реестр стейкхолдеров. Помогает выявить тех, на кого влияет процесс закупок, а также тех кто  него будет вовлечен или будет определять его путь, например менеджеров по закупкам, гос.регуляторов, или юристов

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

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

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

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

1. стремимся уменьшить угрозы до их возникновения
2. стремимся раскрыть возможности
3. уменьшаем вероятность и импакт угроз
4. увеличиваем вероятность и импакт возможностей
5. планируем, что делать, если риск случится - планы на чрезвычайные ситуации
6. планируем, что делать, если планы из п.5 окажутся неэффективными (запасные планы)

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

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

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

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

Входы в процесс Проведения количественного анализа рисков

Входы включают:

1. План управления проектом
2. Базовые значения расписания
3. Базовые значения бюджета
4. Базовые значения содержания
5. Реестр предположений
6. Оценки и прогнозы проекта
7. Реестр рисков
8. Отчет по рискам

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

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

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

• Устав проекта. Определяет высокоуровневые риски, и помогает понять, рискованны ли общие цели и ограничения проекта. Также можно понять риски того, что  проект не включено (да, это тоже косвенно может повлиять)
• План управления проектом.
• Планирование управления рисками. План управления проектом включает: планы по управлению каждой областью знаний; дополнительные планы по конфигурациям, изменениям, требованиям; базовые значения содержания, бюджета, сроков; подход к жизненному циклу проекта; принципы измерения перфоманса. Во всем это могут быт свои риски!
• Выявление рисков. Используются:
• план управления требованиями - список требований проекта, помимо самих требований, сдержит также и потенциальные проблемы и возможности
• план управления расписанием - агрессивное расписание может быть источником риска, а предположения, связанные с расписанием, могут показывать степень неопределенности
• план управления затратами - детализирует процесс бюджетирования и предположения, связанные с неопределенностью
• план управления ресурсами - показывает, какие ресурсы нужны и когда должны быть доступны, и рассказывает, как они должны управляться. Так можно предвидеть риски, связанные с ресурсами
• план управления рисками - определяет подход к управлению рисками
• план управления качеством - требования и предположения этого плана, а также требования к точности измерений, помогают понять риски
• Выявление рисков, количественный анализ рисков. Используются:
• базовые значения по содержанию - помогают понять, насколько сложен проект, и какие вообще усилия требуются для управления рисками. Базовые значения включают границы проекта, критерии приемки, ограничения и предположения, которые показывают риски проекта
• базовые значения по расписанию - используем для определения дат, которые могут быть недостигнуты. Ограничения расписания, зависимости между задачами, отсутствие ясности вех - это индикаторы риска
• базовые значения бюджета - помогают найти какие-то значения затрат, которые не полностью определены. Ограничения по бюджету, при условии неопределенности затрат, это индикаторы риска. Величина резерва на непредвиденные обстоятельства это иной входной параметр
• Проектная документация.
• Планирование управления рисками, Выявление рисков, Проведение качественного анализа рисков, Планирование реагирования на риски - Реестр заинтересованных сторон. Показывает проект с различных перспектив, тем самым показывает риски, которые команда не видит
• Выявление рисков, Планирование реагирования на риски, Реагирование на риски, Мониторинг рисков - Реестр вынесенных уроков. Дает информацию, что сработало, а что нет на это и прошлых проектах. Также он показывает повторение рисков на идентичных ошибках, и все потенциальные возможности
• Выявление рисков, Проведение качественного анализа рисков, Проведение количественного анализа рисков - Реестр предположений. Ревью этого реестра помогает нам понять риски проекта
• Выявление рисков, Проведение количественного анализа рисков - базовые оценки бюджета и продолжительности помогают понять, рисково ли их достижение
• Выявление рисков - документация на требования. Помогает понять плохо определенные требования, которые являются источником рисков проекта
• Выявление рисков, Проведение количественного анализа рисков - требования к ресурсам. Они должны содержать какие-то количественные метрики, показывающие уровень рисков
• Планирование реагирования на риски - календарь ресурсов. Показывает, когда ресурсы должны быть доступны, и так позволяет прогнозировать риски
• Проведение качественного анализа рисков, Проведение количественного анализа рисков, Планирование реагирования на риски, Реагирование на риски, Мониторинг рисков - реестр рисков. Это репозитарий выявленных рисков проекта; это важный фактор приоритезации и анализа рисков, планирования и имплементации реагирования на риски, и их мониторинга
• Проведение количественного анализа рисков, Планирование реагирования на риски, Реагирование на риски, Мониторинг рисков - Отчет по рискам. Готовится регулярно в течение проекта, включает стратегию об общем риске проекта, стратегиях реагирования на риски, типах риска, трендах рисков, метриках и источниках рисков. Анализ этой информации помогает понять, какие риски дают максимальный импакт на показатели рисков проекта
• Проведение качественного анализа рисков:
• прогнозы по бюджету и расписанию - дают информацию, реалистичны ли бюджет и расписание
• список вех - это ключевые события, которые случатся на проекте; с его помощью можно понять, реалистично ли расписание проекта
• Планирование реагирования на риски:
• расписание проекта - используется для предсказания, как реагировать на риски в пределах активностей проекта
• назначения команды проекта - не согласованные назначения могут провоцировать риски
• Факторы среды компании.
• Планирование управления рисками, Выявление рисков, Проведение количественного анализа рисков, Проведение качественного анализа рисков, Планирование реагирования на риски. Знание уровня риска, который компания готова принять, а также специфичных областей этого риска, помогает определить импакт риска, проранжировать риски, и понять, какие стратегии по работе с рисками нужно использовать. Культура компании может добавить или снизить риски, и это нужно учесть в работе с ними
• Процессные активы компании.
• Планирование управления рисками, Выявление рисков, Проведение качественного анализа рисков, Проведение количественного анализа рисков, Планирование реагирования на риски, Реагирование на риски - это все может информировать вас о рисках с прошлых проектов, включая категории рисков, форматы рисков, варианты реагирования на риски.
• Соглашения по выявлению рисков - могут информировать вас об угрозах или возможностях
• Документация по закупкам.
• Выявление рисков - документация отвечает на вопросы: Сколько контрактов на проекте? Какой уровень экспертизы требуется от каждого? Поучаствовал ли РМ в контрактации? Контракты как помогают переложить риск на поставщика, так и могут способствовать большему нашему риску
• Данные и отчеты по исполнению работ.
• Мониторинг рисков - дают проанализированные результаты множества контролирующих процессов, в формате, который может быть использован для переоценки, анализа факта, либо трендов, либо отклонений

Также, косвенно с планом управления рисками связано:

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

Процесс Мониторинга коммуникаций

В ходе Мониторинга, РМ и команда проверяют, как идут коммуникации по проекту, и передается ли информация как планировалось - правильным путем, правильным людям, и вовремя - чтобы все были информированы, и поддерживалась вовлеченность. План управления коммуникациями дает показатели для измерения их эффективности и скорости.
Нужно понимать, следуем ли мы Плану управления коммуникациями, и удовлетворяет ли он потребностям бизнеса. Если нет, то нужно выяснить пробелы, и исправить их. Помимо использования метрик, в этом процессе полезно применить и soft skills. Многие проблемы тут очевидны глазом, получить обратную связь от участников проекта как правило тоже несложно.
Использование проектной документации для мониторинга коммуникаций:

1. План управления проектом - нужен, чтобы было с чем сравнить факт, и понять к чему стремиться. Конкретно план управления коммуникациями, в составе общего плана проекта, показывает, как, когда, с кем и как часто обмениваться информацией
2. Факт управления коммуникациями - сравниваем с планом, смотрим, получили ли мы запланированный результат
3. Реестр проблем - используется для сбора негатива, как то путаницы, несогласия, конфликты, вопросы к обсуждению. Это очень хороший инструмент коммуникации по проблемам, поскольку позволяет работать с ними скорее проактивно, нежели реактивно, предотвращая тем самым проблемы и запросы на изменения
4. Реестр вынесенных уроков - это вклад скорее в коммуникации будущих проектов, нежели текущего, но крайне полезный
5. Данные по исполнению работ - это сырые коммуникации, по сабжу "что произошло на проекте". С их помощью возможно измерить эффективность коммуникаций против плана
6. Факторы среды компании - в любом случае на проекте нужно учитывать культуру компании, сложившиеся инструменты общения, и прочие практики
7. Процессные активы компании - это устоявшиеся процедуры, форматы отчетов, инструменты и политики безопасности; план коммуникаций на проекте должен все это учитывать

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

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

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

По ходу проекта, информация о нем нужна многим заинтересованным сторонам. Коммуникационные нужды определяются при планировании, и документируюся в План  управления коммуникациями. Далее, эти потребности исполняются в процессе Управления коммуникациями, через распространение коммуникационных артефактов, типа отчетов, графиков, и имейлов, а также через митинги.
Планы управления ресурсами, коммуникациями, и заинтересованными сторонами документируют коммуникационные потребности. Также, управление качеством и рисками генерит отчеты, которые распространяются через План управления коммуникациями.
Процесс Управления коммуникациями также включает проверку того, что проектная информация движется в соответствии с планом. Он повышает эффективность коммуникаций, и насаживает гибкие подходы в управление коммуникациями. Управление коммуникациями также предполагает возможность заинтересованным сторонам запросить дополнительную информацию и пояснения. Важно, что отчеты по проекту, и иная информация, должны архивироваться как часть исторических записей проекта.
Блокировки коммуникаций. Они могут варьироваться от культурных различий до ошибок в сообщениях. На экзамене обычно есть пара вопросов, типа "Что могло произойти со следующими коммуникациями", или "Случилось следующее; что делать?!". Правильный ответ может быть:

1. шумное окружение
2. дистанция между собеседниками
3. неверное понимание сообщений
4. язык
5. культура

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

Для управления коммуникациями, используются следующие инструменты и техники.
Коммуникационные и межличностные навыки. Хотя РМ и должен следовать плану, в его же ответственности быть гибким и адаптивным, вносить в него корректировки, если таковые выглядят необходимыми по итогам работы с заинтересованными сторонами. Также, всегда важно иметь ввиду культурные и организационные различия, которые не всегда могут быть прописаны в плане. РМ в первую очередь должен стремиться уменьшить конфликты, а не цепляться за документацию (что не уменьшает ее важность, но во всем надо искать баланс).
Собрания. Очень часто, собрания - это ключевой элемент коммуникаций. Помним следующие правила проведения митингов:

1. устанавливаем лимит времени, и придерживаемся его
2. адженду создаем с участием команды, рассылаем заранее, придерживаемся
3. даем всем участникам понять их ответственности заранее
4. собираем вместе правильных людей
5. модерируем митинг в соответствии с правилами
6. по итогам договоренностей, назначаем ответственных и даты разрешения
7. документируем и рассылаем протокол

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

1. отчеты дают информацию с уровнем детальности, запрошенным заинтересованными сторонами
2. отчеты соответствуют нуждам проекта
3. для рассылки информации используется наиболее подходящий метод
4. отчеты включают измерение перфоманса против базовых значений из плана управления проектом. На экзамене, всегда предполагаем, что у РМ есть эта информация, и она будет рассылаться заинтересованным сторонам
5. отчеты правдивы и не скрывают реального положения дел. Это вроде как очевидно, но поскольку в мире случались скандалы у серьезных корпораций по теме, ждем несколько провоцирующих вопросов
6. отчитываться нужно по бюджету, расписанию, содержанию и качеству! (не только по расписанию)
7. отчеты помогают участникам команды понять, нужны ли им корректирующие действия
8. отчетность по исполнению включает и провижены на будущее. Используя прогнозы, спонсор и команда могут выработать превентивные действия
9. обратная связь от получателей отчетности должна анализироваться, чтобы будущие коммуникации лучше соответствовали потребностям заинтересованных сторон

В проектном менеджменте определено несколько типов отчетов. На экзамене, думаем в терминах большого проекта, и имеем ввиду, что РМ может выпускать следующие типы отчетов:

1. Статус-репорт. Показывает, где проект сейчас, против базовых значений
2. Отчет по прогрессу. Показывает, что было сделано
3. Отчет по трендам. Показывает, прогресс улучшается, либо становится хуже
4. Прогнозный отчет. Показывает будущий статус и перфоманс проекта
5. Отчет по освоенным объемам. Интегрирует управление бюджетом, содержанием и расписанием в части прогресса проекта
6. Документация вынесенных уроков

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

1. Отчеты по исполнению, статус-репорты, презентации, и т.д.
2. Обновления Плана управления коммуникациями в соответствии с эволюцией подхода к проекту
3. Обновления Плана вовлечения заинтересованных сторон
4. Обновления Реестра заинтересованных сторон, в соответствии с изменением их требований к коммуникациям, или стратегии проекта по удовлетворению им
5. Реестр проблем, дополняется возникшими проблемами с коммуникациями
6. Реестр вынесенных уроков
7. Расписание проекта может быть изменено, если возникнет необходимость внедрения серьезных изменений в план управления коммуникациями.

Модели коммуникаций

Мы часто не думаем о коммуникациях - просто шлем письмо, и ожидаем, что его получат вовремя и поймут правильно. В самом простом случае, нужно контролировать прочтение письма; но отличные проектные коммуникации еще более структурны. Комплексная коммуникационная модель включает три составляющие: отправитель, получатель, и понимание того, что послание корректно воспринято. Получатель подтверждает, что увидел, а ответственность за корректную интерпретацию сообщения несут обе стороны.
На восприятие получателем сообщения может влиять настроение, предвзятось, отсутствие интереса; коммуникационные теории зовут все это "шумом".
Эффективные коммуникации. Отправитель определяет метод коммуникаций, правильно формулирует сообщение, и потом проверяет, что оно верно понято. Нужно учитывать факторы:

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

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

Проектные документы для Контроля ресурсов

Принцип контроля определяется в следующих документах:

1. Реестр проблем - свод вопросов, связанных с ресурсами. Например это доступность ресурсов, уровень использования, отклонения по качеству, и перерасходы бюджета
2. Реестр вынесенных уроков, особенно с похожих проектов
3. Назначение ресурсов - показывает ожидаемое использование ресурсов, и их происхождение
4. Расписание проекта. Показывает, как ресурсы планируется использовать, когда, и на какие активности
5. Иерархическая структура ресурсов
6. Требования к ресурсам - указывают потребность в материалах, запчастях, и оборудовании
7. Реестр рисков - включает информацию о потенциальных рисках, связанных с приобретением и использованием физических ресурсов. РМ должен быть на страже рисков, мониторить их триггеры. По мере прогресса проекта, в реестр могут добавляться новые риски

Процесс Контроля ресурсов

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

1. Проектные документы
2. Соглашения и контракты
3. Данные по исполнению работ

Документация: Реестр проблем

Многие РМ используют Реестр проблем (также может называться реестр вопросов, или реестр пунктов к действию). Реестры проблем используются в процессах Интеграции проекта и Управления качеством. Поскольку Реестр проблем обновляется по мере разрешения их, он сам является выходом процесса Управления командой.
Как часть управления командой и заинтересованными сторонами, Реестр проблем используется для коммуникаций. Он усиливает внимание на причинах проблем, на их влиянии на содержание, расписание, бюджет, риски, и иные аспекты проекта, и содержит рекомендации корректирующих действий. Такие реестры дают людям понимание, что их проблемы имеются ввиду, даже если и не будут решаться прямо сейчас. Эффективные РМ контролируют вопросы так, чтобы они не влияли на проект. Как и вся проектная документация, Реестр проблем обновляется по мере прогресса проекта.
Колонки реестра проблем, примерно:

1. номер проблемы
2. кем добавлено
3. когда добавлено
4. описание проблемы
5. ответственный
6. статус
7. решение

Можно колонки кастомизировать под потребности данного проекта.

Процесс Управления командой

Как и Развитие команды, Управление командой происходит постоянно по мере исполнения проекта. Управление командой включает ежедневные активности, и мы рассмотрим их далее.
Входы в процесс Управления командой:

1. Детали, связанные с управлением командой, включаются в План управления ресурсами
2. Реестр проблем (особенно связанных с командой)
3. Назначения участников команд (RACI диаграмма)
4. Устав команд
5. Отчеты о прогрессе работ дают индикации прогресса проекта в соответствии с планом. РМ использует эту информацию для выявления необходимости корректировок. Результаты оценки прогресса команды из Развития команды анализируются, для выявления успехов, областей где команде нужно больше поддержки, и конфликтов, которые надо решать.

В процессе Управления командой, РМ должен делать следующее для построения эффективной команды:

1. оценивать и отслеживать прогресс команды
2. быть лидером
3. разбираться с проблемами команды
4. способствовать разрешению конфликтов
5. вести переговоры, влиять на людей
6. корректировать планы на основании данных об их исполнении
7. управлять рисками для успеха команды
8. быть в курсе происходящего
9. использовать лог проблем для поиска решений

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

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

Например:
Вы только что переняли проект от иного РМ, который увольняется. Он говорит, что проект в расписании, но только потому, что он без конца всех пинал. Что прежде всего должны сделать вы?

• А. Проверить статус рисков
• В. Проверить исполнение бюджета
• С. Выработать стратегию управления
• D. Сказать команде свои цели

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

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

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

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

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

Процесс Приобретения ресурсов

Этот процесс подразумевает следование Плану управления ресурсами, чтобы обеспечить проект людьми и физическими ресурсами. План управления ресурсами включает то, как ресурсы будут привлекаться и отпускаться; а документация на требования к ресурсам скажет РМ, что именно за ресурсы ему нужны. Расписание и бюджет проекта дают четкую информацию по тому, когда ресурсы будут привлекаться, и сколько денег в бюджете на их оплату.
Для понимания того, зачем нужно управление ресурсами, подумаем о большом проекте, в несколько лет, с сотнями людей  массивом физических ресурсов. Такое спланировать можно только с командой! Финальный список ресурсов может включать поставщиков, подрядчиков, и людей которые на момент старта проекта в компании еще работать не будут (но будут наняты потом). Также, многие физические ресурсы лучше не покупать заранее чтобы не затаривать склады. Привлечение запланированных ресурсов по мере потребности в них - хороший пример планирования набегающей волной.
Приобретение ресурсов начинается с планирования и оценки работ, это дает информацию, сколько кого и чего надо.
Рассмотрим далее процессы приобретения человеческих и физических ресурсов.

Процесс Оценки активностей ресурсов

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

1. базовое содержание (описание содержания, ИСР, словарь ИСР)
2. список активностей из Управления расписанием, что позволяет оценить о потребность в ресурсах на уровне активностей и пакетов работ
3. атрибуты активностей, то есть специфичная информация о каждой активности, вроде типа и количества ресурсов, нужных для нее

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

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

Оценки используются для принятия решений - например, писать софт самим или купить, нанять в штат или на аутсорс, какие материалы использовать на проекте.

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

В конце процесса оценки активностей ресурсов, команда должна определить как выходы:

1. ресурсы на активности проекта
2. их количество и стоимость
3. их доступность

Эти результаты можно документировать в RBS, Resourse Breakdows Structure (первоначально она создается при Планировании управления ресурсами, а тут - уточняется).

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

Частая жалоба участников проектных команд, что они не понимают ролей и ответственностей на проекте. Так что, это критически важная часть процесса Планирования управления ресурсами.
Работа по проекту редко заключается просто в исполнении пакетов работ; как правило, кто-то должен помогать РМ в определении рисков, управлении качеством, в активностях по управлению проектом. Участники команды должны понимать, на какие активности и пакеты работ они назначены, какой отчетности от них ожидают, и какую работу они должны делать на проекте. Также, в функциональной или матричной среде, менеджеры должны понимать, каково будет отвлечение их ресурсов.
В терминах физических ресурсов, РМ должен определить, какие ресурсы нужны, и где их взять. Если ресурсы внутренние, то нужно договориться с владельцами. Если внешние, то надо работать с департаментом закупок (и скорее всего РМ будет вовлечен в процесс закупки).
В планировании управления ресурсами, используется следующий набор входящей документации:

1. Устав проекта. Документирует высокоуровневые требования к проекту, в т.ч. требования к ресурсам, и выделенный на них бюджет
2. План управления проектом. Прежде чем определять роли, ответственности, структуру отчетности и т.д., нужно понять жизненный цикл проекта, и процессы, уже для него определенные, как будет делаться работа, что нужно заинтересованным сторонам, и иные вводные:
1. Базовые значения содержания - включают описание продуктов проекта, которые помогают РМ определить нужные для них ресурсы
2. План управления качеством - включает согласованный уровень качества физических ресурсов для нужд проекта
3. План вовлечения заинтересованных сторон - распространяется в т.ч. и на команду, ее привлечение к планированию, исполнению, выявление влияния каждого на проект
4. План управления закупками - регламентирует, как РМ будет взаимодействовать с департаментами закупок, и HR
3. Проектная документация: расписание, Реестр рисков, Реестр заинтересованных сторон. Эта документация дает понимание сроков привлечения ресурсов, их типа и количества
4. Факторы среды компании. Нужно понимать, на каком поле мы будем работать:
1. какие компании будут вовлечены в проект?
2. есть ли подводные камни?
3. может, кто-то настроен против проекта?
4. участники команды сидят вместе, или в разных офисах и странах?
5. доступна ли поддержка на контракте?
6. доступны ли тренинги участникам команды?
5. Процессные активы компании. Возможно, уже есть какие-то шаблоны, или вынесенные уроки

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

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

1. План управления качеством
2. Метрики качества
3. Документация по тестированию и приемке
4. Данные по исполнению работ и поставок
5. Одобренные запросы на изменения
6. Обновления проектной документации

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

Контроль качества отвечает на следующие вопросы:

1. Результаты проекта соответствую согласованным стандартам (а значит, и требованиям проекта)?
2. Каково отклонение от стандартов?
3. Это отклонение в рамках допустимых лимитов?
4. Используется ли чеклист, для проверки требований?
5. Не нужно ли внести изменений в проект?