PMBoK (Project Management Body of Knowledge) — свод профессиональных знаний по управлению проектами, которые обычно считаются хорошей практикой, является Американским национальным стандартом. В нём описываются суть процессов управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат.
Источник: www.wikipedia.org/
Проектов без рисков не бывает
Изучение опыта предприятий по проведению проектов автоматизации свидетельствует о том, что у руководителей функциональных подразделений предприятий часто возникает стремление «провести проект, как все» и использовать только типовые решения, которые на слуху. Создаётся иллюзия, если «быть как все», то рисков можно избежать. Более того, при этом часто руководствуются тезисом: «Мы не какие-нибудь авантюристы, чтобы реализовывать опасные проекты. Наш проект не должен быть слишком сложным, и на нем никто не собирается рисковать. Мы хотим внедрять типовую программу типовым способом, и не намерены делать рискованных шагов».
Но возможно ли, чтобы на ход и результат проекта «как все» не оказывали влияния никакие неопределенности? Как ни парадоксально, в предельном случае — да! Но только теоретически, поскольку в жизни, в том числе и в жизни предприятия, «абсолютно безопасные» проекты никому не нужны. Как писал в своих книгах Том де Марко1Том де Марко2, «Проекты без риска — удел неудачников».
Строго говоря, проект тем и отличается от операционной деятельности, что при его выполнении создается нечто новое. Если при автоматизации предприятия до минимума урезать элемент новизны (совсем исключить не получится, поскольку внедряемая информационная система — новая, по определению), то соответственно уменьшаются неопределенности. Но одновременно снижаются возможные конкурентные преимущества, которые могло бы получить предприятие от новой системы. В лучшем случае будет реализовано то, что давным-давно работает на множестве других предприятий-конкурентов.
Означает ли это, что более рискованный проект предпочтительнее типового, поскольку больше инноваций создадут больше преимуществ? Нет, не означает! И большинство руководителей и специалистов подразделений понимают, что создавать заказную систему «с нуля» неоправданно безрассудно. Неоправданно, потому что те же самые преимущества можно получить с гораздо меньшими сопутствующими неопределенностями. А, самое главное, не факт, что новый продукт будет лучше, чем типовой, ведь можно изобрести давно изобретенный велосипед.
При выборе продукта для автоматизации (информационной системы) в рассматриваемом контексте надо обратить внимание на следующее:
- действительно ли он более инновационный и даст предприятию что-то дополнительное, чего нет в «более типовом» решении, с помощью которого ведут свою деятельность конкуренты;
- есть ли у поставщика инновационного решения готовые технологии для контроля рисков проекта.
Не обязательно, и, точнее, даже нежелательно, чтобы управление рисками воспринималось как сложный формализованный многоступенчатый процесс. На самом деле, заметки на листе бумаги или письмо по электронной почте уже могут быть частью контроля рисков. Суть не в том, чтобы «наворотить» как можно больше лишней бюрократии. Достаточно просто обозначать неопределенности, анализировать их и принимать меры по ограничению найденных угроз.
Не следует требовать от консультантов или внедренцев информационной системы: «Убедите меня, что проект будет безрисковым!». Если поставщик берется доказывать абсолютную предсказуемость всего, что может возникнуть при автоматизации, то он или лукавит, или пытается продать «типовой проект для неудачников». Более целесообразно, не стесняясь, высказывать все свои опасения относительно рисков и выяснять, есть ли у поставщика реальный опыт снижения проектных неопределенностей на других предприятиях.
Соответственно, приоритет в выборе продукта-прототипа и партнера для внедрения лучше устанавливать не по иллюзиям «самого безрискового проекта», а по информации об успешной практике контроля рисков.
Хорошие руководители проектов умеют определять и планировать задачи, которые необходимо выполнить для реализации проекта. Но только лучшие руководители проектов успешно справляются с тем, чтобы определить и создать резерв ресурсов под задачи, которые вдруг могут возникнуть в ходе проекта.
Советы и способы расчета рисков
Консультанты и специалисты по автоматизации постоянно совершенствуют проектные технологии и вводят в практику выявление рисков предстоящего проекта. Многие руководители, особенно не имеющие проектного опыта, недоумевают: «Откуда мы знаем, какие задачи могут внезапно возникнуть на проекте в будущем? Как можно угадать, с чем придется бороться?!»
Понятно, никто не может запросто заглянуть в будущее. Но одно из необходимых качеств менеджера заключается в умении прогнозировать развитие событий на основе той информации о неизвестном, которая уже имеется, пусть даже это всего лишь крохи данных и обрывки сведений. Тем более, что руководителю проекта не надо изобретать и составлять с нуля новый исчерпывающий список рисков на каждый новый проект автоматизации. Можно использовать имеющуюся статистику по наиболее распространенным и значимым рискам проектов автоматизации и наложить на нее свои накопленные данные. Так, среди возможных рисков могут быть:
- невозможность выполнения требований (спецификаций проекта) имеющимися инструментами;
- возникновение кадровых проблем;
- изменение требований к системе в виду объективных обстоятельств.
Есть еще риски, которые проявляются реже, но их следует упомянуть, это — планирование нереальных сроков под давлением владельцев проекта и снижение производительности исполнителей в ходе работ.
Если предпосылки к «давлению» или «снижению» уже имеются, то они обычно не слишком замаскированы, и их можно идентифицировать в самом начале проекта. Иными словами, тут чаще сталкиваются не с неопределенностью проекта, а с вполне определённым отсутствием проблемы либо с заведомо известным её наличием.
Далее перечисленные статистические неопределенности и риски надо наложить на свой опыт, то есть, проанализировать практику ранее выполненных проектов — насколько часто риски реализовывались и к какому дополнительному расходу ресурсов приводили (обычно под ресурсом можно понимать деньги и время).
Если у предприятия нет своей накопленной практики, не беда. В любом случае общеотраслевая статистика уже задает руководителю проекта более конкретное направление для размышлений. Ему не нужно гадать, «какие неприятности вообще возможны на проекте ААА, и каких дополнительных ресурсов они могут потребовать». Вместо этого у него уже есть «система координат», и вопросы сводятся к более предметным, например: «какой резерв времени нужно добавить для нейтрализации возможного увольнения одного из специалистов?».
Очевидно, что заложить в проект запас времени по всем возможным рискам в предположении, что они все реализуются сразу, будет полярной крайностью, поскольку делает проект избыточно затратным. Одинаково безрассудно из диапазона всех неопределенностей взять как нулевые точки, так и сложить все максимумы.
В теории рекомендуется добавить к планируемым ресурсам резерв, рассчитанный как математическое ожидание неопределенности по формуле:
Дополнительный резерв = Вероятность Риска 1 * Затраты по Риску 1 + Вероятность Риска 2 * Затраты по Риску 2 + ... + Вероятность Риска N * Затраты по Риску N,
где N — количество рассматриваемых рисков.
На практике вычисления часто упрощают, вводя среднестатистическую вероятность для каждого риска в размере 15-25%. Конечно, это большое допущение, но в любом случае оно лучше, чем зависимость от крайностей.
Стоит упомянуть и про альтернативные стратегии работы с неопределенностями. Так, создание резерва ресурсов для выправления последствий одного или нескольких реализовавшихся рисков — одно из направлений контроля, которое называется сдерживанием рисков. Кроме создания страхового запаса средств на восстановление хода проекта после реализации риска (сдерживание риска) — возможно применение стратегии ослабления риска. В этом случае компания несет затраты до возможного проявления риска, с тем чтобы если риск реализуется, то его последствия обошлись дешевле.
Если обратиться к языку формул, то под последствием имеется в виду упомянутое выше математическое ожидание:
Вероятность Риска * Затраты по Риску
То есть «предоплата» за ослабление риска может снизить как вероятность его возникновения, так и снизить затраты на исправление ситуации, если неприятность все же случится.
И третья стратегия работы с неопределенностями — избегание риска. В этом названии, разумеется, нет эмоциональной негативной окраски: это инструмент, который иногда целесообразно использовать, а иногда — нет. Этот вариант контроля неопределенностей заключается в том, чтобы вообще не выполнять какой-то из этапов проекта, на котором риски неудачи слишком велики.
Например, некоторое время назад в типовых продуктах системы «1С:Предприятие» не все задачи сложного производственного планирования решались оптимальными методиками. И предприятия, заинтересованные в автоматизации планирования, ограничивались только внедрением только учетных функций, поскольку неопределенности в затратах и сроках достижения результата были высоки. Сегодня использование новых разработок позволяет автоматизировать производственное планирование даже в сложных процессных отраслях промышленности. Поэтому стратегия избегания риска в этом контексте перестала себя оправдывать.
Можно отметить и такие стратегии, как сдача риска, трансферт риска, передача риска, страхование риска, делегирование риска и т.д. В управлении проектами они сегодня мало используются.
Таким образом, контроль рисков проекта и управление ими подразумевает не только констатацию факта наличия неопределенности и рисков, но и анализ их последствий, что, свою очередь, позволяет заранее спланировать дополнительные ресурсы и выбрать соответствующую стратегию.
Чтобы оставить комментарий пожалуйста Авторизуйтесь