PC Week
Продолжая начатый нами ранее разговор о причинах провала ИТ-проектов, на сей раз остановимся на вопросах, связанных с распределением ответственности за проект. Вряд ли кто-либо станет оспаривать тезис, что это один из ключевых моментов, определяющих многие возникающие по ходу выполнения проекта проблемы, и его судьбу в целом. Что в этой связи отмечают западные исследователи и что по этому поводу думают наши эксперты?
Отсутствие долгосрочной ответственности за конечный результат
Согласно наблюдениям зарубежных исследователей, в ходе выполнения проектов, рассчитанных на несколько лет, порой случается, что к концу срока люди, принимающие решения об их реализации, уже не работают на своём месте — либо поднимаются вверх по служебной лестнице, либо переходят в другие подразделения.
Это естественно, считают эксперты, поскольку в сфере ИТ, где жизненный цикл продукта обычно составляет от трех до пяти лет, если сотрудник остается на своем рабочем месте более чем на два-три года это означает отсутствие у него амбиций, напористости и профессионализма. В результате провал проекта может быть без труда представлен как неудача инициаторов, большинство из которых теперь занимают более высокий пост и поэтому уже не являются непосредственно ответственными.
Комментируя данный тезис, заместитель директора ТЦ по проектному управлению компании «Инфосистемы Джет» Сергей Колчин ссылается на свой опыт, в соответствии с которым проект, не показывающий результата в течение года (а лучше еще раньше), практически обречен на неудачу. Так что проблема заключается в недостаточно развитой проектной культуре в компаниях исполнителя или заказчика, и всегда можно спланировать работу таким образом, что будут достигнуты промежуточные результаты, приносящие прибыль для бизнеса и не позволяющие проекту развалиться даже в случае смены спонсоров.
Также исходя из своего опыта Марина Аншина, председатель Комитета по стандартам Российского союза ИТ-директоров (СоДИТ), отметила, что средний срок «жизни» российского ИТ-руководителя составляет шесть месяцев, а за это время серьезный ИТ-проект сделать невозможно. Причем очень часто отставка ИТ-руководителя связана именно с неуспешностью инициированного им ИТ-проекта.
Для сокращения риска того, что начатый руководителем проект умрет после его ухода, необходимо, считает г-жа Аншина, чтобы вся связанная с ним информация была актуальна, доступна и понятна тем, кто будут продолжать его внедрение. «Вполне возможно, что новый руководитель привнесет новую стратегию, в рамках которой некоторые проекты станут ненужными. Однако, отказываясь от того или иного проекта, нужно принимать во внимание не только планируемые, но и понесенные затраты и то, что выгоды обычно идут за затратами, а не наоборот», — подчеркнула она.
По мнению же Антона Левикова, ИТ-директора группы компаний «Новард», трудно говорить о наличии системы управления в компании, где проекты пропадают вместе с их инициаторами: «Сложно считать успешным руководителя ИТ-проекта, который входит в проект и бросает его на половине. Команда может меняться, даже руководитель проекта может меняться, но в компании должен быть кто-то (им может быть, например, ИТ-директор), способный обеспечить передачу компетенций и доведение проекта до результата. Именно поэтому хорошие ИТ-директора работают в компаниях долго».
Данную мысль поддерживает директор службы профессионального сервиса компании «АйТи» Вячеслав Суханов, которому известны многие абсолютно успешные топ-менеджеры и руководители среднего уровня, работающие в крупных организациях свыше двух-трех лет. И при этом никто не считает их недостаточно напористыми или непрофессиональными. Наоборот, летуны, часто меняющие компании, вызывают подозрение, да и добиться реальных успехов за два-три года чрезвычайно сложно.
Вместе с тем г-н Суханов с сомнением относится к тезису что очень крупные проекты критически зависят от одного конкретного инициатора: «Безусловно, если „сменщик“ ушедшего инициатора или спонсора проекта относится к проекту с предубеждением, то он имеет хорошие шансы его завалить. Но это уже из разряда вредительства».
Андрей Педоренко, директор ИТ-департамента группы компаний «АльфаСтрахование», напротив, считает данный тезис справедливым не только по отношению к ИТ-руководителям, но и к менеджерам бизнес-направлений, несущих солидарную ответственность за внедрение ИТ-решений: «Нередки ситуации, когда новая бизнес-метла, сменив на руководящем посту человека, принимавшего вместе с CIO решение о внедрении и даже уже прошедшего часть пути по внедрению системы, ставит вопрос о нецелесообразности той или иной трансформации. И вот тут опускаются руки».
И наконец, Павел Алферов, заместитель генерального директора по управлению проектами и информационным сервисам в научно-исследовательской производственной компании «Электрон», полагает, что проблемой является смена ответственных за проект и соответственно взглядов на то, как его надо реализовывать: «Это действительно очень серьезная проблема, особенно для России. Смена курирующего топ-менеджера или ответственного миддл-менеджера оборвала не один очень успешный проект».
Неопределенность в выборе ответственных
В зарубежных исследованиях говорится, что порой в организациях возникает интересная ситуация, когда CIO выступает с инициативой реализации ИТ-проекта, направленного на развитие бизнеса. Для воплощения в жизнь этой идеи ИТ-руководителю требуется бизнес-спонсор, которому и достаются все лавры в случае успешной реализации данного проекта, даже если его участие было минимально и сводилось лишь к присутствию на собраниях и ответам на письма по электронной почте. Однако, если проект терпит неудачу, именно CIO оказывается виновным — ведь это была его идея, а не бизнес-спонсора. В итоге, по мнению экспертов, получается, что реальных ответственных за результаты проекта нет, и в таком случае его шансы на успешную реализацию невелики.
Комментируя подобную ситуацию, наши эксперты оценивают ее весьма неоднозначно. По словам Павла Алферова, описанный случай означает отсутствие вменяемой методологии управления ИТ-проектами в компании: «Любая нормальная методология подразумевает, что у проекта в обязательном порядке должен быть бизнес-спонсор или куратор, отвечающий за успех на уровне топ-менеджмента. Если такой методологии нет, то процент провальных проектов действительно будет зашкаливать». Причем это будет виной исключительно CIO, который не сумел объяснить бизнес-руководству, как это работает. А уж как делить лавры — вопрос отдельный и к причинам провала ИТ-проектов никакого отношения вообще не имеет. Наилучшим образом это иллюстрируют слова Джона Фитцджеральда Кеннеди: «У победы много отцов, поражение — всегда сирота».
Схожей точки зрения придерживается Сергей Колчин, считая, что если бизнес-спонсор ведет себя таким образом, это как правило означает, что проект не имеет такой ценности для бизнеса, как это представляется инициаторам. Что же касается ответственности, то ответ давно известен — за успех проекта отвечает его менеджер, и если шансы на успех действительно невелики, его не надо реализовывать. Очень важно, чтобы в проектных процедурах были предусмотрены некие контрольные точки, когда решение о старте проекта перепроверялось бы с учетом новых вводных, оценки рисков, проблем и прочих факторов, подчеркнул г-н Колчин.
А вот Вячеслав Суханов обращает внимание на то, что CIO чаще всего выступает инициатором проектов развития ИКТ-инфраструктуры, в этом случае спонсором проекта является он, и ответственность ему делить просто не с кем. Инициаторами же развития бизнес-приложений чаще всего выступают функциональные заказчики, которые при этом, однако, далеко не всегда готовы взять на себя хотя бы частичную ответственность за работы по проекту. В любом случае, по мнению г-на Суханова, существенно бОльшая доля ответственности в таких ИТ-проектах лежит на CIO, и это вполне естественно. Кроме того, надо иметь в виду, что если бизнес-спонсор не обеспечивает необходимый уровень взаимодействия исполнителя с реальными бизнес-заказчиками, не участвует в решении возможных проблем проекта, то это является большим риском и, безусловно, способствует его возможному провалу.
Антон Левиков считает нормальной описанную ситуацию, полагая при этом, что ИТ-директор может развивать бизнес самостоятельно только в части сервисов. Если же требуется менять бизнес, то ИТ-директору следует скооперироваться с кем-то, кому это делать положено по должности. Причем нужно смотреть заранее, с кем пойдешь «в связке»: «Если в своих силах ты не уверен, а бизнес-партнер слабоват духом, лучше и не начинать. Правда, в таком случае авторитет ИТ-директора точно не прирастет».
С точки зрения Марины Аншиной, нормальный ИТ-руководитель всегда заинтересован в успехе инициированного им проекта, а нормальный бизнес-спонсор всегда заинтересован в получении нового эффективного инструмента, в частности ИТ-инструмента. Если у него такой заинтересованности нет, проект бесполезен и ИТ-руководителю стоит от него отказаться. А то, каким образом эта заинтересованность бизнес-спонсора проявляется — в присутствии на собраниях, ответах на письма или как то иначе, не принципиально. Существенно также, что именно CIO должен в большинстве случаев привносить ИТ-проекты, поскольку бизнес-руководители не настолько хорошо знают ИТ-рынок, который стремительно развивается.
Наиболее решительно настроен Андрей Педоренко, который убежден, что ИТ-проект может быть успешен только в том случае, если его возглавляет бизнес-заказчик: «Тогда и лавры делить легче, и ответственность за ошибки, хотя желание свалить вину за те или иные ошибки проекта периодически возникает у обоих партнеров по процессу».
