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