В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических методологий проектного управления. Вопрос классических методологий всё еще актуален для договорных отношений Заказчик – Исполнитель и проектов с каскадной формой управления.
Упомянутый в заголовке статьи стандарт PRINCE2 также актуален и для проектов с гибкими методологиями, так как Agile-методы очень четко и структурировано рассказывают, как правильно разрабатывать продукт (и управлять именно процессом разработки продукта), но как именно управлять проектной деятельностью (а это, как известно, не только один процесс производства продукта) гибкие методологии покрывают не всегда и не полностью.
В силу своей разрекламированности PMBOK всегда был более востребованный и популярный, вместе с этим очень перегруженный по группам процессов (например, для IT-проектов). Многим руководителям проектов использование проектной методологии PRINCE2 в сравнении с PMBOK (в силу лаконичности и структурированности первого) позволяет более изящно управлять проектами разного масштаба и структур.
Историческая справка
PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании. Как указывают сами авторы методологии, PRINCE2 создан на основе опыта, полученного из тысяч проектов, в центре внимания методологии – управленческие стороны проекта.
В 2013 году права на PRINCE2 переданы AXELOS Ltd (совместное предприятие правительства Великобритании и компании Capita).
Исторически методология создавалась для руководства проектами в сфере IT, но в настоящее время является «de facto» стандартом для руководства проектами в Великобритании.
Краткие вводные
PRINCE2:
не гарантирует соблюдение сроков или бюджета, сокращение издержек или увеличение прибыли;
гарантирует прозрачный учет и управление рисками проекта;
формализует возможности оперативного получения данных с необходимой детализацией;
способствует повышению производительности работ в рамках унифицированных форматов управленческих документов.
Создатели методологии также утверждают, что использование PRINCE2 помогает обеспечить правильной информацией в правильное время правильных людей для принятия правильных решений.
Как и любая методология, PRINCE2 обладает своими плюсами и минусами:
+ | - |
Применим для проектов любой проектной области (особенно для IT) | Отсутствуют рекомендации по инструментам менеджеров |
Четкая структура процессов (включая четкие входы и выходы) и процедур управления и контроля | Отсутствуют процессы управления поставками (закупками) |
Минимальные усилия на адаптацию методологии к проектам | Отсутствуют процессы управления участниками команды проекта (в том числе с точки зрения лидерских компетенций) |
Формула PRINCE2
Авторы методологии приводят следующую схему проектного управления: фундаментом являются 7 принципов, в центре находятся 7 процессов, объединяющие 7 тем, вокруг – окружающая среда проекта. При этом стандарт четко указывает, что выбранные авторами 7 принципов универсальны и не требуют обоснования, при этом управление проектом по PRINCE2 возможно только при реализации всех 7 принципов (здесь есть некоторая аналогия со SCRUM: «Только следуя всем правилам SCRUM, можно прийти к успеху проекта»).
7 принципов:
CONTINUED BUSINESS JUSTIFICATION (Постоянная оценка целесообразности). Спонсор проекта (в русских договорных отношениях это чаще всего Заказчик, даже если он внутренний) должен быть постоянно уверен в необходимости реализации проекта, если такая необходимость отпала, то проект следует прекратить. Ожидаемые выгоды должны быть больше затрат и рисков.
LEARN FROM EXPERIENCE (Учет предыдущего опыта). Принцип призывает руководителей проектов постоянно анализировать и использовать извлеченные уроки других проектов, а также фиксировать собственный опыт в ходе своего проекта.
DEFINED ROLES AND RESPONSIBILITIES (Определенные роли и обязанности). В каждом проекте должна быть сформирована матрица ответственности в рамках проекта и его организационной структуре. Авторы PRINCE2 выделяют три заинтересованные стороны проекта: бизнес (определяет цели проекта и инвестирует его), пользователи (используют продукт проекта) и поставщики (предоставляют ресурсы).
MANAGE BY STAGES (Управления по стадиям). Проект должен планироваться, отслеживаться и контролироваться по стадиям, в конце каждой стадии должен обновляться план следующей стадии с учетом результатов завершающейся текущей стадии. Между каждой стадией должны присутствовать точки принятия основных решений.
MANAGE BY EXCEPTION (Управление по исключениям). Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Такой способ управления позволяет экономить как время высшего руководства, спонсоров проекта, так и самого менеджера проекта. Допустимые отклонения должны быть определены для каждого уровня плана проекта.
FOCUS ON PRODUCT (Фокус на продукте). Акцент в проекте должен быть на конечном продукте и его качестве. Процедура управления изменениями снижает увеличение скоупа проекта. Акцент на качестве и утвержденном описании продукта снижает неудовлетворенность пользователей (потребителей) конченного продукта проекта.
TAILOR TO SUIT THE PROJECT ENVIRONMENT (Адаптация к внешним условиям). Проектная команда должна осознавать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта.
7 тем = аспекты проекта, которые требуют постоянного внимания:
Экономическое обоснование (Business Case) позволяет сформировать механизмы для определения востребованности, выполнимости и жизнеспособности проекта, а также остается ли проект таковым на протяжении всего его выполнения. На основании экономического обоснования с учетом выгоды, затрат и рисков должно приниматься решение о дальнейшем продолжении проекта и его инвестициях.
Организация (Organization). Как и в любой методологии проектного управления заинтересованными лицами проекта являются лицо или группа лиц, которая может влиять на проект или на которую может влиять проект (включая процессы и риски проекта). В проекте должна быть определена и сформирована четкая структура ответственности и обязанностей проекта. Подробное описание каждой роли можно прочитать в стандарте.
Управление качеством (Quality) – определение и внедрение средств в рамках проекта для подтверждения, что продукты проекта соответствуют утвержденному описанию и подходят для тех целей, для которых они предназначены. Любой продукт проекта должен обладать определенным комплексом свойств и неотъемлемых или установленных характеристик, которые дают понимание, что продукт отвечает ожиданиям или удовлетворяет установленным потребностям, требованиям или спецификации.
Планы работ (Plans) – широко описывает понятия и уровни планов в проекте (план стадии инициации проекта, план самого проекта, планы стадий создания продуктов, планы исключений, планы команды).
Анализ и управление рисками проекта (Risk). Здесь по классике: управление рисками должно осуществляться не только при инициации проекта или в момент наступления риска, а на протяжении всего срока реализации проекта. Тема анализа и управления риска предоставляет подход к выявлению, оценке и контролю рисков во время проекта и, как результат, повышению успеха проекта.
Управление изменениями содержания (Change) = определение, оценка и последующее управление любыми потенциальными и одобренными изменениями конечных продуктов проекта. При управлении изменениями всегда должен использоваться предыдущий опыт, запросы на изменения и отклонения от спецификации должны оцениваться с точки зрения влияния на экономическое обоснование проекта.
Принятие решений (Progress) – предназначена для формирования и утверждения механизмов мониторинга фактических результатов и достижений проекта и их сравнение с запланированными, прогнозирование целей проекта и его отклонения.
7 процессов, каждый из которых представляет набор операций для управления и реализации проекта:
Начало проекта (Starting up a Project). Цель процесса – выполнить минимальные необходимые действия для принятия решения, стоить ли приступать к стадии инициирования проекта. Данный процесс подразумевает подготовку наброска экономического обоснования проекта для принятия решения о финансировании и необходимости проекта.
Руководство проектом (Directing a Project) – принятие ключевых решений управляющим советом (Directing), делегируя оперативное управление менеджеру проекта. Данный процесс не равен фактическому управлению проектом менеджером проекта.
Инициация проекта (Initiating a Project) предполагает подготовку стратегий управления риском, качеством, коммуникациями и конфигурацией проекта, создание плана проекта и установку средств контроля проекта. Данный процесс выполняется уже менеджером проекта.
Контроль стадии (Controlling a Stage) – делегирование и отслеживание выполнения работы в рамках каждой стадии проекта, формирование отчетов о прогрессе, принятие решений по инцидентам и обеспечение корректирующих действий в проекте.
Управление границами стадии (Managing a Stage Boundary) – предоставление необходимой информации менеджером проекта для оценки управляющим советом проекта успехов текущей стадии и утверждения плана следующей стадии с учетом экономической обоснованности.
Управление созданием продукта (Managing Product Delivery) – управление связью между менеджером проекта и менеджером команды посредством установления формальных требований к приемке, выполнению и поставке результатов проектной работы по созданию продукта проекта.
Закрытие проекта (Closing a Project) – обеспечение конкретного момента для подтверждения приемки продукта и признания достижения целевых показателей проекта, либо отсутствия экономического обоснования продолжения проекта в случае его досрочного прекращения.
Возможная адаптация PRINCE2
PRINCE2 в рамках своего седьмого принципа говорит о том, что все составляющие стандарта (кроме принципов) могут быть адаптированы под конкретный проект (в зависимости от сложности и масштаба) и его окружающую среду (внешние методологии, местное законодательство, стандарты по охране труда, корпоративную культуру). Использование методологии в любом виде (полном или адаптированном) должно добавлять ценность проекта. При этом следует понимать, что не существует единственного правильного варианта адаптации.
Короткие правила для адаптации, которые регламентируют авторы в рамках всего стандарта:
Принципы стандарта должны выполняться всегда.
Темы и процессы можно адаптировать при соблюдении всех принципов.
Назначение каждой темы (аспекта проекта) должны сохраняться при адаптации с учетом выполнения минимальных требований.
Используемые техники должны отвечать потребностям и масштабу проекта.
Адаптация не должна повышать риск провала проекта.
Проектный метод должен соответствовать проектной среде с учетом существующей управленческой структуры.
Хочется отметить отдельно, что PRINCE2 также допускает комбинации и сочетания практик Agile в управлении проектом вместе со своими подходами. Как и Agile-методы, PRINCE2 в своих последних изданиях фокусируются на вовлечении стейкхолдеров и плотной работе с Заказчиками, разделении на четкие роли в рамках темы «Организация». В 2015 году AXELOS выпустил руководство «PRINCE2 Agile: лучшие практики и квалификации», описывающее случаи, в которых необходимо применять те или иные техники Agile совместно с PRINCE2, а когда от них стоит отказаться.
Стадии проекта в PRINCE2 Agile по-прежнему должны устанавливаться на основе потребностей управления проектом, а не превращаться в итерации. Каждый этап содержит один или несколько «выпусков», и каждый «выпуск» содержит одну или несколько «итераций». В PRINCE2 Agile итерации обычно называют «временными рамками». PRINCE2 Agile определяет Agile как набор моделей поведения и практик, а не использование адаптивного жизненного цикла.
Собственный опыт
В своих проектах в «классическом» виде я никогда не применяла PRINCE2 по нескольким причинам: в нашей компании принята своя методология, основанная на комбинации «куски PMBOK + собственные правила», у Заказчиков либо отсутствовала методология управления проектами, либо использовались вырожденные случаи PMBOK/IPMA. При этом внутри нашей компании не запрещено вести проекты по лучшим практикам или методологиям, если это не нарушает правила компании с точки зрения процессов и соглашений с Заказчиком.
Пожалуй, самая главная причина — избыточность в классическом виде некоторых процессов методологии конкретно для моих проектов и взаимоотношений с Заказчиками. Сам стандарт говорит о том, что PRINCE2 допускает использование минимального количества документов (минимальный перечень и требования указаны в стандарте). Вместе с этим, при возникновении каких-то нестандартных ситуации или отклонений в проекте я каждый раз стараюсь проанализировать ситуации по шаблону «а что говорит PRINCE2 на этот счет».
В силу NDA с Заказчиками и компанией могу привести только сопоставление управленческих продуктов PRINCE2, которые были адаптированы в рамках моих проектов (шаблоны PRINCE2):
Название документа по PRINCE2 | Назначение документа по PRINCE2 | Проектные артефакты |
Краткое описание проекта | Для предоставления полного и надежного основания для инициации проекта | Меморандум оценки работ / проекта по шаблону компании |
Экономическое обоснование | Документ, составляемый в начале проекта и содержащий в себе описание продукта проекта, структуру команды, роли и ответственность, и экономическое обоснование | |
Документация инициации проекта | Описание основных характеристик проекта | Внутренний приказ о начале работ по проекту по шаблону компании |
Стратегия управления коммуникациями | Описание смысла и частоты коммуникаций с внешними и внутренними участниками проекта | План управления взаимодействием, в котором описаны представители команд исполнителя и Заказчика, периодичность отчетности, правила проведения совещаний и т.п. |
План проекта | Предоставляет описания, как и когда цели должны быть достигнуты, отображая основные продукты, активности и ресурсы, требуемые в рамках плана | План работ по проекту в MS Project |
Описание продукта | Цели и задачи создания продукта, описание требований к характеристикам продукта и качеству, критерии качества | Функциональная спецификация (оформляется оп требованиям/шаблонам Заказчика) |
Стратегия управления качеством | Определение техники и стандартов качества, которые должны быть применены | Внутренний регламент компании «Технология выполнения проектов» |
Реестр рисков | Запись определенных рисков, относящихся к проекту, включая их статус и историю | Реестр рисков аналогичный шаблону PRINCE2 |
Отчет об окончании стадии | Используется для обзора прогресса на определенную дату, общей ситуации на проекте | Отчет о ходе проекта в свободной форме |
Отчет о контрольных точках | Используется, чтобы сообщать статус комплекса работ с заданной частотой | |
Отчет об исключении | Производится, когда есть прогноз, что рамки допустимых отклонений плана стадии или плана проекта будут превышены | Зафиксированного формата нет, чаще всего отчет об исключениях направляется в виде электронного письма |
Отчет о завершении проекта | Используется при закрытии проекта для оценки как выполняется проект в сравнении с Инициацией проекта | Отчет о завершении проекта по внутреннему шаблону компании |
Отчет об уроках | Используется для передачи извлеченных уроков, которые могут быть полезны для применения на других проектах | |
План проверки выгод | Используется для определения, как и когда могут проводится измерения достижения выгод проекта, ожидаемые Старшим пользователем | Не используется на уровне РП в компании |
Бонус: Сертификация
В настоящее время очень развиты разнообразные программы сертификации в сфере IT, в том числе и по проектному управлению. AXELOS также проводит сертификации по двум своим стандартам: PRINCE2 и PRINCE2 Agile. По данным за 2019 год, сертификация PRINCE2 имеет самое большое распространение в мире в области проектного управления (1,4 млн сертифицированных профессионалов), на 2 месте PMP (700 тыс.), на 3 — IPMA (250 тыс.).
В России в настоящее время доступны все 4 экзамена, краткое описание привожу ниже.
Ступень | Срок действия | Формат сдачи |
PRINCE2 Foundation | Бессрочный | Электронное тестирование: 60 минут, 60 вопросов; проходной балл >55%; нельзя пользоваться книгой |
PRINCE2 Practitioner | От 3х до 5 лет | Наличие уровня PRINCE2 Foundation |
PRINCE2 Agile Foundation | Бессрочный | Электронное тестирование: 60 минут, 60 вопросов; проходной балл >55%; нельзя пользоваться книгой |
PRINCE2 Agile Practitioner | 3 года | Наличие одного из уровней PRINCE2 Foundation |
Сейчас среди многих моих знакомых бытует мнение, что сдавать срочные сертификаты в России по большей части бессмысленно, и редко такие сертификаты приносят долгосрочные бенефиты. Впрочем, в любом случае такие сертификаты помогают понять реальный уровень своих знаний стандартов, поднимают самооценку, и, наверное, статус среди других руководителей проектов (этот список можно продолжать словами про красивые строчки в резюме…).
В любом случае, если погружаться в стандарт основательно, то профессиональные сертификаты получать надо. В свое время, я получила обе степени PRINCE2, и смело могу заверить, что после внимательного изучения стандарта и доступных онлайн-тестов можно легко сдать сертификацию, тем более сейчас существует множество авторизованных провайдеров, проводящих обучение и подготовку к сертификации.
