Ошибки PMO: lessons learned как кладбище документов

40 документов, которые никто не открывал

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

Мы назвали это путеводителем по рискам и я до сих пор считаю, что документ получился просто отличным.

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

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

Когда грабли повторяются третий раз

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

PMO констатирует провал и не понимает, где сбой. База ведётся, правило соблюдается: каждый завершённый проект проходит сессию lessons learned. Откуда тогда повтор?

Хранить и применять: в чём разница

Хранение знания и его применение в нужный момент - это две принципиально разные задачи. Мы хорошо умеем первое и почти не думаем о втором.

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

Это та же архитектурная ошибка, которую хорошо видно в AI-системах. Компании строят огромные корпусы документов, загружают туда всё, что накопили, и считают задачу решённой. Но корпус без механизма retrieval (поиска, извлечения), без процедуры активации знания в момент принятия решения, не работает. Именно поэтому появились RAG-системы: не чтобы хранить больше, а чтобы извлекать в нужный момент.

Уложить знание в документ и сделать его доступным тогда, когда оно нужно, - это разные задачи. Мы долго считали, что первое автоматически означает второе.

Как сдвинуть PMO с архивирования на применение

Если retrieval не происходит сам по себе, его нужно встроить в процесс. Три паттерна, которые работают.

Первый: risk-triggered lookup. При инициации проекта PMO поднимает релевантные уроки: по типу заказчика, по технологии, по подрядчику. Не вся база, а прицельно то, что относится к конкретному контексту. Это переводит retrieval из случайного события в обязательный шаг.

Второй: чек-лист рисков как операционный артефакт. Не отчёт на полку по итогам проекта, а документ, который встраивают в жизненный цикл проекта и используют при переходе на следующий этап в stage-gate модели. Выученные уроки перестают быть ретроспективным жанром и становятся входом в следующий проект. Форма меняется: не “что было”, а “на что смотреть дальше”.

Третий: PMO как активный ретранслятор. Не ждёт, когда команда придёт в базу. Сам доставляет знание в нужный момент: на kick-off, при входе нового подрядчика, на старте рискованной фазы. Роль PMO здесь не архивариус, а тот, кто знает, что лежит в базе, и понимает, когда это нужно достать.

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

После провала с рассылкой мы пересмотрели логику распространения. Один канал, одно письмо - это не стратегия, это надежда. Мы перестали на неё полагаться.

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

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

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

Задача PMO: не вести базу, а обеспечивать применение

Это сдвиг, который меняет всё. PMO отвечает не за то, чтобы документ существовал. PMO отвечает за то, чтобы его использовали.

Звучит как очевидность. Но большинство процессов lessons learned выстроены иначе: сессия проведена, артефакт создан, галочка поставлена. Дальше - тишина.

Если встроить retrieval в жизненный цикл проекта, логика меняется. Kick-off, gate, старт работы с новым подрядчиком: это точки, где PMO активирует нужный урок, а не ждёт, пока кто-то сам догадается поискать. Процесс, а не хранилище.

Пока PMO считает задачу выполненной в момент записи урока, уроки будут повторяться. Сорок документов в папке и ноль применений - это не проблема базы знаний. Это проблема процесса, который остановился на полпути.