Воздействие изменений, вносимых в проект, на его содержание, расписание, качество и прочие параметры легко может выйти за границы опыта автора данного изменения [7]. Как следствие этого проект может значительно пострадать и в некоторых случаях даже потерпеть крах (см. приводимые ниже заштрихованные прямоугольники «Расползание содержания, вызванное проектом по предметной части» и «Расползание содержания, вызванное недостатком проекта по предметной части: короткое интервью с менеджером проекта»). По этой причине очень важно обеспечить, чтобы каждое изменение оценивалось дисциплинированным (упорядоченным) и профессиональным образом, прежде чем будет получено разрешение на его практическую реализацию. Запрос на внесение изменений в проект как раз и предназначен для того, чтобы помочь выполнить всестороннее оценивание предлагаемых изменений (см. рис. 11.3).

Рис. 11.3.Пример запроса на внесение изменения в проект

Хотя запрос выглядит как простая форма (стремитесь к тому, чтобы он укладывался в 1 страницу и включал то количество вспомогательных деталей, которое необходимо), подготовка его требует определенной домашней работы, и начинается эта работа с подготовки исходной информации.

Подготовка исходной информации.В случае крупных проектов основные исходные данные для использования запроса на внесение изменения – это базовый план содержания с ИСР и план контроля изменений (см. раздел «Констатация содержания» главы 5). В случае более малых проектов исходные данные обычно включают в себя устные указания, касающиеся пунктов, включенных в план.

Расползание содержания, или неконтролируемое изменение содержания, часто рассматривается как главная угроза проектам [2, 3]. Однако некая компания, имеющая дело с очень неопределенными проектами фабрик по производству полупроводников, контролирует изменения по принципу «одно изменение за один раз». Во время определения содержания, исторически предрасположенного к большому количеству изменений, компания устанавливает (определяет) сумму денег, равную 10% от бюджета проекта, которая получает название резерва на изменения (AFC). Назначение этого резерва состоит в том, чтобы оплачивать те элементы содержания, которые не могут быть предсказаны. Чтобы держать процесс под контролем, всякий раз, когда возникает необходимость во включении такого элемента, когда всплывает такой вопрос, этот элемент трактуется (рассматривается) как изменение содержания, и менеджер проекта должен формально утвердить его. Эта очень успешная практика помогла компании контролировать расползание содержания с помощью AFC.

РАСПОЛЗАНИЕ СОДЕРЖАНИЯ, ВЫЗВАННОЕ НЕДОСТАТКОМ ДИЗАЙНА: КОРОТКОЕ ИНТЕРВЬЮ С МЕНЕДЖЕРОМ ПРОЕКТА Вопрос:Какого типа проектом вы управляете?

Ответ:Передо мной поставлена задача разработать платформу продуктов для бизнес-единицы ВАС.

Вопрос:Есть ли какие-нибудь серьезные проблемы?

Ответ:Самая малость! Спустя шесть месяцев после начала проекта вице-президент (VP) корпорации потребовал, чтобы платформа была изменена для включения еще двух бизнес-единиц. Несколько месяцев спустя нам было приказано добавить портативную версию продукта.

Вопрос:Каким образом эти изменения повлияли на проект?

Ответ:Первоначальное содержание предполагало завершение через 18 месяцев при бюджете 2 млн долл. На данный момент мы уже 3 года как увязли в этом проекте, бюджет подбирается к 4 млн долл., и нам необходимо еще 6 месяцев, чтобы завершить его.

Вопрос:Однако ваша платформа продукта великолепна, верно?

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

Когда вам следует начинать применять PCR?Как показывает жизненная мудрость, изменение должно быть предложено сразу же, как только возникает необходимость в нем. Мы бы хотели несколько уточнить это положение. Ранняя концептуальная стадия определения содержания проекта – это время, когда нет места использованию PCR как средства контроля изменений. При наличии лишь грубо очерченного содержания нет никакого практического смысла пытаться контролировать изменения. Однако на более поздней стадии определения содержания использование для этой цели PCR приобретает практический смысл. Например, проект разработки нового продукта, в ходе которого еще не было проделано никакой работы по проектированию или не было выпущено ни одного чертежа, не нуждается в применении PCR. Более вероятно, что PCR будет использован для изменений, которые [7]:

•составляют отход от согласованных технических спецификаций (норм) на проектирование;

•влияют на спецификации, выпущенные инженерным отделом для планирования закупок или производства.

Принимая во внимание, что приведенные выше положения – это примеры, организация должна создавать свои собственные политики.

