Руководство к своду знаний по управлению проектом седьмое издание скачать

Руководство к Своду знаний по управлению проектами, 2017.

  Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.

Руководство к Своду знаний по управлению проектами, 2017

СТАНДАРТ УПРАВЛЕНИЯ ПРОЕКТОМ.
В основу настоящего Руководства положен Стандарт управления проектом [1]. Стандарт — это документ, установленный уполномоченным органом, обычаем или по общему согласию в качестве модели или образца. Стандарт управления проектом был разработан как стандарт Американского национального института стандартов (American National Standards Institute, ANSI) с использованием процесса, основанного на принципах консенсуса, открытости, соблюдения процессуальных норм и сбалансированности. Стандарт управления проектом является основополагающим справочным материалом для программ PMI по профессиональному развитию и в практике управления проектом. Поскольку существует необходимость адаптации управления проектом с целью обеспечить соответствие потребностям конкретного проекта, в основу как Стандарта, так и Руководства положены описательные, а не директивные практики. В силу этого настоящий Стандарт определяет процессы, которые являются хорошими практиками при осуществлении большинства проектов в большинстве случаев. Данный Стандарт также определяет входы и выходы, которые обычно связаны с этими процессами. Стандарт не содержит требований об обязательном исполнении тех или иных конкретных процессов или практик. Стандарт управления проектом входит в состав части II Руководства к Своду знаний по управлению проектом (Руководство РМВОК).

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

Оглавление.
ЧАСТЬ 1 РУКОВОДСТВО К СВОДУ ЗНАНИЙ ПО УПРАВЛЕНИЮ ПРОЕКТОМ (РУКОВОДСТВО PMBOK®).
1.ВВЕДЕНИЕ.
2.СРЕДА, В КОТОРОЙ ОСУЩЕСТВЛЯЕТСЯ ПРОЕКТ.
3.РОЛЬ РУКОВОДИТЕЛЯ ПРОЕКТА.
4.УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА.
5.УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА.
6.УПРАВЛЕНИЕ РАСПИСАНИЕМ ПРОЕКТА.
7.УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА.
8.УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА.
9.УПРАВЛЕНИЕ РЕСУРСАМИ ПРОЕКТА.
10.УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА.
11.УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА.
12.УПРАВЛЕНИЕ ЗАКУПКАМИ ПРОЕКТА.
13.УПРАВЛЕНИЕ ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА.
ССЫЛКИ.
ЧАСТЬ 2 СТАНДАРТ. УПРАВЛЕНИЯ ПРОЕКТОМ.
1.ВВЕДЕНИЕ.
2.ГРУППА ПРОЦЕССОВ ИНИЦИАЦИИ.
3.ГРУППА ПРОЦЕССОВ ПЛАНИРОВАНИЯ.
4.ГРУППА ПРОЦЕССОВ ИСПОЛНЕНИЯ.
5.ГРУППА ПРОЦЕССОВ МОНИТОРИНГА И КОНТРОЛЯ.
6.ГРУППА ПРОЦЕССОВ ЗАКРЫТИЯ.
ЧАСТЬ 3 ПРИЛОЖЕНИЯ, ГЛОССАРИЙ И УКАЗАТЕЛЬ.
ПРИЛОЖЕНИЕ X1 ИЗМЕНЕНИЯ В ШЕСТОМ ИЗДАНИИ.
ПРИЛОЖЕНИЕ X2 СОАВТОРЫ И РЕЦЕНЗЕНТЫ РУКОВОДСТВА PMBOK® — ШЕСТОЕ ИЗДАНИЕ.
ПРИЛОЖЕНИЕ X3 ГИБКИЕ, ИТЕРАТИВНЫЕ, АДАПТИВНЫЕ И ГИБРИДНЫЕ СРЕДЫ ПРОЕКТА.
ПРИЛОЖЕНИЕ X4 ОБЗОР КЛЮЧЕВЫХ КОНЦЕПЦИЙ В ОТНОШЕНИИ ОБЛАСТЕЙ ЗНАНИЙ.
ПРИЛОЖЕНИЕ X5 ОБЗОР СООБРАЖЕНИЙ ПО АДАПТАЦИИ ДЛЯ ОБЛАСТЕЙ ЗНАНИЙ.
ПРИЛОЖЕНИЕ X6 ИНСТРУМЕНТЫ И МЕТОДЫ.
ГЛОССАРИЙ.

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:

Скачать книгу Руководство к Своду знаний по управлению проектами, 2017 — fileskachat.com, быстрое и бесплатное скачивание.

Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.Купить эту книгу

Скачать
— pdf — Яндекс.Диск.

Дата публикации: 29.07.2021 12:33 UTC

Теги:

учебник по бизнесу :: бизнес :: проект


Следующие учебники и книги:

  • Стратегия голубого океана, Как найти или создать рынок, свободный от других игроков, Ким Ч.В., Моборн Р., 2017
  • Сначала скажите нет, Секреты профессиональных переговорщиков, Кэмп Д., 2015
  • Сам себе MBA, Самообразование на 100 %, Кауфман Д., 2013
  • Руководство разумного инвестора, Надежный способ получения прибыли на фондовом рынке, Богл Д., 2013

Предыдущие статьи:

  • Разумный инвестор, Полное руководство по стоимостному инвестированию, Грэм Б., 2014
  • Принципы, Жизнь и работа, Далио Р., 2018
  • Построение бизнес-моделей, Настольная книга стратега и новатора, Остервальдер А., 2012
  • Полная Ж, Жизнь как бизнес-проект, Гандапас Р., 2018

PMBOK-7th

В июле 2021 членам Института управления проектами стала доступна новая 7-ая редакция Руководства к своду знаний по управлению проектами (PMBOK Guide). Выпуски на других языках, в том числе на русском, ожидаются в августе 2021.

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

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

Что изменилось

Как и в шестом издании, новое издание содержит две основные части — стандарт ANSI и руководство PMBOK Guide. Однако структура каждой части значительно изменилась.

Изменения в стандарте ANSI

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

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

Несмотря на простоту цикла, на практике его постоянно путают с фазами проекта при каскадной организации: старт проекта, организация и подготовка, исполнение, завершение. Неужели фазой «организация и подготовка» не нужно управлять? Если нужно, значит управленческий цикл отрабатывает в полной мере для этой фазы. Однако разбор этой ошибки — тема другой статьи.  

Системный подход к поставке ценности

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

Цель проектов по новому стандарту не в производстве результатов, а в поставке ценности. Это не одно и то же. Новая цель означает, что проектная команда должна смотреть дальше во времени, думать о пользе создаваемых продуктов. А раз меняется цель проектов, то меняется и система управления.

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

12 принципов

  1. Будьте прилежным, уважительным и заботливым управляющим
  2. Создавайте среду сотрудничества проектной команды
  3. Вовлекайте заинтересованные стороны
  4. Фокусируйтесь на ценности
  5. Используйте системное мышление
  6. Поощряйте лидерство на всех уровнях
  7. Адаптируйте систему управления проектом к конкретной ситуации
  8. Встраивайте качество в процесс и конечные продукты
  9. Учитывайте сложность проекта на протяжении всего проекта
  10. Учитывайте угрозы и возможности
  11. Встраивайте адаптируемость и устойчивость в систему управления проектом
  12. Управляйте изменениями в организации

Если у вас остался вопрос после прочтения американского национального стандарта (!), а как же управлять проектом, то я вас прекрасно понимаю. Принципы хороши тем, что они более стабильны и универсальны, нежели процессы. Однако от принципов трудно перейти к конкретным действиям. Аналогичная проблема есть и в agile. Есть манифест с общими ценностями, но, чтобы перейти к действиям, нужно разобраться хотя бы с одной конкретной практикой (например, Scrum), которая построена в согласии с манифестом.

Изменения в PMBOK Guide

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

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

  1. Заинтересованные стороны. Была область знаний, а стал домен. Ничего, по сути, не изменилось.
  2. Команда. Раньше PMBOK Guide не различал людей и асфальтоукладчики. Теперь авторы увидели различие и выделили команду в отдельный домен. Это выделение напрашивалось давно уже. Так что здесь явное улучшение.
  3. Неопределенность. Была область «управление рисками», а стал домен неопределенность. Яйца в профиль.
  4. Поставка результатов. Были две области знаний «Содержание» и «Качество», зачем-то разделенные. Отчасти логика была, т.к. тема качества развивается в отдельных стандартах. Но с точки зрения практики отделение было нелогичным. Сейчас все стало на свои места – есть один домен, в котором нужно думать о продуктах и их качестве.
  5. Жизненный цикл. Раньше эта тема отделялась от областей в красивую логику. Теперь это стало одним из доменов. Мне кажется, это менее удобным. Возможно, просто нужно привыкнуть. Радует, что тема жизненного цикла проработана глубже. Хотя ребята сами запутались и инкрементный подход проиллюстрировали неверно.
  6. Планирование. Раньше был управленческий цикл из 5 шагов. Конечно, инициация и завершения были довольно куцыми, но вместе с ними последовательность была целостной, законченной. Теперь остались только три самых наполненных действиями шага – планирование, выполнение и мониторинг.
  7. Выполнение. Был шаг управленческого цикла, теперь отдельный домен
  8. Измерение прогресса. Был шаг управленческого цикла «мониторинг и контроль», теперь отдельный домен. Справедливости ради, стало больше четкости, т.к. речь идет только про метрики слежения за прогрессом.
В этой иллюстрации инкрементный подход неотличим от каскадного

Полноценная интеграция Agile

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

  • Итеративно-инкрементальная разработка и поставка — это вариант жизненного цикла
  • Самоуправляемые команды — опция при построении команды проекта
  • Стили лидерства — на выбор руководителя проекта: можешь помогать команде самоорганизовываться, а можешь управлять директивно
  • Практики — на выбор команды, можно использовать Scrum, Kanban или любой другой подход

Конечно, после PMBOK Guide невозможно начать делать проект с помощью Scrum. Верно также, что и после прочтения Scrum Guide (17 страниц описания на русском языке) команда вряд ли сразу сможет делать поставку продукта спринтами. Нужна конкретика.

Платформа PMIstandards+

Платформа PMIstandards+ задумана как хранилище полезных дополнений к основным стандартам.

Поиск удобный, ценность остального под вопросом

Сейчас здесь можно найти 4 руководства (шестое издание PMBOK Guide с приложением по Agile, руководство по иерархическим структурам и руководство по бизнес-анализу). К ним можно скачать шаблоны, небольшие поясняющие видео, аудио и текстовые материалы по различным отдельным темам.

Я честно пытался понять, в чем отличие платформы от ресурса projectmanagement.com, но пока сути различий не понял. Опять яйца в профиль?

Этим ресурсом пользуюсь давно

Современная тенденция плодить продукты-близнецы начинает уже раздражать. Какую проблему пытались решить ребята в PMI? Типа сайт ProjectManagement.com не диджитал, и нам страшно упустить тренд?

Заключение

Из-за стремления авторов к универсальности система управления стала более абстрактной, что затруднит ее применение на практике. Логика 6-й редакции хоть и была похожа на частный случай, все же была понятной: на каждом этапе жизненного цикла вы проходите управленческий набор шагов, акцентируя внимание на 10 областях знаний проекта. Довольно просто и логично.

Теперь в списке из 8 доменов перемешались и жизненный цикл проекта, и управленческий цикл и при этом сохранились некоторые из прежних областей (заинтересованные стороны и риски/неопределенность). Логика в этом тоже есть, ведь работа с заинтересованными сторонами, командой и рисками идет в своем ритме, не сильно связанном с процессами планирования, выполнения и контроля всех работ проекта. Пока это трудно уложить в голове. Только время покажет, насколько это будет логично, как для меня, так и других практиков.

Если обратиться к описаниям различных agile-практик, все-таки традиционно участники проекта четко отделяются от процесса. Мне кажется, это логично именно с системной точки зрения. Люди — это элементы системы. Артефакты (требования, результаты) — тоже элементы системы. А процессы описывают взаимодействия элементов. Это совершенно разные характеристики системы. И в том же Scrum они четко отделены друг от друга. Я бы тоже их не смешивал в общую кучу.

Материалы по теме

  • Обзор шестого издания PMI PMBOK
  • Что будет в седьмом издании PMI PMBoK
  • Что нового в Руководстве по Scrum 2020

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство. Шестое издание

  • Скачали: 2 936
  • Автор:
  • Объем страниц: 1170 стр. 326 иллюстраций
  • Жанр: Бизнес-стратегии / Зарубежная деловая литература / Руководства / Новинки книг
  • Возрастное : 12+
  • Год: 24 сентября 2019
  • isbn: 978-5-9693-0402-4
  • Дата: 08 январь 2022

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство. Шестое издание скачать fb2, epub, pdf, txt бесплатно

Новинки в

Телеграм

«Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах…»

Читать книгу Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство. Шестое издание онлайн, совершенно бесплатно и без регистрации. Автор книги . Жанр книги: Бизнес-стратегии / Зарубежная деловая литература / Руководства / Новинки книг, является одним из самых популярных жанров современности.

Руководство к Своду знаний по управлению проектами

Свод знаний по управлению проектам PMBOK представляет собой сумму профессиональных знаний по управлению проектами. Институт управления проектами использует этот документ в качестве основного…

Подробнее

Руководство к своду знаний по управлению проектами . Шестое издание. Agile: практическое руководство

«Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу…

Подробнее

Отзывы читателей

  • В

    Шестое издание у меня есть на русском. Кто может помочь с электронной версией 7 издания на русском?

PMBoK 5 скачать

Руководство к Своду знаний по управлению проектами (PMI PMBoK 5th Edition) – пятое издание отражает опыт и знания руководителей-практиков и освещает фундаментальные основы управления широким кругом проектов. Этот признанный международный стандарт предоставляет руководителям проектов важнейшие инструменты для управления проектами и достижения результатов в организации работы.

Была добавлена 10-я область знаний; в которой управление заинтересованными сторонами проекта расширяет важность привлечения соответствующих заинтересованных сторон проекта в принятие ключевых решений и мероприятия.

Был пересмотрен поток данных и информации проекта для обеспечения согласованности и соответствия модели информационной иерархии, включающей данные, информацию, знания и мудрость (Data, Information, Knowledge and Wisdom, DIKW), которая используется в области управления знаниями.

СкачатьСКАЧАТЬ
PMI PMBoK 5 на русском языке
PDF

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

Cкачать предыдущие издания PMI PMBoK:

  • Скачать PMBoK 4 бесплатно на русском языке (PDF)
  • Скачать PMBoK 3 бесплатно на русском языке (PDF)

Просмотры: 190 150

Обложка книги «Руководство к Своду знаний по управлению проектами (Руководство PMBOK)»

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

Коллектив авторов

Обложка книги «Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство»

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

Коллектив авторов

Вы просматриваете книги из серии «Руководство PMBOK», которые можно читать онлайн бесплатно или скачать в формате fb2

Topics
هندسة مدنية
Collection
opensource
Language
English

هندسة مدنية

Addeddate
2019-12-03 13:08:20
Identifier
pmbok6thedenglish
Identifier-ark
ark:/13960/t6j185d3p
Ocr
ABBYY FineReader 11.0 (Extended OCR)
Ppi
300
Scanner
Internet Archive HTML5 Uploader 1.6.4

plus-circle Add Review

comment

Reviews

There are no reviews yet. Be the first one to
write a review.

23,072

Views

27
Favorites

DOWNLOAD OPTIONS


download 1 file

ABBYY GZ download


download 1 file

DAISY download

For print-disabled users


download 1 file

EPUB download


download 1 file

FULL TEXT download


download 1 file

ITEM TILE download


download 1 file

KINDLE download


download 1 file

PDF download


download 1 file

SINGLE PAGE PROCESSED JP2 ZIP download


download 1 file

TORRENT download

download 11 Files

download 6 Original

SHOW ALL

IN COLLECTIONS

Community Texts

Community Collections

Uploaded by

EKRAMY LIBRARY

on December 3, 2019

Руководство к Своду знаний по управлению проектами, 2017.

  Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.

Руководство к Своду знаний по управлению проектами, 2017

