второй ИТ-проект брокерской компании A. G. Edwards не доводился до логического завершения в срок, а его стоимость намного превышала бюджет. Теперь же руководство компании не без гордости заявляет, что 88 % их проектов успешны. На пути к достижению таких результатов удалось значительно оживить работу ИТ-отдела, перестроить работу группы управления проектами и внедрить стандартную модель контроля проектных работ и систему отчетности.
 |
|
«Для того чтобы усовершенствовать процесс управления проектами, прежде всего необходимо заручиться поддержкой руководства компании», — Джон Паркер, ИТ-директор компании A. G. Edwards |
Поступая в компанию A. G. Edwards на должность технического директора, Джон Паркер хорошо понимал, что работа будет не из легких. Во время собеседования осенью 2001 года руководство компании подробно описало, с какими проблемами ему придется столкнуться. Расходы на ИТ превышали все разумные пределы. Работа над проектами затягивалась на годы, а то и вовсе оставалась незавершенной.
Очевидно, что компании был нужен профессионал на должность технического директора. Причем такой, который бы не просто возглавил ИТ-отдел, но и смог бы гарантировать, что глобальный проект по переходу с одного мэйнфрейма на другой будет выполнен в установленный пятилетний срок и без превышения бюджета в 196 млн. долл. Допустить, чтобы реализация и этого, стратегически важного, проекта протекала по обычному сценарию, руководство попросту не могло.
Начав работу, Паркер обнаружил, что все услышанное на собеседовании соответствовало действительности. Практически половина всех проектов были либо затянуты, либо грозили компании неоправданно высокими расходами. Сроки выполнения и затратная часть большинства проектов на 54 % превышали изначальные оценки. Некоторые проекты даже приходилось закрывать. «В течение года мы разрабатывали сотни проектов, из которых 1б—2 % приходилось закрывать, а расходы списывать. А это означало, что многие тысячи долларов были попросту выброшены на ветер», — говорит Паркер, теперь ИТ-директор компании. Согласно справке, поданной руководством компании в Комиссию по ценным бумагам и биржам (Securities and Exchange Commission, SEC), только в 2002 году A. G. Edwards пришлось списать разработанное программное обеспечение на сумму около 46 млн. долл.
Немного забегая вперед, можно сказать, что к концу 2006 года доля успешных проектов компании (то есть выполненных в срок и уложившихся в рамки бюджета) составит 88 %. Для сравнения, в 2002 году этот показатель не превышал 54 %. Благодаря качественному управлению проектами финансовое положение компании улучшилось. Согласно данным SEC, расходы компании на ИТ и телекоммуникации снизились с 295 млн. долл. в 2002 году до 241 млн. долл. в 2005 году при том, что компания продолжает вкладывать средства в проект по переходу на новый мэйнфрейм. В то же время прибыль компании увеличилась с 71 млн. долл. в 2002 году до 186 млн. долл. в 2005 году.
Как же удалось добиться таких результатов? Во-первых, Паркер полностью перестроил работу ИТ-отдела, начиная с взаимодействия с другими подразделениями компании и заканчивая структурой группы управления проектами. Он знал по опыту, что никакие методики и современное программное обеспечение, на которые делают ставку большинство ИТ-компаний, не спасут положение. Самое главное, по его мнению — грамотное управление проектами и конструктивное сотрудничество ИТ-менеджеров с представителями других отделов компании. Кроме того, Паркеру много удалось достичь благодаря тесной работе с руководителями компании, которые помогли ему определить наиболее значимые проекты и организовать обучение для ИТ-менеджеров.
«Для того чтобы усовершенствовать процесс управления проектами, прежде всего необходимо заручиться поддержкой руководства компании, — говорит Паркер. — Иначе вы будете обречены на неудачу, вне зависимости от того, насколько хороши ваши управленческие методики».
Чтобы упорядочить процесс разработки проектов, Паркер пригласил эксперта по управлению проектами. Эд Пилевски, ныне вице-президент по вопросам производительности и качества ИТ, для решения поставленной перед ним задачи выбрал нестандартный путь. Он не стал навязывать техническому персоналу жесткую методологию управления проектами (как делали многие его коллеги), поскольку это могло вызвать только недовольство и сопротивление переменам. Вместо этого он внедрил стандартную процедуру мониторинга и отчетности по этапам реализации проекта. В результате процесс руководства стал более наглядным, и проектные менеджеры получили некоторую свободу в выборе стиля работы.
Кроме того, была полностью перестроена работа группы управления проектов. Раньше менеджеры проектов отчитывались только перед руководством, теперь же они составляли отчеты и доклады для функциональных групп, с которыми совместно работали. По мысли Паркера это позволило бы им разделить с компанией ее успех и ее неудачу в случае успешной или, наоборот, неудачной реализации проекта. Задачей группы производственных услуг, как теперь называется группа управления проектами, стала помощь менеджерам проектов в планировании и сборе информации по ходу выполнения тех или иных работ. Таким образом, старая бюрократическая модель управления проектами осталась в прошлом.
По мнению специалистов, опыт A. G. Edwards в области управления проектами означает отход от стандартной модели и достоин пристального внимания. б«Не всякая компания в состоянии сделать то, чего добилась A. G. Edwardsб», — говорит Сэм Лоулер, директор GlassHouse Technologies, компании, предоставляющей услуги по управлению проектами. — A. G. Edwards удалось внедрить новый подход к управлению проектами. И это сделало ее уникальной в своем родеб».
Очевидно, что подход A. G. Edwards к управлению проектами достаточно эффективен и, возможно, подойдет и для вашей компании.
Общая ситуация
Неумелое руководство проектами может повлечь за собой крайне неприятные последствия: множество компаний, начиная с Nestlе и заканчивая Nike, знакомы с результатами некачественной работы ИТ-отдела не понаслышке. И многие из них, даже под угрозой финансового риска, до сих пор не могут принять решительных мер по усовершенствованию управления проектами. Консультационная группа The Standish Group, публикующая раз в два года исследования по успешности реализации ИТ-проектов, приводит следующие данные: из всех ИТ-проектов, начатых в 2004 году, только 29 % были завершены вовремя, не превышали бюджета и соответствовали изначально поставленным задачам и целям. Неграмотное управление проектами чревато невыполнением заказов и возникновением задолженностей, особенно сейчас, в 2006 году, когда компании делают все большую ставку на ИТ-решения. «Сегодня мы испытываем острую, как никогда прежде, потребность в качественном ИТ-руководстве. Ситуация на рынке улучшается, доходы растут, и у организаций теперь есть средства на улучшение технологической базы, в том числе и ИТ-основы», — говорит Лоулер из GlassHouse. Однако до сих пор многие ИТ-руководители признаются в своей неспособности своевременно завершить работу над проектом. «Умелое руководство проектами является ключом к успешной деятельности компании, — говорит Лоулер. — Способность компании реализовать свою стратегию напрямую зависит от способности ее менеджеров к эффективному управлению проектами».
Однако управление проектом далеко не простая задача. Использование таких формальных методик, как PMI или ITIL, не является залогом успеха. И опыт A. G. Edwards, располагавшей обеими, является прямым тому подтверждением. «Я видел много организаций, использовавших методику реализации проектов, но тем не менее не добивавшихся успеха, — говорит Питер Грэм, вице-президент консультационной группы Palladium Group.
Компаниям не удается успешно завершить свои проекты по двум причинам. Во-первых, применение формальных методик требует смены стиля руководства не только ИТ-отделом, но и всей компанией в целом. Во-вторых, подобные методики зачастую сводятся к бюрократической формальности и не помогают разрешить проблемы, которые и приводят к провалу проектов. К числу таких проблем можно отнести, например, недостаточно хорошо налаженное сотрудничество между функциональным менеджером и менеджером проекта. Именно поэтому руководство A. G. Edwards не стало полагаться ни на существующую систему управления проектами, ни на какую-либо новую методику.
Начало
Когда в ноябре 2001 года Паркер пришел в компанию, его взору предстал классический образ ИТ-отдела. Вот два устоявшихся принципа работы его сотрудников: никогда не говорить «нет» руководству компании и никогда не давать однозначных ответов. Он понимал, что не сможет улучшить ситуацию в компании, пока эти принципы не будут сломаны, а руководство не перестанет считать сотрудников ИТ отдела пассивными и некомпетентными. «Успешный проект подобен бракосочетанию, бракосочетанию между бизнесменами и специалистами по ИТ», — считает Паркер. И его точка зрения далеко небезосновательна: будучи вице-президентом по информационным услугам компании Northwest Airlines с 1999 по 2001 годы, он курировал целый ряд успешных проектов.
Придя в A. G. Edwards, Паркер начал с того, что попытался изменить ментальность сотрудников ИТ-отдела, дать им почувствовать себя не просто исполнителями приказов руководства. Он хотел, чтобы они поняли свою роль в достижении стратегических целей A. G. Edwards. Он считал, что все ИТ-менеджеры должны рассматриваться как реальные управленцы, их мнение так же весомо, как и мнение любого другого сотрудника, находящегося на руководящей должности. Без этого эффективная работа по проектам невозможна. В связи с этим все 250 сотрудников, занимающие руководящие должности в ИТ-отделе, прошли специальный тренинг для лидеров.
«Именно руководители задают тон взаимоотношений в ИТ-отделе, именно от них зависит эффективность и качество работы их подчиненных, — говорит Паркер. — Если сотрудники превращаются в бездумных исполнителей приказов своего начальства, нечего ждать от них высоких показателей».
Обучение было особенно необходимо для менеджеров по линиям продукции. Паркер ожидал, что эти менеджеры должны принять участие в руководстве отделом, так как именно они находятся в тесном контакте с сотрудниками, непосредственно участвующими во всех проектных работах, начиная от написания кодов и заканчивая проведением тестирования. Он подготовил и провел несколько ежеквартальных тренингов, в ходе которых менеджеры изучали основы бюджетного планирования, развивали навыки стратегического мышления и дипломатии.
Паркеру активно помогало все высшее руководство во главе с генеральным директором Робертом Бегсби. Главной целью была разработка плана развития экономической деятельности компании и поиск технологий, которые бы способствовали реализации этого плана. Паркер регулярно участвовал в собраниях совета директоров, состоящего из восьми высших руководителей компании. На совещаниях были определены приоритетные задачи, что позволило Паркеру наиболее эффективно планировать работу отдела и использование ресурсов. Перемены в ИТ-отделе стали потрясением не только для самого отдела, но и для всей компании. Несмотря на поддержку высшего руководства, Паркер до сих пор чувствует сопротивление некоторых сотрудников, которых не устраивают нововведения.
Решить проблему помогла дипломатия. «Разумеется, я не врываюсь в кабинеты со словами: “Внимание! Всем немедленно изучить новые правила работы с ИТ-отделом!” Я понимаю, что это ничего не даст», — говорит Паркер. При личных встречах он рассказывает о проблемах, которые возникали у него с конкретными руководителями отделов и менеджерами, приводит примеры успешного и плодотворного сотрудничества с менеджерами, которые сами всячески способствовали нововведениям. Заканчивает он обычно такими словами: «Нам сложно работать с вами. Довольно рассуждать о том, хороши новые порядки или нет, лучше подробно опишите, какой результат вы хотели бы видеть». Тем же, кто упорно не желает сотрудничать с ним, он предлагает ознакомиться с графиками, наглядно демонстрирующими, насколько подобная позиция увеличивает вероятность провала проекта.
Однако иногда Паркер вынужден проявлять жесткость по отношению к наиболее злостным «ИТ-ненавистникам», которые сознательно вредят работе ИТ-отдела. В этом случае ему приходится обращаться за помощью к своим начальникам, а при необходимости к начальникам их начальников.
Реализация тактического плана
 |
