Эксперты выделяют пять самых распространенных причин, по которым проект может “отклониться от курса” и принести немалый вред вашему бизнесу и всем его участникам.
Естественно, увлечение технологиями может привести к большой головной боли, но технологии сами по себе редко бывают причиной провала ИТ-проекта.
“Конечно, ИТ-департаменты часто увлекаются технологиями, но, как правило, провалы происходят по другим причинам, а точнее — в результате неправильного управления технологиями, — сказал Михаэль Кригсман из компании Asuret, занимающейся консалтингом в сфере управления проектами. — Последствия подобных провалов могут быть очень существенными как с точки зрения техники, так и с точки зрения бизнеса. Но самое обидное — большинство этих провалов можно было бы избежать”.
Журнал Baseline обратился к Михаэлю Кригсману и целому ряду других экспертов с просьбой рассказать о пяти наиболее вероятных моментах провалов проектов.
1. Недостаточная подготовка
Одна из самых очевидных причин провала проектов — это плохое планирование. Те менеджеры, которые не могут правильно определить масштаб проекта, не применяют в работе принципы управления рисками и вовремя не планируют меры по обеспечению качества и безопасности, рискуют провалить всё.
Некоторые эксперты считают важным на этапе планирования проекта провести интенсивное обсуждение, что позволит заинтересованным лицам создать лист пожеланий и соответствующий ему бюджет, это даст менеджерам компании возможность заниматься проектом еще до начала его реализации.
“Одна из главных причин неудачи множества проектов — это недостаток подготовки, — отметил Стив Мак-Коннел, генеральный директор компании Construx Software, занимающейся консалтингом в сфере ПО. — Если вы приступаете к этапу разработки, то одна из его целей — подготовка к реализации проекта еще до его одобрения. Эта деятельность снизит вероятность провала проекта, если, конечно, он будет запущен”.
2. Несоответствие бизнесу
Даже прекрасно реализуемый ИТ-проект может провалиться. Если технология или процесс ее внедрения не увязан с нуждами бизнеса или не синхронизован с операционной деятельностью компании, то с большой вероятностью проект окажется бессмысленной тратой денег. ИТ-департамент должен работать в тесном контакте с лицами, заинтересованными в бизнесе компании, чтобы иметь ясное представление о его нуждах и обеспечить соответствие проекта схеме всего бизнеса.
“Определить, что нужно бизнесу, может только тот, кто является его владельцем, — считает Майк Сиско, президент компании MDE Enterprise, занимающейся подготовкой ИТ-персонала. — ИТ-специалисты далеко не всегда знают, какое решение оптимально для биллинговой компании или аудиторской компании, как лучше продавать ИТ-решения и обслуживать клиентов”.
3. Одностороннее принятие решений
Когда ИТ-департамент не может учесть интересы бизнеса при планировании новых инициатив, влияющих на действия бизнеса, он рискует не обеспечить соответствие бизнесу. Когда лидеры бизнеса считают, что ИТ-служба должна реализовать проект с конкретными параметрами, не спрашивая о его гибкости, они рискуют неудачным внедрением проекта или перерасходами и выходом за временные рамки.
“Первое, что вы должны сделать на самом раннем этапе, — это провести тщательное обсуждение проекта, — сказал Мак-Коннел. — В обсуждении проекта должны принимать участие все топ-менеджеры проекта, технические специалисты, руководство и лица, заинтересованные в бизнесе компании”.
Когда все соберутся за одним столом, то есть некая гарантия того, что не будет принято односторонних решений.
4. Отсутствие гибкости
Гибкий и динамичный бизнес может быстро реагировать на изменения рынка, поэтому только он может быть гарантией роста. К несчастью, некоторые ИТ-проекты бывают жестко определенными и не могут позволить бизнесу менять процессы или быстро подстраиваться под новые ситуации для извлечения прибыли. Отсутствие гибкости может убить проект.
“Динамика бизнеса может меняться, следовательно, может измениться и цель проекта, к тому же она должна быть гибкой и динамичной с самого начала, чтобы быстро адаптироваться к изменениям бизнеса”, — уверен Сиско, рекомендуя ИТ-директорам регулярно сканировать все аспекты реализации проекта, чтобы убедиться, что они соответствуют потребностям бизнеса в данный момент, и уничтожать то, что им не отвечает.
5. Увеличение размера
Недостаток подготовки обычно связан с “кухонным” синдромом, когда руководство добавляет в проект все новые и новые пункты вплоть до "обстановки на кухне". Ситуация прямо противоположна причине № 4, когда менеджеры ИТ и бизнеса ведут себя настолько “гибко”, что могут невероятно раздуть стоимость проекта там, где в этом нет необходимости.
Эта проблема вырастает все из той же неподготовленности проекта. Строгий процесс планирования и фаза тщательной разработки должны дать четкую картину масштаба и стоимости проекта, которые, по словам Мак-Коннела, почти всегда в два-три раза больше первоначальных оценок.
Очень важно осуществлять разумный баланс гибкости проекта с выполнением бюджета и его временных параметров. Руководство проектом должно разработать и внедрить процедуру внесения изменений в проект, чтобы гибкость не означала раздувание сроков и бюджета.
“Я думаю, что четкая процедура одобрения и блокировки изменений — это необходимая составная часть хорошего руководства проектом”, — заявил Мак-Коннел.