Основы проектной деятельности Лекция 3
Планируем ответственность, коммуникации, качество
Входы:
- Концепция проекта
- ИСР (WBS) и ресурсы, распределенные по работам
- Команда проекта
Каждый элемент создаваемого нами плана должен быть понятным и реально использоваться заинтересованными лицами. Сейчас, когда все грани треугольника уточнены, стоит уделить особое внимание достаточности коммуникаций и распределению ответственности на проекте.
Распределяем ответственность
На прошлой лекции мы говорили о том, как распределяются ресурсы по работам (шаг 4). Одновременно с таким «назначением» распределяется и ответственность за выполнение конкретного пакета или действия.
Если вы действительно привлекали команду к формированию ИСР (WBS) и прочим элементам планирования - то каждый сотрудник уже «в курсе», за какие работы ему придется взяться и в какие сроки уложиться. Не думайте, что ПМ на этом можно остановиться!
Представьте, что произойдет, если вы дадите страт выполнению работ прямо сейчас? Действительно ли каждый член команды понимает, за какую работу браться первой? А что делать, когда он ее закончит? А если одна работа должна выполняться после другой- как понять, что соответствующий этап выполнен и можно приступать?
Каждый член команды должен знать свои приоритеты и понимать, где их можно посмотреть, а также откуда почерпнуть уточняющую информацию (помните - ИСР, ИСР-словарь, результаты обследования?). На вашем проекте могут действовать различные правила: «сделал работу - позови - покажи - берись за следующую», или «сделал первое по списку - отпишись - берись за второе».
Возможно, «младшие» члены команды будут уточнять постановку у более опытных.
Признак правильно организованных работ - если вы, приступив к выполнению работ по проекту - никогда не услышите от члена команды «я закончил, что дальше?» (или того хуже - не обнаружите его за неоправданным бездействием «а разве есть еще работа?»). Постарайтесь организовать работу так, что без вашего личного участия команда могла действовать во благо проекта.
Помните, раздавать поручения в фазе исполнения проекта - не работа ПМ!
Я еще за что-то отвечаю?
Помимо самих работ - обратите внимание на распределение ответственностей за то, что не находит отражения в ИСР (WBS).
Вы помните, что ИСР (WBS) - это работы по созданию продукта? Он может не включать отдельных работ по контролю качества, по выявлению и отслеживанию рисков и т.д. Найдите способ договориться с командой о распределении ответственностей такого рода.
Фиксируйте договоренности. Сделайте это для каждой области знаний или для каждой роли вашей команды.
Можно закрепить обязательства по областям знаний. Например, описав «главного» и «вспомогательного» ответственных за какую-то задачу. Для этого удобно использовать простейшие таблицы, которые иногда называют «матрицами ответственности».
Матрица ответственности может выглядеть, следующим образом:
Г - главный ответственный, В - вспомогательный ответственный
Другой способ - закрепить обязательства за определенными категориями сотрудников (скажем, любой программист при разработке кода осуществляет самоконтроль качества, выполняя тестирование по определенным принципам). Для таких целей лучше подходят свободные текстовые описания.
Постарайтесь не оставить «белых пятен». Все аспекты проекта должны иметь своего исполнителя, если это не вы - позаботьтесь, чтобы он был назначен.
Планируем коммуникации
Распределяя ответственность - самое время договориться о коммуникациях.
Этот, во многом интуитивно-понятный аспект управления проектом, по некоторым данным, отнимает у ПМ до 90% его рабочего времени. Правильно спланированные коммуникации помогут вам серьезно снизить собственные трудозатраты.
Очень существенным является выбор метода. Будет ли общение на ту или иную тему вестись устно или письменно? В последнем случае - требуются ли согласовательные подписи (и чьи) или можно ограничиться сообщением по электронной почте? Важен ли формат такого письма?
Руководствуйтесь здравым смыслом.
Наиболее существенные аспекты коммуникаций, которые всегда стоит оговаривать в любом проекте это:
- Отчеты команды о выполненных работах
- Методы коммуникаций с представителями заказчика и пользователями
- Коммуникации со спонсором
Отчеты команды о выполненных работах
Отчеты должны быть организованы наиболее удобным для обеих сторон способом. Их необходимо адаптировать к конкретным используемым на проектах методологиям (так, при разработке ПО, согласно методологии, «водопад» отчеты о выполнении работ будут драматически отличаться от таковых, если применяются «гибкие» (Agile) методики).
Однако, есть несколько общих правил, которых стоит придерживаться на любом проекте:
Во-первых, плохой практикой является обсуждение статуса работ на совещаниях. Не делайте так (если только это не продиктовано методологией разработки или особой производственной необходимостью). Вам и команде и так есть, чем заняться. Просите прислать вам информацию в электронном виде. Пусть каждый создаст отчет тогда, когда ему это будет удобно, и читайте их - когда это удобно вам.
Во-вторых, не заставляйте людей без нужды много писать. Отчет о результатах должен разумно соотноситься по трудоемкости с самим результатом. Учтите также, что, подавляющее большинство технических специалистов не любят писать и сочинять документы. Для них вы можете использовать это как «наказание» («кто забыл прислать отчет - в следующий раз пишет эссе на пол страницы за всю команду»); однако не демотивируйте таких людей с самого начала. Если вам нужна цифра (сколько тебе осталось по задачке в часах?) - просите цифру и все. Если нужны комментарии - позвоните, или оставьте их на усмотрение разработчика. Помните, не все одинаково относятся к созданию даже коротких текстов.
Методы коммуникаций с заказчиком
Правила таких коммуникаций важны не только для «фиксации договоренностей», но и для соблюдения субординации.
Аналитику понадобилось съездить на объект и еще раз переговорить с пользователем - можно ли ехать сразу? Или позвонить пользователю и уточнить удобное время? Или обязательно каждый раз договариваться с его начальником?
А что, если возникли вопросы к самому заказчику (скажем, директору крупного завода)? Удобно ли ему позвонить на мобильник? Или через секретаря? Или послать вопрос почтой? Или по всем вопросам за заказчика решения принимает его заместитель, и директора лучше вовсе не беспокоить?
Нарушение гласных и негласных правил предприятия - в долгосрочной перспективе ни к чему хорошему вас не приведет. Определите «правила игры» на поле заказчика и доведите их до всей команды. Это существенно снизит количество и уровень потенциальных конфликтов.
Коммуникации со спонсором
Главное, что интересует спонсора в ходе выполнения проекта - укладывается ли тот в треугольник сейчас и сохранится ли это по окончании проекта? Как правило, нюансы хода работ спонсора не очень волнуют (для этого он нанял вас).
Оговорите со спонсором до фазы исполнения - как именно вы будете держать его в курсе. Обычно, одним из самых удобных инструментов для этого является «график вех» (о нем мы упоминали в главе VIII во время шага 6 «создание расписания»).
Что означает термин «качество»?
Планируем качество
Говорить об управлении качеством в отрыве от проекта или организации - очень тяжело. Само понятие качества ИТ-продуктов тесно сплетено с технологиями, используемыми для их создания. Мы ограничимся лишь описанием важнейших терминов и практик.
Качество - это некий уровень выполнения работ, при котором создаваемый продукт удовлетворяет предъявленным требованиям.
Обратите внимание - качество не является синонимом «очень хорошего продукта» или «продукта без единого дефекта». Качество - это когда продукт настолько хорош, насколько этого просил заказчик. Перфекционизм является типичной проектной ошибкой.
«Золотая сервировка» (gold platting) - добавление в продукт возможностей и функциональности, которые хоть и приятны заказчику, но не были им запрошены и не являются необходимыми для закрытия работ. Такое увлечение команды ненужными улучшениями очень характерно для ИТ- проектов.
«Золотая сервировка» является злом, причем в сфере ИТ, часто - трудноискоренимым. Разработчикам, аналитикам и прочим членам команды свойственно увлекаться своими делами, или (того хуже) переключаться с «трудных задач» на «интересные».
Предотвращение «золотой сервировки» - задача ПМ. Основные причины - она съедает драгоценные ресурсы проекта (время, деньги). Даже если в результате этого, выполнение проекта не пострадает - ресурсы вовсе не бесплатны для самой организации.
Планирование данной сферы предполагает ответы на главные вопросы: «что есть качество на нашем проекте?» и «как мы будем его достигать?».
На первый вопрос помогут ответить документированные требования (концепция проекта + ИСР + Словарь ИСР) и компетентные мнения нашей команды.
Документированные требования позволяют нам понять ожидание заказчика и пользователей, а командные усилия - найти способ их достижения. Как построить работы, чтобы действительно выдать заказчику систему, функционирующую в режиме 24*7*365, как он и просил? Как реализовать информационный обмен и устранение коллизий между распределенными системами, в объеме доступных нам спецификаций? На подобные вопросы ищут ответы эксперты вашей команды (возможно, при помощи «хозяев ресурсов»).
«Хозяева ресурсов» могут очень сильно помочь вам в планировании качества. В большинстве организаций именно они отвечают за развитие навыков своих подчиненных, наставничество и кураторство.
Занимаясь планированием, учтите: контроль качества не является действием, выполненным «перед тем как отдать продукт заказчику». Этот процесс идет непрерывно. В него вовлечен каждый член команды (каждый отвечает за качество собственной работы, т.е. «достаточно хорошее для заказчика»). Вся работа ваших сотрудников построена и повязана на «представлениях о качестве». К моменту «закрытия» работ (т.е. к моменту передачи продукта заказчику), работы по контролю качества должны быть закончены (а не запущены).
Если в вашем проекте предполагаются закупки - не забудь спланировать процедуры контроля качества для них. В этом картина будет обратной - вы выступаете в роли «заказчика». Ваш субподрядчик должен был позаботиться о том, чтобы контролировать качество в ходе выполнения работ. Вы же оцениваете лишь конечный результат, сверяя продукт с его спецификациями.
Таким образом, планирование качества на проекте предполагает использование экспертных знаний и навыков членов команды («как продукт, соответствующий требованиям»), предотвращение «золотой сервировки» и проверка результатов закупок.
Выходы:
- Дополнительные документы, описывающие ответственность (матрица ответственности / текстовые описания)
- Договоренности об отчетах (устно или письменно)
- Представление о способах контроля качества
- Запросы на изменения
Планируем и работаем с рисками
Входы:
- ИСР и ИСР-словарь
- Расписание
- Оценки предельной цены проекта
- Список ресурсов проекта
Что такое риски проекта?
Управление рисками призвано экономить деньги и время проекта. В «лучших проектных практиках» на управление рисками делается особый акцент, в то время как менеджеры, сторонящиеся методологий, им пренебрегают.
Работая с рисками, ПМ всерьез повышает шансы проекта «удержаться в треугольнике». Кроме того, он получает возможность проиллюстрировать спонсору эффективность своей работы. Поясним эти тезисы ниже, начнем с определения.
Риск - это вероятностное событие, которое может оказать положительное или отрицательное влияние на проект.
Риск имеет вероятность. Если «нечто» гарантированно должно случится (например, поставщик лицензионного ПО объявил о повышении стоимости в конце года) - то это нельзя называть риском, это данность, которую мы должны учесть в ходе планирования ресурсов.
Риск может иметь как негативное, так и положительное влияние на проект (например, отрицательный риск - уход одного или нескольких членов команды; положительный - появление на проекте признанного эксперта, если он успеет освободиться от текущих дел и не будет перехвачен другими командами). Соответственно, планируя риски, стремимся избежать негативных влияний и гарантировать наступление позитивных.
Работу с рисками можно представить в виде набора последовательных процессов (шагов).
Шаг 1. Планирование управления рисками
В вашей компании могут существовать сложившиеся методики и подходы к управлению рисками - если это так, то сейчас их можно изучить и отобрать удобные к использованию. В настоящей книге мы будем исходить из самых пессимистичных предположений - «в вашей организации управление рисками не ведется».
Поэтому, подходы мы выработаем самостоятельно.
Кто выявляет риски?
Шаг 2. Идентификация рисков
Идентификация рисков отчасти схожа с процессом сбора требований (описанном в главе VI). Нам понадобится приложить массу усилий (а, порой, и фантазии), чтобы выявить и описать в формате таблицы все разнообразие «неопределенных» событий проекта.
Распространенный подход гласит- «к идентификации рисков привлекаются все».
Не ищите риски в одиночку и не ограничивайтесь помощью команды. Попробуйте привлечь спонсора, заказчика (если это допустимо), пользователей, приглашенных экспертов и т.д. Пусть каждый вносит свой вклад.
Источники информации о рисках
Начинать идентификацию рисков лучше всего с анализа документов (у нас на руках уже есть устав, scope - со ссылками на расписание, бюджет, план коммуникаций и т.п.). Они содержат достаточно
«пищи для размышлений». Кроме того, создавая устав, мы уже могли вписать в него некие, самые очевидные и «высокоуровневые» риски.
Второй источник информации - это всевозможные интервью, мозговые штурмы, совещания. Проводить их можно и нужно как внутри команды, так и с привлечением пользователей и специалистов заказчика. Общаясь с последними - используйте приемы, аналогичные сбору требований (глава VI). Планируя встречи с командой - стремитесь включать обсуждение рисков в повестку каждого совещания. Помните - обсуждать статусы работ (прогресс) по поставленным задачам на совещаниях - дурной тон? Напрашивался логичный вопрос - что же обсуждать на совещаниях, кроме форс-мажоров. Ответ - риски. Вот обязательная тема на каждом из них.
Какая информация о рисках важна?
Идентифицируя риски -научитесь находить самые неожиданные возможности и угрозы проекту. Требуется командировка - попробуйте предположить, что рейс могут задержать дня на полтора - скажется ли это на проекте? Предполагается нанять субподрядчиков - учтите, что их фирма может разориться в ближайшие два месяца или просто украсть у вашего проекта идею и продать конкурентам.
Как уже было сказано - информацию о рисках удобно хранить в формате таблицы. Назовем ее «реестр рисков».
Данную таблицу мы будем заполнять в течение управления рисками (вплоть до закрытия проекта).
Сейчас, на втором шаге планирования нас интересуют только поля «описание риска» и «хозяин». Их мы должны заполнить для каждого выявленного рискового события.
Хозяин риска - персона, которой ПМ поручит обрабатывать риск (контролировать, что превентивные меры предприняты, а в случае наступления риска - реагировать на него).
Хозяином риска может быть ПМ или любой из членов команды, в редких случаях хозяином можно назначить кого-то из представителей заказчика.
На данном шаге «хозяин риска» может и не определиться. Самое главное - «накидать» максимально полный список самих рисков (и не забывать дополнять его в дальнейшем, возвращаясь к нему в ходе всего проекта). Когда идентификация завершена - ваш перечень рисков должен насчитывать сотни позиций. Не беспокойтесь, это не означает, что для каждого из них потом потребуется детальное планирование.
Шаг 3. Качественный анализ
Риски собраны и внесены в реестр. Время приступить к их оценке и сортировке.
Качественный анализ - это субъективная оценка выявленных рисков. Мы должны определить - как сильно тот или иной риск угрожает проекту.
Один из самых широко распространенных способов - оценить каждый риск по двум параметрам
«вероятность» и «влияние», задав для каждого значение из диапазона «высокое»/ «среднее» /«низкое».
В приведенном нами шаблоне, электронная таблица самостоятельно формирует заключение по каждому из рисков, сопоставляя позиции (подробнее рассказано в Приложении 5). Результат отображается по принципу светофора. «Зеленый» уровень говорит о минимальном влиянии риска,
«желтый» - об умеренном, а «красный» означает, что риск может очень сильно подействовать на проект.
По результатам качественного анализа мы сможем разделить все риски на те, что требуют дальнейшего контроля и те, которыми мы пока пренебрежем. Допустим, мы собираемся управлять только «красными» рисками (при этом не имеет значения, будет ли он позитивным или негативным по своей сути).
Так, пожар в головном офисе нашей компании или внезапное увольнение спонсора может оказать сильнейшее влияние на проект, но вероятность таких событий по нашим оценкам - низка. Уровень риска «желтый». Пренебрегаем.
А вот вероятность того, что требуемый для проекта сервер не доставят вовремя- средняя, при этом влияние на проект это также окажет значительное. Уровень риска «красный». Используем его для уточнения оценок в ходе следующего шага.
По завершении текущего шага у нас также появится возможность оценить Общий уровень риска
проекта в терминологии качественной оценки (проект высоко- / умеренно- / низко- рискованный). Такая оценка будет субъективной (вы сами можете определить, при каком количестве, например,
«красных» уровней - будете считать свой проект «высоко-рисковым») , однако ее очень полезно зафиксировать на будущее. Запишите оценку отдельно - ее динамика в будущем будет, в том числе, и отражением качества вашей работы.
Шаг 4. Количественный анализ
Количественный анализ - это форма объективной оценки риска. Этому подвергаются только
«значимые» риски, отобранные в ходе предыдущего шага.
Следует сразу оговориться - количественный анализ нужен не для всех рисков (а только для тех, уровень которых мы признали значимым).
Кроме того, количественный анализ выполняется не на всех проектах. Т.е. мы с вами вполне можем договориться пропустить этот этап и перейти сразу к шагу 5. Также стоит помнить, что количественный анализ необходимо пропустить для всех значимых рисков, которые требуют немедленного реагирования. Причины тому - высокая трудоемкость количественного анализа. Так что сами решайте
- требуется ли вам дополнительное уточнение оценки, или стоит сэкономить время и силы для себя и команды.
Среди методов количественного анализа выделяют:
- Сбор экспертных мнений
- Анализ Монте-Карло (мы коротко говорили о нем в разделе, посвященном формированию расписания - глава VIII шаг 6)Оценку стоимости риска (оценивается как произведение количественной оценки вероятности риска на его влияние).
Остановимся подробнее на последнем методе.
Стоимость риска оценивается как произведение количественной оценки вероятности риска на его влияние. К такому методу прибегают, например, при сравнении между собой нескольких альтернативных сценариев, каждый из которых сопряжен с рисками.
Например, вы можете потратить 1500 долларов на лицензионный софт, и эту трату придется понести с вероятностью 100%. Или использовать «пиратское ПО» бесплатно, однако тогда с вероятностью 5% вас поймают и выпишут штраф на 100.000 долларов. Что предпочесть?
Сравниваем стоимость риска по каждому из сценариев:
Для сценария 1 = 1500 * 1 = 1500 долларов
Для сценария 2 = 100.000 * 0,05 = 5000 долларов.
Вывод - сценарий 1 выгоднее для проекта (т.к. его стоимость риска ниже).
Для упрощения мы отбросили этическую составляющую в данной задаче, но не будем так поступать в жизни.
По результатам количественного анализа (если мы все же решились его проводить), мы сможем уточнить качественные оценки (включая общий рейтинг рисков проекта) - зафиксируйте его.
В представленном нами шаблоне «реестра рисков» нет полей для внесения результатов количественной оценки, вы можете добавить их самостоятельно.
Шаг 5. Планирование реагирования на риск
Определив самые значимые из выявленных на данный момент рисков, мы приступаем к построению планов. Наша задача – для каждого риска постараться найти ответы на два вопроса:
- «Как изменить уровень риска на проекте (увеличить / уменьшить)?»
- «Что делать, если мероприятия пункта 1 окажутся неэффективными, и риск все-таки произойдет?
Содержимое пункта 1 будем называть «Планом А» (общепринятые названия – «план реагирования на непредвиденные ситуации» или contingency plan). Содержимое пункта 2 назовем «Планом Б» (в методологиях он часто называется «планом отступления» или fallback plan).
Создаем «План А» (contingency plan)
Главный элемент «Плана А» для каждого риска – это стратегия. Выделяют четыре вида стратегии для положительных и отрицательных рисков:
Стратегия «Нивелирование » / «Использование» устраняет корневую причину риска (или наоборот, гарантирует ее сохранение). Это самый лучший вид стратегии, если он приемлем по цене и прочим параметрам - стремитесь использовать именно его.
Пример для негативного риска: неопытный член команды может завалить работу. План А - заменить сотрудника на более опытного.
Пример для позитивного риска: закупаемое для проекта лицензионное ПО, может достаться нам со скидкой, если все закупки будут проведены до конца года. План А - провести закупки ПО до конца года.
Стратегия «Ослабление» / «Усиление » нацелена на изменение вероятности или влияния рисков.
Пример для негативного риска: неопытный член команды может завалить работу. План А - заранее провести тренинг для сотрудника.
Пример позитивного риска: закупаемое для проекта лицензионное ПО может достаться нам со скидкой, если все закупки будут проведены до конца года. План А - уведомить о возможных рисках заинтересованных и ответственных за закупки лиц.
Стратегия «Перенос» / «Разделение » нацелена на то, чтобы либо переложить бремя риска на третью сторону (например, субподрядчика или страховую компанию); либо наоборот, поделиться возможностями с теми же субподрядчиками, если это принесет удачу проекту в целом.
Пример негативного риска: неопытный член команды может завалить работу. План А - нанять субподрядчиков для выполнения этих работ.
Пример позитивного риска: Результаты проекта будут знаковыми не только для нашей организации, но и для потенциальных поставщиков лицензионного ПО (они смогут гордиться, что именно на их платформах создана столь масштабная система). План А - провести переговоры с
поставщиками (возможно, кто-то из них, заинтересовавшись, предложит нам льготные условия поставки или иную помощь)
Стратегия «Принятие» предполагает бездействие, «смирение» с обстоятельствами. Это наиболее пассивная из всех стратегий. Она может быть использована для неснижаемых рисков, предотвратить которые дороже, чем дождаться их наступления. Остерегайтесь применения такой стратегии, следите, чтобы такой тип реагирования применялся не более чем для 10% рисков на любом проекте, а по возможности - стремился к нулю.
Пример: неопытный член команды может быть уволен из организации за провал на другом проекте (при этом он покинет и ваш проект). План А - уточняем риски у «хозяина ресурсов» и бездействуем.
Зафиксируйте выбранную стратегию в реестре - опишите ее вид и действия «Плана А». Определение вида стратегии очень важно для самоконтроля. Классифицируя намеченный «план действий» - проверьте себя. Зная, что наилучшим сценарием будет нивелирование / использование риска, а худшим - принятие, убедитесь, что выбран был действительно наилучший способ реагирования из доступных.
Помимо стратегии, важнейшая задача данного шага - определить «хозяина риска», если таковой не был назначен в ходе идентификации (шаг 2). По умолчанию, хозяином всех рисков является ПМ - избегайте такой ситуации.
Общее правило - хозяином становится тот, кто находится «на передовой» (т.к. именно он будет проверять, что определенные действия в рамках Плана А выполнены).
В работе «хозяина» крайне важны правильно определенные «триггеры риска».
Триггеры риска - признаки, по которым «хозяин риска» поймет, что превентивные действия не сработали и пора «отступать» (использовать План Б). Это еще один резон не становиться хозяином всех рисков - пусть хозяином будет тот, кто первым заметит триггер.
«План Б» (fallback plan)
План Б будет использоваться «хозяевами рисков», если План А окажется недостаточно эффективен.
Для негативных рисков это будет означать, что превентивные меры не помогли, и риск все же начал реализовываться, для положительных - что, не смотря на приложенные усилия, мы все же упускаем удачную возможность.
Заполняя данный раздел реестра, используйте эффективный прием: задавайтесь вопросом не «что делать, если...», а «что делать, КОГДА риск произойдет». Таким образом, можно сделать гипотетическую картинку на много ярче и реалистичнее.
Шаг 6. Изменяем планы и определяем резервы
Оба плана (в особенности «План А») в зависимости от выбранной стратегии - предполагают какие-то действия с нашей стороны.Иногда, можно ограничиться внесением изменений в планы: корректировка расписания или состава работ сама по себе, порой, способна понизить уровень риска, скажем, с «красного» на «зеленый».
В других случаях потребуются определенные ресурсы - для найма сотрудников или проведения тренингов, для привлечения субподрядчиков и так далее. Для их обозначения обычно используется термин «резервы на непредвиденные случаи»
Такие резервы являются неотъемлемым компонентом «предельной цены контракта». По завершении работы с рисками, мы сможем вернуться к соответствующему шагу главы VIII и уточнить созданные ранее оценки стоимости.
«Резервам на непредвиденные случаи» иногда противопоставляют «управленческие резервы» (они целиком планируются и распределяются спонсором проекта и ПМ не известны).
Обратите внимание - резервы не удорожают проект! Сумейте, при необходимости, донести до своего руководства.
Управление рисками в целом имеет единственной целью сэкономить время и деньги проекта. Пренебрежение управлением рисками с огромной вероятностью потребует затрат, превышающих все возможные резервы (мы наглядно проиллюстрировали это, когда говорили о количественной оценке в шаге 4).
Используйте аналогичный прием, чтобы продемонстрировать свою успешность, как ПМ спонсору. Я бы рекомендовал вам фиксировать результаты «качественной» и, (если таковая проводилась)
«количественной» оценок. Если работы были организованы правильно, то результаты неизменно покажут снижение потенциальных затрат и, возрастающую вероятность «удержать» проект внутри тройственного ограничения (общий рейтинг рисов проекта будет падать).
И еще один совет - сформировав план управления рисками, просмотрите его еще раз. Подумайте, не породили ли ваши запланированные действия в рамках «резервов на непредвиденные случаи» - дополнительных рисков (их принято называть вторичными). Если да - внесите их в реестр (как идентифицированные) и повторите процедуру. Чем полнее окажется реестр рисков, тем лучше для проекта.
Выходы:
- Реестр рисков
- Запросы на изменения