9 ошибок, которые могут свести на нет все усилия по сокращению потерь

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

1. Бездумное внедрение классической японской системы «пять сигм» (5S: сортировка на полезное и бесполезное, соблюдение порядка, содержание рабочего места в чистоте, стандартизация, совершенствование). Часть этих элементов может стать актуальной на поздних этапах, а может и вообще не понадобиться. Более жизнеспособной альтернативой классической концепции 5S на практике оказывается подход, при котором выявляются существующие проблемы и все усилия направляются на их устранение.

2. Отказ от обучения персонала принципам улучшений. Сотрудникам, участвующим в проектах улучшений, предлагается самим выйти «в поле», увидеть проблемы и придумать, как их решить. Так практикуется в Японии, японские консультанты советуют это и российским предприятиям. Трудность в том, что неподготовленный человек, особенно если он долго работает в данной организации, проблем не видит. Все как всегда, люди заняты, процессы выполняются. Но это не значит, что проблем нет, это говорит лишь о том, что сотрудник их не осознает. И, следовательно, не сможет их решить. В результате проект бережливого производства затягивается, а консультанты надолго обеспечиваются работой (и стабильным доходом). Поэтому рекомендуется начинать процесс улучшений с обучения персонала его принципам. Люди должны понять, как выявлять и решать проблемы, и только после этого их можно бросать в бой. Спешке здесь не место, но в итоге результаты все равно появятся быстрее. В США я наблюдала подход, прямо противоположный японскому: четко прописанные сроки проекта, бюджеты и плановые результаты держали его участников в повышенном напряжении, что тоже иногда негативно сказывалось на результатах.

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

4. Пренебрежение материальной мотивацией. В Японии за участие в проектах повышения эффективности сотрудникам не платят. Предполагается, что это их непосредственная обязанность. Возможно, и российские предприятия когда-нибудь придут к этому, но пока реальность такова, что без понимания личной выгоды персонал не будет деятельно участвовать в сокращении потерь. Люди должны четко знать, как они смогут дополнительно заработать, и этот стимул пока остается наиболее сильным.

5. Нетерпеливость. Думаю, с этой ошибкой сталкивались все. В организации стартует процесс улучшений, проходит два, три или четыре месяца – видимых результатов нет. Процесс улучшений сворачивается. Однако именно терпение и последовательность – секрет успеха изменений. Если вы не видите результатов через два месяца, значит, организация еще не созрела. Результаты появятся чуть позже. Но надо понять, что пошло не так, и вовремя внести коррективы.

6. Неправильный выбор консультантов. Программы повышения эффективности и сокращения затрат часто требуют привлечения экспертов. Но не любых, а тех, кто был «в поле» и может предоставить документированные результаты своей работы. Избегайте теоретиков и выбирайте практиков.

7. Перекладывание ответственности на консультантов. Самый лучший сторонний эксперт не сделает за руководство и сотрудников их работу. Его задача – довести проект изменений до заранее оговоренной стадии и передать в руки инициативной группы внутри компании.

8. Оптимизация операций, которых просто не должно быть. Это одна из самых частых и опасных ошибок. Вместо того чтобы тратить время и усилия на оптимизацию бесполезных процессов, их надо искоренить. Например, вместо совершенствования отчетов, которыми никто не пользуется, надо всего-навсего научить сотрудников делать выгрузки из уже существующих учетно-управленческих систем.

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

Наш эксперт по управлению проектами, директор компании «АйТи уит» Максим Якубович, задался вопросом: насколько велика вероятность того, что ИТ-проекты будут внедрены в срок и уложатся в бюджет, а также почему они проваливаются. Вот его комментарии и выводы.

— Около 10 лет назад от одного из успешных бизнесменов, в компании которого я руководил проектом внедрения КСУП , я услышал такую фразу: «Бизнес сидит на игле у ИТ». Я попросил объяснить, что он имеет в виду. Вот что примерно он сказал: «Мы не можем не автоматизировать наш бизнес, потому как конкуренты это сделают ранее нас и станут эффективнее нас. С другой стороны, мы боимся это делать, т.к. вероятность успеха ИТ-проекта крайне низка».

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

2. Отсутствие со стороны компании-заказчика проекта команды проекта . Я имею в виду команду, которая имеет полномочия и ответственность принимать решения по содержанию проекта.

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

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

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

