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

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

1) неполных и непрозрачных требованиях;

2) недостаточной вовлеченности пользователей;

3) нереалистичных ожиданиях.

Кроме этого, в своей статье «6 причин провала проектов по разработке программного обеспечения» Барри Бем выделяет: недостаток коммуникаций; недостаточную гибкость компании и плохое тестирование (Boehm, 2002). Согласно отчету The Standish Group особое значение придается поддержке исполнительного руководства, а также говорится об эмоциональной зрелости компании (управлении ожиданиями) и правильном планировании (Chaos report, 2015). В более позднем анализе Бента Фливбьерга и Александра Будзье формулируются следующие существующие организационные проблемы (Flyvbjerg, Budzier, 2011):

1) политический уклон и неэффективное спонсорство проекта;

2) неэффективная структура управления бизнесом, ИТ;

3) неясные цели и критерии успеха бизнеса;

4) отсутствие управления рисками.

Наиболее полный обзор состояния индустрии проектного управления дает ежегодный отчет Project Management Institute 2017 года «Пульс профессии». Результаты опроса 3000 людей из разных промышленных отраслей о причинах неудачного завершения проектов приведены на диаграмме (см. Рисунок 4):

Рисунок 4 Причины неудачного завершения проектов, опубликованные в отчете Project Management Institute 2017 года «Пульс профессии»

1.4 Теория ограничений системы Э.Голдратта

В 1984 году была опубликована книга «Цель» автора и основоположника Теории ограничений системы Элияху Моше Голдратта. На сегодняшний день книга стала мировым бестселлером и практическим пособием всех прогрессивных руководителей, а журнал Time включил ее в список двадцати пяти наиболее влиятельных книг по бизнес-управлению (Time, 2011). Книга рассказывает о новых принципах в управлении производством, но не является руководством по внедрению.

Разработав в 1975 году программное обеспечение по планированию мощности производственного процесса (Optimized production timetables - Оптимизация технологии производства), Голдратт понял, что существующая система показателей эффективности, базирующаяся на учете издержек, не отвечает основной цели производства и не отражает в достаточной степени реального положения вещей. Так, предложенная в 1984 году Теория ограничений системы (TOC, Theory of Constraints) раскрывает новую методологию управления, в основе которой - определение ключевого ограничения системы, которое не позволяет реализовать ее мощность в полном объеме. Особенностью методологии является сосредоточение на управлении небольшим количеством ключевых элементов системы, что позволяет во много раз усилить эффект по сравнению с тем, который достигается от одновременного влияния на все проблемные зоны сразу (Голдратт, 2009).

Теория ограничений предлагает практические инструменты и типовые решения, из которых наиболее известными являются: метод Критической цепи (которому посвящена отдельная книга Голдратта, опубликованная в 1997 году), метод «Барабан-буфер-веревка», технология пяти сфокусированных шагов «Процесс непрерывного улучшения». Книга «Цель» ориентируется на малый бизнес и, преимущественно, производственную сферу (Борута, 2017). Книга «Критическая цепь» является адаптацией теории ограничений для целей проектного управления (Голдратт, 2006). Теория ограничений применяется:

1) в управлении производством;

2) в управлении запасами, закупками и дистрибуцией;

3) в управлении продажами и маркетинге;

4) при принятии управленческих решений;

5) в проектном управлении;

6) в управлении изменениями и персоналом.

Основное понятие рассматриваемой методологии - «ограничение» - фактор, определяющий предел системы. Система - цепь взаимосвязанных и взаимозависимых элементов/событий. Взаимосвязанность означает, что каждый элемент цепи вносит свой вклад в достижение общей цели, взаимозависимость говорит о том, что второе событие не может начаться до тех пор, пока не закончится первое. Вся цепь будет настолько стабильна и прочна, насколько надежным будет ее самый слабый элемент. При этом, особое внимание Теория ограничений уделяет тому, что для достижения цели систему необходимо рассматривать всю целиком, оптимизации только одного этапа/процесса не всегда может быть достаточно.

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

1) ограничение мощности - невозможность обеспечения требуемого уровня мощности системы в единицу времени;

2) ограничение рынка - недостаточность спроса для обеспечения требуемого уровня развития системы;

3) ограничение времени - время отклика системы на запрос потребителя;

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

5) физическое ограничение - нехватка ресурсов;

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

Рассмотрим подробнее технологию пяти сфокусированных шагов «Процесс непрерывного улучшения». Данная технология используется для того, чтобы определить на что нужно обратить внимание и что непосредственно нужно сделать. Три главных вопроса, на которые позволяет ответить Теория ограничений, в контексте достижения основной цели компании, можно сформулировать так: Что менять? На что менять? Как обеспечить данные изменения?

