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