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

Олег Пашинин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Александр Абрамов +935 Александр Абрамов Управляющий директор, Самара
В условиях, когда Исполнитель не сторонняя компания (которая имеет возможность отказаться от проекта), а часть группы компаний (пусть и равная в Совете директоров с автоматизируемым Заказчиком), такие тезисы, как:
- мнение Исполнителя всегда важнее мнения будущих пользователей, поэтому лучше вообще не спрашивать мнения пользователей
Исполнитель еще на этапе предпроектного исследования знает, что в итоге получится у Заказчика, и лучше с этим смириться за названную цену, а то выйдет дороже
...обретают смысл вовсе не ироничный. Пользователей (ползователей!) в массе вообще нельзя и на версту подпускать к переговорному процессу, нужно учитывать требования только руководителей. Пользователей - только точечно, избранных, кто заинтересован в успешной автоматизации.
Управляющий директор, Ростов-на-Дону
Елена Дегтярёва пишет: Дискуссия здесь неуместна - автор статьи прав на все сто. За грамотную, непредвзятую статью (ведь ИТ-специалисты никогда открыто не признаются, что дурят народ, доверчивый к техническому прогрессу))) спасибо.
Согласен. Но проблема скрыта намного глубже. Есть проекты которые инициируются только ради проектов.. Тогда они на 99% провалены ещё до начала. Эту тему мне обсуждать не интересно, мне интересно, когда проект назрел и он не обходим. 1. Проблема которая возникает. IT -компании как и обычные люди ленивы по своей натуре, и соответственно проще продать решение несколько раз с различными ''доработками'', чем каждый раз начинать работу с ''0''. Но для заказчика с финансовой точки зрения зачастую разработка продукта с ''0'', окажется дешевле, чем адаптация готового продукта. Анализируя продукты созданные под конкретного заказчика и полученные из ''стандартного'' продукта, я пришёл к выводу, что последние имеют более сложные структуры и при их внедрении приходится ''перестраивать'' компанию под использование продукта. Созданный под заказчика продукт легко ''ложится'' в структуру компании и не вызывает ''эффекта отторжения''. Итак берём лучший Вариант, у меня как у заказчика есть потребность в продукте. Я смог найти IT компанию которая ''гарантирует'' предоставить мне ''продукт''. Вся Мы встречаемся и обсуждаем функционал и другие технические параметры продукта, проектная группа ТЗ... :idea: Вот тут кроется 1 подводный камень, приступает к работе на основании ТЗ,а потом уже начинает дополнительно наращивать продукт адаптируя его под предъявляемые требования. Необходимо по факту получения ТЗ, провести предварительную ''на бумаге'' встройку продукта в компанию.. и задача проектной команды заказчика как раз и состоит в этом. т.е на этапе примерки они должны внести корректировки в ТЗ.. - назовём этот этап 1-я примерка. 2-этап (2-я примерка) необходим для того, чтобы понять возможно ли создание такого продукта силами исполнителя и выяснения какие возможности ''роста'' нужно заложить в продукт. Соответственно ТЗ опять изменяется и дополняется. 3-этап окончательная примерка ''на бумаге'', уточнение мелких (но очень важных) деталей и согласование сроков между заказчиком и исполнителем. Только после этого исполнитель может приступать к разработке продукта и инсталляции его в компанию заказчика. Да проблемы возникать будут, но положительный результат гарантирован в 95 случаях, при этом заказчик получает оптимальный (цена/качество) для него продукт, а исполнитель минимизирует любые'' свои расходы при создании продукта. Нужно не забывать, что заказчик имеет только потребность, но он сам ещё не знает какой именно продукт ему нужен сейчас и будет нужен завтра. Задача исполнителя как профессионала как раз и помочь получить заказчику нужный ему продукт. :idea: Главное правило, Вам всегда отдадут часть доходов, которые они смогли получить с Вашей помощью, но помните, что ваша часть будет маленькая в % соотношении, а значит Вы должны помочь получать большой доход ;)
Руководитель проекта, Екатеринбург
Денис Милованов пишет: IT -компании как и обычные люди ленивы по своей натуре, и соответственно проще продать решение несколько раз с различными ''доработками'', чем каждый раз начинать работу с ''0''. Но для заказчика с финансовой точки зрения зачастую разработка продукта с ''0'', окажется дешевле, чем адаптация готового продукта.
Это для заказчик. Для ИТ-компании это получается вложения в компанию. Ведь заказчик по цене так называемого ''коробочного'' решения хочет получить продукт под свои нужды. Платить за разработку под себя он не готов или готов, но не хочет. Тогда Исполнителю, чтобы не упустить клиента необходимо оплатить труд разработчика из своих свободных средств. Хорошо если потом долгосрочное сотрудничество с заказчиком окупится. Это риски ИТ-компаний.
Researcher, Москва

Статья мне категорически НЕ ПОНРАВИЛАСЬ!
Я бы назвал ее (статью) – «дурацкой». А как иначе…

Описывается взаимодействие ЗАКАЗЧИКА неизвестно зачем устанавливающего у себя систему и не в состоянии определить цель и требования к системе, для краткости назовём ЗАКАЗЧИК-дурак.

С другой стороны ИСПОЛНИТЕЛЬ, который не знает цели, требования заказчика, не понимает проблемы заказчика, и при этом, БЕРЁТСЯ делать ЧТО-ТО :!: не зная что. Для краткости назовём ИСПОЛНИТЕЛЬ-дурак.

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

Ну как НЕ НАЗВАТЬ эту статью «дурацкой» и вредной как для НОРМАЛЬНЫХ исполнителей, так и для НОРМАЛЬНЫХ заказчиков???