Когда вам следует заканчивать применять PCR?Хотя этот вопрос может выглядеть как бессмысленный, приходит такое время, когда любое изменение может замедлить ход продвижения проекта, потенциально ведя к дорогостоящим убыткам и переделкам. В таких ситуациях эффективным шагом является замораживание проекта по предметной части, после которого ни одно изменение не будет рассматриваться, если только не находится доминирующей причины в пользу такого рассмотрения. В качестве примера можно привести финансируемое заказчиком требование добавить в продукт новый показатель безопасности. Хорошее общее понимание того, каким образом будет осуществляться работа с планом контроля изменений и временными параметрами, необходимо нам до того, как мы начнем иметь дело с конкретными запросами на внесение изменений в проект.

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

Объяснение причин изменения.Почему у нас возникает желание реализовать то или иное запрашиваемое изменение? Мотивация может быть различной. Для того чтобы иметь уверенность в правильном понимании мотивации и не допустить мотивации, идущей во вред, одна организация требует от автора изменения, чтобы он сформулировал, к какому типу относится данное изменение: необходимое или желаемое. На профессиональном жаргоне, принятом в компании, необходимое изменение – это то изменение, без которого проект может погибнуть. Вследствие этого оно требует надлежащего внимания и одобрения (утверждения). С другой стороны, желаемое изменение обычно придает продукту проекта большую элегантность, но не меняет суть. В то же время желаемое изменение может легко привести к дополнительным усилиям по перепланированию, что становится основным доводом в пользу отклонения такого изменения. Эта почтенная концепция «необходимого / желаемого изменения» может стать хорошим подспорьем для тех, кто склонен игнорировать или недооценивать риски, сопутствующие расползанию содержания. Эта концепция может нравиться или не нравиться, однако, для того чтобы обезопасить себя, убедитесь, что каждое предлагаемое изменение имеет свое разумное обоснование.

Идентификация чрезвычайных изменений.Одна из основных проблем, сопутствующих регулярному, ориентированному на формальности рассмотрению PCR, состоит в том, что такое рассмотрение чрезмерно медлительно. Чтобы преодолеть эту проблему, вам нужно ввести в систему такую характеристику, которая бы обеспечивала быстрое реагирование на срочные PCR, которые обозначены словами «Требуются чрезвычайные действия». Задача такого PCR – проинформировать орган по изменениям о том, что запрашиваемое изменение нуждается в срочном рассмотрении и утверждении. Это может означать, что органу по изменениям придется действовать быстро. В зависимости от правил, установленных политикой, они могут решить этот вопрос на личном совещании, по телефону или с помощью интерактивной программы, обеспечивающей взаимодействие через интранет организации (см. приводимый ниже заштрихованный прямоугольник «Интранет помогает рассматривать финансируемые заказчиком изменения как привилегированные»). Исключительно важно, чтобы чрезвычайные изменения не являлись оправданием дезинформирующих оценок в части качества, исполнения, надежности, безопасности или любых других аспектов. Принятие мер предосторожности, которые обеспечивают надлежащее рассмотрение изменений, может быть полезным средством.

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

Оценивание влияния на стоимость проекта.Требование выполнения оценивания стоимости или ресурсов, необходимых для предлагаемого изменения, представляет собой благотворную стратегию предотвращения финансовых сюрпризов. То, что люди склонны к недооценке стоимости, хорошо известно и задокументировано в различных книгах и статьях. Десятилетия назад, так же, как и сегодня, ошибка в оценке на 20 с лишним процентов не являлась чем-то странным и необычным. Странным и необычным является неспособность руководства принять эту тенденцию во внимание (учесть эту тенденцию) при оценивании запросов на изменения. Требование выполнения основанной на базе данных восходящей оценки при подаче запроса на внесение изменения – это имеющая твердое обоснование мера предосторожности, направленная на противодействие этой тенденции. Если изменение является значительным, вполне можно пойти дальше и запросить оценку из независимого источника, чтобы сравнить ее с оценкой автора изменения. Данная практика часто используется менеджерами проектов фирмы Intel под названием «теневая оценка».

Идентификация типа изменения.В некоторых организациях существует практика утверждения значительных изменений содержания без обращения к первоначальному содержанию (часто называемому базовым планом содержания). Эта порочная практика приводит к тому, что содержание меняется постоянно и превращается в плавающую цель. Риск здесь состоит в том, что плавающее содержание, расписание, стоимость и качество могут раздуться до того состояния, когда проект фактически выродится в новый проект, который потребует планирования и исполнения, отличающихся oт текущих. Для того чтобы предотвратить это, необходимо просеять все предлагаемые изменения, идентифицировав, как они повлияют на содержание и качество. Если изменение окажет незначительное влияние (если вообще окажет), то оно может рассматриваться как незначительное корректирующее воздействие, не затрагивающее базовые планы содержания, качества, стоимости и расписания.

