Особенности проектного управления в кризис

Влияние кризиса на управление проектами очевидно: проекты ужимаются в объеме из-за безжалостно срезанных ИТ-бюджетов. Возрастает взаимное влияние проектов (даже совершенно не связанных по смыслу) — из-за конкуренции за ресурсы. На первый план выходят риски заморозки бюджетов и неплатежей за сданные этапы.

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

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

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

Микропроекты: стоимость проекта ниже, риск неоплаты минимален

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

• & ИТ-аудит текущего состояния инфраструктуры (отдельно для центра, отдельно для регионов);
• & планирование и выбор архитектуры решения;
• & выстраивание каналов связи в центре и регионах.

Впрочем, некоторые шаги целесообразно распараллеливать, например загодя начинать закупку оборудования, чтобы успеть к сроку.

И для заказчика, и для исполнителя это дробление может значительно упростить управление проектом, ведь, например, только на этапе выстраивания каналов связи в регионах нужно управлять десятками специалистов и подрядчиков — интернет-провайдеров. Не менее важно и снижение ресурсных и финансовых затрат на каждый этап и на проект в целом (15–25%), так как, скажем, на этапе оптимизации каналов не нужны ни дорогостоящие аналитики, ни специалисты по СХД. Исполнитель может занять их на других проектах, в запланированных заранее промежутках, а заказчик — не платить за лишние ресурсы. К тому же упрощается вынужденное дробление менее критичных для клиента этапов и перенос их на следующий год, если у заказчика закончились деньги. Технология микропроектов позволяет проводить эти изменения в более или менее штатном режиме и не оставляет у сторон ощущения, что проект находится в глубоком кризисе.

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

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

Лучше всего такую не вполне привычную модель работы на ИТ-проектах, по нашему опыту, воспринимает средний бизнес (200–500 сотрудников), способный критически оценить свои и чужие риски, ограничения существующей системы управления проектами и буквально за месяц ввести в нее снижающий эти риски новый компонент. Но здесь нельзя забывать и о втором обязательном компоненте модернизированной системы управления проектами — проактивности самого исполнителя.

Проактивность исполнителя: выносить вперед самое ценное и только нужное

Проактивность исполнителя должна проявляться сразу в нескольких обязательных действиях.

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

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

В-третьих, проактивный исполнитель должен искать и предлагать заказчику альтернативы привычным решениям (например, на базе Open Source, облаков или гибридных схем).

OpenSource: увеличиваем резерв времени и денег на проект

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

Что это за риски? Прежде всего — значительное растягивание во времени этапа предпроектной оценки, так как поставщиков «свободных» решений нужно найти и оценить, а сами решения проверить на наличие важных для проекта функций, актуальность версий. Надо оценить возможности дальнейшего развития, за которое отвечает (или, напротив, уже не отвечает) сообщество разработчиков. А так как в рамках серии замен проверять нужно достаточно много классов ИТ-продуктов (и ОС, и СУБД, и бизнес-приложения, и десктопные системы), сделать это самостоятельно для заказчика почти нереально. Выходом может стать быстрый подбор интегратора с нужными компетенциями, но на это все равно потребуется время, пусть и в три-четыре раза меньшее, чем при самостоятельном решении задачи. И это время надо заложить в тот же этап заранее.

Важно учитывать, что замещаемый и замещающий продукты наверняка будут неравнозначными, что исключает их замену «один в один». И здесь даже не важно, какое решение функциональнее. Главное, что они различаются. Поэтому в проектах перехода на Open Source нужно закладывать время и неизбежные ресурсные расходы на большой блок предварительной работы — не только в части оценки, но и в части доработки решения (включая детальный план комплементарных изменений). При этом придется комбинировать несколько подходов: дописывание нужных инструментов и функций; построение «обходной ветки» за счет внедрения сопутствующих систем, компенсирующих слабые места продукта, и на интеграцию с ними; перенос заведомо слабых функций замещающего продукта в поле уже работающих систем, что, возможно, повлечет за собой смену требований к аппаратной части проекта. А это — новые время и деньги.

