Предотвращение краха проекта

Исследования, касающиеся краха проекта, довольно-таки невеселые, к примеру , Gartner предполагают, что 75% всех ИТ-проектов США считаются неуспешными теми, кто давал проекту старт. Но что представляет собой крах проекта?

Это означает то, что решение в основе  своей не выполнило то, что требовалось, проект не уложился в установленные сроки, либо превысил бюджет. По правде говоря, половина проектов превышала бюджет на 200%!

Исследования группы Standish, проведенные в ИТ-индустрии США, показали, что 31% были закрыты, а производительность 53% всех проектов была настолько тревожная, что они были изменены.

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

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

Проблемы с планированием и стартом проекта

• Нечеткое и неубедительное экономическое обоснование проекта
• Несоответствующий и несуществующий порядок выдачи разрешения
• Слабое определение масштаба проекта и его целей
• Недостаток времени и денежных средств
• Недостаточный контроль над бизнесом и подотчетностью
• Недостаточное и/или чрезмерно оптимистичное планирование
• Плохие прогнозы
• Длинные и нереальные временные рамки; принудительные даты завершения без учета предыдущего опыта
• Недостаток скрупулезности и стараний на начальных стадиях проекта

Проблемы, связанные с требованиями и техническими аспектами

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

Проблемы между членами команды, участниками проекта и высшим управлением

• Недостаточное внимание к участникам проекта и их нуждам, неспособность к управлению ожиданиями
• Недостаток со стороны высшего руководства внимания/поддержки, спонсоры проекта не преданы на 100% своим целям, недостаток в понимании проекта и не совсем активное вовлечение
• Неадекватная ясность статуса проекта
• Отрицание горькой правды  вместо  принятия и осознания её
• Недостаточная преданность людей проекту, попытки сбалансировать множество приоритетов
• Недостаток опыта у членов команды проекта, отсутствие у них требуемого опыта и навыков
• У команды нет достаточных прав и возможности принятия решений
• Плохое сотрудничество, недостаток общения и способности к командной работе

Проблемы с управлением проектом

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

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

На заметку:

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

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

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