С широко закрытыми глазами

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

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

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


Ошибка первая: главное — ввязаться в драку


Увы, абсолютным лидером по количеству провалов и созданных сложностей является подход, при котором мы ставим себе цель «взять проект любой ценой». Ресурсы? Нет, не слышали. Ну, или вариации: ресурсы есть! То, что профиль другой — немножечко не важно. Перепрофилируем. А то, что java и delphi — технологии разные... ну так это так, фактор второго порядка. У нас же есть программисты, которые, наверное, обрадуются возможности... Да, а что delphi за вечер не освоить? Жаль-жаль. Ну ладно, тогда два вечера есть в наличии, о’кей. И да, проект связан с hiload.

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

В итоге большая часть (примерно процентов 70) такого рода проектов заканчивалась ничем. А некоторые подобное попытки даже приводили к закрытию инициировавшей проект компании (речь идет о небольших предприятиях) либо к существенным убыткам (в случае с госконтрактами — черный список поставщиков и гигантские штрафы).

Что можно сделать, чтобы не совершать данной ошибки? С одной стороны, всё очень просто: достаточно лишь внимательно и вдумчиво оценить свои силы и возможности для реализации проекта. Понять, что он представляет собой по сути для компании: штатный проект (типовая деятельность), немного нестандартный проект (похож на то, что уже делается либо делалось и есть некий опыт в этой области), нестандартный проект (такого рода проекты напрямую не выполнялись, но компетенции хотя бы частично есть), нестандартный высокорисковый проект (подобные проекты не делались и компетенций нет) либо просто проект в неизвестной области (такие проекты не делались и область проекта неизвестна). Если проект находится в нижней области приведенной шкалы риска, то за него можно браться и, скорее всего он будет реализован. Если в верхней — то обязательна оценка рисков и разработка стратегий работы с ними. Причем это должна быть не просто «стратегия на бумажке», писать ее следует с пониманием, что, вероятно, придется ее применять. Фактически для высокорисковых либо неизвестных проектов нужны не просто оценки рисков, но и солидный бюджет на их покрытие. Я сталкивался с ситуациями, когда новые проекты такого типа делались по принципу внутреннего стартапа, на который выделяется определенное финансирование и который можно было прекратить в любой момент, причем не только по финансовым причинам. Подобное отношение к особенно большим и рискованным проектам либо проектам с высокой неопределенностью мне кажется достаточно разумным — с точки зрения того, что стартап «если что» закрыть намного проще, чем основную организацию. Да и контролировать его бюджет намного проще — нет трат, которые «размазаны» по другим активностям.

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


Ошибка вторая: не по Сеньке шапка


Это ситуация, обратная рассмотренной выше, когда от перспективных проектов отказываются потому, что компания считает, будто не сможет выполнить проект. Причины самые разные — нехватка ресурсов, например. Или опасения не выдержать сроки и/или вовремя не сделать некие существенные части проекта из-за отсутствия опыта, компетенций и т. д. Кстати, я сталкивался с подобной позицией, и в 90% случаев оказывалось, что реальная причина заключается в том, что компания печальный опыт, и вот теперь, обжегшись на молоке, дует на воду. Фактически это означает, что для всех проектов, кроме штатных, зажигается «красный свет». Позиция, на самом деле, имеет право на жизнь, правда, есть несколько «но».

Первое «но» состоит в том, что компания, придерживаясь стратегии производства только штатных проектов, сознательно отсекает от себя как возможности развития, так и новые рынки, фактически обрекая себя на стагнацию. Потому что, к сожалению, в мире бизнеса не работает unix-way (ситуация, при которой одна команда-утилита делает свое дело так хорошо, как только возможно, не покушаясь на «соседние» утилиты).

Второе «но» заключается в том, что даже при такой стратегии можно пропустить «черный проект», то есть проект, который, с одной стороны, выглядит как штатный, а с другой — им не является.

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

Что можно посоветовать, если вы, как РП или РПО попали в подобную ситуацию? Если вы видите перспективу в проекте, постарайтесь ее оцифровать. А также оцифровать риски и степень рисков. Разговаривайте на языке цифр. Возможно, стоит начать с малого — сделать один небольшой проект, с минимальными рисками. Потом еще один. И так далее, постепенно «раскачивая» корпоративные стандарты.


Ошибка третья: ошибка мотивации


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

Ситуация № 1. Проектная команда финансово не мотивирована вообще. Работаем за зарплату. С одной стороны — прекрасно, потому что люди получают базовую безопасность. С другой — далеко не все члены команды имеют высокую самомотивацию, и, сказать честно: а какая разница, что и как будет сделано? И будет ли сделано вообще... зарплата-то гарантирована!

