Типичные ошибки при оценке ИТ-Проектов. Оценка рисков

Типичные ошибки при оценке ИТ-Проектов. Оценка рисков

Ошибки управления рисками в ИТ-проектах

Риск нарушения методологии ведения проекта

Это, пожалуй, первый и самый большой риск, с которым мне пришлось столкнуться. Его выявили не на стадии планирования проекта, а уже в процессе работы. Большой и непростой проект состоял во внедрении ERP-системы SAP R/3 на предприятии, оказывающем сервисные услуги. Объем проекта был достаточно велик, внедрялось пять модулей – FI, MM, CO, SD и CRM. Выявленный риск состоял в том, что проект велся не по методологии ASAP.

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

Понимая все это, мы в начале проекта решили некоторые документы просто не делать, пропустить. И все были согласны – компания-внедренец пошла нам навстречу, потому что считала, что проект маленький. Менеджеры финансового и коммерческого департаментов то же самое считали – “зачем нам это все надо, и так понятно”. Ведь в принципе кампания небольшая, около 500 сотрудников, все и так в курсе происходящего. У нас было налажено управление рисками этого проекта, но на такой риск – вообще говоря, считающийся типовым и входящий в стандартный список рисков ИТ-проекта, – никто просто не обратил внимания.

Все это продолжалось до стадии настройки системы, пока вдруг один из менеджеров не заметил: “Посмотрите, у нас ведь финансовый модуль настраивается чуть ли не на глазок, мы ведь не продумали на стадии концептуального проектирования вот эти и эти вопросы”. Подняли документацию, посмотрели и увидели, что на самом деле это именно так. После этого было принято решение вести весь проект по методологии ASAP. Но потери от риска были огромными – мы вынуждены были сразу израсходовать почти половину, 3% средств, из 10% резерва в бюджете этого проекта. В результате, когда сыграли три других риска, нам не хватило средств, выделенных в этом резерве. Бюджет проекта был превышен. Мы вынуждены были выделить дополнительных 30 человеко-часов на переделку сделанного и пересмотреть ожидаемые сроки сдачи проекта почти на полтора месяца. Вот цена некачественного управления рисками.

Риск недостаточной заинтересованности менеджеров

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

В нашем перечне рисков мы учитывали риск недостатка времени у функциональных менеджеров. Например, конкретный менеджер должен согласовать схему бизнес-процессов, но он ведь может заболеть, уехать в командировку или в отпуск. А кроме него это сделать никто не может. Этот риск был выявлен и оценен. Его вероятность согласно экспертной оценке была средней (около 0,3), влияние на бюджет – минимальным. Но он оказывает среднее влияние на сроки и существенное влияние на качество решений. Поскольку общая величина риска была значительной, то для его минимизации были приняты определенные меры. Но риск того, что нам не удастся в достаточной степени заинтересовать функциональных менеджеров, учтен не был. Тем не менее он сработал, и при утверждении концептуального проекта нам пришлось потратить дополнительно несколько дней на его устранение. Оценка ущерба от него – несколько дней работы руководителя проекта (что эквивалентно 20-30 тыс. долл.), которые я теперь непременно закладываю в график каждого ИТ-проекта.

Риск неверного технического решения

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

Конечно, посчитать конкретную величину этого риска невозможно. Как оценить то, что на этапе проектирования принято на 5% неоптимальное решение? Так, при настройке ERP-системы и реализации бизнес-процессов в ряде случаев могут быть выбраны разные варианты, каждый из которых по-своему близок к оптимальному и имеет свои риски. Мы учитывали, что этот вариант решения имеет такие-то риски, а этот вариант – такие-то. Но оценить их величину было невозможно. Поэтому мы прибегли к опыту проектов в западных странах. Как правило, этот резерв составляет от 10 до 20% стоимости проекта и от 5 до 10% резерва времени. Кроме того, мы минимизировали риски, прибегнув к многошаговой процедуре утверждения проектного решения, но не привлекали внешний аудит.

