Kitabı oxu: «Управление крупными строительными проектами»

Об этой книге

Учебные проекты «Северный узел» и «Южный терминал» вымышлены вместе с их участниками, цифрами и событиями. Они собраны из типичных ситуаций крупных строек и не описывают ни один реальный объект, организацию или человека; совпадения случайны. Реальные объекты, на которых работает автор, в книге не раскрываются.

Ссылки на законы, стандарты и другие нормативные акты приведены по состоянию на октябрь 2026 года. Нормы меняются, поэтому перед применением сверяйте действующую редакцию по официальным источникам.

Книга — не юридическая, не налоговая и не инвестиционная консультация. Решения по конкретному контракту, спору или вложению принимайте вместе с юристом и финансовой службой своей компании.

От автора

В строительство я пришла из права. Много лет руководила юридическими службами, читала договоры подряда, спорила о неустойках и сроках и была уверена, что понимаю, как устроена стройка. Потом оказалась на площадке космодрома Восточный: сначала заместителем руководителя строительства, потом — директором обособленного подразделения, которое ведёт объекты «под ключ», от рабочей документации и проектных организаций до сдачи в эксплуатацию. Инженерный диплом я получила уже работая в строительстве.

Этот путь научил меня одной вещи, ради которой и написана книга. Юрист видит в проекте договор. Инженер — конструкцию и технологию. Экономист — деньги. Каждый прав, и каждый видит только часть. Крупный проект проваливается не там, где не хватило знаний в одной области. Он проваливается там, где никто не держал в голове всю картину сразу: решение, его цену, его юридические последствия и людей, которым предстоит его исполнять.

Эта книга написана для тех, кто держит такую картину: руководителей строительных проектов, технических заказчиков, директоров по строительству. И для тех, кто готовится ими стать, в том числе выпускников программ MBA по управлению проектами. Я опираюсь на признанные методы проектного управления, но переношу их в российские условия: государственный заказчик, 44-ФЗ, экспертиза, казначейское сопровождение, удалённые площадки, вахта. В зарубежных учебниках этих условий почти нет, а на российском крупном объекте именно они чаще всего решают, уложится ли проект в срок и деньги.

Как устроена книга. В её центре стоит авторская модель «Семь точек невозврата». Это семь решений, после которых ошибку можно исправить только ценой денег, срока или репутации. Первая часть объясняет саму модель, части со второй по девятую проводят читателя через семь точек по порядку, от замысла до ввода (пятой точке, контуру управления, отведены две части), а десятая посвящена людям. В каждой главе есть инструмент, которым можно воспользоваться уже завтра, и метрика, по которой видно, работает ли он. Пороговые значения метрик (80 %, 70 %, двенадцать дней и другие) — авторские ориентиры, а не нормативы: настраивайте их под свой проект. В десяти главах есть врезки «Если вы заказчик», а в восьми — «Как это делают в мире»: разбор зарубежного проекта и вывод о том, что из его опыта применимо у нас. Каждая глава завершается рабочим блоком: пошаговый алгоритм, типичные ошибки, упражнение, ситуация для разбора, вопросы для ближайшего совещания и три тезиса «Главное в главе». В конце книги есть карта всех инструментов с подсказкой, когда каким пользоваться, маршруты чтения для разных ролей, экспресс-аудит проекта по семи точкам, все формулы на одной странице и предметный указатель.

Об учебном проекте. Через всю книгу проходит история одного объекта, инфраструктурного комплекса «Северный узел» в удалённом регионе. Оба учебных проекта вымышлены, об этом сказано в самом начале книги. Для контраста в каждой главе появляется второй учебный проект, «Южный терминал». Там похожие ситуации решены иначе. Сравнение двух историй показывает: разница между провалом и успехом чаще всего не в таланте команды, а в нескольких вовремя принятых решениях.

Что известно и что авторское. Критический путь, освоенный объём, реестр рисков, оценка инвестиций давно известны, и я привожу их со ссылками на первоисточники. Модель семи точек невозврата, матрица «7 × 3» и инструменты, адаптированные к российской практике, — авторский синтез.

Книгу можно читать подряд, а можно начать с той главы, где сейчас находится ваш проект. Но пролог стоит прочитать первым: в нём звучит вопрос, на который отвечает вся книга.

Пролог. Объект, который все строили и никто не сдал

Учебный проект «Северный узел». Художественная реконструкция; все имена и детали вымышлены.

В конференц-зале административного здания пахло свежей краской. Здание было готово: фасад из композитных панелей, ровные полы, светильники в потолке. За окном видны складской корпус, котельная с трубой, асфальтированная площадка для техники. Три года работы, почти четыре миллиарда рублей, четыреста человек на пике. Марина Королёва, руководитель проекта генподрядчика, впервые за много месяцев выспалась. Через неделю — итоговая проверка органа строительного надзора, затем заключение о соответствии и разрешение на ввод.

Совещание длилось сорок минут. За это время выяснились три вещи.

Первая. У объекта нет постоянного электроснабжения. Здание работает от временной дизельной электростанции, которую генподрядчик арендует с начала стройки. Линию электропередачи и подстанцию по договору технологического присоединения должна построить сетевая организация. Срок по договору истёк год назад, а линия построена наполовину. В контракте генподрядчика её не было. В графике проекта тоже: она «шла отдельно».

Вторая. Эксплуатирующая организация, которой заказчик собирается передать объект, отказывается его принимать. Её специалисты впервые увидели проект котельной два месяца назад и потребовали другую систему автоматики — ту, что стоит на всех их объектах и под которую обучен персонал. Формально они не правы: проект прошёл экспертизу. Фактически без них объект не заработает.

Третья. Исполнительная документация по наружным сетям собрана на шестьдесят процентов. Часть актов скрытых работ подписана задним числом, а по части освидетельствование не проводилось вовсе: сети засыпали, когда «горел» график. Инспектор, который придёт через неделю, это увидит.

Представитель заказчика долго молчал, а потом спросил о том, о чём в эту минуту думали все:

— Как это получилось? Мы же каждую неделю видели, что всё идёт по плану.

Вопрос был справедливым. Отчёты действительно показывали движение: бетон заливали, металл монтировали, проценты росли. На каждом совещании обсуждали отставание по конкретным работам, и каждое удавалось закрыть. Подрядчики работали, проектировщики отвечали на вопросы, деньги платились. Никто не саботировал, никто не воровал, никто не был некомпетентен.

И всё же объект, построенный почти полностью, нельзя было ввести в эксплуатацию ещё как минимум восемь месяцев. Каждый из них стоил генподрядчику аренды дизельной станции, охраны, содержания городка и зарплаты команды, которая в полном составе была уже не нужна. А неустойка по контракту начислялась с первого дня просрочки.

Через полгода Марина разбирала эту историю и нашла ответ, который ей не понравился. Проект проиграли не на площадке. Его проиграли в нескольких решениях, принятых задолго до финала, а некоторые за три года до того совещания. Каждое тогда казалось разумным или вообще не казалось решением. Электроснабжение «шло отдельно», потому что так было записано в задании на проектирование. Эксплуатацию не позвали на этапе проекта, потому что её тогда ещё не определили. Исполнительную документацию откладывали, потому что надо было держать темп.

Эта книга о таких решениях. О том, как распознать их заранее, пока их ещё можно принять иначе. Я называю их точками невозврата: после каждой ошибку можно исправить только ценой денег, срока или репутации.

Мы будем возвращаться к «Северному узлу» на протяжении всей книги и пройдём его историю с самого начала, от первых исходных данных до того дня в конференц-зале. В эпилоге станет видно, где именно была совершена каждая ошибка и как всё могло сложиться иначе.

Часть I. Анатомия строительного проекта

Почему крупные проекты срываются системно, что такое семь точек невозврата и каким мандатом должен обладать руководитель проекта.

Глава 1. Почему большие проекты срываются системно

Спросите руководителей, почему их крупный проект вышел за сроки и бюджет, и ответы будут разными. Подрядчик подвёл, проектировщик опоздал, заказчик менял задание, металл подорожал, зима пришла рано. Каждое объяснение правдиво. Но если собрать сотни таких историй, проступает странная вещь: причины разные, а результат почти всегда одинаковый. Значит, дело не в конкретных обстоятельствах, а в чём-то, что повторяется от проекта к проекту.

Железный закон мегапроектов. Датский исследователь Бент Фливбьорг десятилетиями собирал данные о больших проектах по всему миру: дорогах, мостах, зданиях, энергетических объектах, IT-системах. Свой вывод он сам назвал железным законом: крупные проекты выходят за бюджет, выходят за сроки и не дают ожидаемой пользы, и так снова и снова. В книге «How Big Things Get Done» (2023), написанной вместе с Дэном Гарднером, он приводит итог по базе из более чем шестнадцати тысяч проектов. Лишь 8,5 % из них уложились одновременно в бюджет и срок, и лишь 0,5 % — в бюджет, срок и запланированные выгоды.

Важно не столько само число, сколько форма распределения. Большинство проектов отклоняются умеренно, но заметная часть уходит в «хвост»: перерасход там измеряется разами, а не процентами. Такие провалы не редкая случайность, а закономерная часть статистики. Поэтому руководитель крупного проекта должен исходить из того, что его проект может оказаться в этом хвосте, и строить управление так, чтобы вовремя это заметить.

Почему умные люди планируют плохо. Даниэль Канеман и Амос Тверски описали ошибку планирования ещё в конце 1970-х годов. Люди систематически недооценивают время и затраты на собственные задачи, даже когда знают, что похожие задачи в прошлом занимали больше. Мы планируем изнутри: представляем, как всё пойдёт, если ничего не помешает. Но на большом проекте что-нибудь мешает всегда.

К психологическому объяснению Фливбьорг добавил политическое — стратегическое искажение. Проект с честной оценкой стоимости и рисков часто не получает одобрения. Поэтому на этапе обоснования оценки становятся оптимистичнее, чем считают сами их авторы. Это не всегда сознательный обман. Чаще это правила игры, в которой выигрывает тот, кто пообещал дешевле и быстрее.

Пять системных причин в российских условиях. Международные исследования объясняют общую природу срывов. Российский проект с государственным заказчиком добавляет к ней свои механизмы. Назову пять, с которыми руководитель сталкивается почти на каждом крупном объекте.

Первая — твёрдая цена при неполной информации. По закону о контрактной системе цена государственного контракта, как правило, твёрдая. Но контракт часто заключают, когда проект ещё не доведён до рабочей документации, а условия площадки известны не полностью. Подрядчик берёт на себя риск того, чего ещё никто не знает, а снижение цены на торгах съедает запас, который мог бы этот риск покрыть.

Вторая — проектирование параллельно со стройкой. Рабочую документацию часто выпускают по ходу строительства. Это ускоряет старт, но делает график выдачи чертежей главным ограничителем всего проекта. Площадка ждёт решений, снабжение не может заказать оборудование, а изменения в проекте ложатся на уже выполненные работы.

