ГЛАВА 26

Механизм внесения изменений

Один молодой журналист однажды спросил английского премьер-министра Гарольда Макмиллана, чего он больше всего опасается в политике. — Событий, мой мальчик, событий, — ответил тот.

События ломают наши планы. И вы должны быть всегда готовы к этому.

Как вы уже знаете, если что-то ломает наши планы, если возник инцидент, то его нужно максимально оперативно отработать, чтобы он не порождал цепочку проблем. Если удастся все решить быстро и малой кровью — отлично. Но если все-таки не получается остаться в рамках плана и возникает ситуация, которая требует изменений, нам нужно будет их провести. И делается это не как угодно, а упорядоченно. Для этого должен быть определен механизм внесения изменений, корректировки утвержденных требований или параметров проекта.

Ниже вы можете видеть пример матрицы изменений из Положения о проектной деятельности Оргкомитета «Сочи-2014» (табл. 26.1). Матрица фиксировала, как должны приниматься решения по изменениям проектов.

Здесь приведены основные объекты и возможные изменения по ним. Если возникала необходимость провести изменение в проекте, руководитель должен был действовать согласно матрице. Какие-то изменения достаточно было утвердить только на уровне Лидера проекта, какие-то потребуют утверждения с Владельцем (у нас он Куратор). А какие-то, например увеличение сроков, принимаются только на уровне Проектного комитета, который возглавлял Президент Оргкомитета. Например, превышение бюджета утверждали на уровне Проектного комитета.

Но обратите внимание: перераспределение средств внутри общего согласованного бюджета уже не требовало участия Проектного комитета. Достаточно было согласовать с финансистами. Если бы этой таблички не было, то перераспределение также приходилось бы выносить на Проектный комитет, который утверждал бюджет с разбивкой по статьям.

Таким образом, вам нужно быть готовым к изменениям. Ведь мир богаче любых наших планов. И что-нибудь такое обязательно произойдет… Как говорил Хельмут Карл фон Мольтке (который старший), ни один план не переживает встречи с противником.

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

Типовые шаги механизма следующие.

1. Оценить влияние изменения. Как изменение повлияет на установленные ограничения? На принятые обязательства?

2. Подготовить обоснование изменения. Чаще всего это делается в виде отдельного документа — запроса на изменение (ЗнИ). В нем фиксируются такие моменты:

• что именно меняется, какой параметр проекта;
• прежнее и новое значение;
• изменение (или отклонение);
• и самая важная часть — обоснование, почему вы считаете это изменение необходимым.

Почему это так важно? Потому что как только вы начнете согласовывать запрос на изменение, первым же вопросом будет «Зачем?». «Зачем нам что-то менять? Может, вы просто хотите упростить себе жизнь, а на самом деле надо просто поднапрячься, поработать хорошенько — и все останется в согласованных параметрах?»

Помните модель Ананьина? Есть, есть у нас предрасположенность не реагировать на инцидент, пока не станет очевидно, что нужно действовать. Так что не пренебрегайте этим пунктом, всегда готовьте аргументированное обоснование. Шаблон запроса на изменение вы найдете на сайте книги (см. ).

3. Согласование изменения. Существует такой принцип легитимности: любое изменение должно утверждаться на том же уровне, что и исходное решение. Это означает, что если исходное требование утверждалось десятком согласующих на бумаге, то и изменение к нему производится тем же десятком людей, и тоже на бумаге. Сообщением «Всем привет, мы теперь решили делать по-другому» вы здесь не обойдетесь. Так что стоит заранее подумать о том, какие изменения могут возникнуть на проекте, и предусмотреть другие, более простые маршруты согласования. Как в примере сочинской Олимпиады, который я показывал выше.

4. Фиксация решения. Изменение утверждено? Значит, это должно быть официально зафиксировано — в протоколе встречи, подписью в «Запросе на изменение», записью в системе электронного документооборота. Если изменения масштабные и затрагивают другие процессы, возможно, понадобится создать новую версию вашего основного документа — описания проекта, паспорта и так далее.

5. Информирование всех заинтересованных сторон об изменении. Важно, чтобы все узнали о том, что в проекте произошли изменения.

Хочу еще раз подчеркнуть: если заранее не подумать о возможных изменениях, они, согласно принципу легитимности, всегда должны проходить тот же путь, которым принималось первоначальное решение. Вариант «все поменяем как хотим, а там разберемся» может для вас плохо закончиться.

Вообще, изменения — неотъемлемая часть любого проекта. Но все-таки их внесение в проект не должно быть слишком частым. Если у нас постоянно идут изменения, то либо что-то не то с планами и профессионализмом команды, либо вы с заинтересованными сторонами неправильно выбрали подход к управлению проектами. Возможно, вы попали в запутанный домен «Киневин» — ситуацию, в которой очень высока неопределенность. Тогда вам подойдет какой-то фреймворк из мира agile, а скорее — гибридный подход. Посмотрите в таком случае на РИМ-III. Гибрид. Информацию о нем можно найти на сайте .

Цена постоянных изменений может быть очень высокой.

Крупный проект совместного предприятия российской и зарубежной нефтяной компании. Суть: бурение нефтяных скважин и обустройство нового добычного хаба. Сам проект инициирован в 2017 году, завершен в 2023-м. Срок реализации съехал на два года, бюджет превышен на 30%. Экономические показатели тоже сильно съехали.

Причины: за жизненный цикл у проекта сменилось пять руководителей, два раза полностью поменялся состав команды. Многократно менялись требования. Произошли многочисленные смены подрядчиков. Как в таких условиях можно сдать проект в срок?!

Для сложного домена существенные изменения не должны быть слишком частыми. Отлаженная система управления проектом значительно уменьшит количество возможных проблем, а те, которые все же возникнут, будет значительно легче обнаружить и вовремя устранить.

Отправить