Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Как не провалить ИТ-проект и остаться в рамках бюджета

Тим Уилсон

Менеджер проекта сидит в задумчивости, обхватив голову рука-ми: тщательно спланированный бюджет всего несколько месяцев спустя трещит по швам. Знакомая картина, не правда ли? Технические проблемы оказались гораздо сложнее, чем предполагалось сначала. Теперь для завершения проекта требуются дополнительное время и оборудование — следовательно, впереди неутешительная перспектива разговора с руководством на предмет выпрашивания новых денег.

Согласно исследованию компании Standish Group, затраты на ИТ-проект в среднем превышают отведенный под него бюджет на 43%. В прошлом году только 29% ИТ-проектов были выполнены в срок и в рамках бюджета, 53% проектов не были сделаны в срок или не уложились в бюджет, а 18% просто провалились.

Standish Group изучает опыт выполнения ИТ-проектов с 1994 г., и ее эксперты считают, что большинство компаний не в состоянии адекватно оценить ресурсы, необходимые для выполнения проекта, и часто их требования слишком завышены по скорости и недооценены по объему работ. Хотя половина проектов, вышедших за рамки бюджета, не превышают его более чем на 20%, это мало утешает.

Специалисты компании Artemis International Solutions, разрабатывающей ПО управления проектами и контроля их бюджета, считают, что большинство компаний уделяют достаточно внимания своим крупным и наиболее затратным проектам, чего нельзя сказать о сотнях небольших проектов, планирование и контроль в которых налажены из рук вон плохо.

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

Полную версию данной статьи смотрите в 14-ом номере журнала за 2005 год.

Как не потратиться впустую

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

Эксперты советуют начинать с известной области. Например, стоимость технического обеспечения данного ИТ-проекта обычно легко рассчитать. Чтобы определить ее, можно основываться на ценах поставщика или провести инвентаризацию имеющегося оборудования. Стоимость пакетов программ также заранее известна, хотя она может варьироваться в зависимости от требуемых дополнительных модулей, особенностей внедрения и тестирования. Также можно подсчитать стоимость часа работы ИТ-персонала (исходя из месячного оклада), но наибольшую сложность для менеджера проекта составляет оценка необходимого количества часов для выполнения проекта. Продолжительность проекта является наименее предсказуемым фактором.

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

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

Даже после того, как вы все это выполнили, было бы неплохо включить в бюджет умеренную сумму на случай дополнительных затрат. Большинство опрошенных для данной статьи ИТ-менеджеров сказали, что они включили в бюджет “страховой запас” в размере 10%, чтобы в финансовом отделе не паниковали в случае возникновения незначительных проблем. Но если вы постоянно переоцениваете бюджет на ваш проект, то вы блокируете средства, которые могли бы пойти куда-нибудь еще, а делать это вы сможете только до тех пор, пока вас не остановит руководство.

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

Многие эксперты советуют менеджерам проектов рассчитать возможные непредвиденные расходы, предварительно оценив риски до того, как “застолбить” бюджет. Расчет рисков дает возможность оценить как потенциальные проблемы, с которыми может столкнуться проект, так и то негативное воздействие на бизнес компании или другой ИТ-проект, которое возникнет в случае задержки проекта или перерасхода средств.

Часто взаимозависимость графиков работ и бюджетов не берется в расчет в программах управления проектами, например в Microsoft Project или в свободно распространяемой программе Open Workbench, которые призваны помочь в планировании проектов, создании графиков работ и контроле за выполнением проекта. По этой причине компании предпочитают использовать ПО управления портфелем проектов, такое, как Changepoint Portfolio Management или Artemis, в котором реализованы общее хранилище бюджетов проектов и контроль временных ограничений. Средства управления портфелем проектов стандартизируют процесс финансового планирования, установку приоритетов ИТ-проектов и позволяют проследить влияние измененного ресурса на множество проектов.

Программный пакет Artemis с его начальной стоимостью 50 тыс. долл. подходит далеко не всем компаниям. Для небольших фирм можно предложить набор руководств COBIT Quickstart по разработке ИТ-проектов и их бюджетов стоимостью 50 долл. Система COBIT (Control Objectives for Information and Related Technology) представляет собой обширный набор документов, включающий в себя и некоторые указания по управлению портфелем проектов.

