8.3.Профилактика и как бороться с проявлениями рисков

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

Народная мудрость о профилактике рисков: «Кабы знал, где упасть, так соломки бы подостлал».

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

• определить триггеры для управляемых рисков (критерии и симптомы срабатывания);
• составить план действий по ослаблению для каждого риска;
• назначить ответственных за управление рисками в целом и/или по каждому риску в отдельности.

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

• устав проекта – задает регламент управления рисками проекта;
• отчет о состоянии проекта – регулярно составляется и имеет раздел текущих проектных рисков;
• журнал рисков – сводный перечень рисков как часть отчета о состоянии проекта;
• карточка риска – каждый значимый риск описывается отдельно.

«Врага нужно знать в лицо» – в нашем случае возможные риски нужно заранее хотя бы проговорить, зафиксировать и учесть в планировании работ. Если сформулированы возможные риски проекта, оценены их вероятность овеществления и степень воздействия на проект, то можно рассчитать, какой резерв (сроки, финансы, персонал, дополнительные командировки, оборудование и т. д.) нужно заложить в проект, чтобы минимальными усилиями предотвратить и/или устранить последствия рисков.

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

Даже в гибких методиках есть риск-менеджмент, но он идет сессиями по принятым квантам разработки, а не целиком на весь проект.

Управление рисками осуществляется за счет использования:

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

Согласно PMBOK, возможны четыре метода реагирования на риски:

• уклонение от риска;
• передача риска;
• снижение риска;
• принятие риска.

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

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

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

Частый пример такого подхода в ИТ-проектах, даже для fixed price проектов, – переложить риск на заказчика. Это достигается за счет следующих возможностей:

• обосновать, что нужен отдельный бюджет на предпроектное обследование, в котором найдутся ответы на неизвестные вопросы (технические, организационные, методологические), и как следствие – риск неопределенности перестанет существовать;
• составить перечень рисков, сделать их оценку и в явной форме озвучить заказчику, что в случае наступления определенных событий потребуется дополнительный бюджет на проект. Если следовать здравой логике, то заказчик должен оставить резерв на известные риски. Исполнитель может явно прописать в договоре критерии увеличения бюджета проекта или заложить такие риски сразу в бюджет проекта (что даже выгоднее исполнителю, но не заказчику, так как бюджет вырастет, а риск может не сработать).

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

Так, например, раннее решение архитектурных задач (проектируем архитектуру решения до начала активной разработки) существенно снижает технические риски. Регулярная демонстрация промежуточных результатов заказчику может снизить вероятность риска его неудовлетворенности конечным результатом. Если в проектной команде высокая текучка сотрудников, то введение на начальной стадии в проект дополнительных (избыточных) людских ресурсов снижает потери при увольнении некоторых членов команды, поскольку не будет затрат на адаптацию новых участников и риска задержки работ.

Принятие риска означает, что команда проекта осознанно приняла решение не изменять план проекта в связи с риском или не нашла подходящей стратегии реагирования на него.

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

• Срочность. Период времени, в течение которого меры реагирования на риск должны быть осуществлены, чтобы они дали ожидаемый результат. Короткий период показывает высокую срочность.
• Близость. Период времени до того, как риск может оказать влияние на одну или несколько целей проекта. Короткий период показывает высокую степень близости.
• Латентность. Период времени, который может пройти после наступления риска до обнаружения его воздействия. Короткий период показывает низкую степень латентности.
• Управляемость. Насколько просто владелец риска (или организация – владелец риска) может управлять наступлением или воздействием риска. В случаях, когда управление не представляет особой сложности, степень управляемости является высокой.
• Контролируемость. Степень, в которой владелец риска (или организация – владелец риска) способен контролировать последствия риска. В случаях, когда контроль последствий риска не представляет особой сложности, степень контролируемости является высокой.
• Выявляемость. Насколько просто можно выявить и опознать признаки наступления или высокой вероятности наступления риска. В случаях, когда наступление риска можно обнаружить без особого труда, степень выявляемости считается высокой.
• Сопряженность. Степень, в которой риск связан с другими индивидуальными рисками проекта. В случаях, когда риск связан с несколькими другими рисками, степень сопряженности является высокой.
• Стратегическое воздействие. Потенциал риска оказать позитивное или негативное воздействие на стратегические цели организации. В случаях, когда риск может оказать значительное воздействие на стратегические цели, степень стратегического воздействия является высокой.
• Восприятие. Степень значимости риска с точки зрения восприятия по крайней мере одной или несколькими заинтересованными сторонами. В тех случаях, когда риск воспринимается как очень значительный, его восприятие считается высоким.

Далее рассмотрим несколько ситуаций, которые возникают на практике, и то, как бороться с такими рисками.

Срывы сроков – как с ними бороться?

Том ДеМарко в своей книге утверждает: «У проекта должно быть два срока сдачи: запланированный и желаемый. Эти сроки должны быть разными».

Полезным инструментом руководителя проектов со стороны исполнителя для минимизации рисков затягивания сроков является использование разных оценок сроков и дедлайнов (дат, когда все должно быть готово):

• для руководства заказчика – на уровне договора фиксируется пессимистичный срок;
• своего руководства (исполнителя) – озвучивается реалистичный срок;
• для команды проекта (конечных исполнителей) – задается оптимистичный срок как целевой.

Оптимистичный целевой срок работает как часть мотивационной схемы и не дает по закону Паркинсона («работа занимает все выделяемое на нее время») впустую тратить сроки проекта. Резерв на риски будет реальным резервом для команды, а не запасом для неспешной работы с первого дня по принципу «времени много, успеем», но уже без возможного запаса, когда в последний момент никакие усилия не позволят доделать задачу в срок.

