Заглавная страница
Избранные статьи
Случайная статья
Познавательные статьи
Новые добавления
Обратная связь

ТОП 10 на сайте

Приготовление дезинфицирующих растворов различной концентрации

Техника нижней прямой подачи мяча.

Франко-прусская война (причины и последствия)

Организация работы процедурного кабинета

Смысловое и механическое запоминание, их место и роль в усвоении знаний

Коммуникативные барьеры и пути их преодоления

Обработка изделий медицинского назначения многократного применения

Образцы текста публицистического стиля

Четыре типа изменения баланса

Задачи с ответами для Всероссийской олимпиады по праву

Мы поможем в написании ваших работ!

ЗНАЕТЕ ЛИ ВЫ?

Влияние общества на человека

Приготовление дезинфицирующих растворов различной концентрации

Практические работы по географии для 6 класса

Организация работы процедурного кабинета

Изменения в неживой природе осенью

Уборка процедурного кабинета

Сольфеджио. Все правила по сольфеджио

Балочные системы. Определение реакций опор и моментов защемления

Главная Избранные Случайная статья Познавательные Новые добавления Обратная связь FAQ

Определение уровней вероятности возникновения рисков и их последствий

Основные понятия управления рисками

Риск проекта - это кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта [23]. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и следовательно, невозможно спланировать действия по реагированию на такой риск.

Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту [23].

Вероятность возникновения риска - вероятность того, что событие риска наступит [23]. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.

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

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

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

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

Планирование реагирования на риски включает разработку плана управления рисками - документа, разрабатываемого в начале проекта и представляющего собой график работы с рисками в течение всего ЖЦ проекта. План содержит следующую информацию [18].

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

Роли и обязанности - раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта.

Бюджетирование - определяет бюджет для управления рисками проекта.

Временные рамки - устанавливают частоту процессов управления рисками.

Инструменты - раздел определяет, какие методы количественного и качественного анализа рисков рекомендуется применять и в каких случаях.

Контроль - раздел, определяющий формат плана реагирования на риски.

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

Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework) [11]. MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта.

Методы управления проектными рисками для малых и средних проектов достаточно проработаны и позволяют эффективно снижать уровень рисков и трудозатраты по проекту (см. табл. 5.1) Для ведения крупных проектов "стандартного" набора методов оказывается недостаточно [15].

Таблица 5.1. Примеры управления рисками
Масштаб проекта	Число работ	Число подпроектов	Связность работ	Методы управления
Малый	too	Нет	Низкая	PMI ¹ FMEA MSF, личный опыт руководителя
Средний	50-100	Единицы	Низкая, средняя	Стандартные методики (ASAP ² PJM ³ PMI), SPICE⁴ COBIT
Крупный	100-1000	От нескольких десятков до нескольких сотен	Высокая	Проработаны слабо

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

На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:

· утвердить систематический подход к определению рисков, их оценке и обработке.

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

· идентифицировать риски.

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

Интервал вероятностей

Значение вероятности, используемое для вычислений

Словесная формулировка

Числовая оценка

От 1% до 14%

крайне маловероятно

От 15% до 28%

21%

низкая вероятность

От 29% до 42%

35%

скорее нет

От 43% до 57%

50%

50-50

От 58% до 72%

65%

возможно

От 73% до 86%

79%

весьма правдоподобно

От 87% до 99%

93%

почти наверняка

Таблица 5.3. Шкала для оценки последствий риска, измеряемых в деньгах

Оценка

Денежное выражение

до $100

$100-$1000

$1000-$10,000

$10,000-$100,000

$100,000-$1,000,000

$1,000,000-$10 миллионов

$10 миллионов-$100 миллионов

$100 миллионов-$1 миллиард

$1 миллиард-$10 миллиардов

свыше $10 миллиардов

Когда денежные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки последствий риска (см. табл. 5.4). Система оценки воздействий должна отражать политику и ценности организации и проектной группы.

Таблица 5.4. Шкала для оценки последствий риска, измеряемых отклонениями в стоимости, сроках и технических условиях проекта

Оценка

Перерасход средств

Календарный график