Третья — бюджетный цикл. Финансирование государственных проектов привязано к годовым лимитам. Деньги, не освоенные в году, могут не перейти на следующий, а лимиты будущих лет зависят от решений, которые принимаются за пределами проекта. Отсюда давление «освоить любой ценой» в конце года и паузы в начале следующего.

Четвёртая — множество согласований. Экспертиза, технические условия сетевых организаций, согласования с эксплуатацией, надзорными органами, местной властью. У каждого согласования своя логика и свой срок, и ни одно не подчиняется графику проекта.

Пятая — удалённость и сезонность. Крупные инфраструктурные объекты часто строятся далеко от больших городов: завоз ограничен, персонал работает вахтой, строительный сезон короткий. Ошибка в планировании, которую в городе исправляют за неделю, здесь стоит месяцы.

Что из этого следует. Если причины системные, то и управление должно быть системным. Нельзя рассчитывать, что сильная команда «вытянет» проект на энтузиазме: сильные команды тоже оказываются в хвосте распределения. Зато можно другое: заранее знать, где проект уязвимее всего, и тратить внимание руководителя именно там.

Опыт показывает, что такие места распределены по проекту неравномерно. Есть немногие решения, после которых пространство для манёвра резко сужается. Если они приняты правильно, проект выдерживает множество мелких ошибок исполнения. Если неправильно, никакое исполнение уже не спасёт. Таких решений семь, и о них пойдёт речь в следующей главе.

Инструмент главы: экспресс-диагностика проекта. Ответьте на семь вопросов «да» или «нет». Каждое «нет» — точка, в которой проект уже сейчас находится в зоне риска.

1. Все исходные данные, от которых зависит результат, получены и подтверждены документами, включая условия подключения к сетям?

2. Контрактная модель выбрана осознанно, и известно, у кого какие риски?

3. Цена контракта покрывает реальную себестоимость с резервом на риски?

4. Рабочая документация выдаётся раньше, чем она нужна площадке и снабжению?

5. Отклонения по деньгам и срокам видны раньше, чем они попадают в отчёт о срыве?

6. Есть понятный порядок действий, если проект пошёл не так, и он уже применялся?

7. Подготовка к вводу в эксплуатацию идёт с первого года стройки, а не с последнего месяца?

Метрика главы: число ответов «нет». Проект с тремя и более «нет» требует внимания руководства компании, а не только руководителя проекта.

Ход учебного проекта. Проведи Марина Королёва эту диагностику в первый месяц работы над «Северным узлом», она получила бы четыре ответа «нет». Условия электроснабжения не были подтверждены, контрактная модель досталась от заказчика без анализа рисков, график выдачи РД не был связан со стройкой, а о вводе никто не думал. Тогда это выглядело обычным состоянием старта. Через три года каждый из этих ответов превратился в отдельную проблему на совещании из пролога.

Пошаговый алгоритм: системная диагностика проекта.

1. Соберите референтный класс. Возьмите пять–десять завершённых проектов компании или известных вам объектов похожего типа и масштаба. Для каждого запишите плановый и фактический срок, плановую и фактическую стоимость. Даже грубые данные лучше, чем никаких.

2. Определите типичное отклонение. Посчитайте среднее и худшее отклонение по срокам и стоимости. Это ваш реалистичный ориентир: если ни один из прошлых проектов не уложился в план, нет причин думать, что текущий уложится без особых мер.

3. Проведите экспресс-диагностику. Ответьте на семь вопросов из этой главы вместе с главным инженером, руководителем ПТО, юристом и экономистом. Каждый видит свою часть картины, и ответы «нет» чаще всего прячутся на стыке их зон.

4. Назовите системные причины. Для каждого ответа «нет» определите, какая из пяти российских причин за ним стоит: твёрдая цена при неполной информации, параллельное проектирование, бюджетный цикл, множественность согласований или удалённость.

5. Сформулируйте задачи. Каждая уязвимость становится задачей с владельцем, сроком и признаком выполнения. Задача без владельца так и остаётся тревогой.

6. Повторяйте раз в квартал. Диагностика не разовая: по мере движения проекта одни уязвимости закрываются, другие появляются.

Как это сделали иначе. Учебный проект «Южный терминал», художественная реконструкция. Андрей Волков возглавил проект логистического терминала на юге страны. Тоже государственный заказчик, тоже торги по проектной документации и рабочая документация, которая выпускалась по ходу стройки. В первую неделю он не поехал на площадку. Он собрал главного инженера, руководителя ПТО, юриста и экономиста и полтора дня провёл с ними экспресс-диагностику по семи вопросам. Ответов «нет» оказалось три. Условия подключения к водоснабжению были выданы на старую точку, которую водоканал собирался закрывать. График выдачи рабочей документации никто не видел. Себестоимость объекта в компании не считали.

Ни одна из этих проблем ещё не горела. Но Волков оформил каждую как задачу с владельцем и сроком и в первый же месяц отправил заказчику три письма: о необходимости уточнить условия подключения, о датах потребности в документации и о связанных с ними рисках. Через полтора года водоканал действительно закрыл старую точку. К этому времени у проекта уже были новые условия, а у генподрядчика — переписка, подтверждающая, что риск был заявлен вовремя. Разница с «Северным узлом» возникла не на площадке, а в первую же неделю.

Как это делают в мире. Министерство финансов Великобритании борется с ошибкой планирования напрямую. В дополнительном руководстве к Green Book, по которому оценивают государственные проекты, сказано, что оценщики склонны к излишнему оптимизму, и поэтому оценки стоимости, выгод и сроков нужно явно поправлять. Поправку берут из данных прошлых и похожих проектов, а если своих данных нет, используют типовые проценты по категориям проектов. Оптимизм там считают не чертой характера, а систематической погрешностью, которую закладывают в расчёт. Что применимо у нас: даже без такого требования в законе компания может ввести собственную поправку на оптимизм по своим завершённым объектам. Это и есть референтный класс из пошагового алгоритма этой главы.

Типичные ошибки.

• Считать срыв случайностью. После провала команда объясняет его уникальным стечением обстоятельств и ничего не меняет. На следующем объекте обстоятельства будут другими, а результат — прежним.

• Планировать по лучшему сценарию. Сроки и бюджет закладывают так, будто ничего не помешает. Это не оптимизм, а систематическая ошибка, и исправить её можно только одним способом: опираться на фактические результаты прошлых проектов.

• Тратить внимание по громкости. Руководитель реагирует на то, что шумит сегодня, и не замечает тихих проблем, которые станут громкими через год.

• Путать занятость с управлением. Совещания, отчёты и поездки на площадку создают ощущение контроля. Но контроль — это знание, где проект уязвим, и действия именно там.

Упражнение. Возьмите последний проект вашей компании, который вышел за сроки или бюджет. Выпишите все причины срыва, которые назывались на итоговых совещаниях, и разложите их по пяти системным причинам из этой главы. Отдельно отметьте «непредвиденные» причины, то есть те, что на самом деле случаются почти на каждом объекте. Если таких больше половины, проблема не в обстоятельствах, а в том, как компания планирует.

Ситуация для разбора: «нам просто не повезло».

Итоговое совещание по проекту логистического комплекса, сданному почти на год позже срока. Руководитель проекта перечисляет причины: экспертиза вышла поздно, весной подорожал металл, сменился субподрядчик по инженерным системам, зима выдалась ранней. Каждая причина подтверждена документами. Совет директоров соглашается, что проекту не повезло, и утверждает следующий с той же командой, той же контрактной схемой и тем же подходом к графику. Через полтора года второй проект повторяет судьбу первого, только с другим набором «невезений».

Вопрос для разбора: где в этой истории системная причина и почему её никто не увидел?

Комментарий автора. По отдельности каждая причина и правда похожа на внешнее событие. Но если сложить их вместе, проступает общее: у проекта не было резерва ни во времени, ни в деньгах, ни в ресурсах, и любое отклонение сразу превращалось в задержку. Экспертиза выходит поздно у многих, металл дорожает регулярно, субподрядчики меняются, зимы бывают ранними. Системная причина — график и бюджет, построенные на допущении, что ничего не случится. Совет директоров принял объяснение, потому что оно никого не обвиняло, и именно поэтому оно ничему не научило. Правильный вопрос на итоговом совещании звучит не «что нам помешало», а «почему наш план не выдержал обычных для отрасли событий».

Вопросы для ближайшего совещания.

• Как отклонялись от плана по срокам и стоимости наши последние три проекта похожего масштаба?

• Какие из семи вопросов экспресс-диагностики получили бы сегодня ответ «нет»?

• Какая из пяти системных причин сильнее всего угрожает именно этому проекту?

• На что руководитель проекта тратил больше всего времени в последний месяц — и совпадает ли это с главными уязвимостями?

• Какую проблему, которая сейчас тихая, мы увидим громкой через год?

Главное в главе.

• Причины срывов разные, а результат почти всегда одинаковый. Значит, дело не в обстоятельствах, а в системе.

• Планируйте от фактических результатов прошлых проектов, а не от сценария, в котором ничего не помешает.

• Тратьте внимание там, где проект уязвим, а не там, где сегодня громче всего.

Глава 2. Семь точек невозврата

На любой стройке наступает момент, когда арматуру закрывают бетоном. До этой минуты ошибку в армировании исправляют за час: переставляют стержни, добавляют хомуты. После заливки исправить её можно только вскрытием конструкции, экспертизой, усилением, а иногда и сносом. Любой прораб знает: скрытые работы проверяют до закрытия. Удивительно, как редко тот же принцип применяют к управленческим решениям, хотя устроены они точно так же.

Кривая, которую знают проектировщики. В архитектурной практике хорошо известна закономерность, которую обычно рисуют двумя пересекающимися кривыми. По мере движения проекта возможность влиять на его стоимость и результат падает, а цена любого изменения растёт. На стадии замысла здание можно бесплатно передвинуть на сто метров. На стадии рабочей документации это уже стоит денег и времени. После заливки фундамента обходится переделкой. Одним из первых эту зависимость описал американский инженер Бойд Полсон в 1976 году, а в 2000-е годы её популяризировал архитектор Патрик Маклими, и сегодня её часто называют кривой Маклими. Кривая описывает проектирование, но на практике верна для всего строительного проекта: для контракта, выбора подрядчика, подготовки к вводу.

Рис. 1. Возможность влиять на результат и цена изменения по ходу проекта. Качественная схема по мотивам кривой Полсона — Маклими; положение точек условно

Вывод из неё простой: внимание руководителя ценнее всего там, где решение ещё можно изменить дёшево. На практике же внимание распределяется наоборот. В начале проекта всё кажется управляемым, проблем мало, и руководство занято другими объектами. В конце, когда кривая уже наверху, начинаются ежедневные совещания и штабы. Руководитель тратит больше всего сил там, где может изменить меньше всего.

Что такое точка невозврата. Точкой невозврата я называю решение, после которого исправление ошибки требует непропорционально больших денег, времени или репутации. Важно: точка невозврата — это не катастрофа и не кризис. Чаще всего это рутинное событие: подписание задания на проектирование, выбор схемы договоров, подача заявки на торги. В тот момент, когда оно происходит, никто не чувствует, что принимается судьбоносное решение.

На строительных проектах, с которыми я работала, и в историях, которые изучала, эти точки повторяются. Их семь.

1. Замысел. Что строим, зачем и на каких исходных данных. Здесь определяется, будет ли у объекта всё необходимое для работы: сети, дороги, эксплуатация, а не только здание. Ошибка в замысле не видна, пока не наступает момент ввода.

2. Модель. Кто и как будет строить: генподряд или раздельные договоры, кто проектирует, кто отвечает за поставки, как распределены риски. Модель решает, у кого окажется проблема, когда она возникнет.

3. Сделка. За сколько и на каких условиях: цена, сроки, порядок приёмки и оплаты, ответственность. После подписания контракта всё это можно изменить только по основаниям, которые предусмотрены законом и договором.

4. Проект. По каким решениям мы строим и когда эти решения будут готовы. Здесь решается, будет ли площадка работать по готовым чертежам или ждать их, успеют ли вовремя заказать оборудование.

5. Контур. Как мы узнаем об отклонении раньше, чем оно станет срывом. Это система управления: графики, показатели, отчётность, каналы информации. Если контур не построен в начале, проект идёт вслепую.

6. Поворот. Что мы делаем, когда проект пошёл не так. Это не одно решение, а момент, который наступает почти на любом крупном проекте. Точка невозврата здесь измеряется временем: каждый месяц, на который откладывают признание проблемы, сужает выбор.

7. Финиш. Как довести объект до ввода в эксплуатацию и закрыть без хвостов. Подготовка к финишу начинается не в конце, а в первый год: для ввода нужны документы, согласования и люди, которых за месяц не получить.

Три силы. Каждая точка невозврата — это одновременно экономическое, юридическое и человеческое решение. Выбор контрактной модели — это и распределение рисков в деньгах, и конструкция договоров, и решение о том, кто вообще будет участвовать в проекте. Поэтому каждую точку я рассматриваю через три силы: деньги, право и люди. Так получается матрица 7 × 3.

Как пользоваться моделью. У модели три применения.

Первое — планирование внимания. Для каждой точки определите, когда она наступает в вашем проекте и кто принимает решение. Эти даты важнее многих вех графика: в такие дни руководитель должен присутствовать лично, а не узнавать обо всём из отчётов.

Второе — диагностика. Если проект уже идёт, пройдите по точкам и оцените, как было принято каждое решение. Ошибка, найденная в пройденной точке, ещё не проявилась, но уже заложена. Если знать о ней заранее, её последствия можно смягчить.

Третье — общий язык с руководством. Фраза «мы проходим третью точку невозврата, решение о цене нельзя принимать без расчёта себестоимости» действует сильнее общих слов о рисках. Модель помогает объяснить, почему именно сейчас нужны время, деньги или внимание руководства.

Чего модель не делает. Она не заменяет методы проектного управления: календарное планирование, управление стоимостью и рисками подробно описаны в стандартах и учебниках. Модель лишь показывает, где эти методы важнее всего применить и где их пропуск обходится дороже всего.

Инструмент главы: карта точек невозврата проекта.

Заполните карту в первую неделю работы над проектом и пересматривайте раз в квартал. Каждая следующая часть книги разбирает одну точку и даёт инструменты, которые понадобятся к моменту её прохождения.

Метрика главы: доля ключевых решений, принятых уже после наступления своей точки невозврата, когда изменить их без потерь нельзя. Её считают при разборе проекта, и она показывает, насколько управление опережает события.

Ход учебного проекта. Когда «Северный узел» стартовал, первые две точки были уже пройдены без генподрядчика: замысел и модель определил заказчик. Третью точку, сделку, Марина прошла, не видя всей картины: торги шли по проектной документации, а цену снизили на семь процентов, чтобы выиграть. Впереди оставались четыре точки. Для генподрядчика это обычная ситуация: часть решений приходит готовыми. Именно поэтому первая неделя должна начинаться не с вопроса «что строим», а с вопроса «какие решения за нас уже приняты и что в них заложено».

Пошаговый алгоритм: работа с картой точек невозврата.

1. Отметьте пройденные точки. Для каждой из семи точек определите, пройдена ли она в вашем проекте. Генподрядчик, пришедший на готовый контракт, обычно застаёт пройденными первые две, а третью, сделку, проходит сам на торгах.

2. Разберите решения, принятые за вас. По каждой пройденной точке выпишите, что именно решено, кем и какие риски это создаёт для вашей стороны. Цель не в том, чтобы оспорить решение, а в том, чтобы знать, что в нём заложено.

3. Пройдите по трём силам. Для каждой точки ответьте на три вопроса: что это значит для денег проекта, для его юридической позиции и для людей. Пустая клетка в матрице 7 × 3 — зона, которую никто не продумал.

4. Назначьте даты будущих точек. Для непройденных точек определите, когда они наступят. Внесите эти даты в график руководителя проекта как отдельные вехи.

5. Подготовьтесь заранее. К каждой будущей точке составьте список того, что должно быть готово: данные, расчёты, согласования, люди.

6. Пересматривайте раз в квартал. Отмечайте, какие точки пройдены, с каким результатом и что из этого следует для следующих.

Как это сделали иначе. На «Южном терминале» первые две точки тоже прошли без генподрядчика. Но Волков начал не с жалоб на то, что «всё решили за нас», а с инвентаризации этих решений. За неделю его команда составила список того, что заказчик уже определил: схему договоров, состав проектной документации, порядок передачи рабочей документации, источник финансирования по годам. Напротив каждого решения записали, какой риск оно создаёт для генподрядчика и что с ним можно сделать уже сейчас.

Оказалось, что изменить нельзя почти ничего, а смягчить можно многое. Порядок выдачи документации «по мере готовности» в контракте не перепишешь, но можно в первый же месяц письменно сообщить заказчику даты потребности. Годовые лимиты финансирования не изменишь, но можно построить график так, чтобы к концу года объём выполненных и подтверждённых работ совпадал с лимитом, а не опережал его. Карта точек невозврата на одной странице весь срок стройки висела в кабинете руководителя проекта. Раз в квартал Волков отмечал на ней, какие точки пройдены и с каким результатом.

Типичные ошибки.

• Считать точку невозврата кризисом. Кризис заметен, а точка невозврата нет. Если ждать, пока решение станет драматичным, оно к тому времени уже будет принято по умолчанию.

• Не замечать решений, принятых за вас. Генподрядчик, пришедший на готовый контракт, считает первые точки чужой зоной. Но последствия этих решений ложатся на него, и знать их нужно в первую же неделю.

• Видеть решение только в одной плоскости. Выбор подрядчика обсуждают как вопрос цены и забывают о праве и людях. Выбор схемы договоров — как юридический вопрос и забывают о деньгах. Матрица 7 × 3 нужна именно для того, чтобы видеть все три силы сразу.

• Сосредоточиться на финише. Самые громкие события проекта происходят в конце. Самые важные — в начале.

Упражнение. Заполните карту точек невозврата для своего текущего проекта. По каждой точке ответьте: пройдена она или нет. Если пройдена — кто принял решение и что в нём заложено. Если нет — когда она наступит и что к этому моменту должно быть готово. Отдельно отметьте точки, где решение приняли без вас. Для каждой запишите одно действие, которое смягчит её последствия, и дату, к которой вы его выполните.

Ситуация для разбора: решение, которое приняли по умолчанию.

Заказчик торопится выйти на площадку и предлагает начать земляные работы, не дожидаясь окончания инженерно-геологических изысканий по всему участку: «по соседнему объекту грунты нормальные, здесь будет то же самое». Руководитель проекта не возражает: формально решение принимает заказчик, а площадка и правда простаивает. Через два месяца на части участка обнаруживаются слабые грунты. Тип фундамента меняется, часть выполненных работ приходится переделывать, а проектировщик ещё три месяца выпускает изменения.

Вопрос для разбора: какая точка невозврата здесь была пройдена и что должен был сделать руководитель проекта?

Комментарий автора. Это классический пример того, как первую точку невозврата, «Замысел», проходят не решением, а молчанием: исходные данные приняли такими, какими они оказались. Руководитель проекта не обязан запрещать заказчику начинать работы. Но он обязан добиться, чтобы заказчик принял решение осознанно: письменно зафиксировать, что изыскания не завершены, оценить последствия возможной ошибки в днях и деньгах, предложить вариант, например, начать с участков, где данные уже есть. Заказчик мог бы принять тот же риск. Но тогда это было бы его решение с понятной ценой, а не общее разочарование задним числом.

Вопросы для ближайшего совещания.

• Какие решения по нашему проекту были приняты до нас, и что в них заложено?

• Какая следующая точка невозврата нас ждёт и когда?

• Что должно быть готово к этому моменту, и кто за это отвечает?

• В какой из трёх плоскостей — деньги, право, люди — мы меньше всего продумали ближайшее ключевое решение?

• Где мы сейчас тратим максимум сил там, где можем изменить меньше всего?

Главное в главе.

• Точка невозврата — обычное рабочее решение, после которого исправить ошибку можно только непропорционально дорого. Никакой драмы в момент её прохождения нет.

• Семь точек: замысел, модель, сделка, проект, контур, поворот, финиш. Каждую решают деньги, право и люди одновременно.

• Внимание руководителя ценнее всего в начале. Решения, принятые за вас, нужно знать в первую неделю.

Глава 3. Руководитель проекта: мандат, власть, ответственность

В российских строительных компаниях должность «руководитель проекта» может означать очень разное. В одной компании это человек, который распоряжается бюджетом объекта, подписывает договоры с субподрядчиками и сам ведёт переговоры с заказчиком. В другой — координатор: собирает отчёты и передаёт просьбы площадки в головной офис, где решения принимают другие. Название одно, а возможности влиять на результат отличаются в разы. Отвечать же за срыв обоим придётся одинаково.

Ответственность без полномочий. Это самая распространённая и самая разрушительная конфигурация. Руководителю проекта поручают сдать объект в срок и в бюджете, но не дают права выбрать субподрядчика, перераспределить деньги между статьями, нанять ключевого специалиста или отправить заказчику письмо без согласования с тремя службами. Каждое решение уходит наверх и возвращается через неделю. Проект движется со скоростью самого медленного согласования.

Теория управления проектами давно описала эту проблему через типы организационных структур. В функциональной структуре власть принадлежит начальникам отделов, а руководитель проекта лишь координирует. В проектной у руководителя проекта собственные ресурсы и полномочия. Между ними лежат матричные структуры, где руководитель проекта делит власть с функциональными руководителями. Большинство строительных компаний устроены матрично: ПТО, снабжение, юристы, финансы подчиняются головному офису, а работают на объект. Само по себе это нормально. Ненормально, когда никто не определил, кто и в какой ситуации принимает решение.

Мандат — это не должностная инструкция. Должностная инструкция описывает обязанности, а мандат — права: какие решения руководитель проекта принимает сам, какие согласует, а о каких только информирует. Мандат должен отвечать на конкретные вопросы:

• до какой суммы руководитель проекта может перераспределять средства между статьями бюджета;

• может ли он сам заключать договоры с субподрядчиками и поставщиками, и в каких пределах;

• вправе ли он направлять заказчику юридически значимые уведомления — о препятствиях, приостановке, неучтённых работах;

• подписывает ли он акты о приёмке выполненных работ и исполнительную документацию;

• может ли он нанимать и увольнять ключевых людей команды объекта;

• в какой срок головной офис обязан ответить на его запрос, и что происходит, если ответа нет.

Последний пункт важнее, чем кажется. Многие проекты теряют недели не потому, что руководителю не дали полномочий, а потому, что вопрос «завис» между службами. Правило «нет ответа в течение трёх рабочих дней — решение руководителя проекта считается согласованным» дисциплинирует систему сильнее любого регламента.

Юридическая сторона полномочий. Для внешнего мира полномочия руководителя проекта существуют, только если они оформлены: доверенностью, приказом, указанием в контракте. Письмо заказчику, подписанное человеком без полномочий, может не иметь юридической силы. И это не теоретический риск: в спорах о сроках подрядчики проигрывают именно потому, что уведомления о препятствиях подписал не тот человек или отправили не тем способом. Закон прямо связывает последствия уведомления с его доставкой: юридически значимое сообщение действует с момента, когда оно доставлено адресату или его представителю (п. 1 ст. 165.1 ГК РФ). Значит, важны и подпись, и способ отправки, и доказательство доставки. Поэтому мандат руководителя проекта должен быть отражён в доверенности, а порядок подписания документов по объекту известен заказчику.

Верховный Суд разъяснил, как это работает на практике. Юридически значимое сообщение можно направить и по электронной почте, если закон, договор или сложившаяся практика сторон не требуют иного, но отправитель должен доказать, что сообщение отправлено и доставлено (п. 65 и 67 постановления Пленума ВС РФ от 23.06.2015 № 25). Если контракт требует писать через систему электронного документооборота, письмо на обычную почту рискует не считаться надлежащим уведомлением. Именно так случилось на «Северном узле» (глава 10).

Власть, которой нет в документах. Мандат определяет формальную власть. Но на крупном проекте не менее важна неформальная: доверие заказчика, авторитет у подрядчиков, доступ к первому лицу компании, репутация человека, который держит слово. Руководитель с узким мандатом и сильной неформальной властью часто добивается большего, чем руководитель с широким мандатом, которому никто не верит.

Неформальную власть не получить приказом, но её можно выстроить. Она растёт из трёх вещей. Из точности: обещания выполняются в срок или заранее пересматриваются. Из предсказуемости: решения принимаются по понятной логике, а не по настроению. И из защиты команды: руководитель берёт на себя ответственность за ошибки системы, а не перекладывает их на исполнителей.

Распределение ответственности: RACI. Для ключевых процессов проекта полезно составить матрицу ответственности. Самый распространённый её формат называется RACI: для каждого процесса указывают, кто исполняет (Responsible), кто отвечает за результат (Accountable), с кем советуются (Consulted) и кого информируют (Informed). Главное правило: у каждого процесса ровно один ответственный за результат. Если их двое, на деле нет ни одного.

Инструмент главы: устав строительного проекта. Национальный стандарт ГОСТ Р 54869 описывает процесс инициации проекта (п. 5.2). Его цель — формальное открытие проекта, а на выходе документируют цели и продукты, заказчика, руководителя и куратора проекта. В международной практике (PMBOK) документ, которым оформляют это открытие, называют уставом проекта. Для строительного проекта его стоит наполнить конкретикой:

1. Цель проекта и критерии успеха: что считается завершением — разрешение на ввод, передача эксплуатации, финансовое закрытие.

2. Границы проекта: что входит и что не входит (подробно — в главе 6).

3. Ключевые даты и ограничения: контрактный срок, лимиты финансирования по годам.

4. Мандат руководителя проекта: полномочия, финансовые пределы, сроки ответов головного офиса.

5. Матрица ответственности по ключевым процессам.

6. Порядок эскалации: какие вопросы, кому и в какой срок поднимаются.

7. Подписи первого лица компании и руководителя проекта.

Устав занимает три–четыре страницы, но служит главной защитой руководителя проекта. Когда через год кто-нибудь спросит, почему решение принималось так долго, ответ уже будет записан.

Метрика главы: доля решений по проекту, которые руководитель проекта принял без эскалации, и среднее время ответа головного офиса на запросы объекта. Если время ответа растёт, мандат перестал работать, даже если на бумаге он широкий.

Ход учебного проекта. Марину назначили руководителем проекта «Северного узла» приказом из двух строк: назначить и возложить ответственность за выполнение контракта. Права подписывать договоры с субподрядчиками у неё не было, а письма заказчику согласовывал юридический отдел головного офиса, до которого была тысяча километров. Первое уведомление о том, что сетевая организация не выдала точные технические условия, ушло заказчику через двадцать два дня после того, как Марина о нём узнала. Позже, в споре о неустойке, именно эти двадцать два дня станут одним из главных аргументов против генподрядчика.

Пошаговый алгоритм: как получить работающий мандат.

1. Соберите статистику согласований. Выпишите решения, которые объект за последние два–три месяца отправлял на согласование в головной офис, и сколько дней ждал ответа. Без цифр разговор о полномочиях превращается в спор о доверии.

2. Разделите решения на три группы. Решения, которые руководитель проекта может принимать сам; решения, о которых он лишь информирует головной офис; решения, которые требуют согласования. Для каждой группы нужны конкретные примеры и денежные пределы.

3. Составьте устав проекта. Включите цель и критерии успеха, границы проекта, мандат, матрицу ответственности, порядок эскалации и сроки ответа головного офиса.

4. Оформите полномочия для внешнего мира. Доверенность на подписание уведомлений, актов и договоров в пределах мандата; письмо заказчику о порядке подписания документов по объекту.

5. Договоритесь о правиле молчания. Если головной офис не ответил в установленный срок, решение руководителя проекта считается согласованным. Срок и перечень таких решений запишите в уставе.

6. Измеряйте. Раз в месяц считайте среднее время ответа головного офиса и долю решений, принятых без эскалации.

Как это сделали иначе. Андрей Волков согласился возглавить «Южный терминал» с одним условием: до выхода на площадку генеральный директор подпишет устав проекта. На трёх страницах устава было записано, что руководитель проекта сам заключает договоры с субподрядчиками до определённой суммы, перераспределяет бюджет между статьями в пределах пяти процентов, направляет заказчику уведомления о препятствиях за своей подписью по доверенности и нанимает людей на объект в пределах утверждённого штатного расписания. Отдельной строкой шло правило: если головной офис не отвечает на запрос объекта в течение трёх рабочих дней, решение руководителя проекта считается согласованным.

Первые месяцы это правило раздражало головной офис: юристам и финансистам пришлось отвечать быстрее. Но через полгода выяснилось, что большинство запросов объекта решается за один–два дня, а вопросы, которые действительно требуют внимания руководства, попадают к нему без очереди. Письмо о неточных условиях подключения к водоснабжению ушло заказчику через два дня после того, как проблему обнаружили. На «Северном узле» такое же письмо шло двадцать два дня.

Типичные ошибки.

• Назначить руководителя проекта приказом из двух строк. Без перечня полномочий он будет согласовывать всё и отвечать за всё.

• Не оформить полномочия для внешнего мира. Внутренний приказ не делает подпись руководителя проекта действительной для заказчика. Нужна доверенность и понятный заказчику порядок подписания.

• Дать два ответственных за один процесс. «Отвечают ПТО и главный инженер» означает, что не отвечает никто.

• Опираться только на формальную власть. Руководитель, который требует, но сам не выполняет обещаний, теряет неформальное влияние, и широкий мандат перестаёт работать.

• Не измерять скорость системы. Если никто не считает, сколько дней объект ждёт ответа головного офиса, проблема видна только по сорванным срокам.

Упражнение. Выпишите десять последних решений по вашему проекту, которые потребовали согласования с головным офисом или заказчиком. Для каждого отметьте, сколько дней прошло от запроса до ответа и мог ли руководитель проекта при разумном мандате принять это решение сам. Если больше половины решений можно было принять на объекте, подготовьте проект устава с перечнем полномочий и предложите его руководству.

Ситуация для разбора: ответственность без полномочий.

Нового руководителя проекта назначают на объект, который уже отстаёт от графика. В приказе сказано, что он «отвечает за реализацию проекта в установленные сроки и в пределах бюджета». Но договоры с подрядчиками подписывает коммерческий директор, платежи согласует финансовая служба, а изменения проектных решений утверждает технический директор. Через три месяца отставание выросло, и на совещании у генерального директора руководителя проекта спрашивают, почему он не принял мер.

Вопрос для разбора: что руководителю проекта нужно было сделать в первые недели?

Комментарий автора. Разрыв между ответственностью и полномочиями — не ошибка конкретного приказа, а обычное состояние многих компаний. Руководитель проекта не может устранить его в одиночку, но может сделать видимым. В первые недели нужно было составить простую таблицу: какие решения критичны для сроков, кто их принимает и как быстро. Затем показать её генеральному директору с конкретным предложением: либо передать часть полномочий, либо установить сроки согласования для служб, либо признать, что за сроки отвечает не один человек. Руководитель, который молча принимает ответственность без полномочий, заранее соглашается стать объяснением будущей неудачи.

Вопросы для ближайшего совещания.

• Какие решения руководитель проекта может принять сам, без звонка в головной офис?

• Сколько дней в среднем объект ждёт ответа на свой запрос?

• Кто подписывает уведомления заказчику, и знает ли заказчик об этом порядке?

• Есть ли процесс, за который отвечают двое, а значит — никто?

• Какие обещания команды объекта за последний месяц не были выполнены, и почему?

Главное в главе.

• Ответственность без полномочий — самая частая и самая разрушительная конфигурация. Молча принять её — значит заранее согласиться стать объяснением будущей неудачи.

• Мандат описывает права, а не обязанности. Он оформляется уставом и доверенностью, а правило молчания ускоряет всю систему.

• Неформальная власть строится из точности, предсказуемости и защиты команды.

Часть II. Точка 1. Замысел