СТАНДАРТ УПРАВЛЕНИЯ ПРОЕКТОМ.
В основу настоящего Руководства положен Стандарт управления проектом [1]. Стандарт — это документ, установленный уполномоченным органом, обычаем или по общему согласию в качестве модели или образца. Стандарт управления проектом был разработан как стандарт Американского национального института стандартов (American National Standards Institute, ANSI) с использованием процесса, основанного на принципах консенсуса, открытости, соблюдения процессуальных норм и сбалансированности. Стандарт управления проектом является основополагающим справочным материалом для программ PMI по профессиональному развитию и в практике управления проектом. Поскольку существует необходимость адаптации управления проектом с целью обеспечить соответствие потребностям конкретного проекта, в основу как Стандарта, так и Руководства положены описательные, а не директивные практики. В силу этого настоящий Стандарт определяет процессы, которые являются хорошими практиками при осуществлении большинства проектов в большинстве случаев. Данный Стандарт также определяет входы и выходы, которые обычно связаны с этими процессами. Стандарт не содержит требований об обязательном исполнении тех или иных конкретных процессов или практик. Стандарт управления проектом входит в состав части II Руководства к Своду знаний по управлению проектом (Руководство РМВОК).

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

Оглавление.
ЧАСТЬ 1 РУКОВОДСТВО К СВОДУ ЗНАНИЙ ПО УПРАВЛЕНИЮ ПРОЕКТОМ (РУКОВОДСТВО PMBOK®).
1.ВВЕДЕНИЕ.
2.СРЕДА, В КОТОРОЙ ОСУЩЕСТВЛЯЕТСЯ ПРОЕКТ.
3.РОЛЬ РУКОВОДИТЕЛЯ ПРОЕКТА.
4.УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА.
5.УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА.
6.УПРАВЛЕНИЕ РАСПИСАНИЕМ ПРОЕКТА.
7.УПРАВЛЕНИЕ СТОИМОСТЬЮ ПРОЕКТА.
8.УПРАВЛЕНИЕ КАЧЕСТВОМ ПРОЕКТА.
9.УПРАВЛЕНИЕ РЕСУРСАМИ ПРОЕКТА.
10.УПРАВЛЕНИЕ КОММУНИКАЦИЯМИ ПРОЕКТА.
11.УПРАВЛЕНИЕ РИСКАМИ ПРОЕКТА.
12.УПРАВЛЕНИЕ ЗАКУПКАМИ ПРОЕКТА.
13.УПРАВЛЕНИЕ ЗАИНТЕРЕСОВАННЫМИ СТОРОНАМИ ПРОЕКТА.
ССЫЛКИ.
ЧАСТЬ 2 СТАНДАРТ. УПРАВЛЕНИЯ ПРОЕКТОМ.
1.ВВЕДЕНИЕ.
2.ГРУППА ПРОЦЕССОВ ИНИЦИАЦИИ.
3.ГРУППА ПРОЦЕССОВ ПЛАНИРОВАНИЯ.
4.ГРУППА ПРОЦЕССОВ ИСПОЛНЕНИЯ.
5.ГРУППА ПРОЦЕССОВ МОНИТОРИНГА И КОНТРОЛЯ.
6.ГРУППА ПРОЦЕССОВ ЗАКРЫТИЯ.
ЧАСТЬ 3 ПРИЛОЖЕНИЯ, ГЛОССАРИЙ И УКАЗАТЕЛЬ.
ПРИЛОЖЕНИЕ X1 ИЗМЕНЕНИЯ В ШЕСТОМ ИЗДАНИИ.
ПРИЛОЖЕНИЕ X2 СОАВТОРЫ И РЕЦЕНЗЕНТЫ РУКОВОДСТВА PMBOK® — ШЕСТОЕ ИЗДАНИЕ.
ПРИЛОЖЕНИЕ X3 ГИБКИЕ, ИТЕРАТИВНЫЕ, АДАПТИВНЫЕ И ГИБРИДНЫЕ СРЕДЫ ПРОЕКТА.
ПРИЛОЖЕНИЕ X4 ОБЗОР КЛЮЧЕВЫХ КОНЦЕПЦИЙ В ОТНОШЕНИИ ОБЛАСТЕЙ ЗНАНИЙ.
ПРИЛОЖЕНИЕ X5 ОБЗОР СООБРАЖЕНИЙ ПО АДАПТАЦИИ ДЛЯ ОБЛАСТЕЙ ЗНАНИЙ.
ПРИЛОЖЕНИЕ X6 ИНСТРУМЕНТЫ И МЕТОДЫ.
ГЛОССАРИЙ.

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:

Скачать книгу Руководство к Своду знаний по управлению проектами, 2017 — fileskachat.com, быстрое и бесплатное скачивание.

Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.Купить эту книгу

Скачать
— pdf — Яндекс.Диск.

Дата публикации: 29.07.2021 12:33 UTC

Теги:

учебник по бизнесу :: бизнес :: проект


Следующие учебники и книги:

  • Стратегия голубого океана, Как найти или создать рынок, свободный от других игроков, Ким Ч.В., Моборн Р., 2017
  • Сначала скажите нет, Секреты профессиональных переговорщиков, Кэмп Д., 2015
  • Сам себе MBA, Самообразование на 100 %, Кауфман Д., 2013
  • Руководство разумного инвестора, Надежный способ получения прибыли на фондовом рынке, Богл Д., 2013

Предыдущие статьи:

  • Разумный инвестор, Полное руководство по стоимостному инвестированию, Грэм Б., 2014
  • Принципы, Жизнь и работа, Далио Р., 2018
  • Построение бизнес-моделей, Настольная книга стратега и новатора, Остервальдер А., 2012
  • Полная Ж, Жизнь как бизнес-проект, Гандапас Р., 2018

Пройдите бесплатный курс по Scrum на английском языке и в ответ оставьте 5* и позитивный отзыв udemy.com/course/scrum-guide-roles-events-artifacts/?couponCode=8A75FAC2A5858A507AC8 (если вы в РФ, но необходима регистрация из-под VPN).


Седьмая версия свода знаний по управлению проектами PMI PMBoK вышла 1 августа 2021.

От поставки результата к созданию ценности

Ранее PMBoK в основном фокусировался на управлении последовательным проектом (waterfall). Ужесточение конкуренции привело к сокращению ЖЦ проектов и частому внесению в ходе проекта изменений. Уже давно стали популярны итеративные-инкрементальные подходы и процессы проверки идей и гипотез перед реализацией.

PMI понимает, что стандарты должны не предпочитать какие-то подходы, а помогать создавать успешные продукты и реализовывать проекты. Раньше PMBoK фокусировался на получении запланированных результатов (deliverables, outputs), а теперь – на outcomes (по-русски это тоже «результаты», но другие – о ценности, пользе, выгодах, целях).

От последовательного процесса к свободе выбора

РП сам выбирает подходящий процесс (последовательный, agile, смешанный) и инструменты, основываясь на специфике конкретного проекта. Среди новых глав PMBoK:

  • Tailoring – настройка процессов и инструментов под свою специфику.
  • Models, Methods и Artifacts – модели, методы, артефакты с расширенным списком инструментов и аргументами к выбору из этого списка под ваш проект.

От этапов и активностей к принципам

Ранее PMBoK был основан на процессах управления (49 конкретных активностях), разложенных по 5 последовательным этапам:

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

и 10 областям знаний (аспектам проекта):

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

Логика изложения была понятной: на каждом из 5 этапов жизненного цикла проекта РП управляет несколькими-всеми из 10 крупных аспектов проекта (областей знаний), выполняя конкретные из 49 действий (процессы управления). Теперь свод стал почти в 2 раза короче, но менее структурным.
Итак, ранее PMBoK был основан на процессах управления, разложенных по 5 этапам и 10 областям знаний. Новый PMBoK 7 основан на 12 принципах и 8 областях деятельности.

10 областей знаний —> 8 областей деятельности.

8 областей деятельности

Здесь смешались этапы и области знаний предыдущих PMBoK.

  1. Stakeholders – работа с заинтересованными сторонами. Была областью знаний, стала доменом.
  2. Team – управление командой. Раньше была в составе Resources.
  3. Lifecycle – управление ЖЦ проекта: модели, методы, этапы/циклы. Не было отдельной областью, потому что цикл был единственный – последовательный, из 5 этапов.
  4. Planning – планирование проекта. Было одним из 5 этапов, стало деятельностью.
  5. Project work – управление ходом реализации проекта. Было одним из 5 этапов, стало деятельностью.
  6. Navigating uncertainty and ambiguity – работа с неопределенностью. Раньше была областью знаний Risks.
  7. Delivery – создание ценности и поставка результатов. Ранее были области Scope + Quality.
  8. Performance – оценка эффективности проекта. Ранее был псевдо-этап Monitoring and control.

5 групп/этапов процессов —> 12 принципов.

Направляют поведение участников проектной команды

12 принципов

  1. Stewardship, ответственное руководство. Будьте проактивным, осознавайте последствия своих действий, заботьтесь и поддерживайте команду, будьте честны с заказчиком.
  2. Team, команда. Создавайте среду сотрудничества и уважительной требовательности к результатам внутри команды.
  3. Stakeholders, заинтересованные стороны. Стремитесь понять интересы и ожидания ЗС и вовлекать их в процесс создания ценности.
  4. Value, ценность. Фокусируйтесь на максимизации ценности для заказчика и организации.
  5. Целостная картина. Думайте системно, воспринимайте проект, как элемент большой системы, учитывайте взаимосвязи.
  6. Лидерство. Поощряйте лидерство на всех уровнях; учите, наставляйте и воодушевляйте участников команды.
  7. Подстройка процесса. Адаптируйте систему управления проектом к конкретной ситуации; выберите подходы и инструменты ради максимизации ценности.
  8. Качество. Встройте качество в процесс создания продуктов.
  9. Комплексность. Учитывайте сложность проекта на каждом этапе, снижайте ее, используя свои компетенции.
  10. Угрозы и возможности. Минимизируйте угрозы и максимизируйте возможности.
  11. Адаптивность и устойчивость. Умейте действовать по ситуации, сохраняя фокус на создании ценности.
  12. Управление изменениями. Будьте готовыми к изменениям, управляйте ими.

Принципы стабильнее и универсальнее процессов. Однако от них труднее перейти к конкретным действиям. Стремясь к универсальности, PMBoK стал более абстрактным.


Эти темы мы подробно обсуждаем на курсе «Управление проектами».

Стандарт управления проектом PMBOK 7

Стандарт управления проектом (The Standard for Project Management) идентифицирует принципы управления проектом, направляющие поведение и действия специалистов  по проектам и прочих заинтересованных сторон, работающих над проектами или  вовлеченных в них. Применяется вне зависимости от области и подхода к поставке (например, предиктивного, адаптивного или гибридного). 

Основные термины

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

Продукт — произведённый артефакт, который можно выразить количественно и который может являться как конечным объектом, так и компонентом.

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

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

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

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

Команда проекта — группа лиц, которая выполняет работы проекта для достижения его целей.

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

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

Система поставки ценности

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

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

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

1.png

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

Внутренняя среда— активы процессов, данных, знаний, защита и безопасность, инфраструктура, ПО, тп
Внешняя — ситуация на рынке, социальное и культурное влияние, исследования, отраслевые стандарты, тп

2.png

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

3.png

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

Функции, связанные с проектными

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

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

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

Ценности сообщества управления проектом- ответственность, уважение, справедливость, честность.

Ниже представлены 12 принципов управления проектом.

4.png

5.png

6.png

7.png
8.png
9.png

10.png
11.png
12.png13.png14.png
15.png

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

Руководство состоит из трех основных разделов:

  • Домены исполнения проекта — 8  доменов, образующих интегрированную систему, цель которой обеспечить успешное осуществление проекта и поставку предусмотренных конечных результатов;
  • Адаптация — что требуется адаптировать и как следует заниматься адаптацией отдельных проектов;
  • Модели, методы и артефакты — иллюстрируют ряд возможностей, которые команда проекта может использовать для создания поставляемых результатов, организации работы.

16.png

Домены исполнения проекта

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

Домен исполнения «Заинтересованные стороны»

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

1.png

К домену исполнения относятся следующие определения:

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

2.png

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

3.png

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

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

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

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

Типы коммуникаций:
4.png

Методы коммуникаций включают push- (проталкивание), pull- (втягивание) и интерактивные коммуникации (более глубокое погружение, чем push/pull):
Push. Коммуникации, отправляемые заинтересованным сторонам, такие как заметки, сообщения электронной почты, отчеты о статусе, сообщения голосовой почты и т. д. Push-коммуникации применяются для общения в одностороннем порядке с отдельными заинтересованными сторонами или их группами. Push-коммуникации не позволяют непосредственно измерять реакцию и оценивать понимание получателя, в силу чего их следует использовать обдуманно.
Pull. Информация, которую ищет заинтересованная сторона, например когда член команды проекта запрашивает во внутрикорпоративной сети политики или шаблоны коммуникаций, осуществляет поиск в Интернете или пользуется онлайн-хранилищами. Pull-способ потребления информации используется для непрямой оценки интересов заинтересованных сторон

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

Проверка результатов в домене:

5.png

Домен исполнения «Команда»

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

6.png

К домену исполнения относятся следующие определения:

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

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

Лидерство следует практиковать всем членам команды проекта, а операции управления можно централизовать либо распределять. Если в некоторой среде операции управления централизованы, то подотчетность (то есть ответственность за конечный результат) обычно назначена одному лицу, например руководителю проекта или лицу со схожей ролью. 

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

Существуют также ситуации, когда команда проекта самоорганизуется для выполнения проекта.

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

Общие аспекты развития команды:

  • видения и цели;
  • роли и сферы ответственности;
  • повседневные действия членов команды;
  • руководящее указание;
  • рост.

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

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

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

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

  • открытая коммуникация;
  • общее понимание;
  • совместное владение;
  • доверие;
  • сотрудничество;
  • адаптируемость;
  • устойчивость;
  • наделение полномочиями;
  • признание.

Навыки лидерства:

  • Формирование и поддержание видения. У каждого проекта есть цель. Ее понимание критически важно для того, чтобы люди посвящали свое время и силы работе в верном направлении для достижения цели проекта. Видение проекта четко и лаконично излагает цель проекта. Оно содержит реалистический и привлекательный взгляд на будущие конечные результаты проекта.
  • Во всех различных доменах исполнения проекта существует необходимость в выявлении предубеждения, идентификации первопричин проблем и рассмотрении бросающих вызов проблем, таких как неопределенность, сложность и так далее. Критическое мышление помогает в осуществлении таких операций. К критическому относится мышление, характеризуемое дисциплинированностью, рациональностью, логичностью и ориентацией на доказательную базу. Оно требует открытости и способности к объективному анализу. Критическое мышление, особенно применительно к процессу обнаружения, может включать концептуальное воображение, проницательность и интуицию. К нему также может относиться рефлексивное мышление и метапознание (размышление о мышлении и осознание собственного процесса осознания).
  • Мотивация членов команды проекта имеет два аспекта: во-первых, понимание того, что их мотивирует к работе; во-вторых, работа с ними таким образом, чтобы они оставались приверженными проекту и его конечным результатам.
    Мотивация к работе может быть внутренней или внешней. Внутренняя мотивация исходит от самого человека или связана с его работой. Она состоит в способности находить удовлетворение в самой работе, а не вознаграждении за нее. Внешняя мотивация заключается в выполнении работы ради внешнего вознаграждения, например премии.
  • Часто используемые в проектах навыки межличностных отношений включают в себя, среди прочего, эмоциональный интеллект, принятие решений и разрешение конфликтов.
    Существует несколько моделей, определяющих и объясняющих эмоциональный интеллект. Они сходятся в четырех ключевых областях:
    Самоанализ. Самоанализ — это способность к реалистической самооценке. К нему относится понимание собственных эмоций, целей, мотиваций, сильных и слабых сторон.
    Самоуправление. Самоуправление, или саморегуляция, — это способность контролировать и перенаправлять неконструктивные чувства и импульсы. Это способность размышлять перед действием, удерживаться от резких
    суждений и импульсивных решений.
    Социальная осведомленность. Социальная осведомленность основана на эмпатии, понимании и принятии чувств других. К ней также относится способность считывать невербальные сигналы и язык тела.
    ▹ Социальный навык. Социальный навык — это кульминация прочих измерений эмоционального интеллекта. Он позволяет управлять группами людей, такими как команды проектов, строить социальные сети, находить общую позицию с различными заинтересованными сторонами и устанавливать хорошие взаимоотношения.
    7.png
    Принятие решений. Решения могут приниматься единолично. У такого подхода есть преимущество — скорость, однако он располагает к ошибкам по сравнению с ситуацией, когда привлекается опыт разнообразных людей. Единоличное принятие решения может также демотивировать людей, которых такое решение затрагивает: они могут решить, что с их взглядами и опасениями не считаются.
    Групповое принятие решений выгодно тем, что в нем используется широкая база знаний группы. Вовлечение людей в процесс принятия решений также повышает поддержку ими конечного результата, даже если выбранный вариант 
    был предпочтительным не для каждого из них. В целом, привлечение людей увеличивает их приверженность решению. Недостатком группового принятия решений является требуемое время и перерывы в работе команды из-за того, 
    что людей могут отрывать от работы для консультаций по решению.
    Процесс принятия решений командой проекта часто имеет расходящийся-сходящийся характер. Сначала заинтересованные стороны привлекаются для генерации широкого ряда альтернативных решений или подходов. Это часто 
    делается в индивидуальном порядке, чтобы старшие по должности или более харизматичные заинтересованные стороны не оказывали ненадлежащего влияния на других. Затем после генерации широкого спектра альтернативных решений команда проекта сходится на предпочтительном решении. Целью этого является быстрое принятие решений при одновременном вовлечении разнообразных знаний группы в инклюзивной и уважительной форме.
    Многие подходы, такие как римское голосование, оценка по широкополосному методу Дельфи и голосование по методу «пять пальцев», используют схему расхождения / схождения. Их целью является вовлечение индивидуальных мнений с одновременным голосованием, что сводит к минимуму групповое мышление.

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

