Что такое PRINCE2

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

Оглавление

Введение

Личные впечатления

Об описание методологии

Процесс и активности

Организационная структура

Business case oriented

О продуктах и проектах

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Управления людьми

Управления поставками и контрактами

Воды

Введение

PRINCE2 — английский стандарт на ведение проектов. Изначально создан для IT проектов, потом расширен для использования в любых проектах.

PRINCE2 — основан на четком процессе, разбитом на 8 стадий и 45 подстадий. В этом он подобен RUP. У каждой стадии есть свой набор целей, активностей а также входных и выходных артефактов. Есть критерии, по которым можно судить о качестве артефактов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта.

Особенностью стандарта является его масштабируемость. В каждой стадии и подстадии описано, какую ее часть можно опустить, если проект маленький и гигантский масштаб процессов не требуется. С одной стороны, это очень мило, с другой, отмечается появление большого количества так называемых PINO (Prince in name only) проектов, в которых опущено почти все, но они гордо зовутся сделанными по методологии PRINCE2.

Личные впечатления

Писано Itшниками и для Itшников, что бы там не говорили про пригодность для любого проекта.

Причем Itшниками практикующими. Авторы имели личный опыт управления IT проектами. А к самому документу отнеслись как к софту. Очень четко его написали. Воды (в отличие от PMBOK) почти нет. Нет также пространных размышлений что с одной стороны важно то, с другой это, и нужно обладать опытом, чтобы бла бла (этим также изобилует PMBOK)

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

Документ очень хорошо и четко структурирован. Позволяет изучать его последовательно.

Стандарт является методологией, пригодной к непосредственному использованию для выполнения проектов (по крайней мере IT проектов).

Об описание методологии

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

Начато с того что там 8 стадий процесса (например старт проекта, стратегическое управление проектом) и 8 компонентов/аспектов (планирование, управление изменениями и т п).

Затем детализирована каждая стадия по активностям (или подстадиям) (их уже 45), входящим и исходящим артефактам, критериям, позволяющим активность начать.

Затем описаны связи между активностями (в итоге получаем некую «трехмерную сеть», как оно в жизни и бывает). Указаны какие из 8ми компонентов (аспектов) являются актуальными для каких из 45ти подстадий. Забавно, что у каждой из 45 подстадий есть уникальный идентификатор из одной буквы (первая в названии стадии) и цифры — (порядковый номер в стадии). Сразу видно руку Itшников. :-)

Наконец, для трех важных компонентов (Планирование, управление изменениями и управление качеством) даны уже пошаговые инструкции - техники, как это можно делать. Ключевое слово — МОЖНО. На самом деле «техники» - конкретные пошаговые инструкции могут быть разными, в рамках стадий. При описании процессов даны все важные моменты, о которых надо помнить, выбирая (или придумывая) ту или иную технику. Очень похоже на интерфейсы и имплементации — процессы это интерфейсы, техники — имплементации. Три стандартные техники — дефолтовые имплементации. Имплементации, кстати, вполне себе пригодные к непосредственному использованию.

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

Процесс и активности

Стадии в PRINCE не являются последовательными. Зависимости между ними более сложные , но прописаны они четко.

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

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

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

Организационная структура

Интересен подход PRINCE к оргструктуре проекта.

Есть менеджер проекта в традиционном понимании.

Есть совет проекта (project board), перед которым регулярно отчитывается менеджер. Состоит из 3х человек — Заказчика, Главного пользователя и Главного специалиста. Совет проекта ответственен за принятие стратегических решений. Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету альтернативные решения. Совет решает — какой путь лучше.

Есть служба project assurance цель которой предоставлять независимое мнение о проекте с точки зрения тех же трех групп людей — заказчиков, пользователей и специалистов (в предметной области)

Служба готовит три отчета — buniness report, user report & technical report.

В первый входит отчет о финансовом состоянии проекта и выгодности проекта в целом.

Во второй — отслеживание того, насколько хорошо выполняются требования пользователей

В третий — насколько хорош проект в технологическом плане — туда ли он движется.

