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