Презентация запроса на изменение проекта должна показывать разницу между утверждённым планом и предложенным изменением. Дайте тому, кто принимает решение, исходные обязательства, суть дополнения, его последствия и понятный выбор. Новое требование не становится согласованным только потому, что появилось на последнем слайде.
Когда ответственные за соответствующие работы согласовали оценку влияния, можно использовать Presenti, чтобы превратить описание изменения в черновик презентации. Включите в исходный текст допущения и статус согласования. Это часть запроса, а не второстепенные детали, которые можно убрать при сокращении.
Начните с утверждённого базового плана
Допустим, команда запускает пилот внутренней системы бронирования. Согласованный объём включает форму бронирования, подтверждения по электронной почте и еженедельный отчёт об использовании. Запуск намечен на конец шестой недели, утверждённый бюджет — 40 000 долларов. Теперь спонсор проекта просит добавить единый вход до начала пилота.
Во всём примере используются вымышленные плановые показатели. Оценки команды — учебные допущения, а не цены или обещания сроков реальной интеграции.
На первом слайде укажите, что уже согласовано и что запрашивается. Рядом с объёмом работ приведите версию базового плана или ссылку на решение о его утверждении, чтобы участники могли свериться. Если действующий план уже изменился, сначала уточните эту запись и только потом сравнивайте её с новой заявкой.
Рекомендации Microsoft по оценке изменений проекта на английском языке рассматривают влияние на требования, финансирование и даты, а также полномочия для согласования запроса. Презентация должна учитывать реальные правила проекта. Универсальный шаблон не определяет, кому разрешено принимать такое решение.
Покажите прирост затрат и сроков, а не только новый итог
В примере технический руководитель оценивает добавление единого входа в 8000 долларов сверх утверждённого бюджета и десять рабочих дней сверх текущего графика. Оценка предполагает, что настройки системы идентификации, тестовые учётные записи и участники проверки будут готовы к нужному моменту. Поместите эти допущения рядом с оценкой.
| Параметр | Утверждённый план | Предлагаемое изменение | Результат в случае согласования |
|---|---|---|---|
| Объём работ | Форма бронирования, подтверждения по почте, еженедельный отчёт | Добавить единый вход | Текущий объём плюс интеграция и согласованные работы по её приёмке |
| Бюджет | 40 000 долларов | Дополнительно около 8000 долларов | Итого, по оценке, 48 000 долларов |
| Запуск пилота | Конец шестой недели | Предполагаемое продление на десять рабочих дней | Конец восьмой недели при пятидневной рабочей неделе в этом примере, без праздников и конфликтов ресурсов |
| Зависимости | Текущие условия для запуска пилота | Настройки идентификации, тестовые учётные записи, проверка интеграции | При задержке любой зависимости оценку нужно пересмотреть |
Дополнение составляет 20 % исходного бюджета: 8000 ÷ 40 000 долларов. Этот процент даёт контекст, но не является автоматическим правилом согласования. Оценка в десять дней работы также не всегда означает задержку запуска на десять дней. Здесь прямо принято, что дополнительные работы удлиняют цепочку, определяющую запуск. В реальном плане покажите зависимости и доступные ресурсы, на которых основана оценка влияния на сроки.
Не указывайте точную новую дату, если команда предоставила только длительность, а необходимые условия ещё не подтверждены. Если дата нужна, рассчитайте её по календарю проекта вместе с ответственным за график.
Предложите варианты, которые действительно можно согласовать
За выбором «принять или отклонить» может скрываться полезный промежуточный вариант. Для этого запроса сравните три подхода по одинаковым критериям:
| Вариант | Что меняется | Главное последствие | Что нужно подтвердить |
|---|---|---|---|
| Добавить интеграцию до запуска | Сохранить все текущие результаты работ и добавить единый вход | Около 48 000 долларов в сумме и продление на десять рабочих дней | Зависимости, доступность проверяющих и согласование изменения |
| Сохранить текущий пилот, а интеграцию запланировать позже | Оставить утверждённый объём пилота и оценить отдельный последующий выпуск | Исходная дата запуска остаётся ориентиром для планирования | Допустим ли текущий способ доступа и не создаст ли поздняя интеграция дополнительные работы |
| Заменить часть работ в рамках пилота | Оценить замену или перенос другого результата работ | Влияние на стоимость и дату ещё не оценено | Что можно перенести, от чего это зависит и какова новая оценка |
Третий вариант не означает автоматически «тот же бюджет, та же дата». Удаление отчёта из объёма не доказывает, что освободившихся людей или времени хватит для интеграции. Отметьте, что вариант ещё не оценён, и запросите анализ влияния, если его стоит рассматривать дальше.
Второй вариант тоже требует условия. Если новое требование обязательно для работы пилота, отложить его может быть невозможно. Презентация должна показать это ограничение, а не сохранять в таблице удобный, но непригодный вариант.
Структура запроса на изменение из шести слайдов
- Запрашиваемое решение. Назовите изменение, рекомендуемый вариант и срок, к которому нужно принять решение.
- Текущие обязательства. Покажите утверждённые объём, бюджет и этапы со ссылкой на базовый план.
- Причина запроса. Объясните, кому нужно изменение и что произойдёт при его переносе. Отличайте обязательное требование от пожелания.
- Влияние. Покажите дополнительные затраты, сроки, работы и зависимости. Укажите ответственных, предоставивших оценки.
- Альтернативы. Сравните жизнеспособные варианты и нерешённый вопрос по каждому из них.
- Запись решения. Оставьте понятные поля для фактического решения, условий, принимающего решение и даты.
Вынесите технические подробности и расшифровку оценок в приложение. Основные слайды должны объяснять последствия, не заставляя согласующего изучать каждую задачу. Сравнение объёма работ до и после часто понятнее общей дорожной карты, где новый запрос теряется среди уже запланированных работ.
Учитывайте неопределённость и новые данные на встрече
Если на встрече меняется зависимость, покажите, на какую часть рекомендации это влияет. Например, отсутствие тестовых учётных записей может сделать оценку продления на десять дней недействительной. Зафиксируйте необходимость обновить оценку вместо того, чтобы защищать устаревшее число.
Условное решение должно быть таким же конкретным. «Приступить, если технический руководитель подтвердит оценку, а спонсор согласует увеличение бюджета» — не то же самое, что «Согласовано». Не обозначайте оба статуса одним зелёным цветом и не убирайте условия с последнего слайда.
После встречи сохраните обсуждавшуюся версию запроса и свяжите с ней записанное решение. Меняйте план выполнения только по принятой в проекте процедуре управления изменениями. Сама по себе новая версия презентации не говорит команде, какие объём, дата и бюджет теперь действуют.
Составьте задание, в котором запрос не превращается в согласование
Вставьте проверенный текст в Presenti, чтобы организовать его в редактируемый черновик слайдов. Включите базовый план проекта, оценки и допущения. Одной темы вроде «запрос на изменение» недостаточно: слишком многое в обосновании останется неуказанным.
Создай презентацию из шести слайдов о вымышленном запросе на изменение пилота внутренней системы бронирования. Утверждённый объём: форма бронирования, подтверждения по электронной почте, еженедельный отчёт об использовании. Утверждённый бюджет: 40 000 долларов. Плановый запуск: конец шестой недели. Дополнение: единый вход до запуска пилота. Оценка технического руководителя: дополнительные 8000 долларов и десять рабочих дней, удлиняющих цепочку запуска, при условии готовности настроек идентификации, тестовых учётных записей и проверяющих. Только для этого примера используй пятидневную рабочую неделю без праздников. Сравни добавление сейчас, сохранение текущего пилота с оценкой последующего выпуска и замену части работ, требующую новой оценки. Не назначай стоимость или дату ещё не оценённой замене. Сохрани обязательные требования, допущения и условия согласования. Оставь поля фактического решения и согласующего незаполненными; не придумывай одобрение.
Проверьте черновик на незаметные подмены смысла: «оценено» превращается в «подтверждено», условный вариант — в обещание, а пустое поле решения — в согласование. Это важнее выбора темы оформления. Готовая презентация должна облегчать оценку запроса, сохраняя исходные обязательства.
