Как сделать провальный проект успешным?

Олег Пашинин

Проработав длительный срок в IT-сфере, начинаешь понимать, что как бы ты ни хотел, часть проектов проваливается. По оценкам некоторых экспертов, количество таких проектов доходит до 60%. Перефразируя классика, можно сказать, что все успешные проекты успешны одинаково, а каждый провальный - провален по-своему. В каждом случае можно найти свою ключевую причину провала. Вот некоторые из них:

1. Нереальные проектные сроки и бюджет

«…менеджера по маркетингу вряд ли особенно волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель - получить комиссионное вознаграждение или доставить удовольствие своему боссу». Эдвард Йордан, «Смертельный марш».

2. Непрофессионализм участников проектов

«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…». Джоэл Спольски, «Джоэл о программировании».

3. Политические интриги вокруг проектов

«…отличительной чертой безнадежных проектов является настолько сильное влияние политики, что она может свести на нет все усилия выполнить хотя бы какую-нибудь работу». Эдвард Йордан, «Смертельный марш».

4. Изменчивость требований к системам в ходе выполнения проектов

«Одной из самых распространенных причин неуправляемости проектов являются изменчивые требования». Роберт Гласс, «Факты и заблуждения профессионального программирования».

Причины разные, итог один – провал. Но он не приходит сразу. Провал терпеливо ждет своего часа, отмечая промахи, проблемы, конфликты, срывы сроков и другие свидетельства своего неизбежного торжества. Причины провала присутствуют, как правило, с самого начала проекта, но вряд ли кто-то готов закрыть проект на старте. Ведь главное - ввязаться в драку. Но чем больше усилий и (денег!) уходит на проект, тем меньше шансов его закрыть. Возникают все новые и новые проблемы, в которые вовлекается все больше средств и людей. Каждый член проектной команды самоотверженно включается в борьбу. Преодоление уже становится самоцелью: дорога – все, цель – ничто. Думаю, что и вам не раз приходилось наблюдать типичные этапы развития провального проекта.

Этапы развития провального проекта

  • Сроки предоставления технического задания начинают затягиваться. Беспокойства нет – это бывает.
  • Техническое задание представлено на согласование. У Заказчика возникает легкое недоумение - в документах слишком много «воды», часть требований не соответствует тому, что обсуждалось с проектной командой. Начинается процесс согласования. Все полны решимости быстро устранить недочеты.
  • Процесс согласования технического задания затягивается. Появляются первые признаки беспокойства в связи с нарушением сроков. К этому относятся с пониманием, ведь важны не документы, а сама система.
  • Подошел срок поставки первого релиза системы, который Исполнитель должен установить на оборудование Заказчика. Исполнитель сообщает, что все готово, но нужно подождать еще пару дней.
  • Установка системы идет полным ходом, но пока безрезультатно. Систему должны были установить еще две недели назад.
  • Сроки согласования ТЗ давно прошли, но это уже не очень волнует. Озабоченность связана с тем, что никак не удается наладить систему.
  • Система установлена, но работает плохо. Часть функционала не реализована совсем, часть реализована не так, как ожидалось, и все равно не работает из-за большого количества ошибок. Недовольство Заказчика нарастает.
  • Устанавливаются новые релизы системы, но каждый следующий релиз работает не лучше предыдущего. Протоколы встреч уже не ведутся. Встречи превратились во взаимные претензии. О том, что техническое задание до сих пор не согласовано, уже никто не вспоминает.
  • Составляются длинные списки ошибок системы, которые нужно устранить. Новые релизы системы содержат исправления новых ошибок, но обнаруживаются старые ошибки, которые были исправлены ранее в предыдущих релизах.
  • Исполнитель требует начала опытной эксплуатации системы и подписания актов приемки, но пользователи отказываются работать в системе, так как она им не нравится и часто падает.
  • Акты приемки этапа разработки технического задания подписываются с обещанием Исполнителя исправить все позднее.
  • Запаздывание проекта уже составляет 30% - 50%. ТЗ согласовывается задним числом.
  • Установлены, наконец, все компоненты системы. Основные критические ошибки исправлены, но работать в системе невозможно из-за неудобства функционала.
  • Заказчик просит переделать функционал. Исполнитель не соглашается без дополнительной оплаты, так как функционал разработан согласно ТЗ. Заказчик отказывается принимать систему. Идет долгий период непонимания, что делать с системой.
  • Происходят изменения на стороне Заказчика (меняются люди/процедуры/процессы и тому подобное). В связи с произошедшими изменениями становится понятно: чтобы хоть как-то начать работать в системе, ее нужно переделать в соответствии с произошедшими изменениями. Заключается дополнительное соглашение на доработку системы. Чтобы не потерять лицо, руководство договорилось объявить о новом этапе проекта.
  • Идет длительный этап доработки. Сроки превышены уже в два раза. Сотрудники Исполнителя и Заказчика устали от проекта, но не знают, как его прекратить. На проекте меняется руководитель проекта Исполнителя и часть проектной команды. Новая проектная команда заново собирает требования.
  • Заказчик понимает, что существующая система работать не будет. Старая технология работы кажется уже не такой плохой, по сравнению с новой системой. Заказчик максимально тормозит внедрение системы, не зная как выйти из этого внедрения.
  • Идет долгий процесс переговоров. В результате стороны договариваются о приемке системы. Размер денежного вознаграждения Исполнителю существенно снижен. Акты закрываются. Провал не нужен ни одной из сторон, поэтому по молчаливому согласию проект считается успешным.
  • Выходит пресс-релиз об успешном внедрении системы.