Для борьбы за соблюдение сроков нужно вводить контрольные сроки на согласование документов. Прописывать их в уставе проекта (можно разные в зависимости от типа документа). Иначе заложенные, например, 3 дня на согласование технического задания заказчиком «пролетят», и заказчик может не выдать документ, а срок проекта «поедет» от этого у исполнителя (нельзя начать разработку без согласования ТЗ). Любые срывы сроков нужно считать в обе стороны (не только исполнитель затягивает свои задачи, но и заказчик тоже). Наличие контрольных сроков по документообороту проекта стимулирует сотрудников заказчика не откладывать задачи проекта на потом. Ведь все задержки будут учтены и могут в результате сдвинуть срок проекта на сумму таких задержек без санкций исполнителю за провал сроков. Ну, или по крайней мере у исполнителя появится рычаг воздействия, если сроки «поплывут» (по разным причинам), но уже не только по вине одного исполнителя.

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

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

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

В части согласования и утверждения документов есть риск «включить заднюю передачу» («я этого не согласовывал!») – он снимается прописанным в уставе проекта форматом утверждения документов и их защиты. Если реальные подписи на бумажных документах не всегда удобны (много бумаги, удаленно документы сложно подписывать), то можно использовать цифровые подписи.

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

Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов. Нужно следовать принципу: «Мы находимся по одну сторону баррикад. По другую сторону находится сама проблема».

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

• если овеществился «риск заказчика», то деньги за проект не дополучит исполнитель;
• если овеществился «риск подрядчика», то больше денег за проект заплатит заказчик за устранение последствий (или замену подрядчика);
• если овеществился «риск субподрядчика», то отвечать за результат перед заказчиком будет подрядчик (основной исполнитель).

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

В известной сказке только маленький мальчик (без груза ответственности и обязательств) рискнул выкрикнуть: «А король-то голый!» Тогда как все придворные и даже народ боялись санкций за такую правду.

Если руководитель проекта утверждает, что есть лишь 10 %-ная вероятность сдать проект в желательный заказчику срок, то он предоставляет возможность компании-конкуренту сказать: «Поручите это нам, и мы все сделаем вовремя». Поэтому пагубная практика тендеров на понижение сроков и ставок встречается в нашей жизни, а что при этом закрываются глаза на риски или вообще проектные методологии, вторично. Но такие проекты редко становятся успешными и достигают всех изначальных целей в заявленные сроки, бюджет и при должном качестве.

Рассмотрим практический пример риска коммуникации между исполнителем и заказчиком по срокам проекта подробнее.

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

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

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

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

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

Профилактика этого риска – в планировании привлечения специалистов на конкретные задачи, свои на разных фазах проекта: динамический состав участников.

Сработанность и эффективность команды – важный фактор успеха (или неуспеха) проекта внедрения ERP-системы. Рекомендации, которые дает Том ДеМарко в книге «Deadline. Роман об управлении проектами»:

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

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

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

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

• В команде специалисты описывают разные блоки, но все хотят поменять, например, справочник «Договоры». При этом хотят изменить по-разному (закупщикам и продажникам нужно разное) – это противоречия на уровне требований заказчика, но это может пройти, т. к. занимаются разные специалисты исполнителя.
• Нужно сводить все изменения воедино, и системный архитектор должен проверить их на непротиворечивость. Если противоречия есть, то ключевые сотрудники заказчика должны договориться между собой (работа с требованиями и ключевыми сотрудниками), и только потом систему настраиваем и модифицируем под сводные требования.
• Если эту работу не проводить, то проблема выявится на уровне разработки или еще позже, в процессе эксплуатации.

Бывают конфликты внутри организации заказчика – например, бухгалтерия против ERP-системы как небухгалтерской парадигмы учета, потери монополии влияния на учет (на первую роль выходят оперативный контур и первичные документы, которые вводят «небухгалтеры»). Этот тот самый конфликт интересов, который был описан в первой главе. Профилактикой этого риска может быть разъяснительная работа, мотивирование сотрудников, возможность настройки контроля (аудита) всех вводимых менеджерами документов, которые попадают в бухгалтерский учет, закрытие периода и конкретных проверенных документов от изменений или контроль за этими изменениями. В 1С:ERP есть специальное рабочее место для бухгалтера, где можно проверять и защищать от изменений документы, вводимые всеми остальными «небухгалтерами», – его демонстрация на ранних фазах проекта снимает негативное отношение к проекту у бухгалтеров, переводит их в ряды защитников проекта, т. к. система предоставляет им много полезного для ведения регламентированного учета, и компромиссы достижимы.

Эффект от проводимой профилактики рисков при видимой трате усилий (ресурсов в лице руководителя проекта) на эту задачу окупается экономией трудозатрат. Например, для проекта с командой в 10 человек расходы на управление рисками составят условно 40 человеко-часов в месяц. При этом будут идентифицироваться около 20 потенциальных или сработавших рисков текущего периода и состояния проекта. Из этих рисков минимум 5 самых важных будет подавляться комплексом мероприятий. Исходя из того, что критичный риск отбирает у проекта минимум 40 человеко-часов дополнительных усилий на переделки, исправления, доработки, то получаем от 200 человеко-часов экономии ежемесячно. Таким образом, отношение усилий на мониторинг и контроль рисков к положительной экономии усилий команды проекта явно в пользу проведения работ над рисками. Это лучше, чем получить небольшую экономию времени и бросить все на самотек, что может (и это обязательно произойдет) привести к задержкам проекта, конфликтам и общей неудовлетворенности процессом или результатами работы.

Отправить