Десять шагов

Пер. В.Куперштейн

Профессионал управления проектами

В статье, которую мы предлагаем Вашему вниманию, содержится перевод фрагмента документации Ten Steps, выполненный Владимиром Куперштейном.  

1. Процесс управления предметной областью проекта

1.а. Общий обзор

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

1.б. Малые проекты

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

  1. Запрос на изменение предметной области должен быть направлен кому-либо из членов команды проекта. Он должен быть представлен в письменной форме на бумаге, по электронной почте или любым другим способом. Никакие формальные требования к такому запросу не предъявляются.
  2. Руководитель проекта подтверждает, что запрос действительно относится к предметной области проекта. Если это так, то необходимо выполнить следующие шаги данной процедуры.
  3. Руководитель проекта определяет степень влияния запроса на предметную область в терминах стоимости, затрат и длительности. Если эти показатели приемлемы, руководитель проекта определяет такое влияние удовлетворительным.
  4. (При необходимости) Если показатели, определяющие влияние запроса на изменение, не приводят к изменению утверждённых ранее показателей проекта (стоимости, объёма работ и длительности), руководитель проекта и менеджер клиента имеют возможность принять запрос к исполнению или отклонить его. Несмотря на это, инвестор должен согласиться с ответственными за принятие этого решения - обычно в пределах порога затрат в стоимостном измерении или в единицах объёма работ.
  5. Соответствующий анализ, влияние и другие альтернативы учитываются инвестором проекта  для решения (если запрос не был принят в ходе выполнение шага 4 данной процедуры). Если инвестор не принимает запрос и его влияние на проект, запрос на изменение предметной области проекта отклоняется.
  6. Если запрос одобряется, необходимо добавить в план проекта соответствующие работы с тем, чтобы быть уверенным, что изменение действительно будет выполнено.
  7. Запрос, документы о его статусе и принятая резолюция должны быть документированы в «Отчёте о состоянии проекта».

1.в. Средние проекты

  1. Потенциально предложения об изменении предметной области проекта от любых участников проекта, включая членов команды проекта, клиентов, инвесторов и т.д. Запросы об изменении предметной области должны быть документированы и направлены руководителю проекта желательно в виде заполненной «Формы запроса» об изменении или по электронной почте.
  2. Каждый запрос должен сохраняться в «Базе изменений предметной области проекта» для обеспечения дальнейшего отслеживания.
  3. Делегируйте одному из членов команды проекта изучить предложенное изменение предметной области. (Руководитель проекта может сам взяться за такое изучение). Член команды проекта прежде всего должен определить, сколько времени необходимо для изучения запроса на изменение. Если время, запрошенное для выполнения анализа, может вызвать перенос важных дат проекта, такой запрос должен быть направлен инвестору для того, чтобы определить, стоит ли вообще рассматривать такой запрос. Если инвестор даст предварительное согласие на проработку запроса, то план работ и бюджет могут потребовать корректировки для того, чтобы учесть необходимые работы по анализу изменения. Если инвестор не даст согласия на проработку такого запроса, то такой запрос на изменение должен быть закрыт с резолюцией -отклонён- в базе изменений предметной области.
  4. (Желательно). Если влияние на стоимость проекта, объём трудозатрат и длительность работ ниже установленного порога (например, определённого равным 20 часам) и показатели проекта (сроки, стоимость, трудозатраты) при этом не изменяются, запрос на изменение предметной области проекта могут согласовать руководитель проекта и менеджер заказчика. Соответствующие пороговые значения показателей должны быть определены и согласованы заранее, чтобы не направлять инвестору для утверждения запросов на слишком мелкие изменения предметной области. Очевидно, что такое распределение ответственности должен согласовать инвестор - обычно до определённой пороговой величины стоимости или объёма затрат труда.
  5. Представьте запрос на изменение, альтернативы и оценку влияния на проект инвестору проекта для утверждения (если руководитель проекта и менеджер заказчика не одобрили запрос, как это было описано выше).
  6. Документируйте решение или принятый образ действий в «Базе изменений предметной области». Если инвестор не согласует запрос, то запрос должен быть закрыт как -отклонённый- в этой базе.
  7. Если запрос согласован, то в план должны быть внесены необходимые изменения, с тем чтобы обеспечить внедрение принятого изменения. Бюджет проекта при необходимости также должен быть изменён.
  8. Определение проекта должно быть откорректировано в первую очередь, если принятое изменение предметной области затрагивает существо проекта.
  9. Направьте сообщения о статусе запроса на изменение предметной области и принятом по нему решении членам команды проекта и другим заинтересованным участникам проекта в соответствии с «Планом коммуникаций», включая «Отчёт о состоянии проекта».