Технические условия

1 (низкая)

до 1%

сдвиг на 1 неделю

небольшая потеря производительности

2 (средняя)

до 5%

сдвиг на 2 недели

умеренное снижение производительности

3 (высокая)

до 10%

сдвиг на 1 месяц

серьезный ущерб для производительности

4 (критическая)

от 10%

сдвиг более 1 мес.

задача не может быть выполнена

Таблица 5.5. Определение шкалы оценки воздействия для четырех целей проекта

Определенные условия для шкалы оценки степени возможного влияния риска (показаны только примеры негативных воздействий)

Цель проекта

Очень низкое

Низкое

Умеренное

Высокое

Очень высокое

0,05

0,10

0,20

0,40

0,80

Стоимость

Незначительное увеличение

Увеличение < 5%

Увеличение 5-10%

Увеличение 10-20%

Увеличение > 20%

Сроки

Незначительное увеличение

Увеличение < 5%

Увеличение 5-10%

Увеличение 10-20%

Увеличение > 20%

Содержание (объем)

Изменения незаметны

Незначительные изменения

Значительные изменения

Неприемлемое для клиента изменение

Достижение конечных результатов невозможно

Качество

Изменения незаметны

Незначительные изменения

Изменения требуют согласия клиента

Неприемлемое для клиента изменение

Достижение конечных результатов невозможно

Рис. 5.1. Матрица воздействия (вероятностей и последствий) рисков

Относительная шкала последствий разрабатывается каждой организацией самостоятельно. Шкала содержит только описательные обозначения, например, "очень низкий", "низкий", "средний", "высокий" и "очень высокий", расположенные в порядке возрастания максимальной силы воздействия риска согласно определению данной организации. То же самое можно сделать иначе, путем присвоения данным последствиям цифровых значений, которые могут быть линейными и нелинейными, например, 0,1 - 0,3 -0,5 - 0,7 - 0,9 или 0,05 - 0,1- 0,2 - 0,4 - 0,8. В табл. 5.5 представлены как относительный, так и цифровой (в данном случае нелинейный) способы обозначения последствий риска для четырех целей проекта [23].

Шкала уровней воздействия является основой для построения матрицы вероятности и последствий.

Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий, средний или высший [23]. Матрица может содержать описательные термины или цифровые обозначения (см. рис. 5.1) и строится на основании шкал оценки вероятности и оценки степени влияния возможного риска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняются результатами перемножения значений этих шкал. Сопоставляя значение ячейки матрицы со шкалой оценки воздействия, риски можно разделить по категориям: малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рис. 5.1. Риски, имеющие очень высокую вероятность, но незначительные последствия, а также риски, имеющие низкую вероятность и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета), имеют среднее воздействие на проект. Риски, которым необходимо уделять особое внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом).

ИДЕНТИФИКАЦИЯ РИСКА

№

Дата возникновения риска

Дата регистрации риска Наименование и описание риска

Инициатор

Причины Последствия Владелец риска Дата окончания действия риска . .

Таблица 5.8. Пример заполнения реестра рисков (упрощенный)

Первопричина

Условие

Последствие

Необеспеченность кадрами

Могут быть объединены проектные роли. Несовместимые роли: менеджер по качеству и разработчик,тестировщик и разработчик

Совмещение ролей может затруднить контроль и оценку результатов, что снизит качество программного продукта

Изменения в технологии

Разработчикам придется осваивать новые технологии и использовать их впервые

Увеличится время на разработку программного продукта. Возможно снижение качества________

Организация работы

Участники проекта территориально удалены

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

