Як зробити провальний проект успішним?

Мова не про те, як зробити згубний проект хітом, а про те, як зістригти з свідомо паршивої вівці найбільшу кількість вовни. Але попередньо приреченому дітищу потрібно поставити сумний діагноз. Про те, як це зробити і завалити проект найбільш ефективно, в матеріалі з рубрики "П'ятничний менеджер" розповідає учасник Спільноти Олег Пашинін.
Пропрацювавши тривалий термін в IT сфері, починаєш розуміти, що як би ти хотів, частина проектів провалюється. За оцінками деяких експертів, кількість таких проектів доходить до 60%. Перефразовуючи класика, можна сказати, що всі успішні проекти успішні однаково, а кожен провальний - провалений по-своєму. У кожному разі можна знайти свою ключову причину провалу. Ось деякі з них:
1. Нереальні проектні терміни і бюджет
"…менеджера з маркетингу навряд чи особливо хвилює реалістичність запропонованого ним плану і бюджету, оскільки його основна мета - отримати комісійну винагороду або доставити задоволення своєму босові". Едвард Йордан, "Смертельний марш".
2. Непрофесіоналізм учасників проектів
"Всі компанії, що надають послуги в ІТ, стають жадібними і намагаються рости швидше, ніж можуть знаходити талановитих людей…". Джоел Спольскі, "Джоел про програмування".
3. Політичні інтриги навколо проектів
"…відмінною рисою безнадійних проектів є настільки сильний вплив політики, що вона може звести нанівець усі зусилля виконати хоча б якусь небудь роботу". Едвард Йордан, "Смертельний марш".
4. Мінливість вимог до систем в ході виконання проектів
"Однією , анимированные открытки 9 Мая, з найпоширеніших причин некерованості проектів є мінливі вимоги". Роберт Гласс, "Факти та омани професійного програмування".
Причини різні, підсумок один - провал. Але він не приходить відразу. Провал терпляче чекає своєї години, відзначаючи промахи, проблеми, конфлікти, зриви термінів і інші свідоцтва свого неминучого урочистості. Причини провалу присутні, як правило, з самого початку проекту, але навряд чи хтось готовий закрити проект на старті. Адже головне - вплутатися в бійку. Але чим більше зусиль і грошей!) йде на проект, тим менше шансів його закрити. Виникають все нові і нові проблеми, які залучається все більше коштів і людей. Кожен член проектної команди самовіддано включається в боротьбу. Подолання вже стає самоціллю: дорога - все, мета - ніщо. Думаю, що і вам не раз доводилося спостерігати типові етапи розвитку провального проекту.
Етапи розвитку провального проекту
Терміни надання технічного завдання починають затягуватися. Занепокоєння немає - це буває.
Технічне завдання представлено на узгодження. У Замовника виникає легке здивування - у документах дуже багато води", частина вимог не відповідає тому, що обговорювалося з проектною командою. Починається процес узгодження. Всі повні рішучості швидко усунути недоліки.
Процес узгодження технічного завдання затягується. З'являються перші ознаки занепокоєння у зв'язку з порушенням термінів. До цього ставляться з розумінням, адже важливі не документи, а сама система.
Підійшов термін поставки першого релізу системи, який Виконавець повинен встановити на обладнання Замовника. Виконавець повідомляє, що все готово, але потрібно почекати ще кілька днів.
Установка системи йде повним ходом, але поки безрезультатно. Систему повинні були встановити ще два тижні тому.
Терміни погодження ТЗ давно пройшли, але це вже не дуже хвилює. Заклопотаність пов'язана з тим, що ніяк не вдається налагодити систему.
Система встановлена, але працює погано. Частина функціоналу не реалізована зовсім, частина реалізована не так, як очікувалося, і все одно не працює з-за великої кількості помилок. Невдоволення Замовника наростає.
Встановлюються нові релізи системи, але кожен наступний реліз працює не краще попереднього. Протоколи зустрічей вже не ведуться. Зустрічі перетворилися на взаємні претензії. Про те, що технічне завдання досі не погоджено, вже ніхто не згадує.
Складаються довгі списки помилок системи, які потрібно усунути. Нові релізи системи містять виправлення нових помилок, але виявляються старі помилки, які були виправлені раніше в попередніх релізів.
Виконавець вимагає початку дослідної експлуатації системи і підписання актів приймання, але користувачі відмовляються працювати в системі, так як вона їм не подобається і часто падає.
Акти приймання етапу розробки технічного завдання підписуються з обіцянкою Виконавця виправити всі пізніше.

