Многие руководители проектов в сфере Business Intelligence (BI) часто задаются вопросом, почему иногда случается так, что в середине проекта всё просто рассыпается, заказчику вдруг результаты проекта становятся неинтересными, или неожиданно возникают проблемы «а мы совсем не это имели в виду» и становится проблематичным сдать разработанный продукт.
Или в погоне за большей удовлетворенностью заказчика поток изменений требований становится таким, что это приводит к потере рентабельности и срыву сроков. При этом мы приглашаем профессиональных руководителей проектов с сертификатами PMI или IPMA, которых правильно учили, что такое Project Management, которые составляют хорошо проработанные календарные планы, технические задания и контролируют ход выполнения всех работ, т.е., по сути, делают все как надо. Конечно, это случается не всегда и большинство BI-проектов весьма успешны, т.к. ими управляют опытные менеджеры. Но, всё же, это иногда случается.
На самом деле в отличие от многих других ИТ-проектов, проекты в области Business Intelligence имеют свои большие особенности, которые необходимо учитывать и в первую очередь менеджеру проекта.
Чтобы ответить на вопрос, почему BI-проект может неожиданно перестать быть актуальным заказчику или потерять рентабельность, сначала надо разобраться, а чем же BI-проект отличается от остальных ИТ-проектов. В этом может помочь классификация проектов, описанная В.И. Ананьиным [1] [2] на основе теории конфигураций бизнеса, разработанными Генри Минцбергом [3].
Следуя ей можно сделать вывод, что в реальных проектах могут наблюдаться устойчивые формы организации (стили). Владимир Игоревич предложил классификацию проектов по стилю, который определяет форму его организации и в значительной степени влияет на коммерческие и технические результаты проекта. Проекты могут быть типовыми, профессиональными, инновационными и политическими.
Не буду углубляться в подробности, описывать все стили проектов и связывать их с механизмами координации Минцберга − это подробно описано в работах В.И.Ананьина.
Если кратко, то типовой проект, например, это продажа и настройка коробочного продукта или инсталляция какого-то софта на большое количество компьютеров. Риски минимальны, проект легко просчитывается, составляются реально выполнимые календарные планы.
Профессиональный проект – внедрение большой системы, например, класса ERP, когда такое внедрение команда профессиональных исполнителей делает уже не в первый раз, когда все процессы, методология и методики уже отработаны, есть заготовки проектной документации. Здесь, как и в предыдущем проекте, замечательно применяются рекомендации PMI и IPMA.
Инновационный проект – первое внедрение подрядчиком новой для него крупной информационной системы, которое происходит с изменением многих бизнес-процессов в компании, где происходит внедрение. Заказчик и исполнитель выступают здесь как партнеры. Цель подрядчика – получить проектный опыт, цель заказчика – сделать данную систему «локомотивом бизнеса» [2]. Понятно, что риски огромные, проект протекает при постоянно появляющихся проблемах, которые требуют немедленного решения, все планы постоянно меняются и корректируются.
И самый рисковый проект – политический. В отличие от профессионального и инновационного проектов, где обязательно происходит изменения бизнес-процессов и спонсорами выступают обязательно кто-то из топов компании заказчика, в этом проекте спонсор – непосредственный менеджер, которому необходимо, например, оптимизировать подготовку некоторых отчетных документов или получить информационную панель руководителя в том виде, как он ее себе представляет. Это максимум начальник функционального отдела или управления. Если рассматривать проекты по внедрению технологий Business Intelligence не только с позиции руководителя проекта, но и с позиций аккаунт-менеджера, спонсора проекта, системного архитектора, проанализировав внешние условия, в которых зарождаются и протекают такие проекты, можно сделать вывод, что большинство BI-проектов имеют политический стиль.
Какие же отличительные особенности имеет политический проект? Основные:
- Доминирующий механизм координации – работа по прямым поручениям.
- С точки зрения стратегии внедрения – «Натягивание разрабатываемой системы на существующий бизнес» [2].
Почему практически все BI-проекты можно отнести к политическим? Потому что такие проекты, как правило, не затрагивают и не вносят изменений в бизнес-процессы компании. Да, они что-то оптимизируют, безусловно что-то улучшают, уменьшают время выполнения каких-то операций, связанных с подготовкой корпоративной отчетности, уменьшают время подготовки данных и их анализа, тем самым оптимизируя и улучшая системы принятия решений, скорее всего позволяют быстрее сформировать запрос и выдать необходимые данные на стол руководителя. Но такие проекты не меняют сформировавшиеся бизнес-процессы, они их только улучшают, поэтому в большей степени отражают не столько стратегию бизнеса, сколько внутреннюю специфику отношений между подразделениями организации.
При этом в процессе разработки BI-проекта мы всегда сталкиваемся с «диктатом заказчика». Один из спонсоров программы проектов крупной нефтяной компании, где внедрялось сразу несколько новых BI-систем, мне как-то сказал фразу: «Вы для нас гастарбайтеры, поэтому что мы говорим, то вы и будете делать». Конечно, это была шутка, но с очень большой долей правды, и это первый признак политического стиля проекта. Кроме этого, такой проект всегда сопровождается постоянными изменениями требований со стороны заказчика, которые отражают текущие часто меняющиеся проблемы функциональных бизнес подразделений и характер отношений между ними. И это тоже понятно, т.к. после начала проекта пользователи мало знакомы с внедряемыми технологиями, им сложно объяснить, что если они этот документ раньше готовили три дня, то после внедрения данного продукта у них это займет несколько секунд. Что после завершения разработки они сами смогут осуществлять доступ к интересующим данным и быстро их получать в виде таблиц или графиков. Поэтому пользователи не всегда в полной мере могут представить себе заранее, какой продукт они получат. И когда они видят первые результаты, то сразу увеличиваются «хотелки» (многим руководителям проектов хорошо знаком этот термин). Поэтому на первый план выходят не столько вопросы планирования работ и ресурсов, сколько управление требованиями и, как следствие, переработка всех планов после этих изменений, и по масштабам работ, и по ресурсам. В этот момент должно проявиться умение руководителя проекта, который должен анализировать каждое изменение требований и при необходимости выносить проблему на управляющий комитет для принятия решения по изменению либо Scope проекта, либо сроков, либо бюджета.
Таким образом в политическом BI-проекте планирование и контроль сроков и затрат носит обобщенный характер, при постоянном изменении требований заказчика возможны изменения постановки задачи, даже целей проекта, следовательно и все планы постоянно меняются и корректируются. Поэтому результаты BI-проекта часто сильно отличаются от документа «Требования заинтересованных сторон», т.е. тех видений, которые были у самого заказчика до начала проекта. И здесь в общем случае мало подходят стандартные и всем известные методологии управления проектами от PMI или IPMA, основанные на жестком планировании и контроле выполнения планов. Хотя многие области знаний, некоторые группы процессов, рекомендации по проектной документации, несомненно, не только можно, но и нужно смело брать на вооружение из этих стандартов. И именно поэтому в части управления проектом на первый план выходит спонсор проекта со стороны заказчика. Именно он является тем движущим звеном, который гарантирует успех (не без участия, естественно, руководителей проектов с обеих сторон), именно спонсор проекта является координатором отношений между обеими сторонами. Из этого следует и самый главный риск такого проекта – это потеря или смена спонсора. Небольшой пример, пилот-проект подсистемы отчетности в когда-то существовавшей торговой компании «Мир». Все формы отчетов делались по постановке задачи заместителя коммерческого директора. В период разработки на его место приходит совершенно другой человек. Появляются вопросы: «Да кто так анализирует продажи? Да что это за формы? А вот у меня раньше было так…, это всё надо делать совершенно иначе…». Выясняется, что новый заместитель коммерческого директора учился по другому учебнику. Результат проекта на грани полного краха. Полностью меняем постановку, переделываем проект по новым требованиям, добавляем витрины данных в хранилище, тщательно обучаем этого спонсора новому инструменту, показываем все его преимущества по отношению к анализу данных в привычном Excel. В результате получаем очень хороший отзыв, полное понимание и одобрение. Я думаю, что многие руководители BI-проектов могут привести аналогичные примеры, как теряется интерес к результатам проекта, когда в период техпроекта уходит или меняется его спонсор со стороны заказчика, то лицо, которое было инициатором этих работ и основным потребителем разрабатываемого продукта.
В некоторых случаях политические BI-проекты имеют инновационную составляющую и потенциально могут перерасти в инновационный проект. Умение руководителей проекта с обеих сторон заинтересовать бизнес в результатах проекта, во внедрении новых информационных систем, может в значительной степени повысить как значимость проекта, так и успех от его внедрения. Именно в этом случае проект по внедрению BI из политического может перерасти в инновационный. Например, внедрение уникального общекорпоративного хранилища данных, когда в результатах проекта заинтересованы практически все функциональные подразделения компании и спонсором проекта становится, например, финансовый директор или руководитель подразделения контроллинга, или когда внедряются инновационные инструментальные средства, при этом не только подрядчик, но и заказчик заинтересован в таком внедрении. Тогда обе стороны начинают выступать в качестве партнеров и обоюдно берут на себя все риски. Но на старте, как правило, любой BI-проект всё равно будет иметь политический стиль.
Разработчику всегда обидно, когда его труды выбрасываются в корзину. Чтобы этого не случилось, надо обязательно старательно продвигать свое решение, поддерживать лояльность спонсора проекта. Выяснять еще на этапе инициации проекта все проблемы пользователей, не ограничиваться только разработкой информационно-аналитической системы (ИАС) и документации, а доводить разработанную систему до бизнес-пользователей, заинтересовывать, обучать их работать в новой системе. Только в этом случае можно добиться хорошего отношения руководителей компании к данной разработке и получить положительный отклик от непосредственных пользователей. И огромная ответственность в этом лежит именно на руководителе проекта.
Особый вопрос – методика разработки BI-проекта. Часто приходится сталкиваться с требованиями заказчиков вести разработку в точном соответствии наших старых ГОСТов, которые разработаны, а вернее давно были переписаны с американских стандартов для разработки программного обеспечения, цитируя М.М. Жванецкого, «для ориентации ракет в безвоздушном пространстве». Понятно, что в такой предметной области никому в голову не придет тестировать недоделанный релиз сложной программы и выяснять «полетит или не полетит». Каскадный метод проектирования и реализации не всегда применим в BI-проекте. Здесь разработку предпочтительней вести по спиральному методу, постоянно показывая заказчику все промежуточные результаты, прототипы системы, которые могут быть выполнены на ограниченной предметной области или с ограниченным функционалом. На каждой такой итерации мы собираем все предложения и замечания пользователей и обязательно учитываем их в дальнейшей разработке, если надо, то корректируем согласованные ранее планы, вносим изменения в техническое задание. В результате такого итерационного подхода, когда на предварительных испытаниях пользователи говорят, что им нечего смотреть в нашей системе, что они все знакомы с данным продуктом и уже научились им пользоваться, это говорит об отличной работе руководителя проекта и команды внедрения.
Наибольшее внимание при подборе ресурсов для разработки BI-проекта уделяется технической квалификации специалистов исполнителя. Поэтому здесь на фоне главной роли спонсора проекта, руководитель проекта от исполнителя иногда может играть техническую роль, но тогда роль лидера берет на себя системный архитектор. Все решения в проекте, как правило, принимаются лидером, проектная бригада выполняет его поручения. Кто будет этим лидером, руководитель проекта или системный архитектор – зависит от личностных качеств обоих, лидерству научить невозможно, но идеально, если эти две роли соединяются в одном лице. Часто руководителями проекта становятся наиболее опытные разработчики, но в этом случае кроме хорошего знания инструментальных средств и умения проектировать ИАС, таким специалистам необходимо обладать знаниями основ проектного менеджмента, этому их надо обязательно обучить.
Отдельный вопрос – управление контрактом. Хотя это в основном забота аккаунт-менеджера, но часто и руководитель проекта может внести своё корректирующее воздействие в этот процесс. Как правило, в большинстве наших проектов по внедрению BI, с учетом того, что они имеют политический стиль, тип контракта – это фиксированная цена. При старте проекта определяются его рамки, всегда вызывает сложность определение объема трудозатрат, по которым должна определяться стоимость, разрабатывается календарный план. Все стандартно. Основные риски – недооценка трудозатрат, нечеткая постановка задачи, проблемы в работе инструментальных программных средств, постоянное изменение требований. И как следствие потеря результативности, либо рентабельности. Если с некорректной работой программного обеспечения менеджер проекта самостоятельно вряд ли справится, это забота техподдержки, то оценка объемов работ, сроков и четкое управление изменениями требований – это основные задачи руководителя проекта.
При контракте «фиксированная цена» руководитель проекта исполнителя должен фиксировать каждое изменение требований и оценивать его с точки зрения увеличения сроков и стоимости проекта, а затем аргументировать это перед заказчиком. Оформлять на это либо дополнительное соглашение, как приложение к договору, если у него есть на это соответствующие полномочия, или, в противном случае, выносить этот вопрос на управляющий комитет. Другой вариант – переносить какие-то работы на сопровождение. В противном случае проект может стать убыточным для исполнителя. В таких политических проектах, а тем более, если проект становится инновационным, в большем предпочтении оказывается рамочное соглашение, или контракт Time&Material, в котором для каждой стороны определяются источники формирования бизнес эффектов, принципы разделения рисков, а также принципы организации совместной работы. Оплата производится по реальному времени работы консультантов на проекте, а руководители проектов контролируют общий бюджет, чтобы он не превысил своего лимита.
И в заключении, успех любого менеджера проекта целиком и полностью зависит от проектной команды. Именно поэтому он должен пользоваться заслуженным авторитетом у своих коллег. Заслуженный авторитет – это 50% профессиональных и 50% человеческих качеств. Скорее всего, здесь и объяснять больше нечего. Если у руководителя есть оба «50%», только в этом случае он руководитель на все «100%».
Литература:
- Ананьин В.И., «К конкурентному преимуществу – через проекты». Журнал «Управление проектами и программами», 03(23) 2010.
- Ананьин В.И., «В поисках «правильного» стиля ИТ проекта». Журнал «Управление проектами», Март 2007 № 1 (6).
- Г. Минцберг, «Структура в кулаке. Создание эффективной организации», Питер, СПб, 2001.
Орфография и пунктуация в данном тексте сохранены в том виде, в котором они были предложены автором.