1.г. Большие проекты

  1. Запросы на потенциальные изменения предметной области возможно могут приниматься от любых участников проекта, включая членов команды проекта, заказчиков, инвесторов и т.д. Запросы на изменения могут быть сформулированы устно или в письменной форме, но они должны документироваться с использованием «Формы запроса на изменения».
  2. Введите запрос в «Базу изменений предметной области» для обеспечения его  дельнейшего отслеживания.
  3. Поручите проработать запрос на изменение члену команды проекта. (Руководитель проекта может взяться за эту работу сам). Член команды проекта должен оценить влияние изменения на бюджет и график выполнения проекта с учётом возможных вариантов.
    Член команды проекта должен сначала оценить, сколько времени необходимо ему для проработки запроса на изменение. Если необходимое для этого время может вызвать задержку проекта, запрос необходимо прежде всего направить инвестору проекта для того, чтобы определить, должен ли такой запрос прорабатываться вообще или нет. Если инвестор даст предварительное согласие на проработку запроса, то может оказаться необходимым внести соответствующие изменения в график проекта и его бюджет. Установленный статус запроса должен быть отражён в «Форме запроса на изменение». Если инвестор не согласен рассматривать запрос, то такой запрос должен быть помечен в «Базе запросов на изменение предметной области» как отклонённый.
  4. (Желательно). Если оценка влияния запроса на стоимость проекта, объём затрат труда и длительность работ окажутся ниже некоторого порогового значения (например, менее 20 часов) и при этом сохранится возможность завершения проекта в согласованные ранее сроки при согласованных затратах и объёме работ, руководитель проекта и менеджер заказчика могут утвердить такой запрос. Такие пороговые значения должны быть установлены и согласованы заранее с целью предотвратить обращение к инвестору для утверждения слишком мелких запросов. Очевидно, что при этом инвестор по существу должен делегировать соответствующую ответственность руководителю проекта - обычно вплоть до определённых значений стоимости и объёма работ.
  5. Представьте запрос на изменение, возможные альтернативы и оценку влияния на показатели проекта в виде «Формы запроса на изменение», инвестору для решения.
  6. Документируйте принятое решение и необходимые действия в «Формы запроса на изменение».
  7. Документируйте краткое содержание принятого решения в «Базе запросов на изменение предметной области». Если инвестор отклонит запрос на изменение, то в «Базе запросов на изменение предметной области» такой запрос должен быть закрыт как отклонённый.
  8. Если запрос будет одобрен, соответствующие альтернативы включаются в план проекта с тем, чтобы обеспечить реализацию одобренных действий. При необходимости должен быть откорректирован бюджет проекта.
  9. Если одобренный запрос изменяет содержание предметной области, то исходное определение проекта должно быть откорректировано.
  10. Распространите информацию о статусе изменения и принятом решении членам команды проекта и другим заинтересованным участникам проекта в соответствии с «Планом коммуникаций», включая «Отчёт о состоянии проекта».

1.1. Определение предметной области

1.1.а. Общий обзор

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

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

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

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

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

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

1.1.б. Уточнение целей и предметной области

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

2. Приемы и методы управления предметной областью

2.1. Управление запросами на незначительное изменение предметной области

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

  • Формирование пакетов запросов на малые изменения (2.2). Не всегда практично направлять все запросы на малые изменения инвестору. Команда проекта обычно не поддерживает с инвестором ежедневного контакта и даже поэтому сложно постоянно обращаться в инвестору с запросами на малые изменения. Лучше формировать пакеты таких запросов за определённые периоды времени. Это значит, что вы должны отслеживать запросы на малые изменения предметной области, их значение и влияние на проект.

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

  • Предоставление полномочий руководителю проекта (2.3). Это второй способ работы с запросами на малые изменения. С точки зрения практики, обычно руководитель проекта и менеджер заказчика должны рассмотреть запрос на незначительное изменение и принять по нему решение вплоть до определённого порога значений объёма работ и стоимости. Очевидно, что при этом предполагается, что проект идет по графику или даже опережает его, и что эти изменения не приведут к тому, что проект выйдет из утверждённых условий по стоимости, объёму работ и длительности.

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

  • Бюджет непредвиденных расходов на изменения предметной области (2.4). В некоторых организациях предусматривается бюджет непредвиденных расходов для учёта незначительных, но целесообразных изменений предметной области. Для этого обычно не требуются специальные обоснования. Ваша организация может определить, что некоторые незначительные изменения запрашиваются это норма, и они могут составить определённый процент общего бюджета проекта. Например, вы можете иметь 5% непредвиденных расходов, добавленных к бюджету для изменений предметной области. Если общий бюджет проекта составляет 500,000$, ваш бюджет на непредвиденные изменения предметной области будет составлять 25,000$. Очевидно, что вследствие этого бюджет будет учитывать запросы на незначительные изменения предметной области.

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

2.5. Не используйте затраты на непредвиденные расходы для изменений предметной области

Один из шагов процесса оценки заключается в том, чтобы предусмотреть затраты на непредвиденные обстоятельства с целью учесть уровень неопределённости оценки. (Например, если оценка объёма работ составляет 5000 часов, вы можете добавить 500 часов на непредвиденные расходы, что будет соответствовать доверительной вероятности 90%.) Как только затраты на непредвиденные расходы утверждены, на руководителя проекта будет оказываться давление  с тем, чтобы использовать эти затраты на учёт дополнительных требований. Заказчик может сказать: -Почему вы настаиваете на компенсации дополнительных затрат на изменение предметной области в 100 часов. К вашей оценке уже добавлено 500 часов!?.

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