Проверка результатов в домене:

8.png
Домен исполнения «Подход к разработке и жизненный цикл»

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

9.png

К домену исполнения относятся следующие определения:

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

Каденции поставок

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

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

Подходы к разработке

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

10.png

  • Предиктивный подход полезен, когда требования к проекту и продукту поддаются определению, сбору и анализу в начале проекта. Данный подход также может называться водопадным. Его также можно использовать, когда привлечен значительный объем инвестиций и существует высокий уровень риска, что может потребовать частых проверок, механизмов контроля изменений и перепланирования между фазами разработки. Содержание, расписание, стоимость, потребности в ресурсах и риски можно в достаточной степени определить на ранних фазах жизненного цикла проекта, и они относительно стабильны. Данный подход к разработке позволяет команде проекта снизить уровень неопределенности на раннем этапе проекта и осуществить значительный объем планирования заранее.
  • Гибридный подход к разработке представляет собой сочетание адаптивного и предиктивного подходов. Данный подход к разработке полезен, когда существует неопределенность или риск в связи с требованиями. Он также полезен, когда поставляемые результаты можно разбить на модули или когда поставляемые результаты могут разрабатывать различные команды проекта. Гибридный подход более адаптивен, чем предиктивный, но менее адаптивен, чем чисто адаптивный подход. В гибридных подходах часто используется итеративный или инкрементный подход к разработке. Итеративный подход полезен для уточнения требований и поиска разнообразных вариантов. При итеративном подходе могут быть получены достаточные характеристики, которые считаются приемлемыми до заключительной итерации. Инкрементный подход используется для создания поставляемого результата посредством серии итераций. Каждая итерация добавляет функционал в пределах заранее определенного срока (временных рамок). Поставляемый результат содержит характеристики, которые считаются завершенными только после заключительной итерации.

    11.png

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

Определения жизненного цикла и фазы

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

1_1.png

1_2.png

1_3.png

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

Проверка результатов в домене:

12.png

Домен исполнения «Планирование»

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

13.png

К домену исполнения относятся следующие определения:

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

Переменные планирования

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

Поставка

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

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

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

Оценка

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

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

14.png
Точность. Точность означает правильность оценки. Точность связана с диапазоном: чем она ниже, тем больше потенциальный диапазон значений. Оценка в начале проекта имеет более низкую точность по сравнению с оценкой в середине проекта.
Прецизионность. Прецизионность — это не то же самое, что точность. Прецизионность означает степень четкости в определении оценки. Например, оценка «2 дня» более прецизионная, чем «на этой неделе». Прецизионность оценок должна быть совместима с желаемой степенью точности.

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

Существуют различные способы представления и/или коррекции оценок:

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

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

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

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

Расписания

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

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

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

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

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

16.png

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

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

17.png

Бюджет

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

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

18.png

Состав и структура команды проекта

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

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

Коммуникации

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

Материальные ресурсы

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

Закупки

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

Изменения

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

Метрики

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

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

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

Согласование

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

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

Проверка результатов в домене:
19.png

Домен исполнения «Работа проекта»

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

20.png

К домену исполнения относятся следующие определения:

Документация по предложениям. Все документы, используемые для получения информации, расценок или предложений от потенциальных продавцов.
Конференция участников тендера. Встречи с потенциальными продавцами до подготовки тендерной заявки или предложения, чтобы потенциальные продавцы имели четкое и единое представление о закупке. Также известны как конференции подрядчиков, конференции поставщиков или предтендерные конференции. 
Явные знания. Знания, которые можно кодировать, используя такие символы, как слова, числа и рисунки.
Неявные знания. Личные знания, например убеждения, опыт и понимание, формулирование и обмен которыми могут быть затруднены. 

Процессы проекта

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

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

Балансировка конкурирующих ограничений

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

Поддержание сфокусированности команды проекта

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

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

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

Управление материальными ресурсами

В некоторых проектах необходимы обыкновенные и расходные материалы от третьих сторон. Планирование, заказ, транспортировка, хранение, отслеживание таких материальных ресурсов и контроль за ними может потребовать большое количество времени и трудозатрат.

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

Работа с закупками

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

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

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

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

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

В конце концов, стороны достигают соглашения и заключают договор. 

Обучение на протяжении проекта

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

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

Мониторинг новой работы и изменений

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

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

Проверка результатов в домене:

21.png

Домен исполнения «Поставка»

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

22.png

К домену исполнения относятся следующие определения:

Требование. Условие или характеристика, которую должен иметь продукт, услуга или результат в соответствии с бизнес-потребностью.
Иерархическая структура работ (ИСР). Иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов.
Критерии выполнения (DoD). Контрольный список всех критериев, которые необходимо выполнить, чтобы поставляемый результат можно было считать готовым для использования заказчиком.
Качество. Степень соответствия совокупности присущих характеристик требованиям.
Стоимость качества (COQ). Все затраты, понесенные в течение срока службы продукта в результате вложений в предотвращение несоответствия требованиям, оценку продукта или услуги на соответствие требованиям, а также затраты, связанные с невыполнением требований.

Поставка ценности

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

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

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

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

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

Поставляемые результаты

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

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

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

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

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

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

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

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

▶ Завершение поставляемых результатов. В зависимости от примененного подхода, существуют различные способы описания завершения компонента или проекта:
▹ Критерии приемки или завершения. Критерии, которые необходимо выполнить перед приемкой поставляемого результата заказчиком или признанием проекта завершенным, часто документируются в описании содержания.
▹ Показатели технического исполнения. Технические спецификации продукта могут документироваться в отдельном документе спецификаций или в качестве расширения ИСР. 
▹ Критерии выполнения. Критерии выполнения используются в адаптивных подходах, особенно в проектах по разработке программного обеспечения.

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

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

23.png

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

Качество

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

Методология стоимости качества (COQ) применяется для нахождения соответствующего баланса между инвестициями в предотвращение недостатков качества и оценкой для предотвращения дефектов и отказов продукта. 
▶ Предотвращение. Затраты на предотвращение необходимы для исключения в продукте дефектов и отказов. Они связаны с проектированием, внедрением и поддержкой системы управления качеством. Они планируются и осуществляются перед фактической эксплуатацией. 
▶ Оценка. Затраты на оценку необходимы для определения степени соответствия требованиям к качеству. Затраты на оценку связаны с измерением и мониторингом операций, относящихся к качеству. Данные затраты могут быть связаны с оценкой
приобретенных материалов, процессов, продуктов и услуг, призванной обеспечить их соответствие спецификациям. 
Внутренние отказы. Затраты вследствие внутренних отказов связаны с нахождением и исправлением дефектов до поступления продукта заказчику. Их несут, когда результаты работы не достигают расчетных стандартов качества.
Внешние отказы. Затраты вследствие внешних отказов связаны с обнаружением дефектов после поступления продукта заказчику и с их исправлением. Следует учитывать, что для целостного взгляда на такие отказы необходимо обдумывать
продукт проекта, когда он в работе несколько месяцев или лет, а не только в момент его передачи заказчику. Затраты вследствие внешних отказов несут, когда продукты или услуги, не достигшие расчетных стандартов качества, выявляются после их
поставки заказчику. 

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

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

24.png

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

Неоптимальные конечные результаты

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

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

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

Проверка результатов в домене:

25.png

Домен исполнения «Измерение»

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

26.png

К домену исполнения относятся следующие определения:

Метрика. Описание характерного свойства проекта или продукта и способа его измерить.
Базовый план (Базовый вариант). Одобренная версия рабочего продукта, которая используется как основа для сравнения с фактическими результатами.
Информационная панель. Набор диаграмм и графиков, отражающих прогресс или исполнение в сравнении с важными измерениями проекта.

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

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

Внедрение результативных измерений

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

Ключевые показатели исполнения (KPI) проектов — это поддающиеся количественному выражению измерения, используемые для оценки успеха проекта. Сами по себе KPI являются просто измерениями, не имеющими практической пользы, если их не применять.

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

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

К характеристикам результативных метрик (или критериям SMART) относятся следующие:
Конкретность (Specific). Измерения конкретны в отношении измеряемого.
Значимость (Meaningful). Измерения должны быть связаны с бизнес-кейсом, базовыми планами или требованиями. Неэффективно измерять атрибуты продукта или исполнение проекта, если это не ведет к достижению целей или улучшению
исполнения.
Достижимость (Achievable). Цель является достижимой при наличии людей, технологий и среды.
Релевантность (Relevant). Измерения должны быть релевантными. Информация в измерении должна обеспечивать ценность и допускать практическое применение.
Своевременность (Timely). Полезные измерения всегда своевременны. Старая информация не так полезна, как свежая. Прогнозная информация, например, о формирующихся тенденциях, может помочь командам проектов изменить направление и принять лучшие решения.

Предмет измерений

К распространенным категориям метрик относятся следующие:

метрики поставляемых результатов;

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

поставка;

Измерения поставки связаны с незавершенной работой. Данные измерения часто используются в проектах с адаптивными подходами. 
▶ Незавершенная работа. Данное измерение показывает количество элементов работы, исполняемых в определенный момент. Оно помогает команде проекта ограничить количество незавершенных элементов до управляемого числа.
▶ Время выполнения. Данное измерение отражает количество времени, прошедшего от внесения истории или некоторого количества работы в бэклог до конца итерации или релиза. Меньшее время выполнения говорит о более
результативном процессе и более продуктивной команде проекта. 
▶ Время цикла. По отношению к времени выполнения, время цикла показывает количество времени, необходимое команде проекта для завершения задачи. Более короткое время говорит о более продуктивной команде проекта. Стабильное время помогает предсказать возможный темп работы в будущем.
▶ Размер очереди. Данное измерение отслеживает количество элементов в очереди. Эту метрику можно сравнить с лимитом незавершенной работы. Закон Литтла гласит, что размер очереди пропорционален как скорости поступления в очередь, так и скорости завершения элементов в очереди. Можно получить представление о сроках выполнения, измеряя незавершенную работу и разрабатывая прогноз будущего завершения работы.
▶ Размер партии. Размер партии измеряет прогнозируемый объем работы (уровень трудозатрат, относительных единиц и так далее), который, как ожидается, будет завершен в данной итерации.
▶ Эффективность процесса. Эффективность процесса — это отношение, используемое в бережливых системах для оптимизации потока работы. Данное измерение подсчитывает отношение между временем создающих добавленную
стоимость операций, и временем операций, не создающих ее. Задачи в статусе ожидания увеличивают время, не создающее добавленную стоимость. Задачи в статусе разработки или проверки представляют собой время, создающее добавленную стоимость. Чем выше отношение, тем более эффективен процесс.

исполнение базового плана;

Большинство измерений расписания отслеживают фактическое исполнение к запланированному в связи со следующим:
▶ Даты старта и финиша. Сравнение фактических дат старта с запланированными датами старта, а также фактических дат финиша с запланированными датами финиша может показать степень, в которой работа выполняется по плану. Даже если работа не следует самому длительному пути в проекте (критическому пути), поздние даты старта и финиша говорят о том, что проект осуществляется не по плану.
▶ Трудозатраты и длительность. Фактические трудозатраты и длительность в сравнении с запланированными показывают правильность оценок объема работы и времени, необходимого на выполнение работы.
▶ Отклонение по расписанию (SV). Простое отклонение по расписанию можно определить, посмотрев на исполнение по критическому пути. При использовании в управлении освоенным объемом отклонение выражается как разница между
освоенным объемом и плановым объемом. На рисунке 2-24 показан график освоенного объема с отклонением по расписанию.
▶ Индекс исполнения расписания (SPI). Индекс исполнения расписания — это измерение в управлении освоенным объемом, показывающее, насколько эффективно выполняется работа в расписании.
▶ Скорость завершения свойств. Рассмотрение скорости приемки свойств в ходе частых обзоров может помочь в оценке прогресса и определении дат завершения и его стоимости.

К распространенным измерениям стоимости относятся следующие:
▶ Фактическая стоимость в сравнении с запланированной. Данное измерение стоимости сравнивает фактическую стоимость труда или ресурсов с оценочной. Его также могут называть скоростью выгорания.
▶ Отклонение по стоимости (CV). Простое отклонение по стоимости получают сравнением фактической стоимости поставляемого результата с оценочной. При использовании в управлении освоенным объемом отклонение выражается
как разница между освоенным объемом и фактической стоимостью. На рисунке ниже показан график освоенного объема с отклонением по стоимости.
▶ Индекс исполнения стоимости (CPI). Данное измерение из управления освоенным объемом показывает, насколько эффективно выполняется работа по отношению к заложенной в бюджет стоимости работы.

27.png

ресурсы;

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

бизнес-ценность;

Бизнес-ценность имеет множество аспектов, как финансовых, так и нефинансовых. К метрикам, вычисляющим финансовую бизнес-ценность, относятся следующие:
▶ Соотношение затрат и выгод. Это измерение ожидаемой приведенной ценности некоторой инвестиции с первоначальной стоимостью. Соотношение затрат и выгод используется для определения того, перевешивают ли затраты на проект
его выгоды. Если затраты превышают выгоды, результат будет больше 1,0. В таком случае проект не стоит рассматривать, если только нет регуляторных, общественно полезных и прочих причин его осуществлять. Схожим измерением является
соотношение выгод и затрат. В нем используются те же переменные, только выгоды расположены в числителе, а затраты — в знаменателе. Если у такого соотношения результат больше 1,0, то проект стоит рассматривать.
▶ Запланированная поставка выгод в сравнении с фактической. В рамках бизнес-кейса организации могут идентифицировать ценность как выгоду, поставляемую в результате осуществления проекта. В проектах, где поставка выгод ожидается в течение жизненного цикла проекта, измерение поставленных выгод и их ценности с последующим сравнением такой информации с бизнес-кейсом позволяет получить информацию, которая становится основанием для продолжения проекта или, в ряде случаев, его отмены.
▶ Окупаемость инвестиций (ROI). ROI — это измерение объема возврата на капитал в сравнении со стоимостью, и его обычно используют как вход для решения об осуществлении проекта.  Измеряя ROI на протяжении проекта, команда проекта может установить, имеет ли смысл продолжать вложение организационных ресурсов.
▶ Чистая приведенная стоимость (NPV). NPV — это разница между приведенной стоимостью притоков капитала и приведенной стоимостью оттоков капитала за некоторый период, и ее обычно подсчитывают для принятия решения об осуществлении проекта. Измеряя NPV на протяжении проекта, команда проекта может установить, имеет ли смысл продолжать инвестировать организационные ресурсы.

прогнозы;

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

