Wondershare EdrawMind
Галерея диаграмм связей Глава 5 Управление содержанием проекта
- 4
Глава 5 Управление содержанием проекта
Менеджер проекта — это человек, который владеет принципами, приемами, методами и инструментами управления проектами, участвует или возглавляет деятельность по инициированию, планированию, организации, исполнению, контролю и завершению процесса, чтобы гарантировать, что проект может соответствовать указанному объему. ограничения по времени, качеству и стоимости для достижения поставленных целей.
Отредактировано в 2022-06-21 11:42:52
Глава 5 Управление содержанием проекта
- Рекомендовано вам
- Структура
Информационная система Система знаний менеджера проекта (Глава 12 «Управление закупками проекта»)
- 2
Учебное пособие для менеджера проектов информационных систем (4-е издание) Глава 9_Управление содержанием проекта
- 3
Экзамен по расширенному программному обеспечению. Глава 5. Управление содержанием проекта.
- 2
Как быстро работают менеджеры проектов, которые быстро получают повышение по службе и повышение зарплаты
- 1
Глава 5 Управление содержанием проекта
управление содержанием проекта
Цели проекта должны быть выражены более конкретно и должны быть согласованы между заинтересованными сторонами. Делайте что-то в пределах объема и только в рамках объема, ни меньше, ни больше.
1Четкие границы проекта 2 Контроль выполнения работ по проекту 3 Предотвратить расширение масштабов проекта
Сползание объема: новые требования со стороны клиентов, превышающие базовый уровень содержания, неконтролируемое расширение объема продукта или проекта – сползание, вызванное внешними по отношению к проекту причинами;
Позолота масштаба: Заказчик не выдвинул новых требований, а сам проект выполнил лишнюю работу, которая не была нужна - разброс вызван внутренними причинами внутри проектной команды.
Расползание объема: клиенты продолжают бесконтрольно предлагать небольшие, незаметные изменения объема, что в совокупности приводит к серьезному отклонению проекта от базового плана, в результате чего проект выходит из-под контроля или терпит неудачу.
Объем продукта (основное техническое направление): Продукт или услуга воплощают в себе функции страхования, подчеркивая результаты.
Определите, является ли объем продукта полным: судите на основе того, соответствует ли продукт описанию продукта.
Объем проекта (основное направление управления): что проект должен сделать, чтобы доставить продукт – упор на процесс.
Определите, завершен ли объем проекта: базовый план содержания проекта (утвержденное описание содержания проекта, WBS, словарь WBS).
Содержание продукта является основой содержания проекта. Определение содержания продукта является описанием содержания проекта. Определение содержания проекта является основой плана управления проектом продукта. Описание содержания продукта является важной частью содержания проекта. заявление. После изменения объема продукта это сначала повлияет на объем проекта.
управление объемом планирования
Входные данные: 1 план управления проектом 2 устав проекта 3 факторы среды предприятия 4 активы организационных процессов
Инструменты и методы: конференция экспертов
Результат: 1 План управления содержанием 2 План управления требованиями
план управления объемом
содержание: 1. Как разработать описание содержания проекта 2. Как создать WBS (структуру декомпозиции работ) на основе описания содержания 3. Как поддерживать и утверждать WBS 4. Как подтвердить и официально принять завершенные результаты проекта 5. Как обрабатывать изменения в описании содержания проекта
Содержание руководства по подготовке WBS: 1. Определить, что WBS соответствует требованиям функции и проекта, включая затраты на замену и отсутствие замены. 2. Проверьте, обеспечивает ли WBS логическую разбивку всей работы по проекту. 3. Обеспечить, чтобы общая стоимость каждого конкретного слоя была равна сумме затрат компонентов следующего слоя. 4. Изучите WBS с точки зрения всесторонней адаптации и непрерывности. 5. Все должностные обязанности должны быть закреплены за отдельными лицами или организационными подразделениями.
план управления спросом
План управления требованиями описывает, как требования будут анализироваться, документироваться и управляться на протяжении всего жизненного цикла проекта. На протяжении всего процесса Самые основные задачи: Уточнить требования и достичь консенсуса между командой проекта и пользователями, установить базовый уровень требований и создать цепочку контактов с возможностью отслеживания требований, чтобы гарантировать, что все требования пользователей применяются правильно, а при изменении требований они могут полностью контролировать сферу своего влияния. и всегда поддерживать соответствие продукта и спроса.
содержание: ①Как планировать, отслеживать и сообщать о различных действиях, связанных со спросом ②Ресурсы, необходимые для управления спросом, ③План обучения ④Стратегии участия заинтересованных сторон проекта в управлении требованиями ⑤Критерии и процедуры исправления для оценки несоответствия между содержанием проекта и требованиями. ⑥Структура отслеживания требований, ⑦Деятельность по управлению конфигурацией
Сбор требований
Входные данные: 1 План управления содержанием 2 План управления требованиями 3 План управления заинтересованными сторонами 4 Устав проекта 5 Реестр заинтересованных сторон
Результат: документ о требованиях (исчерпывающий метод). Матрица отслеживания требований.
Инструменты и методы: 1 Интервью 2 Фокус-группа 3 Семинар с гидом 4 Групповая инновационная технология 5 Групповая технология принятия решений 6 Анкетный опрос 7 Наблюдение 8 Метод прототипа 9 Бенчмаркинг 10 Диаграмма взаимодействия системы 11 Анализ документов
Классификация требований
Бизнес-потребность: причина реализации проекта (потребность высокого уровня во всей организации)
Требования к решению (функциональные требования, нефункциональные требования)
Потребности заинтересованных сторон
Потребности в переходном периоде
Требования к проекту
Требования к качеству: Стандарты, используемые для подтверждения завершения результатов. 1. Основные требования. 2. Ожидаемые требования. 3. Неожиданные требования.
Инструменты и методы
Интервью
Фокус-группа (групповые интервью один на один для получения более ценного коллективного мнения)
Семинар под руководством гида (быстро определить кросс-функциональные требования, согласовать различия между заинтересованными сторонами и, наконец, сформировать консенсус по установленным целям)
Группа инновационных технологий
Мозговой штурм BS (Каждый высказывает свое мнение)
Методы номинальной группы (углубление BS, структурированная BS, рейтинг голосования)
Техника Дельфи: предотвращение неправильного распространения личного мнения (эксперты, анонимность, несколько раундов, конвергенция, устранение предвзятости).
Концептуальное/ассоциативное отображение (ментальная карта, карта мозга, отражающая общие черты и различия, стимулирующая новые идеи)
Диаграмма родства (диаграмма KJ, ядро — BS, полезно для формулировки WBS)
Многокритериальный анализ решений (несколько критериев, весов, оценок, рейтингов)
Техники группового принятия решений (единогласное согласие, принцип большинства, принцип относительного большинства, диктатура)
Сравнительное сравнение (дети из других семей могут сравнивать организацию внутри и снаружи, выявлять лучшие практики, формировать мнения об улучшении и обеспечивать основу для оценки эффективности)
Анкета
наблюдать
Методы прототипирования (снижение рисков, прогрессивная детализация, Agile, раскадровка)
Схема взаимодействия системы (схема топологии, визуализация)
Анализ документов (анализ существующих документов)
документ с требованиями
Это может быть простой документ, в котором перечислены все требования, классифицированные по заинтересованным сторонам и приоритетам, или это может быть подробный документ, включающий резюме, подробные описания, приложения и т. д.
Содержание: ① Потребности бизнеса ② Потребности заинтересованных сторон ③ Потребности в решениях ④ Потребности проекта ⑤ Потребности в переходном периоде ⑥Предположения, зависимости и ограничения, связанные с требованиями
Отслеживание требований
Управление требованиями включает в себя все действия по поддержанию согласованности и точности требований в процессе разработки продукта, включая контроль базового уровня требований, поддержание соответствия плана проекта требованиям, контроль версий отдельных требований и документов с требованиями, а также управление связями между требованиями. и цепочки контактов или управляйте зависимостями между отдельными требованиями и другими результатами проекта, отслеживайте состояние требований в базовом состоянии.
Прослеживаемость: отслеживание требований предназначено для установления и отслеживания зависимостей и логических связей между одним требованием и другими элементами, включая различные типы требований, бизнес-правила, системные компоненты и файлы справки.
Двусторонняя отслеживаемость
Упреждающее отслеживание: проверьте, может ли каждое требование в документе с требованиями найти соответствующую точку в последующем рабочем продукте (результатах) (чтобы предотвратить пропуск или предвзятость требований);
Обратная трассировка: обратная трассировка, проверка того, можно ли найти результаты работы, такие как проектная документация, компоненты продукта, документация испытаний и т. д., в документе с требованиями. (Она заключается в том, чтобы проверить источник требования и понять, почему это требование выдвигается, какова его исходная подоплека и причины)
1. Исходные требования пользователя можно проследить до документа с требованиями, что позволяет различать требования, на которые влияют изменения, и гарантировать, что документ с требованиями включает все требования пользователя.
2. Проследите от документа с требованиями до соответствующих исходных требований пользователя и подтвердите источник каждого требования.
3. Отследите элементы продукта из документа с требованиями, чтобы узнать элементы продукта, соответствующие каждому требованию, тем самым гарантируя, что элементы продукта соответствуют требованиям.
4. Элементы продукта прослеживаются до документа с требованиями, чтобы члены проектной группы знали причину существования элементов продукта. (Если документ с требованиями невозможно отследить, возможно, он позолочен; если изолированный элемент продукта является законной функцией, в нем могут отсутствовать требования)
5. Отслеживание документов требований способствует лучшей обработке логических корреляций между различными требованиями и проверке возможных ошибок или упущений при декомпозиции требований.
Матрица отслеживания требований
Самый распространенный способ представить цепочку связей между требованиями и другими элементами продукта — использовать матрицу прослеживаемости (возможностей) требований, таблицу, которая связывает требования к продукту из их источников с результатами, которые удовлетворяют этим требованиям.
Типичные атрибуты, записываемые в матрицу отслеживания требований, включают уникальный идентификатор, текстовое описание требования, причину включения требования, владельца, источник, приоритет, версию, текущий статус (например, в работе, отменено, отложено, вновь добавлено). , Утверждено, Назначено, Завершено и т. д.) и дата статуса.
Определить область действия
Входные данные: 1 План управления содержанием 2 Устав проекта 3 Документ с требованиями 4 Активы организационного процесса
Инструменты и методы: 1 Экспертное мнение 2 Анализ продукта 3 Альтернативное поколение 4 Семинары под руководством гида
Результат: 1 описание содержания проекта 2 обновления проектной документации.
заявление о содержании проекта
содержание
① Описание содержания продукта (постепенно уточняйте характеристики продукта, услуги или результата, описанные в уставе проекта и документе с требованиями) ② Критерии приемки (определите ряд условий, которые должны быть выполнены, прежде чем результат поставки сможет пройти приемку, а также приемку процесс) ③Результаты ④Исключения из проекта (необходимо определить, что исключено из проекта. Четкое указание того, что выходит за рамки проекта, поможет управлять ожиданиями заинтересованных сторон) ⑤Ограничения ⑥Предположения
Функция: ① Определение объема, ② Основа коммуникации, ③ Основа планирования и контроля, ④ Основа изменения, ⑤ Основа планирования
Создать СДР
Входные данные: 1 План управления содержанием 2 Описание содержания проекта 3 Документы с требованиями 4 Факторы бизнес-среды 5 Активы организационных процессов
Инструменты и методы: 1. Декомпозиция. 2. Экспертная оценка.
Результат: 1 базовый план объема 2 обновления файла проекта.
уровень СДР
Веха
Веха отмечает формальное завершение результата или этапа. Важные контрольные точки — это вехи, важные вехи — это базовые показатели.
комплекс работ
Рабочие пакеты должны легко распределяться между разными людьми или организационными подразделениями, поэтому необходимо уточнить непосредственный интерфейс каждого рабочего подразделения. Пакеты работ должны быть очень конкретными, чтобы ответственные лица могли понимать свои задачи, цели усилий и обязанности. Правило 8/80 (правило 80 часов) рекомендует, чтобы объем рабочего пакета занимал не менее 8 часов, а общее время выполнения не превышало 80 часов.
контрольный счет
Пункт управления администрацией. В этой контрольной точке объем, бюджет (планирование ресурсов), фактические затраты и график интегрируются и сравниваются с освоенным объемом для измерения производительности. Контрольный счет — это элемент определенного уровня СПП, который может быть пакетом работ или элементом более высокого уровня, чем пакет работ.
планирование домашнего хозяйства
Под контрольной учетной записью — компонент WBS, содержание работы которого известно, но подробные сведения о ходе выполнения еще недоступны. Пакеты планирования — это СПП-элементы, расположенные ниже контрольного счета и выше рабочих пакетов. Пакет планирования временно используется для планирования. По мере прояснения ситуации пакет планирования в конечном итоге будет разбит на пакеты работ и соответствующие конкретные мероприятия.
Словарь WBS
Также называется глоссарием WBS и представляет собой документ, описывающий различные компоненты WBS. Для каждого компонента WBS укажите код счета, описание работы, предположения и ограничения, ответственное лицо или организационное подразделение, контрольные точки графика, связанные плановые действия, необходимые ресурсы, смету затрат, требования к качеству, критерии приемки, технологические ссылки, информацию протокола, и т. д. (Словарь WBS фактически эквивалентен словарю Синьхуа, который представляет собой описание каждого элемента в WBS)
Базовый уровень объема
Заявление о содержании проекта — это описание содержания проекта, ключевых результатов, допущений и ограничений. Весь объем документируется, включая объем проекта и продукта.
WBS — иерархическая декомпозиция всего объема работ (помогает предотвратить расползание объема)
Словарь WBS — документ с подробным описанием результатов, мероприятий и информации о ходе реализации каждого компонента WBS (помогает оценить влияние изменений).
Разложение СДР
Разложение требует действий
①Определить и проанализировать результаты и сопутствующую работу.
② Определить структуру и метод организации WBS.
③Уточнение и разложение слой за слоем сверху вниз.
④ Разработать и присвоить идентификационные коды компонентам WBS.
⑤Убедитесь, что степень декомпозиции результатов соответствует требованиям.
Он должен быть заполнен и единогласно подтвержден всеми членами команды проекта, пользователями и заинтересованными сторонами проекта.
Принцип разделения WBS
①Функциональные или технические принципы. При создании WBS необходимо рассмотреть возможность разделения работы разных людей.
②Организационная структура: Для функциональных проектных организаций WBS также должна адаптироваться к организационной структуре проекта.
③ Система или подсистема: общая система делится на несколько основных подсистем, а затем каждая подсистема разлагается.
Метод разложения WBS
① Каждый этап жизненного цикла проекта используется как второй уровень декомпозиции, а продукты и результаты проекта размещаются на третьем уровне.
②Основные результаты как второй уровень декомпозиции.
③Интегрируйте различные компоненты, которые могут быть реализованы организациями, отличными от команды проекта (например, аутсорсинговые работы), а затем в рамках аутсорсинговых работ продавцу необходимо подготовить соответствующий контракт WBS.
Представительство WBS
Древовидная структура (диаграмма организационной структуры): WBS имеет четкие уровни, интуитивно понятную и прочную структуру, но ее нелегко изменить. Для больших и сложных проектов сложно выразить полную картину проекта (небольшие проекты).
Табличный формат (формат списка): Табличный формат менее интуитивен, но может отражать все рабочие элементы проекта (большие проекты).
Обратите внимание на 8 аспектов при декомпозиции WBS.
①WBS должна быть ориентирована на результат: сумма всех элементов нижнего уровня должна на 100% представлять элементы верхнего уровня.
②WBS должна соответствовать объему проекта. WBS должна включать и включать только те действия, которые необходимы для достижения результатов проекта.
③Нижний уровень WBS должен поддерживать планирование и контроль. WBS — это мост между планом управления проектом и содержанием проекта. Нижний уровень WBS должен не только поддерживать план управления проектом, но также позволять руководству отслеживать и контролировать ход выполнения и бюджет проекта.
④Кто-то должен нести ответственность за элементы WBS, и только один человек, хотя на самом деле для участия может потребоваться несколько человек.
⑤Руководство по WBS: WBS следует контролировать на 4–6 уровнях. Конечно, большие проекты могут превышать 6 этажей.
⑥WBS должна включать работу по управлению проектом (поскольку управление является частью конкретной работы проекта), а также работу по субподряду.
⑦ Подготовка WBS требует участия всех (основных) заинтересованных сторон проекта и участия членов команды проекта.
⑧WBS не статична. После завершения создания WBS, возможно, ее все равно придется модифицировать.
Подтвердите область действия
Входные данные: 1 План управления проектом 2 Документ с требованиями 3 Матрица отслеживания требований 4 Подтвержденные результаты 5 Данные об исполнении работ
Инструменты и методы: 1. Проверка. 2. Техники группового принятия решений.
Результат: 1. Принятые результаты. 2. Запросы на изменения. 3. Информация об исполнении работ. 4. Обновления проектной документации.
Процесс формальной приемки завершенных результатов проекта на протяжении всего проекта, при этом клиент или спонсор совместно проверяют результаты.
Шаги для подтверждения содержания: ① Определите время, когда требуется подтверждение содержания, ② Определите, какие входные данные необходимы для подтверждения содержания, ③ Определите стандарты и элементы для формального принятия содержания, ④ Определите организационные шаги для совещания по подтверждению содержания , ⑤ Организовать совещание по подтверждению содержания.
Фокус другой:
Управление: обратите внимание на масштаб проекта, который относится к влиянию масштаба на ход реализации, средства и ресурсы проекта, выходят ли эти факторы за рамки организации и являются ли они разумными с точки зрения затрат и результатов. . [Корпоративное руководство не будет обращать внимание на слишком подробные вещи. Вам нужно заботиться только о рациональности ввода и вывода]
Клиенты: обратите внимание на объем продукта и на то, достаточны ли результаты проекта для завершения продукта или услуги.
Менеджеры проектов: обратите внимание на то, достаточны ли результаты и должны ли они быть завершены, достаточно ли времени, средств и ресурсов, основные потенциальные риски и подготовленные решения.
Члены команды проекта: заботьтесь об элементах, в которых они участвуют и за которые несут ответственность в рамках проекта.
Проверка продукта: проверьте, завершен ли продукт спонсором или заказчиком в конце проекта (или фазы), подчеркнув, что продукт завершен. Объем подтверждения: подтвердите процесс приемки клиентом или спонсором в конце этапа; для результатов проекта.
Разница между объемом подтверждения и закрытием проекта:
① Хотя работа по подтверждению содержания и закрытию проекта не выполняется на этапе, подтверждение содержания подчеркивает проверку и приемку результатов, тогда как закрытие проекта подчеркивает процессуальную работу, которую необходимо выполнить для завершения проекта (или фазы).
② В объеме подтверждения и закрытии проекта есть работа по приемке. Объем подтверждения подчеркивает приемку результатов проекта, а закрытие проекта подчеркивает приемку продукта.
Разница между объемом подтверждения и контролем качества:
① Объем подтверждения в основном подчеркивает, что результаты приняты заказчиком или спонсором; контроль качества подчеркивает, что результаты являются правильными и соответствуют конкретным требованиям качества (стандартам качества), сформулированным для них.
②Контроль качества обычно проводится до подтверждения объема или может осуществляться одновременно; объем подтверждения обычно проводится в конце этапа, но контроль качества не обязательно проводится до этапа.
③ Контроль качества представляет собой внутреннюю проверку и осуществляется соответствующим отделом качества исполняющей организации; областью подтверждения является проверка и приемка результатов проекта внешними заинтересованными сторонами (заказчиками или спонсорами).
Диапазон управления
Входные данные: 1 план управления проектом 2 документы с требованиями 3 матрица отслеживания требований 4 данные об исполнении работ 5 активы организационных процессов
Инструменты и методы: анализ предвзятости
Результат: 1. Информация об исполнении работ. 2. Запросы на изменения. 3. Обновления плана управления проектом. 4. Обновления документов проекта. 5. Обновления активов процессов организации.
Процесс наблюдения за состоянием содержания проектов и продуктов, управления изменениями базового плана содержания и поддержания базового плана содержания на протяжении всего проекта. Управление содержанием проекта требует обеспечения того, чтобы все запрошенные изменения, рекомендуемые корректирующие действия или предупреждающие действия обрабатывались посредством реализации общего процесса управления изменениями. Процесс контроля содержания также используется для управления изменениями, когда они действительно происходят.
① Воздействовать на факторы, приводящие к изменению масштабов, и стараться, чтобы эти факторы развивались в благоприятном направлении.
② Определите, произошло ли изменение объема.
③Управлять фактическими изменениями при возникновении изменений объема, гарантируя, что все запрошенные изменения обрабатываются в соответствии с общим процессом управления изменениями проекта.
Пополнить
1) Поддерживать целостность проекта иерархически, чтобы не пропустить важные компоненты.
2) Рабочее подразделение может быть подчинено только подразделению верхнего уровня во избежание перекрестного подчинения.
3) Рабочие единицы на одном уровне применяют одни и те же свойства.
4) Рабочее подразделение должно иметь возможность разделять разных ответственных лиц и разное содержание работы.
5) Облегчить потребности планирования управления проектом и контроля проекта.
6) Работа самого низкого уровня должна быть сопоставимой, управляемой и поддающейся количественной проверке.
7) Должна быть включена работа по управлению проектом, включая субподрядные работы.