[an error occurred while processing the directive]
[an error occurred while processing the directive]

5.2 Управляй изменениями / Приемы

Облегчайте управление малыми запросами на изменения

(5.2.P1)

Определяя проект на Шаге 1, его руководитель и другие участники прилагают много усилий к тому, чтобы его график и бюджет отражали сбалансированное соотношение объема, стоимости и продолжительности предстоящих работ.

Никто не станет оспаривать, что любому серьезному изменению объема проекта должно предшествовать выполнение формального процесса управления изменениями. В то же время, пытаясь придерживаться такого процесса в отношении небольших изменений, Вы, скорее всего, столкнетесь с непониманием и сопротивлением. И клиент, и команда проекта будут рассматривать такое Ваше стремление как "перегибание палки" в пользу излишне обременительных процедур.

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

Очевидно, будет не совсем правильно ходить к спонсору за утверждением каждого запроса на малое изменение объема, как только такой запрос будет зарегистрирован. Обычно, у команды проекта нет возможности общаться со спонсором ежедневно, и может оказаться трудной задачей привлечь его внимание к незначительным изменениям. Можно существенно сэкономить время и свое, и спонсора, если объединить ряд мелких изменений в один пакет. Для этого необходимо, как и обычно, отслеживать запросы, оценивать их важность и воздействие на проект. Затем, когда их накопится достаточное количество, Вы представляете их спонсору на утверждение. Таким образом, Вы можете сократить число походов к спонсору с десяти до одного. На этой встрече Вы вместе с представителем клиента можете прокомментировать и обсудить предлагаемые изменения (или возможно, наиболее существенные из них) и получить по ним решение спонсора. То есть даже малые изменения у Вас остаются в рамках процесса управления, что позволяет, при необходимости, сопровождать их дополнительным финансированием и сроками. В противном случае, Ваш проект рискует пострадать от "расползания" объема.

С практической точки зрения, менеджеру проекта и менеджеру клиента может иметь смысл заручиться полномочиями по самостоятельному утверждению запросов на малые изменения, в совокупности, не превышающие установленный лимит стоимости и продолжительности. Такие полномочия должны быть явно и недвусмысленно делегированы спонсором. В случае, если проект в графике или слегка опережает сроки, в объем полномочий могут входить все запросы на изменения, не приводящие проект за пределы ранее установленных сроков. Если же проект имеет хоть малейший риск не выдержать обязательства по срокам и бюджету, такие полномочия использовать нельзя, даже если речь идет о запросе на 1 человеко-час дополнительных трудозатрат. В этом случае, все запросы на изменения должны проходить через спонсора, индивидуально или пакетом.

В некоторых организациях принято выделять часть общего бюджета проекта на реализацию малых изменений. Если Ваше руководство признает неизбежность некоторого расширения объема проекта, Вам могут позволить отнести определенный процент бюджета на соответствующий счет затрат, предназначенный для финансирования такого расширения. К примеру, Вы можете получить 5% бюджета на страхование малых изменений. При общей стоимости проекта в $500 000 это составит $25 000. Однако, смысл такого бюджета именно в том, что это именно все, что позволено потратить на малые изменения. То есть клиент ставится в условия, когда он сам вынужден управлять своими запросами на изменения таким образом, чтобы они уложились в бюджет страхования. Если страховой резерв будет израсходован в начале проекта, ничего не останется на его завершение, когда, обычно, появляется потребность в наиболее важных изменениях. Поэтому клиенту приходится устанавливать приоритеты своим пожеланиям и запрашивать только самые необходимые изменения. Данный бюджет используется только на запросы, стоимость или трудоемкость реализации которых не превышает заранее оговоренной пороговой величины. Все остальные изменения, как и прежде, должны проходить авторизацию спонсором в обычном порядке.

Не дайте истратить на изменения объема бюджет страхования оценок

(5.2.P5)

Одним из рекомендованных действий при оценивании проекта является добавление страхового резерва трудозатрат, который отражает уровень неопределенности, связанной с оценкой. Например, если трудоемкость оценена в 5 000 часов, Вы можете добавить 500 часов резерва, чтобы отразить 90% уверенности и 10% неопределенности. После того, как бюджет страхования оценок утвержден, менеджер проекта может испытывать давление (иногда даже сильное) со стороны клиента по использованию этого резерва на реализацию дополнительных требований. Типичное предложение: "Зачем нам тратить время на прохождение этих твоих процедур? Тут работы-то всего на 50 человеко-часов, а у тебя в резерве - целых 500!"

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

Замораживайте изменения объема вблизи завершения проекта

(5.2.P6)

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

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

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

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

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

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

(5.2.P7)

Типичной причиной проблем для многих проектов является не совсем четкое понимание его командой, какими полномочиями в области управления изменениями обладают спонсор, клиент и его представители, а также конечные пользователи результата поставки проекта.

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

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

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

Не оправдывайте согласие на изменение объема желанием угодить клиенту

(5.2.P8)

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

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

Включайте отложенную прибыль в стоимость изменений объема

(5.2.P9)

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

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

Рассмотрим следующий пример.

Предположим, Ваш проект стоит $100 000. Польза для бизнеса ожидается в виде увеличения прибыли (или снижения издержек) компании на $5 000 в месяц. В ходе проекта клиент вносит запрос на изменение, которое должно приносить дополнительно $1 000 прибыли ежемесячно. Реализация изменения оценивается в $5 000 стоимости и месяц продления сроков проекта.

Вы можете представить спонсору такой запрос на изменение, как стоящий $5 000 и окупающийся за пять месяцев. Но это будет некорректной оценкой, поскольку не будет учтена отложенная прибыль. Если учесть месячную задержку $5 000 дополнительной прибыли (или экономии), то общая стоимость изменения возрастет до $10 000. Если при первом варианте оценки спонсор, скорее всего, утвердит изменение (если срок поставки не столь уж критичен сам по себе), то при втором варианте - ему есть что взвесить и над чем поразмыслить. В любом случае, не учитывая стоимость отложенной прибыли, мы рискуем упустить очень важные обстоятельства.

Позвольте спонсору сказать "Нет"

(5.2.P10)

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

Поддерживайте обязательность в управлении изменениями объема

(5.2.P11)

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

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

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

Создавайте в больших и многопрофильных проектах Координационный совет по изменениям

(5.2.P12)

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

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

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

Ставьте в очередь отклоненные запросы на изменения

(5.2.P13)

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

[Пред. стр. - Общее упр. изменен-ми ]   [След. стр. - Управляй изменен-ми / Кратк. справка]