Меню

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

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

Еще один критерий – величина риска. Например, стратегические, релевантные. Пример – срыв сроков запуска продукции, которая необходима рынку. Это важнее для развития бизнеса, чем мелкие промашки и недочеты.

Эксперты могут сформировать классификацию рисков для вашей компании – если это сделать правильно и структурированно, вы получите большое количество информации. Прежде всего, это матрица рисков, позволяющая их визуализировать. Но сделать это в одиночку невозможно, над этим должна работать команда. Часто обсуждается: правильно ли использовать матрицу для этого? Я считаю, что она очень эффективна, потому что гораздо проще таким образом риски зафиксировать, показать руководству и понять, что за этим стоит. Это простой, но наглядный инструмент.
Когда вы видите структуру рисков, то начинаете с самых важных. Для фиксации рисков мы используем Excel. Вы можете, естественно, составить и свой собственный документ в формате Word. Эта документация проста в использовании, и она работает. Если она работает, значит, надо ею пользоваться.

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

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

Рекомендация
  1. Даже если кто-то говорит, что решение не будет работать, и учтите его мнение и попытайтесь проанализировать, почему он так считает. Есть люди разные: оптимисты, пессимисты. Бывает, что кто-то расстроен. Все мы – люди, в жизни и в любом проекте. Риск часто воспринимается некоторыми более оптимистично, а некоторыми менее. Воспринимайте людей не буквально, а серьезно.
  2. Когда мы говорим о рисках, мы не ищем правых и виноватых. Мы используем нейтральный подход. Это самый лучший вариант, чтобы оценить риски.
  3. Будьте конкретны. Уточните, какова вероятность риска, получите информацию, которой у вас не было раньше. Называйте проблемы конкретными словами, и используйте факты, которые не должны, кстати, разглашаться – соблюдайте конфиденциальность.
  4. Задействуйте всех сотрудников, имеющих достаточное влияние и опыт работы над минимизацией таких рисков в предыдущих проектах. Это не всегда просто сделать, но когда вы так поступаете, благоприятный исход гораздо более вероятен.
  5. Фокусируйтесь на тех рисках, на которые вы можете повлиять. Если вы не можете повлиять на риск, чего, собственно, напрягаться. Лучше браться за то, на что вы можете повлиять.
  6. После идентификации рисков определите, кто будет отвечать за меры по их устранению. Очень трудно найти такого сотрудника: чаще всего люди зависят друг от друга, и никто не хочет брать на себя конечную ответственность. Нужно искать людей, которые отвечают за бюджет, которые отвечают за проект непосредственно.
  7. Иногда приходится проявлять некий волюнтаризм, давить на людей, волевымрешением назначать ответственных за ликвидацию рисков. Им поначалу это не нравится. Но когда они справляются с ситуацией успешно, они начинают этим гордиться, им это очень нравится.

Как устранять риски?

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

Проводите исследования и снижайте последствия возникающих рисков. Здесь возможны разные методы:

  1. Делегирование рисков: например, с юридическим риском должен работать юридический отдел. Они эксперты, они знают, как разобраться с ситуацией. Это очевидно.
  2. Передача риска. Например, покупка страхового полиса – это передача риска страховой компании. Пусть она с ним разбирается.
  3. Снижение вероятности наступления риска. Это самое важное. То, что риск в принципе есть – не так страшно. Первый шаг: согласитесь с риском. Это вполне нормально. Зная, какие риски есть, мы можем принять все меры к их снижению.
  4. Управление рисками заключается не только в уменьшении рисков. Они все равно наступают. Другое дело, как быстро вы можете от них оправиться и снова продолжить работу. Подумайте о ЦОД – центр обработки данных. Один ЦОД ломается, но есть второй – запасной, который может на себя взять резервную нагрузку.

Есть известный видеоролик о рынке в Таиланде – территорию этого рынка буквально прорезают действующие железнодорожные пути. Когда поезд проходит, торговцы убирают свои лотки, но как только он прошел – они все ставят на место и продолжают работу. На все изменения уходит меньше 30 секунд. Многие торговцы даже не убирают свои товары – они расположили их в непосредственной близости от путей, но так, что поезд их не задевает.  Они продумали, как минимизировать риск. Это очень важный урок, который мы можем усвоить при управлении рисками.

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

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

Инструментарий для управления рисками

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

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

После этого мы определяем того, кто будет реагировать на риск - владельца этого риска. Обязательно должен быть кто-то, кто будет реагировать на возникшие риски, и не обязательно, что этот человек – сотрудник организации. Хотя, конечно, проще, когда этот человек находится внутри компании. Его роль – утвердить, взять на себя ответственность, признать наличие риска и его важность.

Мониторинг рисков

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

Пример: вам выданы ноутбуки для решения тестового задания. Но не у всех есть пароль, поэтому мы не можем начать все одновременно. Мы ждем коллегу, который может сообщить пароль, так как только он его знает. То есть, как и в реальном проекте, есть человек, который является владельцем рисков, и его помощники – те, кто помогает ему оценивать риски.