5. Изменение требований. Проявляется этот фактор в том, что на стороне заказчика хотят сразу сделать идеальный продукт и не принимают позицию, связанную с тем, что пользователям все равно что-то не понравится в программном продукте, поэтому важно максимально быстро запустить ключевой функционал. А потом потихоньку дорабатывать «бантики». По статистике, 20% от оплаченного функционала приобретенной ИТ-системы используются пользователями часто, еще 30% функций используются редко и 50% от приобретенного функционала ИТ-системы не используются практически никогда.

6. Отсутствие поддержки высшего руководства компании-заказчика. Я встречал ситуации, когда при внедрении ERP-систем высшие руководители компании-заказчика даже не были представлены команде исполнителя. О каком вовлечении в проект или поддержке проекта руководством со стороны заказчика может идти речь?

7. Команда заказчика и команда исполнителя не работают как одна команда. В этом случае проект строится не на отношениях взаимного доверия, а на отношениях антагонизма: заказчик пытается за зафиксированную цену получить от исполнителя максимально много, а исполнитель пытается максимально заработать на некомпетентном заказчике.

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

Остальные причины, озвученные в отчете, также имеют место быть, но на мой взгляд, они не так важны, как перечисленные выше.

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

Тут я хочу вспомнить один из пунктов манифеста Agile: «Люди и взаимодействие важнее процессов и инструментов», который я трактую так: «Хорошая команда проекта определит, какие процессы и инструменты ей надо использовать, чтобы достигнуть целей проекта».

Agile - это про хорошие команды. Может, поэтому в списке причин успеха ИТ-проектов в отчете компании The Standish Group за 2015 год появилась новая причина успеха — использование Agile-процесса?

Остались вопросы? Пишите в комментариях.

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами — с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Приглашенный преподаватель компании «Инфопарк-проект». Опыт преподавания — с 2005 года (прошли обучение около 2300 студентов).

7 грандиозных проектов человечества, которые взяли и не взлетели

Историю творят мечтатели и идеалисты. Но великие свершения им удаются не чаще, чем грандиозные провалы.

Панамский канал

В 1869 году весь мир рукоплескал Фердинанду Лессепсу на открытии Суэцкого канала. Тот, недолго думая, затеял следующую великую стройку – канал Панамский, полностью проигнорировав бьющих в колокола медиков (Панама – зона желтой лихорадки) и инженеров (чертежи Фердинанда вызвали у них ужас).

Через двадцать лет Лессепса проклянут инвесторы, посадят в тюрьму и предадут анафеме. Двадцать тысяч рабочих вернутся на родину в гробах (а большинство не вернется даже в них), а слово «Панама» станет синонимом афёры и надувательства. Потому что нужно слушать профессионалов, а не авантюристов.

Титаник

Устраивать гонки через Атлантику было любимым развлечением судовладельцев на рубеже веков. В 1907 году, спустив на воду «Мавританию» и «Лузитанию», компания «Кунард Лайн» задала новые стандарты пассажирских перевозок. Ответный ход конкурентов из «Уайт Стар Лайн» впечатлял: три однотипных суперсовременных корабля! «Титаник» был самым большим, самым роскошным и самым безопасным судном того времени.

14 апреля, накануне трагедии, капитан Эдвард Смит получил от различных судов семь предупреждений об айсбергах в океане, но не сбавил скорости. После доклада об обнаружении айсберга прямо по курсу, первый офицер Уйльям Мердок полминуты раздумывал, стоит ли отворачивать от обломка льда. «Титаник» был безупречен и пал жертвой своей безупречности: кому могло прийти в голову готовиться к крушению самого непотопляемого в мире корабля?!

Линия Мажино

К 1936 году французы построили на границе с Германий четырёхсоткилометровую линию укреплений стоимостью три миллиарда франков. Теперь немцам придётся идти в обход, чтобы напасть на нас, – ликовали они! Пусть сначала Бельгию победят, – улыбался военный министр Мажино.

– Да не вопрос, – подумали немцы. Бельгия, отказавшаяся от союзнического пакта с Францией, получила молниеносную оккупацию. Линию Мажино немецкие войска обошли через Арденны на севере, после чего вышли на Монмартр и сказали «Гутен таг». Париж пал раньше, чем осознал, какие деньги закопал в землю.

Это чудо архитектуры XX века должно было стать самым высоким зданием мира и последней и главной сталинской высоткой Москвы. Для этого сначала снесли Храм Христа Спасителя, затем вырыли огромный котлован, но, увы, началась война, и стало как-то не до дворцов. Котлован не пропал зря, и москвичи ещё сорок лет купались в открытом бассейне «Москва», разумеется, самом большом в мире. Затем бассейн закопали, ну а дальше вы знаете.

