Лекция 11. Процедуры контроля

ЛЕКЦИЯ 11. ПРОЦЕДУРЫ КОНТРОЛЯ

 

УПРАВЛЕНИЕ РИСКАМИ

И СПОРНЫМИ ВОПРОСАМИ

 

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

По ходу проекта могут возникать проблемы, с которыми ко­манда проекта может не справиться. Процедура, описанная ниже, должна использоваться для решения подобных проблем и обеспе­чения условий для продолжения процесса разработки. Управление I рисками и спорными вопросами ведется с использованием формы «Риски и спорные вопросы» и отслеживается в соответствующем журнале. Эти документы обсуждаются на совещаниях по проекту. Менеджер проекта назначает ответственного за выполнение процедурных требований. Организация процедуры обеспечивается менеджером проекта.

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

Информация о рисках и спорных вопросах представ­ляется в следующем виде:

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

· текущее состояние (корректируется в случае необходимости) — кому поручено, приоритет (критичный/высокий/средний/низ- кий), статус (табл. 9.1);

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

Таблица 9.1

Таблица 9.2

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

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

 

 

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

 

УПРАВЛЕНИЕ ПРОБЛЕМАМИ

 

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

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

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

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

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

 

Таблица 9.3

Статус проблем

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

 

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

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

 

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

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

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

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

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

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

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

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

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

 

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

Таблица 9.5

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

Таблица 9.6

МОНИТОРИНГ И ОТЧЕТНОСТЬ

СОСТОЯНИЯ ПРОЕКТА

 

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

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

Обзоры состояния работы команды проекта проводятся ежене­дельно с целью ее оценки и планирования работ на следующую неделю (недели). В обзор включается также обсуждение каких- либо спорных вопросов и проблем. Рабочие планы корректиру­ются еженедельно в процессе подготовки к обзору на основе от­четов о работе персонала. Совещания проводятся под председа­тельством менеджера проекта со стороны исполнителя.

Обзоры состояния проекта проводятся ежемесячно. Менеджер проекта со стороны исполнителя предоставляет обеим сторонам отчет, в ко­тором излагаются состояние проекта, проблемы, риски, спорные вопросы и какие-либо предлагаемые изменения.

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

Отслеживание информации по мониторингу

КОНТРОЛЬ РАБОЧЕГО ПЛАНА

 

Процедура контроля рабочего плана определяет требования для поддержки рабочего плана и формирования бюллетеня о состоя­нии работ. К целям данной процедуры можно отнести: 1) сопро­вождение рабочего плана; 2) ввод текущей (актуальной) инфор­мации; 3) ввод данных об оценке завершения задач; 4) подготовку отчетности о состоянии проекта. Эта процедура, прежде всего, находится в компетенции координатора проекта, но также имеет отношение к менеджеру проекта, руководителям групп и членам команды проекта, ответственным за планирование и текущий кон­троль состояния проекта. Организация процедуры обеспечивает­ся менеджером проекта.

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

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

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

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

КОНТРОЛЬ ФИНАНСОВОГО ПЛАНА

 

Процедура контроля финансового плана определяет требова­ния для поддержки финансового плана и планов финансового контроля с целью формирования бюллетеня о финансовом со- ¹ стоянии. К целям данной процедуры можно отнести: 1) сопро­вождение финансового плана; 2) ввод фактических данных (тру­довые затраты и расходы); 3) ввод данных о финансовой оценке завершения задач; 4) подготовка бюллетеня о финансовом со­стоянии. Эта процедура находится, прежде всего, в компетенции координатора проекта, но также имеет отношение к менеджеру проекта, руководителям групп и членам команды, ответственным за планирование и текущий контроль финансового состояния проекта. Организация процедуры обеспечивается менеджером проекта.

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

рабочего времени и оценка предстоящих затрат. Эта оценка пред­ставляется в человеко-днях (обзор по месяцам) либо в человеко­часах (обзор по неделям).

