Последовательность шагов выполнения процедуры

Регистрация проблемы. При возникновении проблем с каким- либо проектным результатом персоналом проекта заполняется отчет по проблемам, который затем представляется на рассмотре­ние администратору проекта. Администратор проекта включает проблему со статусом «открыта» в журнал отчетов по проблемам и присваивает ей учетный номер. Администратор проекта переда­ет отчет по проблемам менеджеру проекта для обзора.

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

проблему. Менеджер проекта также устанавливает приоритет для проблемы и изменяет ее статус на «поручена».

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

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

1) рекомендует не предпринимать никаких действий. В этом слу­чае в отчет по проблемам заносится объяснение и менеджер про­екта должен подписать отчет со статусом проблемы «нет действий»;

2) утверждает рекомендуемое решение. Это утверждение должно быть отражено в отчете по проблемам, статус проблемы при этом меняется на «принята к решению». Менеджер проекта должен обсудить решение с заказчиком, даже если это решение не влияет на затраты, и для отчета по проблемам не требуется утверждения заказчика. В случае необходимости заказчик также подписывает отчет по проблемам.

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

 

Таблица 9.4

Уровни эскалации решения проблем

Уровень эскалации	Роли или организация	Критерии эскалации на данный уровень
	Руководитель группы	Необходимость изменения плана работ члена группы
	Менеджер проекта	Необходимость изменения плана работ группы
	Комитет по контролю за изменениями	Необходимость изменения плана работ в рамках договора
	Комитет по управлению	Необходимость изменения договора

 

Уточнение проблемы. Как только отчет по проблемам утверж­дается, начинается реализация решения. Отчет передается соответствующему члену команды проекта для проведения корректи­рующих действий. По завершении этих действий отчет тестиру­ется (или проверяется) членом команды или организацией, обозначенными в разделе «Организация, роли и ответственность* этого документа, после чего в отчете фиксируется завершение корректирующих действий. Затем отчет передается администра­тору проекта. Администратор проекта меняет статус проблемы в журнале отчетов по проблемам на «закрыта» и сохраняет отчет в виде файла в библиотеке проекта. На совещаниях по проекту жур­нал проверяется на предмет отслеживания еще не закрытых про­блем.

 

КОНТРОЛЬ ИЗМЕНЕНИЙ

 

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

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

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

Администратор проекта ведет учет запросов на изменение в соответствующих форме и журнале. Информация по этим вопро­сам предоставляется специально назначенным членам команды проекта. Форма «Запрос на изменение» возвращается админист­ратору проекта для сохранения в виде файла в библиотеке проек­та после того, как изменение утверждено или, наоборот, никаких действий не предпринималось, а в журнале запросов на изменение указывается окончательное состояние запроса. Информация о запросе на изменение представляется в следующем виде:

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

· текущее состояние (корректируется в случае необходимо­сти) — приоритет (критичный/высокий/средний/низкий), категория (специфическая для проекта классификация запро­сов на изменение), кому поручено, требуемая дата решения, статус (табл. 9.5);

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

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

· утверждение — «принято» (исполнителем) с указанием даты, «принято» (заказчиком) с указанием даты, кем проверено за­вершение, дата завершения.

 

Статус забросов

Таблица 9.5

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