Фобос-грунт

Автоматическая межпланетная станция стоимостью 5 миллиардов рублей должна была сгонять на Марс и обратно, прихватив с собой образцы марсианской почвы и проведя тучу важнейших исследований космоса по пути. Но что-то пошло не так, едва аппарат оторвался от Земли. Астрономы-любители ещё долго фотографировали беспомощную технику, кружащую на околоземной орбите. В итоге «Фобос-грунт» сгорел в плотных слоях атмосферы в январе 2012 года.

Ё-мобиль

В 2010 году российский миллиардер Михаил Прохоров заявил о скором появлении настоящего народного российского автомобиля: высокотехнологичного, красивого и, главное, дешёвого. Через два года двадцать тысяч машин стоимостью от 350 до 500 тысяч рублей должны были появиться на улицах российских городов. Но время шло, технологии менялись, прототипы ездили с трудом, а тут ещё спад авторынка и падение курса рубля. Вместо триумфальной презентации нового автомобиля, Прохоров безвозмездно передаёт всю документацию по проекту в российский автомобильный институт НАМИ. Может, хоть чертежи не пропадут зря.

Большой скачок

К началу шестидесятых Китай был огромной, но бедной сельскохозяйственной страной. Великий кормчий Мао решил одним махом превратить страну в лидера мировой экономики. Отвергнув здравые соображения и тысячелетний сельскохозяйственный опыт, компартия выдавала предписания, что, где и как сеять и сажать. Воробьёв предлагалось уничтожать (чтобы не портили посевы), а кастрюли и гантели переплавлять на нужды металлургической промышленности. Итогами стали Большой голод, гибель десятков миллионов человек, Люшаньская конференция и новая экономика Ден Сяопина. Впрочем, впоследствии Китай все-таки скакнул вперед. Просто потому, что перестал изобретать велосипед и купил учебник «Экономика для чайников». Если взглянуть на современный Китай, то учебник, без сомнения, полезный.

Хотите получать одну интересную непрочитанную статью в день?

Представляем вам перечень дорогостоящих глобальных мировых проектов, которые провалились, несмотря на многомиллионные финансовые вливания.

Проект Мохол — копай глубже, кидай дальше

Назван в честь хорватского геофизика Мохоровичича, предположившего, что существует явная граница между земной корой и земным ядром, которое вращается отдельно от верхних слоев почвы. Этакий шарообразный подшипник, в зазоре которого может располагаться описанный фантастами затерянный мир с джунглями, динозаврами и подземными обитателями. Для проведения фундаментальных исследований вопроса было принято решение пробуриться до вожделенного слоя и произвести соответствующие замеры.

Чтобы сэкономить на процессе, бурить решили в Тихом океане недалеко от побережья Мексики, в месте, где глубина океана составляла более трех километров. Шаг вполне разумный — зачем пробивать дорогостоящим оборудованием земную твердь там, где ее можно пройти сквозь толщу воды? Тем не менее, на проект было “угрохано” около полумиллиарда американских долларов, что по меркам 60-х годов прошлого века просто умопомрачительная сумма.

Однако, пробурить океанское дно удалось всего лишь на жалкие пару сотен метров. Дальнейшее бурение не представлялось возможным из-за несовершенства используемого оборудования. Через пять лет после старта американское научное сообщество приняло решение свернуть проект ввиду безуспешности всех принимаемых попыток. Похоже, эти 180 метров оказались самыми дорогостоящими землеустроительными работами за всю историю человечества. А вы по поводу “Зенит — Арены” переживаете!

Какая боль, какая боль! Канада — СССР: 5-0!

Проведение любых международных мероприятий, будь то конкурс Евровидения или Олимпийские игры, всегда желанное событие для руководства стран-организаторов. Возможность финансовой выгоды базируется на здравой оценке собственных инфраструктурных объектов принимающей стороны и ожидаемых поступлений от туристического сектора собственной экономики. Не известно, какими исходными показателями оперировало канадское руководство в 1976 году, победив в конкурсе на проведение очередной мировой спортивной встречи, но Монреаль начал скорую подготовку к летним Олимпийским играм, вырвав это почетное право у СССР и США.