К количественным прогнозам относятся следующие:
▶ Прогноз до завершения (ETC). Измерение управления освоенным объемом, прогнозирующее ожидаемую стоимость завершения всей оставшейся работы проекта. Существует множество различных способов подсчитать прогноз до завершения. Исходя из того, что исполнение в прошлом характеризует исполнение в будущем, распространенным измерением является вычитание освоенного объема из бюджета по завершении с последующим делением на индекс выполнения стоимости.
▶ Оценка по завершении (EAC). Данное измерение управления освоенным объемом прогнозирует общую ожидаемую стоимость завершения всей работы. Существует множество различных способов подсчитать оценку по завершении. Исходя из того, что исполнение в прошлом характеризует исполнение в будущем, распространенным измерением является деление бюджета по завершении на индекс исполнения стоимости.
▶ Отклонение по завершении (VAC). Измерение управления освоенным объемом, прогнозирующее объем дефицита или профицита бюджета. Выражается как разница между бюджетом по завершении (BAC) и оценкой по завершении (EAC).
▶ Индекс производительности до завершения (TCPI). Измерение управления освоенным объемом, определяющее исполнение стоимости, требуемое для достижения указанной цели управления. TCPI выражается как отношение стоимости завершения всей незавершенной работы к оставшемуся бюджету.
▶ Регрессионный анализ. Аналитический метод, при котором ряд входных переменных изучается относительно соответствующих им результатов на выходе с целью создания математической или статистической зависимости. Данное
отношение можно использовать, чтобы предположить исполнение в будущем.
▶ Анализ производительности. Данный аналитический метод оценивает количество элементов, выполняемых в фиксированные сроки. Команды проектов, использующие адаптивные практики, применяют такие метрики производительности, как сравнение завершенных свойств с оставшимися, скорость и относительные единицы, для оценки своего прогресса и получения вероятных дат завершения. Применение оценок длительности и скорости выгорания в стабильных командах проектов может помочь в проверке и обновлении оценок стоимости.

28.png

заинтересованные стороны.

Удовлетворенность заинтересованных сторон можно измерить с помощью опросов или вывести ее наличие или недостаток из соответствующих метрик, таких как:
Индекс потребительской лояльности (NPS). Индекс потребительской лояльности измеряет степень готовности заинтересованной стороны (обычно заказчика) рекомендовать продукт или услугу другим. Он имеет диапазон
от -100 до +100. Высокий индекс потребительской лояльности не только измеряет удовлетворенность брендом, продуктом или услугой, но и показывает лояльность заказчиков.
Диаграмма настроений. Диаграмма настроений помогает отследить настроение или реакции группы крайне важных заинтересованных сторон — команды проекта. В конце каждого дня члены команды проекта с помощью цветов, чисел или эмодзи выражают свое настроение. На рисунке ниже диаграмма настроений с применением эмодзи. 
Моральный климат. Поскольку доски настроений могут быть субъективны, другим вариантом является измерение морального климата команды проекта. Для этого используются опросы, в которых членам команды проекта предлагается по шкале от 1 до 5 оценить степень своего согласия с утверждениями, такими как:
▹ Я считаю, что моя работа полезна в достижении общих конечных результатов.
▹ Я чувствую, что меня ценят.
▹ Я доволен (-льна) коллективной работой в моей команде проекта.
Текучесть кадров. Другим способом мониторинга морального климата является оценка незапланированной текучести кадров в команде проекта. Высокая текучесть может говорить о плохом моральном климате.

29.png

Представление информации

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

Информационная панель — это распространенный способ представления большого  количества информации о метриках. Такие панели обычно собирают информацию электронным способом и формируют графики, отражающие статус. Информационные панели часто содержат информацию, представленную в виде светофорных схем (также известных как RAG-схемы, где RAG — это сокращение от «красный — желтый — зеленый»), линейчатых диаграмм, круговых диаграмм и контрольных карт. Может использоваться текстовое пояснение всех измерений, находящихся вне установленных порогов.

30.png

Информационные доски, также называемые big visible chart (BVC), — это видимые физические дисплеи, демонстрирующие информацию остальной части организации, обеспечивая своевременный обмен знаниями. Они располагаются в местах, где людям легко увидеть информацию. BVC должны легко обновляться, и делать это следует часто.  Они часто являются «простыми в изготовлении и легкими в использовании», то есть их чаще обслуживают вручную, а не формируют электронным способом. 

31.png
В средах бережливого производства информационные доски называют визуальным контролем. Визуальный контроль иллюстрирует процессы и позволяет легко сравнить фактическое исполнение с ожидаемым. Он показывает процесс с помощью визуальных индикаторов. Визуальный контроль можно использовать для любого уровня информации, от поставленной бизнес-ценности до начавшихся задач. 
▶ Доски задач. Такая доска позволяет любому сразу увидеть статус определенной задачи или количество задач на каждой стадии работы. Для обозначения различных типов работы можно использовать разноцветные стикеры, а для количества дней
нахождения задачи в текущем положении — точки. Проекты на основе потоков, например с использованием досок «канбан», могутиспользовать данные доски для ограничения количества незавершенной работы.
▶ Диаграммы выгорания. Диаграммы выгорания, включая диаграммы сгорания, могут отражать скорость команды проекта. Скорость измеряет темп продуктивности, с которым поставляемые результаты производятся, проходят подтверждение
и принимаются в пределах установленного интервала. Диаграмма выгорания может отслеживать количество выполненной работы в сравнении с ожидаемым количеством работы, которую нужно сделать. На диаграмме сгорания
может быть показано количество оставшихся относительных единиц или снижение подверженности риску, которого удалось добиться.
▶ Другие типы диаграмм. Визуальные диаграммы также могут включать в себя такую информацию, как список препятствий, описывающий препятствия выполнению работы, степень их серьезности и принятые для устранения препятствия меры.

32.png

33.png

Недостатки измерений

Знание данных недостатков может помочь минимизировать их негативный эффект. 
▶ Хоторнский эффект. Хоторнский эффект подразумевает, что само по себе измерение чего-либо влияет на поведение. Следовательно, необходимо уделить внимание выработке метрик. 
▶ Пустая метрика. Пустая метрика — это измерение, показывающее данные, но не предоставляющее информации, полезной в принятии решений.
▶ Деморализация. Если поставлены недостижимые измерения и цели, моральный климат в команде проекта может ухудшиться при постоянных неудачах членов команды в достижении целей. Постановка завышенных целей и побудительных
измерений приемлема, однако работники также хотели бы, чтобы их упорный труд ценили. 
▶ Неправильное использование метрик. Независимо от того, какие метрики используются для измерения исполнения, существует возможность для людей искажать измерения или фокусироваться на неправильных вещах. 
▶ Предвзятость подтверждения. Люди склонны искать и видеть информацию, поддерживающую уже имеющуюся у них точку зрения. Это может приводить к ложной интерпретации данных.
▶ Сравнение корреляции и причинности. Распространенной ошибкой в интерпретации данных измерений является принятие корреляции между двумя переменными за причинно-следственную связь между ними. 

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

Поиск и решение проблем с исполнением

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

34.png

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

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

Рост и улучшения

Для оптимизации исполнения и эффективности проекта необходимо измерять и доводить информацию, которая:

▶ позволит команде проекта обучаться;
▶ будет способствовать принятию решения;
▶ улучшит некоторый аспект продукта или исполнения проекта;
▶ поможет избежать проблемы;
▶ предотвратит ухудшение исполнения.

Правильно примененные измерения способствуют созданию командой проекта бизнес-ценности и достижение целей проекта и исполнения

Проверка результатов в домене:

35.png

Домен исполнения «Неопределенность»

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

36.png

К домену исполнения относятся следующие определения:

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

Общая неопределенность

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

Неоднозначность

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

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

Сложность

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

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

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

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

Изменчивость

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

Риск

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

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

Угроза — это событие или условие, наступление которого отрицательно сказывается на одной или нескольких целях проекта. При работе с угрозами рассматриваются пять альтернативных стратегий:
▶ Уклонение. Уклонение от угрозы — это стратегия, когда команда проекта предпринимает меры с целью устранить угрозу или защитить проект от ее воздействия.
▶ Эскалация. Стратегия эскалации является целесообразной в случаях, когда команда или спонсор проекта согласны, что угроза выходит за рамки содержания проекта или что предлагаемые меры реагирования выходят за рамки полномочий руководителя проекта.
▶ Передача. Передача состоит в переходе владения угрозой к третьей стороне, которая берет на себя управление риском и несет последствия в случае реализации угрозы.
▶ Снижение. Стратегия снижения уровня угрозы предполагает меры по уменьшению вероятности наступления и/или воздействия угрозы. Ранние меры по снижению угрозы во многих случаях оказываются более результативными, чем попытки ликвидации ущерба после реализации угрозы.
▶ Принятие. Принятие угрозы означает осознание существования угрозы без планирования проактивных мер. Активное принятие риска может включать разработку запасного плана на случай возникновения события, а также пассивное принятие, не подразумевающее никаких действий.
Меры реагирования на конкретную угрозу могут включать несколько стратегий. Например, если угрозы нельзя избежать, ее можно снизить до уровня, на котором ее допустимо передать или принять.
Целью внедрения мер реагирования на угрозы является снижение количества отрицательного риска. 

37.png

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

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

Пример кривой ROI с поправками на риск:

38.png

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

Управленческий резерв —  это категория бюджета, рассчитанная на неизвестные события, такие как незапланированная работа в пределах содержания.

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

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

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

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

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

Проверка результатов в домене:

39.png

Адаптация

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

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

Аспекты проекта, которые можно адаптировать, включают в себя:

  • выбор жизненного цикла и подхода к разработке

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

  • процессы

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

  • вовлечение

Адаптация вовлечения участвующих в проекте людей включает в себя следующее:
▶ Люди. Сюда относится оценка навыков и возможностей руководства и команды проекта с последующим выбором, кого из них нужно привлечь и в каком качестве, исходя из типа проекта и условий работы. Например, при осуществлении сложных
или ограниченных во времени проектов привлечение имеющих большой опыт членов команды проекта более целесообразно, чем неопытных специалистов.
▶ Наделение полномочиями. Наделение полномочиями состоит в выборе, какие сферы ответственности и формы принятия локальных решений следует передать команде проекта. Некоторые среды и способности членов команды проекта дают основания для наделения большими полномочиями. В других ситуациях могут быть более целесообразны ограниченные полномочия при большем надзоре и руководстве.
▶ Интеграция. В состав команды проектов могут входить сотрудники из предприятий, с которыми заключены договоры, компаний — торговых партнеров и других сторонних организаций помимо персонала, состоящего в штате спонсорской организации. При адаптации решается вопрос, как создать единую команду проекта из разнообразного состава участников с целью обеспечить оптимальные эффективность и результативность команды проекта и реализацию конечных результатов проекта.

  • инструменты

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

  • методы и артефакты

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

Процесс адаптации

1.png

  • Выбор начального подхода к разработке

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

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

  • Адаптация для организации

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

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

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

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

2.png

Адаптация, которая влияет на работу только команды проекта (например, когда они проводят внутренние совещания, кто где работает и т. п.), требует меньшего надзора в сравнении с адаптацией, которая затрагивает внешние группы (например, как и когда в работу включаются другие подразделения и т. п.).
В силу этого адаптация внутри проекта может быть одобрена на уровне руководителя проекта, а адаптационные изменения, которые влияют на работу внешних групп, могут требовать одобрения офисом управления проектами (ОУП) или офисом поставки ценности (value delivery office, VDO) .
ОУП или VDO могут оказывать командам проекта содействие в процессе адаптации их подходов, предлагая идеи и решения из опыта работы других команд проектов.

  • Адаптация для проекта

На проект оказывают влияние многие атрибуты. К ним, среди прочего, относятся следующие:

продукт/поставляемый результат;

▶ Соответствие стандартам / критичность. В какой мере требуются строгий процесс и обеспечение качества?
▶ Тип продукта / поставляемого результата. Насколько хорошо продукт известен и материален, например, является чем-то, что легко распознать и описать, как, например, здание? Или это что-либо нематериальное, например программный продукт или разработка нового лекарственного средства?
▶ Отраслевой рынок. Для какого рынка предназначен данный продукт или поставляемый результат проекта? Характеризуется ли этот рынок строгим регулированием, высокой динамикой или медленным развитием? Какова на рынке ситуация с конкурентами и действующими участниками рынка?
▶ Технология. Является ли данная технология стабильной и хорошо проработанной, или она быстро развивается с риском устаревания?
▶ Срок. Рассчитан ли проект на короткий срок, например на несколько недель или месяцев, или на длительный срок, то есть на несколько лет?
▶ Стабильность требований. Насколько вероятно внесение изменений в основные требования?
▶ Безопасность. Имеются ли элементы в бизнесе по производству данного продукта, которые являются конфиденциальными или секретными?
▶ Инкрементная поставка. Может ли команда проекта инкрементно разрабатывать продукт и получать отзывы о нем от заинтересованных сторон или продукт трудно поддается оценке до этапа, близкого к окончанию работы?

команда проекта;

▶Размер команды проекта. Сколько человек с полной и неполной занятостью будут работать по проекту?
▶ Географическое размещение команды проекта. Где преимущественно члены команды находятся географически? Будут ли некоторые или все из членов команды работать удаленно или располагаться совместно?
▶ Организационное размещение. Где находятся группы поддержки команды и другие заинтересованные стороны?
▶ Опыт команды проекта. Имеют ли члены команды проекта какой-то опыт работы в отрасли, в данной организации или друг с другом? Имеют ли они навыки, инструменты и технологию, необходимые для рассматриваемого проекта?
▶ Доступ к клиенту. Требуется ли на практике иметь частую и своевременную обратную связь от клиентов или их представителей?

культура.

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

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

3.png

Распространенные проблемы и  предложения по адаптации:

4.png

Адаптация доменов исполнения

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

  • Заинтересованные стороны

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

  • Команда проекта

▶ В каких местах физически находятся члены команды проекта? Находятся ли члены команды проекта в одном и том же месте? Находятся ли члены команды проекта в одном и том же географическом регионе? Находятся ли члены команды проекта в разных часовых поясах?
▶ Имеют ли члены команды проекта разные точки зрения и культурные особенности?
▶ Как будут идентифицированы члены команды проекта для данного проекта? Работают ли члены команды проекта в режиме полного или неполного рабочего дня? Доступны ли подрядчики, которые могут выполнить требуемые работы?
▶ Имеет ли команда проекта сложившуюся культуру? Какое влияние существующая культура окажет на адаптацию, и какое влияние адаптация окажет на существующую культуру?
▶ Как осуществляется управление развитием команды проекта в рамках проекта? Имеются ли в организации инструменты для управления развитием команды проекта или требуется создать новые?
▶ Есть ли в команде проекта члены, имеющие особые потребности? Требуется ли команде проекта специальное обучение для того, чтобы справляться с разнообразием?

  • Подход к разработке и ЖЦ

▶ Какой подход к разработке является целесообразным для данного продукта, услуги или результата? Если адаптивный, то как следует разрабатывать проект — инкрементно или итеративно? Или лучше использовать гибридный подход?
▶ Какой жизненный цикл является целесообразным для данного проекта? Какие фазы должен включать в себя жизненный цикл проекта?
▶ Имеются ли в организации формальные или неформальные политики, процедуры и руководящие указания в области аудита и руководства?

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

▶ Какое влияние внутренние и внешние факторы среды могут оказывать на проект и поставляемый в его рамках результат?
▶ Какие факторы оказывают влияние на длительности (например, взаимосвязь между имеющимся ресурсом и его производительностью)?
▶ Имеет ли организация формальные или неформальные политики, процедуры и указания в отношении оценки стоимости и бюджетирования?
▶ Как организация производит оценку стоимости в случае использования адаптивных подходов?
▶ Предполагается ли одна основная закупка или многократные закупки в разное время у разных продавцов, которые увеличивают сложность процессов закупок?
▶ Интегрированы ли местные законы и нормативные акты в сфере закупочной деятельности в политики организации по закупкам? Как это отражается на требованиях к аудиту договоров?

  • Работа проекта

