Стратегические ошибки российского проектного управления
«Меняйся с тем, что изменяется»
Если взглянуть на гробницу Наполеона в парижском соборе Дома инвалидов, то на полу вокруг гроба можно прочитать названия покоренных полководцем городов. Среди них есть и «MOSKOWA».
Казалось бы, какое отношение это имеет к российскому проектному ИT-менеджменту? Однако факты таковы, что Наполеон завоевал Москву, но проиграл кампанию. К сожалению, российские ИT-реалии доказывают, что мы вновь и вновь повторяем ошибку Наполеона. Классические подходы в управлении ИT-проектами перестают работать. Причина неудач заключается в том, что ИT-руководство, а вместе с ним и руководители проектов виртуозно применяют тактические походы к управлению проектами, забывая о необходимости мыслить и управлять проектами стратегически. Что это означает на деле?
Ошибка № 1. Переоценка, а порой недооценка со стороны руководства компании возможностей собственного руководителя ИT-проектов
Очень часто СЕО, получая информацию от своего PM, забывает простую истину: не верь тому, кто говорит, что всё под контролем. Информация без детализации оказывается фикцией. Аналогично и сам PM, в свою очередь, забывает про это, получая информацию от сотрудников вверенной ему команды. Необходимо требовать детализацию получаемой информации и получать перекрестное подтверждение (approve) от всех участников проекта.
“Nullius in verba” (лат. «ничьими словами») – уже не одно столетие гласит девиз Британского королевского общества (основано в 1662 году с целью содействия успехам естествознания), в знак того, что оно будет полагаться только на свидетельства научных экспериментов, а не на слова авторитетов. Применительно к проектному управлению данное утверждение можно интерпретировать как «всё нужно подвергать сомнению».
Также крайне важно порой не то, что на виду, а то, что скрыто. И не то что сказано, а что не сказано. Важно, о чем умолчал руководитель проекта либо представитель заказчика.
Полагаться лишь на профессионализм руководителей ИT-проектов – неосмотрительная ошибка современных российских консалтинговых компаний. Практика показывает, что даже за две недели проекта его руководитель может сотворить то, чего за оставшиеся плановые сроки уже не исправить, причем не исправить как для текущего проекта, так и для смежных. В итоге – разрыв отношений с заказчиком по всем контрактам.
К основным причинам неграмотных действий руководителей ИT-проектов в российском консалтинге можно отнести следующие:
Поэтапная мотивация
Во многих российских ИТ-компаниях принята схема так называемого поэтапного премирования руководителей проектов: то есть в случае успешного завершения очередного этапа проекта PM получает долгожданную прибавку к окладной части. Что же происходит на практике? Руководитель проектов, видя, что ситуация по проекту ухудшается и через пару-тройку недель будет бум, а повлиять на это, по его мнению, он не может (либо не хочет, поскольку первое, о чем спросит его руководство, просигнализируй он об этом, – в чем причины ухудшения, а они могут быть в том, что это он допустил ошибку, недоглядел, не придал значения важному событию по ходу работ), просто промолчит, спокойно наблюдая за неизбежным. Потому что знает: этот бум случится после того, как завершится очередной этап проекта, так что у него есть все шансы получить солидный куш хотя бы по итогам текущего этапа.
Не секрет, что первый этап ИT-проекта (а это обычно «Проектирование») в большинстве случаев проходит успешно и плоды (проблемы) этого успеха заказчик и исполнитель пожинают уже на следующих этапах. Очень часто мы забываем, что проект – это не спринтерская гонка, а марафон: победа на первом отрезке еще ничего не означает.
Отсутствие опыта
Речь идет о ситуациях, когда PM не увидел, не отследил влияние контролируемого им проекта на смежные. По большей части это связано с отсутствием опыта либо, в более тяжелом случае, с зашоренностью взгляда. И если с первой категорией мероприятия по недопущению достаточно просты (закрепление курирующего руководителя проекта), то вторая категория – это уже халатность как со стороны конкретного руководителя проекта, так и со стороны руководства его компании, которое допускает, а возможно, даже пропагандирует такой зашоренный менеджмент.
Искажение информации
Искажение руководителем проекта информации, предоставляемой своему руководству, – одна из форм проявления непрофессионализма. Причем если обратиться к мемуарам великих разведчиков, то искажение информации – это грубейшая, а порой фатальная ошибка как для карьеры профессионала, так и для самого дела.
Кроме того, руководители проектов порой неумело прибегают к так называемому эффекту плацебо (ложь во спасение), полагая, что тем самым делают благое дело для проекта и своей компании, хотя в большинстве случаев это приводит к плачевным последствиям.
Необоснованная паника, которую может инициировать руководитель проекта прежде, чем дважды-трижды не перепроверит информацию, также оказывает негативное влияние.
Информация, передаваемая руководителем проектов своему руководству, должна обязательно проходить процедуру модерации.
Начну с того, для чего необходимо развитие личного бренда ИТ-директору. Причин несколько, и все они крайне важны.
Ошибка № 2. При принятии решения по одному из проектов не учитываются возможные негативные последствия этого решения на другие проекты
Причина в том, что PM начинает действовать исключительно в интересах своего проекта и не учитывает стратегические интересы и риски компании-заказчика, в которой происходит внедрение проекта, либо интересы и ход реализации смежных проектов в этой же компании. И, к сожалению, такой педантизм со стороны руководителей проектов приводит к очень печальным последствиям. Например к разрыву отношений с заказчиком не только по текущему, но и по всем совместным проектам плюс удар по имиджу ИT-компании. Последствиями же для самого заказчика могут стать остановка текущего и смежных проектов, но в некоторых случаях – остановка стратегического развития компании.
Ошибка № 3. Отсутствие регулярной обратной связи с заказчиком
Когда ИТ-компания полностью полагается на оценку статуса проекта от своего PM.
Работать надо на упреждение проблем, а не на тушение пожара!
Ошибка № 4. Невозможность со стороны руководства консалтинговой компании обеспечить режим оперативного взаимодействия (поддержки) своих PMов.
Зачастую в критические моменты проекта, когда решение необходимо принимать здесь и сейчас, требуется обратная связь от руководства, которую не всегда удается получить, и PM вынужден принимать решение самостоятельно. К сожалению, Суворовых и Жуковых в современном российском проектном управлении, мягко говоря, мало, и «брошенный» недальновидный PM может пообещать заказчику то, за что потом придется отвечать его компании. Институт онлайн-курирования руководителей проектов в ИТ-компаниях развит недостаточно.
Ошибка № 5. Пренебрежительное, формальное отношение к регламентам действий своих специалистов на проектах либо вовсе отсутствие таковых правил
Практика показывает, что критическую ситуацию удается выправить в большинстве случаев исключительно за счет автоматически выработанных действий. Аналогично и в проектном управлении: каждый сотрудник проекта, и тем более PM, должен четко знать и понимать свои действия в большинстве возможных типовых ситуаций. Ключевой набор таких ситуаций ИТ-профессионалам известен, но с завидной упорностью от проекта к проекту мы ищем решения к ошибкам, которые возникали ранее. Подобного рода правила (памятки) – при правильном их составлении и применительно к специфике конкретной ИT-компании – смогли бы внести существенный вклад в достижение успеха как отдельных проектов, так и в целом ИТ-компании.
Ошибка № 6. Непродуманная контрактная политика. Работа по принципу: сделка важнее реализации
Например, когда в текст контракта ради того, чтобы сделка состоялась, вместе с падением по цене закладываются потенциальные бомбы: такие условия, как «автоматизация только 16 филиалов из 20» при создании некой централизованной автоматизированной системы для некого холдинга, и т. д. То есть заведомо закладываются риски, которые с очень большой вероятностью выстрелят, но осознание которых для заказчика, а порой и для самой ИТ-компании придет, только когда проект уже начнется. Ситуация, когда приоритет имеет продажа проекта, а не возможность его реализации. Когда отдел продаж «отлично» (бездумно) работает, накидывая дрова (контракты) в печку (вспоминая советский мультфильм), не заботясь о том, что на выходе получатся горелые пирожки (проекты).
При этом высшее руководство понимает и принимает такую политику – политику, когда производственная часть захлебывается. Ситуация с современным ИТ-консалтингом похожа на ситуацию с самолетом, когда экипаж принимает решение сажать машину, но ее масса превышает максимальную посадочную и, по правилам, экипаж должен избавиться от топлива. Так же и ИТ-компания в лице своего отдела продаж зачастую ради получения первого транша и заключения контракта «сливает» контрактные риски, как лишнее топливо.
Первопричиной данной ошибки является другая ошибка:
Ошибка № 7. Неумение отказываться от проектов
Одна из отличительных черт профессионала в любой сфере – умение отказываться (от проектов, задач): умение еще на входе понимать и фильтровать. И современному российскому консалтингу сейчас необходимо научиться именно этому – отказываться от проектов.
Назовем еще две распространенные ошибки, не требующие особых пояснений.
Ошибка № 8. Отсутствие со стороны консалтинговой компании постоянного аналитического и риск-мониторинга как в рамках, так и за рамками ведомых проектов
Ошибка № 9. Отсутствие гибкости применяемых проектных технологий
Итоги
Большую часть указанных проблем можно не допустить при наличии в компании подразделения риск-менеджмента. Это тот орган, который сейчас крайне необходим в организме современного российского ИТ-менеджмента. Риск-менедежер для консалтинговой компании – этот тот же авиадиспетчер, работа которого для нас практически незаметна.
Вернемся к проектному управлению. Даже хорошо известный в мире проектного управления стандарт PMBok, знаниями по которому так любят щеголять многие руководители и рядовые PM российского консалтинга, содержит такие положения и рекомендации, как: «Команды проектов проводят совещания по планированию для разработки плана управления рисками. В совещаниях могут принимать участие менеджер проекта, отдельные члены команды проекта и заинтересованные стороны проекта, представители организации, отвечающие за действия по планированию рисков и реагированию на них» (PMbok 4ed., раздел 11.1.2). Далее: «В действиях по идентификации рисков могут принимать участие: менеджер проекта; члены команды проекта; команда управления рисками» (PMbok 4ed., раздел 11.2).
Но рекомендации эти современный российский консалтинг с завидным упрямством не применяет на практике, по-прежнему наивно полагая, что затраты на содержание специализированного отдела риск-менеджмента экономически невыгодны. И даже при этом не удосуживается собрать малейшую статистику по своей компании за год, чтобы увидеть реальную картину в цифрах: картину понесенных проектных убытков от непрофессиональных действий своих PM, от рисков, которые были заложены отделом продаж на этапе контрактования и выстрелили позже других.
Как писал Рэй Брэдбери: «В положении умирающего есть свои преимущества. Когда нечего терять — не боишься риска».
Опубликовано 28.10.2015