Однако принятых мер оказалось недостаточно: риск сработал, и где-то на середине проекта мы увидели, что проектное решение неверно. Само по себе это не так страшно, но в нашем случае мы имели дело с чрезвычайно инновационным проектом – реорганизацией и оптимизацией работы крупного склада посредством технологии RFID и соответствующего ПО. Такие проекты в то время (пару лет назад) были еще в диковинку, опыта не накопилось, а у компании, с которой мы проводили внедрение, это вообще был первый подобный проект. В определенной степени они учились на этом проекте. Мы понимали это и потребовали повышенного внимания к этому проекту с их стороны, и они на это пошли, но мы недооценили этот риск.

В результате технического анализа оказалось, что решение неверно и его надо переделывать почти на 50%. Никакие 10% резерва денег и времени, которые мы выделили на этот риск, не смогли его компенсировать. Бюджет проекта был превышен почти на 250 тыс. долл. (около четверти бюджета проекта), а сроки перенесены на три месяца (треть времени проекта). Такова цена недооценки степени инновационности проекта.

Читать еще:  Как создавалось первое кадровое агентство в России

Риск снижения производительности

Следующий риск также присутствует во всех списках типовых рисков ИТ-проекта. Известно, что при запуске в продуктив новой ERP-системы или бизнес-приложения производительность всегда будет падать. Система новая, и как бы мы ни тренировали сотрудников, они привыкли работать со своими процессами в своей старой системе. А с изменениями снижается темп работы – например, уменьшается отгрузка продукции и соответственно доходы компании. К сожалению, это объективно, с этим надо мириться. Конечно, производительность потом вырастает, но при запуске она объективно падает. Понимая это, мы приняли данный риск и оценили его.

При планировании проекта нужно принять решение, как запускаться. Когда мы планировали проект, то оценили степень падения производительности примерно в 10% (это была экспертная оценка, основанная на опыте аналогичных проектов). Исходя из этого была назначена определенная дата пуска системы. Но когда мы провели некоторые подготовительные мероприятия к запуску системы на более мелких объектах и отследили тенденцию снижения производительности, то насторожились. Оказалось, что ожидаемое снижение производительности существенно выше – 20-25%. Мы доложили эту информацию руководству. Ответ был такой: “Если мы сейчас запускаем систему на наиболее важных для бизнеса объектах, то наши доходы серьезно падают, мы теряем конкурентное преимущество. Это очень большой риск для компании, и мы не можем на это пойти. Необходимо сначала разработать превентивные мероприятия по снижению этого риска. Сколько вам нужно времени, чтобы полностью решить эту проблему?” – “Год”. – “Тогда давайте перенесем запуск системы на год”.

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

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

В-третьих – возникает риск изменения бизнес-процессов. Если мы работаем на проекте автоматизации процессов некоторой бизнес-единицы, которая имеет некоторый организационный цикл, то изменение процессов этой бизнес-единицы во время хода проекта должно быть в пределах 10%. Мы должны, в некотором смысле, ситуацию замораживать. Это требуют все методики внедрения бизнес-приложений. И это оправданно. Поэтому такие системы, как ERP, все-таки должны ставиться на более-менее устойчивую организационную структуру. Допустим, мы знаем, что в этой операционной единице больших изменений не предполагается, то есть бизнес работает, приносит доход, но нас не устраивает, как он организован на уровне информационной поддержки. Тогда мы начинаем проект по автоматизации бизнес-процессов этой единицы.

Увеличение срока проекта на год – очень серьезное изменение “замороженного” периода. Появляется огромный риск, что за это время изменится операционная и организационная структура. В результате проектное решение нужно будет пересматривать. Таков основной риск при затягивании проектов внедрения бизнес-приложений. В результате, если переносить запуск на год, возникает риск, что мы вообще не запустим систему и поставленная цель проекта вообще не будет достигнута. Это очень большой встречный риск.

