Разбор ситуации(кейса) 8 для ПМа. Согласование запросов на изменение (CR).

by Опубликовано

Продолжая разбор кейсов для ПМа. Восьмой кейс про обработку запросов на изменение (Change Request) на проекте с контрактом по модели fix price

Ссылки на предыдущие разборы кейсов:

Условие кейса

Вы — ПМ на долгосрочном крупном проекте, который идет уже не первый год. Ваша команда — более 10 человек. На проекте периодически подписывается продление контракта с новым фиксированным объемом работ примерно на год. В процессе работы над таким контрактом клиент присылает вам достаточно крупный запрос на изменение объема работ (Change request). Какой будет ваш алгоритм действий по обработке этого запроса? 

Решение

На проектах с фиксированной ценой и объемом работ процесс внесения изменений прописан прямо в контракте (change request management), обычно в общей форме. Детали обсуждаются на этапе инициирования проекта и на kick-off звонке с клиентом. 
Вот как может выглядеть этот раздел в контракте:

Change Management Any change  in the 1.3 Scope  defined in the current Statement of Work is a Change Request and will be handled through a standard Change Request process which is described below: •  During the project implementation some scope Change Requests may be requested by the Client.  In addition Vendor may identify the matters which it believes should be a subject to a Change Request procedure and will notify the Client about such matters. •  For every Change Request, Vendor will describe the request in writing as soon as reasonably practically possible, including the effort estimation, roughly the change in price (if applicable), project cost based on the rate card defined in 4.1 Fees and the target project duration as well as any changes to the Budget Cap (if necessary), and will provide this information to the Client for approval. •  Vendor is responsible for receiving a written approval for the project cost and the target project duration change as well as any Budget Cap change from the Client for every Change Request before its implementation. The Parties will follow the same procedure in case of any change in Deliverables. The Change Request process will be applied for any changes within the Scope and/or Deliverables described in the current Statement of Work, including but not limited to: (i)  new project requirement or deliverables; (ii)  transformation or expansion of project requirements during the description of functions and features in the specification; (iii)  de-scoping of functions or features; (iv)  movement of resources from one project development area to another. Vendor and the Client will work collaboratively and act reasonably within the best interest of the Client to effect the changes, and where required adjust both the cost and timeframes

В вашем контракте этот раздел может выглядеть иначе, но суть остаётся та же — ПМ сообщает клиенту, что его запрос является запросом на изменение и считает, какое влияние он оказывает на параметры проекта (бюджет, сроки, объем работ)

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

Процесс обработки запроса на изменение

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

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

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

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

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

После того как оценка запроса формально (письменно) одобрена клиентом, ПМ вносит необходимые изменения в планы проекта (сроки, бюджет, ресурсы и так далее). Оценка может быть отклонена клиентом, а также он может изменить изначальную формулировку запроса для его упрощения/удешевления. В таком случае весь процесс надо начинать заново.  Важно вести реестр запросов на изменение, чтобы иметь историю таких запросов в течении проекта.

Дополнительное чтение по теме

  1. PMBOK® Guide – 6е издание, Глава 4.6 — Управление изменениями обьема работ проекта
  2. Концепция: Управление запросами на изменение
  3. Управление изменениями
  4. Инструкция по работе с шаблоном Запрос на изменение в проекте

Опубликовано Alexbelkavets