Вот он, наконец, долгожданный финал. То есть вроде бы не провал. Но мы-то знаем…

К чему были все эти бессонные ночи, мешки под глазами, ссоры с коллегами, убийство нервных клеток, если система все равно не работает, премий нет, а ожидаемая профессиональная удовлетворенность так и не наступила? Потрачен огромный бюджет, а что мы получили в итоге?

«Как сказал мне старый раб перед таверной:
'Мы, оглядываясь, видим лишь руины'.
Взгляд, конечно, очень варварский, но верный».
И.Бродский

А ведь было бы гораздо эффективнее направить усилия на благородное дело - сохранение средств родной компании при сохранении собственного здоровья и душевного равновесия. Иными словами – не пытаться спасти проект, а, наоборот, утопить его как можно раньше. Уверен, что вы уже знаете или догадываетесь, как это сделать.

Что необходимо сделать, чтобы провалить проект наиболее результативно.

  1. Изучите перед проектом резюме специалистов проектной команды Исполнителя. Отвергайте кандидатуры сотрудников до тех пор, пока вы не убедитесь в следующем:
  • Вам представлены наиболее молодые сотрудники компании Исполнителя, пришедшие в команду недавно и не имеющие проектного опыта.
  • Сотрудники проектной команды никогда прежде совместно не работали.
  • Профиль специалистов проектной команды максимально далек от вашей предметной области, а архитектура предложенного решения не соответствует инфраструктуре компании.
  • Руководитель проекта Исполнителя запуган и ведет себя неуверенно.
  • Проекты, которые выполняли сотрудники проектной команды, не были завершены или завершены неудачно.
  1. Поставьте нереально сжатые сроки проекта.
  2. Определите максимальное количество проектных документов, требующих согласования.
  3. Составьте предельно длинный список сотрудников, согласующих проектную документацию с вашей стороны.
  4. Затягивайте согласование технического задания. Отказывайтесь подписывать проектные документы, ссылаясь на несоответствие ГОСТам, внутренним стандартам вашей компании, слабую детализацию или несоответствие бизнес-процессам.
  5. Постоянно изменяйте требования к системе.
  6. Чаще проводите ротацию сотрудников вашей проектной команды и предметных специалистов.
  7. Если почувствуете, что проектная работа, тем не менее, начала стабилизироваться, попросите заменить проектную команду Исполнителя по причине срыва сроков этапов проекта. Начните вновь, с пункта 1.

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

Удачи на проектах!

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

В статье указано, что 60% ИТ-ишных проектов – проваливаются.
Сергей Губко сообщает (06.08.2010 08:16:40): «По личному опыту считаю, что этот процент на уровне 75-80%. А некоторые проекты только со 2 или 3 раза получаются».

Значит, тема, объявленная названием статьи – сверх-актуальная.
А что предложено к чтению? – Ёрничанье на противоположную тему.

Поэтому, Валерий Овсий, с Вашим сообщением (от 06.08.2010 11:37:57) я согласен 100%-но.

Руководитель управления, Москва

По мне так статья пустовата, тема не раскрыта, рассмотрен всего лишь 1 вариант развития событий.
И мне не встачалась ''повареная'' книга с рецептами решения всех случав проблемных проектов.

Мой ответ сегодня, на поставленный автором вопрос «Как сделать провальный проект успешным? » - никак, можно лишь зафиксировать убыток.