Все эти риски были изложены на руководящем комитете проекта. И решение, которое мы приняли, было компромиссным. Мы договорились перенести запуск не на двенадцать месяцев, а на пять. За это время уточнить стратегию перехода, сделать очень четкий детальный план с контролем, с мониторингом, аккуратно проанализировать все риски и т. д. И это решение было абсолютно правильным: в результате мы запустили систему с небольшим уменьшением производительности на 7%. Какова была стоимость риска недооценки падения производительности? Детальный отчет мы не составляли, но отодвигание срока запуска на пять месяцев потребовало увеличения бюджета проекта на 30%.

Типичные ошибки при оценке ИТ-Проектов. Оценка рисков

Часть 1 Проблемы оценки ИТ-Проектов

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

Итак, первая ошибка заключается в том, что, как я уже говорил, правильно оценить проект без понимания требований в принципе невозможно.

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

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

Вторая ошибка – это полагаться при оценке только на сформулированные заказчиком требования.

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

Читать еще:  Что такое хаусситтинг?

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

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

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

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

И обратная ситуация – когда оценка ведется только силами технических специалистов.

Дело в том, что, как правило, программисты склонны переоценивать свои возможности, и это, скорее всего, будет недооценка. А руководитель отдела разработки, наоборот, склонен закладывать в оценку слишком большие риски, перестраховываться – может получиться переоценка. Поэтому здесь правильнее создавать симбиоз менеджера по продажам с техническими специалистами. Кстати, есть такая статистика – чистое время программиста, которое ему требуется для реализации задачи можно помножить на 3-3,5 раза. Получится реальная трудоемкость от постановки задачи до ее передачи пользователю (куда войдет тестирование, обучение и пр.).

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

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

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

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

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

    • Причем, чем больше заказчик, тем таких моментов больше.
    • Особенно, если это госструктура – там до 50% времени может занять только процесс управления бумажками и прочей бюрократией. И к этому нужно тоже относиться внимательно.

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

    • Команда не будет так никогда работать, потому что, во-первых, все люди – они могут потеряться, уволиться и т.д.
    • Есть вынужденные перерывы, например, когда заказчику может потребоваться время на осознание и согласование каких-то промежуточных этапов. Все это будет растягивать процесс.
    • Даже если программисты будут работать в штатном режиме, вряд ли они будут программировать все 8 часов. Поэтому не рекомендуется закладывать на выполнение какой-то конкретной работы более 60% рабочего времени.
    • Нельзя просто так – если вы, допустим, посчитали трудоемкость 100 часов, перевести это в рабочие дни и сказать, что проект будет выполняться столько. Ну не будет он столько выполняться.

    Как говорится, в проектном управлении есть такая маленькая шутка – следствие закона Мерфи: «Если в проекте что-то может пойти не так, оно обязательно пойдет не так».

    Оценка рисков

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

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

    • Следовательно, у вас должен быть где-то зафиксирован перечень тех проблем, которые могут возникнуть.
    • А когда вы беретесь за новый проект, вы просматриваете весь этот перечень возможных рисков, накладывая его в уме на текущую ситуацию, ианализируете, что из этого может быть актуально конкретно в данном проекте. Получается уже некий более узкий перечень из тех проблем, которые мы хотим решить непосредственно здесь.
    • И, по сути, каждое такое опасение нужно проработать, постараться примерно оценить его для себя в деньгах. Если вы считаете, что в данном проекте конкретная проблема ничтожно мала, и если она и случится, то у вас ничего страшного не произойдет – ее можно игнорировать. Но если проблема действительно существенна, то, по крайней мере, ее надо как-то задокументировать. То есть, вы озвучиваете заказчику, что у вас есть такое опасение – и тогда возможны два варианта:
      • Первый вариант – это когда заказчик берет ответственность на себя и говорит: «если это случится, я проблему решу». Тогда вы фиксируете в договоре, что заказчик берет эту ситуацию на себя.
      • И второй вариант – когда он говорит: «нет, я этого не решу, но этого не случится».Тут уже вы можете заложить риск в бюджет как некий оцененный, как опасение, что такая проблема может произойти, и это уже может проходить у вас как определенное обоснование цены.
    Читать еще:  Контентные проекты – радость для инвестора

    Заключение

    В заключение скажу о необходимости непрерывного совершенствования процедуры оценки.

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

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

    Методы оценки рисков проекта

    В данной статье разберем процессы управления рисками IT-проекта. Ответим на вопросы:

    · Что такое управление рисками с точки зрения проектной технологии?

    · Какие сейчас востребованы методы управления рисками IT-проектов?

    · Что можно улучшить в сфере управления рисками IT-проектов?

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

    1. Возможные риски проекта

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

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

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

    a. Неготовность топ-менеджмента Заказчика к изменениям в бизнес-процессах предприятия и организационной структуры;

    b. Незаинтересованность руководителей основных подразделений Заказчика и их прямых, подчиненных в проекте;

    c. Смена в ходе реализации проекта РП, Заказчика;

    d. Недостаточная квалификация РП и ответственных исполнителей Исполнителя;

    e. Текучесть кадров Исполнителя

    f. Отсутствие или нарушение методологии ведения IT-проекта;

    g. Риск неверного технического решения;

    h. Риск снижения производительности информационной системы;

    i. Ошибки календарного планирования;

    j. Изменение требований Заказчика

    k. Нарушение спецификаций (плана результатов) Исполнителем

    l. Низкая производительность Исполнителя (характерно для микро -команд)

    Если руководитель проекта считает, что не все риски выделены, то можно использовать методы мозгового штурма или SWOT-анализ проекта.

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

    Таблица 1 – Пример реестр рисков по проекту внедрения 1С

    2. Уровни риска проекта и превентивные мероприятия

    Анализируем каждый риск с позиций последствий для проекта и вероятности возникновения риска. Для оценки последствий можно воспользоваться инструментом РМВОК (см. Таблица 2)

    Таблица 2 – Влияние оказываемое риском на характеристики проекта

    По каждой из характеристик выбираем воздействие (жирный курсив в Таблица 2), далее считаем среднее арифметическое складывая все строки и получаем итоговую степень воздействия рисков на проект (5%+10%+20%+40%)/4 = 18,75% – т.е. среднее значение (15-30%).

    Совместно с экспертами (командой проекта) по выявленным основным рискам проекта выставляем вероятность: очень высокая (90%), высокая (70), средняя (50%), низкая (30%), очень низкая (10%).

    Далее сводим в общую таблицу вероятность и уровень влияния (см. Таблица 3)и заполняем колонки 4 и 5 Таблица 1

    Таблица 3 – Матрица оценки риска

    Уровень рисков проекта – если риск попадает в красную зону — обязательно вырабатываем противо-рисковое мероприятие (см. ниже). С желтыми рисками — на усмотрение команды проекта.

    Планирование вариантов реагирования для управления риском в желаемом направлении – соответственно определяем приемлемую стратегию реагирования на риск (колонка 6 Таблица 1):

    a. Уклониться (полностью устранить угрозу)

    b. Передать (найти третью сторону, которая может управлять угрозой за нас)

    c. Снизить (уменьшить вероятность и/или силу воздействия угрозы)

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

    e. Использовать (сделать так, чтобы возможность точно реализовалась)

    f. Разделить (привлечь третью сторону в управление возможностью)

    g. Увеличить (увеличить вероятность и/или воздействие возможности)

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

    i. Эскалация (обратитесь за помощью к руководству)

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

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

    3. Влияние риска на проект

    На стадии планирования управления рисками проекта у нас имеется Реестр рисков проекта, календарно-ресурсный план проекта с перечнем задач по управлению рисками проекта.

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

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

    Ссылка на основную публикацию
    Adblock
    detector