Темы

Материал из PRINCE2 wiki русский
Перейти к: навигация, поиск

Эта статья также доступна на языках: Английский, Испанский, Португальский, Французский, Польский, Датский, Итальянский.

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

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

Ответом на этот вопрос будут темы:

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

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

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

Тема экономического обоснования

Шаблон:Основная статья: Экономическое обоснование

Экономическое обоснование отвечает на такие вопросы, как:

  • Почему мы делаем этот проект?
  • Каковы бизнес-причины?
  • Каковы выгоды для организации?

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

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

Документация экономического обоснования на протяжении проекта PRINCE2

Начало: Черновик экономического обоснования написан ответственным руководителем и становится частью краткого изложения проекта

Планирование: Экономическое обоснование создается во время стадии инициации из черновика экономического обоснования. Данные о стоимости проекта берутся из плана проекта

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

Themes BC ru.png

Граница стадии: Экономическое обоснование - это живой документ, поэтому он изменяется во время проекта. Например если проект на 50% отстанет от графика, то значение ROI измениться. Менеджер проекта обновляет экономическое обоснование, и оно рассматривается советом проекта, чтобы убедиться, что проект по-прежнему стоит выполнять.

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

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

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

Тема организации

Шаблон:Основная статья: Организация

Темы организации дает ответы на следующие вопросы:

  • Кто есть кто в проекте?
  • Кто спонсирует проект?
  • Кто отвечает за экономическое обоснование?
  • Кто представляет пользователей и поставщиков?
  • Каковы точные роли и обязанности?
  • Кто менеджер проекта?

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

Проект PRINCE2 основан на среде заказчика/поставщика. Одной из сторон является заказчик, который будет определять результат и, скорее всего, платить за проект. Другая сторона - поставщик, который будет предоставлять ресурсы, делать работу и поставлять результаты.

PRINCE2 утверждает, что успешная команда по управлению проектом должна:

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

Организационные документы во время выполнения проекта PRINCE2

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

Themes ORG ru.png

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

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

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

Тема качества

Шаблон:Основная статья: Качество

Тема качества отвечает на вопросы:

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

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

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

Документы качества во время проекта PRINCE2

Начало: Описание продукта проекта (ОПП) - это главное описание продукта, оно дает видение конечного продукта и перечисляет его возможности (критерии приемки), которые должны быть предоставлены для клиента, чтобы принять конечный продукт.

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

Описание продукта содержит сведения о качестве для каждого продукта, поэтому команда разработчиков знает, что они должны сделать, чтобы поставить продукт. Например, критерий качества для GSM батареи: зарядка на 80% менее, чем за 20 минут.

Themes QUA ru.png

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

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

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

Закрытие проекта: В конце проекта конечный продукт будет передан клиенту. Клиент будет использовать критерии приемки (контрольный список), который был определен в описании продукта проекта, чтобы убедиться, что продукт соответствует ожиданиям, и проект может быть закрыт.

Тема планов

Шаблон:Основная статья: Планы

Эта тема отвечает на вопросы такие, как:

  • Что необходимо выполнить для создания продукта проекта?
  • Какие шаги будут предприняты?
  • Как выполнить планирования на основе продукта?
  • Какое качество должно быть достигнуто?
  • Сколько это будет стоить?
  • Каким будет уровень детализации для каждого плана?
  • Кто из организации участвует и какова их ответственность?
  • Когда будет делаться определенные вещи?
  • Кто должен получать копию планов?

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

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

Вы узнаете о различных уровнях планов: (a) план проекта, который является высокоуровневым планом и в основном используется советом проекта; (b) план стадии, который действует как план на каждый день для менеджера проекта; и (c) план команды, который используется менеджером команды.

Документы планов проекта PRINCE2

Начало: Описание продукта проекта (ОПП) - это описание продукта, оно предоставляет видение конечного продукта. Это документ высокого уровня и не должен быть более 1-3 страниц.

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

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

Themes PLA ru.png

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

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

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

Закрытие проекта: В конце проекта следует обновить план проекта, чтобы показать: 1) что должно быть поставлено, 2) что не было доставлено, 3) сроки поставки, 4) окончательная стоимость проекта.

Тема риска

Шаблон:Основная статья: Риск

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

Эта тема помогает раскрыть следующую информацию:

  • Каковы риски?
  • Что делать, если риск произойдет?
  • Как риски могут быть определены, проанализированы и задокументированы?
  • Как можно уменьшить вероятность риска?
  • Как риск может управляться и контролироваться на протяжении всего проекта?

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

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

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

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

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

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

Themes RIS ru.png

Граница стадии: Информацию о рисках в экономическом обосновании можно обновить, если необходимо поставить в известность совет проекта.

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

Тема изменений

Шаблон:Основная статья: Изменения

Все проекты сталкиваются с инцидентами, и большинство проектов будет иметь дело с запросами на изменения и новыми требованиями. Эта тема изменений рассматривает вопрос: «Каково влияние этого инцидента?»

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

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

  • Как следует планировать, выявлять, контролировать и проверять продукты?
  • Как следует обрабатывать инциденты и изменения?
  • Какие инструменты будут использоваться (например, SharePoint, Niku Clarity, общий диск)?
  • Какие данные нужно хранить для каждого продукта (например, описание продукта, записи об элементе конфигурации, и др.)?

Документы изменений во время проекта PRINCE2

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

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

Граница стадии: Отчеты о статусе продуктов - это простые отчеты о состоянии продуктов в конце стадии; могут быть результатом запроса к базе данных управления конфигурацией или применения фильтра к таблице.

Themes CHA ru.png

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

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

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

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

Тема прогресса

Шаблон:Основная статья: Прогресс

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

Эта тема решает следующие проблемы:

  • Как проект будет контролироваться;
  • Когда будет предоставляться отчетность;
  • Где мы сейчас по сравнению с планом; и
  • Является ли проект по-прежнему жизнеспособным?

Цель темы прогресса можно объяснить в трех частях:

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

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

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

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

Themes PRO ru.png

Граница стадии: Отчет о завершении стадии используется для представления состояния прогресса в конце стадии.

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

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

Ссылки