Таблица 5.9. Пример заполнения расширенного журнала рисков
Тип риска	Описание риска	Проактивные мероприятия	Реактивные мероприятия	Вероятность	Последствия	Фактор риска
Технологический	Заказчик может задержать выпуск продукта из-за постоянных изменений и дополнений требований к продукту	1. Разделить требования на "абсолютно необходимые" и "хорошо бы было иметь", до запуска системы выполнять только абсолютно необходимые требования 2. Убедиться в том, что руководство заказчика понимает и поддерживает подход, что заявки на изменения будут выполняться после завершения основных работ везде, где это возможно	1. Обсудить изменение сроков ввода системы в эксплуатацию из-за накопившегося объема изменений для обеспечения необходимого уровня качества финального продукта	8	6	48
Финансовый	Заказчик настаивает на бесплатном исправлении всех ошибок (в данном случае речь идет только о тех пунктах, которые мы также можем признать ошибками), что может привести к серьезным финансовым потерям	1. Включить в план работ бюджет и время программистов на исправление ошибок по результатам тестирования. 2. Разъяснять ключевым представителям заказчика, что выявление и исправление ошибок является частью технологии разработки ПО	1. В случае невозможности достижения договоренности поднять вопрос на уровень управляющего комитета	8	6	48

План реагирования на риски

Название проекта:

Дата оценивания:

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

На рассматриваемой стадии ЖЦ ИТ наиболее вероятно возникновение рисков, вызванных следующими обстоятельствами [22]:

1. неправильно определена область применения проекта;

2. не определен спонсор проекта;

3. не разработана стратегия реагирования на риски;

4. не определены ожидания участников проекта;

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

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

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

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

Управление конфигурацией ИС и процессами проекта позволяет координировать управление перечисленными видами деятельности, исходя из тех изменений, которые постоянно возникают в ходе реализации проекта.

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

Пример процедуры управления рисками

Настоящая процедура применятся для управления рисками на проекте внедрения ИС. По согласованию сторон процедура может изменяться. Управление рисками выполняется на протяжении всего проекта с использованием журнала регистрации (реестра) рисков.

Запись риска

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

· Одновременно оформляется форма регистрации риска; необходимо дать ссылку на файл формы регистрации рисков в проектной библиотеке.

· Журнал рисков размещается в проектной библиотеке секретарем проекта и обновляется/дополняется ежедневно в конце дня.

· Формы регистрации рисков размещаются в проектной библиотеке и обновляются/дополняются ежедневно в конце дня.

· Управление/минимизация рисков

· Возможные варианты управления/минимизации риска обсуждаются на ежедневных оперативных совещаниях и на еженедельных совещаниях группы управления проектом и документируются в форме регистрации рисков

Таблица 5.11. Пример формы регистрации риска
Запрос на регистрацию риска Номер в журнале рисков:< Заполняется в ГУПР>
< Заполняется автором запроса> ФИО автора:<Петров Петр Петрович> Роль:<Руководитель группы финансы> Проект: <ВМС 2> Фаза проекта:<Планирование>						<Заполняется автором запроса> Приоритет:<Критично, высокий, средний, низкий ()> Дата запроса:<дд.мм.гпт> Желаемая дата разрешения*:<дц.мм.птг>
Описание риска:<Заполняется автором запроса> <Детальное описание риска, контрольная точка (дата) наступления рискового события> < Описание уже предпринятых действий для минимизации риска > Дата окончания действия риска:<дд.мм.птт> () Предпосылки: < Описание причин возникновения риска> Последствия:<Описание возможных последствий в случае наступления рисковых событий и их влияния на проект> Варианты решения**: < Описание предложений по вариантам решения> < Какие действия от проектного офиса ожидаются для минимизации риска>
<Заполняется в ГУП>
Статус (***):

Дата

Комментарий к статусу:

<статус>

<дц.мм.гггг>

<комментарии к статусу>

<статус>

<дд.мм.гггг>

<комментарии к статусу>

<статус>

<дд.мм.гпт>

<комментарии к статусу>

<статус>

<дд.мм.гпт>

<комментарии к статусу>

Результаты анализа риска (****): <Заполняется в ГУПР>

Вероятность

Влияние

Степень угрозы

Стратегия работы

100%

Сильное

Критическая

Избежать 75% <Х>

Среднее

<Х>

Высокая

<Х>

Принять 50%

Слабое

Средняя

Снижать <Х> 25%

Низкая

< Обоснование выбора стратегии (обязательно заполняется в случае выбора стратегии принятия риска) >

<Описание предложений по вариантам решения и действиям для совещания>

