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

Олег Пашинин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интересная статья, но если пункт к пункту 2 вы относите только то, что процитировали:
''2. Непрофессионализм участников проектов
«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…». Джоэл Спольски, «Джоэл о программировании».''
то я бы еще отметил тот факт, что сами заказчики иногда не знают, что хотят, и в этом я думаю заключается их непрофессионализм... И в последствии чего и получается пункт №4.
Если все так и подразумевалось, то беру слова обратно...
P.S.-хорошие советы, тем более от Исполнителя и для Заказчика.

Финансовый директор, Барнаул

''По оценкам некоторых экспертов, количество таких проектов доходит до 60%''.
По личному опыту считаю что это процент на уровне 75-80%, а некоторые проекты только со 2 или 3 раза получаются.

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

Господину, автору статьи, следует пойти поработать в команду Исполнителя.

Руководитель проекта, Екатеринбург

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

Финансовый директор, Иркутск
Дискуссия здесь неуместна - автор статьи прав на все сто. За грамотную, непредвзятую статью (ведь ИТ-специалисты никогда открыто не признаются, что дурят народ, доверчивый к техническому прогрессу))) спасибо.
Александр Власенко пишет: Господину, автору статьи, следует пойти поработать в команду Исполнителя.
От исполнителя статью и прочитали ;)
Нач. отдела, зам. руководителя, Москва

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

Генеральный директор, Уфа

Не жадность губит It-проекты. А недостаток жадности :-). Все, что происходит на обычном проекте описано правильно, с хорошим юмором, кое-где переходящим в добрый сарказм. И вывод хороший - выгнать некомпетентную команду как можно быстрее :) А вот дискуссию на тему, что же сделать, чтобы обычный проект получился при обычной команде, можно и продолжить. У меня простой рецепт. Нужно больше денег и времени! Риски - неизбежны. ТЗ будет кривым, хоть ты у...ся. Спецы исполнителя будут сопротивляться изменениям до последнего, так, как будто бьются с врагом Родины. Будут меняться и требования, и специалисты Заказчика. В жизни не увидите полностью компетентную команду Исполнителя. Ну и что? Все это решается простым увеличением бюджета по мере необходимости. Или закладыванием рисков в начальную цену простым увеличением ее в три раза. Готовность Заказчика платить, не жадничать - очень важна. А вот готовность Исполнителя браться за крупный проект за три копейки из-за недостатка жадности и конкуренции просто опасна.

Генеральный директор, Уфа
Александр Власенко пишет: Господину, автору статьи, следует пойти поработать в команду Исполнителя.
Нет, это будет лишним. Все что надо, он уже знает. Вы обратили внимание на сарказм в рекомендации по подбору проектой команды? :-)
Руководитель проекта, Екатеринбург
Александр Посконный пишет: Считаю, что хороший Исполнитель с опытом способен узнать Заказчика с такими ''недостатками'' и вовремя отказаться от проекта, если не знает как им противостоять. Иначе - это жадность, из-за которой так низок процент успешных проектов.
Это точно жадность. Порой трудно его узнать на анчальном этапе. Это как принимать человека на работу. На собеседовании это одно, а когда начинает работать это порой бывает нечтно другое.
Александр Власенко пишет: Господину, автору статьи, следует пойти поработать в команду Исполнителя.
Я работала в проектах с обоих сторон. Знаю, точно если команды Исполнителя и Заказчика начинают сопротивление, то проект как миниму будет затянут. Обоим командам нужно на одну цель - успешная реализация проекта. Однако,очень много политических моментов вылазит и подковерной войны.
Управляющий директор, Самара
Елена Дегтярёва,
ведь ИТ-специалисты никогда открыто не признаются, что дурят народ, доверчивый к техническому прогрессу)))
Я был бы счастлив найти людей, ''доверчивых к техническому прогрессу''. Даже не так: ''неравнодушных'' (доверие сам создам - это моя работа). При выполнении этого главного условия моей работы - попробовал бы кто у меня задурить..! Чтобы преодолеть равнодушие людей к прогрессу, искоренить потребительское отношение (к ИТ, в частности) - что только ни приходится делать.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
Цифры и факты
Арестован М.Калви

Персона дня: Басманный суд арестовал основателя инвестфонда Baring Vostok Майкла Калви.

США: новые жесткие санкции

Тренд дня: Сенаторы США подготовили новый законопроект о санкциях против России.

Япония готова к долгим переговорам

Тренд дня: Япония может изменить стратегию переговоров с Россией по мирному договору.

Airbus прекратит производство A380

Факт дня: Airbus прекратит производство самолетов A380.