Wondershare EdrawMind
Галерея диаграмм связей Учебное пособие для менеджера проектов информационных систем (4-е издание) Глава 9_Управление содержанием проекта
- 3
Учебное пособие для менеджера проектов информационных систем (4-е издание) Глава 9_Управление содержанием проекта
Этот файл представляет собой самодельную интеллектуальную карту «Главы 9_Управление содержанием проекта» учебного пособия по управлению проектами информационных систем (4-е издание). Он включает в себя планирование управления содержанием, сбор требований, определение содержания, создание WBS, подтверждение содержания, контроль содержания и т. д. В соответствии с ключевыми моментами предыдущих экзаменов отмечена важность и все содержание подробно интегрировано, что может сделать итоговый обзор и начало обучения более эффективными, приложив вдвое меньше усилий. Я потратил более десяти часов на составление и обобщение прочитанного всех глав, все из которых являются последней версией.
Отредактировано в 2023-12-13 09:39:36
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Modèle de processus de gestion de projet
La gestion de projet est le processus qui consiste à appliquer des connaissances, des compétences, des outils et des méthodologies spécialisés aux activités du projet afin que celui-ci puisse atteindre ou dépasser les exigences et les attentes fixées dans le cadre de ressources limitées. Ce diagramme fournit une vue d'ensemble des 8 composantes du processus de gestion de projet et peut être utilisé comme modèle générique.
Учебное пособие для менеджера проектов информационных систем (4-е издание) Глава 9_Управление содержанием проекта
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Cent ans de solitude - Tableau des relations entre les personnages
Cent ans de solitude est le chef-d'œuvre de Gabriel Garcia Marquez. La lecture de ce livre commence par l'analyse des relations entre les personnages, qui se concentre sur la famille Buendía et raconte l'histoire de la prospérité et du déclin de la famille, de ses relations internes et de ses luttes politiques, de son métissage et de sa renaissance au cours d'une centaine d'années.
- Modèle de processus de gestion de projet
La gestion de projet est le processus qui consiste à appliquer des connaissances, des compétences, des outils et des méthodologies spécialisés aux activités du projet afin que celui-ci puisse atteindre ou dépasser les exigences et les attentes fixées dans le cadre de ressources limitées. Ce diagramme fournit une vue d'ensemble des 8 composantes du processus de gestion de projet et peut être utilisé comme modèle générique.
- Рекомендовано вам
- Структура
Учебное пособие для менеджера проекта информационной системы (4-е издание) Глава 16_Управление закупками проекта
- 1
Учебное пособие для менеджера проекта информационной системы (4-е издание) Глава 8_Управление интеграцией проекта
- 2
Экзамен по расширенному программному обеспечению. Глава 5. Управление содержанием проекта.
- 2
управление содержанием проекта
основы управления
Управление содержанием проекта предполагает обеспечение того, чтобы проект выполнял и выполнял только всю работу, необходимую для успешного завершения проекта.
Управление содержанием проекта в основном заключается в определении и контроле того, какие работы следует включать в проект, а какие не следует включать в проект.
Значение области действия
Ассортимент продукции
Относится к характеристикам и функциям продукта, услуги или результата.
Завершение измеряется в соответствии с требованиями к продукту.
«Требования» относятся к условиям или возможностям, которыми должен обладать продукт, услуга или результат в соответствии с конкретным соглашением или другой обязательной спецификацией.
Объем проекта
Работа, которую необходимо выполнить для предоставления продукта, услуги или результата с указанными функциями и функциями.
Завершение измеряется по плану управления проектом (базовый план объема в
1. Если содержание продукта изменится, содержание проекта не обязательно изменится. Например: покраска стены, продукт — это стена после покраски, а проект — покраска стены. Изменения цвета краски не повлияют на конкретную работу в проекте. 2. Если объем проекта изменится, содержание продукта не обязательно изменится. Например: разработка программного обеспечения как продукта, проект — это работа, необходимая для поставки программного обеспечения. Если к программному обеспечению добавляется этап тестирования, содержание проекта меняется, а содержание продукта — нет.
новые методы управления
Бизнес-аналитик (бакалавр)
Если в проекте нет бизнес-аналитика, за деятельность, связанную с управлением требованиями, могут отвечать менеджер проекта и основные разработчики.
Отвечает за деятельность, связанную с управлением спросом.
руководитель проекта
Отвечает за обеспечение того, чтобы деятельность, связанная с управлением требованиями, была включена в план управления проектом.
Между бизнес-аналитиками и менеджерами проектов должно быть партнерство.
процесс управления
Рекомендации по пошиву включают в себя
Управление знаниями и требованиями, валидация и контроль, методы разработки, стабильность требований, управление
Гибкие и адаптивные методы
Гибкие или адаптивные проекты
Примите гибкий или адаптивный жизненный цикл, предназначенный для работы с большими объемами изменений и требующий постоянного участия заинтересованных сторон в проекте.
Общий объем адаптивного проекта должен быть разбит на ряд требований, которые необходимо реализовать, и работ, которые необходимо выполнить (журнал продукта), при этом результаты разрабатываются в течение нескольких итераций, а подробные спецификации определяются и утверждаются в начале каждой итерации.
Каждая итерация работает
Команда проекта повторяет три процесса
Соберите требования, определите объем, создайте WBS
Спонсор и представитель клиента повторяют два процесса.
Подтвердить объем, контролировать объем
Прогнозные (водопадные) проекты
Утвержденное описание содержания проекта, иерархическая структура работ (WBS) и соответствующий словарь WBS составляют базовый план содержания проекта.
Базовые изменения могут быть внесены только посредством формального процесса контроля изменений.
управление объемом планирования
Обзор процесса
определение
Это процесс создания плана управления содержанием, в котором записано, как определять, подтверждать и контролировать содержание проекта и содержания продукта.
основной эффект
Предоставлять рекомендации и указания о том, как управлять объемом на протяжении всего проекта.
Этот процесс выполняется только один раз или только в заранее определенных точках проекта.
план управления объемом
определение
Компонент плана управления проектом или программой, который описывает, как будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться содержание проекта.
Требует анализа при формулировании и уточнении
1. Информация в уставе проекта
2. Утвержденные подпланы в плане управления проектом
3. Историческая информация в активах процессов организации
4. Сопутствующие факторы деловой среды
входить
1. Устав проекта
Задокументируйте цель проекта, обзор проекта, предположения, ограничения и требования высокого уровня, которых проект хочет достичь.
2. план управления проектом
1. план управления качеством
То, как политика, методы и стандарты качества организации реализуются в проектах, влияет на способ управления содержанием проекта и продукта.
2. Описание жизненного цикла проекта
3. метод разработки
3. Факторы, влияющие на карьеру
Организационная культура, инфраструктура, система управления персоналом и рыночные условия и т.д.
4. Активы организационного процесса
Политика и процедуры, историческая информация и база знаний, извлеченных из уроков, и т. д.
Инструменты и методы
экспертная оценка
анализ данных
Альтернативные методы анализа
Различные методы оценки, сбора требований, детализации содержания проекта и продукта, создания продуктов, проверки содержания и контроля содержания.
Встреча
выход
1. план управления объемом
определение
Это компонент плана управления проектом, который описывает, как будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться содержание проекта.
В зависимости от потребностей проекта план управления содержанием может быть формальным или неформальным, очень подробным или высокоуровневым.
Руководящая (последующая) работа
1. Разработать описание содержания проекта (определить объем)
2. Создайте WBS на основе подробного описания содержания проекта (Создание WBS).
3. Официальная приемка завершенных результатов проекта (подтвердить объем)
4. Определите, как утвердить и поддерживать базовый план объема (объем контроля)
2. план управления спросом
определение
Является неотъемлемой частью плана управления проектом, который описывает, как требования будут анализироваться, документироваться и управляться.
основное содержание
1. Как планировать, отслеживать и составлять отчеты по различным действиям, связанным с требованиями
2. Действия по управлению конфигурацией, например, как инициируются изменения, как анализируется их влияние, как осуществляется отслеживание, отслеживание и отчетность, а также разрешения на утверждение изменений.
3. Процесс приоритезации требований
4. Метрики для измерения и причины их использования
Требование должно быть количественным (измеримым), например: скорость ответа страницы не превышает 2 секунд.
5. Отражает, какие атрибуты требований будут включены в матрицу отслеживания.
Сбор требований
Обзор процесса
определение
Это процесс выявления, документирования и управления потребностями и желаниями заинтересованных сторон для достижения целей.
основной эффект
Заложите основу для определения содержания продукта и объема проекта.
нуждаться
определение
Условия или возможности, которыми должен обладать продукт, услуга или результат в соответствии с конкретным соглашением или другой обязательной спецификацией.
включать
Количественные и документированные потребности и ожидания спонсоров, клиентов и других заинтересованных сторон.
иметь дело с
Достаточно подробное изучение, анализ и документирование этих требований и включение их в базовый план содержания, который будет измерен после начала реализации проекта.
последующие эффекты
Будет служить основой для иерархической структуры работ (WBS) и основой для планирования затрат, графика, качества и закупок.
входить
1. Документы по управлению проектом
Это документ, созданный на основе экономического обоснования, который влияет на процесс сбора требований. Он описывает необходимые, ожидаемые и дополнительные стандарты, которые следует соблюдать для удовлетворения потребностей бизнеса.
2. Устав проекта
требования высокого уровня
Используется для формулирования детальных требований (пошаговое уточнение)
3. план управления проектом
1. план управления объемом
2. план управления спросом
3. План взаимодействия с заинтересованными сторонами
Понять потребности заинтересованных сторон в коммуникации и уровни их участия из плана, чтобы оценить и адаптировать участие заинтересованных сторон в деятельности по требованиям.
4. файлы проекта (Классифицируется по выходу процесса)
1. Разработать устав проекта
Гипотетический журнал
Выявляются предположения о продукте, проекте, среде, заинтересованных сторонах и других факторах, влияющих на требования.
2. Управление знаниями проекта
Регистрация извлеченных уроков
Предоставляет эффективные методы сбора требований, особенно для проектов, использующих гибкие или адаптивные методы разработки продуктов.
3. Определить заинтересованные стороны
Реестр заинтересованных сторон
Используется, чтобы понять, какие заинтересованные стороны могут предоставить информацию о требованиях и записать потребности и ожидания заинтересованных сторон в отношении проекта.
5. протокол
6. Факторы, влияющие на карьеру
Организационная культура, инфраструктура, система управления персоналом, рыночные условия и т.д.
7. Активы организационного процесса
Политика и процедуры; историческая информация и база знаний об извлеченных уроках, содержащая информацию из прошлых проектов и т. д.
Инструменты и методы
1. экспертная оценка
Технико-экономическое обоснование и оценка требований; анализ требований к проектным документам из аналогичных предыдущих проектов;
2. Сбор данных
Мозговой штурм, интервью, фокус-группы, анкеты, бенчмаркинг
3. анализ данных
Анализ файлов
Получите требования путем анализа существующих документов и определения информации, связанной с требованиями.
4. Производительность данных
Диаграмма сходства (группировка и классификация), интеллект-карта (интеграция)
5. принятие решений
Голосование (для формирования, категоризации и ранжирования требований к продукту), авторитарное принятие решений, многокритериальный анализ решений.
6. Межличностные и командные навыки
1. метод номинальной группы
Сначала проведите мозговой штурм, затем проголосуйте и оцените
2. наблюдать и говорить
Может раскрыть скрытые потребности
3. гид
Используется совместно с тематическими семинарами для объединения ключевых заинтересованных сторон для определения требований.
7. Схема взаимодействия системы
Визуальное изображение объема продукта, которое визуализирует бизнес-системы (процессы, оборудование, компьютерные системы и т. д.) и то, как они взаимодействуют с людьми и другими системами (субъектами).
8. метод прототипа
определение
Относится к созданию прототипа предполагаемого продукта и получению ранних отзывов о требованиях до фактического производства продукта.
включать
Миниатюры, двух- и трехмерные модели, макеты или симуляции, созданные на компьютере.
инструмент
Аксур
технология прототипирования
Раскадровка
Продемонстрируйте последовательность или путь навигации с помощью серии изображений или диаграмм.
выход
документ с требованиями
эффект
Опишите, как различные отдельные требования будут соответствовать бизнес-требованиям, связанным с проектом (требования высокого уровня).
эталон
Требования, которые являются ясными (измеримыми и тестируемыми), отслеживаемыми, полными, скоординированными и признанными ключевыми заинтересованными сторонами.
Категория требования
1. Потребности бизнеса
Потребности высокого уровня во всей организации, например, решение бизнес-проблемы или использование бизнес-возможностей, а также причины реализации проекта.
2. Потребности заинтересованных сторон
Потребности заинтересованных сторон
3. Требования к решению
Системные требования, чтобы удовлетворить потребности бизнеса и потребности заинтересованных сторон, функции, функции и характеристики, которыми должны обладать продукты, услуги или результаты.
дальнейшее разделение
Функциональные требования
Опишите функции, которыми должен обладать продукт.
Например: действия, процессы, данные и взаимодействия, которые должен выполнять продукт.
нефункциональные требования
Это дополнение к функциональным требованиям и представляет собой условия окружающей среды или требования к качеству, необходимые для нормальной работы изделия.
Например: надежность, конфиденциальность, производительность, безопасность, уровень обслуживания, возможность поддержки, сохранение или удаление и т. д.
4. Потребности в переходном периоде и готовности
Например, требования к преобразованию данных и обучению, которые описывают временные возможности, необходимые для перехода от «текущего состояния» к «будущему состоянию».
5. Требования к проекту
Действия, процессы или другие условия, которым должен соответствовать проект, например контрольные даты, договорные обязательства, ограничения и т. д.
6. требования к качеству
Любые условия или стандарты, используемые для подтверждения успешного завершения результатов проекта или достижения других требований проекта, таких как тестирование, сертификация, валидация и т. д.
Матрица отслеживания требований
определение
Форма, которая связывает требования к продукту от их источника к результатам, удовлетворяющим этим требованиям.
эффект
Связывание каждого требования с бизнес-целями или целями проекта помогает гарантировать, что каждое требование имеет бизнес-ценность.
Предоставляет возможность отслеживать требования на протяжении всего жизненного цикла проекта, помогая гарантировать, что каждое утвержденное требование в документе с требованиями будет реализовано и доставлено в конце проекта.
Также предоставляет основу для управления изменениями содержания продукта.
Отслеживание требований
1. Потребности, возможности, цели и задачи бизнеса
2. Цели проекта
3. Объем проекта и результаты WBS
4. дизайн продукта
5. разработка продукта
6. Стратегии тестирования и сценарии тестирования
Промежуточный анализ случая: пройдите тест, заполните пустые вопросы
7. Требования высокого уровня к детальным требованиям
Типичные свойства записей
Уникальный идентификатор, текстовое описание требования, причина включения требования, владелец, источник, приоритет, версия, текущий статус и дата статуса.
Определить область действия
Обзор процесса
определение
Это процесс разработки подробных описаний проектов и продуктов
основной эффект
Опишите границы и критерии приемлемости продукта, услуги или результата.
Необходимо повторять несколько раз на протяжении всего проекта.
Процесс определения содержания требует выбора окончательных требований проекта из документа с требованиями (результат процесса сбора требований), а затем разработки подробного описания проекта и его продуктов, услуг или результатов.
Необходимость проанализировать полноту существующих рисков (реестр рисков), допущений и ограничений (журнал предположений) и внести необходимые дополнения или обновления.
Подробное описание объема проекта
решающее значение для успеха проекта
Подробное описание содержания проекта должно быть подготовлено на основе ключевых результатов, предположений и ограничений, задокументированных во время инициации проекта.
В процессе планирования проекта, по мере того, как понимание информации о проекте постепенно углубляется, объем проекта должен быть определен и описан более подробно и конкретно.
входить
1. Устав проекта
Содержит общее описание проекта, характеристики продукта и требования к одобрению.
2. План управления проектом – План управления содержанием
Документировано, как определять, подтверждать и контролировать содержание проекта.
3. файлы проекта (Классифицируется по выходу процесса)
1. Разработать устав проекта
Гипотетический журнал
Определил продукт, проект, среду, заинтересованные стороны, а также предположения и ограничения, которые влияют на проект и содержание продукта.
2. Сбор требований
документ с требованиями
Определены требования, которые должны быть включены в объем работ.
3. Определить риски
реестр рисков
Включает стратегии реагирования, которые могут повлиять на объем проекта, например сокращение или изменение объема проекта и продукта, чтобы избежать или смягчить риски.
4. Факторы, влияющие на карьеру
Организационная культура, инфраструктура, система управления персоналом, рыночные условия и т.д.
5. Активы организационного процесса
Политики, процедуры и шаблоны, используемые для разработки заявлений о содержании проекта; файлы проекта из предыдущих проектов; уроки, извлеченные из предыдущих этапов или проектов и т. д.
Инструменты и методы
1. экспертная оценка
Следует обращаться за советом к отдельным лицам или группам, имеющим знания или опыт реализации аналогичных проектов.
2. анализ данных
Анализ альтернатив
Оценивать различные подходы к достижению потребностей и целей, заявленных в уставе проекта.
3. принятие решений
Многокритериальный анализ решений
Метод, в котором используются методы системного анализа с помощью матрицы решений для установления таких критериев, как требования, график, бюджет и ресурсы, для уточнения содержания проекта и продукта.
4. Межличностные и командные навыки
гид
5. анализ продукта
эффект
Используется для определения продуктов и услуг, включая вопросы и ответы на вопросы о продукте или услуге для описания цели, характеристик и других аспектов поставляемого продукта.
Превратите высокоуровневые описания продуктов или услуг в значимые результаты.
шаг
Получите требования высокого уровня
Уточните его до уровня детализации, необходимого для окончательного дизайна продукта.
Технологии включают в себя
Декомпозиция продукта, анализ спроса, системный анализ, системная инженерия, анализ стоимости, инжиниринг стоимости и т. д.
выход
заявление о содержании проекта
определение
Описание масштаба проекта, ключевых результатов, допущений и ограничений.
эффект
Документирует весь объем, включая содержание проекта и продукта, детализирует результаты проекта и отражает консенсус среди заинтересованных сторон проекта относительно содержания проекта.
содержание
1. Описание ассортимента продукции
Постепенно совершенствовать характеристики продукта, услуги или результата, описанные в уставе проекта и документе с требованиями.
2. Практические результаты
Любой уникальный и поддающийся проверке продукт, результат или услуга, которые должны быть созданы для завершения процесса, фазы или проекта, также включают в себя различные вспомогательные результаты, такие как отчеты и документы по управлению проектом. Описание результатов может быть кратким или подробным.
3. Критерии приемки
Ряд условий, которые должны быть выполнены, прежде чем результат может быть принят.
переписка один на один
4. Исключения проекта
Избегайте областей, которые склонны к разногласиям и недоразумениям, например, создание системы управления информацией для Стороны А, но не предоставление ей серверов. Это должно быть отмечено в исключениях проекта.
Определите, что исключено из проекта. Четко укажите, что выходит за рамки проекта, чтобы помочь управлять ожиданиями заинтересованных сторон и уменьшить расползание масштабов.
5. Предположения
6. Ограничения
Связь и отличие от устава проекта
Устав проекта
Содержит информацию высокого уровня
заявление о сфере применения
Подробное описание компонентов объема, которые необходимо постепенно детализировать в ходе проекта.
В содержании есть некоторое совпадение, но уровень детализации совершенно разный.
Уровень детализации, с которой работа должна выполняться и не должна выполняться, определяет, насколько эффективно команда управления проектом может контролировать весь объем проекта.
Файлы проекта (обновлены)
1. документ с требованиями
2. Матрица отслеживания требований
Соберите результаты процесса требований
3. Гипотетический журнал
4. Реестр заинтересованных сторон
Создать СДР
Обзор процесса
определение
Является ли процесс разбиения результатов проекта и работ по проекту на более мелкие, более управляемые компоненты?
основной эффект
Обеспечьте структуру того, что должно быть доставлено.
СДР (структура декомпозиции работ)
определение
Это иерархическая декомпозиция всего объема работ, которые необходимо выполнить команде проекта для достижения целей проекта и создания необходимых результатов.
Значение слова «работа»
Относится к рабочему продукту или результату, который является результатом действия, а не к самому действию.
комплекс работ
Компоненты самого низкого уровня WBS называются пакетами работ, которые включают запланированные работы.
Пакеты работ классифицируют связанные виды деятельности для облегчения организации, оценки, надзора и контроля работ.
это наименьший результат
WBS организует и определяет общий объем проекта и представляет работы, указанные в утвержденном текущем описании содержания проекта.
входить
План управления проектом – План управления содержанием
Определяет, как создать WBS на основе описания содержания проекта.
файлы проекта (Классифицируется по выходу процесса)
1. Сбор требований
документ с требованиями
Подробное описание того, как различные отдельные требования соответствуют бизнес-потребностям проекта.
2. Определить область действия
заявление о содержании проекта
Описывает работы, которые необходимо выполнить, и работы, не включенные в проект.
Факторы, влияющие на карьеру
Стандарты WBS для отрасли, в которой находится проект. Эти стандарты можно использовать в качестве внешних справочных материалов для создания WBS.
Активы организационного процесса
Политики, процедуры и шаблоны для создания файлов проекта WBS на основе уроков, извлеченных из предыдущих проектов, и т. д.
Инструменты и методы
экспертная оценка
Получите информацию от отдельных лиц или групп, обладающих знаниями или опытом реализации аналогичных проектов.
авария
Обзор
определение
Это метод постепенного разделения содержания проекта и результатов проекта на более мелкие, более управляемые компоненты.
комплекс работ
определение
WBS Самый низкий уровень работы, стоимость и продолжительность которого можно оценить и управлять ею.
Уровень детализации
Зависит от размера и сложности проекта
Степень разложения
Зависит от степени контроля, необходимой для достижения эффективного управления проектом.
Как создать WBS
1. нисходящий подход
Может использоваться для объединения компонентов более низкого уровня.
2. Используйте руководство для конкретной организации
3. Использовать шаблон WBS
деятельность по разложению
1. Определить и проанализировать результаты и связанную с ними работу (определить результаты и работу, которые необходимо разбить)
2. Определить, как WBS будет структурирована и организована (определить структурную структуру)
Древовидная структура (организационная диаграмма): подходит для небольших проектов. Структура таблицы (стиль контура): подходит для крупных проектов.
3. Декомпозиция сверху вниз и послойная (пошаговая декомпозиция сверху вниз)
4. Разработать и присвоить идентификационные коды компонентам WBS (Identify WBS Components)
5. Убедитесь, что результаты декомпозированы в необходимой степени (проверьте, соответствует ли уровень декомпозиции)
Структура WBS
тип структуры
1. Фазы жизненного цикла проекта как второй уровень декомпозиции Продукты и результаты проекта размещаются на третьем уровне.
2. Основные результаты как второй уровень декомпозиции
3. Включите различные компоненты более низкого уровня, разработанные организациями, не входящими в проектную группу (например, аутсорсинговые работы). В последующем в рамках аутсорсинговых работ продавец должен подготовить соответствующий договор WBS.
Аутсорсинговая работа также должна быть включена в WBS.
Разложение компонентов более высокого уровня WBS означает разбиение каждого результата или компонента на самые базовые компоненты, которые представляют собой поддающиеся проверке продукты, услуги или результаты.
При использовании гибкого или адаптивного подхода WBS может принять форму схемы, организационной диаграммы или другой формы, иллюстрирующей иерархию.
Различные результаты могут быть разложены на разные уровни.
Подробная разбивка плюсов и минусов
преимущество
Чем детальнее будет разбита работа, тем мощнее будет планирование, управление и контроль работы.
недостаток
Чрезмерная декомпозиция приведет к неэффективному расходованию управленческих усилий, неэффективному использованию ресурсов, снижению эффективности выполнения работ, а также вызовет трудности агрегации данных на всех уровнях WBS.
Меры предосторожности
1. WBS должна быть ориентирована на результат
Цель проекта — предоставить продукт или услугу, а каждая работа в WBS — обеспечить достижимые результаты.
2. WBS должна соответствовать объему проекта.
WBS должна включать и включать только те действия, которые необходимы для достижения результатов проекта.
В WBS сумма всех элементов нижнего уровня должна на 100% представлять собой сумму элементов верхнего уровня (принцип 100%).
3. Базовый уровень WBS должен поддерживать планирование и контроль.
WBS — это мост между планом управления проектом и содержанием проекта.
Нижний уровень WBS должен не только поддерживать план управления проектом, но также позволять руководству отслеживать и контролировать ход выполнения и бюджет проекта.
4. Кто-то, и только один человек, должен нести ответственность за элементы WBS (Принцип независимой подотчетности).
Ответственное лицо только одно, но могут участвовать несколько человек. ИСР и ответственное лицо можно описать с помощью матрицы должностных обязанностей.
5. WBS следует контролировать на 4–6 слоях.
Каждый уровень WBS делит элемент предыдущего уровня на 4–7 новых элементов. Размеры элементов на одном уровне должны быть одинаковыми.
Подразделение может подчиняться только вышестоящему подразделению во избежание перекрестного подчинения.
6. WBS должна включать работу по управлению проектом (поскольку управление является частью конкретной работы проекта), а также работу по субподряду.
7. Подготовка WBS требует участия всех (ключевых) заинтересованных сторон проекта.
8. WBS не статична
После завершения создания WBS ее, возможно, все равно придется модифицировать, и изменения должны быть внесены посредством формального процесса контроля изменений.
9. Принцип 8/80
Пополнить
Продолжительность рабочего пакета контролируется в пределах 8-80 часов.
выход
Базовый уровень объема
определение
— это утвержденное описание содержания, WBS и соответствующий словарь WBS, которые можно изменить только посредством формального процесса контроля изменений и которые используются в качестве основы для сравнения.
заявление о содержании проекта
Включает описание объема проекта, ключевых результатов, предположений и ограничений.
СДР
Это иерархическая разбивка всего объема работ, которые команда проекта должна выполнить для достижения целей проекта и создания необходимых результатов.
контрольный счет
Точка управленческого контроля, в которой объем работ, бюджет и график интегрируются, а производительность измеряется по сравнению с освоенным объемом.
Включать
комплекс работ
Самый нижний уровень WBS — это пакет работ с уникальным идентификационным номером.
Идентификационный номер
Обеспечивает иерархическую структуру, то есть кодирование счетов, для послойного агрегирования информации о затратах, расписаниях и ресурсах.
Управляющая учетная запись содержит два или более рабочих пакета, и каждый рабочий пакет может быть связан только с одной управляющей учетной записью.
пакет планирования
Это компонент иерархической структуры работ, который находится ниже, чем контрольный счет, и выше, чем пакет работ. Содержание работы известно, но подробные сведения о ходе выполнения неизвестны.
Контрольный счет может содержать один или несколько пакетов планирования.
Словарь WBS
определение
Документ, в котором подробно описываются результаты, мероприятия и информация о ходе реализации каждого компонента WBS (дополнение к WBS).
эффект
Словарь WBS обеспечивает поддержку WBS, где большая часть информации создается другими процессами, а затем добавляется в словарь на более позднем этапе.
содержание включает в себя
Идентификация кода счета, описание работы, предположения и ограничения, ответственная организация, этапы графика, соответствующие плановые мероприятия, необходимые ресурсы, смета затрат, требования к качеству, критерии приемки, технические ссылки, информация о соглашении и т. д.
Файлы проекта (обновлены)
Гипотетический журнал
документ с требованиями
Подтвердите область действия
Обзор процесса
следует использовать на протяжении всего проекта
определение
Является ли процесс формальной приемки завершенных результатов проекта
основной эффект
Сделайте процесс приемки объективным
Повысьте вероятность принятия конечного продукта, услуги или результата путем проверки каждого результата.
Следует проводить регулярно на протяжении всего проекта по мере необходимости.
участники
Проверка проверенных результатов процесса контроля качества (Управление качеством) ключевыми заинтересованными сторонами, особенно заказчиком или спонсором, с подтверждением того, что эти результаты были удовлетворительно завершены и официально приняты.
Основание для подтверждения объема
Результаты, полученные в результате соответствующих процессов в области знаний «Управление содержанием проекта» (например, документы с требованиями или базовые уровни содержания).
Данные о производительности труда, полученные в результате процессов выполнения в других областях знаний
Действия для подтверждения объема
Возможный рейтинг
1. Определите, когда требуется проверка области действия
2. Определите, какие входные данные необходимы для проверки объема
3. Определить официально принятые критерии и элементы для определения масштаба
4. Определите организационные шаги для обзорного совещания
5. Совещание по подтверждению объема деятельности организации
Сравните с процессом контроля качества
Процесс подтверждения содержания фокусируется на приемке результатов, тогда как процесс контроля качества фокусируется на правильности результатов и их соответствии требованиям качества.
Обычно перед подтверждением объема проекта команде проекта необходимо сначала выполнить работу по контролю качества (сначала контроль качества, затем подтверждение объема). Например, перед подтверждением объема проекта программного обеспечения необходимо выполнить тестирование системы и другие работы. обеспечить плавность работы по подтверждению.
Процесс контроля качества обычно предшествует процессу проверки объема, но их также можно выполнять одновременно.
Проблемы, которые стоит проверить
Анализ дела пройден
1. Являются ли результаты определенными и подтверждаемыми
2. Имеет ли каждый результат четкую веху, а также имеет ли эта веха четкое и идентифицируемое событие, например письменное одобрение от клиента и т. д.
3. Существуют ли четкие стандарты качества?
Поставка результатов должна иметь не только четкие стандарты, но и стандарты того, выполняются ли они должным образом и существует ли четкая связь между результатами и их стандартами.
4. Четко ли выражены обзоры и обязательства?
Спонсор должен официально согласовать границы проекта, продукты или услуги, которые будут реализованы в рамках проекта, а также результаты, связанные с проектом.
Команда проекта должна иметь четкое представление о том, каковы результаты проекта.
5. Охватывает ли объем проекта все действия, которые необходимо выполнить для продукта или услуги. Есть ли какие-либо упущения или ошибки?
6. Не слишком ли высоки риски масштаба проекта?
Сможет ли руководство снизить воздействие на проект в случае возникновения риска
Различия в фокусе внимания заинтересованных сторон
1. Руководство фокусируется в первую очередь на масштабе проекта.
Относится к влиянию масштаба на ход проекта, средства и ресурсы. Превышают ли эти факторы терпимость организации и являются ли входные и выходные данные разумными.
2. Клиенты в основном ориентируются на ассортимент продукции
Обеспокоенность тем, достаточны ли результаты проекта для завершения продукта или услуги.
3. Менеджеры проектов сосредотачиваются в первую очередь на ограничениях проекта.
Заботьтесь о том, являются ли результаты проекта достаточными и должны ли они быть завершены, достаточно ли времени, средств и ресурсов, а также являются ли основные потенциальные риски и подготовленные решения
4. Члены проектной команды в основном сосредотачиваются на элементах объема проекта, в которых они участвуют и за которые несут ответственность.
Проверьте, достаточно ли вашего рабочего времени, определив время в объеме, есть ли у вас несколько задач в рамках проекта и нет ли конфликтов между этими задачами.
входить
план управления проектом
1. план управления объемом
Определяет, как завершенные результаты будут официально приняты.
2. план управления спросом
Описывает, как определить требования проекта.
3. Базовый уровень объема
Сравните базовый план объема с фактическими результатами, чтобы определить, необходимы ли изменения, корректирующие или предупреждающие действия.
файлы проекта (Классифицируется по выходу процесса)
1. Сбор требований
документ с требованиями
Сравните требования с фактическими результатами, чтобы определить, необходимы ли изменения, корректирующие или предупреждающие действия.
Матрица отслеживания требований
Содержит информацию, связанную с требованиями, в том числе способы подтверждения требований.
2. Качество управления
отчет о качестве
Содержимое может включать в себя обзор всех вопросов обеспечения качества, которыми управляет команда или которые требуют эскалации, предложения по улучшению и ситуаций, обнаруженных в ходе контроля качества.
3. Управление знаниями проекта
Регистрация извлеченных уроков
Уроки, извлеченные на ранних этапах проекта, могут быть применены на более поздних этапах для повышения эффективности и результативности принятия результатов.
данные о производительности труда
В том числе степень соответствия требованиям, количество несоответствий, серьезность несоответствий или количество подтверждений, выполненных в течение определенного периода времени
Проверенные результаты
Относится к результату, который был завершен и проверен на правильность в процессе контроля качества.
Инструменты и методы
Инспекции (обзоры, обзоры продукции и проверки)
Проводить такие мероприятия, как измерение, анализ и валидация, чтобы определить, соответствуют ли работа и результаты требованиям и критериям приемки продукции.
принятие решений
выход
Результаты для приемки
Для результатов, соответствующих критериям приемки, должен быть составлен официальный документ, официально подписан и одобрен заказчиком или спонсором.
Запрос на изменение
Результаты, которые были завершены, но не прошли официальную приемку, а также причины неудачи должны быть документированы. Может возникнуть необходимость подать запросы на изменение этих результатов и выполнить соответствующие работы по устранению дефектов.
информация о производительности труда
Включите информацию о ходе проекта, например, какие результаты были приняты, а какие не были приняты и почему. Запишите эту информацию и передайте ее заинтересованным сторонам.
Файлы проекта (обновлены)
1. документ с требованиями
Зафиксируйте фактические результаты приемки и обновите документы с требованиями.
2. Матрица отслеживания требований
Обновите матрицу отслеживания требований на основе результатов приемки, включая использованные методы приемки и их результаты.
3. Регистрация извлеченных уроков
Диапазон управления
Обзор процесса
определение
Это процесс мониторинга состояния содержания проектов и продуктов и управления изменениями в базовом плане содержания.
основной эффект
Поддержание базового объема на протяжении всего проекта
Необходимо выполнять на протяжении всего проекта.
Процесс определения объема контроля должен быть скоординирован с процессами контроля в других областях знаний управления проектами.
Управление изменениями
Контроль содержания проекта гарантирует, что все запросы на изменения, рекомендуемые корректирующие действия или предупреждающие действия выполняются посредством реализации общего процесса управления изменениями.
Ползучесть масштаба
Неконтролируемое расширение объема продукта или проекта (без соответствующей корректировки времени, стоимости и ресурсов)
входить
план управления проектом
1. план управления объемом
Документировано, как контролировать объем проекта и продукта.
2. план управления спросом
Документировано, как управлять требованиями проекта.
3. план управления изменениями
Определенный процесс управления изменениями проекта
4. план управления конфигурацией
Определяет, какие элементы конфигурации являются элементами конфигурации, какие элементы конфигурации требуют формального контроля изменений, а также процесс контроля изменений для этих элементов конфигурации.
5. Базовый уровень объема
Сравните базовый план объема с фактическими результатами, чтобы определить, необходимы ли изменения, корректирующие или предупреждающие действия.
6. тесты измерения производительности
При использовании анализа освоенного объема базовые показатели измерения производительности сравниваются с фактическими результатами, чтобы определить, необходимы ли изменения, корректирующие или предупреждающие действия.
файлы проекта (Классифицируется по выходу процесса)
1. Управление знаниями проекта
Регистрация извлеченных уроков
2. Сбор требований
документ с требованиями
Используется для выявления любых отклонений от согласованного объема проекта или продукта.
Матрица отслеживания требований
Помогает изучить влияние любых изменений или любых отклонений от базового плана содержания на цели проекта, а также обеспечивает статус контролируемых требований.
данные о производительности труда
Включает количество полученных запросов на изменения, количество принятых запросов на изменения или количество проверенных, утвержденных и завершенных результатов.
Активы организационного процесса
Существующие формальные и неформальные политики, процедуры и руководящие принципы, связанные с контролем объема, доступные методы и шаблоны мониторинга и отчетности и т. д.
Инструменты и методы
анализ данных
Анализ отклонений
Сравните базовые показатели с фактическими результатами (данными об исполнении работы), чтобы определить, находятся ли отклонения в интервалах критических значений или необходимы корректирующие или предупреждающие действия.
анализ тенденций
Анализируйте эффективность проекта с течением времени, чтобы определить, улучшается или ухудшается производительность.
Определение причин и степени отклонений от базового плана содержания и принятие решения о необходимости принятия корректирующих или предупреждающих действий являются важными задачами контроля содержания проекта.
выход
информация о производительности труда
Взаимосвязанная и контекстная информация о реализации проекта и содержания продукта (по сравнению с базовым планом содержания)
включать
Включает классификацию полученных изменений, выявленные отклонения от содержания и причины, влияние отклонений на график и стоимость, а также прогнозы будущих показателей содержания.
Запрос на изменение
План управления проектом (обновленный)
1. план управления объемом
2. Базовый уровень объема
После утверждения изменений в области действия, заявлении области действия, WBS или словаре WBS потребуются соответствующие изменения в базовом плане области действия.
3. базовый уровень прогресса
После утверждения изменений в объеме, ресурсах или сметах расписания требуются соответствующие изменения в базовом плане расписания.
4. базис затрат
После утверждения изменений в объеме, ресурсах или сметах затрат необходимо внести соответствующие изменения в базовый план затрат.
5. тесты измерения производительности
После утверждения изменений в объеме, производительности графика или смете затрат вносятся соответствующие изменения в базовый план измерения производительности.
Если отклонение слишком велико, необходимо переустановить эталон.
Файлы проекта (обновлены)
1. документ с требованиями
Добавить или изменить требования
2. Матрица отслеживания требований
Изменения в документе с требованиями
3. Регистрация извлеченных уроков
упражнение
Правильный ответ — C. Каждый процесс управления сам по себе перекрывается и взаимодействует друг с другом. В процессе контроля объема, если объем меняется, это приведет к изменениям в графике, стоимости и качестве, поэтому эти процессы необходимо интегрировать.
Вариант Б. Изменения в организации, исполняющей проект, могут привести к изменению содержания проекта. Если человек из организации увольняется, но только он имеет право на определенную работу в проекте, работу придется временно приостановить до тех пор, пока не будет выполнена работа. на замену этому сотруднику найден новый человек.