1) Шаг 1. Выявить ограничение системы. Важно не на скорую руку решать проблемы, лежащие на поверхности, в попытках «потушить пожар», а определить, какие изменения необходимо внести в систему, для устранения «слабого звена». В противном случае, режим работы «пожарной команды» будет включен постоянно.

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

3) Шаг 3. Синхронизировать остальные элементы системы. Все «снабжающие» элементы системы должны быть способны обеспечить в полном объеме ограничивающий ресурс.

4) Шаг 4. Устранить ограничение. На данном этапе необходимо превратить в неограничивающий ограничивающий ресурс.

5) Шаг 5. В случае устранения выявленного ограничения нужно вернуться к первому шагу - убедиться, что определение ограничения было верным, и найти новое ограничение.

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

Метод «Барабан - буфер - веревка» используют для управления ограничениями после их выявления на стадии пяти шагов процесса непрерывного улучшения. Разберемся с основными понятиями данной концепции:

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

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

3) Веревка. Веревка выступает связующим звеном между барабаном и буфером. Веревка позволяет ограничить входной поток в систему в соответствии с темпом барабана. Пли планировании объема входного потока необходимо контролировать состояние буфера и барабана (ограничивающего ресурса).

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

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

Не стоит забывать о том, что метод «Барабан - буфер - веревка» разрабатывался в конце прошлого столетия, и для его применения в современных условиях необходимы определенные модификации и доработки.

1.5 Управление проектом по методу Критической цепи

Как уже было сказано ранее, в 1997 году Э.Голдратт опубликовал еще одну свою книгу - «Критическая цепь», которая является адаптацией ТОС для целей проектного управления. Критическая цепь - это последовательность взаимозависимых задач проекта, имеющая наибольшую длину, и необходимая для реализации проекта. Данный подход отличается от хорошо известного метода Критического пути тем, что:

1) учитывает одновременный запрос задач на общие ресурсы проекта;

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

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

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

Данный метод определяет конкретные правила при принятии управленческих решений, которые диктуются размером остатка буфера и процентом завершения задач в критической цепи. Прогресс проекта оценивается при таком подходе не при помощи традиционного анализа освоенного объема, а по проценту использованного времени, заложенного в качестве проектного буфера. Условно выделяют три зоны буфера: зеленая зона - не требующая действий (в случае, если последняя из задач критической цепи опережает график или опоздание не превосходит 1/3 размера проектного буфера), желтая зона - при попадании в которую необходимо произвести оценку проблемы и составить план действий по восстановлению буфера или сокращению времени на выполнение текущих/предстоящих задач, красная зона - зона, требующая срочных действий.

Ученые называют концепцию Критического пути удачным дополнением Теории ограничений к своду знаний PMBOK, а методика CCPM (Critical Chain Project Management), разработанная Лоуренсом Личем, перешла в разряд базовых методик в сфере проектного управления (Лич, 2010). Практика доказывает эффективность описанного метода, более того, в последнее время все чаще говорят об удачном синтезе подхода Agile и метода Критической цепи для управления проектами в высокотехнологичных отраслях.

1.6 Методы анализа и оценки рисков

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

Согласно определению, данному Институтом проектного управления (PMI), риск - это неопределенное условие или событие, при наступлении которого на цели проекта может быть оказано положительное или отрицательное влияние. В качестве причины для наступления рискового события могут выступать: требования, проектные ограничения и допущения или определенные условия. Степень неопределенности причины появления риска, вероятности его возникновения и силы воздействия присуща всем проектам. Рисками, выявленными на ранних этапах, можно управлять проактивно. Для неизвестных рисков необходимо выделить заранее управленческий резерв на возможные потери (Дубинин, 2007).

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

В основе качественного анализа рисков лежит три этапа:

1) выявить риск;

2) определить вероятность его возникновения;

3) проанализировать потенциальное воздействие риска.

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

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

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

2) анализ сценариев - позволяет не только проанализировать чувствительность проекта к ключевым переменным и факторам, но и рассчитать их вероятностные значения;

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

4) анализ дерева решений - метод, показывающий последствия выбора той или иной альтернативы в процессе принятия управленческих решений, для эффективной работы данного метода необходимо обладать большим объем как статистических, так и динамических данных;

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

6) анализ уровней защиты (LOPA);

7) анализ режимов отказа и воздействия (FMEA).