▶ Какие процессы управления наиболее результативны с учетом особенностей данной организационной культуры, сложности проекта и других факторов проекта?
▶ Как будет осуществляться управление знаниями в целях поощрения формирования совместной рабочей среды?
▶ Какую информацию следует собирать в ходе реализации и по завершении проекта? Как будут организованы сбор информации и работа с нею? Какая технология доступна для разработки, записи, передачи, поиска / извлечения, отслеживания и хранения информации и артефактов?
▶ Будут ли историческая информация и извлеченные уроки доступны будущим проектам?
▶ Имеется ли в организации формальный репозиторий для управления знаниями, который команда проекта должна использовать и который постоянно находится в ее распоряжении?

  • Поставка

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

  • Неопределенность

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

  • Измерение

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

Модели, методы и артефакты

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

Модель — это стратегия мышления, объясняющая процесс, фреймворк или явление.

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

Артефакт может быть шаблоном, документом, выходом или поставляемым результатом проекта.

5.png

Общепринятые артефакты

Артефакт — это шаблон, документ, выход или поставляемый результат проекта.

  • Артефакты стратегии

Документы, созданные до или в начале проекта, которые включают в себя информацию о стратегии, бизнесе или высокоуровневую информацию по проекту. Артефакты стратегии разрабатываются в начале проекта и обычно не меняются, хотя и могут быть пересмотрены на любом этапе проекта.
▶ Бизнес-кейс. Бизнес-кейс — это определение экономической ценности от реализации предлагаемого проекта, которая может включать как финансовые, так и нефинансовые выгоды.
▶ Канва бизнес-модели. Этот артефакт представляет собой одностраничный визуальный обзор с описанием предложения ценности, инфраструктуры, заказчиков и финансов. Такие артефакты часто используются в бережливых стартапах.
▶ Резюме проекта. Резюме проекта — это высокоуровневый обзор целей, поставляемых результатов и процессов проекта.
▶ Устав проекта. Устав проекта — это документ, выпущенный инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта.
▶ Описание видения проекта. Этот документ представляет собой краткое высокоуровневое описание проекта с указанием его цели. Он призван мотивировать команду внести свой вклад в проект.
▶ Дорожная карта. Это высокоуровневый временной график, на котором графически представлены такие вещи, как «контрольные события», «существенные события», «обзоры» и «точки принятия решений».

  • Журналы и реестры

Журналы и реестры используются для документирования постоянно меняющихся аспектов проекта. Они обновляются на протяжении всего проекта. Термины «журнал» и «реестр» иногда могут быть взаимозаменяемыми. 
▶ Журнал допущений. Допущение — это фактор, который считается верным, реальным или определенным без предоставления доказательств и без демонстрации. Ограничение — фактор, ограничивающий возможности для управления проектом, программой, портфелем или процессом. Журнал допущений используется для записи всех допущений и ограничений на всем протяжении проекта.
▶ Бэклог. Бэклог — это упорядоченный перечень всех работ, которые предстоит выполнить. Проекты могут содержать бэклог продуктов, бэклог требований, бэклог препятствий и т. д. Элементы бэклога располагаются в приоритетном порядке. Затем составляется приоритизированное расписание работ для предстоящих итераций.
▶ Журнал изменений. Журнал изменений — это исчерпывающий список изменений, предоставленных в ходе проекта, и их текущий статус. Изменение может касаться какого-либо формально контролируемого поставляемого результата, компонента плана управления проектом или документа проекта.
▶ Журнал проблем. Проблема — это текущее состояние или ситуация, которые могут повлиять на цели проекта. Журнал проблем используется для документирования и мониторинга информации об активных проблемах. Дальнейшее реагирование и решение проблем поручается ответственному лицу.
▶ Реестр извлеченных уроков. Реестр извлеченных уроков используется для регистрации знаний, полученных в ходе реализации проекта, его фазы или итерации, с тем чтобы их можно было применять в целях совершенствования работы команды проекта и (или) организации в будущем.
▶ Бэклог с поправками на риск. Бэклог с поправками на риск — это бэклог, который включает в себя работы по продукту и действия, направленные на угрозы и возможности.
▶ Реестр рисков. Реестр рисков — это репозиторий, в котором записываются выходы процессов управления рисками. Реестр рисков может содержать информацию о лице, ответственном за управление риском, вероятности, воздействии и оценке риска,  планируемых мерах реагирования на риск и другую информацию для высокоуровневого представления отдельных рисков.
▶ Реестр заинтересованных сторон. Реестр заинтересованных сторон содержит информацию о заинтересованных сторонах проекта, включая их оценку и классификацию.

  • Планы

План — это предлагаемое средство достижения некоторой цели. Команды разрабатывают планы по отдельным аспектам проекта и (или) объединяют всю эту информацию в общий план управления проектом. Планы обычно представляют собой письменные документы, но также могут быть изображены на визуальной или виртуальной доске.
▶ План управления изменениями. План управления изменениями — это компонент плана управления проектом, в котором учреждается совет по контролю изменений, документируется объем его полномочий и описывается, каким образом будет реализована система контроля изменений.
▶ План управления коммуникациями. Это компонент плана управления проектом, программой или портфелем, в котором описывается, как, когда и кто будет администрировать и распространять информацию о проекте.
▶ План управления стоимостью. Это компонент плана управления проектом или программой, описывающий способы планирования, структурирования и контроля стоимости.
▶ План итерации. Это подробный план текущей итерации.
▶ План управления закупками. Это компонент плана управления проектом или программой, который описывает, каким образом команда проекта будет приобретать товары и услуги у сторонней исполняющей организации.
▶ План управления проектом. План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль, а также закрытие.
▶ План управления качеством. Это компонент плана управления проектом или программой, описывающий, каким образом будет обеспечиваться выполнение существующих политик, процедур и руководящих принципов для достижения целей в области качества.
▶ План релиза. Этот план определяет ожидания в отношении дат, свойств и (или) конечных результатов, которые должны быть поставлены на протяжении нескольких итераций.
▶ План управления требованиями. Это компонент плана управления проектом или программой, описывающий способы анализа, документирования требований и управления ими.
▶ План управления ресурсами. Это компонент плана управления проектом, который описывает, как ресурсы проекта приобретаются, выделяются, отслеживаются и контролируются.
▶ План управления рисками. Это компонент плана управления проектом, программой или портфелем, описывающий характер структурирования операций по управлению рисками и порядок их выполнения.
▶ План управления содержанием. Это компонент плана управления проектом или программой, описывающий, каким образом содержание будет определяться, разрабатываться, отслеживаться, контролироваться и подтверждаться.
▶ План управления расписанием. Это компонент плана управления проектом или программой, устанавливающий критерии и операции по разработке, мониторингу расписания и контролю за ним.
▶ План вовлечения заинтересованных сторон. Это компонент плана управления проектом или программой, определяющий стратегии и действия, необходимые для содействия продуктивному вовлечению заинтересованных сторон в процесс принятия решений и исполнения работ по проекту или программе.
▶ План тестирования. Этот документ описывает поставляемые результаты, которые подлежат тестированию; тесты, которые нужно выполнить, и процессы, которые будут применяться при тестировании. Он формирует основу формального тестирования компонентов и поставляемых результатов.

  • Иерархические диаграммы

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

  • Базовые планы

Базовый план — это одобренная версия продукта или плана работ. Для выявления отклонений реальное исполнение сравнивается с базовым планом.
▶ Бюджет. Бюджет — это одобренная оценка проекта, любого компонента иерархической структуры работ (ИСР) или какой-либо операции расписания.
▶ Расписание контрольных событий. Этот тип расписания представляет собой контрольные события с запланированными датами.
▶ Базовый план исполнения. Интегрированные базовые планы по содержанию и стоимости, а также базовое расписание используются для сравнения, чтобы регулировать, измерять и контролировать исполнение проекта.
▶ Расписание проекта. Расписание проекта — это выход модели расписания, представляющий взаимосвязанные операции с запланированными датами, длительностями, контрольными событиями и ресурсами.
▶ Базовый план по содержанию. Этот тип базового плана представляет собой одобренную версию описания содержания, иерархической структуры работ (ИСР) и связанного с ними словаря ИСР, которая может быть изменена с помощью формальных процедур контроля изменений и используется как основа для сравнения с фактическими результатами.

  • Визуальные данные и информация

Визуальные данные и информация — это артефакты, которые служат для организации и представления данных и информации в визуальной форме, например схемы, графики, матрицы и диаграммы. Визуализация данных упрощает их понимание и преобразование в информацию. Визуальные артефакты часто создаются после сбора и анализа данных. Эти артефакты могут помочь в принятии решений и приоритезации.
▶ Диаграмма сходства. На такой диаграмме показано большое количество идей с разбивкой по группам с целью обзора и анализа.
▶ Диаграмма сгорания/выгорания. Это графическое представление невыполненных работ, определенных для исполнения в данных временных рамках, или выполненных работ, необходимых для осуществления релиза продукта или поставляемого результата.
▶ Диаграмма причинно-следственных связей. Это визуальное представление, помогающее проследить возникновение нежелательного эффекта вплоть до его первопричины.
▶ Диаграмма суммарного потока (CFD). На этой диаграмме отражены завершенные за определенный период времени свойства; свойства в разработке; а также свойства, включенные в бэклог. Она также может содержать свойства в промежуточном
состоянии, например разработанные, но еще не созданные свойства, свойства на стадии обеспечения качества или свойства на стадии тестирования.
▶ Диаграмма времени цикла. На этой диаграмме показано среднее время цикла элементов, завершенных в ходе работы за определенный период времени. Она может быть представлена в виде диаграммы разброса или линейчатой диаграммы.
▶ Информационные панели. Этот набор диаграмм и графиков отражает прогресс или исполнение в сравнении с важными измерениями проекта.
▶ Блок-схема. На этой диаграмме отображены входы, действия и выходы одного или нескольких процессов в системе.
▶ Диаграмма Ганта. Это линейчатая диаграмма, относящаяся к расписанию, в которой операции перечислены на вертикальной оси, даты приведены на горизонтальной оси, а длительность операций показана в виде горизонтальных полос, расположенных в соответствии с датами старта и финиша.
▶ Гистограмма. На этой линейчатой диаграмме показано графическое отображение числовых данных.
▶ Информационная доска. Это видимый физический дисплей, который представляет информацию остальной части организации, обеспечивая своевременный обмен знаниями.
▶ Диаграмма времени выполнения. Это диаграмма, показывающая тенденцию в изменении за определенный период среднего времени выполнения завершенных элементов в работе. Она может быть представлена в виде диаграммы разброса или линейчатой диаграммы.
▶ Матрица приоритезации. Это диаграмма разброса, где горизонтальная ось представляет трудозатраты, а вертикальная ось — ценность, с разделением на четыре квадранта для классификации элементов в порядке приоритета.
▶ Диаграмма сети расписания проекта. Это графическое отображение логических связей между операциями расписания проекта.
▶ Матрица отслеживания требований. Это таблица, связывающая требования к продукту, начиная от их создания и заканчивая предоставлением соответствующих им поставляемых результатов.
▶ Матрица ответственности (RAM). Это таблица, показывающая ресурсы проекта, назначенные для каждого пакета работ. Диаграмма RACI часто используется для того, чтобы показать заинтересованные стороны, которые несут ответственность, утверждают, с которыми консультируются, которых информируют или которые связаны с операциями, решениями и поставляемыми результатами проекта.
▶ Диаграмма разброса. На этой диаграмме показано отношение между двумя переменными.
▶ S-кривая. На этом графике показаны совокупные затраты на протяжении определенного периода времени.
▶ Матрица оценки уровня вовлечения заинтересованных сторон. Эта матрица сравнивает текущий и желаемый уровень вовлечения заинтересованных сторон.
▶ Карта историй. Карта историй — это визуальная модель всех свойств и функциональности, намеченных для данного продукта, которая создается с целью дать команде проекта целостное представление о том, что и для чего она создает.
▶ График производительности. На этом графике показаны принятые поставляемые результаты за определенный период времени. Он может быть представлен в виде диаграммы разброса или линейчатой диаграммы.
▶ Сценарий использования. Этот артефакт описывает и разъясняет взаимодействие пользователя с системой ради достижения конкретной цели.
▶ Карта потока ценности. Это метод бережливого производства, используемый для документирования, анализа и совершенствования потока информации или материалов, необходимых для производства продукта или услуги для потребителя. Карту потока ценности можно использовать для выявления потерь.
▶ График скорости. Этот график отражает темп, с которым поставляемые результаты производятся, проходят подтверждение и принимаются в пределах установленного интервала.

  • Отчеты

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

  • Соглашения и договоры

Соглашение — это любой документ или метод коммуникаций, определяющий первоначальные намерения сторон. Соглашения в рамках проектов принимают форму договоров или другие установленные формы. Договор — это обоюдное соглашение, обязывающее продавца предоставить определенный продукт, услугу или результат, а покупателя — оплатить его. Существуют разные типы договоров, некоторые из которых подпадают под категорию договоров с фиксированной ценой или с возмещением затрат.
▶ Договоры с фиксированной ценой. Эта категория договоров предусматривает фиксированную стоимость четко определенного продукта, услуги или результата. К ней относятся, помимо прочего, договоры с твердой фиксированной ценой (FFP), договоры с фиксированной ценой и поощрительным вознаграждением (FPIF) и договоры с фиксированной ценой и оговоркой о возможной корректировке цены (FPEPA).
▶ Договоры с возмещением затрат. Эта категория договоров подразумевает оплату продавцу всех фактических затрат, понесенных в результате исполнения работы, плюс вознаграждение, составляющее его прибыль. Такие договоры часто используются, когда содержание проекта определено нечетко или часто меняется. К этой категории относятся договоры с возмещением затрат плюс премиальное вознаграждение (CPAF), договоры с возмещением затрат плюс фиксированное вознаграждение (CPFF) и договоры с возмещением затрат плюс поощрительное вознаграждение (CPIF).
▶ Договор «время и материалы» (T&M). Такой договор подразумевает фиксированную ставку без точного описания работ. Он часто используется при дополнительном наборе персонала, привлечении экспертов по предметным областям и для другой сторонней поддержки.
▶ Неопределенная поставка неопределенного количества (IDIQ). Это договор на поставку неустановленного количества продуктов или услуг в рамках установленного минимума и максимума за установленный срок. Такие договоры могут использоваться в сферах архитектуры, инженерного дела или информационных технологий.
▶ Прочие соглашения. К другим типам соглашений относятся, помимо прочего, меморандум о взаимопонимании (MOU), меморандум о соглашении (МОА), соглашение об уровне услуг (SLA) и основное закупочное соглашение (ВОА).

  • Прочие артефакты

Документы и поставляемые результаты, описанные в данном разделе, не подпадают под определенную категорию; однако это важные артефакты, которые применяются в самых различных целях.
▶ Список операций. Это документированное табличное представление операций расписания, отображающее описание операции, идентификатор операции и описание содержания работы, достаточно подробное для того, чтобы члены команды проекта понимали, какая работа должна быть выполнена.
▶ Документация по предложениям. Документация по предложениям используется для запроса предложений от потенциальных продавцов. В зависимости от того, какие товары или услуги требуются, документация по предложениям может включать, помимо прочего:
▹ запрос информации (RFI);
▹ запрос расценок (RFQ);
▹ запрос предложений (RFP).
▶ Метрики. Метрики описывают атрибут и то, как его измерить.
▶ Календарь проекта. Этот календарь определяет рабочие дни и смены, доступные для выполнения запланированных операций.
▶ Документация по требованиям. Этот документ представляет собой запись требований к продуктам и важной информации, необходимой для управления требованиями, включая соответствующую категорию, приоритет и критерии приемки.
▶ Устав команды проекта. Этот документ содержит ценности команды проекта, соглашения и рабочие руководящие принципы, а также устанавливает четкие ожидания в отношении приемлемого поведения членов команды проекта.
▶ Пользовательская история. Пользовательская история — это краткое описание конечного результата для определенного пользователя, которое декларирует уточнение деталей в ходе обсуждения.

Оптимальные сочетания доменов исполнения и артефактов:
6-.png
7-.png
8-.png

Общепринятые методы

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

  • Сбор и анализ данных