Запізнювання проекту вже становить 30% - 50%. ТЗ узгоджується заднім числом.
Встановлено, нарешті, всі компоненти системи. Основні критичні помилки виправлені, але працювати в системі неможливо з-за незручності функціоналу.
Замовник просить переробити функціонал. Виконавець не погоджується без додаткової оплати, так як функціонал розроблений відповідно до ТЗ. Замовник відмовляється приймати систему. Іде довгий період нерозуміння, що робити з системою.
Відбуваються зміни на стороні Замовника (змінюються люди/процедури/процеси тощо). У зв'язку з подіями змінами стає зрозуміло: щоб хоч якось почати працювати в системі, її потрібно переробити в згідно з подіями змінами. Укладається додаткова угода на доопрацювання системи. Щоб не втратити обличчя, керівництво домовилося оголосити про новий етап проекту.
Йде тривалий етап доопрацювання. Строки перевищено вже в два рази. Співробітники Виконавця і Замовника втомилися від проекту, але не знають, як його припинити. На проекті змінюється керівник проекту Виконавця і частина проектної команди. Нова проектна команда знову збирає вимоги.
Замовник розуміє, що існуюча система працювати не буде. Стара технологія роботи здається вже не такий поганий, порівняно з новою системою. Замовник максимально гальмує впровадження системи, не знаючи як вийти з цього впровадження.
Йде довгий процес переговорів. В результаті сторони домовляються про приймання системи. Розмір грошової винагороди Виконавцю суттєво знижено. Акти закриваються. Провал не потрібен ні однієї зі сторін, тому з мовчазної згоди проект вважається успішним.
Виходить прес – реліз про успішне впровадження системи.
Ось він, нарешті, довгоочікуваний фінал. Тобто начебто не провал. Але ми знаємо…
До чого були всі ці безсонні ночі, мішки під очима, сварки з колегами, вбивство нервових клітин, якщо система все одно не працює, премій немає, а очікувана професійна задоволеність так і не настала? Витрачений величезний бюджет, а що ми отримали в результаті?
"Як сказав мені старий раб перед таверна:
"Ми, озираючись, бачимо лише руїни".
Погляд, звичайно, дуже варварський, але вірний".
і. бродський
адже було б набагато ефективніше спрямувати зусилля на благородну справу - збереження коштів рідної компанії при збереженні власного здоров'я і душевної рівноваги. Іншими словами - не намагатися врятувати проект, а, навпаки, втопити його як можна раніше. Упевнений, що ви вже знаєте або здогадуєтеся, як це зробити.
Що необхідно зробити, щоб провалити проект найбільш результативно.
Вивчіть перед проектом резюме фахівців проектної команди Виконавця. Відкидайте кандидатури співробітників до тих пір, поки ви не переконаєтеся в наступному:
Вам представлені найбільш молоді співробітники компанії Виконавця, які прийшли в команду недавно і не мають проектного досвіду.
Співробітники проектної команди ніколи раніше не працювали спільно.
Профіль фахівців проектної команди максимально далекий від вашої предметної області, а архітектура запропонованого рішення не відповідає інфраструктури компанії.
Керівник проекту Виконавця заляканий і веде себе невпевнено.
Проекти, які виконували співробітники проектної команди, не були завершені або завершені невдало.
Поставте нереально стислі терміни проекту.
Визначте максимальна кількість проектних документів, що потребують узгодження.
Складіть гранично довгий список співробітників, що погоджують проектну документацію з вашої сторони.
Затягуйте узгодження технічного завдання. Відмовляйтеся підписувати проектні документи, посилаючись на невідповідність ГОСТам, внутрішнім стандартам вашої компанії, слабку деталізацію або невідповідність бізнес-процесів.
Постійно змінюйте вимоги до системи.
Частіше проводите ротацію співробітників вашої проектної команди і предметних фахівців.
Якщо відчуєте, що проектна робота, тим не менш, почала стабілізуватися, попросіть замінити проектну команду Виконавця з причини зриву термінів етапів проекту. Почніть знову, з пункту 1.
Погодьтеся, все це зробити набагато простіше, ніж гинути за проект. При цьому ви нічого не втрачаєте. Провал проекту - це вже не провал, а ваш успіх. А якщо проект все ж завершено успішно впроваджена система, значить це дійсно гарна система, яка загартувалася в боротьбі завдяки вам. Ви в будь-якому випадку залишаєтеся у виграші. І може бути навіть з премією. За успішно виконаний проект або як результат економії коштів вашої компанії.
Удачі на проектах!