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

Олег Пашинин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Александр Абрамов +935 Александр Абрамов Управляющий директор, Самара
Как-то они существовали до Вас? Значит всё, что перечислено они могут (теоретически). Ваша задача получить в конечном итого деньги при этом минимально на это потратится.
Кто существовали? :) Непуганый жирный потребительский рынок, госконтракты, правительственное лобби, что еще там..? это всё существовало, да. Зачем думать об оргструктуре, процессах, операционной эффективности?
О уважаемый Вы ошибаетесь... 1. компании в состоянии ''агонии'' хватаются за всё.. 2. компании с верой в технологический прогресс который их спасёт 3. холдинги с ''отсутствующей'' ''системой управления'' (Грибы дождя 2005-2007 года). Я из Ростова-на-Дону не выходя с десяток на память Вам назову, и это только с численностью персонала до 600 человек. А так берите любое предприятие с персоналом от 100 человек и желательно живущее на ''остатках СССР'', вот Вам ''такой клиент''.
Да ничего это не такой клиент. Почему-то ИТ-проекты, и любые ''тяжелые'' проекты, находятся где-то в конце списка этого ''всего''. А в первых позициях - одержимость идеей чучхе, когда ''можно сделать всё самим, лишь чуток поднапрягшись''. Когда давно уже пора безжалостно применять хирургию. А хирургия - она денег стоит. Как так, раньше жили как-то без этих тотальных затрат, авось и сейчас вывезем?
Руководитель проекта, Екатеринбург
Денис Милованов пишет: О уважаемый Вы ошибаетесь... 1. компании в состоянии ''агонии'' хватаются за всё.. 2. компании с верой в технологический прогресс который их спасёт 3. холдинги с ''отсутствующей'' ''системой управления'' (Грибы дождя 2005-2007 года).
При этом цель проекта- Сделайте так чтобы все было хорошо.
Александр Абрамов +935 Александр Абрамов Управляющий директор, Самара

Денис, да будь ИТ-компания хоть трижды профессионалом в создании продуктов с нуля! Не сдаст она систему никогда, если не будет порядка в организации Заказчика. Если в ней не будет ''штабных игр'' на бумаге. ИТ-компания вечно будет на шаг оставать!

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

Event manager, Воронеж