Вот характерный пример. Проведенный нами цикл тестирования PostgreSQL показал, что с этой СУБД платформа бизнес-приложений заказчика работает на 15–30% хуже, чем с коммерческой СУБД, для которой платформа оптимизировалась. Этот недостаток можно компенсировать экстенсивно — применив более мощное серверное оборудование. Но, скорее всего, наилучшим решением станет дополнительный анализ кода запросов платформы к СУБД и их перестройка в более оптимальный для PostgreSQL вид. В обоих случаях потребуются эксперименты с разными версиями платформы и сборками СУБД, так как показанные ими результаты могут сильно различаться. Поэтому в этап реализации проекта нужно закладывать запас на устранение возможных шероховатостей (до 15-20% от времени на весь проект). Звучит неприятно, но на практике это далеко не всегда утяжеляет финансовую составляющую проекта на те же 15%, поскольку интегратор может взять значительную часть затрат на себя — например, выработку подходящих клиенту конфигураций «1С»+ PostgreSQL. Но рост затрат (как минимум на 5-7%) стоит заложить.

Отмечу, что этап предварительной оценки должен включать в себя и обязательную оценку экономической целесообразности внедрения СПО. Может случиться так, что внедрение комплекса нового ПО, оптимизация кода запросов, дозакупка «железа», рост сроков и стоимости проекта, а также затраты на обучение пользователей сделают переход не столь целесообразным, как первоначально казалось.

Узконаправленный аудит — средство правильно оценить проект

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

Скажем, крупной компании с развитой филиальной сетью нужно здесь и сейчас оптимизировать быстродействие «1С», чтобы информация по результатам продаж в регионах собиралась в общий отчет не за восемь часов, а за два (например, для обеспечения быстрого закрытия ежемесячной отчетности на предприятиях нефтедобывающей отрасли), и только потом двигаться дальше, внедряя другие модули учетной системы. Цена такого аудита составит 10-15% от стоимости всего проекта. Но полученные оценки дадут исполнителю возможность определить оптимальный путь решения задачи, не «перезакладываясь» при оценке затрат на проект. На рынке нередки случаи, когда такая страховка составляет более 50% бюджета проекта. Таким образом, эффект от предварительного ИТ-аудита с лихвой перекрывает затраты на него.

Каскад ИТ-аудитов как быстрое и дешевое средство снижения рисков и затрат

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

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

Может показаться, что микроаудиты усложняют управление проектами, так как к каждому этапу добавляется еще один, нулевой. Но множество белых пятен, снимаемых на каждом этапе, того стоит. Игнорирование же только одного риска, связанного с выбором неоптимального решения на проекте по повышению надежности и быстродействия учетных систем (покупка нового «железа» без оптимизации кода запросов к системе, выяснение, что выбор неверен, возврат к другому варианту, его использование, новые тесты), может увеличить длительность этапа в три-пять раз, а стоимость — на 50-60%. И к тому же спровоцировать штрафы и конфликты с заказчиком.

Процессный и проектный подходы к управлению ИТ — синергетический эффект

Уместно отметить, что наличие у компании процессов по управлению ИТ (собственных или «заимствованных» у подрядчика-аутсорсера) оказывает положительный эффект на качество управления ИТ-проектами и, что немаловажно, на способность проектного подхода к адаптации к новым условиям. Так, работающий процесс управления изменениями (стандартный процесс ITIL/ITSM, обеспечивающий максимально безболезненное внесение изменений в ИТ-среду) помогает реализовывать проекты быстрее и с меньшим числом рисков. Что, в частности, упрощает процесс миграции на OpenSource-решения, так как требуемая «обвязка» таких проектов (оценка, тестирование, план возврата в прежнее состояние) встроена в процесс управления изменениями. Это хороший пример синергетический эффекта от разных компонентов современного управления ИТ, о котором много говорится в теории, но который обычно сложно пощупать на практике.

Итого

Кризис — это не только повод для негативных прогнозов и настроений, но и изменение условий внешней среды, требующее подстройки к новым условиям и исполнителей, и заказчиков ИТ-проектов. Такая подстройка открывает поле для новых решений, в том числе и в сфере управления проектами. Несколько нетривиальных, но четких шагов (дробление проектов на микропроекты, выдвижение вперед самых критичных или дорогих для бизнеса этапов, каскад коротких и дешевых экспресс-аудитов на нулевом этапе каждого из них, предложение бюджетных аналогов: OpenSource, гибридных схем потребления ресурсов, облаков и др., проактивность интегратора, ИТ-процесс управления изменениями), если их применить в комплексе, существенно снижают главные риски: остановки/неоплаты, срыва сроков.

Эффект особенно велик в средних и крупных компаниях, в структурах с развитой филиальной сетью. А также в проектах, связанных с повышением производительности критичных бизнес-приложений (ERP, CRM), увеличением надежности и отказоустойчивости инфраструктуры, внедрением свободного ПО.