И наоборот, изменение может быть определено как значительная перемена в содержании работ, финансировании и сроках. Это может служить оправданием перепланирования (или переопределения базового плана), включая изменение констатации содержания, ИСР, расписаний, бюджета и распределения ресурсов. Для того чтобы сделать всех вовлеченных в полном объеме осведомленными о таких последствиях, необходимо определиться с тем, является ли данное изменение значительным или незначительным. А это, в свою очередь, становится возможным лишь после оценивания влияния изменения на содержание, качество, стоимость и расписание (для этого оценивания отведена верхняя часть PCR).

В этой же части PCR может быть идентифицирован и рассмотрен еще один тип изменения. Поскольку современные расписания находятся под давлением сроков (характеризуются поджимающими сроками), в некоторых организациях вводится требование установки приоритетов для отдельных запросов на изменения, что обеспечивает более короткие сроки реагирования для изменений большей важности. В некоторой организации была учреждена система контроля изменений с четырьмя уровнями приоритета, и согласно этой системе орган по изменениям должен был реагировать на изменения наивысшего приоритета в течение 24 часов, а на изменения наинизшего приоритета – в течение 30 дней. Это великолепный пример того, как можно обеспечить быстрое реагирование при необходимости и препятствовать внесению нежелательных изменений.

Заказчики очень четко дали это понять в случае с Oscope, Inc (OI): «Мы не желаем мириться с вашими длительными сроками реагирования на наши запросы на внесение важных изменений!» Стремясь удержать заказчиков, OI переработала свою процедуру контроля изменений, внеся в нее три важных новшества. Во-первых, было введено правило, согласно которому время рассмотрения запросов заказчика на внесение важных изменений составило 48 часов. Эти изменения требовали значительных усилий по оцениванию, включая труд инженеров по проектированию, инструментальной обработке и производству, а также специалистов по маркетингу и закупкам. Дополнительно к этому эти люди и их представители не были собраны в одном месте, вследствие чего коммуникация между ними была медленной и потребляла значительное время. Во-вторых, OI создала в интранете сайт, что значительно ускорило коммуникацию. В-третьих, вместо принятия комитетом по изменениям решения на основе консенсуса (как правило, весьма медленный метод) было решено наделить одного члена комитета полномочиями утверждать изменения, в то время как остальные члены рассматривались лишь как рецензенты. Переработка системы привела к радикальному улучшению, что помогло OI удержать своих клиентов.

Прочие соображения.Частью PCR являются также такие требования как решения комитета по изменениям, принятые по представленному запросу, либо необходимость затребования дополнительной информации. Поскольку эти требования в достаточной мере говорят сами за себя, их более детальное рассмотрение здесь может быть излишним.

Развертывание и закрытие.Утверждение запроса на изменение есть не что иное, как прелюдия к собственно действию по реализации изменения. И, как и в случае любых других действий, выполняемых в ходе проекта, это действие требует планирования, в высшей степени скрупулезного для больших проектов и менее скрупулезного для малых. Планирование действия по изменению и тщательный мониторинг его выполнения являются необходимыми предварительными условиями для его успешного завершения. Однако чтобы добраться до завершения, необходимо убедиться, что все конфликты разрешены – ибо таковые могут возникнуть по ходу реализации изменения – а также в том, что завершены все (вторичные) изменения, вытекающие из действий по реализации (первичного) изменения. Лишь после этого можно объявлять, что изменение реализовано.

Когда использовать.Каждый проект должен использовать PCR для просеивания и рационального оценивания предлагаемых изменений [8]. В более крупных проектах использование PCR нуждается в документировании (насколько это возможно) – для того, чтобы оставить след в виде зафиксированных изменений. Вследствие того, что над малыми проектами обычно довлеет недостаток бюджета, они обычно не могут позволить себе вести документирование PCR, что служит обоснованием использования уникального неформального использования PCR. Во-первых, все пункты, присутствующие в документированном PCR, присутствуют также и в таблице изменений небольшого проекта. Однако эти пункты будут обсуждаться, устанавливаться, разделяться и применяться устно для любого рассматриваемого изменения. Само по себе присутствие такой дисциплины, разумеется, не может обеспечить строгости документированного процесса, однако с легкостью может приспособиться к недостатку ресурсов и лихорадочному темпу, свойственному малым проектам. Проще говоря, дадим малым проектам возможность жить с тем, с чем возможно.