Мне статья понравилась, материал лаконичен и доступен. Спасибо автору за описание признаков и этапов провальных проектов. Ужасная статистика по поводу провальности проектов: 60, 70, 80%. Уважаемые Заказчики, Менеджеры и Исполнители проектов будьте бдительнее... :(

IT-менеджер, Москва

Краски в статье сгущены (видимо, художественный приём), но в целом достаточно правдиво.
На мой взгляд, корень всех бед в том, что Заказчик до конца не знает, что и как ему нужно автоматизировать (и главное - зачем), а Исполнитель не пытается разобраться до конца, а ''пихает'' более или менее подходящее решение. которое будет затем адаптироваться, модифицироваться, а иногда и переписываться полностью. Но, главное - ввязаться в драку.
То есть большую половину проектного времени никто толком не представляет что нужно делать и к чему это должно привести.
Оттуда такие проблемы с ТЗ, и с постоянным изменением объёмов выполняемых работ, и сроками и т.д.

Ну а нехватка по настоящему опытных людей в ИТ - эта болезнь не вылечилась даже кризисом :(

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

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

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

IT-менеджер, Москва
Рустэм Валеев пишет: - Первая интересная технология - это технология создания больших систем на основе прототипов Rational Rose (Рейшнл Роуз). В основе технологии простой тезис. Никто (ни Заказчик, ни Исполнитель) заранее не знают, что им нужно и что должно получиться. Но кое-что они знают. Это кое-что лепится кое-как, но как-то работает. Собирается компания друзей и внимательно смотрят на первый прототип. Что-то он может, что-то нет. Что-то делает правильно, что-то нет. Результаты наблюдения ложатся в основу требований и планов работ по превращению первого плохого прототипа во второй получше. И так далее, до тех пор, пока кто-нибудь не скажет ''ну вот, это уже вполне годится''. Да, в процессе пишется много бумажек и строится много моделек, но все равно, это намного лучше громоздкого и незыблемого ТЗ. Это т.н. спиральная модель. Более строго описана в нескольких методиках, например в AIM for business flow (Oracle). Но после окончания сессии проверки очередного прототипа производится обязательное документирование (ТЗ наоборот). - Вторая технология - это технология ''контрольного примера''. Она годится, когда есть базовое типовое решение, которое ''почти подходит'' заказчику. В этом случае на нем моделируют реальные бизнес-процессы Заказчика на небольшой, но разнообразной выборке искусственно придуманных данных, и смотрят, что получается. Если все хорошо, то все хорошо. Если что-то не получилось, пишут локальное ТЗ и делают доработку. ТЗ и доработок много, но система не рассыпается, потому что в любом случае изменения не превышают 10-20% от типового решения. В общем вариация первого метода. - Ну и, наконец, когда прсто со слов делают программу. И переделывают ее тоже со слов, после того как попробуют в работе. Часто этот много раз раскритикованный метод оказывается лучшим, так как экономится куча времени на написании горы бумажек
Этот метод годится только для маленьких программ и работает при условии незыблемости команды Исполнителя и лояльности Заказчика. Иначе - можно бесконечно заниматься ''улучшайзингом'', двигаясь по кругу. В любом случае без документирования успех маловероятен.
IT-менеджер, Москва
Неправильно процитировал. Дисквалифицировался совсем - давно на форумах E-x не общался плотно. Нужно так:
Рустэм Валеев пишет: Почитал дискуссию, и вдруг обнаружил, что никто не написал про проекты без ТЗ. А ведь сейчас это - мейнстрим! Я знаю минимум три технологии, в которых ТЗ или нет совсем, или их много, но они маленькие. - Первая интересная технология - это технология создания больших систем на основе прототипов Rational Rose (Рейшнл Роуз). В основе технологии простой тезис. Никто (ни Заказчик, ни Исполнитель) заранее не знают, что им нужно и что должно получиться. Но кое-что они знают. Это кое-что лепится кое-как, но как-то работает. Собирается компания друзей и внимательно смотрят на первый прототип. Что-то он может, что-то нет. Что-то делает правильно, что-то нет. Результаты наблюдения ложатся в основу требований и планов работ по превращению первого плохого прототипа во второй получше. И так далее, до тех пор, пока кто-нибудь не скажет ''ну вот, это уже вполне годится''. Да, в процессе пишется много бумажек и строится много моделек, но все равно, это намного лучше громоздкого и незыблемого ТЗ.
Это т.н. спиральная модель. Более строго описана в нескольких методиках, например в AIM for business flow (Oracle). Но после окончания сессии проверки очередного прототипа производится обязательное документирование (ТЗ наоборот).
Рустэм Валеев пишет: - Вторая технология - это технология ''контрольного примера''. Она годится, когда есть базовое типовое решение, которое ''почти подходит'' заказчику. В этом случае на нем моделируют реальные бизнес-процессы Заказчика на небольшой, но разнообразной выборке искусственно придуманных данных, и смотрят, что получается. Если все хорошо, то все хорошо. Если что-то не получилось, пишут локальное ТЗ и делают доработку. ТЗ и доработок много, но система не рассыпается, потому что в любом случае изменения не превышают 10-20% от типового решения.
В общем вариация первого метода.
Рустэм Валеев пишет: - Ну и, наконец, когда прсто со слов делают программу. И переделывают ее тоже со слов, после того как попробуют в работе. Часто этот много раз раскритикованный метод оказывается лучшим, так как экономится куча времени на написании горы бумажек
Этот метод годится только для маленьких программ и работает при условии незыблемости команды Исполнителя и лояльности Заказчика. Иначе - можно бесконечно заниматься ''улучшайзингом'', двигаясь по кругу. В любом случае без документирования успех маловероятен. Теперь получше
Александр Абрамов +935 Александр Абрамов Управляющий директор, Самара
Пришел к убеждению, что в провальных (вот-вот готовых сорваться в пропасть) проектах любые технологии следует заменять психологией. Иначе говоря, человек с механистическим мышлением на должности РП не вытянет его. Если даже взять итеративный подход: ''слепили колобка, обхлопали варежкой по бокам, прикинули - нравится/не нравится? Нравится - на следующей итерации наращиваем, не нравится - срезаем''. То как в этой ситуации определить ''сделал-не сделал''? Все равно должна быть база: набор критериев, контрольных примеров, которые на каждой итерации нужно переопределять, находить время для проверки и т.п. В ходе этого процесса возникает столько флуктуаций, что очки иной раз спрыгивают с носа. Не говоря уже про учащающийся интерес ''с небес'' о ходе работ... Считаю, единственное, что остается - это управлять ими (флуктуациями): аккуратно фиксировать (даже через силу), по ряду случаев - вставать в оборону, в режиме онлайн находить и объявлять противоречия; максимально перекидывать мячик на чужое поле. При этом в фоновом режиме создавая и расширяя себе пространство для маневра: срочно находя новый ИТ-персонал и обучая, обучая его, вводя в тему. Авось и удастся прогрызть этот полиэтиленовый мешок на голове! мне удавалось. Механист тут не у дел, только психолог. Вооооооот...
Управляющий директор, Ростов-на-Дону
Александр, давайте определимся.. Мы с Вами мало того, что в одной лодке да ещё и плывём в одном направлении. Я не пытаюсь в чём-то вам противоречить, просто статья описывала одну сторону монеты, я другую. Вы сейчас утверждаете, что вы придерживаетесь золотой середины, по вполне понятным причинам от Вас независящим. Думаю, что имеет смысл обсуждать вопрос как заставить ''играть в штабные игры'' заказчика. И поймите меня правильно, с ''0'' это не значит изобретать двоичный код и т.д. С ''0'' это создание продукта под нужды заказчика, а не попытка приспособить продукт и заказчика ''под проект''. Модульная схема, Велкам!!! Но в умелых руках и с умом в головах. ;) А штабные игры, не проблема, если заказчик поймёт, что именно они ему дадут в итоге. Попробуйте объясните... правильно... и получите полное понимание и содействие...
Александр Абрамов пишет: Денис, да будь ИТ-компания хоть трижды профессионалом в создании продуктов с нуля! Не сдаст она систему никогда, если не будет порядка в организации Заказчика. Если в ней не будет ''штабных игр'' на бумаге. ИТ-компания вечно будет на шаг оставать!
Я тоже люблю клиентов которые всё сами делают, и потребность свою определят и производителя найдут и скидку у него выбьют, и все оплатят сами и привезут себе, даже документы сами все себе оформят, а мне просто роялти на р/счёт перечислят да ещё и бонус добавят. Такие вот они хорошие не хотят мне мешать отдыхать.. Ну нет деда мороза, нету!!!! А значит берём и начинаем нянчить, воспитывать, растить клиентов, учить их зарабатывать деньги ну и соответственно оплачивать наши услуги. P.S. Я житель и труженик России - Замкадной, а гос деньги и всё, что с ними связано слышал есть в России - Столичной. Вот накоплю денег, куплю билет и поеду посмотреть на это чудо компании, Госкорпорациями называются, а ещё говорят там есть компании которым за то, что они есть государство деньги даёт.. Представляете??? :o
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
В российских IТ-компаниях не хватает специалистов по кибербезопасности

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

 

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

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

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

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

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

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