В маленьких проектах роль project assurance выполняет совет проекта. В больших это — отдельная группа.

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

Понравилась идея совета проекта (project board) из представителей трех категорий людей в нее входящих. Идея , что успешность зависит не от полного удовлетворения Заказчика, а от сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости. Здесь же — идея о том, что именно совет дает добро (или не дает) всем важным решениям, которые оформляются как бизнес кэйсы.

Стадии и компоненты

Стадии:

• Starting Up a Project (SU)

  Смысл стадии — понять, а надо ли вообще проект делать. Описать причины проекта в документе Мандат Проекта. Выбрать подход к выполнению проекта.

• Initiating a Project (IP)

  Здесь описывается Бизнес Кейс проекта, формируется орг структура. Планируется сроки и цена проекта.

• Planning (PL)

  Планирование и перепланирование проекта. Идет все время жизни проекта.

• Directing a Project (DP)

  Стратегическое управление проектом. Выполняется Project Board-ом на основе документов, предоставленных менеджером проекта и Project Assurance. Менеджер обязан отслеживать возможные риски и возможности проекта и формулировать вопросы к PB. Желательно, чтобы на них можно было ответить да или нет. PB принимает решения. Причем каждый член PB должен отстаивать свой аспект — бизнес, usability и технологический соответственно.

• Controlling a Stage (CS)

  Стандартные активности по ежедневному управлению проектами при помощи контура управления. Осуществляются менеджером проекта.

• Managing Product Delivery (MP)

  Активности по обеспечению создания нужных продуктов в нужные моменты времени. Осуществляются менеджером проекта.

• Managing Stage Boundaries (SB)

  Активности по подготовке и предоставлению информации Project Boardу.

• Closing a Project (CP)

  Активности по контролируемому закрытию проекта.

Компоненты :

• Business case

• Организация

• Контроль

• Управление рисками

• Управление конфигурациаями

• Планы

• Управление качеством

• Управление изменениями

Business case oriented

Понравилась идея периодической оценки проекта на предмет — а не пора ли его закрыть пока не поздно. На самом деле в PRINCE пошли еще дальше — ключевым в проекте является business case , который изначально формально описывается, даются граничные условия, в которых этот кэйс является актуальным (жизнеспособным). Потом кэйс периодически оценивается на предмет не выхода за эти граничные условия. И если вышел — то, при невозможности запихать его обратно, проект немедленно останавливается дабы не тратить ресурсы.

О продуктах и проектах

Забавен «рекурсивный» подход, продвигаемый авторами PRINCE. Например, вместо выделения скажем прототипирования в отдельный этап проекта, утверждается что проекты могут состоять из проектов и прототипирование — отдельный проект, который можно делать по методологии PRINCE. Как отдельный проект может быть выделен проект по пониманию, а нужно ли вообще наш проект делать и тп. Явно прослеживается стремление к обобщению и борьба с расползанием, которого так много в PMBOK

Аналогично, термином «продкут», называют как сам продукт, который надо произвести, так и любую его часть, а также существующие продукты, которые надо задействовать при производстве и продукты, которые при производстве произвести придется (например любой проектный документ — тоже продукт, а написание его можно считать проектом, который можно делать по методологии PRINCE) :-)

При планировании, вместо традиционного WBS используют PBS — Product Breakdown Structure, которая разбивает целевой продукт на непересекающиеся подпродукты (в том числе и проектная документация туда входит)

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Тоесть для

• Business case

• Organisation

• Controls

• Management of Risk

• Configuration management

Хотя первые три «разжеваны» очень хорошо, а вторые две сильно зависят от характера проекта.

Для остальных трех техники описаны:

• Plans

• Quality Management

• Change control

Управления людьми

Остаётся вне контекста, кроме описания орг. Структуры. Ничего про мотивацию и т п

Управления поставками и контрактами

Утверждается что, например, заключение контракта - проект, который надо делать по методологии PRINCE2 (см о продуктах и проектах)

Воды

Никаких лишних рассуждений за жизнь