Время использования.Несколько минут – вот и все время, которое необходимо для заполнения PCR. Однако, это лишь техническая часть, которой должен предшествовать солидный анализ, являющийся функцией размера и сложности предлагаемого изменения. В случае мелкомасштабного изменения, подобного приведенному в примере на рис. 11.3, расчет его последствий для содержания, стоимости и расписания может потребовать от 15 до 30 минут. В другом конце спектра лежат значительные изменения, вносимые в крупные проекты, и в этих случаях группе экспертов может понадобиться неделя или две для того, чтобы в полном объеме оценить влияние запрошенного изменения на бизнес-цель и задачи проекта, задаваемые тройственным ограничением «содержание – сроки – качество».

Выгоды.Благодаря своему процессу, структуре и содержанию PCR предоставляет руководству выгоды, заключающиеся в том, что оно может принимать осознанные решения, а не пускать события на самотек. Естественно, что в результате совместной работы руководства и членов команды проекта над PCR принимаемые решения имеют более высокое качество. Когда решения основываются на других инструментах или координируются с другими инструментами, необходимыми для оценивания влияния PCR, содержание, стоимость и расписание проекта держатся под контролем и в соответствии друг с другом. К очевидным результатам также относятся документирование изменений, меньшая путаница среди участников проекта, улучшенный контроль изменений содержания, меньшая общая стоимость и меньшие задержки.

Преимущества и недостатки.Основные преимущества PCR – это:

•ясность.PCR является воплощением ясности: «Это то изменение, которое мы предлагаем внести, и вот как оно влияет на фундаментальные параметры проекта». Для обеспечения возможности понять суть изменения ясность имеет основополагающую важность;

•краткость.PCR целенаправленно исключает любые детали, находящиеся за пределами фундаментальных параметров. Ecu in возникает необходимость в большей детализации для работы с изменением, то эти детали приводятся в приложении. Таким образом, сама суть изменения, его существо, не будет страдать от чрезмерного уровня детализации.

Ценность вышеперечисленных неоспоримых преимуществ возрастет еще более, когда будут вскрыты недостатки PCR (на фоне недостатков PCR), который по самой своей природе является весьма времяемким инструментом. В больших проектах, выполняемых по контракту, количество изменений может доходить до тысяч (о чем говорит личный опыт автора). Даже при наличии хорошо спроектированной и надлежащим образом применяемой системы PCR это количество изменений требует значительной доли времени, отводимого на управление проектом, что существенно повышает издержки. И хотя эти издержки гарантированно окупаются, когда дело доходит до контроля содержания, стоимости и расписания, многие смогут насладиться вздохом облегчения от осознания того, что малые проекты обычно обходятся без слишком большого количества потребляющих время изменений.

Адаптация запроса на внесение изменения в проект.Различные типы проектов могут требовать различных подходов к PCR. Использовать общий формат PCR, подобный описанному здесь, значит искать па спою гол о ну проблем, которых можно избежать путем адаптации PCR под конкретные нужды проекта. Приведенные выше советы могут дать нам некоторые идеи относительно того, как можно выполнить такую адаптацию.

Убедитесь, что вы разработали надлежащий запрос на внесение изменения в проект. Данный запрос должен:

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

• описывать предлагаемое изменение, его причину и влияние на содержание/ качество;

• идентифицировать, когда запрос на внесение изменения требует чрезвычайного отношения;

• оценивать влияние предлагаемого изменения на расписание и стоимость проекта;

• идентифицировать тип изменения.

В настоящем разделе мы рассмотрели запрос на внесение изменения в проект – инструмент, который помогает выполнить всестороннее оценивание возможного изменения. Каждый проект должен использовать PCR для просеивания и рационального оценивания предлагаемых изменений. В этом случае процесс, структура и содержание PCR помогают принимать более качественные решения, держа содержание, стоимость и расписание проекта под контролем и в согласии друг с другом. Кроме того, к очевидным выходам (результатам) относятся также документирование изменений, меньшая путаница среди участников проекта, улучшенный контроль изменений содержания, меньшая общая стоимость и меньшие задержки. И наконец, в приводимом ниже заштрихованном прямоугольнике приведены ключевые соображения, которые следует принять во внимание при разработке запроса на внесение изменения в проект.