Разбор кейса: Недостижимое отставание

Что же, кейс «Недостижимое отставание» стал рекордсменом, как по количеству комментариев, так и по качеству и объему (текста комментариев, советов и т.д – где-то в 20 раз больше, чем история).

Очень сложно что-то добавить  к описанным  ошибкам? в управлении проектом в его классическом понимании. Управление вышло из-под контроля и никто не знает, в каком состоянии сейчас проект и как его сдать.

Что-то мне подсказывает, что проект этот с просторов СНГ и как решится подобный вопрос сдачи проекта можно догадаться («ресторан-откат»). Потому что нормальными проектными средствами этого не решить в недельный срок.

Давайте предположим, что этот проект нельзя решить «русскими методами» и пойдем до конца. Я попробую сделать акцент исключительно на взаимоотношениях Исполнитель-Заказчик

Disclaimer 1: Так как у меня в практике были подобные проекты, то многое из оригинальной истории я «воссоздал» из своего опыта. Анализ требовал намного больше фактов, чем было в истории.

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

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

Что нужно Заказчику:

  1. Система, которая выполняет функции бизнеса.
  2. Знать, что система в будущем будет «работать» (переводя на ИТ язык – дорабатываться и поддерживаться)

Что нужно Исполнителю:

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

«Козыри» Заказчика

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

Еще одним козырем является сотрудничество по другим направлениям. Если кроме этой системы есть еще другие направления, то Заказчик опять выигрывает. В случае конфликта пойдут репрессии на всех уровнях сотрудничества.

«Козыри» Исполнителя

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

Если Заказчик заинтересован в поставке именно этой системы в обозримом будущем, то другого Поставщика искать бессмысленно. Соответственно, можно идти на отказ делать хоть что-то в дальнейшем без четких договоренностей и задач.

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

Если посмотреть со стороны «козырей», то вроде у Заказчика сильнее карта, но козырь безысходности практически выводит их на одинаковый уровень. То есть, используя метод силы, изменить что-то в этой ситуации будет очень накладно для обеих организаций. Поэтому нужно смотреть на слабые стороны:

«Пробелы» со стороны Заказчика:

  1. Уже потрачено много денег и времени на тестовую эксплуатацию.
  2. Вероятно, нет человека, который знает статус проекта. То есть есть человек, который подписывает «бюджет», но нет человека, который знает «почему система сырая» и может отличить реальные проблемы от нечестных отчетов тех, кто не заинтересован в системе.

«Пробелы» со стороны Исполнителя:

  1. Затрачено большое количество ресурсов с надеждой на перспективу.
  2. Управление объемами работ и функциональными требованиями.
  3. В команде Исполнителя тоже не знают, почему систему называют «сырой».

Анализ проблем и пробелов со стороны Заказчика и Исполнителя показывает, что корень зла в том, что никто не знает общее состояние проекта. Насколько готова система и насколько это соответствует требованиям каждой группы из предприятия Заказчика. Поэтому сдача проекта будет идти бесконечно, как война на истощение (принцип: Too big to fail). Причем чем дольше это будет идти, тем сложнее будет сказать «Нет, больше не работаем над этой системой».

Вот именно эту проблему нужно решать в первую очередь!

Варианты решения:

(нереальный; потому что в практике не встречал) – Заказчик выделяет руководителя проекта со своей стороны. Этот РП заинтересован в успешной сдаче проекта. Он, взаимодействуя с РП со стороны Исполнителя, дожимает проект. В удачном случае наиболее дешевый и быстрый способ решения проблем.

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

(суд; вариант практически нереальный в СНГ) Проект останавливается. Возможны споры и суды, которые идут годами. Система не работает, денег не получили.

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

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

(банный) Русский вариант, когда подписание системы решится откатами. Обсуждать нечего. Не выиграет никто, кроме человека, получившего откат.

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

>>> Посмотреть другие кейсы и решения!

Oct 16th, 2011
  1. Vasko
    Nov 9th, 2011 at 22:28 | #1

    (нереальный; потому что в практике не встречал) – Заказчик выделяет руководителя проекта со своей стороны. Этот РП заинтересован в успешной сдаче проекта. Он, взаимодействуя с РП со стороны Исполнителя, дожимает проект. В удачном случае наиболее дешевый и быстрый способ решения проблем.

    Приятно сознавать, что являешься частью чего-то уникального :) Ведь это мой случай – я именно РП со стороны Заказчика.

  2. Dec 1st, 2011 at 18:42 | #2

    (реальный, вероятен) этот самый fixed price проект можно завернуть и затем продавать другим компаниям. в таком случае договариваемся с первоначальным Заказчиком об оставлении прав у Исполнителя. Заказчику хорошо – у него рабочая система. Исполнителю хорошо – у него потенциальный(!) продукт.

    (абсолютно реальный, один раз у нас такое было) происходит встреча топов, на которой Исполнитель честно говорит как есть, что им очень невыгодно и компания терпит убытки, и, как следствие, компания может закрыться. если Заказчик продолжает настаивать, то конечно увы, надо посылать его. в моем случае мы перешли с fixed price на dedicated (monthly payments) так как проект был ключевой для бизнеса Заказчика.

Leave a comment