Почему считаю статью ВРЕДНОЙ?
1. Она не дает советы НОРМАЛЬНЫМ участникам процесса.
2. Она не указывает НОРМАЛЬНЫМ исполнителям и заказчикам на «подводные камни» и не показывает, как избежать неприятности.
3. Она ничему не учит!
Но если кто и прочел статью до конца, то мой (личный) совет – не будьте дураками!!

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

Могу порекомендовать к чтению (есть в интернете):

Автор : Эдвард Йордон
Название книги : Путь камикадзе [Смертельный марш]
Аннотация :
Книга Эдварда Йордона «Путь камикадзе» представляет собой полное руководство по выживанию в безнадёжных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т.е. проектами, обречёнными на неудачу. В условиях реинжиниринга корпораций безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обречённых на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти изпроекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех, или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, «Путь камикадзе» – ваша книга.

Дата : 1997

Александр Абрамов +935 Александр Абрамов Управляющий директор, Самара
Денис Милованов,
IT -компании как и обычные люди ленивы по своей натуре, и соответственно проще продать решение несколько раз с различными ''доработками'', чем каждый раз начинать работу с ''0''. Но для заказчика с финансовой точки зрения зачастую разработка продукта с ''0'', окажется дешевле, чем адаптация готового продукта
На чем основано это утверждение? Я с ним не согласен, это неправда. Современные программные продукты давно имеют блочную архитектуру, стандартизированные процедуры. Это конструктор, иные модули которого можно запустить в работу в первую неделю. За модульными системами - будущее, ибо они уже в базе покрывают минимум 50% типовых бизнес-операций. Модульные системы во многих случаях являются для бизнеса даже носителем знаний, энциклопедией ''как надо работать''. Утверждение ИТ-компаний: ''наше конкурентное преимущество - это то, что мы разработаем систему с нуля под Вас, именно под Ваши потребности и структуру'' - это чистой воды развод и некомпетентность.
Управляющий директор, Ростов-на-Дону
Александр Абрамов пишет: Я уж не говорю про такие утопичные вещи, как ''структура'', ''вменяемые требования'', ''готовность аккуратно работать над ТЗ'', ''возможности роста'', ''штабная игра на бумаге''.. Над каждым из этих слов я готов пролить слезу счастья, это где бывают такие Заказчики? :)
Как-то они существовали до Вас? Значит всё, что перечислено они могут (теоретически). Ваша задача получить в конечном итого деньги при этом минимально на это потратится. Так решайте свою задачу.. тем более что мы не рассматриваем вопрос как Вам к ним попасть.. Вы уже у них, Вы пришли.. Так действуйте, ПОМНИТЕ ВЫ СПЕЦИАЛИСТ В СВОЕЙ ОБЛАСТИ!!!! И пока вы своими делами и поступками это не опровергните.. Вас будут СЛУШАТЬ и к Вам прислушиваться. Мой способ всегда давать выбор заказчику, Всегда!!! Но всегда я даю ему выбрать из 2-х предложенных мною вариантов, при этом обсуждая и разбирая с ним каждый из них.. ''фишка'' как говорится, что 3-го варианта нет:0 Как говорил Форд, Вы можете любить любую машину, любого цвета, но это точно будет черный Форд-Т.. Все остальные крики и жалобы я считаю проявлением непрофессионализма.
Александр Абрамов пишет: Денис, хотел бы я посмотреть сейчас, какая коммерческая компания (не госкомпания!), готова (перефразируя Вас) ''потратить кучу денег, ради потратить кучу денег''... Не знаю, вообразить себе даже не готов...
О уважаемый Вы ошибаетесь... 1. компании в состоянии ''агонии'' хватаются за всё.. 2. компании с верой в технологический прогресс который их спасёт 3. холдинги с ''отсутствующей'' ''системой управления'' (Грибы дождя 2005-2007 года). Я из Ростова-на-Дону не выходя с десяток на память Вам назову, и это только с численностью персонала до 600 человек. А так берите любое предприятие с персоналом от 100 человек и желательно живущее на ''остатках СССР'', вот Вам ''такой клиент''. А Ваша задача,в итоге прийти к результату описываемому в моём предыдущем посте.
Управляющий директор, Ростов-на-Дону
Александр Абрамов пишет: На чем основано это утверждение? Я с ним не согласен, это неправда. Современные программные продукты давно имеют блочную архитектуру, стандартизированные процедуры. Это конструктор, иные модули которого можно запустить в работу в первую неделю. За модульными системами - будущее, ибо они уже в базе покрывают минимум 50% типовых бизнес-операций. Модульные системы во многих случаях являются для бизнеса даже носителем знаний, энциклопедией ''как надо работать''. Я выше писал, что внедрение потребует изменения компании заказчика и породит ''эффект отторжения'' :!: Это Россия уважаемый Александр, ну не типовые мы, не типовые.. Согласен, что есть компании которые... (ну скажем так более или менее используют ''типовые процессы'', но все остальные изобрели их сами, придумали, модифицировали и используют. Но раз они живут, у них есть деньги, значит это имеет право жить. Утверждение ИТ-компаний: ''наше конкурентное преимущество - это то, что мы разработаем систему с нуля под Вас, именно под Ваши потребности и структуру'' - это чистой воды развод и некомпетентность.
Если это только утверждение - согласен, если это факт - то это профессионализм. Может я немного неправильно расставил акценты в своих высказываниях, но я имел ввиду, что продавать голый продукт (коробочное решение) нельзя.. К продукту должно идти РЕШЕНИЕ как его применять!!! Не инструкция а именно решение..
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
В российских IТ-компаниях не хватает специалистов по кибербезопасности

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

 

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

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

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

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

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

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