< Предложение по назначению владельца риска>

Ответственный за риск: <ФИО сотрудника>

Утвержденный вариант решения по минимизации риска:< Заполняется в ГУП><Заполняется в ГУЛ на основании протокола совещания>

Назначенные действия

Ответственный

Срок

Источник действия

Статус

< Описание назначенного действия>

<Сидоров СО

<дд.мм.гггг>

< Совещание от...>

<(*****)>

· Принятое решение документируется в форме регистрации рисков.

· Влияние на график работ оценивается для каждого решения.

· Если необходимо, заполняются формы - запросы на изменение.

Информация фиксируется в форме регистрации риска (см. табл. 5.11), состоящей из:

1. верхнего колонтитула с указанием:

o имени автора, объявившего риск;

o функциональной области и этапа проекта, к которому относится риск;

o даты записи;

o порядкового номера записи;

o полного описание риска;

2. формулировки текущего состояния (изменяется по мере необходимости):

o назначенный ответственный за разрешение риска;

o приоритет: "критично", "высокий", "средний", "низкий";

3. изучения/минимизации риска:

o возможные пути решения: возможные пути минимизации риска, включая влияние на проект в терминах нарушения хода проекта, времени, качества;

o оценка влияния: оценка влияния на бизнес/технические аспекты проекта;

4. решения:

o рекомендация: окончательное решение для утверждения;

5. утверждения:

o утверждено исполнителем, дата;

o утверждено заказчиком, дата;

o соответствующий номер запроса на изменение (если присутствует запрос на изменение);

o запрос на изменение утвержден, дата.

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

Лекция 7. Планирование человеческих ресурсов проекта

Планирование человеческих ресурсов - процесс определения и документального оформления ролей, ответственности и подотчетности, а также создание плана управления обеспечением проекта персоналом [16].

Определение ролей проекта

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

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

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

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

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

Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.

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

Ключевые роли со стороны исполнителя - руководитель проекта (менеджер проекта) со стороны исполнителя и бизнес- менеджер.

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

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

В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].

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

Состав команды управления должен быть достаточным, чтобы осуществлять [11]:

· управление ресурсами проекта, в том числе:

o определение требуемых для достижения целей проекта ресурсов;

o подготовка предложений по изменению состава группы управления проектом;

o утверждение персональных изменений в составе рабочих групп проекта;

o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов;

· управление сроками выполнения проекта, в том числе:

o подготовка плана работ проекта;

o контроль над выполнением проекта;

o подготовка отчетов о ходе работ проекта;

· управление качеством проекта, в том числе:

o контроль соответствия разрабатываемых проектных решений техническому заданию;

o организация экспертизы проектных решений;

· управление рисками проекта, в том числе:

o анализ рисков проекта;

o разработка планов мероприятий по снижению рисков;

o реализация мероприятий по снижению рисков;

· управление проблемами проекта, в том числе:

o анализ проблем проекта;

o разработка мероприятий по разрешению проблем проекта;

o реализация мероприятий по разрешению проблем проекта;

· контроль над организацией работ в проектных группах, в том числе:

o согласование отчетов о ходе работ;

o контроль над функционированием системы сбора и распределения информации;

o контроль документирования проектных результатов.

В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролей исполнителей, характерных для IT-проектов: функциональный архитектор, функциональный консультант, разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик. В проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается в небольших проектах, что позволяет снизить накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика.

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

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

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

увеличить изображение
Рис. 6.1. Пример организационной структуры проекта

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

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

Расшифровка

Описание

Исп. (R)

Исполнитель (Responsible)

Несет ответственность за непосредственное исполнение задачи. К каждой задаче должно быть приписано не менее одного исполнителя

Утв. (A)

Утверждающий (Accountable)

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

Cогл. (C)

Согласующий (Consulted)

Согласует принимаемые решения, взаимодействие с ним носит двусторонний характер

Н. (I)

Наблюдатель (Informed)

Его информируют об уже принятом решении, взаимодействие с ним носит односторонний характер

Таблица 6.2. Распределение функциональных обязанностей команды управления проектом

Функциональные обязанности