Три ошибки при внедрении регламентов в проектных компаниях
Руководитель инжиниринговой компании решает навести порядок. Заказывает консультанту (или пишет сам) пакет регламентов: ведение проекта, работа с подрядчиками, документооборот, взаимодействие между отделами. Через три месяца документы готовы, красиво оформлены, разосланы по почте. Через полгода никто ими не пользуется. Знакомая история? Вот три причины, по которым это происходит раз за разом. Ошибка 1. Регламент без обучения Документ написан, утверждён и отправлен «для ознакомления». Сотрудники расписались в листе ознакомления. На этом внедрение закончилось. Проблема в том, что регламент — это изменение поведения, а не передача информации. Инженер, который 5 лет вёл проекты «по-своему», не переключится на новый порядок потому, что прочитал 20-страничный PDF. Ему нужно пройти через новый процесс руками: заполнить шаблон на реальном проекте, получить обратную связь, разобрать ошибки. Что работает: не рассылка документа, а 2-3 рабочих сессии по 1.5 часа. Берём текущий проект, проходим его по новому регламенту от начала до конца. Вопросы, споры, корректировки — всё на месте. После третьей сессии процесс становится привычным. Без сессий — остаётся файлом на сервере. Ошибка 2. Регламент без ответственного Документ написан, обучение проведено, но за соблюдением регламента никто не следит. Нет конкретного человека, который проверяет, что проекты ведутся по новому процессу, что шаблоны заполняются, что этапы согласования не пропускаются. Через месяц после внедрения 30-40% сотрудников возвращаются к старому порядку. Через два — большинство. Это не саботаж. Это нормальная инерция: человек действует так, как привык, пока нет внешнего контроля и обратной связи. Что работает: назначить владельца процесса. Не «контролёра», а человека, который отвечает за то, чтобы регламент жил. Раз в неделю — экспресс-проверка: три случайных проекта, три вопроса. Заполнен ли чек-лист входного контроля? Есть ли протокол совещания с подрядчиком? Обновлён ли статус в системе? Пятнадцать минут, которые поддерживают дисциплину. Ошибка 3. Регламент «для галочки» Самая тяжёлая. Руководитель заказывает регламенты не потому, что хочет изменить процессы, а потому, что «в компании нашего уровня должны быть регламенты». Или потому, что аудит показал отсутствие документированных процедур. Или потому, что инвестор попросил. Результат предсказуем. Документы написаны под формальные требования, а не под реальную работу. Формулировки общие: «обеспечить своевременное выполнение», «осуществлять контроль качества». Конкретных шагов, шаблонов, точек контроля — нет. Сотрудники видят, что регламент оторван от реальности, и молча игнорируют его. Руководитель доволен: «документы есть». Процессы не изменились. Что работает: писать регламент не «сверху вниз» (руководитель → консультант → документ → сотрудники), а «снизу вверх». Собрать руководителей проектов, зафиксировать, как они реально ведут проекты сейчас. Найти 2-3 точки, где регулярно теряются деньги или сроки. Написать процедуру именно для этих точек. Не 20 страниц, а 2. Не «политика управления проектами», а «чек-лист из 8 пунктов перед стартом монтажа». Общий паттерн Все три ошибки растут из одного корня: регламент воспринимается как документ, а не как изменение поведения. Документ можно написать за неделю. Изменение поведения 20-30 инженеров занимает 2-3 месяца системной работы. У кого нет терпения на эти месяцы, получает папку файлов и иллюзию порядка. Какой из трёх сценариев ближе к вашей компании? #ПроектноеУправление #Инжиниринг #Регламенты #B2B #Процессы