Методы сбора и анализа данных используются для сбора, оценки и анализа данных и информации для более глубокого понимания ситуации. 
▶ Анализ альтернатив. Анализ альтернатив используется для оценки выявленных вариантов с целью выбора вариантов или подходов, которые будут использоваться в работе над проектом.
▶ Анализ допущений и ограничений. Допущение — это фактор, который считается верным, реальным или определенным без предоставления доказательств и без демонстрации. Ограничение — ограничивающий фактор, влияющий на ход исполнения проекта, программы, портфеля или процесса. Такая форма анализа позволяет убедиться в том, что принятые допущения и ограничения интегрированы в планы проекта и документы, а также в их согласованности.
▶ Бенчмаркинг. Бенчмаркинг — это сравнение используемых или запланированных к использованию продуктов, процессов и практик с продуктами, процессами и практиками сопоставимых организаций для выявления лучших практик, генерирования идей в отношении улучшений и предоставления основы для измерения эффективности и результативности.
▶ Методы анализа бизнес-обоснования. Эта группа методов анализа связана с авторизацией или обоснованием проекта или решения. Конечные результаты следующих видов анализа часто используются в бизнес-кейсах для обоснования проекта:
▹ Период окупаемости. Период окупаемости — это время, необходимое для возврата инвестиций (как правило, месяцы или годы).
▹ Внутренняя норма доходности (internal rate of return, IRR). Внутренняя норма доходности — это прогнозируемая годовая доходность инвестиций в проект. При расчете приблизительных ожидаемых темпов роста проекта в процентном выражении  учитываются как первоначальные, так и текущие затраты.
▹ Окупаемость инвестиций (ROI). Окупаемость инвестиций — это окупаемость первоначальных инвестиций в процентном выражении. Она рассчитывается путем деления прогнозируемого среднего значения всех чистых выгод на первоначальные затраты.
▹ Чистая приведенная стоимость (NPV). Чистая приведенная стоимость — это будущая стоимость ожидаемых выгод, выраженная в стоимости этих выгод на момент инвестиций. Чистая приведенная стоимость учитывает текущие и будущие затраты, выгоды и инфляцию.
▹ Сравнительный анализ затрат и выгод. Сравнительный анализ затрат и выгод — это инструмент финансового анализа, используемый для определения выгод, получаемых в результате исполнения проекта, по отношению к затратам.
▶ Контрольный лист. Контрольный лист — это учетный лист, который может быть использован как контрольный список при сборе данных. Контрольные листы можно использовать для сбора и разбивки данных по категориям, а также для создания гистограмм и матриц.
▶ Стоимость качества. Стоимость качества включает все затраты, понесенные в течение срока службы продукта в результате вложений в предотвращение несоответствия требованиям, оценку продукта или услуги на соответствие требованиям, а также затраты, связанные с невыполнением требований.
▶ Анализ дерева решений. Анализ дерева решений — это метод построения диаграммы и расчета для оценки последствий цепи множественных вариантов в условиях неопределенности. Для заполнения ветвей дерева решений можно использовать информацию, полученную в результате анализа ожидаемой денежной стоимости.
▶ Анализ освоенного объема. Анализ освоенного объема — это метод, в котором используется набор измерений, связанных с содержанием, расписанием и затратами, для определения стоимости и расписания проекта.
▶ Ожидаемая денежная стоимость (expected monetary value, EMV). Ожидаемая денежная стоимость — это оценочная стоимость конечного результата, выраженная в денежных единицах. Этот показатель используется для количественного выражения стоимости неопределенности, например риска, или для сравнения стоимости альтернативных вариантов, которые не обязательно эквивалентны. Ожидаемая денежная стоимость рассчитывается путем умножения вероятности события на значение его  экономического воздействия в случае, если оно произойдет.
▶ Прогноз. Прогноз — это оценка или предсказание условий и будущих событий проекта на основании информации и знаний, доступных на момент прогнозирования. В качественных методах прогноза используются мнения и суждения экспертов по предметным областям. Количественный прогноз для прогнозирования будущего исполнения использует информацию о прошлых событиях. В причинно-следственном или эконометрическом прогнозировании, например в регрессионном анализе,  идентифицируются переменные, которые могут оказать значительное воздействие на будущие конечные результаты.
▶ Диаграмма влияния. Эта диаграмма является графическим представлением ситуаций, отображающим причинно-следственные связи, последовательности событий во времени и другие отношения между переменными и конечными результатами.
▶ Оценка жизненного цикла. Такая оценка представляет собой инструмент, используемый для оценки совокупного воздействия продукта, процесса или системы на окружающую среду. Она учитывает все аспекты изготовления поставляемого результата проекта: от происхождения материалов, примененных в поставляемом результате, до его распространения и итоговой утилизации.
▶ Анализ «производить или покупать». Анализ «производить или покупать» — процесс сбора и организации информации о требованиях к продукту, а также анализа данных требований с учетом доступных альтернатив, например покупка или внутреннее производство продукта.
▶ Матрица вероятности и воздействия. Матрица вероятности и воздействия — это таблица, отображающая вероятность наступления каждого риска и его воздействие на цели проекта в случае наступления данного риска.
▶ Анализ процессов. Данный вид анализа представляет собой систематический обзор этапов и процедур выполнения операции.
▶ Регрессионный анализ. Регрессионный анализ — это аналитический метод, при котором ряд входных переменных изучается относительно соответствующих им результатов на выходе с целью создания математической или статистической зависимости.
▶ Анализ резервов. Этот метод используется для оценки величины риска проекта и объема резерва расписания и резерва бюджета с целью определить, является ли резерв достаточным относительно остаточного риска. Резерв помогает снизить риск до приемлемого уровня.
▶ Анализ первопричины. Этот аналитический метод призван найти основную причину отклонения, дефекта или риска. Одной первопричиной могут быть вызваны сразу несколько отклонений, дефектов или рисков.
▶ Анализ чувствительности. Этот аналитический метод призван определить, какие индивидуальные риски проекта или другие источники неопределенности оказывают наиболее сильное воздействие на конечные результаты проекта, сопоставляя вариации результатов проекта с вариациями в элементах модели количественного анализа рисков.
▶ Имитация. Этот аналитический метод моделирует комбинированное действие неопределенностей для оценки их потенциального воздействия на цели. Имитация методом Монте-Карло — это метод определения потенциальных воздействий риска
и неопределенности при помощи множественных итераций компьютерной модели для формирования распределения вероятностей ряда результатов, которые могут быть получены в результате принятия решения или исполнения плана действий.
▶ Анализ заинтересованных сторон. Этот метод включает систематический сбор и анализ количественной и качественной информации о заинтересованных сторонах с целью определения того, чьи интересы необходимо учесть в проекте.
▶ SWOT-анализ. SWOT-анализ позволяет оценить сильные и слабые стороны, возможности и угрозы организации, проекта или варианта.
▶ Анализ тенденций. В анализе тенденций используются математические модели для прогнозирования результатов в будущем на основании исторических данных.
▶ Картирование потока ценности. Картирование потока ценности — это метод бережливого производства, используемый для документирования, анализа и совершенствования потока информации или материалов, необходимых для производства продукта или услуги для потребителя.
▶ Анализ отклонений. Анализ отклонений — это метод определения причины и степени различий между базовым планом и фактическим исполнением.
▶ Анализ сценариев «что если». Этот аналитический метод оценивает сценарии с целью прогнозирования их воздействия на цели проекта.

  • Оценка

Методы оценки применяются для формирования примерной оценки объема работ, времени исполнения или затрат проекта.
▶ Группировка по сходству. Группировка по сходству позволяет классифицировать элементы по категориям или группам на основании сходства. К распространенным группам по сходству относятся, например, размеры футболок и числа Фибоначчи.
▶ Оценка по аналогам. Оценка по аналогам позволяет оценить длительность или стоимость операции или проекта с использованием исторических данных аналогичной операции или проекта.
▶ Функциональная точка. Функциональная точка — это оценка объема бизнес-функциональности в информационной системе. Функциональные точки используются для расчета измерения функционального размера (functional size measurement, FSM) программной системы.
▶ Многоточечная оценка. Многоточечная оценка — это метод оценки стоимости или длительности, при котором используется средняя или взвешенная средняя величина оптимистичной, пессимистичной и наиболее вероятной оценки в тех случаях, когда существует неопределенность в оценках отдельных операций.
▶ Параметрическая оценка. При параметрической оценке используется алгоритм вычисления стоимости или длительности на основе исторических данных и параметров проекта.
▶ Сравнительная оценка. Сравнительная оценка применяется для формирования оценок путем сравнения с аналогичной совокупностью работ, принимая в расчет факторы трудозатрат, сложности и неопределенности. Она не обязательно основывается на абсолютных единицах затрат или времени. При сравнительной оценке часто используются такие безразмерные единицы измерений, как относительные единицы.
▶ Оценка по одной точке. Оценка по одной точке подразумевает использование данных для расчета единственного значения, которое отражает наиболее вероятный приблизительный прогноз. Оценка по одной точке противопоставляется оценке размаха, которая учитывает лучший и худший сценарии.
▶ Оценка относительных единиц. При оценке относительных единиц члены команды проекта распределяют абстрактные, но относительные единицы трудозатрат, необходимые для реализации некоторой пользовательской истории. Это позволяет команде проекта оценить сложность истории с учетом сложности, рисков и трудозатрат.
▶ Широкополосный метод Дельфи. Широкополосный метод Дельфи — это вариация метода оценки Дельфи, в рамках которого эксперты по предметным областям участвуют в нескольких раундах выработки оценок в индивидуальном порядке с обсуждением в команде проекта после каждого раунда вплоть до достижения консенсуса. В широкополосном методе Дельфи те, кто поставил самую высокую и самую низкую оценку, обосновывают свои решения, после чего все выставляют оценки повторно. Процесс повторяется до тех пор, пока оценки не сойдутся. Покер планирования — это вариация широкополосного метода Дельфи.

  • Совещания и мероприятия

Совещания — это важное средство вовлечения команды проекта и других заинтересованных сторон. Это основное средство коммуникации на протяжении всего проекта.
▶ Совершенствование бэклога. На совещании по совершенствованию бэклога выполняется последовательное уточнение содержания бэклога, а также пересмотр предусмотренных в нем приоритетов с целью определения работ, которые можно выполнить в рамках предстоящей итерации.
▶ Конференция участников тендера. Встречи с потенциальными продавцами до подготовки тендерной заявки или предложения с целью обеспечения того, чтобы потенциальные продавцы имели четкое и одинаковое представление о закупке. Также  известны как конференции подрядчиков, конференции поставщиков или предзаявочные конференции.
▶ Совет по контролю изменений. В совещаниях совета по контролю изменений принимает участие группа лиц, ответственных за анализ, оценку, одобрение, отсрочку или отклонение внесения изменений в проект. Решения, принятые на совещании, документируются и доводятся до сведения соответствующих заинтересованных сторон. Такое совещание также можно называть совещанием по контролю изменений.
▶ Ежедневная летучка. Ежедневная летучка — это краткое совещание по вопросам совместной работы, на котором команда проекта подводит итоги предыдущего дня, определяет задачи на текущий день и рассматривает имеющиеся или ожидаемые препятствия. Такие совещания также можно называть ежедневным скрамом.
▶ Планирование итерации. Совещание по планированию итерации используется для уточнения деталей элементов бэклога, критериев приемки, а также трудоемкости работ, необходимых для исполнения обязательств по предстоящей итерации. Такие совещания также можно называть совещаниями по планированию спринта.
▶ Обзор итерации. В конце итерации проводится обзор итерации для демонстрации работы, выполненной в ходе итерации. Такие совещания также можно называть обзором итогов спринта.
▶ Стартовое совещание. Стартовое совещание — это собрание членов команды проекта и других ключевых заинтересованных сторон в начале проекта с целью формального определения ожиданий, выработки общего понимания задач и начала работы. На нем запускается проект, фаза или итерация.
▶ Совещание по извлеченным урокам. Совещание по извлеченным урокам используется для выявления и обмена знаниями, полученными во время проекта, его фазы или итерации, с целью повышения результативности и эффективности команды проекта. На таком совещании можно обсудить ситуации, которые были разрешены не лучшим образом, а также хорошие практики и ситуации, которые привели к крайне благоприятным конечным результатам.
▶ Совещание по планированию. Совещание по планированию используется для составления, уточнения или пересмотра плана или планов и контроля за их соблюдением.
▶ Закрытие проекта. Совещание по закрытию проекта используется для окончательной приемки поставляемого результата спонсором, владельцем продукта или клиентом. Это совещание означает, что поставка продукта завершена.
▶ Обзорное совещание по проекту. Обзорное совещание по проекту — это мероприятие в конце фазы или проекта с целью анализа статуса, оценки поставленной ценности и определения готовности проекта к переходу к следующей фазе или передаче в операционную деятельность.
▶ Планирование релиза. На совещаниях по планированию релизов составляется высокоуровневый план в отношении релиза или передачи продукта, поставляемых результатов или инкремента ценности.
▶ Ретроспектива. Ретроспектива — это регулярно проводимый семинар, в ходе которого участники анализируют свою работу и полученные результаты с целью улучшения как процесса, так и самого продукта. Это вид совещания по извлечению уроков.
▶ Обзор рисков. Совещание по анализу статуса существующих рисков и идентификации новых. Такое совещание включает определение активности риска и наличия изменений в его атрибутах (например, вероятность, воздействие, срочность и т. д.). Проводится оценка результативности мер реагирования на риски, чтобы определить, нуждаются ли они в изменении. На этом совещании могут быть идентифицированы и проанализированы новые риски и закрыты риски, которые больше не активны. Переоценка рисков является примером совещания по обзору рисков.
▶ Совещание по статусу. Совещание по статусу — это запланированное на регулярной основе мероприятие для обмена информацией о текущем прогрессе проекта и его исполнении, а также для анализа этой информации.
▶ Управляющий комитет. Совещание, на котором высокопоставленные заинтересованные стороны дают направление и оказывают поддержку команде проекта, а также принимают решения по вопросам, не входящим в полномочия команды проекта.

  • Прочие методы

Методы, описанные в данном разделе, не подпадают под определенную категорию; тем не менее это распространенные методы, которые применяются в различных целях при работе над проектами.
▶ Картирование воздействия. Картирование воздействия — это метод стратегического планирования, который служит организации визуальной дорожной картой в ходе разработки продукта.
▶ Моделирование. Моделирование — это процесс создания упрощенного представления систем, решений или поставляемых результатов, например, прототипов, диаграмм или раскадровок. Моделирование может упростить дальнейший анализ благодаря выявлению пробелов в информации, недостатков в коммуникации или дополнительных требований.
▶ Индекс потребительской лояльности (NPS®). Показатель степени готовности клиентов рекомендовать продукты или услуги организации другим потребителям. Этот индекс используется в качестве косвенного индикатора общего уровня удовлетворенности клиента продуктом или услугой организации, а также степени его лояльности бренду.
▶ Схема приоритезации. Схема приоритезации — это методы, используемые для определения приоритетов портфеля, программы или проектных компонентов, а также требований, рисков, свойств или иной информации по продукту. Примеры: взвешенный анализ на основе множества критериев и метод MoSCoW (должно быть, следует иметь, желательно иметь и не хотелось бы иметь).
▶ Временные рамки. Временные рамки — это короткий фиксированный период времени, в течение которого работа должна быть завершена (например, 1 неделя, 2 недели или 1 месяц).

Оптимальные сочетания доменов исполнения и методов:
9--.png
10--.png

Общепринятые модели

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

  • Модели ситуационного лидерства

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

Модель ситуационного лидерства Бланшара

Модель ситуационного лидерства (Situational Leadership® II) Кена Бланшара измеряет развитие членов команды проекта, используя компетентность и приверженность в качестве двух основных переменных. Компетентность — это сочетание способностей, знаний и навыков. Приверженность говорит об уверенности и мотивации сотрудника. По мере роста компетентности и приверженности сотрудника стиль лидерства меняется от директивного к коучинговому, поддерживающему и  делегирующему в ответ на потребности сотрудника.
11---.png

Модель OSCAR

