Как думаете, в чем разница между новичками в управлении проектами и опытными руководителями?
В их акцентах.
Новички фокусируются на соблюдении формальных инструментов, а опытные руководители на рисках: пытаются выявить их как можно раньше и либо предотвратить негативные последствия, либо минимизировать стоимость устранения. Как мы писали в прошлой статье, наш фокус в управлении коммуникациями и раннем выявлении рисков от людей-экспертов в своей области.
А знаете почему опытные руководители так внимательно смотрят на риски?
Для ответа на этот вопрос надо изучить статистику и понять, как часто изменения или реализованный проект завершены невовремя, с превышением бюджетов или не достигли поставленных критериев успеха, каково среднее отклонение при реализации проектов?
Ну а затем необходимо разобраться, а какие есть инструменты для выявления рисков, как минимизировать эти риски, в том числе с помощью цифровых инструментов?
Также в качестве предисловия добавим, что большинство цифр ниже актуальны для ИТ и цифровых проектов, но они более чем подходят и для проектов в "классическом производстве", кардинальной разницы нет.
Содержание
Введение
И так, для начала давайте разберемся, а насколько глубока проблема? Какая доля проектов имеет проблемы или провальны?
Сначала предлагаем вспомнить нашу статью и на чем строится "проектный треугольник"
Если же обратиться к исследованиям Standish Group то мы получим, что успешны в среднем 30% проектов, а 70% проектов проблемные или провальные: имеют превышение сроков, бюджетов, не достигаются критерии успешности или вовсе закрываются до завершения.
Так, по ее исследованиям 1994 года (ссылка 1 и ссылка 2) доля успешных проектов была лишь 16,2%, а 2018 году таковых было около 29%. При этом примерно с 2000 года доля успешных проектов перестала увеличиваться, а после 2015 годов наоборот, появляется тренд на снижение.
Предлагаем ознакомиться с несколькими цифрами из исследований и презентаций
Также немного статистики из отчета по отраслям
При этом наиболее "проблемные" проекты самые дорогие и большие (если убрать из внимания продуктовые оценки)
И это логично, ведь если обратиться к той же модели Киневин, то чем крупнее проект, тем более неочевидные связи в нем, там банально больше "узких" мест и гораздо сложнее учесть все факторы, то есть чем больше проект, тем более гибким необходимо быть и больше прорабатывать вопросы рисков. И это подтверждается статистикой Standish Group.
Самые внимательные читатели тут могут задать вопрос: "Эй, тут противоречие с исследованием о статистике продуктового управления. Ведь менеджеры по продуктам как раз часто используют Agile практики. И в итоге продуктовые инициативы проваливаются чаще, а тут наоборот".
И он будет совершенно прав в своем возражении.
Но давайте вспомним, чем же отличаются проекты от продуктов? Об этом мы говорили в статье про управление продуктами. Кратко различие продемонстрировано ниже
В итоге менеджеры по продуктам работают с большей степенью неопределенности и на большем горизонте. И с одной стороны проекты внутри продуктовой инициативы могут быть успешными, но из-за глобальных ошибок продукт будет провальным или проблемным: неверные функциональные приоритеты, ошибки с маркетингом и позиционированием продукта, в общем причин множество.
Подтверждение тому тоже статистика Standish Group. Если мы говорим про ИТ-проекты и разработку программного обеспечения, то в итоге из всего перечня заложенных функций лишь 20% востребованы и используются часто, 30% - редко, а почти 50% - никогда.
Отсюда рождается и еще более печальная статистика о успешности продуктов
А если копнуть в статистику стартапов и молодых компаний, то статистика еще печальнее - 90% закрываются в течение 3-х лет, а около 99% в течение 5-ти лет. Тут накладываются еще проблемы работы с инвесторами, формирования команды, выстраивания системной работы. О том, что такое системный подход в нашем понимании тоже инфографика ниже.
Так почему же, если говорить в рамках проектного управления, проекты по Agile более успешны? Причин множество, но не в последнюю очередь из-за подхода к планированию. В гибких методологиях мы отталкиваемся от доступных ресурсов - времени и бюджета. Мы рассматривали этот вопрос в нашей статье ранее.
Теперь же приведем разбор, а каковы последствия всех этих проблем? В среднем, согласно исследованиям того же Standish Group, ИТ-проекты имеют следующие отклонения:
превышают первоначальный бюджет в среднем на 50-60%
среднее превышение времени в проблемных проектах на 80-85% от плана
Все эти цифры сходятся и с нашими наблюдениями. Ну и относительно того, когда надо вносить изменения и почему опытные руководители стараются выявить риски как можно раньше - ответ на визуализации ниже
Теперь понятно, почему опытные руководители проектов делают упор на стадии инициации и планирования и могут отдать этим стадиям до 30-40% времени проекта.
И еще немного о факторах успеха проекта
А теперь просто подумайте, сколько из этих критериев можно закрыть работой с рисками, будь то на стадии планирования или реализации, проведения ревью по итогам проекта и обучением на собственных ошибках.
При этом, как показало недавнее исследование "Проектного управления в России 2022", проведенное руководителем проектного офиса СберМаркет Дмитрием Ирешевым, руководители проектов повсеместно используют инструменты планирования и всевозможные таск-трекеры. При этом из личных наблюдений можно сделать вывод, что культура постоянного совершенствования процессов планирования пока распространена не широко. Получается руководители проектов любят планировать, а вот учиться на своих ошибках, структурировать полученный опыт и повышать качество планирования - нет.
Приведенная ниже классификация очень условная, но тем не менее позволяет понять, а "куда" смотреть, когда Вы занимаетесь самой сложной задачей - выявлением рисков.
Глобальные или системные риски:
Политические — изменение политической ситуации в стране и мире.
Природные риски. К ним относятся экологические катастрофы или стихийные бедствия.
Юридические — сюда входит как несовершенство существующих законов, так и риск появления новых, способных создать дополнительные проблемы для бизнеса.
Экономические — изменения в налоговой системе, санкции против государства, потери из-за нестабильности курсов валют и т. п.
Частные, или локальные риски:
Производственные - производственные и управленческие ошибки и ограничения, в том числе невыполнение плана продаж, сокращение объёмов производства.
Финансовые - недополучение прибыли от проекта, неликвидности продукции
Рыночные - нестабильность ситуации на рынке, например спрос, ценовая политика компании, конкурентная борьба
Немного более подробная классификация представлена ниже.
Какие же есть основные документы, на которые можно опираться в работе с рисками?
Ключевым документом является ГОСТ Р ИСО 31000-2010
Вот главные схемы из него
Если же совсем упростить, то механизм работы с рисками внутри проекта на схеме ниже.
Основные типы рисков по областям управления проектами
Контрольный список общих проектных рисков:
Расписание проекта
Бюджет/финансирование
Кадровые вопросы (отсутствие руководителя и недостаточное количество сотрудников в группе)
Качество (несоответствие стандартам качества)
Взаимное согласие основных заинтересованных лиц (конфликты)
Изменения содержания проекта
Проектные планы (их согласованность и проработанность)
Методология управления проектом
Деловой риск
Управленческий риск (реорганизация, приводящая к изменению состава проектной команды)
Риски со стороны поставщика (задержка или отмена поставок)
Юридические вопросы - увеличение стоимости, отрицательный имидж
Политические риски - отрицательный имидж
Экологический риск
Погодные и природные катаклизмы
Технологические риски (нет в наличии необходимых составляющих).
Сложность проекта и квалификация персонала(недостаток компетенций у проектной команды и руководителя)
Как Вы уже наверно догадались, самое сложное в данном направлении - выявление перечня рисков и их оценка.
Мы погрузились с Вами в тему, понимаем последствия и общий алгоритм, но какая может быть стратегия работы с рисками?
Исключение
Стратегия исключения предполагает полное исключение риска из проекта. То есть необходимо на "верхнем" уровне придумать действие, которое исключит саму вероятность реализации риска. Эта стратегия очень сложна и дорога для применения, а порой невозможна, так как может заставить отказаться от части ключевых работ или от всего проекта целиком.
Например, Вы работаете в сфере логистики и Вам необходимо исключить возможные простои груза. В итоге исключение этого риска может стоить настолько дорого, что доставка груза теряет всякий смысл.
Тоже самое и с разработкой и внедрением ПО. Вы можете исключить риски изменения запросов Заказчика жесткой фиксацией требований в контракте. Но вот гарантирует ли это успех проекта в целом, а главное согласен ли клиент будет на такие условия?
Минимизация
Это наиболее распространенная стратегия. Её задача - заранее проработать риск и минимизировать вероятность его наступления и/или тяжести последствий.
Давайте снова разберем на примере логистики. Можно ли снизить до нуля риск поломки машины в пути? Конечно нет, но что можно сделать для минимизации этой вероятности? Например организовать своевременное техническое обслуживание, оформить топливные карты с сетевыми заправками, чтобы водитель не заливал некачественное топливо, ориентируясь на низкую цену.
И второй пример еще раз разработка ПО?
Возможно ли полностью исключить ситуацию, когда клиент изменит пожелания? Тоже нет. Но что, если мы на ранней стадии проведем обследование, расскажем клиенту о том, как мы видим решение задачи с учетом нашего опыта, опишем возможные альтернативы и совместно с Клиентом выберем оптимальный вариант до начала работ. В итоге мы не исключили риск полностью, но мы минимизировали вероятность его наступления и возможные последствия, ведь Вам теперь вряд ли придется все переделывать, а лишь скорректировать некоторые детали.
Да, это сложный вариант, не все Клиенты готовы думать и слушать, но и вступать в заранее опасные проекты может оказаться слишком рискованным мероприятием. Стратегия "продай любой ценой" в итоге всегда проигрышна.
Принятие
Здесь все просто - до наступления риска предполагается «ничего не делать». Однако совсем ничего не делать – это не управление рисками. Тут есть 2 варианта – активное и пассивное принятие.
Активное – формируется резерв времени и денег на устранение последствий материализации риска. Так, самое распространенное правило для более менее понятных проектов - заложи резерв 30-35% на различные форс-мажоры и непредвиденные расходы. Но здесь 2 ограничения:
все равно необходим опыт руководителя, чтобы он заранее мог корректно оценить сроки и стоимость, количество пропущенных условий и их потенциальное влияние;
необходимо вести переговоры с Клиентом, ведь чем больше запас у Вас, тем лучше Вам, но хуже ему.
Пассивное – наличие плана Б (устранения последствий проблемы) на случай, если риск материализуется, в котором руководство проекта и его команда будут решать проблемы из-за этого риска собственными силами по мере их поступления.
Это хорошая стратегия для использования при очень небольших рисках, которые не окажут большого влияния на проект, если они произойдут. При этом разработка альтернативной стратегии управления рисками и проработка дополнительных может оказаться чрезмерно долгой и дорогой, что может поставить под угрозу весь проект.
Делегирование
Эта стратегия перекладывает последствия материализации риска и ответственность за реагирование на 3-ю сторону, при этом сам риск не устраняется. Эта стратегия практически всегда предполагает финансовые затраты на передачу и получение финансовой компенсации в случае материализации риска.
Типичный пример - страхование. Мы перекладываем свои риски на страховую компанию. Которая, если риск, например повреждение груза во время шторма, выплатит Вам все неустойки. Но за это все она берет премию.
Ну или, если на примере разработки ПО, можно заключить договор с консалтинговым агентством, чтобы они изначально провели обследование клиента и подготовили все требования. А если в процессе требования изменятся, то они оплатят все переработки Ваших людей и все судебные претензии клиента. Но это из области фантастики, вряд ли кто-то согласится на такие условия, или цена контракта с консультантами станет такой, что уже Ваш клиент откажется от проекта.
Выявлять, или идентифицировать риски можно через несколько ключевых подходов:
ретроспективный анализ
анализ текущего проекта
анализ возможных событий
Далее мы чуть подробнее рассмотрим основные инструменты в рамках данной классификации Если Вам будет интересно погрузиться в какой-либо глубже, то будут полезные ссылки на подробные статьи
Здесь Вы можете анализировать прошлые проекты компании, ну если у Вас есть такой архив, где есть планы и история реализации, и, если повезет, ретроспектива проектов, с историей сработавших рисков и предпринятых мер.
А если ведется системная работа (правда мы такого практически не встречали) в компании могут быть контрольные листы рисков.
Ну и финальное в этом блоке - анализ лучших практик. Если Ваш проект не является запутанным, с неочевидными связями, то можно изучить лучшие практики реализации аналогичных проектов или использовать чек листы
Тут изучаем входную информацию о текущем проекте и качество проектной документации:
насколько проработано техническое задание и критерии успешности, продукт проекта, границы. Есть ли у этих атрибутов измеримые показатели;
проработаны ли допущения, оценена ли техническая возможность реализации проекта и необходимость в доработках типового решения, имеются ли в команде проекта все необходимые специфичные / технические компетенции;
есть ли карта стейкхолдеров, оценено ли их влияние и план работы с ними
есть ли поддержка от первых лиц
насколько проработаны планы реализации и их согласованность, определена потребность во внешних поставщиках и есть ли опыт работы с ними.
Если посмотреть на ИТ-проекты, то полезно обратить внимание на бережливое производство, понимание механизмов мотивации и причин сопротивления, 7 причин большинства проблем в цифровых проектах.
Бережливое производство
Понимание какие потери бывают в бережливом производстве позволяет выявить риски:
связанные с требованиями к продукту проекта;
связанные с внутренней организацией;
связанные с работой ИТ-систем (например, скорость или надежность, запутанный интерфейс и т.д.)
Подробнее про бережливое производство по ссылке.
Мотивация и сопротивление изменениям
Проекты почти всегда связаны с изменениями. Естественная реакция людей – сопротивление и агрессия. Понимание этих механизмов также позволит выявить риски и запланировать мероприятия для их исключения или минимизации.
7 причин большинства проблем в цифровизации
Во всех ИТ-проектах есть несколько общих причин, которые приводят к большинству проблем.
Нет глобального понимания сути, целей и технологий цифровизации и цифровой трансформации
Недостаток необходимых soft и hard компетенций у ИТ
Недостаток компетенций в управлении проектами, продуктами, изменениями, в работе с сопротивлением персонала на среднем и техническом уровне управления
Неудобство ИТ-систем, высокие трудозатраты на интеграцию
в единую ИС и сопровождение
Низкая культура работы с данными и процессами
Отсутствие базовой цифровой грамотности у персонала и виртуализации цифровых навыков
Культура компании, в том числе ожидания, что кто-то решит все проблемы
Подробнее по ссылке.
В общем анализ текущего проекта - это анализ того, все ли сделано из того, что должно быть проработано на стадиях инициации и планирования.
Это самое сложное направление, где применяются сложные математические и экспертные подходы: SWOT, мозговые штурмы, метод сценариев, интервью, диаграммы Ишикавы и влияния, деревья отказов и перечни подсказки (PESTLE, SPECTRUM, TECOP), а также всевозможные методы моделирования.
SWOT-анализ — метод стратегического планирования, для оценки внутренних и внешних факторов, которые влияют на развитие компании. SWOT-анализ нужен, чтобы оценить сильные и слабые стороны компании и определить перспективы развития и угрозы извне.
S – Strengths (сильные стороны),
W — Weaknesses (слабые стороны),
O — Opportunities (возможности),
T — Threats (угрозы).
Плюсы
универсальность
применим в самых разнообразных сферах экономики и управления. Его можно адаптировать к объекту исследования любого уровня (продукт, предприятие, регион, страна), использоваться и для оперативного, и для тактического, и для стратегического планирования.
простота и доступность
не надо со сложными вычислениями, задействовать дорогостоящие маркетинговые процедуры. SWOT-анализ сможет провести каждый, кто обладает информацией о свойствах продукта и ситуации на рынке.
гибкость работы с данными
Свободный выбор анализируемых элементов в зависимости от поставленных целей (например, можно анализировать город только с точки зрения туризма или только с точки зрения работы транспорта и т.д.).
Недостатки
результаты здесь и сейчас
SWOT-анализ отражает текущую ситуацию на рынке и внутри компании и не учитывает предполагаемые изменения. Иными словами, с появлением новых факторов или при переменах анализ нужно будет проводить заново.
субъективность
Многое зависит от того, кто проводит анализ, его компетенций, осведомленности и экспертности в отрасли, личной оценки и предпочтений
необъективность
отсутствует оценка основных и второстепенных факторов, их взаимосвязей
отсутствуют количественные оценки.
Полезные материалы:
Метод служит для оперативного решения проблем и основывается на стимулировании творческой активности людей, принимающих в нём участие и предлагающих максимальное количество всевозможных вариантов решения. После того, как все варианты озвучены, выбираются те, которые более всего подходят. Обычно мозговой штурм состоит из 3 обязательных этапов:
Постановка проблемы
Генерация идей
Отбор, систематизация и оценка идей
Как правило, для мозгового штурма создаётся 2 группы: в первую входят генераторы идей, предлагающие решения, во вторую те, кто занимается обработкой предложенных решений.
Ключевые правила мозгового штурма
Предварительная подготовка
Много участников
Уточнение поставленной задачи
Записывание всех идей
Никакой критики
Максимальная генерация идей
Привлечение других людей
Модификация идей
Визуальное отображение
Отрицательный результат тоже полезен
Также к такому разделу можно отнести и подходы латерального мышления из продуктового управления.
Полезные ссылки:
Подвид мозгового штурма, в котором участники анонимно и письменно генерируют идеи. Цель - более полное участие членов команды в генерации идей.
Примерный алгоритм
Посредник (менеджер проекта) просит присутствующих выписать на стикере только один, самый опасный риск.
Затем посредник собирает заметки и прикрепляет их на доске.
После этого он просит участников записать второй по значимости или опасности риск.
Так продолжается до тех пор, пока группа не исчерпает все возможные идеи.
Далее начинается этап оценки и приоритезации:
Выявив все риски и расклеив заметки на доске, участники должны расположить их в порядке приоритетности. Сначала они делают это письменно: каждый составляет свой список и передает его посреднику.
Просмотрев все поданные ответы, посредник составляет общий список приоритетов в соответствии с мнением большинства. На этом этапе он может обратиться к группе за разъяснениями и комментариями. В результате такой работы получается полный список рисков, расположенных в порядке их значимости или степени воздействия на проект.
Ключевые правила:
Одна записка содержит один риск.
Записки, размещенные на доске не должны дублировать друг друга.
Участники не могут критиковать или судить варианты рисков, предложенных другими. Группа должна быть достаточно компактной и легко управляемой, иначе процесс может затянуться.
Плюсы
Низкие затраты времени, обычно не более 2 часов
Независимость от авторитетов
Большое количество идей
Минусы
Исключается принятие решений по неотложным вопросам
Использование данного метода требует очень квалифицированного официального руководства.
Полезные ссылки:
Позволяет произвести оценку наиболее вероятного хода развития событий, а также наиболее вероятные последствия принимаемых решений.
На основе разработанных сценариев становится возможным, на определенном уровне достоверности, определять возможные варианты событий и развития ситуации, определять взаимосвязь между различными факторами.
Как правило, применяют подготовку 3-х сценариев
оптимистического;
пессимистического;
ожидаемого, наиболее вероятного.
Наиболее популярные методы реализации:
получение согласованного мнения;
повторяющаяся процедура независимых сценариев;
использование матриц взаимодействия.
Плюсы метода
возможность заблаговременно выявить неэффективные, с точки зрения последствий, решения;
разработка нескольких прогнозных вариантов развития ситуации и спрогнозировать поведение объекта в каждой из них.
Минус - трудоемкость получения большого количества оценок и корректной их обработки.
Полезные ссылки:
Набор сеансов вопросов и ответов, проводимый с участием основных заинтересованных лиц, членов группы и других сотрудников, имеющих отношение к данному проекту или опыт реализации подобных проектов.
Они могут называть потенциальные риски, исходя из своего прошлого опыта.
Участникам можно задать вопросы о прошлых проектах и о ситуациях, которые могут сложиться в будущем, представить описание работ, матрицу распределения ответственности, список заданий, перечень ограничений, то есть все документы, которые могут помочь им выявить потенциальные риски.
Плюсы:
возможность выявить скрытые и неочевидные риски через уточняющие вопросы
возможно нахождение неочевидных выходы и решения по преодолению
повышение вовлеченности заинтересованных лиц в процесс реализации проекта
процесс взаимодействия позволяет проверить правильность понимания всех вопросов респондентом.
Минусы
трудоемкость сбора и обработки данных
высокая стоимость и требовательность к компетенциям интервьюера и ассистентов
сложность и трудоемкость проверки качества работы интервьюеров.
Полезные ссылки:
Инструмент для системного подхода к определению фактических причин возникновения проблем и рисков.
Работа с диаграммой Исикавы проводится в несколько этапов:
Выявление и сбор всех факторов и причин, каким-либо образом влияющих на исследуемый результат / проблему.
Группировка факторов по смысловым и причинно-следственным блокам.
Ранжирование этих факторов внутри каждого блока.
Анализ полученной картины.
«Освобождение» факторов, на которые мы не можем влиять.
Игнорирование малозначимых и непринципиальных факторов.
Чтобы более эффективно выявить и добавить возможные причины в состав основных, а также более конкретно детализировать возможные первопричины ответвлений «основной кости» традиционно применяют метод мозгового штурма.
Пример диаграммы в рамках проектного управления
Плюсы
удобная визуализация причинно-следственных связей для персонала
возможность анализа цепочки взаимосвязанных причин для устранения корневых причин и проблем
не требуется высокая квалификация сотрудников, и нет необходимости проводить длительное обучение
Минусы
отсутствует четкая структура и иерархия между блоками, ранжирование блоков, что затрудняет анализ причинно-следственных связей
возможны попадания одной причины в несколько блоков
сложно исключить ошибки в составлении схемы, потому что каждый сотрудник излагает свое субъективное видение проблемы
Полезные ссылки:
Метод прямого и нисходящего логического моделирования как успеха, так и неудачи. Работает через моделирование событий через одно инициирующее.
Начиная с инициирующего события исследователи постоянно ищут ответ на вопрос "Что произойдет, если ...". Опираясь на полученные ответы, аналитик строит дерево возможных выходов. Поэтому крайне важно составить перечень всех возможных инициирующих событий.
Плюсы
Позволяет оценивать множественные сосуществующие варианты отклонений
Работает одновременно в случае неудачи и успеха
Не нужно предвидеть конечных событий
Пути в системе, которые приводят к отказу, могут быть идентифицированы и отслежены для отображения неэффективных контрмер
Может выполняться с разным уровнем детализации
Визуальная причинно-следственная связь
Относительно легко изучить и применить
Моделирует сложные системы в понятной форме
Разрешает оценку вероятности
Минусы
Для каждого ключевого события необходима отдельная схема - высокие трудозатраты на комплексный анализ
Первоначальный вызов должен быть идентифицирован и все пути проработаны аналитиком - субъективность и привязка к человеческому фактору
Уровень убытков для каждого пути не может быть различим без дальнейшего анализа
Трудно определить вероятность успеха или неудачи
Возможно пропустить малозначимые на первый взгляд факторы
Частичные успехи / неудачи неразличимы
Полезные ссылки
Дерево отказов (происшествий, последствий, нежелательных событий) лежит в основе логико-вероятностной модели причинно-следственных связей отказов системы с отказами ее элементов и другими событиями (воздействиями).
Анализ дерева неисправностей может быть использован для:
понимания логики, ведущей к нежелательному явлению или состоянию;
создания списков критических событий;
минимизация и оптимизация ресурсов;
выявления и устранения причин верхнего события, помощи в создании диагностических руководств.
Пример визуализации ниже
Плюсы
фокус на нахождении потенциальных проблемах и удобной визуализации;
метод позволяет специалистам поочередно сосредотачиваться на отдельных конкретных событиях или узких местах;
обеспечивает глубокое представление о поведении системы и проникновение в процесс ее работы;
являются средством общения специалистов, поскольку они представлены в четкой наглядной форме;
помогает дедуктивно выявлять отказы;
облегчает анализ надежности сложных систем.
Недостатки
реализация метода требует значительных затрат средств и времени: увеличение детальности рассматриваемой системы приводит к геометрическому увеличению числа влияющих событий;
дерево отказов представляет собой схему булевой логики, на которой показывают только два состояния: рабочее и нет;
трудности в анализе системных или "множественных" узких мест
дерево отказов описывает систему в определенный момент времени.
Полезные ссылки:
Все подходы ниже являются своего рода контрольными списками, или как сейчас говорят - фреймворки, которые предлагают рассмотреть риски по определённому перечню.
PESTEL-анализ или PESTLE-анализ (ранее известный как PEST-анализ) — это подход к оценке факторов или рисков внешней среды, на которые мы не можем оказывать прямого воздействия
Подход подразумевает анализ следующих факторов:
политических
экономических
социокультурных
технологических
экологических
законодательных и правовых.
Здесь необходимо оценить факторы:
социокультурные
политические
экономические
конкурентные
технологические
законодательные и правовые
неопределенность
рыночные
Ну и финальный список фокусируется на:
технических факторах
экологических
коммерческих
операционных
политических
Суть - с помощью серии последовательных действий — опросов, интервью, мозговых штурмов — добиться максимального консенсуса при определении правильного решения. Анализ с помощью дельфийского метода проводится в несколько этапов, результаты обрабатываются статистическими методами.
Метод Дельфи предполагает обобщение всех индивидуальных экспертных оценок относительно одной ситуации с тем, чтобы получить максимально надежное и достоверное общее мнение.
То есть этот метод предполагает выявление рисков, с помощью инструментов выше, а затем их оценку.
Этапы метода Дельфи
предварительный этап
основной этап
аналитический этап.
Предварительный этап
Подбор экспертной группы. Рекомендуемое количество экспертов - 20.
Основной этап
Постановка проблемы перед экспертами
Декомпозиция проблемы экспертами на более мелкие
Аналитики производят отбор самых распространённых вопросов и составляют общий опросник
Полученный опросник вновь представляется экспертам и оценка необходимости корректировки опросника
Аналитики составляют ещё один опросник
Новый опросник снова предоставляется экспертам. Теперь им нужно предложить свои способы решения проблемы и изучить альтернативные позиции остальных экспертов. Здесь производится оценка эффективности, наличия ресурсов, актуальности способов решения.
Аналитики выделяют основные мнения экспертов и стараются их сблизить. Если чьи-то мнения идут в разрез с мнением большинства, эти мнения озвучиваются экспертам. В итоге, эксперты могут изменить свои позиции, после чего данный шаг снова повторяется.
Шаги повторяются снова и снова до тех пор, пока эксперты не придут к консенсусу, и не будет установлено единого мнения. А исследование аналитиками расхождений во мнениях членов экспертной группы может указать на незамеченные до этого тонкости проблемы. В конце концов, выносится общая оценка, и составляются практические рекомендации по решению проблемы.
Аналитический этап
Проверяется согласованность мнений экспертов, анализируются полученные выводы и разрабатываются окончательные рекомендации.
Недостатки метода
Организаторы мероприятия обладают чрезмерно большими полномочиями, по сравнению с экспертами
Коллективное мнение далеко не во всех случаях является верным
Аналитики отбрасывают креативные решения, имеющие наименьшее количество сторонников, а эти решения могут быть самыми эффективными
Невозможен оперативный анализ, т.к. для осуществления последнего этапа требуется много времени: каждый этап анализа может занимать минимум до 24 часов
Эксперты склонны проявлять конформизм, испытывая желание и стремясь присоединиться к мнению большинства
Организаторы имеют возможность манипулировать экспертной группой
Полезные ссылки
К этому подходу можно отнести следующие методы:
Математическое ожидание
Дисперсия и среднеквадратическое отклонение
Оценка рыночного риска (Value at Risk)
Полудисперсия
Мы пытались понять, как описать все это доступно и понятно, но увы, мы пока не нашли подходящих способов.
Если Вам интересно погрузиться в эту тему, то воспользуйтесь ссылками ниже, здесь мы это разбирать не будем, потому что абсолютное большинство в жизни их использовать не будет.
Полезные ссылки:
И так, мы выявили все риски, оценили вероятность их наступления, тяжесть последствий. Что с эти делать?
Необходимо эту информацию структурировать и выработать стратегию по отношению к каждому из рисков и разработать план мероприятий.
Для этого существует такой инструмент, как матрица рисков. Есть упрощенная версия - 3х3, она ниже
Есть также и более крупная версия - 5х5
Соответственно из этого рождается следующий алгоритм:
для красной зоны необходимы стратегии исключения (вплоть до отказа от проекта) или делегирования (страхования). На крайний случай минимизации. Здесь необходимо постоянное отслеживание и частые обзоры
для желтой и оранжевой зон - минимизация или делегирование (страхование). Необходимо или отслеживание, или настройка ранних триггерных (спусковых) точек
для зеленой зоны вполне приемлема стратегия принятия, а реагирование
Схематический способ описания и анализа пути развития опасного события от причин до последствий. Данный метод сочетает исследование причин события с помощью дерева неисправностей и анализ последствий с помощью дерева событий.
Алгоритм построения
В центр название риска
Слева - причины возникновения риска
Справа - возможные последствия
Критически оцениваем результат и прорабатываем инструменты контроля: слева для выявления потенциальных рисков на ранней стадии, справа для минимизации ущерба от риска
Полезные ссылки:
Моделирование методом Монте-Карло
Метод Монте-Карло относится к методам моделирования различных явлений, событий, параметров или процессов, как благоприятных, так и неблагоприятных, с целью определения вероятности их наступления. Для этого генерируется определенное количество случайных величин, отвечающих установленным критериям, а затем на их основе вычисляют приблизительное значение искомой величины
Полезные ссылки:
Байесовские статистические методы используют теорему Байеса для вычисления и обновления вероятностей после получения новых данных, то есть теорема Байеса описывает условную вероятность наступления события
Математический инструмент системного подхода к сложным проблемам принятия решений.
МАИ не предписывает лицу, принимающему решение (ЛПР), какого-либо «правильного» решения, а позволяет ему в интерактивном режиме найти такую альтернативу, которая наилучшим образом согласуется с его пониманием сути проблемы и требованиями к её решению.
Анализ проблемы принятия решений в МАИ начинается с построения иерархической структуры, которая включает цель, критерии, альтернативы и другие рассматриваемые факторы, влияющие на выбор. Эта структура отражает понимание проблемы лицом, принимающим решение
Этапы
1. Выделение проблемы. Определение цели.
2. Выделение основных критериев и альтернатив.
3. Построение иерархии: дерево от цели через критерии к альтернативам.
4. Построение матрицы попарных сравнений критериев по цели и альтернатив по критериям.
5. Применение методики анализа полученных матриц.
6. Определение весов альтернатив по системе иерархии
Полезные ссылки:
И так, мы с Вами погрузились в работу с рисками. Согласитесь, большое и сложное направление, с большим набором инструментов.
В чем общая проблема всего направления работы с рисками?
Высокая сложность математических методов
Они не подходят для массового применения. Средний работник не сможет ими овладеть, а если и сможет, то объяснить и донести до высшего руководства будет практически невозможно
Высокие трудозатраты
Это касается и экспертных методов, и математических. Добавляем к этому низкое осознание проблематики и понимания статистики проектного управления, в итоге получаем, что никто не хочет этим заниматься и тратить ресурсы
Субъективность
Многие методы крайне зависимы от личности эксперта и/или аналитика. Но к чему приводит человеческий фактор и какие типовые ловушки бывают? Ответы ниже
Типовые психологические ошибки при оценке рисков:
эффект «репрезентативности» – переоценка надежности малых выборок, неслучайный характер выборки
эффект «наглядности» – переоценка «понятных», запоминающихся рисков
эффект «эгоцентризма» – ориентация на собственный опыт, а не данные
эффект «консерватизма» – жесткость сложившегося мнения о каких либо событиях
эффект «края» – недооценка высоко вероятных событий и переоценка маловероятных (при этом слишком малая вероятность может вообще не восприниматься)
эффект «Монте-Карло» – стремление установить связь между двумя последовательными событиями, в том числе это можно назвать апофенией
конформизм — это следование правилам, установкам и нормам группы, под влиянием реального или воображаемого давления
эффект Даннинга-Крюгера — когнитивное искажение, при котором люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации.
А теперь посмотрим, что мы видим в жизни? Здесь приведем результаты опроса с Телеграмм канала Михаила Софонова.
И еще раз вспомним результаты исследования Дмитрия Ирешева
В итоге как думаете, как у нас принято работать с рисками? Есть ли вообще культура работы с рисками?
Короткий ответ - нет. Мы практически никогда не видели качественной работы в этом направлении: этого либо нет, либо оно формальное.
И да, нельзя однозначно утверждать, что только из-за этого у проектного управления столь удручающая статистика, но сколько проблем можно было избежать, если бы:
на старте проекта, в стадии инициации и планирования, прорабатывались основные риски и стратегии работы с ними
в реализации проектов велся хотя бы дневник, с записями всех событий и сработавших рисков
по итогам проекта проводилось бы ревью и разбор, извлеченные уроки вносились бы в базу знаний.
К чему в итоге мы приходим ?
Во-первых появляются глобальные инициативы вроде ESG. Подробнее об этом направлении Вы можете прочитать в нашей статье.
Во-вторых начинают появляться цифровые инструменты. Мы сейчас, в 2022 году, работаем над своим цифровым советником для управления проектами. Это не трекер типа Jira и не система управления проектами типа Advanta. Это именно система поддержки и принятия решений, формирования культуры проектного управления без привязки к конкретному программному обеспечению.
Наша философия - оценка проекта, культуры, руководителя и подготовка уже конкретного гибрида с рекомендациями и сопровождением руководителя: что и когда сделать. В дополнение к этому необходимо проводить обучение в игровой и сценарной форме.
Как в целом решается вопрос проектного управления? Если мы говорим про крупные компании и корпорации, то:
Если же про стартапы и "молодые" организации, которые хотят быть Agile
Подробнее о решении в презентациях ниже
При этом уже сейчас существуют цифровые решения для оценки рисков. Например, RISKGAP. Причем это российское решение, и мы планируем интегрировать эту систему в наше решение.
О чем это решение? Ниже приведем небольшую галерею из официальной презентации системы
В чем же плюс цифровых систем?
возможность заложить сложные алгоритмы, которые среднестатистический сотрудник не сможет использовать
возможность влиять на всю систему / культуру в компании
автоматизированный учет опыта
объективность и непредвзятость
возможность отслеживания тенденций и систематизации "внешнего" опыта
В чем ключевой минус?
необходимы большие данные для качественного обучения систем - высокая сложность
недоверие пользователей / сотрудников
Проектное управление само по себе сложное направление менеджмента, которое освоено еще очень слабо. И массовое внедрение очень осложненно. А работа с рисками вообще труднодоступна среднестатистическому сотруднику или малому и среднему бизнесу, слишком сложные методики и трудоемкость. При этом и крупный бизнес, у которого есть ресурсы, не может выстроить качественную работу и в области проектного управления, и в области работы с рисками. Крупный бизнес тяготеет к реализации масштабных проектов, при этом работают там вполне обычные и, можно так сказать, нормальные люди. В итоге проектное управление и имеет печальную статистику с высокими убытками для компаний.
Наше мнение, что постепенно все придут к реализации небольших и простых проектов с использованием современных цифровых советников.
Сейчас же ключевая задача - выполнять дисциплинировано основные действия на каждой стадии проекта.
И так, чек-лист задач по управлению проектами
Для стадии инициации
Определение целей проекта (коммерческие, маркетинговые, технические, производственные, операционные) и его границ, в том числе сроков
Установка критериев успешности и целевых показателей, оценка эффектов
Оценка технической и ресурсной (деньги, технологии, компетенции) возможности реализации
Выявление ключевых заинтересованных сторон, их интереса и отношения к проекту, степени влияния
Определение ограничений проекта / ключевых рисков, в том числе вероятности наступления и тяжести последствий
Оценка необходимых компетенций для реализации проекта и состава команды проекта, организационной структуры (полномочия руководителя проекта и его граница ответственности, вовлеченность членов команды проекта)
Оценка потребности во внешних поставщиках
Оценка альтернативных способов достижения целей проекта
Определена необходимость внедрения изменений в бизнес-процессы и работу других сотрудников, возможность этих изменений
Подготовка устава проекта
Итоговая оценка целесообразности и возможности (достаточность ресурсов) реализации проекта, принятие решения о запуске проекта
Для стадии планирования
Подготовка технического задания, в котором описан продукт проекта и ключевые требования к нему и его качеству
Определение подхода к реализации проекта и поставке продукта
Определение и фиксация потребности в доработках типового решения (для проектных продаж)
Определение структуры работ (какие работы необходимы и в какой последовательности, как они взаимосвязаны)
Подготовка календарно-сетевого плана (работы разбиты по времени)
Планирование финансового и ресурсного обеспечения, определение источников этих ресурсов, подготовлен финансовый план (если необходимо)
Определение стратегии и тактики реагирования на риски
Определение зон ответственности участников проектной команды
Подготовка плана коммуникаций (кто, с кем, когда, о чем, в каком формате и виде, через какой канал коммуникации взаимодействует)
Подготовка плана внедрения изменений
Подготовка плана работы с внешними поставщиками
Для стадии реализации
Контроль исполнения плана проекта и отклонений по срокам, объемам/содержанию, бюджету
Контроль качества выполнения работ и соответствия установленным требованиям к продукту проекта
Управление ожиданиями заинтересованных сторон и промежуточные оценки проекта
Исполнение плана внедрения изменений
Ведение дневника коммуникаций
Работа с рисками и фиксация наступления незапланированных рисков. Принятие корректирующих мер до наступления негативных последствий
Для стадии завершения
Документальное оформление выполненной работы, в том числе акты выполненных работ
Оценка проекта участниками команды, руководителем проекта, клиентом / спонсором, конечным пользователем продукта и куратором
Проведение ретроспективы проекта: что реализовано хорошо, что можно было улучшить в организации проекта, какие риски и что дополнительно нужно учесть на стадиях инициации и планирования в следующий раз
Полезные ссылки
***
Мы разрабатываем собственное цифровое решение для ваших проектов. Ознакомиться с ним можно по ссылке: