Блог
Почему подготовку к стройке нельзя вести по чек-листу
На бумаге подготовка к стройке премиального объекта выглядит как список задач: выбрать подрядчика, согласовать смету, получить разрешения, начать работы. На практике управляемость объекта определяет не список задач, а то, как устроены процессы вокруг него, кто фиксирует отклонение от плана, как оформляется и утверждается изменение, кто отвечает за риск до того, как он стал проблемой.
Чек-лист хорош, пока всё идёт по плану. Чек-лист прекрасно работает в стабильных условиях: пункты выполнены по порядку, то объект движется вперёд. Проблема в том, что на сложном премиальном объекте по плану идёт немного. Меняется материал, потому что нужного нет на складе. Меняется узел, потому что при детальной проработке выяснилось, что исходное решение не реализуемо. Смещается срок одной поставки и вместе с ней сдвигается очередь работ, которые от неё зависели. Чек-лист не отвечает на вопрос, что делать с этим отклонением. Он просто ждёт, пока кто-то вручную решит, что делать дальше и часто это решение принимается на словах, без следа, без оценки последствий для бюджета и графика
Управление изменениями - где чек-лист сдаётся первым. Любое изменение на стройке - это не изолированное событие, а цепочка последствий: новый материал может стоить дороже или требовать другого монтажа, смещённый срок одной работы сдвигает связанные с ней. В зрелой процессной модели изменение - это не разговор в чате, а оформленный объект: кто предложил, в чём суть, как оно влияет на бюджет, срок и уже принятые решения, кто и когда его утвердил. Без этого правила накапливается то, что можно назвать тихим ползучим удорожанием, а это десятки формально небольших решений, ни одно из которых не выглядело критичным в моменте, но их сумма к концу проекта оказывается совсем не небольшой. И что хуже, никто не может объяснить заказчику, из чего она сложилась, потому что решения нигде не были зафиксированы как связанная цепочка.
Управление рисками - не список опасностей, а рабочий инструмент. Реестр рисков, составленный один раз на старте проекта и больше не открывавшийся - это не управление рисками, а формальность для отчётности. Рабочий инструмент выглядит иначе: у каждого риска есть конкретный владелец, понятный триггер - событие, после которого риск нужно считать наступившим, а не гипотетическим и понятная реакция, что делать, когда триггер сработал. Риск пересматривается регулярно, а не один раз. Разница на практике проста: там, где риск управляется, о проблеме узнают в момент, когда её ещё дёшево решить. Там, где риска нет как процесса, о нём узнают постфактум и называют это неожиданностью, хотя чаще всего неожиданностью это не было, просто никто не отвечал за то, чтобы вовремя об этом сказать.
Что это значит для частного заказчика. Частному заказчику не нужна процессная модель уровня крупного девелопера или строительной компании с десятками регламентов и выделенным офисом управления проектами. Но два элемента этой логики работают на любом масштабе и стоят того, чтобы их требовать от любого, кто управляет подготовкой объекта. Первый - реестр изменений: каждое решение, влияющее на бюджет или график, зафиксировано письменно, с указанием, кто его принял и как оно повлияло на смету и сроки. Второй - реестр рисков с именными владельцами и понятными триггерами, который пересматривается регулярно, а не лежит закрытым файлом с даты старта проекта. Это не бюрократия ради бюрократии, а минимальный набор, который превращает управление проектом из набора устных договорённостей в то, что можно проверить в любой момент.
Что в итоге? Чек-лист и процесс решают разные задачи. Чек-лист хорош для того, что известно заранее и идёт по плану. Процесс нужен именно там, где план неизбежно нарушается, — а на сложном премиальном объекте он нарушается почти всегда. Вопрос не в том, готовы ли вы к отклонениям, а в том, есть ли у команды, которая ведёт проект, рабочий механизм, чтобы их фиксировать, оценивать и решать системно, а не по памяти и не задним числом.
Запросить услугу - управление подготовкой строительства.
Управление изменениями - где чек-лист сдаётся первым. Любое изменение на стройке - это не изолированное событие, а цепочка последствий: новый материал может стоить дороже или требовать другого монтажа, смещённый срок одной работы сдвигает связанные с ней. В зрелой процессной модели изменение - это не разговор в чате, а оформленный объект: кто предложил, в чём суть, как оно влияет на бюджет, срок и уже принятые решения, кто и когда его утвердил. Без этого правила накапливается то, что можно назвать тихим ползучим удорожанием, а это десятки формально небольших решений, ни одно из которых не выглядело критичным в моменте, но их сумма к концу проекта оказывается совсем не небольшой. И что хуже, никто не может объяснить заказчику, из чего она сложилась, потому что решения нигде не были зафиксированы как связанная цепочка.
Управление рисками - не список опасностей, а рабочий инструмент. Реестр рисков, составленный один раз на старте проекта и больше не открывавшийся - это не управление рисками, а формальность для отчётности. Рабочий инструмент выглядит иначе: у каждого риска есть конкретный владелец, понятный триггер - событие, после которого риск нужно считать наступившим, а не гипотетическим и понятная реакция, что делать, когда триггер сработал. Риск пересматривается регулярно, а не один раз. Разница на практике проста: там, где риск управляется, о проблеме узнают в момент, когда её ещё дёшево решить. Там, где риска нет как процесса, о нём узнают постфактум и называют это неожиданностью, хотя чаще всего неожиданностью это не было, просто никто не отвечал за то, чтобы вовремя об этом сказать.
Что это значит для частного заказчика. Частному заказчику не нужна процессная модель уровня крупного девелопера или строительной компании с десятками регламентов и выделенным офисом управления проектами. Но два элемента этой логики работают на любом масштабе и стоят того, чтобы их требовать от любого, кто управляет подготовкой объекта. Первый - реестр изменений: каждое решение, влияющее на бюджет или график, зафиксировано письменно, с указанием, кто его принял и как оно повлияло на смету и сроки. Второй - реестр рисков с именными владельцами и понятными триггерами, который пересматривается регулярно, а не лежит закрытым файлом с даты старта проекта. Это не бюрократия ради бюрократии, а минимальный набор, который превращает управление проектом из набора устных договорённостей в то, что можно проверить в любой момент.
Что в итоге? Чек-лист и процесс решают разные задачи. Чек-лист хорош для того, что известно заранее и идёт по плану. Процесс нужен именно там, где план неизбежно нарушается, — а на сложном премиальном объекте он нарушается почти всегда. Вопрос не в том, готовы ли вы к отклонениям, а в том, есть ли у команды, которая ведёт проект, рабочий механизм, чтобы их фиксировать, оценивать и решать системно, а не по памяти и не задним числом.
Запросить услугу - управление подготовкой строительства.