Исходные данные, инвестиционная оценка и границы проекта: решения, после которых меняется сам объект.

Глава 4. Исходные данные решают всё

Самая дорогая ошибка в строительном проекте в момент, когда её совершают, обычно стоит копейки. Непроверенная цифра в задании на проектирование. Предварительные технические условия, принятые за окончательные. Изыскания, выполненные в другой сезон или на соседнем участке. Через два года такая копеечная ошибка оборачивается переделкой фундаментов, новой трассой сетей или полугодовым ожиданием подключения.

Что такое исходные данные. Исходными данными я называю в этой книге всё, на чём строится проектное решение и что проектировщик не создаёт сам, а получает извне. Основные группы:

• права на землю и градостроительный план земельного участка — что и в каких параметрах на нём можно строить;

• результаты инженерных изысканий — геологических, геодезических, гидрометеорологических, экологических;

• задание на проектирование — что именно заказчик хочет получить;

• технические условия и условия подключения к сетям — электроснабжение, тепло, газ, вода, канализация, связь;

• технологическое задание — требования к процессам, которые будут идти внутри объекта, и к оборудованию;

• требования будущей эксплуатирующей организации;

• особые условия — режимные, экологические, требования собственников соседних объектов и линейных сооружений.

Многие из этих элементов регулирует Градостроительный кодекс: градостроительный план участка, инженерные изыскания, подключение объектов к сетям инженерно-технического обеспечения. Только закон отвечает на вопрос, какие документы нужны. А вот достаточно ли они хороши для вашего проекта, решает руководитель.

Три ловушки исходных данных.

Предварительное вместо окончательного. Технические условия на подключение нередко выдают сначала в предварительном виде, с оговорками и без точной точки присоединения. Проектировать по ним начинают сразу, чтобы не терять время. Потом приходят окончательные условия, и в них может оказаться другая мощность, другая трасса или новая подстанция, а значит, и переделка проекта.

Чужая ответственность. Многие исходные данные зависят от организаций, которые в проект не входят: сетевых компаний, муниципалитетов, владельцев соседних коммуникаций. Их сроки графику проекта не подчиняются, и договорных рычагов влияния на них почти нет. Если в команде нет человека, который ведёт эти отношения как отдельную задачу, они «идут отдельно». Ровно до того дня, когда окажутся на критическом пути.

Отсутствующий голос. Самые важные требования к объекту часто знает тот, кого на этапе замысла ещё нет за столом: будущая эксплуатирующая организация, технологи, служба безопасности. Проект проходит экспертизу без них, потом они появляются и требуют изменений. Формально их можно не слушать. На практике без них объект работать не будет.

Как проверять исходные данные. Каждой группе исходных данных руководителю полезно задать четыре вопроса.

1. Есть ли документ? Устное подтверждение, протокол совещания или письмо «в рабочем порядке» исходными данными не считаются.

2. Окончательный ли он? Предварительные условия, условия с истекающим сроком действия, изыскания с оговорками означают риск, а не данные.

3. Кто отвечает за его выполнение? Если по техническим условиям сети должна построить другая организация, кто следит, чтобы она успела в срок?

4. Что будет, если он изменится? Какие разделы проекта, работы и поставки зависят от этих данных и сколько стоит их пересмотр?

Последний вопрос превращает список документов в карту рисков. Как правило, судьбу проекта определяют две-три позиции, остальное рутина.

Время исходных данных. У исходных данных почти всегда есть срок жизни. Технические условия действуют ограниченное время, изыскания стареют, а информацию из градостроительного плана участка можно использовать для подготовки проектной документации и получения разрешения на строительство только три года со дня его выдачи (ч. 10 ст. 57.3 ГрК РФ). На длинных проектах это вполне реальная проблема: к выходу на площадку часть документов уже приходится продлевать или получать заново. Поэтому в реестре исходных данных должны стоять сроки действия и фамилия того, кто отвечает за продление.

Инструмент главы: чек-лист полноты исходных данных.

Метрика главы: доля изменений проекта, которые вызваны изменением или неполнотой исходных данных. Если доля высокая, дело не в проектировщике, а в том, как проект готовили.

Ход учебного проекта. Электроснабжение в задании на проектирование «Северного узла» уместилось в одну строку: «по техническим условиям сетевой организации». Технические условия выдали за год до торгов, и они были предварительными. Точку присоединения в них обозначили так: «существующая подстанция либо новая, по результатам расчёта». Расчёт показал, что существующей мощности не хватит. Новую подстанцию и линию должна была строить сетевая организация по отдельному договору с заказчиком, а договор появился только через восемь месяцев после начала стройки. Документа, где связь этой линии с датой ввода объекта была бы хоть как-то записана, в проекте не было вовсе.

Пошаговый алгоритм: аудит исходных данных за две недели.

1. Составьте реестр исходных данных. Это таблица, в которой каждая строка соответствует документу: градостроительный план, технические условия, изыскания, правоустанавливающие документы на землю, задание на проектирование. Для каждого документа запишите дату выдачи, срок действия и ответственного. Пустая графа «ответственный» уже сама по себе находка.

2. Проверьте сроки. Отдельно выпишите всё, что истекает раньше планируемой даты ввода. Технические условия и градостроительный план, которые формально действуют, но закончатся посреди стройки, означают скрытый пересмотр бюджета и графика.

3. Сверьте документы между собой. Нагрузки в технических условиях должны совпадать с заданием на проектирование, границы участка в правоустанавливающих документах — с генпланом. Каждое расхождение запишите отдельной строкой и адресуйте вопрос конкретному человеку.

4. Выйдите на площадку с изысканиями в руках. Посмотрите, где на самом деле идут сети, где стоит вода, что изменилось после съёмки. Разницу между бумагой и местностью находят глазами, а не в кабинете.

5. Оцените каждую дыру в деньгах и днях. Точность до рубля не нужна, хватит порядка: «неделя и небольшие деньги» или «квартал и пересмотр концепции». После этого список замечаний становится списком решений.

6. Вынесите на решение заказчика короткий итог: что подтверждено, что требует доизысканий, что можно принять как риск с резервом. Подпись под таким итогом закрывает первую точку невозврата в части исходных данных осознанно, а не по умолчанию.

Как это сделали иначе. На «Южном терминале» Волков дал главному инженеру задачу на первые три недели: пройти по каждому документу исходных данных и ответить на четыре вопроса из этой главы. Работы оказалось меньше, чем думали, документов набралось около двадцати. Зато результат удивил. Условия подключения к водоснабжению выдали на точку, которую водоканал собирался закрыть. Инженерно-геологические изыскания по участку складов делали восемь лет назад, ещё до подсыпки территории. Технологическое задание на складское оборудование было подписано, но поставщик, под которого его писали, ушёл с рынка.

По каждому пункту заказчику ушло письмо с предложением: запросить уточнённые условия подключения, сделать контрольное бурение на участке складов до проектирования фундаментов, подтвердить технологическое задание под оборудование, которое реально можно купить. Бурение стоило немного и заняло три недели. Выяснилось, что под складами нужны сваи другой длины. Узнай об этом команда при земляных работах, проект потерял бы несколько месяцев и ещё долго спорил бы с заказчиком, кто платит за изменение.

Если вы заказчик. Исходные данные — прежде всего ваша зона. Задание на проектирование, изыскания, градостроительный план и технические условия получаете вы или ваш технический заказчик, а подрядчик отвечает за их полноту лишь в пределах, записанных в контракте. Проведите аудит исходных данных до объявления торгов, а не после. Каждая дыра, найденная до торгов, стоит изысканий или письма, а найденная после — изменения цены и срока. Срок действия технических условий и градостроительного плана сверяйте с реалистичной, а не с плановой датой ввода.

Типичные ошибки.

• Принимать документ за данные. Если технические условия есть, это ещё не значит, что они окончательные и что их можно выполнить к нужному сроку.

• Отложить проверку «до проектирования». Проектировщик работает с тем, что ему дали. При неполных исходных данных он выпустит грамотный проект для условий, которых не существует.

• Не назначить владельца внешних данных. Условия сетевых организаций, требования эксплуатации, согласования с соседями: у каждой позиции должен быть свой человек в команде, иначе всё это «идёт отдельно».

• Забыть о сроках действия. На длинном проекте часть исходных данных устаревает раньше, чем объект достраивается.

Упражнение. Составьте реестр исходных данных своего проекта по таблице из этой главы. Отметьте красным позиции, где документ предварительный, срок действия заканчивается до ввода или нет ответственного. Для каждой красной позиции запишите, какие разделы проекта и какие работы от неё зависят. Обычно после этого становится ясно, какие два-три вопроса пора поднять с заказчиком на ближайшей встрече.

Ситуация для разбора: технические условия, которые «всегда продлевали».

Во время аудита исходных данных команда видит, что технические условия на подключение к теплосетям истекают за четыре месяца до планируемого ввода. Главный инженер успокаивает: «С этой сетевой компанией мы работаем давно, продлевали всегда без проблем». Вопрос откладывают. За полгода до ввода у сетевой компании меняется руководство и порядок работы, и при продлении выдают условия с другой точкой подключения и дополнительными работами за счёт заявителя.

Вопрос для разбора: в чём была ошибка, если формально все документы действовали?

Комментарий автора. Ошибка в том, что факт подменили прошлым опытом. Хорошие отношения с сетевой компанией ценны, но это не документ и не гарантия. При аудите истекающие условия следовало внести в реестр рисков, назначить владельца и начать продление заранее, пока изменения ещё можно учесть в проекте без переделок. Урок шире этого случая: если на совещании звучит «всегда так было», это повод проверить, а не успокоиться.

Вопросы для ближайшего совещания.

• Какие исходные документы истекают раньше планируемого ввода и кто отвечает за их продление?

• Где данные изысканий не совпадают с тем, что мы видим на площадке?

• Какие нагрузки и параметры в технических условиях мы приняли на веру, не сверив с заданием?

• Что из исходных данных мы считаем подтверждённым только потому, что так было в предыдущем проекте?

• Какой резерв времени и денег заложен под доизыскания и кто вправе его расходовать?

Главное в главе.

• Ошибка в исходных данных почти ничего не стоит в момент, когда её совершают, и обходится дороже всего в момент ввода.

• Предварительное — не окончательное. У каждого документа есть срок действия, владелец и связь с другими документами.

• Фраза «всегда так было» — сигнал проверить, а не повод успокоиться.

Глава 5. Строить ли вообще: инвестиционная оценка

Почти все книги о строительных проектах начинаются с того момента, когда решение строить уже принято. Но первое и самое дорогое решение звучит иначе: строить ли вообще, что именно и в каком объёме. Проект, невыгодный на входе, хорошим управлением не спасти, можно только сократить потери. Проект с честно оценённым запасом прочности выдерживает и задержки, и удорожание.

