Здесь спросили , как преодолеть сдержанность в использовании журналов RAID (со Aссылкой на действия, а не на предположения). Общий подход, уже предложенный ОП, заключался бы в том, чтобы избавить (в данном случае гибкую) команду от форматов документов и аспектов, которые не вписываются в их мир, и позволить менеджеру проекта позаботиться о координации между двумя мирами. различных взглядов и документов, которые необходимо поддерживать.
В этом ответе на приведенный выше вопрос было предложено, чтобы Реестр рисков PM был коротким, а agile-команда поддерживала свой собственный, при этом они либо находили документ полезным и поддерживали его самостоятельно, либо поощрялись к этому:
Ваши журналы должны содержать только пять или шесть основных элементов. Может семь. Это элементы с наивысшим приоритетом, которые вам нужно отслеживать, самые дорогие, самые важные. Остальные отпадают и делегируются командам, которые, вероятно, сами ведут свои собственные журналы ... или их следует поощрять к этому. Таким образом, журналы остаются действительно актуальными и важными, и я подозреваю, что даже SCRUM-команда изучит их и найдет полезными.
На мой взгляд, это предложение вызывает следующие вопросы:
Как всегда, ответ @DavidEspina превосходен. С другой стороны, поскольку сегодня утром эта проблема возникла в моем окружении, я решил поделиться ею.
Я веду структуру распределения рисков, которая отслеживает риски на довольно детальном уровне — мы используем другую структуру, но эффективно я отслеживаю на L2 WBS (L1 — конечный результат, L2 — рабочие пакеты, необходимые для создания этого результата). . Я составляю ежедневные графики риска и изменения риска.
Мой коллега ведет реестр рисков, который является нашим хранилищем возможных рисков. Мы эскалируем риски реестру только в том случае, если:
Ваш вопрос чрезвычайно проницателен. Это аксиома PMBOK, что PM — это самодержец, способный отменить проект, если все не следуют правильному процессу. Это академическое предположение для описания эффективного управления проектами.
Мы все хотим работать над зрелыми проектами, в которых все понимают, что совместная работа приводит к более успешным результатам. Но правда в том, что в большинстве наших сред WIFM сильнее, чем PMBOK. Правда в том, что большинство менеджеров по проектам работают над изолированными рабочими моделями, чтобы иметь возможность предсказывать влияние проекта и раскрывать только продукты модели. (После нескольких месяцев работы я, наконец, сделал свой проект достаточно зрелым, чтобы работать с EVM; я нарисовал график, и прежде чем я закончил первое предложение, мой босс сказал: «Вы мне уже наскучили». EVM — фантастический инструмент; усилия по навязыванию EVM ценны сами по себе, но все, что босс хочет услышать, это: «Я изучил проблему; команда 2 опаздывает в 80% случаев по крайней мере на 33% от их оценки; проект, основанный на том, как они действуют,
Управление рисками наиболее ценно для дискуссий, которые оно порождает. Никого не волнует, равен ли риск 2 или 3; ценность в том, когда кто-то говорит: «Я думаю, что это будет происходить реже, если мы купим более толстую булавку, или уволим Теда, или привлечем контроль качества раньше, или…». К сожалению, я не знаю, как загнать людей на этот холм. зрелости управления рисками.
Один из моих учителей в старшей школе сказал, что «все начинается как искусство, становится наукой, затем инженерией, а затем заканчивается ремеслом». В ПМ все начинается как племенное знание, потом частная модель, перерастает в плохо управляемый проект, потом хреновая работа, потом операции. Вы находитесь на стадии закулисной модели. Не иначе, как вверх.
(WIFM-Что в этом для меня?)
В проектах, за которыми я наблюдал, мне не удалось воплотить свое видение того, как должен выглядеть журнал рисков на уровне проекта, в том смысле, что он должен содержать шесть или семь самых высоких угроз, стоящих перед проектом, и что журналы более низкого уровня могут и должны использоваться различными командами. Журнал уровня проекта быстро превращается в тщательно контролируемый результат, как было сказано в исходном вопросе о RAID.
На уровне проекта я бы назначил человека менеджером по рискам проекта, который будет выполнять дополнительные роли по управлению рисками на уровне задач. Этот человек будет поощрять или заставлять менеджеров по рискам более низкого уровня вести свои собственные журналы рисков и будет «проверять» их по мере необходимости, чтобы обеспечить или облегчить соблюдение и разумные усилия в этой задаче. Если журналы плохо поддерживаются, это становится задачей для команд по исправлению, и это действие будет контролироваться PMO. Кроме того, на основе анализа рисков на более низких уровнях менеджер по управлению рисками проекта будет иметь полномочия передавать выявленную угрозу в журнал уровня проекта, а затем управлять этой угрозой на самом высоком уровне.
При всем при этом культура мышления, не основанного на рисках, или то, что я называю сопротивлением управлению рисками, преобладает, кажется системным во всех проектах, и ее ужасно трудно преодолеть.
Если бы вы опросили свои команды, я бы подозревал, что 100% из них согласятся, что управление рисками — важная, а может быть, и самая важная задача в каждом проекте. Однако мы, кажется, хотим этого избежать, как люди, которые высказывают угрозы, так и те, кому нужно их услышать.
Люди предпочитают гарантии; нам кажется неудобным из-за неопределенности; и у нас мутнеют глаза, когда мы начинаем говорить о статистике, вероятностных распределениях, уверенности..... Заснул, извините.
Мы не хотим поднимать угрозы по проектам, которые мы реализуем, потому что это выглядит так, как будто мы не контролируем, это выбрасывает наше грязное белье, оно передает ответственность за его смягчение эскалатору рисков, когда, если не поднять, мы можем обвинять форс-мажор или другие заинтересованные стороны, и так далее. Нам говорят, что нельзя пытаться, но нужно делать, неудача — это не вариант, пессимисты — это негативные люди, с которыми никто не хочет работать, и т. д. Все это — убийцы управления рисками.
С другой стороны, для тех, кому нужно услышать угрозы, мы следим за теми, кто их высказывает. Мы говорим им исправить это, потому что «вот почему я нанял вас». И тогда мы заставляем их сообщать нам об этой угрозе несколько раз в неделю, микроконтролируя каждый шаг. И если угроза материализуется, мы обвиняем эскалатор риска, независимо от того, насколько сложными и строгими были действия по смягчению последствий, в то время как мы вознаграждаем пожарного, который не пытался предсказать и избежать бурных вод впереди. В целом, есть серьезные последствия, вызывающие угрозы.
Для надежного, зрелого и действенного процесса управления рисками все вышеперечисленное должно быть противоположным тому, что происходит. Повышение и снижение рисков должно вознаграждаться, даже если снижение не принесло результатов; в то время как неожиданности и героическое тушение пожара нужно «наказывать» даже после успешного восстановления. Кажется, прямо сейчас происходит обратное.
Все решения, которые я пробовал, противоречат тому, как мы естественным образом реагируем на угрозы. Я думаю, что решение здесь больше связано с человеческой психологией, чем с процессами, инструментами, журналами и т. Д. Это скорее разглагольствование, чем ответ, но это действительно сложный вопрос.
Дэвид Эспина
ткацкий станок с бригадой
Дэвид Эспина