Как продать reference

Немного курьезный случай, тем не менее, это вполне рабочая методика. Дело было в 2006 году, когда я занимал должность руководителя проектов финансового управления в одном известном иностранном банке.  В зону моей ответственности входило замена системы бухгалтерского учета в соответствии с РСБУ. Подрядчиком выступала одна компания из страны ближнего зарубежья. Компания не сильно известная, но предлагаемое ею решение вполне способно было занять свою нишу, по причине распространенности в нашей стране автоматизированных банковских систем (АБС) иностранного производства.  Кто в теме, тот  поймет, о какой нише идет речь:) Проект сложный, с кучей нюансов, за пару лет содержание проекта поменялось чуть ли не наполовину.  В процессе подготовки к запуску в опытную эксплуатацию, выяснилось, что важный функционал был упущен в ТЗ и соответственно реализован не был. Подрядчик понимал ситуацию и тем не менее выставил оценочную стоимость трудозатрат по доработке на полную катушку. Без данного функционала результаты проекты не были достигнуты в нужном объеме. Денег в бюджете не было.

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

  1. Доработка требуемого функционала за счет ресурсов подрядчика, и как следствие — успешный запуск в опытную, а затем и в промышленную эксплуатацию. 
  2. Успешная продажа проекта тем самым потенциальным клиентам. 

  Морали у этой истории тоже две:

  1. Для подрядчика: Удовлетворение ожиданий заказчика стоит в некоторых случаях дороже стоимости фактических трудозатрат.
  2. Для заказчика: Для достижений целей проекта, в некоторых случаях нужно уметь распознать нужный момент и потенциальную возможность. Не путать с прямым шантажом.   

Передача в прямое управление

Допустим, имеется организационная структура, в которой присутствуют два проектных офиса. Первый —  на уровне топ менеджмента (далее «BPMO»), второй — в ИТ. Имеется комплексный проект, включающий в себя как изменение бизнес процессов, так и изменение функциональности информационных систем. Начальные фазы проекта – инициация, первоначальная оценка бюджета, защите на проектном комитете, формирование проектной команды и прочее, вплоть разработки и согласования модели бизнес процессов  «TO BE» идет по плану и без особых проблем.  

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

Данный подход имеет сразу несколько преимуществ:

  • Эффективность коммуникации сразу возрастает за счет уменьшения количества участников.

  • Проектный менеджер  BPMO по своей сути обладает большими полномочиями в части влияния на ключевые параметры проекта: бюджет, сроки, функционал.

  • Также он имеет большее влияние на вендора, как с точки зрения исполнения текущих контрактных обязательств, так и с точки дальнейших перспектив взаимоотношений.

Разумеется, необходимым условием успешности описанного подхода является наличие у менеджера соответствующих компетенций, позволяющих управлять ИТ проектом – так называемый «IT background»,  а также знание, хотя бы на высоком уровне, о функциональности затрагиваемых в проекте ИТ систем.