Рубрика: Анатомия провала · Блок: Бизнес-практика и кейсы
Провал проекта: человеческие причины, которых нет в плане
Провал проекта чаще всего вызван не техническими ошибками, а людьми: цели понимают по-разному, сроки планируют с избыточным оптимизмом, о проблемах молчат до последнего, а решения принимают, чтобы не спорить. Эти причины не видны в плане-графике, но их можно заметить заранее, если знать признаки и смотреть на команду, а не только на задачи.
Антикейс: как выглядит провал изнутри
Типичный сценарий выглядит так. Компания запускает проект внедрения новой системы. На старте — энтузиазм: руководство поддерживает, команда собрана, план расписан по неделям. Через два месяца первые этапы сдвигаются, но в отчётах значится «в работе, по плану». Через четыре — выясняется, что подразделения ждут от системы разного, и часть сделанного приходится переделывать. Ключевой участник уходит в другой проект. Заказчик перестаёт приходить на встречи. Через полгода проект формально закрывают как «выполненный частично», а сотрудники продолжают работать по-старому.
Если спросить участников, почему так вышло, каждый назовёт внешнюю причину: сроки были нереальные, другие отделы не помогали, требования менялись. Всё это правда, но это симптомы. Под ними лежат несколько человеческих причин, которые повторяются в провалившихся проектах любого масштаба и отрасли.
Причина 1. Размытые цели и ответственность
Цель «внедрить систему» или «повысить эффективность» каждый участник понимает по-своему. Руководство видит экономию, подразделения — удобство, ИТ — техническое решение. Пока цель не уточнена, все работают на разные результаты и считают, что работают на общий.
Та же проблема с ответственностью. Если за проект отвечают «все» или комитет, на практике не отвечает никто: решения откладываются, конфликты не разрешаются, каждый ждёт, что инициативу проявит другой. Проекту нужен один владелец с полномочиями и измеримые критерии успеха, о которых договорились с заказчиком до начала работы.
Причина 2. Оптимизм в планах
Люди систематически недооценивают время и затраты будущих задач. Это явление психологи Даниэль Канеман и Амос Тверски назвали ошибкой планирования: даже зная, что похожие задачи в прошлом заняли больше времени, мы уверены, что в этот раз всё пойдёт по плану.
К этому добавляется давление: сроки часто назначают «сверху» под желаемую дату, и команда соглашается, чтобы не выглядеть нерешительной. В результате проект с первого дня живёт в нереальном графике, отставание накапливается, и команда начинает скрывать его, чтобы не признавать провал. Защита — планировать по данным прошлых проектов, закладывать запас на неопределённость и честно обсуждать риски с заказчиком до старта.
Причина 3. Молчание о проблемах
Почти в каждом провалившемся проекте участники знали о проблемах задолго до того, как они стали очевидны руководству. Знали, но молчали: плохие новости в компании не любят, за них наказывают, а «по плану» в отчёте никого не беспокоит.
Чем позже о проблеме узнают, тем дороже её решение. Поэтому одна из главных задач руководителя проекта — сделать так, чтобы о рисках говорили рано. Помогают регулярные разборы, где обсуждают не только сделанное, но и то, что тревожит; реакция руководителя на плохую новость без поиска виноватых; вопросы к тем, кто обычно молчит. Почему люди молчат на совещаниях и что за этим стоит, разобрано в статье «Молчание в ответ».
Причина 4. Групповое мышление
Групповое мышление — явление, которое описал психолог Ирвинг Джанис: сплочённая группа принимает решение, стремясь к согласию, а не к лучшему варианту. Сомнения не высказываются, альтернативы не рассматриваются, несогласные замолкают, чтобы не нарушать единство.
В проектах это выглядит как единогласное одобрение рискованного плана, к которому потом у всех «были вопросы». Особенно часто групповое мышление возникает, когда руководитель высказывает своё мнение первым и обладает сильным авторитетом. Помогают простые приёмы: руководитель говорит последним, кто-то из участников получает роль «адвоката дьявола», альтернативы обсуждаются до выбора решения, а не после.
Причина 5. Состав команды не под задачу
Команду проекта часто собирают по принципу «кто свободен» или «кто в теме», не задумываясь, хватает ли в ней нужных ролей. В результате в одной команде оказываются только генераторы идей, и никто не доводит дело до конца, или только исполнители, и некому принимать решения в неопределённости.
| Чего не хватает в команде | Как это проявляется в проекте |
|---|---|
| Человека, который принимает решения | Вопросы висят неделями, проект дрейфует |
| Человека, который объединяет людей | Конфликты между подразделениями, низкая вовлечённость |
| Человека, который обеспечивает стабильность | Постоянная смена приоритетов, хаос в процессах |
| Человека, который проверяет качество и риски | Ошибки обнаруживаются в конце, переделки |
Профиль DISC помогает увидеть, каких поведенческих ролей в команде не хватает. Стили мышления (ACI) показывают, как участники принимают решения: кто лучше видит людей и их реакцию на изменения, кто — практические задачи, кто — системные правила и процессы. Если все в команде видят проект только с одной стороны, она пропустит риски с других. О составе команд — на странице об оценке команды, о стилях мышления — на странице о методике стилей мышления (ACI).
Как заметить проваливающийся проект заранее
Признаки проблем видны задолго до формального провала:
- в отчётах «всё по плану», но видимых промежуточных результатов нет;
- промежуточные сроки постоянно сдвигаются «на чуть-чуть»;
- участники по-разному отвечают на вопрос, что должно получиться в итоге;
- заказчик или спонсор перестаёт приходить на встречи;
- ключевые люди уходят из проекта или из компании;
- на обсуждениях молчат те, кто раньше спорил.
Заметив два-три признака, стоит остановиться и честно пересмотреть проект: цели, объём, сроки, состав команды. Иногда это спасает проект, иногда — помогает вовремя его закрыть и сберечь ресурсы. Хуже всего — продолжать по инерции, потому что «уже столько вложено». Как выстроить изменения так, чтобы люди в них участвовали, рассказано на странице об управлении изменениями.
Что делать после провала проекта
Провал проекта болезненный, но полезный опыт — если его разобрать. Многие компании предпочитают поскорее забыть неудачу, и через год повторяют те же ошибки в новом проекте с новыми людьми.
Разбор после проекта работает, когда он ищет причины, а не виноватых. Участники отвечают на несколько вопросов: что мы планировали, что получилось, в чём разница и почему, что мы сделаем иначе в следующий раз. Важно услышать разные точки зрения — заказчика, руководителя проекта, исполнителей, смежных подразделений. Часто оказывается, что каждый видел свою часть проблемы, и только вместе картина складывается.
Выводы стоит превращать в конкретные изменения: правила запуска проектов, требования к постановке целей, порядок эскалации рисков, принципы подбора команды. И отдельно — поддержать людей: участники провалившегося проекта часто теряют уверенность и вовлечённость. Признание того, что они сделали, и честный разговор о системных причинах помогают сохранить команду для следующих задач.
Частые вопросы
Каковы главные причины провала проектов?
Чаще всего — размытые цели и ответственность, нереалистичные сроки и бюджет, молчание о проблемах, решения без настоящего обсуждения, потеря поддержки руководства и состав команды, который не соответствует задаче. Технические ошибки обычно становятся следствием этих причин.
Как понять, что проект идёт к провалу?
Признаки — статусы «всё по плану» при отсутствии видимого результата, постоянные переносы промежуточных сроков, споры о том, что вообще нужно сделать, исчезновение заказчика с встреч, уход ключевых участников, молчание команды на обсуждениях.
Что такое ошибка планирования?
Это склонность недооценивать время, затраты и риски будущих задач, даже если похожие задачи в прошлом заняли больше времени. Её описали психологи Даниэль Канеман и Амос Тверски. Защита — опираться на фактические данные прошлых проектов, а не на ощущения.
Как предотвратить провал проекта?
Договориться о цели и критериях успеха с заказчиком, назначить одного ответственного, планировать с запасом по данным прошлых проектов, регулярно и честно обсуждать риски, создать условия, в которых о проблемах говорят рано, и подбирать команду под задачи проекта.
Можно ли спасти проваливающийся проект?
Иногда да: пересмотреть цели и объём, сменить подход или состав команды, вернуть вовлечённость заказчика. Иногда разумнее остановить проект и сохранить ресурсы. Решение стоит принимать по фактам, а не по уже потраченным деньгам и усилиям.
Кто виноват в провале проекта?
Поиск одного виноватого обычно мешает понять настоящие причины. Провал почти всегда складывается из нескольких факторов: целей, планирования, коммуникации, решений руководства и состава команды. Полезнее разобрать, что в системе позволило проблемам накопиться, и изменить это.