Сам руководитель строительного проекта инвестиционное решение принимает нечасто, это дело инвестора или государства. Но понимать его логику он должен, и причин тут две. От этой логики зависит, что будут считать успехом проекта и где проходит граница допустимого перерасхода. А ещё у подрядчика есть собственное инвестиционное решение: браться ли за объект. О нём я расскажу в конце главы.

Базовые показатели. Методы оценки инвестиционных проектов давно стандартизированы. В России на них опираются Методические рекомендации по оценке эффективности инвестиционных проектов, утверждённые Минэкономики, Минфином и Госстроем России в 1999 году. Основных показателей четыре.

• Чистая приведённая стоимость (NPV) — сумма всех будущих денежных потоков проекта, приведённых к сегодняшнему дню по ставке дисконтирования, за вычетом инвестиций. Если NPV положительная, проект создаёт ценность сверх требуемой доходности.

• Внутренняя норма доходности (IRR) — ставка, при которой NPV равна нулю. Её сравнивают со стоимостью капитала.

• Срок окупаемости — когда накопленные поступления покроют вложения. Простой срок не учитывает стоимость денег во времени, дисконтированный — учитывает.

• Индекс доходности — отношение приведённых поступлений к приведённым инвестициям.

Для государственных объектов без прямой выручки вместо денежных поступлений оценивают общественные эффекты: экономию на транспорте, рост деловой активности, безопасность. Логика расчёта та же, сложнее только измерить сами эффекты.

Почему одной цифры мало. Расчёт NPV по одному, «базовому» сценарию почти всегда получается оптимистичным, и причины этого мы разобрали в главе 1. Поэтому решение проверяют на устойчивость: что станет с проектом, если строительство обойдётся дороже, а срок окажется длиннее.

Возьмём упрощённый учебный пример. Объект требует инвестиций 1 млрд рублей и после ввода в течение 15 лет приносит 160 млн рублей чистого денежного потока в год. Ставка дисконтирования 12 %.

В базовом сценарии проект выгоден. Однако хватает всего года задержки, чтобы он стал убыточным, а сочетание задержки с удорожанием, обычное для крупных проектов, оборачивается серьёзными потерями. Запас прочности у проекта меньше года и меньше десяти процентов стоимости. Главный результат анализа именно в этом, а не в цифре +90.

Взгляд снаружи. Как выбрать реалистичные сценарии удорожания и задержки? Канеман и Тверски предложили для таких случаев «взгляд снаружи», а Фливбьорг превратил его в метод прогнозирования крупных проектов по референтному классу. Вместо того чтобы строить прогноз изнутри проекта, берут распределение фактических результатов похожих завершённых проектов и спрашивают, где в нём окажется наш. Если похожие объекты обычно превышали бюджет на треть, закладывать в базовый сценарий ноль значит обманывать себя.

Для российской компании референтный класс складывается из её собственных завершённых объектов и тех объектов конкурентов, о которых что-то известно. Даже простая таблица «плановые срок и стоимость против фактических» по десяти прошлым проектам даёт больше, чем самый подробный расчёт без неё.

Инвестиционное решение подрядчика. Для генподрядчика вопрос «строить ли» звучит как «браться ли за объект». И это тоже инвестиционное решение: компания вкладывает оборотный капитал, гарантии, людей и репутацию. Оценивать его стоит по тем же принципам:

• какова ожидаемая маржа в базовом и пессимистичном сценариях (подробно — в главе 9);

• сколько оборотных средств проект потребует в пике и во что обойдётся их финансирование (глава 17);

• какие люди нужны и кого компания снимет с других объектов;

• что даёт объект стратегически: опыт, отношения с заказчиком, вход в новый регион или отрасль.

Последний пункт иногда оправдывает проект с низкой маржой. Но такое решение руководство должно принимать осознанно и с понятной ценой, а не придумывать задним числом, чтобы объяснить участие в торгах.

Инструмент главы: сценарный анализ проекта. Для каждого проекта посчитайте не одну цифру, а четыре: базовый сценарий, задержку ввода на типичную для референтного класса величину, удорожание на типичную величину и их сочетание. Если во всех четырёх случаях проект остаётся приемлемым, запас прочности у него есть. Если нет, решение принимают с открытыми глазами, зная, сколько можно потерять и при каких условиях.

Метрика главы: запас по NPV (у подрядчика — по марже) в пессимистичном сценарии. Отрицательный запас ещё не повод отказаться от проекта, но всегда повод для явного решения руководства.

Ход учебного проекта. «Северный узел» строился на государственные средства, и инвестиционное обоснование подготовили задолго до торгов. Объект в нём выглядел как одно здание с котельной. Сети, дорога и подстанция проходили отдельными мероприятиями других программ. Поэтому по официальным документам проект получался дешёвым и быстрым. Генподрядчик со своей стороны сценарного анализа не делал. Решение участвовать в торгах приняли за неделю, потому что «нужен объём на следующий год».

Пошаговый алгоритм: инвестиционная оценка, которой можно доверять.

1. Запишите вопрос, на который отвечает оценка. «Строить или нет», «строить сейчас или через год», «какой из двух вариантов выбрать» — три разных расчёта. Оценка без явного вопроса незаметно превращается в обоснование уже принятого решения.

2. Отделите допущения от фактов. Вынесите на отдельный лист все допущения модели: цены, ставку, сроки, темпы продаж или загрузки. У каждого допущения должен быть автор и источник. Допущение без автора ничьё, и его никто не пересматривает.

3. Посчитайте базовый вариант и два стрессовых. Сдвиньте срок, поднимите стоимость, снизьте доход, сначала по отдельности, потом вместе. Найдите сочетание, при котором проект перестаёт окупаться. Эта граница важнее базового результата.

4. Найдите допущения, к которым модель чувствительнее всего. Обычно их два-три. На них и стоит тратить время экспертов, за ними и нужно следить после старта.

5. Сверьте модель с бюджетом и графиком проекта. Частая история: инвестиционная модель живёт отдельно от сметы и календарного плана, и через полгода их цифры уже расходятся.

6. Запишите пороги пересмотра. Заранее зафиксируйте: если допущение X выйдет за значение Y, решение пересматривается. Без такого порога любое отклонение будут называть временным.

Как это сделали иначе. В компании, где работал Андрей Волков, действовало правило: решение об участии в крупных торгах принимают только после сценарного анализа на одной странице. Экономист берёт данные по пяти–семи завершённым объектам компании похожего масштаба, считает средние и худшие отклонения по срокам и стоимости и прогоняет новый объект через четыре сценария. С этим результатом идут на совет директоров и задают один вопрос: готовы ли мы к худшему сценарию и что будем делать, если он случится.

Для «Южного терминала» анализ показал: при обычной для компании задержке на пять месяцев и удорожании на 12 % объект остаётся безубыточным, хотя маржа почти исчезает. Совет одобрил участие с двумя условиями. На торгах не снижать цену больше чем на 3 %, а сразу после победы законтрактовать металлоконструкции по фиксированной цене. Через год металл подорожал, и плановую маржу объекту сохранило именно это решение.

Если вы заказчик. Сценарный анализ нужен вам даже больше, чем подрядчику: от него зависит, какой резерв закладывать в бюджет и при каком удорожании проект пора пересматривать. Попросите проектный офис или технического заказчика собрать референтный класс по вашим собственным объектам. Если прошлые объекты в среднем выходили за бюджет и срок, а в новом обосновании этого нет, расчёт стоит вернуть на доработку до решения, а не после торгов.

Как это делают в мире. Норвегия с 2000 года проверяет крупные государственные проекты внешней экспертизой до решения о финансировании. Сейчас порог — 1 млрд норвежских крон, для цифровых проектов 300 млн. Проверок две. Первая, QA1, оценивает выбор концепции, то есть строить ли вообще и что именно. Вторая, QA2, проверяет управленческую базу и оценку стоимости перед тем, как проект уйдёт в парламент за финансированием. Проверки ведут внешние консультанты по рамочным договорам с Министерством финансов, а опыт системы изучает исследовательская программа Concept при Норвежском университете естественных и технических наук. Что применимо у нас: смысл норвежской системы в том, что концепцию и резервы проверяет тот, кто их не готовил, и до решения о деньгах. Внутри компании или у заказчика такую проверку можно ввести без изменения законов: независимый сценарный анализ до решения об инвестициях или участии в торгах.

Типичные ошибки.

• Считать NPV один раз. Оценка по одному сценарию создаёт иллюзию точности. Ценность анализа в том, как меняется результат при реалистичных отклонениях.

• Брать сценарии из головы. «Пессимистичный сценарий — минус 10 %» без опоры на прошлые проекты — всё та же ошибка планирования, только с другим числом.

• Не считать стоимость денег. Длинный проект с поздними поступлениями может приносить прибыль в рублях и оказаться убыточным, если учесть стоимость оборотного капитала.

• Путать стратегическое решение с оправданием. «Проект важен стратегически» — законный аргумент, если он прозвучал до торгов и с понятной ценой. После торгов это обычно объяснение ошибки.

Упражнение. Откройте финансовую модель своего проекта или последнего проекта, который вы оценивали. Ухудшайте по одному допущению на 10 %: стоимость, срок, доход, ставку. Записывайте, насколько меняется результат, и расставьте допущения по силе влияния. Потом выясните, кто в компании отвечает за три верхних и когда их последний раз сверяли с фактом.

Ситуация для разбора: модель, которая всегда сходится.

Инвестиционный комитет рассматривает проект бизнес-центра. Финансовая модель показывает хорошую доходность. На вопрос о чувствительности аналитик отвечает, что даже при росте стоимости строительства на десятую часть проект окупается. Комитет одобряет. Позже выясняется, что модель предполагала заполнение площадей с первого месяца после ввода, а срок строительства взяли из коммерческого предложения подрядчика без всякого запаса. Стоимость выросла меньше, чем проверяли, зато сдача задержалась на полгода, а заполнение растянулось ещё на год, и проект ушёл в минус.

Вопрос для разбора: почему стресс-тест не защитил от ошибки?

Комментарий автора. Проверили не то допущение. Стоимость строительства бросается в глаза, но далеко не всегда сильнее всего влияет на результат. В коммерческой недвижимости часто важнее сроки и темп заполнения: они сдвигают весь денежный поток. Хорошая оценка начинается с вопроса, к чему модель чувствительнее всего, и уже потом проверяет именно это. Второй урок касается источника допущения. Срок из коммерческого предложения подрядчика — это его обещание в момент продажи, а не реалистичный прогноз.

Вопросы для ближайшего совещания.

• На какой вопрос отвечает наша инвестиционная оценка и кто его сформулировал?

• Какие три допущения сильнее всего двигают результат и кто за каждое отвечает?

• При каком сочетании задержки и удорожания проект перестаёт окупаться?

• Совпадают ли сегодня цифры модели с актуальной сметой и графиком?