|
«...схема дает менеджеру возможность осуществить работу самостоятельно: она не диктует ему, как он должен выполнить те или иные действия, а лишь напоминает, что необходимо сделать в настоящий момент.» — Эд Пилевски, вице-президентом по вопросам производительности и качества ИТ компании A.G. Edwards |
После утверждения ИТ-стратегии следующей, не менее важной, задачей стала выработка нового подхода к руководству проектами как таковому. Для ее решения в июне 2003 года руководители A. G. Edwards пригласили Пилевски в качестве независимого консультанта. Через три месяца он был назначен вице-президентом по вопросам производительности и качества ИТ.
Пилевски незаурядный профессионал в области руководства проектами. До прихода в A. G. Edwards он шесть лет проработал консультантом по вопросам ведения крупных ИТ-проектов, находящихся на грани провала. Кроме этого, он был директором по реализации проектов в одном из подразделений компании Capgemini.
К моменту прихода Пилевски брокерская компания уже выработала методику по реализации проектов. Он принял эту методику, но с одним кардинальным нововведением. Он внедрил то, что сам называет стандартной структурой плана реализации проекта. Иначе говоря — это комплекс мер, который выполняется в ходе работы над проектом. Пилевски уже применял его ранее и знал, что он может подойти и для A. G. Edwards.
Принцип ее работы следующий. Структура включает 25 шагов, или этапов, курируемых менеджером, которые необходимо осуществить по мере реализации проекта, например, разработку спецификаций архитектуры, анализ требований и составление плана проведения тестирования. Менеджер по проекту также отвечает за выполнение мероприятий, необходимых при прохождении каждого шага. Скажем, чтобы осуществить такой шаг, как анализ требований в процессе реализации проекта по разработке приложения для отдела кадров, менеджеру проекта необходимо составить документ, включающий подробное описание функций, которые приложение должно выполнять.
В структуре перечислены конкретные ИТ-группы, работающие над проектом, и указано количество времени, затрачиваемое каждой из них. Это помогает правильно расходовать ресурсы и распределять рабочую силу. Например, проект по вводу новой технологии обслуживания клиентов не был выполнен в срок ни в одном из офисов A. G. Edwards. Из-за этого от местного руководства нередко уже ближе к ночи поступали телефонные звонки с требованием, чтобы функциональные менеджеры перестали заниматься ерундой и бросили все силы на обновление технологий. Взяв на вооружение свою структуру, Пилевски сумел установить контроль за исполнением проекта. Появилась возможность визуализировать план работы над проектом и стало более понятно, когда функциональным менеджером следует устанавливать инфраструктуру или проводить испытания аппаратного и программного обеспечения. Для большей наглядности Пилевски и его команда специалистов по планированию, менеджеров и разработчиков проектов использовали программное обеспечение Primavera, облегчающее отслеживание реализации проекта. Оно выполняет сравнение начальных оценок с фактическими затратами, отмечает достижение определенных поставленных целей, составляет перечень ресурсов, необходимых для выполнения тех или иных задач, и позволяет просмотреть все проекты, над которыми работает функциональная группа ИТ-отдела. Primavera также предоставляет данные, касающиеся необходимости использования различных ИТ-функций на всех этапах реализации проекта и сроков выполнения тех или иных мероприятий. Все 126 проектов компании прорабатывались по схеме Пилевски. Таким образом, все проекты оценивались единообразно.
Примечательно, что схема стандартного плана не содержит указаний о том, как именно проектный или функциональный менеджер должен выполнять каждый из 25 шагов, и в этом ее кардинальное отличие от стандартной методологии разработки проектов. Как говорит Пилевски, схема дает менеджеру возможность осуществить работу самостоятельно: она не диктует ему, как он должен выполнить те или иные действия, а лишь напоминает, что необходимо сделать в настоящий момент. И это очень важно, так как стандартные проектные методологии большинство менеджеров проектов считает слишком ограниченными. «Невозможно стандартизировать абсолютно все процессы, — говорит Патрик Бойлан, генеральный директор Intellilink Solutions, консультационного агентства, специализирующегося на проектном менеджменте. — Компании — это крупные и сложные образования. Им необходимо научиться контролировать свои проекты, при этом не слишком сильно ограничивая свободу ИТ-отдела». И A. G. Edwards с помощью новой схемы сумела этого добиться.
Искусство убеждать
Несмотря на то, что структура стандартного плана достаточно гибкая, сотрудники ИТ-отдела неохотно знакомились с ней. Чтобы изменить настроение своих подчиненных, Паркер и Пилевски использовали разные тактики. Паркер взывал прежде всего к чувству профессионализма своих сотрудников. Он знал, что им не доставляет удовольствия годами биться над проектами, и говорил, что эта структура как раз может помочь в достижении поставленных целей.
Пилевски отметил, что некоторые менеджеры проектов восприимчивы к новым идеям и очень хотели бы повысить эффективность своей работы. Он попросил их принять участие в пилотных проектах б— малом проекте закупки оборудования и большом проекте обновления инфраструктурных приложений. При реализации этих проектов они воспользовались структурой стандартного плана впервые. Затем эти же менеджеры самостоятельно и довольно быстро внедрили структуру среди своих коллег.
Пилевски и его консультационное агентство по вопросам управления проектами предоставляли услуги планирования всем проектным менеджерам. Это делалось для того, чтобы они не чувствовали себя перегруженными при изучении нового инструмента. Кроме того, агентство помогло обюединить стандартную структуру плана с личным планом каждого менеджера. В итоге менеджеру оставалось лишь сказать, в каком виде он хотел бы получить свой план: в документе Word, таблице Excel либо выполненным в виде плаката. Пилевски говорит, что это помогло ему смягчить недовольство, связанное с введением новой методики.
Наконец Паркер всячески хвалил своих сотрудников за то, что они приняли новую, более эффективную форму управления проектами. Он рассчитывал показатели успешной реализации проектов и вносил эти данные в ежеквартальные отчеты для высшего руководства A. G. Edwards, поскольку считал: если его персонал будет в курсе того, что он сообщает эти данные руководству компании, отношение к управлению проектами станет значительно более серьезным.
Повторное определение успеха
Помимо введения стандартной структуры плана, Паркер изменил смысл понятия «успешное выполнение проекта». Прежде под этой формулировкой подразумевалось своевременное выполнение проекта без превышения затратной части, теперь же он предложил оценивать успешность проекта по его значимости для компании. Между прочим, именно этот критерий является ключевым для спонсоров проектов. Таким образом, компания считает проект успешным, если его выполнение, пусть даже с превышением сроков, приносит ожидаемую пользу.
Цель изменений была не в том, чтобы снизить планку. Паркер хотел, чтобы оценку успешности проекта давали, в первую очередь, внутренние клиенты, что делало проект ориентированным на их конкретные потребности. Например, когда перед ИТ-отделом поставили задачу разработать приложение для найма финансовых консультантов, Пилевски сумел представить краткосрочный малобюджетный план разработки этого проекта. В процессе работы над функциональными требованиями сотрудники проектного отдела хорошо поняли конкурентное преимущество подобного программного обеспечения для найма талантливых брокеров. Стало очевидно, что для достижения оптимального результата им потребуется больше времени. В итоге срок реализации проекта на три месяца превысил запланированный, а бюджет был превышен вдвое. Тем не менее проект был признан успешным, так как позволил оптимизировать процесс приема на работу.
«Менеджеры проектов уделяют чрез мерное внимание затратной части и срокам исполнения, — говорит Пилевски. — Тогда как в управлении проектами самое главное — это понять, что ключевым фактором в разработке проекта является сам клиент. Ведь именно клиент, и никто другой, в конечном итоге определяет успешность реализации проекта». Он преобразовал отдел управления проектами так, чтобы стимулировать взаимодействие между проектными и функциональными менеджерами, которые, как правило, редко бывают в хороших отношениях друг с другом. «Люди, работающие в ИТ-структуре, слишком заняты текущими делами, — считает Лоулер из GlassHouse’s Lawler. — Им то приходится иметь дело с простоями, то в спешном порядке решать неотложные проблемы. И эти вопросы зачастую становятся более приоритетными, чем сами проекты, работа над которыми может затягиваться на долгие годы».
Пилевски говорит, что, когда он пришел в A. G. Edwards, дела там обстояли именно таким образом. Чтобы решить эту проблему, он перевел менеджеров проекта из отдела управления проектами в функциональные отделы. Так они смогли лучше понять текущую ситуацию. Когда они работали в отделе проектирования, им не приходилось сталкиваться с изменениями, происходившими в ИТ-системе в результате их работы. Теперь же степень участия менеджера в работе над проектом заметно увеличивалась, так как ему приходилось ежедневно сталкиваться с этой системой.
Также была введена новая система составления отчетов, заметно облегчившая задачу функциональных менеджеров, которым иногда приходилось работать сразу с несколькими проектными менеджерами. Теперь же они взаимодействовали с одним проектным менеджером, прикрепленным к их функциональному отделу. Кроме того, функциональные менеджеры получили доступ к отчетам в системе Primavera, в которой было четко обозначено, за какие проекты отвечает их отдел, благодаря чему они могли планировать распределение рабочей силы.
Достижение доверия
В настоящее время ИТ-отдел брокерской фирмы находится на подюеме. Его сотрудники доказали свою способность эффективно руководить проектами и помогать компании в достижении поставленных целей. Проваленные проекты остались в прошлом. «Теперь мы имеем большую прибыль, так как научились более эффективно управлять нашими проектами», — говорит Паркер.
А как же обстоят дела с проектом по переходу со старой аппаратной базы на новую, ради которого его и пригласили в эту компанию? Паркер говорит, что первый этап этого многолетнего проекта завершился достаточно гладко. Как и планировалось, к маю 2005 года проектная группа успешно заменила старую правовую систему на новую. Несмотря на то, что бюджет был превышен на 5,5 %, Паркер сказал, что «все остается в рамках установленных показателей». Руководство A. G. Edwards уже выделило средства на выполнение последнего этапа проекта, который планируется завершить к 2008 году.
«Мы проделали колоссальную работу, — говорит Паркер, — Образно говоря, из тысячи усовершенствований, которые мы могли бы осуществить, реализовано приблизительно семьсот. Остались последние триста».
MERIDITH LEVINSON. When Failure Is Not an Option. CIO MAGAZINE. JUNE 1, 2006
8 шагов к совершенному проектному менеджменту
1) Проанализируйте удачные текущие проекты и ознакомьте сотрудников ИТ-отдела с результатами, чтобы они знали, к чему стремиться.
2) Обюясните подчиненным, каковы должны быть результаты качественного управления проектом и что сулит компании удачная реализация проекта.
3) Организуйте проведение управленческих тренингов для всех менеджеров, чтобы помочь им почувствовать уверенность в себе, повысить их уровень знаний в области коммерческой деятельности и подготовить их к переменам, которые ждут компанию по мере реализации проектов.
4) Проводите обучение для сотрудников по всем новым управленческим методикам, используемым вами.
5) Расскажите об инновациях своим клиентам. Убедитесь, что они хорошо понимают суть новых процессов и практик. Если они неодобрительно отнесутся к ним, вы обречены на неудачу.
6) Поощряйте личную ответственность друг перед другом менеджеров проектов и функциональных менеджеров, постарайтесь сделать так, чтобы их каждодневная работа была гармонична.
7) Отслеживайте степень реализации проектов сами и держите в курсе своих подчиненных, чтобы те в свою очередь чувствовали ответственность за успешное завершение проектных работ.
8) Поощряйте регулярную и эффективную взаимосвязь менеджеров проектов со спонсорами и акционерами. Оценивайте их деловые качества не только по способности реализовать проект в требуемые сроки не выходя за рамки бюджета, но и по тому, каково значение их проекта для деятельности компании в целом.