Глеб Галкин
«Количественная оценка рисков не нужна, так как ИТ-проекты проходят в более-менее детерминированных условиях (по сравнению, скажем, с разработкой совершенно нового двигателя)». «Аргументированная количественная оценка рисков часто невозможна, особенно это касается организационных рисков и зависящих от внешних условий». «Детальная количественная оценка рисков займет слишком много времени (или денег) и поэтому нецелесообразна». Подобные высказывания я слышал, наверное, полсотни раз. И даже вначале верил в то, что это действительно так. Увы, жизнь жестоко наказала меня за это.
Во всех вариациях методологии управления проектами четко прописано, что риски необходимо оценивать. Конечно, делать это тяжело, особенно для не слишком дисциплинированного российского менталитета. И в начале своей работы я с радостью поверил тем, кто говорил, что количественная оценка рисков не нужна. Хотя при этом стремился соблюдать остальные правила проектного управления. В самом начале проекта для определения его содержания и границ я использовал механизм структурной декомпозиции работ проекта (WBS). И проводя с экспертами и бизнес-пользователями собрания для декомпозиции работ, я обнаружил, что могу получить более чем исчерпывающий список потенциальных рисков, совершенно не ставя себе такой задачи. Я поручил одному из сотрудников фиксировать при обсуждениях только причинные риски, не обращая внимания на комплементарные, и к получившемуся списку из более чем сорока рисков номинальная группа экспертов потом смогла добавить всего два.
Затем, отложив в сторону список рисков, я занялся составлением бюджета и плана проекта. Мой проект «тянул» примерно на полтора года, но вот с оценкой запаса или резерва времени мне пришлось туго. Обоснование необходимости резерва в одну неделю после каждого квартала работ, рекомендованное в методике внедрения приложений этого типа, руководство компании не приняло всерьез, а попытки скопировать логику распределения резервов времени из аналогичного проекта, проведённого в другой компании, просто были подняты на смех. Еще хуже закончилось обсуждение резервов бюджета проекта. Попытка обосновать управленческий резерв в 25 % чуть не свела меня в могилу. «По той же вашей статистике перерасход статьи на консалтинговые услуги в таких проектах составляет от 10 до 200 %, и вы предлагаете нам опираться на аналогичный проект, бюджет которого находится в какой-то точке в рамках этой неопределенности!?» — яростно бросил мне один из топ-менеджеров компании.
На второй раунд обоснования я пришел уже более подготовленным, проведя оценку рисков, но только качественную. И бюджет снова завернули. И только когда я, потратив почти неделю работы, количественно оценил каждый из более чем 40 причинных рисков, получил пессимистическое и оптимистическое значение стоимости проекта и вычислил стандартное отклонение, мне удалось наконец утвердить бюджет проекта. К слову сказать, бюджетный резерв даже увеличился — до 28 %, но мне не было сказано ни слова возражения.
Мораль очевидна: если не хотите краснеть на управляющем совете проекта — не тычьте пальцем в небо. Ключевые элементы управления проектами настолько сильно связаны с управлением рисками, что убрать их — это все равно что отправится в путешествие на трехногой кляче. Конечно, даже качественная оценка рисков требует времени и денег (а количественная и подавно). Как, впрочем, и всё управление проектом. Но ведь вас именно для этого сюда и поставили! А гадание на неопределенности в сроках и смете проекта может очень быстро перерасти в неопределенность вашего будущего...