Остановимся чуть подробнее еще на некоторых методах количественного анализа рисков. Широко распространенным является PERT-анализ (Program Evaluation and Review Technique). Метод впервые был использован в 1958 годe для управления проектом по созданию баллистической ракеты Polaris. Специфика метода и, одновременно, инструмента сетевого планирования заключается в его применимости к крупным проектам (для проектирования Polaris было привлечено более 3300 подрядчиков, число операций проекта превосходило 400). Метод демонстрирует наибольшую эффективность при проведении оценки сроков и ресурсов проекта. Смысл PERT-анализа заключается в том, чтобы рассчитать стоимость и сроки реализации проекта по трем оценкам: наиболее вероятной, оптимистической и пессимистической. Тогда ожидаемые показатели реализации проекта (срок/стоимость) будут равняться сумме оптимистической, пессимистической и наиболее вероятной оценки (х4), деленной на 6. Коэффициенты 6 и 4 здесь определены эмпирическим путем на базе собранной статистики большого числа проектов. Практика показывает, что PERT занижает ожидаемую продолжительность выполнения процесса, задачи проекта. Поэтому, такой метод рекомендуют использовать в том случае, если есть четкое обоснование значений трех перечисленных оценок. При расчете ожидаемых сроков проекта по трем временным показателям данный метод не учитывает вероятность появления задержек и сбоев. Защитой от подобного являются буферы.

В случае если невозможно задать точные оценки ключевых параметров проекта (как в PERT-анализе и других сценарных методах), но можно установить интервалы изменения показателей, рекомендуется использовать метод имитационного моделирования Монте-Карло. Метод Монте-Карло, имеющий мощный технологический аппарат и построенный на применении математических алгоритмов, является наиболее формализованным и точным среди существующих методов идентификации и оценки рисков. Сложность данного метода оправдывается только при работе с большим объемом накопленной информации и наличием достаточного количества времени для обработки данных. Метод Монте-Карло используют в некоторых сферах бизнеса, в том числе в процессах управления рисками, в случае, если аналитических моделей и экспертных оценок становится недостаточно (Зеленков, 2016). К преимуществам данного метода относят:

1) его универсальность, как со стороны входных данных, так и создаваемых моделей;

2) возможность учета взаимосвязи процессов;

3) понятность используемых моделей;

4) возможность достижения требуемой точности результатов.

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

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

2. Основные положения методологии оценки проектных рисков

2.1 Выявление и анализ причин неудачного завершения проекта системной интеграции в банковской сфере

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

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

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

- старт проекта без согласованных требований и видения проекта;

- смена идей проекта;

- отсутствие у подрядчика понимания формата использования конечного результата проекта;

- частые изменения требований в процессе реализации проекта и отсутствие единых требований от бизнеса;

- недостаточная глубина проработки требований;

- отсутствие четких технических заданий и детальных моделей данных;

- низкий уровень анализа входных данных перед началом проекта;

- отсутствие учета прироста данных в ходе реализации проекта;

- большое количество систем заказчика и зависимостей между ними, создающих блокировки для реализации проекта;

- низкая надежность систем заказчика;

- в проект не были заложены ресурсы на инфраструктуру (в т.ч. человеческие);

- технические проблемы и низкая скорость реакции на них;

- отсутствие гибкого подхода к разработке;

- нарушение требований стандартов разработки;

- отсутствие описания процессов по всему жизненному циклу;

- некорректные сроки планирования;

- постоянная смена заказчика и руководителя проекта со стороны подрядчика;

- нехватка ресурсов (людей) и частичная занятость на проекте, со стороны клиента;

- нехватка экспертизы и опытных специалистов;

- отсутствие понимания ролей и организационной структуры;

- смешение ответственности: объединение ролей, размытие границ ролей;

- отсутствие возможности быстрых коммуникаций, разрозненность команд и низкая степень взаимодействия между командами;

- не налаженная система передачи знаний;

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

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

Рисунок 5 Плановые и фактические сроки реализации исследуемого проекта

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

· зеленое тонирование означает, что этап завершен без нарушения запланированных сроков реализации;

· желтое тонирование - нарушение сроков установленного графика выполнения работ не превосходит 50%;

· красное тонирование - запланированные сроки выполнения этапа превышены более чем на 50%.

В первую очередь, такое критичное отставание от запланированных сроков реализации проекта, обусловлено:

1) неправильной оценкой и планированием проекта на ранних стадиях (недооценили сложность проекта в принципе);

2) появлением новых или изменением первоначальных требований и выявлением критичных ошибок в ходе реализации, которые блокировали целые этапы проекта.

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

2.2 Обоснование выбора подходов и методов для разработки методологии системы управления проектными рисками

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

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

Рисунок 6 Учет риска при оценке задач проекта

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

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

2) потратит на выполнение задачи все отведенное на нее время, в том числе и резервное (закон Паркинсона).

В случае с проектом, который рассматривается в данной работе в качестве основного примера, и на котором будет тестироваться предлагаемый механизм оценки рисков, в среднем 30-40% от общего объема работ закладывается на наступление неблагоприятных событий: 15% - обязательный минимум, 10% на коммуникации и переговоры, 5% на всякий случай. Такой расчет является более практичным по сравнению с изложенным выше, так как резерв формируется для всего проекта в целом, а не по каждой отдельно взятой задаче, но все равно является неточным (оценка производится «на глаз», «на всякий случай»).

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