Будьте в курсе

Хотя большинство проектов выходят за рамки бюджета из-за неточных первоначальных расчетов, некоторые в него не укладываются вследствие недостатка контроля. Многие организации используют программные средства по составлению графиков работ, чтобы отслеживать степень готовности проекта, но они не ведут точного учета потраченного на проект рабочего времени сотрудников и других затрат, которые могут привести к тому, что проект постепенно станет убыточным. Часто руководители ИТ-отделов считают, что самое главное — это закончить работу вовремя, поэтому иногда при пересмотре плана проекта они могут потратить больше ресурсов, чтобы успеть все сделать в срок.

Существует множество способов контроля бюджета: от периодических совещаний и общего файла Excel до сложных программных средств по управлению бюджетами взаимозависимых проектов (те же Artemis и Changepoint). Хотя многие опрошенные нами ИТ-менеджеры отдавали предпочтение интерактивным средствам контроля за бюджетом, некото-рые заявили, что вообще не нуждаются в подобном ПО. Однако все они согласились, что для нормального ведения проектов необходимы регулярные совещания и составление отчетов о текущем их состоянии.

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

Специалисты из Standish Group рекомендуют вместо контрольных точек сфокусироваться на “опорных рубежах”, или заметных достижениях, при выполнении проекта. В примере с Web-сайтом таким опорным рубежом может служить завершение разработки домашней страницы. Это как раз тот момент, когда все части разработки собраны воедино и уже представляют собой некоторую практическую ценность, и, значит, вы можете сравнить реальные затраты с теми, что запланированы в бюджете.

Во многих случаях бизнес-подразделения компании попросят о внесении “незначительного” изменения в проект, когда он уже наполовину выполнен, и ИТ-отдел соглашается. Но такие “незначительные” изменения могут сильно повлиять на длительность проекта и его бюджет, иногда даже коренным образом, поэтому любые предлагаемые модификации следует тщательно изучить как техническим экспертам, так и руководителям бизнес-подразделений. На этот случай в ПО Artemis встроено средство имитационного моделирования, позволяющее менеджерам вносить изменение в проект, а затем рассчитать его влияние на бюджет и ресурсы.

Потеря контроля

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

По мнению экспертов, в данном случае компания может действовать двумя способами: пересмотреть бюджет, попросив еще денег, или “срезать углы”, тем самым выполнив проект лишь частично. Практически все опрошенные ИТ-менеджеры проектов пытались урезать проект, и большинство из них потом пожалели об этом. Урезание означает, по сути, изменение всего проекта, чего нельзя делать без соответствующего согласования с руководством и со всеми непосредственными пользователями.

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

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

Бывает, что лучше вовсе закрыть затянувшийся проект, чем потерять еще большие деньги. В январе 2005 г. ФБР сдала в утиль почти готовый проект Виртуального архива уголовных досье стоимостью 170 млн долл., решив подождать до 2006 г., пока не будет реализована более совершенная специализированная система. Что ж, данный проект был признан критически важным, и при этом он хорошо финансировался. Но лишь такие могущественные ведомства способны решать свои проблемы подобным образом, просто добавив еще денег..


www.rusprofile.ru/codes/620000




  
14 '2005
СОДЕРЖАНИЕ

бизнес

• Как не провалить ИТ-проект и остаться в рамках бюджета

• Белая Магия ИТ, или как сберечь ваш бюджет от проходимцев

• Мировая индустрия call-центров в цифрах и фактах

• VoIP по-новому

инфраструктура

• Электропитание ЦОДа: анализ проектов

• Средства репликации данных помогают резервировать ихДон Маквитти

• Рынок мобильных и беспроводных систем развивается

• Не дайте радиочастотной идентификации застать себя врасплох

информационные системы

• Мобильная электронная почта: свобода или зависимость?

• Свободно распространяемые утилиты администрирования Linux-систем

• Тестируем ПО управления бизнес-процессами

сети связи

• В чем польза IMS

кабельные системы

• Новый взгляд на зоновые кабельные системы

• Как создать кабельную инфраструктуру для высоконадежного ЦОДа

• «ЦОД в коробке»

• Приоритет — технике безопасности

защита данных

• Бурлящие волны RFID


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх