Проектная команда из партнёров: как вендору собрать команду

Вендор выиграл проект. Оборудование на складе. Дальше — привязка, монтаж, пусконаладка, сдача. Ни одного из этих ресурсов в штате нет. Есть партнёрская сеть: проектные бюро, монтажные организации, пусконаладочные бригады. У каждого свои объекты, приоритеты и уровень компетенций Задача PM — собрать из этих элементов рабочую команду за одну-две недели. Ниже — алгоритм, который сокращает хаос до управляемого процесса. 1. Разложить проект на блоки работ До поиска исполнителей проект разбивается на логические блоки: проектирование привязки, поставка вспомогательных материалов, СМР, ПНР, подготовка исполнительной документации, сдача заказчику. Каждый блок фиксируется в таблице: требуемая компетенция, сроки, критерии приёмки. Частая ошибка — отдать всё одному «универсальному» партнёру. Обычно он силён в двух блоках из пяти, а остальные тянет по остаточному принципу. Результат — провал сроков именно там, где контроль ослаблен. 2. Оценить партнёров под конкретный объект Не каждый партнёр из реестра годится. Оценка идёт по двум параметрам: опыт на аналогичных объектах и текущая загрузка. Опыт — тип объектов, масштаб, допуски СРО. Загрузка — количество объектов в работе прямо сейчас. Если три и больше, партнёр выделит наименее опытных людей или начнёт сдвигать сроки в пользу собственных заказчиков. Формат проверки: звонок руководителю проекта партнёра на десять минут. Три вопроса: аналогичный опыт, свободные бригады, готовность к дедлайну. 3. Разграничить ответственность через RACI Главный риск «виртуальной» команды — размытые границы. Кто принимает решение о замене материала? Кто согласовывает отклонение от проекта? Без ответа на эти вопросы начинаются звонки по кругу. Матрица RACI закрывает проблему за полчаса. Монтажная организация — исполнитель (R). PM вендора — подотчётный, принимает результат (A). Проектировщик и инженер по продукту — консультируемые (C). Конечный заказчик и технадзор — информируемые (I). Без этого разграничения даже мелкий вопрос эскалируется до уровня совещания. 4. Создать минимальный информационный контур Объединять партнёров в одну корпоративную систему бессмысленно — у каждого своя. Достаточно трёх элементов: общая папка с актуальной документацией, общий чат проекта (не личная переписка), еженедельная летучка на тридцать минут. Жёсткое правило: протоколы решений — только письменно. Устные договорённости на объекте обнуляются после следующей смены. Если задачи нет в общем реестре — ею никто не занимается. 5. Контролировать качество промежуточными приёмками Вендор обязан проверять монтаж своего оборудования. Иначе гарантийные рекламации ложатся на производителя, а монтажник, допустивший ошибку, уже работает на другом объекте. Приёмка проводится после каждого логического блока: обвязка, подключение автоматики, пусконаладка. Чек-лист — от вендора, не от подрядчика. Подрядчик не может оценить качество собственных работ объективно. Скрытые работы фиксируются фото до закрытия конструкций. Дополнительный риск на этом этапе: партнёр, получивший доступ к конечному заказчику, в следующий раз может предложить услуги напрямую. Защита — договорная (NDA, non-solicitation) и ценностная: через вендора партнёр получает проекты, которые сам бы не нашёл. «Виртуальная» команда работает, когда PM выстраивает не иерархию, а систему прозрачных правил. Партнёры — союзники с собственными интересами. Управлять через приказы невозможно, через понятные правила — вполне. О практических инструментах контроля задач на объекте — в материале про адаптацию Канбан для монтажных проектов. О том, как быстро оценить подрядчика до подписания договора, — в чек-листе технического аудита. Как вы организуете работу с подрядчиками на объектах? Есть единый контур или каждый проект — с чистого листа? #HVAC #ProjectManagement #Инжиниринг #УправлениеПроектами #Сетка