Принятые результаты

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

Дополнительно по теме:

 

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

Завершение проекта или фазы

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

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

Дополнительно по теме:

Диаграмма процесса "Завершение проекта или фазы"

Диаграмма группы процессов завершения проекта

Диаграмма группы процессов интеграции проекта

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

Дополнительно по теме:

 

Диаграмма процесса "Осуществление общего управления изменениями"

   

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

   

Диаграмма группы процессов интеграции проекта

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

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

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

Запрос на изменение может подать любая заинтересованная сторона, вовлеченная в проект. Хотя изменения могут быть инициированы устно, они обязательно должны быть зарегистрированы в письменной форме и переданы в систему управления изменениями и/или управления конфигурацией. Запросы на изменения подвержены процессам, указанным в системах управления изменениями и управления конфигурацией. Эти процессы, связанные с запросами на изменение, могут требовать информацию об ожидаемом воздействии на сроки и на стоимость. Каждый задокументированный запрос на изменение либо одобряется, либо отклоняется каким-либо уполномоченным лицом из команды управления проектом или сторонней организации. Во многих проектах менеджер проекта наделен полномочиями одобрять определенные виды запросов на изменение, что указано в документах о ролях и обязанностях в рамках проекта. При необходимости процесс осуществления общего управления изменениями включает в себя совет по управлению изменениями (change control board, CCB), отвечающий за одобрение или отклонение запросов на изменение. Роли и обязанности таких советов четко определяются в рамках процедур управления конфигурацией и управления изменениями и согласуются с соответствующими заинтересованными сторонами проекта. Многие крупные организации разрабатывают многоуровневые структуры, разделяющие обязанности между советами. Если проект реализуется по контракту, то некоторые предложенные изменения могут требовать одобрения заказчиком, что указывается в контракте. Одобренные запросы на изменение могут потребовать создания новых или пересмотра старых оценок стоимости, последовательностей операций, дат расписания, потребностей в ресурсах и анализа альтернатив реагирования на риски. Эти изменения могут потребовать внесения поправок в план управления проектом или в другие планы/документы проекта. Применяемый уровень управления изменениями зависит от прикладной области, сложности конкретного проекта, требований контракта, а также контекста и среды, в которых осуществляется проект. Система управления конфигурацией с общим управлением изменениями предоставляет стандартизированный, эффективный и действенный способ централизованного управления одобренными изменениями и базовыми планами в рамках проекта. Управление конфигурацией сконцентрировано на детализации результатов и процессов, тогда как управление изменениями сосредоточено на выявлении, документировании и контролировании изменений проекта и базовых планов продукта. Применение системы управления конфигурацией, включающей процессы управления изменениями, в рамках всего проекта решает три основные задачи:

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

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

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

Дополнительно по теме:

Диаграмма процесса "Осуществление общего управления изменениями"

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

Диаграмма группы процессов интеграции проекта

Глава 1. Управление программными проектами

Конспект Pankaj Jalote "Управление программным продуктом на практике"

Каждый год выполняется примерно 1 000 000 проектов, на общую сумму $600 000 000 000. Приблизительно 33% превышают стоимость и отстают по срокам более, чем на 125%. Наиболее важными причинами провала является неправильное управление проектом.

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

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

1. Оценивание трудоемкости
2. Управление рисками
3. Мониторинг проекта
4. Управление конфигурацией и т.д.

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

• Установить контрольные точки
• Организовать персонал
• Управлять рисками
• Отслеживать продвижение вперед и т.д.

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

1. Процессы представляют коллективное знание. Их использование повышает шансы на успех
2. Процесс может включать несколько дополнительных шагов, но никогда нельзя знать заранее, каким путем будет развиваться ситуация, поэтому использование коротких путей повышает риски выполнения проекта.
3. Не пользуясь процессами, нельзя предсказать результаты проекта.
4. Вы и ваша организация не сможете обучаться, если не будете пользоваться предопределенными процессами.
5. Процессы снижают уровень опасений. Контрольные перечни неизбежно охватывают 80% того, что необходимо сделать. Вам остается проработать только 20%.

1.2. Управление проектами и CMM 
CMM - the Capability Maturity Model. CMM для ПО является системой понятий, которые пытаются ответить на вопрос, какие должны быть характеристики эффективных процессов, не предписывая никаких конкретных процессов. CMM может использоваться для оценки процесса разработки ПО в организации и для определения его недостатков. Другой стандарт - ISO 9001.

  1.2.1. Обзор CMM 