• Какой порог отклонения автоматически запускает пересмотр решения?

Главное в главе.

• Оценка отвечает на конкретный вопрос. Одна цифра без сценариев не оценка, а надежда.

• Взгляд снаружи, то есть фактические отклонения похожих проектов, честнее любой внутренней уверенности.

• Найдите допущения, к которым модель чувствительнее всего, и заранее запишите, при каком значении решение пересматривается.

Глава 6. Границы проекта

Любой строительный объект похож на остров, к которому должны вести мосты. Здание можно построить идеально, но без электричества, тепла, воды, дороги и людей, которые будут его эксплуатировать, получится не объект, а памятник. Мосты почти никогда не входят в контракт на остров. Они «идут отдельно», «решаются заказчиком», «предусмотрены другой программой». И как раз от них чаще всего зависит, когда объект на самом деле заработает.

Содержание проекта и его границы. В теории управления проектами есть понятие содержания проекта, то есть всего объёма работ, нужного для получения результата. Стандартный инструмент для его описания — иерархическая структура работ (ИСР, в англоязычной литературе WBS). Результат проекта шаг за шагом делят на всё более мелкие части: объект, здания и сооружения, системы, конструктивные элементы, пакеты работ. Делят до уровня, на котором каждую часть можно оценить, поручить одному ответственному и проверить. Практический стандарт PMI по иерархической структуре работ формулирует для неё правило 100 %: структура охватывает всё содержание проекта, и только его. Поэтому граница проекта определяется раньше структуры. Прежде чем раскладывать содержание по уровням, нужно ответить на вопрос попроще: где проходит граница проекта? Что мы делаем сами, что делают другие и чего не делает никто.

Последняя категория опаснее всего. Работы, за которые никто не отвечает, никуда не исчезают. Они всплывают в конце, когда без них объект не ввести, и тогда их делают в спешке, за чужой счёт и с сорванными сроками.

Что обычно оказывается за границей. На крупных объектах повторяется один и тот же набор «забытых» элементов:

• внешние сети и подключения: линии электропередачи, подстанции, магистральные трубопроводы, точки присоединения;

• подъездные дороги и внешний транспорт для доставки крупного оборудования;

• вынос и переустройство существующих коммуникаций, попадающих в пятно застройки;

• временные здания и сооружения на весь срок стройки, включая их содержание и демонтаж;

• технологическое оборудование, мебель и оснащение, без которых объект нельзя эксплуатировать;

• комплексные испытания и пусконаладка с участием эксплуатирующей организации;

• обучение персонала эксплуатации и передача документации;

• получение разрешений и согласований за пределами строительного контракта.

Каждый пункт из этого списка может стоить меньше процента бюджета и при этом остановить ввод на месяцы.

Интерфейсы. Граница проекта не стена, а линия соприкосновения с другими проектами и организациями. Каждое такое соприкосновение называют интерфейсом: в этом месте результат одной стороны становится исходными данными для другой. Сетевая организация тянет линию до границы участка, генподрядчик — от границы до здания. Поставщик привозит котёл, монтажник устанавливает, эксплуатация принимает. Для каждого интерфейса должно быть определено, что передаётся, в каком виде, в какой срок и кто проверяет.

Опасны интерфейсы ещё и тем, что их сроков не видно в графике ни одной из сторон. У сетевой организации свой план, у генподрядчика свой. Связь между ними существует только в голове руководителя проекта, и то если он о ней знает.

Реестр интерфейсов. Простой и сильный инструмент: перечень всех точек соприкосновения проекта с внешним миром, где указаны стороны, предмет передачи, срок и статус. Пересматривать его достаточно раз в месяц. Но каждая позиция, у которой срок близко, а статус неясен, должна обсуждаться на уровне руководителя проекта, а если нужно, то и заказчика.

Кто должен отвечать за то, что вне контракта. Генподрядчик не обязан строить то, что не входит в его контракт. Но он кровно заинтересован, чтобы это построили вовремя, иначе он не сдаст объект и будет платить за ожидание, а иногда и неустойку. Позиция «это не наша зона» безопасна юридически, но убыточна экономически. Правильнее сказать так: «это не наша зона работ, но наша зона внимания». Генподрядчик отслеживает внешние интерфейсы, вовремя и письменно предупреждает заказчика о рисках и фиксирует, как задержка смежников сдвигает его собственные сроки. Это одновременно и управление, и защита.

Инструмент главы: карта границ проекта.

Любая отметка в колонке «ни у кого» означает немедленный письменный вопрос заказчику.

Метрика главы: число работ за границами проекта, выявленных уже после начала строительства, и их общая стоимость. На хорошо подготовленном проекте эта цифра стремится к нулю.

Ход учебного проекта. Карта границ «Северного узла», составленная задним числом, показала бы три отметки в колонке «ни у кого»: комплексные испытания котельной с участием эксплуатации, обучение персонала и вынос старого кабеля связи под будущим складом. Кабель нашли при земляных работах на втором месяце. Выносили его шесть недель, согласовывая с владельцем, о котором никто из участников проекта даже не подозревал. Эти шесть недель стали первым отставанием на критическом пути.

Пошаговый алгоритм: как зафиксировать границы проекта.

1. Опишите результат, а не работы. Одной фразой: что будет у заказчика в день ввода и по каким признакам он поймёт, что получил именно это. Пока результат описан списком работ, границы будут расползаться вместе с этим списком.

2. Составьте перечень «входит / не входит». Вторая колонка важнее первой. Наружные сети, благоустройство за забором, мебель, пусконаладка технологического оборудования, обучение персонала: всё, что обычно считается «само собой разумеющимся», нужно назвать прямо.

3. Нарисуйте физические границы на плане. Линия раздела ответственности на схеме снимает больше споров, чем страница текста. Отдельно отметьте точки подключения и кто отвечает за участок от точки до объекта.

4. Проверьте границы на стыках с другими проектами. Если рядом строится соседний объект, дорога или сеть, запишите, кто делает общий участок, в какой последовательности и кто платит за переделку, если один из проектов опоздает.

5. Договоритесь о процедуре изменения границ. Кто вправе предложить изменение, кто оценивает его в деньгах и днях, кто подписывает. Без такой процедуры любое «добавьте ещё вот это» становится устной договорённостью без цены.

6. Утвердите документ у спонсора и раздайте его всем ключевым участникам. Границы, о которых знает один руководитель проекта, не работают. Подрядчик и служба эксплуатации должны видеть ту же линию.

Как это сделали иначе. На «Южном терминале» карту границ составили на второй неделе, и в колонку «ни у кого» попали пять позиций. Самой неожиданной оказалась подъездная дорога. Проект предусматривал только внутриплощадочные проезды. Заказчик рассчитывал, что муниципалитет отремонтирует существующую дорогу к участку, а муниципалитет об этом даже не знал. Провезти по этой дороге тяжёлое оборудование было нельзя.

Волков не стал спорить, чья это зона. Он написал для заказчика короткую записку: что не входит ни в один договор, чем это грозит дате ввода и какие есть варианты. Можно включить ремонт дороги в контракт дополнительным соглашением, можно договориться с муниципалитетом, можно проложить временный подъезд. Заказчик выбрал первый вариант. Решение заняло два месяца, но его приняли за год до того, как по дороге понадобилось везти оборудование. В реестре интерфейсов «Южного терминала» в итоге набралась тридцать одна позиция, и раз в месяц его пересматривали на совещании с заказчиком.

Если вы заказчик. Позиции из колонки «ни у кого» в итоге становятся вашими: объект не введут, а взыскать с кого-то неустойку за чужую задержку удаётся не всегда. Сведите в один реестр все договоры, без которых не будет ввода, а не только строительный контракт: техприсоединение, вынос сетей, дорогу, оборудование, эксплуатацию. Назначьте у себя владельца каждого договора и поставьте их сроки в общий график проекта, который видит и генподрядчик.

Типичные ошибки.

• Описывать границу только тем, что входит в контракт. Важнее то, что нужно объекту для работы и при этом не входит ни в один контракт.

• Успокоиться фразой «это решает заказчик». Юридически всё верно. Но если заказчик не решит вовремя, сдать объект не сможет генподрядчик.

• Не вносить интерфейсы в график. Срок готовности внешней сети записан в чужом плане, а в вашем графике он должен стоять как ограничение.

• Обнаружить временные решения в конце. У временного подъезда, временной котельной, временного электроснабжения должна быть дата замены постоянными.

Упражнение. Заполните карту границ своего проекта по таблице из этой главы. Для каждого элемента, где граница проходит между вами и другой организацией, запишите, что именно передаётся, в какой срок и кто проверяет готовность. Если хотя бы одна позиция оказалась в колонке «ни у кого», в течение недели отправьте заказчику письменный запрос.

Ситуация для разбора: «а благоустройство разве не ваше?»

За два месяца до ввода жилого комплекса заказчик сообщает генподрядчику, что ждёт от него благоустройства прилегающей территории: детской площадки, озеленения, освещения дорожек. Генподрядчик возражает, в договоре этого нет. Заказчик ссылается на проект, где благоустройство нарисовано на генплане, и на общую формулировку договора о «полном комплексе работ для ввода объекта в эксплуатацию». Стороны не могут договориться, работы не начаты, и ввод под угрозой.

Вопрос для разбора: где в начале проекта была упущена возможность избежать этого спора?

Комментарий автора. Спор вырос из пустой колонки «не входит». Генплан показывал благоустройство, договор описывал объём общими словами, и каждая сторона прочла неопределённость в свою пользу. Будь на старте составлен перечень «входит / не входит», где благоустройство названо прямо, а граница нарисована на плане, спора бы не было. Была бы либо цена в договоре, либо отдельная задача заказчика с собственным сроком. Теперь решение уже не юридическое, а управленческое: быстро договориться, кто делает и как это оплачивается, а выяснять, кто был прав, потом. Ввод не будет ждать, пока стороны разберутся с толкованием договора.

Вопросы для ближайшего совещания.

• Что именно не входит в наш проект и знает ли об этом заказчик?

• Где на плане проходит линия ответственности по каждой инженерной сети?

• Какие работы мы выполняем «по умолчанию», хотя они нигде не записаны?

• Кто последним добавил что-то в объём проекта и была ли у этого добавления цена?

• Какой соседний проект может сдвинуть наши сроки и как мы об этом узнаем?

Главное в главе.

• Границу проекта определяет то, что в него не входит. Колонка «не входит» важнее колонки «входит».

• Главные риски живут на стыках. У каждого элемента должен быть владелец, а на позицию «ни у кого» нужно в течение недели ответить письмом.

• Границы меняют только по процедуре, с ценой и сроком. Иначе любое изменение становится бесплатной уступкой.

Часть III. Точка 2. Модель

Кто участвует в проекте и как между участниками распределены риски и ответственность.