Будем анализировать разные параметры – насколько они являются рисками. Первый параметр: выручка компании - 800 миллионов евро. Влияет ли этот показатель на ваш проект? Исходя из моего опыта, это не влияет на проект. Размер компании не влияет непосредственно на результат внедрения. При оценке рисков очень важно выбрать важную информацию  и отсеять несущественную.

Второй параметр: в проекте участвуют 100 человек, 50 из них – младшие сотрудники. То есть они недостаточно опытны. Влияет ли это на результат проекта? Зная, что проект длится год, вы можете попытаться прикинуть, сколько зарабатывают сотрудники разных категорий, и получить цену реализации проекта. Допустим, получается 1 миллион евро. Это база для того, чтобы посчитать риски: этот миллион вы потеряете, если проект не осуществится. Представьте себе, что на 10% увеличивается благоприятный исход. 100 тысяч евро. Это то, что вы можете сэкономить, изменив лишь на 10% благоприятность исхода. В этом заключается основная мысль.

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

Используется  решение сторонних производителей. Например, техническая инфраструктура сторонних производителей. Что будет, если эта третья сторона не предоставит свой продукт? Какие риски? Что, если ваша сеть не будет работать? Какие риски вызовет отсутствие надежной работы платформы?  

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

И еще – такие аспекты, как соответствие стандартам безопасности, юридическим стандартам и так далее. Это риск или просто требование?

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

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

Главное, сделать ситуацию понятной и прозрачной для руководителей компаний. Руководство примет решение: либо выделит дополнительные средства либо сохранит ограничения, и вам придется работать с их учетом или увольняться. Нужно ли перекладывать этот риск на тех, кто владеет бюджетом? Те, у кого бюджет, отвечают за риски, как правило. Если вы несете ответственность за проект, и у вас есть бюджет, хоть и ограниченный – вы должны решать, будете ли браться за эту задачу в таких условиях. Об этих вещах можно договариваться. Как раз для этого нужны владельцы рисков. Иногда есть внешние силы, которые вы не можете контролировать. Придется с этим смириться. Либо же сделать что-то, что позволит вам достичь успеха даже в этих обстоятельствах.

Создайте оценку рисков, обозначьте риски, сделайте их видимыми, это поможет вам. Даже если вы начнете думать об этом более пристально, вы уже будете минимизировать риски, потому что подсознательное помогает здесь сознанию. Люди говорят: нам нужно еще добавить сто человек в команду, иначе успеха не будет. Естественно, руководителям такие меры совсем не нравятся. Как это, добавить еще сто человек в команду? С такими вещами приходится считаться и не искать оправданий. Попытайтесь решить вопрос.

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

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

Возвращаясь к нашей задаче, можно выделить такие риски:

  1. Одновременное проведение трех инсталяций, то есть запуск системы сразу в трех местах. Может не хватить ресурсов. Владельцем этого процесса является руководитель проекта, и уровень риска будет средний.
  2. Поставка оборудования внешним поставщиком – рисками являются сроки и качество работы поставщика. Ответственный здесь – поставщик.
  3. Софтверный риск - смена операционной системы. Если текущая операционная система несовместима, это вызовет дополнительные работы, соответственно, сроки проекта могут увеличиться.
  4. Дополнительный риск - невыполнение наших договорных обязательств. Это юридический риск, возможны финансовые потери. Владельцем этого всего будет, конечно, финансовый директор. Кроме того, репутационные риски может понести компания. Это единственное, что мы новенького смогли бы добавить.
  5. Госстандарты - если будет обнаружено несоблюдение, это вызовет дополнительные работы и сдвиг сроков проекта. Владельцемь может быть юридическая служба, юридические подразделения.
  6. Несоблюдение бюджета. На каждом проекте этот риск есть, от него никуда не уйдешь, и при его обнаружении мы должны будем провести определенные действия – собрать проектные комитеты, чтобы утвердить новый бюджет, или скорректировать объемы работ.  Владельцем здесь,  скорее всего, будет руководитель проекта и руководитель организации, в которой проект ведется. Нас сильно озаботило количество специалистов. 50% из них – необученные специалисты, то есть вполне возможно, на проекте не хватит квалификации. Вполне возможно, что, когда поплывут сроки, мы начнем закупать более дорогих специалистов. Второй риск –  соответственно, сроки проекта. Хорошо бы, чтобы владельцем был наш директор по персоналу, и вовремя бы нам помог.
  7. Команда - один из самых больших рисков, который в задаче не звучал, но на проектах всегда возникает: смена специалистов команды в ходе проекта. Его возможные последствия - дополнительные расходы и изменение сроков.

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

Вероятность обнаружения ошибки остается той же самой, просто мы обнаружим эту ошибку раньше. У нас появится лишнее время на исправление. Поэтому мы уменьшаем последствия.

У нас было два серьезных риска. Это квалификация персонала – много необученных специалистов, и смена команды, то есть уход. Как бороться с этими рисками?

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

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

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