Незрелость процессов разработки ПО означает, что проекты выполняются без многих необходимых правил, а результаты проекта зависят в значительной степени от руководителя проектом и команды. При использовании зрелых процессов проект выполняется в соответствии с определенными процессами. В этом случае результат меньше зависит от людей и больше от процесса. Чем более зрелые процессы используются, тем более предсказуемы результаты, тем лучше контролируется проект. Устойчивость процесса проекта (process capability) - диапазон результатов проекта, которые получаются как следствие исполнения проекта согласно этого процесса. Производительность процесса (process performance) - фактический результат процесса, полученный в результате использования этого процесса. Таким образом производительность (эффективность) процесса зависит от его устойчивости. Уровень зрелости процессов - определенная стадия, на которой находятся процессы организации, которой соответствуют определенные характеристики. Ключевая область процесса (key process area, KPA) - характеристика каждого уровня зрелости, это те области, на которые организация должна обращать внимание, чтобы поднять свои процессы до данного уровня зрелости (отображены на диаграмме). Чтобы организация достигла уровня определенного уровня зрелости, она должна соответствовать всем KPA это уровня и всем KPA нижних уровней.

  1.2.2. Ключевые области процесса (KPA) для управления проектами 
Каждая KPA задает цели, которым процессы организации должны соответствовать. Также задается Ключевые практики (key practices) - группа действий, которые вместе соответствуют целям KPA.

  Уровень 2 
В таблице перечислены все цели для KPA уровня 2. Почти все внимание отдается управлению проектом.

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

Исходя из этих целей:

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

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

KPA	Цели
Интегральное управление разработкой ПО	Определенный для проекта процесс разработки ПО является специализированной версией стандартного процесса разработки ПО в организации Проект планируется и исполняется в соответствии с определенным для него процессом разработки ПО
Межгрупповая организация	Требования заказчика согласовывается всеми заинтересованными сторонами Все стороны согласовывают взаимные обязательства Стороны определяют, отслеживают и разрешают межгрупповые вопросы
Экспертизы специалистов	Планируется проведение экспертиз Определяются и устраняются ошибки в программных рабочих продуктах

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

KPA	Цели
Количественное управление процессом	Планируются действия по количественному управлению процессом Производительность процесса, определенного для проекта, контролируется в количественном отношении Устойчивость стандартного процесса в организации известна в количественном измерении
Управление качеством ПО	Планируются действия по управлению качеством ПО в проекте Определяются измеряемые цели качества ПО и из приоритеты Измеряются фактические показатели качества программных продуктов и принимаются действия по их достижению

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

  1.3. Управление проектами в компании InfoSys 
1.3.2. Поддержка проектов со стороны SEPG 
SEPG - software engineering process group. Отвечает за координацию всей деятельности, связанную с процессами, в том числе за определение, совершенствование, размещение процессов. Также управляет всей информацией, связанной с использованием процессов и базовой линией устойчивости процесса. Также формирует независимый канал для мониторинга выполнения проекта и отправки отчетов менеджменту по вопросам процесса и качества. Также занимается внедрением процессов в обычную практику. Выделяется сотрудник, который является членом команды проекта и отвечает за качество продукта. Также предоставляет помощь при планировании, обучении. Также проводит экспертизу плана управления проектом.

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

  1.3.4. Обучение менеджеров проектов 
Все новые сотрудники проходят 3-4 месячную ознакомительную обучающую программу:

1. Курсы по инженерии и технологиям
2. Профессиональная этика бизнеса,
3. Правила ведения переписки
4. Публичные выступления
5. Жестикуляция, мимика, …

  Для кандидатов в лидеры модулей ПО/менеджеров проектов:

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

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

1. Планирование проекта
2. Выполнение проекта
3. Закрытие проекта

  Планирование проекта
Руководитель проекта изучает контрактные обязательства и разрабатывает план по их выполнению. План проекта:

• Определение процесса жизненного цикла
• Оценивание трудоемкости и сроков работ
• Подготовка детального графика задач
• Управление качеством
• Управление конфигурацией
• Управление рисками

Менеджер проекта:

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

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

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

Менеджер проекта:

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

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

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


1.5. Итоги

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

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

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

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

Дополнительно по теме:

Диаграмма процесса "Мониторинг и управление работами проекта"

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

Диаграмма группы процессов интеграции проекта

Отчеты об исполнении

<span style="color: #0c0c0c;">Отчеты, составляемые командой проекта, должны содержать детальное описание работ, достижений, контрольных событий, выявленных вопросов и проблем. Отчеты об исполнении могут использоваться для сообщения ключевой информации, включающей в себя, среди прочего:
</span>
<ul>
<li><span style="color: #0c0c0c;">текущий статус;<span style="font-family: Times New Roman;">
</span></span></li>
<li><span style="color: #0c0c0c;">существенные достижения за указанный период времени;
</span></li>
<li><span style="color: #0c0c0c;">внесенные в расписание операции;
</span></li>
<li><span style="color: #0c0c0c;">прогнозы;
</span></li>
<li><span style="color: #0c0c0c;">проблемы
</span></li>
</ul>