Как и полагается в таких случаях, Канада начала спешно возводить соответствующую инфраструктуру. Был заказан проект нового стадиона с инновационной раздвижной крышей, строительство которого обошлось в 135 млн. долларов. Как это и водится, к сроку стадион не был готов и все действие пришлось проводить на этом незаконченном объекте с минимальными удобствами. Полноценный ввод в эксплуатацию горе-стадиона произошло только спустя шесть лет, хотя некоторые инженерные решения так и остались неработающими, в том числе и чудо-крыша. Общие расходы на проведение Олимпиады составили пять миллиардов канадских долларов, которые были вынуты из экономики страны и выплачивались как совокупный долг аж до 2006 года, перевалив по оценкам специалистов в пересчете на текущий курс за $20 миллионов! К слову сказать, Канада на этой Олимпиаде не завоевала ни одной золотой медали.

Проект «Авангард»: Догоним и перегоним!

Любая спешка до добра не доводит. А если при этом две сверх державы пытаются во что бы то ни стало обогнать друг друга в такой наукоемкой и затратной сфере, как космос, то цена ошибки ожидаемо окажется весьма высока. Так, уступив пальму первенства в покорении космоса всего на пару месяцев СССР, США, стиснув зубы, продолжили доводить до совершенства разработку собственного ракетоносителя под названием «проект “Авангард” (англ. Vanguard).

Стремление к совершенству вылилось в целый ряд аварийных стартов, при которых ракета взрывалась в атмосфере, либо просто разваливалась на старте. Позор, длившийся несколько лет, удалось прекратить только передав проект в руки военных специалистов НАСА. За эти пару-тройку неудачных лет проект “Авангард” уже поглотил более ста миллионов долларов, нисколько не оправдав своего претенциозного названия.

Заполярная железная дорога

Для реализации любого амбициозного проекта в СССР необходимо наличие достаточного количества людского ресурса и.. пожалуй, этого достаточно. Сталинские идеологи в 1947 году замахнулись на прокладку транспортной железнодорожной магистрали, соединившей бы Северный полярный круг, Урал и Центральную Сибирь. Стройка века подразумевала умопомрачительные финансовые траты, оптимизировать которые решили за счет использования труда заключенных.

На тот момент источников подобных ресурсов хватало с избытком. Официальные цифры участников строительства озвучивают 80 тысяч человек. Ударная стройка, длившаяся шесть лет, потребовала вложений 42 миллионов рублей и так и не была завершена — в 1953 году скончался Сталин, положив конец масштабному расточительству средств и человеческих жизней. По сей день в лесах на просторах Сибири ржавеют остовы брошенных паровозов, разваливается железнодорожное ветхое полотно, рельсы которого устанавливались с нарушением всех допустимых ГОСТов отрасли — весь подвиг многострадального народа делался для галочки, эксплуатировать магистраль даже после успешного окончания строительства не представлялось возможным — большинство развязок и скруглений не выдержали бы и минимальной транспортной нагрузки, так как строились непрофессионалами без соблюдения норм проектной документации. Еще один невостребованный памятник роптанию перед тоталитарным режимом.

К еще одному фундаментальному провалу амбициозной стройки также приложилась рука Коммунистической партии Советского Союза, когда по предложению товарища Кирова в 1922 году было решено построить для парламентариев-коммунистов самое высокое здание в Москве и в мире.

Строить решили не абы где, а на месте расположенного в Москве храма Христа Спасителя, стоявшего в столице с середины девятнадцатого века. Сказано-сделано. Храм был взорван, на его месте возвели гигантский котлован под фундамент. Близкое расположение реки обусловливало постоянное подтопление обнаженного слоя земли грунтовыми водами и уже на том этапе строительства было понятно, что проект окажется провальным.

Но воду героически откачивали, не менее героически возводя многотонный фундамент будущего Дворца Съездов. До начала Великой Отечественной успели даже построить первые десять этажей гиганта. Но война внесла свои коррективы — здание было разобрано на нужды фронта. Оставшийся котлован с неумолимым постоянством затапливался водой, пока послевоенным руководством не было принято решение открыть на этом месте крупнейший в стране бассейн под открытым небом. Зимний плавательный бассейн “Москва” просуществовал до 1994 года, когда было принято решение о восстановлении храма Христа Спасителя. За неполную пятилетку храм был реконструирован, вновь вернувшись на круги своя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Изучите перед проектом резюме специалистов проектной команды Исполнителя. Отвергайте кандидатуры сотрудников до тех пор, пока вы не убедитесь в следующем:

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

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

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

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