Для того чтобы избежать данной ошибки, имеет смысл для проектных команд как минимум ввести премиальную часть. Но тут важно, чтобы она была «сверху» зарплаты, как бонус, к которому можно стремиться. (Важно выставить такие условия получения бонуса, при которых он будет достижим. На мой взгляд, суммарный бонус не должен превышать 20–30% дохода за период работы каждого сотрудника над проектом.)

Читайте также
Как построить систему информационной безопасности, чтобы она обеспечивала защиту на уровне, превосходящем тех, кто наименее подготовлен к угрозам.

Ситуация № 2. Проектная команда работает «на бонус», имея минимальную зарплату. Я считаю данную ситуацию одной из самых плохих, потому что в итоге, как правило, приводит к тому, что сотрудники идут на все, лишь бы получить бонус в полном объеме. То есть сильно страдает качество, во главу угла ставится формальное исполнение обязательств. Фактически введение подобной схемы мотивации представляет собой попытку «пересадить» схему мотивации сотрудника отдела продаж на ниву проектного управления... Проблема в том, что управление проектами — иная дисциплина, чем продажи. И как следствие, мотивационные схемы в продажах и управлении проектами просто не могут быть одинаковы.

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

Хорошим примером служит такая ситуация: в некой компании сотрудники получают среднюю по рынку зарплату. При начале проекта бонус всех членов команды составляет 10–30% от оклада (в зависимости от вклада в результат и роли в проекте). При этом у РП есть право менять членов команды из свободного пула ресурсов. При достижении всех целей проекта (они, кстати, оцифрованы и измеримы — по-другому там проекты не запускаются) команда получает 100% бонуса. При отклонениях бонус снижается. Таким образом, получается относительно сбалансированная и самоорганизованная ситуация, когда членам команды выгодно работать с полной отдачей и без подтасовок.

Ситуация № 3. Ставка исключительно на нематериальную составляющую мотивации. Это когда проводятся командообразующие мероприятия, чай, кофе, плюшки, взращивается командный дух... На все это тратятся немалые средства. При этом материальная мотивация или отсутствует, или находится в зачаточном состоянии. В итоге, у команды проекта начинает возникать закономерный вопрос: «Не проще ли все эти деньги потратить на дополнительный заработок для нас, любимых?» Такая вот получается демотивация через мотивацию.

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


Ошибка четвертая: игнорирование реальности


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

Ситуация № 1. Игнорирование других игроков рынка и конкурентов. У меня был случай, когда требовалось получить ПО с некоторыми характеристиками. Решение руководства клиента было «лобовое»: «У нас есть штат программистов, напишут». Составили ТЗ, посчитали трудозатраты. Получили сумму, втрое превышающую стоимость тиражируемого решения, существующего на рынке, — при сроках разработки порядка года. В итоге проект было решено не открывать, а обойтись внешней закупкой. Это с моей точки зрения однозначно позитивный сценарий. В негативном сценарии компания начала бы самостоятельную разработку в области, где у нее не имелось высоких компетенций, полученное решение наверняка потребовало бы поддержки и отладки. И самое главное — на период разработки и отладки решения были бы недоступны ресурсы задействованных на проекте разработчиков, аналитиков и пользователей.

Что делать при такой ситуации? Мне кажется, что перед тем как запускать любой проект, просто по умолчанию необходимо делать обзор рынка на предмет наличия планируемых результатов проекта. И если таковые будут обнаружены, нужно подсчитать, что выгоднее: сделать проект самостоятельно или приобрести стороннее решение. Это если речь идет об удовлетворении неких внутренних запросов. Если же мы говорим о выводе на рынок нового продукта, то оценка конкурентов и общего состояния рынка просто необходима, что называется, must have. В противном случае велики риски, что продукт, представляемый рынку, будет изначально проигрышным, невостребованным.

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

Что можно было бы сделать? Рассмотреть стратегии, которых придерживались поглощенные компании на своих рынках, и обеспечить плавный переход бренда в глазах потребителей, с постепенным переходом позиционирования (если проект вообще надо было делать, но об этом можно сказать только по итогам расчетов и анализа).

 

Ошибка пятая: отсутствие культуры работы с рисками


Эта ошибка характерна для многих, даже очень зрелых компаний. Дело в том, что у нас вообще слабо развита риск-культура. Это выражается в эмоциональном стиле принятия решений. Что, в свою очередь, накладывает ограничения на риск-культуру. В самом жестком варианте тот, кто говорит про риски, начинает рассматриваться как диссидент, оппозиция. А между тем присутствие хоть какого-то жизненного плана управления рисками способно существенно помочь проекту в момент, когда «что-то пошло не так». К сожалению, по теме могу привести только «плохие» кейсы, когда случалось что-то изначально «не предусмотренное», то есть срабатывал риск. Причем этом решения по риску приходилось принимать в авральном режиме, с низкой степенью проработки, и,как итог это приводило к финансовым потерям.

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

***

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

 

Опубликовано 26.01.2018

Похожие статьи