Модель коучинга и менторства OSCAR была разработана Карен Уитлворт (Karen Whittleworth) и Эндрю Гилбертом (Andrew Gilbert). Она помогает адаптировать свой стиль коучинга или лидерства так, чтобы поддержать сотрудников, у которых есть план действий по персональному развитию. Модель имеет 5 составляющих факторов:
▶ Конечный результат («O»). Конечный результат определяет долгосрочные цели сотрудника и желаемый результат от каждой беседы.
▶ Ситуация («S»). Ситуация позволяет обсудить текущий уровень навыков, способностей и знаний члена команды проекта; причину его нахождения на таком уровне; каким образом этот уровень воздействует на результативности и эффективность сотрудника и его отношения с коллегами.
▶ Выбор / последствия («C»). Выбор и (или) последствия определяют все возможные пути достижения желаемого конечного результата и последствия каждого выбора, что позволяет сотруднику выбрать подходящий путь для достижения своих долгосрочных целей.
▶ Действия («A»). Действие — это достижение конкретных улучшений путем концентрации на краткосрочных и достижимых целях с определенным сроком выполнения.
▶ Обзор («R»). Проведение регулярных собраний обеспечивает сотрудникам необходимую поддержку и позволяет оставаться мотивированными и целеустремленными

  • Коммуникационные модели

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

Кросскультурная коммуникация

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

Результативность коммуникационных каналов

Алистер Кокберн (Alistair Cockburn) разработал модель, описывающую коммуникационные каналы в системе координат результативности и богатства. Согласно определению Ричарда Дафта (Richard Daft) и Роберта Ленгеля (Robert Lengel) богатство 
связано с количеством знаний, которые могут быть переданы через носитель информации. 
Богатство медиавозможностей — это функция характеристик, включая возможность:
▶ одновременной передачи нескольких информационных сигналов;
▶ быстрого получения обратной связи;
▶ ориентации на личность;
▶ использования естественного языка.
Богатство коммуникации позволяет быстро передать широкий спектр информации. В ситуациях, которые требуют передачи сложной, запутанной и личной информации, желательно использовать более богатых коммуникационные каналы, такие как очная коммуникация. Для передачи простой фактической информации можно использовать менее богатые коммуникационные каналы, например записки или текстовые сообщения.

Пропасти исполнения и оценки

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

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

  • Мотивационные модели

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

Гигиенические и мотивационные факторы

Фредерик Герцберг (Frederick Herzberg) провел исследование мотивационных факторов, влияющих на работу. Он считал, что удовлетворенность и неудовлетворенность от работы зависят от условий, называемых мотивационными факторами. К ним относятся вопросы, касающиеся содержания работы, такие как достижения, рост и продвижение. Недостаток  мотивационных факторов ведет к неудовлетворенности. Достаточный объем мотивационных факторов ведет к удовлетворенности.

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

Внутренняя и внешняя мотивация

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

Теория X. Y. Z

Дуглас Макгрегор (Douglas McGregor) разработал модели «Теория Х» и «Теория Y», которые представляют собой спектр мотивации сотрудников и соответствующих стилей управления. Позже была предложена «Теория Z».
▶ Теория X. На стороне спектра Х находятся сотрудники, которые работают исключительно ради дохода. Они не амбициозные и не целеустремленные. Соответствующий управленческий стиль, чтобы мотивировать данных сотрудников — это директивное управление сверху вниз. Такой стиль управления часто встречаются на производстве и на трудоемких предприятиях или при многоуровневой системе управления.
▶ Теория Y. На стороне спектра Y находятся сотрудники, которых мотивирует желание хорошо выполнять свою работу. Соответствующий управленческий стиль, близкий к личному коучингу. Руководство поощряет креативность и дискуссии. Этот стиль управления часто встречается в среде творческого и умственного труда.
▶ Теория Z. Абрахам Маслоу (Abraham Maslow) видел в «Теории Z» идеальную рабочую среду, в которой сотрудников мотивируют самореализация, ценности и призвание. В такой ситуации оптимален стиль управления, культивирующий инсайт и осмысление.

Теория потребностей

Согласно модели Дэвида Макклелланда (David McClelland), всеми людьми движут потребности достижения, власти и причастности. Относительная сила каждой потребности зависит от опыта человека и его культуры.
▶ Достижение. Люди, которыми движет потребность достижения, например достижения целей, мотивируются нестандартными, но обоснованными задачами и работой.
▶ Власть. Люди, которыми движет потребность власти, любят организовывать, мотивировать и возглавлять других. Их мотивирует повышенная ответственность.
▶ Причастность. Люди, которыми движет потребность в причастности, стремятся к
признанию и востребованности. Их мотивирует чувство принадлежности к команде

  • Модели изменений

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

Управление изменениями в организациях

Управление изменениями в организациях — это итеративная модель, основанная на общих элементах различных моделей управления изменениями. Она состоит из пяти элементов, соединенных между собой серией витков обратной связи:
▶ Формулирование изменений. Цель этого элемента — сформировать обоснование, помогающее людям понять, почему изменения необходимы и чем будущее состояние будет лучше.
▶ Планирование изменений. Идентификация операций помогает людям подготовиться к переходу из текущего состояния в будущее.
▶ Реализация изменений. Цель этого итеративного элемента — продемонстрировать возможности будущего состояния, убедиться в том, что эффект от изменений соответствует запланированному и внести необходимые улучшения или исправления.
▶ Управление переходом. Этот элемент нужен для того, чтобы удовлетворить потребности, связанные с изменениями, которые могут возникнуть после достижения будущего состояния..
▶ Поддержание изменений. Цель этого элемента — убедиться в том, что новые возможности будут существовать и дальше, а устаревшие процессы или модели поведения больше применяться не будут.

Модель ADKAR

Джефф Хайатт (Jeff Hiatt) разработал модель ADKAR®, в основе которой лежат пять последовательных этапов, которые проходят люди во время адаптации к изменениям:
▶ Этап  1: осознание («A»). На этом этапе объясняется, почему изменения необходимы.
▶ Этап  2: желание («D»). Когда люди поймут, почему изменения необходимы, у них должно возникнуть желание принять участие в них и поддержать их.
▶ Этап  3: знание («K»). Людям необходимо понимать, как измениться. Сюда относится понимание новых процессов и систем, а также новых ролей и сфер ответственности. Знания можно передать через тренинг или обучение.
▶ Этап  4: способность («A»). На этом этапе знания подкрепляются непосредственной практикой и обращением за экспертизой и помощью при необходимости.
▶ Этап  5: подкрепление («R»). Подкрепление обеспечивает долгосрочность изменения. Этот этап может включать вознаграждение, признание, обратную связь и измерение.

8-этапный процесс руководства изменениями

Джон Коттер (John Kotter) разработал 8-этапный процесс руководства изменениями в организациях. Это подход сверху вниз, при котором потребность в изменениях и подход к их реализации появляется на верхнем уровне организации, а затем спускается по уровням управления до получателей изменений. Вот эти этапы:
▶ Этап 1: создать безотлагательность. Идентифицировать потенциальные угрозы и возможности, которые обуславливают необходимость изменений.
▶ Этап 2: сформировать мощную коалицию. Определить лидеров изменений. Лидеры изменений не обязательно зависят от иерархии. Лидеры изменений должны быть влиятельными людьми с разными ролями, экспертизой, общественной и политической значимостью.
▶ Этап 3: сформулировать видение для изменений. Определить ценности, лежащие в основе изменений. Затем создать краткое описание видения, которое дает суть изменения. Наконец, определить стратегию реализации этого видения.
▶ Этап 4: транслировать видение. Транслировать видение на протяжении всего процесса изменений. Применять видение ко всем аспектам организации. Высшее руководство и коалиция по изменениям должны единообразно транслировать
видение и демонстрировать безотлагательность изменений и выгоду от них.
▶ Этап 5: Устранить препятствия. Любые изменения сопряжены с препятствиями. Иногда изменениям мешают устаревшие процессы, иногда  организационная структура, а иногда люди сопротивляются им. Как бы то ни было, все препятствия должны быть рассмотрены.
▶ Этап 6: Осуществлять краткосрочные победы. Определить быстрые и легкие победы, чтобы создать движущую силу и поддержку для изменений.
▶ Этап 7: использовать изменения как основу для дальнейших целей. После достижения краткосрочных побед организации необходимо поставить цели по дальнейшему совершенствованию.
▶ Этап 8: укоренить изменения в корпоративной культуре. Убедиться, что изменения укоренились в культуре: продолжать транслировать видение, рассказывать истории успеха, поощрять сотрудников организации, которые воплощают эти изменения и делают их возможными, и продолжать поддерживать коалицию по изменениям.

Модель изменений Вирджинии Сатир

Вирджиния Сатир (Virginia Satir) разработала модель того, как люди переживают изменения и справляются с ними. Цель этой модели — помочь членам команды проекта понять, что они чувствуют, и более эффективно проходить сквозь изменения.
▶ Затянувшийся статус-кво. На начальном этапе все кажется знакомым. Его можно охарактеризовать как «обычное положение дел». Для некоторых людей обычное положение дел — это хорошо, поскольку они знают, чего ожидать. Другим такое
положение дел может казаться скучным застоем.
▶ Чуждый элемент. На этом этапе происходит что-то, что меняет статус-кво. Это может быть запуск проекта, вносящего изменения в повседневную работу. Зачастую за знакомством с изменением следует период сопротивления и снижения производительности. Люди могут игнорировать изменения или отрицать их важность.
▶ Хаос. Люди находятся на незнакомой территории. Они больше не чувствуют себя комфортно и производительность падает до минимума. Чувства, действия и поведение становятся непредсказуемыми. Некоторые люди чувствуют беспокойство,
некоторые совершенно теряются, а некоторые, напротив, чувствуют прилив сил. Хаос может сделать людей очень креативными, пока они пытаются осмыслить ситуацию. Они будут пробовать разные идеи и модели поведения, чтобы узнать, какие из них
приведут к положительному конечному результату.
▶ Трансформирующая идея. У людей возникает идея, помогающая им осмыслить ситуацию. Они начинают понимать, как найти выход из хаоса и совладать с новой реальностью. Производительность труда начинает расти.
▶ Практика и интеграция. Люди пытаются внедрить собственные новые идеи или модели поведения. В этот период может происходить немало проб и ошибок, различных заминок, но со временем люди понимают, что работает, а что — нет. Это приводит к улучшению производительности. Зачастую на этом этапе производительность находится на более высоком уровне, чем до появления чуждого элемента.
▶ Новый статус-кво. Люди привыкают к новой среде, и их производительность стабилизируется. Со временем новый статус-кво становится привычным образом работы.

Модель управление переходом

Модель управления переходом Уильяма Бриджеса (William Bridges) позволяет понять психологические переживания сотрудников во время организационных изменений.  В этой модели изменения и переход разделяются. Изменения являются ситуационными и происходят независимо от факта перехода через них людей. Переход — это психологический процесс, во время которого люди постепенно принимают детали новой ситуации и связанные с этим изменения.
В этой модели выделяются три этапа перехода, связанные с изменением:
▶ Конец, потеря и смирение. На данном этапе происходит знакомство с изменением. Он часто ассоциируется со страхом, гневом, грустью, неуверенностью, отрицанием и сопротивлением изменению.
▶ Нейтральная зона. На данном этапе происходит изменение. В некоторых случаях люди могут чувствовать фрустрацию, возмущение, растерянность и тревогу по поводу изменения. Производительность может падать, пока люди учатся работать
по-новому. В других случаях люди могут демонстрировать высокую креативность, изобретательность и энтузиазм в поиске новых способов работы.
▶ Новое начало. На этом этапе люди принимают изменения и даже приветствуют их. Они лучше обучаются новым навыкам и методам работы. Зачастую люди открыты для новых знаний и чувствуют прилив сил в связи с изменениями.

  • Модели сложности

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

Фреймворк Кеневин

Созданный Дэйвом Сноуденом (Dave Snowden) фрэймворк Кеневин — это концептуальный фреймворк, используемый для диагностики причинно-следственных связей с целью облегчить принятие решений. Он включает 5 контекстов принятия решений в пяти проблемных ситуациях.
▶ При наличии явных причинно-следственных связей для принятия решений следует полагаться на лучшие практики.
▶ Сложные связи существуют, когда есть набор «известных неизвестных» или ряд правильных ответов. В таких ситуациях лучше оценить факты, проанализировать ситуацию и применить хорошие практики.
▶ Комплексные связи содержат «неизвестные неизвестные». В такой ситуации нет явных причин и следствий и явных правильных ответов. В комплексных средах следует исследовать обстановку, осознать ситуацию и ответить действием. При
таком подходе применяются неожиданные практики, позволяющие создавать повторяющиеся циклы «исследование-осознание-реагирование», поскольку комплексные среды меняются от воздействия различных стимулов, и то что работало раньше, в следующий раз может не сработать.
▶ В хаотичных средах причинно-следственные связи неясны. Замешательство слишком большое, и нет времени, чтобы понять ситуацию. Первым делом следует попытаться стабилизировать такую ситуацию, затем осознать, где есть определенная стабильность, и принять меры для перевода ситуации из хаотичной в комплексную.
▶ В неупорядоченных взаимоотношениях нет ясности. Их, возможно, потребуется разбить на несколько меньших частей, чей контекст совпадает с одним из четырех вышеописанных.

Матрица Стейси

Ральф Стэйси (Ralph Stacey) создал матрицу Стэйси, которая сходна с моделью Кеневин, но в ней относительная сложность проекта определяется на основе двух факторов: относительная неопределенность требований к поставляемому результату и относительная неопределенность технологий, которые будут использоваться для создания поставляемого результата. В зависимости от значений этих факторов проект считается простым, сложным, комплексным или хаотичным. Степень сложности — это 
один из факторов, влияющих на процесс адаптации методов и практик к проекту.

12---.png

  • Модели развития команды проекта

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

Модель Такмана

Брюс Такмен (Bruce Tuckman) сформулировал следующие стадии развития команды: 
▶ Формирование. Команда проекта впервые собирается вместе. Члены команды узнают имена, должности, наборы навыков и другую значимую информацию друг о друге. Это может произойти на стартовом совещании.
▶ Шторм. Члены команды проекта соревнуются за должность в команде. На этой стадии начинают проявляться личные качества, сильные и слабые стороны людей. Прежде чем люди поймут, как работать друг с другом, могут возникать конфликты или
борьба. Стадия шторма может быть длительной или относительно краткосрочной.
▶ Нормализация. Команда проекта начинает функционировать как единый коллектив. На этой стадии члены команды проекта знают свое место в команде и то, как они относятся ко всем остальным членам и взаимодействуют с ними. Они начинают работать вместе. В ходе работы могут возникать некоторые проблемы, но они быстро решаются и команда проекта переходит к действию.
▶ Результативность. Работа команды проекта становится эффективной. Это стадия зрелости команды. Команды, работающие друг с другом долгое время, приобретают синергию. Работая вместе, члены команды проекта достигают большего и производят высококачественный продукт.
▶ Завершение. Команда проекта завершает работу и распадается, чтобы перейти к другим проектам. Если в команде сложились хорошие отношения, некоторые члены команды могут испытывать грусть от расставания с командой.

Модель командной продуктивности Дрекслера — Сиббета

Аллан Дрекслер (Allan Drexler) и Дэвид Сиббет (David Sibbet) разработали модель командной продуктивности, имеющую семь шагов. Шаги 1-4 описывают стадии создания команды проекта, а шаги 5-7 касаются поддержания команды в стабильной форме и обеспечения ее производительности.
▶ Шаг 1: ориентация. Ориентация отвечает на вопрос зачем. На этой стадии команда узнает цель и миссию проекта. Это обычно происходит на стартовом совещании или документально оформляется в виде бизнес-кейса, устава проекта или канвы бережливого стартапа.
▶ Шаг 2: обретение доверия. Обретение доверия отвечает на вопрос кто. Эта стадия проливает свет на то, кто входит в команду проекта и какими навыками и умениями обладает каждый ее участник. Она также может включать получение информации о ключевых заинтересованных сторонах, которые могут не входить в состав команды проекта, но влиять на ее работу.
▶ Шаг 3: уточнение цели. Уточнение цели отвечает на вопрос что. На этой стадии команда формирует высокоуровневую информацию о проекте. Сюда может относиться получение подробной информации об ожиданиях заинтересованных сторон, их требованиях, допущениях и критериях приемки поставляемых результатов.
▶ Шаг 4: обязательность. Обязательность отвечает на вопрос как. На этой стадии команда проекта начинает составлять планы достижения целей: расписания контрольных событий, планы релизов, высокоуровневые бюджеты, потребности в ресурсах и т. д.
▶ Шаг 5: внедрение. Высокоуровневые планы декомпозируются в уровни с большей детализацией, такие как подробное расписание или бэклог. Команда проекта начинает работать слаженно с целью производства поставляемых результатов.
▶ Шаг 6: высокая производительность. Команда проекта, работающая вместе уже долгое время, достигает высокого уровня производительности. Ее члены хорошо работают друг с другом, не требуют значительного надзора и образуют синергию в рамках команды проекта.
▶ Шаг 7: обновление. На стадии обновления происходят изменения в команде проекта или в самом проекте. Поставляемые результаты, заинтересованные стороны, среда, руководители или члены команды проекта могут меняться. В связи с этим  команда проекта начинает размышлять, достаточно ли используемых моделей поведения и действий или команде нужно вернуться на некоторую предыдущую стадию, чтобы пересмотреть ожидания и способы совместной работы.

  • Прочие модели