2.6. Замораживание запросов на изменение предметной области

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

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

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

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

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

2.7. Только инвестор может одобрять изменения - не менеджеры пользователя и заказчика

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

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

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

2.8. Соглашаться ли с запросами на изменение предметной области, демонстрируя ориентацию на заказчика?

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

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

2.9. Включать ли упущенную прибыль в стоимость изменений предметной области

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

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

Вы можете представить инвестору запрос на изменение стоимостью 5,000$, которое обеспечивает дополнительные поступления 1,000$ в месяц. Очевидно, что часть финансовых потерь будет вызвана опозданием проекта на один месяц. В этом случае ввод в эксплуатацию продукта проекта с опозданием на один месяц приведёт к потере прибыли объёмом 5,000$ по сравнению с первоначальным планом и поэтому общая стоимость изменения составит 10,000$. Инвестор может не одобрить такое изменение. Очевидно, что учёт потерянной прибыли, вызванное задержкой проекта, следует рассматривать как часть влияния изменения предметной области, которое инвестор должен знать и понимать.

2.10. Инвестор обычно будет говорить «Нет»

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

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

Многие процессы управления предметной областью хорошо срабатывают на уровне руководителя проекта, но связаны с компромиссами на уровне членов команды проекта. Если руководитель проекта тщательно поддерживает правила управления предметной областью, заказчик может пытаться влиять прямо на членов команды проекта с тем, чтобы они поддержали предлагаемые им изменения. Например, когда согласованный отчёт представляется для обозрения, заказчик может запросить второй отчёт для большей понятности. Член команды проекта может согласиться на такую работу (демонстрируя ориентацию на заказчика). Результатом может быть то, что такая работа может потребовать значительных ресурсов или времени совершенно вне предметной области проекта, которые должны бы были быть потрачены на более приоритетные работы.

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

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

2.12. Комитет контроля изменений

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

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

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

2.13. Отложенные запросы

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

3. Продукт проекта

Размер проекта

Информационные потребности

Малые

Для малых проектов запросы на изменение предметной области и их статус должны быть идентифицированы в отчёте о состоянии проекта в шаге 6. Существенные изменения предметной области малых проектов весьма необычны и поэтому процедуры управления изменениями существенно проще. Поэтому Реестра Изменений Предметной области обычно создаётся в средних и больших проектах. Это может быть полезным, если вы вынуждены будете работать с многочисленными изменениями предметной области.

Средние

Реестр изменений предметной области

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

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

Атрибуты запроса:

  • Номер изменения предметной области: Можно использовать произвольную систему нумерации, например, 1, 2, 3?  
  • Описание запроса на изменение предметной области: Краткое описание запроса на изменение предметной области
  • Приоритет: Указание относительной важности / приоритете запроса. Это может быть, например, В / С / Н (Высокий / Средний / Низкий) или 1 / 2 / 3.
  • Дата поступления запроса: Дата, в которую поступил данный запрос.
  • Автор запроса: Указание о том, кто является автором запроса.
  • Поручено: Указание на то, кому поручен предварительный анализ запроса на изменение и его влияния на проект.
  • Дата принятия решения: Дата принятия решения по данному запросу.
  • Статус: Обычно указывается «Ожидает решения», «Задержан», «Находится в работе», «Завершен», «Не одобрен»
  • Решение / Комментарий: Краткое описание принятого решения.

Найдите реестр изменений предметной области в библиотеке шаблонов

Большие

(1) Реестр Изменений Предметной области (так же, как и для средних проектов)

(2) Форма запроса на изменение предметной области

Большие проекты нуждаются в более строгом управлении предметной областью. Это включает и большую формализацию проработки потенциальных изменений. Для идентификации, проработки и изучения запросов на изменения используется Форма Запроса на Изменение Предметной Области. Каждый экземпляр формы должен быть использован для одного конкретного изменения предметной области. Следует убедиться, что запрос на изменение предметной области содержит достаточно информации для того, чтобы он мог бы быть идентифицирован и проанализирован, но не превращая всё-таки форму в пространный отчёт.

Номер изменения предметной области - используется для идентификации запроса. Обычно не требуется большая формализация, чем последовательные номера: 1, 2, 3. Вероятно, что некоторые простые и логичные системы кодирования могут позволить легко определять категорию запроса. Какая система не применялась бы, она должна применяться в Реестре Запросов на Изменения предметно области последовательно.

Атрибуты запроса:

  • Автор запроса: Кто является автором запроса?
  • Дата поступления запроса: Когда поступил запрос?
  • Состояние: Обычно это «Ожидает решения», «Задержан»,  «Обрабатывается». «Закончен», «Отклонён».
  • Поручен