Зачем нужна формальная процедура изменений, что писать в запросе, кто его утверждает и чем это отличается от простого переноса срока в плане.
Обновлено 11.09.2026
Любой проект меняется. Вопрос не в том, менять или нет, а в том, остаётся ли после изменения понятно, что было обещано изначально. Формальный запрос на изменение существует ровно для этого.
Не всякая правка требует процедуры. Перенос внутренней задачи на день - работа руководителя проекта. Изменением считается то, что задевает обязательства: объём работ, дату сдачи, бюджет, состав результата.
Сдвиг вехи, рост бюджета, добавление или снятие работ, смена требований к результату.
Перестановка работ внутри этапа, замена исполнителя, уточнение длительности в пределах резерва.
Что произошло. Не «по просьбе заказчика», а что именно изменилось в условиях.
На сроки, бюджет и объём - в цифрах. Запрос без оценки влияния утверждать нечем.
Хотя бы два: сделать и не сделать, с последствиями каждого. Решение без альтернативы - не решение.
Уровень зависит от суммы влияния. Мелкие - руководитель проекта, крупные - заказчик.
Можно. Через полгода никто не вспомнит, почему проект идёт на два месяца дольше и стоит на треть дороже: цепочка мелких сдвигов не оставляет следов. Запросы оставляют - и по ним видно, что половина изменений пришла со стороны заказчика, а половина из недооценки на старте.
Вторая причина техническая: без процедуры базовый план переписывается молча и перестаёт быть базовым. Тогда отклонений не будет никогда - план всегда будет совпадать с фактом.
Гонять каждое изменение к заказчику - верный способ похоронить процедуру. Работает лестница уровней, привязанная к масштабу влияния.
Изменения внутри резерва: сдвиги без влияния на веху, замена исполнителя, перераспределение работ.
Влияние на бюджет до нескольких процентов или сдвиг внутренней вехи.
Всё, что задевает договорные обязательства: срок сдачи, стоимость, состав результата.
Границы уровней стоит записать один раз в начале проекта. Спор о том, кто вправе утвердить изменение, посреди изменения - худшее время для такого спора.
Процедура умирает от двух крайностей. Либо через неё пропускают всё подряд, и она становится тормозом; либо ею пользуются раз в квартал, и она ничего не фиксирует.
Изменения ниже порога проводит руководитель проекта своим решением. Порог должен быть числом, а не ощущением.
Запрос без срока рассмотрения зависает. Три рабочих дня - разумный ориентир.
Причина, влияние, варианты и решение в одном месте. Переписка в почте не заменяет запрос, потому что её нельзя найти через год.
Особенно нужен. Устная просьба через полгода превращается в «мы такого не просили».
Хранить. Отклонённый запрос - доказательство, что вариант рассматривали и сознательно от него отказались.
Тот, кто обнаружил необходимость изменения. Оценку влияния готовит руководитель проекта.
План, риски, качество, бюджет и трудозатраты в одном контуре
Проекты, доски, программы и портфели
Связи, критический путь, базовые планы, импорт MS Project