Итак, успех проекта определяется немногими факторами. Разумеется, распознание этих факторов и управление ими не гарантирует успеха проектов. Понимание факторов и роли, которую они играют в успешном управлении проектами, - одно, а грамотное управление этими факторами - другое. В связи с тем, что управление факторами успеха еще не стало неотъемлемой частью практики управления проектами, слишком многие проекты в определенной степени страдают несостоятельностью.
Заметьте, мы говорим именно о "несостоятельности" проектов, а не о "неуспехе", "провале", чтобы избежать ассоциации с полным крахом проектов и колоссальными затратами. Существует огромный спектр несостоятельности проектов, связанный с самыми разными процессами. Это, например, проекты, которые вышли за рамки сроков или бюджетов, но в конце концов стали полностью функциональны. Есть еще множество проектов, которые успешно внедрены, но оказались не вполне соответствующими ожиданиям заказчиков. Бывают случаи, когда после "успешного" внедрения приложения оказывается, что оно недостаточно хорошо функционируют в данных конкретных условиях, или для данных условий слишком сложно, требует много времени для выполнения критичных задач и т. д.
Девять факторов, которые контролируют успех или несостоятельность ИТ-проектов:
1. Соответствующий уровень обязательств перед проектом со стороны топ-менеджмента
компании.
2. Адекватное финансирование проекта.
3. Грамотные проектные требования и спецификации.
4. Внимательное создание полномасштабного плана проекта.
5. Оценка рисков проекта и потенциальных проблем, связанных с этими рисками.
6. Соответствующее планирование непредвиденных затрат и чрезвычайных обстоятельств.
7. Обязательства всех вовлеченных сторон.
8. Честные отчеты о статусе проекта и о потенциальных проблемах, которые возникают
по мере продвижения проекта.
9. Объективная оценка возможности организации следовать проектному курсу.
Обязательства руководства компании
Часто менеджмент компании одобряет ИТ-проекты, которые несут в себе потенциально серьезные проблемы для предприятия, не понимая, какому риску они подвергают предприятие. ИТ-директор должен соответствующим образом информировать старшее управленческое звено о возможных проблемах, связанных с проектом. Однако часто эйфория по поводу подписания проекта и выделения фондов заставляет страхи отступить. Менеджмент компании с помощью ИТ-директора или без него из своего опыта должен понять, что проект необходимо отклонить или приостановить по крайней мере до тех пор, пока все сложные вопросы не будут решены.
Есть и другая сторона вопроса. Старшее управленческое звено компании должно понять, что важно не только подписание проекта к выполнению, но и определенный уровень обязательств по мере выполнения проектов в течение всей жизни проекта. Когда все видят и понимают, что ИТ-проект находится под пристальным контролем управления компании, все вовлеченные стороны в гораздо большей степени фокусируются на проекте. Крайне важно, чтобы руководящие менеджеры, ответственные за определенные части проекта, продолжали держать руку на пульсе по мере его выполнения. К сожалению, очень часто случается, что после подписания проекта к выполнению его полностью оставляют на ИТ-отдел. В этом случае проект в опасности. Поведение руководства компании в отношении ИТ-проекта еще называют SMC-фактором (Senior Management Commitment) успеха проекта.
Адекватное финансирование проектов
ИТ-проекты часто требуют существенных финансовых вложений. Однако финансы сами по себе не являются панацеей, и доступ к большому количеству денег не гарантирует успеха проекта. Организации должны понимать, что время, аппаратное и программное обеспечение, а также человеческий фактор - все компоненты, составляющие ИТ-проект, - дороги. До начала проекта необходимо потратить достаточно много времени на то, чтобы проанализировать стоимость компонентов проекта. Хотя хороший начальный анализ затрат проекта может и не привести к точной цифре, процесс должен обеспечить понимание затрат, ассоциированных с проектом. Как только получены более-менее реальные цифры, в эти затраты надо еще интегрировать разумное количество фондов на непредвиденные обстоятельства.
Но дело не только в грамотной начальной оценке стоимости проекта. Эти оценки затрат по проекту должны быть сделаны, но их результаты не должны рассматриваться как окончательные. Оценка финансовых затрат на ИТ-проект должна быть продолжительным и гибким процессом. Затраты на проект следует пересчитывать несколько раз по мере выполнения проекта и новые цифры представлять менеджменту компании. Топ-менеджмент компании должен рассмотреть эти изменения бюджета проекта без какого-либо негативного предрасположения. Перемены всегда выявляют истинную сущность происходящего. Например, спонсоры проекта могли запросить дополнительный функционал, не предусмотренный в начале проекта, что повлекло за собой увеличение общей стоимости проекта (к слову, примерно в 70-80% ИТ-проектов, связанных с автоматизацией бизнес-процессов, именно так и происходит). В реальности часто случается, что руководитель ИТ-проекта самостоятельно без санкции топ-менеджмента увеличивает промежуточные затраты, добавляет новую функциональность, но эти добавления не выплывают наружу до конца проекта. Если, конечно, при таком подходе проект вообще удается довести до конца. Промежуточные оценки затрат на проект помогают переоценить масштаб проекта и часто безболезненно снизить затраты до приемлемого уровня. Каков бы ни был результат пересмотра, при таком подходе есть возможность сделать определенные изменения, приемлемые для бизнеса. А по мере продвижения проекта в какой-то момент истинный масштаб проекта будет выявлен, и руководитель проекта сможет определить стоимость проекта более точно.
Проектные требования и спецификации
Для успеха проекта необходимо понять, что будет сделано в проекте и чего делаться не будет. Большинству руководителей ИТ-проектов знакома ситуация, когда функциональные заказчики начинают говорить, что функциональность, которая ранее была не нужна, вдруг оказывается срочно необходимой. Это обычно приводит к нарушению намеченного плана работ и является результатом недостаточной предварительной работы с функциональными заказчиками.
Более того, даже если требования и спецификации хорошо продуманы и задокументированы, по мере продвижения проекта все равно возникнут непредвиденные обстоятельства и решения. Поэтому важно с самого начала договориться, по крайней мере по поводу крупных модулей системы, и подписать соответствующее соглашение. Требования к проекту и спецификации должны быть одобрены бизнес-отделами, проблемы которых данный ИТ-проект и призван решить.
Максимально полный план проекта
Многие ИТ-менеджеры до сих пор убеждены, что план ИТ-проекта - бесполезная трата времени, хотя уже давно обнаружена зависимость между временем, затраченным на планирование проекта, и успехом проекта. Во-первых, планирование представляет четкое, документированное должным образом сфокусированное представление о проекте. Во-вторых, процесс планирования поднимает вопросы, которые бы не принимались во внимание без планирования. Очень часто все хотят побыстрее приступить к работе без адекватного понимания задач проекта или путей их реализации. В-третьих, умелое планирование формирует уверенность в успехе проекта. Соответственно по мере углубления плана становится легче приступить к проекту. ИТ-директор должен внедрять это положение самым настойчивым образом: планирование является важным компонентом управления проектами, и план должен быть закончен и утвержден, прежде чем проект начнется.
Оценка рисков проекта
До того как проект будет утвержден, необходимо сделать анализ рисков. Определение проектных рисков предполагает понимание рисков двух типов: стандартные риски и риски, связанные с требованиями данного конкретного проекта. К стандартным рискам относятся использование нового ПО, уровень ИТ-навыков в организации, наличие успешно оконченных ИТ-проектов, размер и сложность проекта, готовность организации финансировать проект, уровень доверия между ИТ-отделом и функциональными заказчиками. Риски, ассоциированные с конкретным проектом, включают в себя важность проекта для бизнеса организации (чем более он важен, тем больший риск). Внедрение нового приложения несет в себе больший потенциальный риск для эффективности бизнеса, чем апгрейд существующей системы. К рискам конкретного проекта относят риски, связанные с вендорами, например, возможность вендоров обеспечить оговоренную производительность или необходимость привлечения других вендоров. Обстоятельства внутри вендорской компании могут измениться. Например, на половине проекта вендорская компания может принять решение снять с производства линию аппаратного обеспечения, которая используется для данного проекта. Кроме того, к рискам конкретного проекта относят возможности потери ключевых специалистов.
Планирование чрезвычайных обстоятельств
По мере продвижения проекта всегда возникают сложности. Хотя организация может быть и полностью уверена в успехе проекта, разумно все же допускать вероятность провала. В связи с тем, что такая возможность существует, организация должна создать план преодоления препятствий. Одно из распространенных чрезвычайных обстоятельств - уровень аппаратных средств для поддержания проекта, становящийся вдруг неадекватным, когда проект запускается. Одна из типичных проблем ИТ-проектов, в особенности клиент-серверных, состоит в производительности приложений - она часто оказывается гораздо ниже планируемой. Следовательно, план проекта должен предусматривать возможности увеличения аппаратных ресурсов в случае необходимости. Конечно, никакое планирование не покроет всех возможных чрезвычайных ситуаций. В связи с этим финансирование проектов должно осуществляться гибко и давать возможность дополнительного финансирования затрат.
Обязательства вовлеченных сторон
Очень часто - слишком часто, чаще, чем хотелось бы, - ответственность за ИТ-проект полностью перекладывается на ИТ-отдел. К сожалению, порой ИТ-проекты значительного размера заканчиваются практически без какого-либо вмешательства функциональных заказчиков, потому что заказчики находятся в плену иллюзии: "закончите полностью - тогда покажете". Сотрудники за пределами ИТ-отдела, для которых, собственно, и выполняется проект, отделяют себя от проекта, в котором они кровно заинтересованы. Когда ИТ-проекты идут таким образом, они редко соответствуют запросам заказчиков. Дело не только в заказчиках, организационная вина ИТ-отделов тут тоже есть. Руководители проектов должны понять, что в их собственных интересах выстроить свои процессы, гарантируя максимальное вовлечение заказчиков в процесс работы над проектом. Отсутствие такой организации обязательно снизит коэффициент удовлетворенности. ИТ не должно инициировать никакие проекты без гарантии вовлеченности функциональных заказчиков и необходимого времени для их участия в проекте.
Учитывая возрастающую сложность ИТ-проектов, можно поставить такой диагноз: отсутствие ответственности за проект со стороны функциональных заказчиков представляет собой грубейшее нарушение принципов управления проектами. ИТ-инвестирует много времени и усилий в проекты, и заказчики со своей стороны должны найти способ инвестировать их со своей стороны. Старая парадигма "я плачу деньги - остальное меня не интересует" перестает работать. Топ-менеджмент компании должен организовать процессы таким образом, чтобы все стороны участвующие в проекте разделили ответственность за проект.
Правдивые отчеты о статусе проекта
Аккуратная отчетность по проекту - это звучит просто, но на деле оказывается немалой проблемой. Реальность такова, что отчеты о статусе ИТ-проектов чрезмерно оптимистичны. Главная проблема здесь в том, что приукрашенный отчет гораздо удобнее для всех отделов, так как дает чувство устойчивого прогресса. ИТ-директор часто полагает: недостатки и проблемы проекта будут разрешены по мере его продвижения, и никто ничего не заметит, когда все будет исправлено и проект вернется в колею намеченного расписания. Однако, как показывает практика, если однажды проект выпадает из планового расписания, ситуация без вмешательства топ-менеджмента, как правило, только ухудшается. Чем раньше отчет по проекту покажет проблемы проекта, тем лучше для всего проекта. Конечно, откровенный отчет такого рода создаст известное напряжение как для клиентов, так и для ИТ-отдела. Но определенный уровень напряжения как раз желателен. Он заставит людей разрешать возникшие проблемы на более ранних этапах. Игнорировать проблемы и переносить их разрешение на будущее означает превращать эти проблемы в сложные, трудно преодолимые препятствия.
Держать намеченный курс
Большинство сложностей, с которыми сталкиваются ИТ-проекты, можно преодолеть различными управленческими решениями. По мере того как проблемы возникают, менеджмент будет искать способы уменьшить негативные последствия и устранить источник этих проблем, однако давление, которое развивается в эти моменты, чаще всего изменяет ход проекта.
Варианты решения проблем чаще всего сводятся к одному из следующих:
a) снижение количества поставляемых пользователям возможностей;
b) использование обходного маневра решения проблемы;
c) снижение требований при тестировании подсистем, чтобы не выпасть из графика.
Обходные маневры и снижение стандартов при тестировании исходят из одной и той же идеи - проблема должна быть полностью и корректно решена, но сейчас для этого нет времени. Обходной маневр, как правило, сопровождается обещанием в какой-то момент вернуться к проблеме и сделать все как надо. К сожалению, на практике вероятность возвращения к решению этой проблемы близка к нулю.
Все это показывает, что шаги, которые должны быть предприняты для корректирования ситуации, и их производные в различных частях проекта следует внимательно продумать. Иначе от первоначального плана проекта очень быстро не останется ничего. План проекта должен быть достаточно гибок, чтобы допускать подобные вмешательства.
