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

Мой подход к ситуации срыва сроков подрядчиком

Как Project Manager с более чем 10-летним опытом, я сталкивался с подобными ситуациями неоднократно. Мои действия всегда носят системный характер и направлены не на поиск виноватых, а на минимизацию рисков и восстановление контроля над проектом. Вот пошаговый алгоритм, который я применяю:

1. Немедленный анализ ситуации (Root Cause Analysis)

Первым делом я провожу срочную встречу с подрядчиком, но не в формате «разбора полетов», а как совместный рабочий сеанс. Цель — понять истинные причины срыва. Они редко бывают очевидными. Я использую метод «5 почему» (5 Whys).

# Пример анализа для задержки модуля интеграции:
1. Почему модуль не сдан? → Не пройдены acceptance-тесты.
2. Почему тесты не пройдены? → Обнаружены критические баги в API.
3. Почему появились баги? → Спецификация API менялась в процессе работы.
4. Почему изменения не были согласованы? → Не было formal change request.
5. Почему не было запроса? → Отсутствовала четкая процедура коммуникации между нашей и их командами.

Вывод: Проблема не в компетенции, а в процессах коммуникации и управления изменениями.

2. Пересмотр и реабилитация плана (Re-planning)

На основе анализа я пересматриваю базовый план проекта (baseline) вместе с командой и заказчиком. Мы оцениваем:

• Критичность задержки для общего графика.
• Возможности сокращения объема работ (de-scoping) без ущерба для MVP.
• Варианты перераспределения ресурсов (например, усиление их команды нашими специалистами).
• Возможность параллелизации задач (fast-tracking) или ускорения за счет дополнительных затрат (crashing).

Результат оформляется в виде скорректированного календарного плана и, если необходимо, запроса на изменение (Change Request).

3. Усиление контроля и коммуникации

Я ужесточаю режим мониторинга, но делаю это прозрачно и коллаборативно:

• Укороченные daily stand-up с командой подрядчика (15 минут в день).
• Демо-сессии раз в 2-3 дня, а не раз в неделю/спринт, чтобы видеть прогресс в реальном времени.
• Внедрение или усиление Definition of Ready (DoR) и Definition of Done (DoD) для каждой задачи.
• Все договоренности фиксируются письменно (в минутках встреч или в Jira/Confluence).

4. Эскалация и работа с контрактами

Если ситуация не улучшается, я действую согласно заранее согласованным процедурам эскалации (escalation matrix):

1. Формальное уведомление руководителю подрядчика с изложением фактов, рисков и ожиданий.
2. Совместная работа по плану исправления (Corrective Action Plan).
3. Если и это не помогает — обращение к юридическим и договорным рычагам. Мы всегда включаем в контракт пункты о штрафных санкциях (penalties) и праве на привлечение третьей стороны для выполнения работ за счет подрядчика.
4. В крайнем случае — инициирование процедуры замены подрядчика, параллельно начиная поиск резервного исполнителя.

5. Извлечение уроков (Lessons Learned)

После стабилизации ситуации я провожу ретроспективу (retrospective) со всеми вовлеченными сторонами.

• Что в наших процессах привело к этой ситуации? (Возможно, плохое управление требованиями с нашей стороны).
• Как улучшить процесс отбора подрядчиков (vendor management)?
• Как усовершенствовать шаблоны контрактов и процедуры коммуникации?

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