Модели конфиктов

При работе над проектами часто возникают конфликты. Конфликты могут быть здоровыми и продуктивными при правильном управлении ими. Разрешение конфликта может привести к укреплению доверия между членами команды проекта и усилению стремления достичь конечных результатов. Страх перед конфликтом может ограничивать коммуникацию и креативность. Однако конфликты могут быть и нездоровыми. Неправильное течение конфликта может привести к  неудовлетворенности, потере доверия, снижению морального климата и мотивации. Модель, основанная на работах Кена Томаса (Ken Thomas) и Ральфа Килманна (Ralph Kilmann), описывает 6 способов реагирования на конфликты на основе  соотношения сил между сотрудниками и желания сохранить хорошие отношения.
▶ Конфронтация/разрешение проблем. Конфронтация — это подход, при котором конфликт рассматривается как проблема, которую нужно решить. Этот подход к разрешению конфликтов применяется, когда отношения между сторонами важны и каждый человек уверен в способности другой стороны решить проблему.
▶ Сотрудничество. Сотрудничество подразумевает объединение разных взглядов на конфликт. Цель — узнать разные взгляды и посмотреть на ситуацию с разных сторон. Этот метод результативен при наличии доверия между участниками и
времени для достижения консенсуса. Руководитель проекта может способствовать разрешению конфликта между членами команды в таком ключе.
▶ Компромисс. Есть конфликты, в которых невозможно полностью удовлетворить все стороны. В таких случаях лучше всего найти путь к компромиссу. Для компромисса нужна готовность не только приобретать, но и чем-либо жертвовать. Это позволяет всем сторонам получить нечто желаемое и избежать эскалации конфликта. Такой подход часто применяется, когда у сторон конфликта равные «силы». Например, руководитель проекта может прийти к компромиссу с техническим руководителем относительно выделения времени члена команды проекта для работы над проектом.
▶ Сглаживание/ приспосабливание. Сглаживание и приспосабливание полезны, когда достижение главной цели важнее разногласий. Этот подход позволяет сохранить гармонию в отношениях и может сформировать доброжелательность 
между сторонами. Он также применяется, когда относительный авторитет или силы сторон различаются. Например, он может быть уместен при разногласиях со спонсором. Поскольку статус спонсора выше, чем у руководителя или члена команды проекта, и есть желание остаться с ним в хороших отношениях, то приспособление может быть уместным.
▶ Принуждение. Принуждение применяется, когда нет времени сотрудничать или решать проблему. В данном сценарии одна сторона навязывает свою волю другой стороне. Принуждающая сторона обладает большей силой, чем другая сторона. Принудительный подход может применяться, если конфликт касается охраны здоровья и безопасности труда и требует немедленного разрешения.
▶ Уклонение/избегание. Иногда проблема решается сама собой или обсуждение становится слишком бурным, и людям требуется время, чтобы остыть. В обоих случаях уместно «отойти» от ситуации. Уклонение также применяется в безвыигрышных сценариях (например, выполнение требования контролирующих органов вместо его оспаривания).

Переговоры

Существует много моделей переговоров. Одна из них — это принцип Стивена Кови  (Steven Covey) «Думайте в духе выиграл-выиграл». Этот принцип применим не только к  переговорам, но и к любым взаимодействиям вообще, однако здесь он приводится именно в контексте переговоров. По итогам переговоров возможны различные исходы:
▶ Выиграл-выиграл. Это оптимальный исход, удовлетворяющий каждую из сторон.
▶ Выиграл-проиграл/проиграл-выиграл. Это подход к переговорам как к соревнованию: чтобы кто-то выиграл, кто-то должен проиграть. Такой исход также возможен при жертвенном подходе: кто-то добровольно проигрывает, чтобы другие выиграли.
▶ Проиграл-проиграл. Такой исход возможен, когда стороны могли достигнуть результата «выиграл-выиграл», но поставили соревновательность выше сотрудничества. В данном сценарии проигрывают все. 

Для достижения результата «выиграл-выиграл», как правило, необходимо соблюдение следующих условий:
▶ Характер. Стороны переговоров действуют взвешенно, демонстрируют добросовестность и сходятся во мнении, что сделка может быть выгодна для всех.
▶ Доверие. Стороны доверяют друг другу, заключают соглашение о принципах работы и ответственно подходят к его соблюдению.
▶ Подход. Каждая из сторон готова увидеть ситуацию глазами другой стороны. Стороны вместе работают над выявлением ключевых проблем и опасений. Они определяют, как будет выглядеть приемлемое решение, и находят возможные пути достижения такого решения.

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

Барри Боэм (Barry Boehm) разработал модель (СОСОМО), в которой сравниваются время и трудозатраты, вложенные в разработку планов по сокращению рисков, с учетом задержек и других затрат, связанных с чрезмерным планированием. Во многих проектах, потратив больше времени на предварительное планирование, можно снизить степень неопределенности и сократить число оплошностей и необходимость в доработке. Однако, чем больше времени вы тратите на планирование, тем больше срок окупаемости инвестиций и возможные потери в доле рынка и тем больше обстоятельства могут измениться к моменту поставки выхода.
Назначение этой модели — определить оптимальный объем планирования, так называемую «золотую середину». «Золотая середина» разная для каждого проекта; следовательно, нет универсального ответа на вопрос, какой объем планирования  достаточен. Эта модель демонстрирует, что есть точка, по достижении которой дальнейшее планирование становится контрпродуктивным.

Группы процессов

Процессы управления проектом можно объединить в логические группы по входам, инструментам, методам и выходам, адаптируемым к потребностям организации, заинтересованных сторон и проекта.
Группы процессов не являются фазами проекта. Группы процессов взаимодействуют внутри каждой фазы жизненного цикла проекта. Все эти процессы могут происходить в течение одной фазы. Процессы могут повторяться в течение фазы или  жизненного цикла. Повторение процессов и их взаимодействие варьируется в зависимости от потребностей проекта.
В качестве организационной структуры для проектов, к которым применяется основанный на процессах подход, можно использовать следующие пять групп процессов:
▶ Инициация. Процессы, выполняемые для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы.
▶ Планирование. Процессы, требуемые для установления содержания работ, уточнения целей и определения направления действий, требуемых для достижения целей проекта.
▶ Исполнение. Процессы, выполняемые для исполнения работ, указанных в плане управления проектом, с целью соответствия требованиям проекта.
▶ Мониторинг и контроль. Процессы, требуемые для отслеживания, анализа, а также регулирования исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений.
▶ Закрытие. Это процессы, выполняемые для формального завершения или закрытия проекта, фазы или договора.

Модель особенностей

Модель особенностей ориентирована на заинтересованные стороны. Особенность — это то, что выделяется, является заметным или представляется важным. Эта модель была предложена Рональдом Митчеллом (Ronald K. Mitchell), Брэдли Эглом (Bradley R. Agle) и Донной Вуд (Donna J. Wood). Авторы классифицировали заинтересованные стороны на  основе трех переменных: власть влияния, легитимность связей заинтересованных сторон с проектом и срочность требования заинтересованных сторон к проекту для их вовлечения.

Оптимальные сочетания доменов исполнения и моделей:
13---.png

Автор: Андрей Береговенко

Время на прочтение
4 мин

Количество просмотров 51K

Рассмотрим ситуацию с одним из самых популярных проджект-менеджмент «талмудов» — Сводом знаний по управлению проектами (PMBoK — Project management body of knowlege) от американского института PMI (Project management institute). Вряд ли вам встретится нелегальная бумажная книга, поэтому далее речь пойдет об электронном варианте.

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

Простых способов для этого нет — электронную книгу невозможно купить, надо стать участником проектного сообщества PMI. C первого раза для доступа к электронному варианту PMBoK и куче остальных интересных книг надо заплатить $ 139 за членство в PMI. Не буду останавливаться на подробностях о преимуществах участника PMI, но помимо доступа к электронной библиотеке без дополнительной платы за каждую книгу (а это действительно ценный ресурс), можно купить бумажный вариант со скидкой 50 %. Это приятный бонус, потому что доставка стоит не дешево, а бумажный артефакт будет во многом приятнее электронного варианта. Но об этом далее.

Страх и ненависть PDF DRM

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


Открываем PMBoK на iPad и на iMac

Все книги защищены твоим паролем от профиля на сайте PMI. Поэтому важно придумать надежный, но относительно легко вводимый пароль. Иначе придется всё время копировать свой пароль из менеджера паролей или заметок.


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

Запрещено всё, кроме листания книги и использования поиска: нельзя делать пометки, выделять и копировать текст, делать закладки, нельзя распечатать нужную страницу. То есть отсутствует функционал любой нормальной современной электронной книги, позволяющий работать с текстом быстрее и эффективнее, чем в случае обычной книги. Для проработки текста придется взять классический бумажный блокнот или параллельно книге открыть приложение для электронных заметок (Apple notes, Microsoft OneNote, Evernote, Google Keep или кто чем ещё привык пользоваться) и вручную туда конспектировать и делать скриншоты текста.

К вопросу о том какой именно вариант PMBoK стоит читать — на английском или на русском. Если готовиться к сертификации PMP и для развития языкового навыка конечно лучше читать английский вариант. К тому же английский вариант книги удобнее из-за интерактивного оглавления, которое в русском издании то ли забыли, то ли не успели сделать.


Английское издание с оглавлением

Русское издание — оглавление не доступно, только общий обзор страниц.

Тут я делаю не очень утешительный вывод, что с бумажным вариантом PMBoK (особенно на русском языке) работать удобнее — там доступны закладки, стикеры, пометки на полях и в тексте.

iPad

Оказывается, далеко не все программы и сервисы умеют работать с запаролеными PDF. Например, PMBoK не получится читать с помощью Google Play Books. Стандартные планшетные программы-читалки (iBooks, Adobe Acrobat Reader) ведут себя так же, как на компьютере — книгу можно листать. Но на iPad есть миллион других программ для работы с PDF и заметками. Как оказалось, очень популярное приложение Notability не умеет открывать запароленные PDF. А Microsoft OneNote открывает такой PDF только в режиме Preview, что не предполагает удобного чтения.


iBooks для iOS

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


Выделение текста, пометки, удобные заметки на полях в GoodNotes 4


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

За GoodNotes 4 просят 600 рублей. Не так уж и много за волшебство, которое позволяет работать с книгой удобнее, чем задумали её авторы.

Android

В порядке эксперимента попробовал полистать PMBoK на планшете Samsung Galaxy Tab S3. Без установки дополнительных программ у Samsung немного больше возможностей, чем у iPad.
С помощью комплектного пера делаем скриншот части экрана. При желании [коряво] распознаем текст со скриншота.

Но принципиальных отличий от iPad нет — штатная PDF читалка так же обеспечивает листание книги и ничего больше. А есть ли под Android аналог GoodNotes 4 для запароленных PDF я не узнавал и не искал.

E-reader

Настоящая боль ждёт обладателей электронных читалок. Для эксперимента я воспользовался PocketBook 740 с большим экраном. Это работает медленно, неспешно, но читать вполне можно, как и на экране iPad mini 7,9″. На 6″ читалке думаю будет совсем уж некомфортно.



По сравнению с прекрасным iBooks, штатная читалка PocketBook всё же умеет делать заметки в запароленном PDF. Но в момент появления клавиатуры не видно какой именно участок текста ранее был выделен для комментирования

Итоги

Для меня лучшей читалкой электронных изданий PMI является iPad с GoodNotes 4. Желательно с каноническим, теперь уже средним по размеру, экраном.

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

Что делать с DRM-защитой вашего персонального экземпляра книги решайте сами — на Хабре множество публикаций о том, что нельзя делать с такими файлами.

Руководство к Своду знаний по управлению проектами

Свод знаний по управлению проектам PMBOK представляет собой сумму профессиональных знаний по управлению проектами. Институт управления проектами использует этот документ в качестве основного…

Подробнее

Руководство к своду знаний по управлению проектами . Шестое издание. Agile: практическое руководство

«Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу…

Подробнее

Отзывы читателей

  • В

    Шестое издание у меня есть на русском. Кто может помочь с электронной версией 7 издания на русском?

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство. Шестое издание

  • Скачали: 2 943
  • Автор:
  • Объем страниц: 1170 стр. 326 иллюстраций
  • Жанр: Бизнес-стратегии / Зарубежная деловая литература / Руководства / Новинки книг
  • Возрастное : 12+
  • Год: 24 сентября 2019
  • isbn: 978-5-9693-0402-4
  • Дата: 08 январь 2022

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство. Шестое издание скачать fb2, epub, pdf, txt бесплатно

Новинки в

Телеграм

«Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах…»

Читать книгу Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство. Шестое издание онлайн, совершенно бесплатно и без регистрации. Автор книги . Жанр книги: Бизнес-стратегии / Зарубежная деловая литература / Руководства / Новинки книг, является одним из самых популярных жанров современности.

  • Книги
  • Руководства

  • 📚 Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

Коллектив авторов

Ключевые идеи книги: Руководство к своду знаний по управлению проектами. Руководство PMBOK. Институт управления проектами. Коллектив авторов

Электронная книга

279 

Подробнее

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

Электронная книга

Подробнее

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

Коллектив авторов

Ключевые идеи книги: Руководство к своду знаний по управлению проектами. Руководство PMBOK. Институт управления проектами. Коллектив авторов

Аудиокнига

Читает Ольга Ганкова

279 

Подробнее

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

Коллектив авторов

PR для малого бизнеса. Кратко, ясно, просто

Электронная книга

430 

Подробнее

Эта и ещё 2 книги за 399 

По абонементу вы каждый месяц можете взять из каталога одну книгу до 700 ₽ и две книги из специальной подборки. Узнать больше

Оплачивая абонемент, я принимаю условия оплаты и её автоматического продления, указанные в оферте

Описание книги

«Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах…»

Подробная информация

Возрастное ограничение:
12+
Дата выхода на ЛитРес:
24 сентября 2019
Дата перевода:
2018
Дата написания:
2017
Объем:
1170 стр. 326 иллюстраций
ISBN:
978-5-9693-0402-4
Переводчик:
Коллектив переводчиков
Правообладатель:
Олимп-Бизнес
Оглавление

Книга «Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство» — скачать в fb2, txt, epub, pdf или читать онлайн. Оставляйте комментарии и отзывы, голосуйте за понравившиеся.

Другие версии

Ключевые идеи книги: Руководство к своду знаний по управлению проектами. Руководство PMBOK. Институт управления проектами. Коллектив авторов

Аудиокнига

Читает Ольга Ганкова

279 

Цитаты 4

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

+2232549079

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

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

+1antokhov

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

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

0antokhov

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

«Управление изменениями в организациях: практическое руководство»

0sy.naumenko

«Управление изменениями в организациях: практическое руководство»

Оставьте отзыв

Удобные форматы для скачивания

Файл(ы) отправлены на почту

Читайте эту книгу бесплатно

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

После регистрации ссылка на книгу будет отправлена на указанный Вами e-mail

Введите вашу электронную почту

Поделиться отзывом на книгу

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководство

Руководство к своду знаний по управлению проектами (Руководство PMBOK®) + Agile: практическое руководствоТекст

Понравилась статья? Поделить с друзьями:
  • Как создать свой бренд на вайлдберриз бесплатно пошаговая инструкция
  • Наставнический стиль руководства это
  • Бадяга масло арники гель бальзам для тела инструкция по применению
  • Обогреватель электрический timberk инструкция по эксплуатации
  • Азелик цена в аптеке инструкция по применению цена отзывы