ОБЗОР КАЧЕСТВА

 

Цель данной процедуры — выявить как можно больше ошибок во всех результатах проекта. В рамках этой процедуры проводится

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

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

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

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

Организацией процедуры обзора результатов проекта занима­ется менеджер по качеству. Организацией процедуры обзора ре­зультатов работы групп занимаются руководители групп. Для пла­нирования и проведения обзора качества используются показате­ли рабочего плана. Возможный статус обзора качества представлен в табл. 9.7.

 

Таблица 9.7

АУДИТ КАЧЕСТВА РАБОТ

 

Цель процедуры «аудит качества работ» — установить, осущест­вляются ли процессы проекта в соответствии с заданными плана­ми и процедурами. Аудит качества управления проектом осуще­ствляется менеджером по качеству. Для планирования и проведе­ния аудита и мониторинга качества управления проектом используются показатели плана качества работ по проекту. Возможный статус аудита качества представлен в табл. 9.8.

ОЦЕНКА ПОКАЗАТЕЛЕЙ КАЧЕСТВА

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

По ходу проекта производится сбор следующей информации:

1) процент затрат на составление обзоров;

2) процент затрат на доработку проекта;

3) эффективность обзоров;

4) процент зафик­сированных ошибок при сборе данных;

5) разница между пла­нируемыми и фактическими показателями (материальные и фи­нансовые затраты и время).

Доработка проекта проводится из-за неточных данных, принятия неверных решений, системных оши­бок (нет резервной копии), ошибочных процедур, проблем с ре­ализацией, а также в связи с изменениями в процедурах. Возможный статус обзора показателей качества представлен в табл. 9.9.

Таблица 9.9

КОНТРОЛЬ ДОКУМЕНТОВ

 

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

КОНТРОЛЬ КОНФИГУРАЦИИ

 

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

УПРАВЛЕНИЕ РЕЛИЗАМИ

 

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

ПОДПИСАНИЕ АКТА ПРИЕМКИ

Для выполнения процедуры необходимо решить следующие задачи:

I) оценить выполнение обязательств;

2) подготовить отчет об окончании проекта;

3) подписать акт приемки выполненных работ.

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

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

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

 

ОЦЕНКА РАБОТЫ ПЕРСОНАЛА

Для выполнения процедуры необходимо решить следующие задачи:

I) извещение менеджмента проекта, заказчика и персона­ла;

2) подготовка окончательных оценок работы персонала;

3) воз­вращение материальных ресурсов.

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

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

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

 

ОЦЕНКА КАЧЕСТВА РАБОТ

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

I) оценить завершенность мероприятий по каче­ству работ;

2) зафиксировать выявленные замечания в отчете по качеству.

Оценка завершенности мероприятий по качеству работ. На осно­вании собранных материалов необходимо провести следующие виды оценки: завершенности всех обзоров по результатам, завер­шенности всех мероприятий по проведению аудита и «закрытости» отчетов по проблемам.

ЛЕКЦИЯ 11. ПРОЦЕДУРЫ КОНТРОЛЯ

 

УПРАВЛЕНИЕ РИСКАМИ

И СПОРНЫМИ ВОПРОСАМИ

 

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

По ходу проекта могут возникать проблемы, с которыми ко­манда проекта может не справиться. Процедура, описанная ниже, должна использоваться для решения подобных проблем и обеспе­чения условий для продолжения процесса разработки. Управление I рисками и спорными вопросами ведется с использованием формы «Риски и спорные вопросы» и отслеживается в соответствующем журнале. Эти документы обсуждаются на совещаниях по проекту. Менеджер проекта назначает ответственного за выполнение процедурных требований. Организация процедуры обеспечивается менеджером проекта.

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

Информация о рисках и спорных вопросах представ­ляется в следующем виде:

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

· текущее состояние (корректируется в случае необходимости) — кому поручено, приоритет (критичный/высокий/средний/низ- кий), статус (табл. 9.1);

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

Таблица 9.1