Глава 7. Заинтересованные стороны строительного проекта

На совещаниях по крупному строительному проекту обычно сидят заказчик, генподрядчик, проектировщик и строительный контроль. Но судьбу объекта решают не только они. Инспектор строительного надзора, который придёт на итоговую проверку. Начальник сетевого района, от которого зависит подключение. Главный инженер будущей эксплуатирующей организации. Глава местной администрации, по чьей земле идёт подъездная дорога. Никого из них за столом нет, а без их решений объект не введут.

Кто такие заинтересованные стороны. В проектном управлении заинтересованной стороной считают любого человека или организацию, которые влияют на проект или на которых влияет проект. Определение широкое, и в этом его смысл: оно заставляет искать тех, о ком легко забыть. Стандарты проектного управления выделяют работу с заинтересованными сторонами особо. В шестом издании PMBOK это отдельная область знаний, в седьмом и восьмом — отдельная область результативности, в программах MBA — отдельная дисциплина. На строительном проекте она особенно важна: сторон много, и у многих есть право вето.

Круг сторон строительного проекта. Их удобно разделить на четыре кольца.

Внутреннее кольцо — участники контракта: заказчик, технический заказчик, генподрядчик, субподрядчики, проектировщик, строительный контроль. Отношения с ними регулируются договорами.

Кольцо разрешений — органы, без решений которых проект не сдвинется с места: экспертиза, государственный строительный надзор, органы, выдающие разрешения на строительство и ввод, надзор в сфере пожарной, промышленной и экологической безопасности, если объект ему подлежит.

Кольцо ресурсов — организации, от которых зависят подключения и инфраструктура: сетевые компании, ресурсоснабжающие организации, владельцы дорог и коммуникаций, поставщики уникального оборудования.

Внешнее кольцо — те, на кого проект влияет: будущая эксплуатирующая организация и пользователи объекта, местные власти, жители, общественные организации, средства массовой информации.

Договорные рычаги действуют только во внутреннем кольце. В остальных нужны другие инструменты: раннее вовлечение, понимание интересов, официальная переписка, а иногда и поддержка заказчика или органов власти.

Матрица влияния и интереса. Классический инструмент анализа заинтересованных сторон — матрица, которую связывают с работой А. Мендлоу 1981 года. Стороны располагают по двум осям: насколько сильно они могут повлиять на проект и насколько им интересен его результат. Получаются четыре группы:

• сильное влияние и высокий интерес — управлять вплотную: вовлекать в решения и регулярно встречаться;

• сильное влияние и низкий интерес — удовлетворять: давать им нужное без лишней нагрузки и следить, чтобы интерес не перерос в противодействие;

• слабое влияние и высокий интерес — информировать;

• слабое влияние и низкий интерес — наблюдать.

Главная ловушка на строительном проекте — вторая группа. Надзорные органы, сетевые компании, эксплуатирующая организация на ранней стадии проектом почти не интересуются. Но к концу их влияние становится решающим. Если с ними не работали заранее, их интерес впервые просыпается как раз тогда, когда что-то менять уже дорого.

Уровень вовлечённости. Полезно оценивать не только позицию стороны, но и то, насколько она вовлечена: не знает о проекте, сопротивляется, нейтральна, поддерживает, ведёт. Для каждой ключевой стороны определяют нынешний и нужный уровень и разрыв между ними. Скажем, эксплуатирующую организацию нужно перевести из «не знает» в «поддерживает» до утверждения проектных решений по инженерным системам, а не после их монтажа.

Как работать с теми, кому вы не можете приказать.

1. Найти конкретного человека. Решения принимает не организация, а люди. Не «сетевая компания», а начальник отдела технологического присоединения, с телефоном и почтой.

2. Понять его интерес. Инспектору нужно, чтобы объект был безопасен и его самого не наказали за пропущенное нарушение. Эксплуатации — оборудование, которое она умеет обслуживать. Сетевой компании — выполнить свою инвестиционную программу и не получить штраф.

3. Вовлечь рано. Показать проект, пригласить на объект, спросить мнение, пока решение ещё не принято. Тот, с кем посоветовались, сопротивляется реже.

4. Фиксировать письменно. Устные договорённости с внешними сторонами не переживают смену людей. Позиции, замечания и обязательства должны оставаться в письмах и протоколах.

5. Опираться на заказчика. Многие внешние стороны охотнее отвечают государственному заказчику, чем подрядчику. Это нормально: генподрядчик готовит вопрос, а поднимает его заказчик.

Инструмент главы: карта заинтересованных сторон. Ниже пример: пять сторон из карты «Южного терминала», составленной в первый месяц.

Карту составляют в первый месяц проекта и пересматривают раз в квартал. Особое внимание уделяют сторонам с сильным влиянием и низким интересом.

Метрика главы: число согласований и решений внешних сторон, полученных позже, чем это было нужно проекту. Каждое такое опоздание говорит о том, что с этой стороной начали работать слишком поздно или не тем способом.

Ход учебного проекта. Эксплуатирующую организацию «Северного узла» заказчик определил только на третьем году стройки. До этого никто не знал, кто будет обслуживать котельную, и поэтому никто её и не спрашивал. Главный инженер эксплуатации, впервые увидев проект, задал один вопрос: почему автоматика котельной другой системы, не той, на которой работают все остальные их объекты? Вопрос был разумным. Ответ на него обошёлся проекту в четыре месяца и замену уже смонтированного оборудования.

Пошаговый алгоритм: карта заинтересованных сторон за один рабочий день.

1. Выпишите всех, кто может остановить, ускорить или удорожить проект. Не только заказчика и подрядчиков, но и надзорные органы, сетевые компании, соседей, местную администрацию, будущую службу эксплуатации. Обычно список выходит вдвое длиннее, чем ожидали.

2. Для каждой стороны запишите одной фразой её интерес. Не «поддерживает проект», а что ей конкретно нужно: сроки, отсутствие жалоб, загрузка мощностей, отчётность перед вышестоящими.

3. Оцените влияние и интерес. Разместите стороны на матрице «влияние × интерес». Отдельно отметьте тех, у кого влияние высокое, а интерес пока низкий: они проснутся в самый неудобный момент.

4. Назначьте владельца отношений. У каждой значимой стороны в команде должен быть один человек, который знает её представителей по имени и отвечает за контакт. Без владельца отношения складываются как придётся.

5. Определите формат и частоту контакта. Кому-то нужна ежемесячная встреча, кому-то предупреждение перед шумными работами, кому-то официальное письмо. Запишите это в план коммуникаций.

6. Пересматривайте карту в каждой точке невозврата. Стороны меняются: на этапе проектирования главный — эксперт, на этапе ввода — надзор и эксплуатация. Карта, составленная однажды, через полгода показывает уже прошлое.

Как это сделали иначе. Эксплуатирующую организацию «Южного терминала» на старте тоже не определили. Но Волков внёс её в карту как сторону с сильным влиянием и низким интересом и поставил задачу найти её до утверждения рабочей документации по инженерным системам. Заказчик не знал, кому передаст объект. Тогда Волков предложил промежуточное решение: пригласить на технические совещания специалистов организации, которая обслуживала похожий терминал заказчика в соседнем регионе.

Два их инженера провели на объекте один день и оставили список из двенадцати замечаний. Большинство были мелкими, но три оказались существенными. Узел учёта тепла был такого типа, которого не было у них в сервисе. На кровле не предусмотрели площадку для обслуживания вентиляционных установок. Система диспетчеризации не стыковалась с их программным обеспечением. Все три замечания исправили в рабочей документации ещё до заказа оборудования, и обошлось это недорого. На «Северном узле» такой же вопрос возник уже после монтажа.

Если вы заказчик. Многие стороны из внешних колец охотнее говорят с вами, чем с подрядчиком: у вас статус, бюджет и официальные каналы. Это не повод брать всю работу на себя. Распределите стороны: где ведёте вы, а где подрядчик готовит вопрос, а вы его поднимаете. И определите эксплуатирующую организацию как можно раньше. Каждый месяц, прожитый проектом без неё, потом возвращается переделками.

Типичные ошибки.

• Считать заинтересованными сторонами только участников договоров. Самые опасные для проекта стороны часто не подписывают с ним никаких документов.

• Работать с организацией, а не с человеком. Письмо «в сетевую компанию» без конкретного адресата нередко остаётся без ответа.

• Вовлекать, когда понадобилась подпись. Сторона, которую впервые зовут согласовать готовое решение, ищет в нём недостатки. Сторона, которую спросили заранее, становится соавтором.

• Не фиксировать договорённости. Устное согласие представителя внешней организации не переживёт его отпуска или увольнения.

Упражнение. Составьте список всех организаций и людей, без решения которых ваш объект не введут в эксплуатацию. Разместите их в матрице влияния и интереса. Для каждой стороны с сильным влиянием и низким интересом запишите имя контактного лица, что ей нужно от проекта и одно действие, которое в ближайший месяц вовлечёт её в работу.

Ситуация для разбора: жители, о которых забыли.

Рядом с жилым кварталом начинается строительство многоэтажного паркинга. Команда проекта согласовала всё с администрацией и надзорными органами, а с жителями не общалась: «разрешение есть, остальное нас не касается». Через месяц после начала свайных работ пошли жалобы на шум и вибрацию, затем обращения в контролирующие органы, проверки, публикации в местных СМИ. Работы несколько раз останавливают на время проверок, а администрация, которая раньше поддерживала проект, просит «снизить напряжённость».

Вопрос для разбора: какую ошибку допустила команда при составлении карты заинтересованных сторон?

Комментарий автора. У жителей был низкий интерес и высокое потенциальное влияние, то есть ровно тот тип стороны, который просыпается в самый неудобный момент. Карта, составленная только по формальным согласованиям, не видит тех, кто может остановить проект неформально. На старте простые меры стоили бы немного: встреча с инициативной группой, график шумных работ, телефон для обращений, информационный стенд. Шума они бы не отменили, но изменили бы отношение к стройке. Люди чаще жалуются не на неудобства, а на то, что их не предупредили и не выслушали. После публикаций в СМИ те же меры стоят дороже и работают хуже.

Вопросы для ближайшего совещания.

• Кто может остановить проект завтра и когда мы последний раз с ним разговаривали?

• У какой стороны высокое влияние, но пока низкий интерес к нам?

• Есть ли у каждой значимой стороны свой владелец отношений в команде?

• Чьи ожидания мы не проверяли с начала проекта?

• Кто станет главным на следующем этапе и готовы ли мы к встрече с ним?

Главное в главе.

• Заинтересованная сторона — любой, кто может остановить, ускорить или удорожить проект, даже без формальных полномочий.

• Опаснее всего стороны с высоким влиянием и пока низким интересом: они просыпаются в самый неудобный момент.

• У каждой значимой стороны есть владелец отношений, а карта пересматривается в каждой точке невозврата.