Директор по R&D, Москва
Олег Кашуба пишет: Впрочем, остановка проекта вовремя - не такая уже и плохая мысль. Но... к этому у нас не привыкли. Считается провалом. А ведь если ты уберег компанию от больших и бессмысленных трат - это же здорово.
Именно! Есть успешные проекты и успешные менеджеры проектов. Задача менеджера - или довести проект до конца (если он обещает быть усешным), или во-время остановить.
Руководитель, Москва
Очень заметно, что автор находится под большим впечатлением от ''Марша смерти''. Хорошая книга, актуальная не только для ИТ и вопросы, в ней поднятые - будут актуальны во все времена. Полагаю, автор хотел поделиться своими мыслями на тему того, что ''невозможные проекты'' - это отдельная песня, и они есть и будут во многих областях нашей жизни. Пример: ИТ в секторе государственного/муниципального управления, в которой (и с которой) я имею удовольствие работать. И предложил свой оригинальный выход для Заказчика :) Конечно, на полноценную статью это не тянет... так, короткая зарисовка. Подпишусь под комментарием Александра Абрамова - управление такими проектами больше искусство, чем наука.
Александр Абрамов пишет: Пришел к убеждению, что в провальных (вот-вот готовых сорваться в пропасть) проектах любые технологии следует заменять психологией. Иначе говоря, человек с механистическим мышлением на должности РП не вытянет его. Если даже взять итеративный подход: ''слепили колобка, обхлопали варежкой по бокам, прикинули - нравится/не нравится? Нравится - на следующей итерации наращиваем, не нравится - срезаем''. То как в этой ситуации определить ''сделал-не сделал''? Все равно должна быть база: набор критериев, контрольных примеров, которые на каждой итерации нужно переопределять, находить время для проверки и т.п. В ходе этого процесса возникает столько флуктуаций, что очки иной раз спрыгивают с носа. Не говоря уже про учащающийся интерес ''с небес'' о ходе работ... Считаю, единственное, что остается - это управлять ими (флуктуациями): аккуратно фиксировать (даже через силу), по ряду случаев - вставать в оборону, в режиме онлайн находить и объявлять противоречия; максимально перекидывать мячик на чужое поле. При этом в фоновом режиме создавая и расширяя себе пространство для маневра: срочно находя новый ИТ-персонал и обучая, обучая его, вводя в тему. Авось и удастся прогрызть этот полиэтиленовый мешок на голове! мне удавалось. Механист тут не у дел, только психолог. Вооооооот...
Единственное, чего не сказал автор (и другие участники обсуждения) - для таких проектов надо четко и вовремя (а не постфактум, как написал автор) определять критерии успешности. Грубо говоря, на одном полюсе успешности ''Заказчик все акты закрыл, денег заплатил но не работает и ничего не просит'', а на другом - ''Заказчик ничего не подписал, ни за что не заплатил но активно эксплуатирует систему и постоянно выдвигает новые требования''. Что для вас успешно? Идеал, который посередине? Тогда мы говорим не о ''невозможных'' проектах и автора статьи не критикуем :)
Генеральный директор, Уфа
Владимир Зонзов пишет: Значит, тема, объявленная названием статьи – сверх-актуальная. А что предложено к чтению? – Ёрничанье на противоположную тему.
А я вот статью распечатал и в комнате переговоров повесил. Хотя я - подрядчик ИТ. Пусть мои сотрудники посмотрят, посмеются. Я доверяю их разуму, и думаю, что они все поймут правильно ;-)
Генеральный директор, Уфа
Александр Абрамов пишет: Пришел к убеждению, что в провальных (вот-вот готовых сорваться в пропасть) проектах любые технологии следует заменять психологией. Иначе говоря, человек с механистическим мышлением на должности РП не вытянет его.
Вот полностью согласен, что успешное внедрение - это из области психологии. Успешно внедряют пооекты люди, которые сами по себе - успешны. Эти люди думают: - Вокруг замечательные люди и они меня поддержат - Все зависит от меня - Я всем управляю - Я сделаю то, что хочу - Я закончу этот проект ВО ЧТО БЫ ТО НИ СТАЛО ... Можно и продолжить - это первое, что пришло на ум :-)
1 2 4
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
В российских IТ-компаниях не хватает специалистов по кибербезопасности

Также компании отмечают высокую потребность в системных аналитиках.

 

Опубликован рейтинг лучших работодателей 2022 года по версии HeadHunte

За год список HeadHunter увеличился на 28%, финалистами рейтинга стали 1082 организации.

Россияне стали чаще конфликтовать на работе

По сравнению с 2019 годом, вдвое увеличилось число респондентов, когда-либо ссорившихся с коллегами и начальством начальством.

Две трети россиян думают о смене места работы в 2023 году

Больше всего хотят сменить работу респонденты из таких сфер, как маркетинг и управление персоналом.