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

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

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

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

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

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

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

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

Жизненный цикл проекта

Важно понимать разницу между жизненным циклом проекта, и процессом управления проектом. И то и другое надо для успешного его завершения; но жизненный цикл это то, что вам надо делать для выполнения работы, а процесс управления проектом - это, то нужно делать чтобы ей управлять.
Жизненный цикл проекта - это цепочка фаз, наложенная на стадии разработки. Он отражает методику компании по управлению проектам. Это - логическая развертка того, что надо сделать для получения продуктов проекта. Построение жизненного цикла конкретного проекта может зависеть от типа выпускаемого продукта, отрасли, и предпочтений компании.
Жизненный цикл может быть plan-driven или change-driven. Внутри жизненного цикла может быть одна или несколько фаз, эти фазы в общем совпадают с процессом разработки продукта. Например, при разработке софта эти фазы могут быть: рисерсч, проектирование, код, тестирование, имплементация.
Plan-driven жизненный цикл подразумевает предопределенные стадии цикла разработки (ватерфалл). Значит, содержание, расписание и бюджет должны быть определены на старте проекта, до начала разработки. Скажем, конструкторские проекты скорее всего будут управляться именно в этом ключе.
Change-driven жизненный цикл использует итеративные, инкрементальные, адаптивные подходы к организации жизненного цикла разработки, и допускают вариации по планированию на ранней стадии.
Инкрементальные и итеративные жизненные циклы предполагают верхнеуровневое планирование содержания, достаточное для того, чтобы дать общие оценки времени и затрат; само содержание прорабатывается шаг за шагом с каждой итерацией. Варианты:

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

Проект может и комбинировать инкрементальный и итеративный подходы.

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

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