Проработав длительный срок в IT-сфере, начинаешь понимать, что как бы ты ни хотел, часть проектов проваливается. По оценкам некоторых экспертов, количество таких проектов доходит до 60%. Перефразируя классика, можно сказать, что все успешные проекты успешны одинаково, а каждый провальный - провален по-своему. В каждом случае можно найти свою ключевую причину провала. Вот некоторые из них:
1. Нереальные проектные сроки и бюджет
«…менеджера по маркетингу вряд ли особенно волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель - получить комиссионное вознаграждение или доставить удовольствие своему боссу». Эдвард Йордан, «Смертельный марш».
2. Непрофессионализм участников проектов
«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…». Джоэл Спольски, «Джоэл о программировании».
3. Политические интриги вокруг проектов
«…отличительной чертой безнадежных проектов является настолько сильное влияние политики, что она может свести на нет все усилия выполнить хотя бы какую-нибудь работу». Эдвард Йордан, «Смертельный марш».
4. Изменчивость требований к системам в ходе выполнения проектов
«Одной из самых распространенных причин неуправляемости проектов являются изменчивые требования». Роберт Гласс, «Факты и заблуждения профессионального программирования».
Причины разные, итог один – провал. Но он не приходит сразу. Провал терпеливо ждет своего часа, отмечая промахи, проблемы, конфликты, срывы сроков и другие свидетельства своего неизбежного торжества. Причины провала присутствуют, как правило, с самого начала проекта, но вряд ли кто-то готов закрыть проект на старте. Ведь главное - ввязаться в драку. Но чем больше усилий и (денег!) уходит на проект, тем меньше шансов его закрыть. Возникают все новые и новые проблемы, в которые вовлекается все больше средств и людей. Каждый член проектной команды самоотверженно включается в борьбу. Преодоление уже становится самоцелью: дорога – все, цель – ничто. Думаю, что и вам не раз приходилось наблюдать типичные этапы развития провального проекта.
Этапы развития провального проекта
- Сроки предоставления технического задания начинают затягиваться. Беспокойства нет – это бывает.
- Техническое задание представлено на согласование. У Заказчика возникает легкое недоумение - в документах слишком много «воды», часть требований не соответствует тому, что обсуждалось с проектной командой. Начинается процесс согласования. Все полны решимости быстро устранить недочеты.
- Процесс согласования технического задания затягивается. Появляются первые признаки беспокойства в связи с нарушением сроков. К этому относятся с пониманием, ведь важны не документы, а сама система.
- Подошел срок поставки первого релиза системы, который Исполнитель должен установить на оборудование Заказчика. Исполнитель сообщает, что все готово, но нужно подождать еще пару дней.
- Установка системы идет полным ходом, но пока безрезультатно. Систему должны были установить еще две недели назад.
- Сроки согласования ТЗ давно прошли, но это уже не очень волнует. Озабоченность связана с тем, что никак не удается наладить систему.
- Система установлена, но работает плохо. Часть функционала не реализована совсем, часть реализована не так, как ожидалось, и все равно не работает из-за большого количества ошибок. Недовольство Заказчика нарастает.
- Устанавливаются новые релизы системы, но каждый следующий релиз работает не лучше предыдущего. Протоколы встреч уже не ведутся. Встречи превратились во взаимные претензии. О том, что техническое задание до сих пор не согласовано, уже никто не вспоминает.
- Составляются длинные списки ошибок системы, которые нужно устранить. Новые релизы системы содержат исправления новых ошибок, но обнаруживаются старые ошибки, которые были исправлены ранее в предыдущих релизах.
- Исполнитель требует начала опытной эксплуатации системы и подписания актов приемки, но пользователи отказываются работать в системе, так как она им не нравится и часто падает.
- Акты приемки этапа разработки технического задания подписываются с обещанием Исполнителя исправить все позднее.
- Запаздывание проекта уже составляет 30% - 50%. ТЗ согласовывается задним числом.
- Установлены, наконец, все компоненты системы. Основные критические ошибки исправлены, но работать в системе невозможно из-за неудобства функционала.
- Заказчик просит переделать функционал. Исполнитель не соглашается без дополнительной оплаты, так как функционал разработан согласно ТЗ. Заказчик отказывается принимать систему. Идет долгий период непонимания, что делать с системой.
- Происходят изменения на стороне Заказчика (меняются люди/процедуры/процессы и тому подобное). В связи с произошедшими изменениями становится понятно: чтобы хоть как-то начать работать в системе, ее нужно переделать в соответствии с произошедшими изменениями. Заключается дополнительное соглашение на доработку системы. Чтобы не потерять лицо, руководство договорилось объявить о новом этапе проекта.
- Идет длительный этап доработки. Сроки превышены уже в два раза. Сотрудники Исполнителя и Заказчика устали от проекта, но не знают, как его прекратить. На проекте меняется руководитель проекта Исполнителя и часть проектной команды. Новая проектная команда заново собирает требования.
- Заказчик понимает, что существующая система работать не будет. Старая технология работы кажется уже не такой плохой, по сравнению с новой системой. Заказчик максимально тормозит внедрение системы, не зная как выйти из этого внедрения.
- Идет долгий процесс переговоров. В результате стороны договариваются о приемке системы. Размер денежного вознаграждения Исполнителю существенно снижен. Акты закрываются. Провал не нужен ни одной из сторон, поэтому по молчаливому согласию проект считается успешным.
- Выходит пресс-релиз об успешном внедрении системы.
Вот он, наконец, долгожданный финал. То есть вроде бы не провал. Но мы-то знаем…
К чему были все эти бессонные ночи, мешки под глазами, ссоры с коллегами, убийство нервных клеток, если система все равно не работает, премий нет, а ожидаемая профессиональная удовлетворенность так и не наступила? Потрачен огромный бюджет, а что мы получили в итоге?
«Как сказал мне старый раб перед таверной:
'Мы, оглядываясь, видим лишь руины'.
Взгляд, конечно, очень варварский, но верный».
И.Бродский
А ведь было бы гораздо эффективнее направить усилия на благородное дело - сохранение средств родной компании при сохранении собственного здоровья и душевного равновесия. Иными словами – не пытаться спасти проект, а, наоборот, утопить его как можно раньше. Уверен, что вы уже знаете или догадываетесь, как это сделать.
Что необходимо сделать, чтобы провалить проект наиболее результативно.
- Изучите перед проектом резюме специалистов проектной команды Исполнителя. Отвергайте кандидатуры сотрудников до тех пор, пока вы не убедитесь в следующем:
- Вам представлены наиболее молодые сотрудники компании Исполнителя, пришедшие в команду недавно и не имеющие проектного опыта.
- Сотрудники проектной команды никогда прежде совместно не работали.
- Профиль специалистов проектной команды максимально далек от вашей предметной области, а архитектура предложенного решения не соответствует инфраструктуре компании.
- Руководитель проекта Исполнителя запуган и ведет себя неуверенно.
- Проекты, которые выполняли сотрудники проектной команды, не были завершены или завершены неудачно.
- Поставьте нереально сжатые сроки проекта.
- Определите максимальное количество проектных документов, требующих согласования.
- Составьте предельно длинный список сотрудников, согласующих проектную документацию с вашей стороны.
- Затягивайте согласование технического задания. Отказывайтесь подписывать проектные документы, ссылаясь на несоответствие ГОСТам, внутренним стандартам вашей компании, слабую детализацию или несоответствие бизнес-процессам.
- Постоянно изменяйте требования к системе.
- Чаще проводите ротацию сотрудников вашей проектной команды и предметных специалистов.
- Если почувствуете, что проектная работа, тем не менее, начала стабилизироваться, попросите заменить проектную команду Исполнителя по причине срыва сроков этапов проекта. Начните вновь, с пункта 1.
Согласитесь, все это сделать гораздо проще, чем погибать за проект. При этом вы ничего не теряете. Провал проекта – это уже не провал, а ваш успех. А если проект все же завершен успешно, система внедрена, значит это действительно хорошая система, которая закалилась в борьбе благодаря вам. Вы в любом случае остаетесь в выигрыше. И может быть даже с премией. За успешно выполненный проект или как результат экономии средств вашей компании.
Удачи на проектах!
Интересная статья, но если пункт к пункту 2 вы относите только то, что процитировали:
''2. Непрофессионализм участников проектов
«Все компании, предоставляющие услуги в ИТ, становятся жадными и пытаются расти быстрее, чем могут находить талантливых людей…». Джоэл Спольски, «Джоэл о программировании».''
то я бы еще отметил тот факт, что сами заказчики иногда не знают, что хотят, и в этом я думаю заключается их непрофессионализм... И в последствии чего и получается пункт №4.
Если все так и подразумевалось, то беру слова обратно...
P.S.-хорошие советы, тем более от Исполнителя и для Заказчика.
''По оценкам некоторых экспертов, количество таких проектов доходит до 60%''.
По личному опыту считаю что это процент на уровне 75-80%, а некоторые проекты только со 2 или 3 раза получаются.
Господину, автору статьи, следует пойти поработать в команду Исполнителя.
В любом проекте присутсвуют эти причины провала.
Иногда даже несколько одномоментно.
Главное в любом проекте это умение договариваться Исполнителя и Закакзчика.
Всем бы нам адекватных заказчиков.
Считаю, что хороший Исполнитель с опытом способен узнать Заказчика с такими ''недостатками'' и вовремя отказаться от проекта, если не знает как им противостоять. Иначе - это жадность, из-за которой так низок процент успешных проектов.
Не жадность губит It-проекты. А недостаток жадности :-). Все, что происходит на обычном проекте описано правильно, с хорошим юмором, кое-где переходящим в добрый сарказм. И вывод хороший - выгнать некомпетентную команду как можно быстрее :) А вот дискуссию на тему, что же сделать, чтобы обычный проект получился при обычной команде, можно и продолжить. У меня простой рецепт. Нужно больше денег и времени! Риски - неизбежны. ТЗ будет кривым, хоть ты у...ся. Спецы исполнителя будут сопротивляться изменениям до последнего, так, как будто бьются с врагом Родины. Будут меняться и требования, и специалисты Заказчика. В жизни не увидите полностью компетентную команду Исполнителя. Ну и что? Все это решается простым увеличением бюджета по мере необходимости. Или закладыванием рисков в начальную цену простым увеличением ее в три раза. Готовность Заказчика платить, не жадничать - очень важна. А вот готовность Исполнителя браться за крупный проект за три копейки из-за недостатка жадности и конкуренции просто опасна.