Используют ли руководители проектов журналы RAID?

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

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

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

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

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

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

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

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

Я никогда не использовал журналы предположений и зависимостей, пока не начал работать у своего предыдущего работодателя, где я впервые столкнулся с ними и использовал их в ряде проектов. Боюсь, мой вывод после этого заключался в том, что они не давали никакой реальной пользы, хотя это вполне могло быть моей наивностью при их использовании (для чего я не проходил обучение). К сожалению, у меня сложилось впечатление, что они существуют только для того, чтобы обеспечить «A» и «D» для изящного слова RAID!

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

Что мне нужно знать:

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

И я оставляю это там - больше мне лишняя деталь. Если это не поможет мне устранить риск, меня это не интересует.

Я использую журналы рисков и проблем и регулярно просматриваю их. Они являются важными инструментами как для меня как PM, так и для более широкого сообщества заинтересованных сторон в рамках проекта. Почему я так говорю?

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

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

Я определяю риск как «что-то, что может произойти, что повлияет на проект», тогда как проблема — это «что-то, что произошло, что повлияло на проект». Суть в том, что риск МОЖЕТ оказать влияние там, где проблема УЖЕ оказала влияние.

Я считаю, что полезно попытаться выразить риски в форме: «Существует риск того, что (что-то может случиться), потому что (что-то может пойти не так), что может привести к (описанному влиянию на проект)». Итак, снова ссылаясь на ответ Дэвида Эспины, если у пациента не было сердечного приступа, я мог бы сказать: «Существует риск того, что у пациента может случиться сердечный приступ, потому что у него повышено кровяное давление и высокий уровень холестерина, что может привести к серьезные долгосрочные проблемы со здоровьем или даже смерть». Чтобы снизить этот риск, примите все необходимые меры для снижения артериального давления/снижения уровня холестерина и задокументируйте их.

Существует аналогичный формат для проблем в духе «Есть проблема, которая (что-то пошло не так) в результате (что бы это ни вызвало), которое привело к (влиянию на проект)». Итак, вернемся к примеру Дэвида, если пациент действительно перенес сердечный приступ: «Существует проблема, заключающаяся в том, что пациент перенес сердечный приступ в результате высокого кровяного давления и холестерина, что привело к необходимости открытого сердца. хирургия и длительное лечение».

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

Я работал как со Scrum, так и с гибкими методологиями, поэтому все зависит от вашего подхода к разработке.

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

Однако я использовал scrum в сочетании с планом проекта. Сначала составляется устав клиента, если это применимо. Затем проводится качественная оценка рисков.

Затем проводится анализ воздействия. Диаграмма ниже является примером такого анализа. Вероятность возникновения риска умножается на последствия, если это произойдет. На диаграмме ниже приведен пример

Качественный анализ используется для анализа воздействия, и это делается путем умножения вероятности возникновения проблемы на воздействие. Я обычно даю баллы из 10 вероятности возникновения риска и воздействия, где 10 баллов является самым высоким. Это делает его простым. Результаты формируют ранг каждого риска, и 1 становится самым высоким риском.

Наконец, план смягчения рассматривается для каждого риска. Рассматриваются Риск, потенциальная причина и реакция.

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

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

В заключение я предпочитаю методы scrum и agile в сочетании с хорошим планом проекта и программным обеспечением с открытым исходным кодом для отслеживания проблем.

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

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

1. Элементы никак не связаны с расписанием. Во многих случаях элемент RAID возникает из-за того, что что-то идет не так, когда люди пытаются выполнить запланированную задачу. Я бы предпочел использовать некоторое программное обеспечение, которое отслеживает задачи , и их проблемы связаны друг с другом.
2. Поскольку каждая категория RAID находится на отдельном рабочем листе, сложно связать связанные элементы вместе. Например: риск регистрируется, позже он становится проблемой. Вы вырезаете первоначальный риск и вставляете в лист задачи? Вы дублируете информацию и пишете «относится к риску 123»?
3. Поскольку это электронная таблица, нет автоматического способа поиска дубликатов (было бы неплохо иметь что-то вроде stackexchange, когда вы создаете новый вопрос — предложите, если похожие уже существуют)

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

Я считаю, что управление рисками и проблемами имеет решающее значение для успеха проекта. A и D в RAID обычно обозначают предположения и зависимости — они становятся все более важными по мере увеличения размера и физического разделения проектной группы.

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

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

Определение риска как чего-то, что с вероятностью менее 100 % окажет влияние на проект, дает вам два способа справиться с ним: попытаться изменить вероятность (избежать или передать) воздействия и попытаться изменить воздействие (смягчить или уменьшить). планировать непредвиденные обстоятельства). В случае проблемы все, что вы действительно можете сделать, это работать над смягчением последствий.

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