ТОП-10 ошибок проектного менеджера (и которые каждый из нас хоть раз совершил)

Меня тут попросили поговорить на лекции про ошибки проектного менеджера. Решила проверить на вас свою версию.

1️⃣Слабое управление ожиданиями и объемами
К вам же точно приходил человек, который «мои требования тут самые важные»? А потом проектные рамки тихо «расползаются», появляются «небольшие» правки, дополнительные требования и т.п.
Что бывает: Бесконечный проект, срыв сроков, перерасход бюджета, выгорание команды.
Что делать: Жесткий процесс Change Request. Любое изменение - только через оценку изменений бюджета и сроков. Иногда уже на этапе оценки заказчики передумывают.

2️⃣Работа без фундамента (устав, ТЗ, договор, методология, требования или что-то еще)
Старт работ по письму важного человека, отсутствие утверждённых требований, нечёткий контракт.
Что бывает: Бесконечные споры о включении работ в стоимость, «мы думали, вы это сами учли», юридические риски.
Что делать: Разработать хотя бы какой-то документ перед началом проекта. Даже один лист с описанием состава работ лучше, чем ничего.

3️⃣ Отсутствие единого заказчика и зон ответственности
У проекта всегда несколько «хозяев» с разным видением (ИТ vs бизнес-департаменты, центр vs филиалы).
Что бывает: Противоречивые требования, паралич в принятии решений, бесконечные переделки.
Что делать: делать матрицу ответственности (кстати, про нее писала тут) и добиваться работы по ней.

4️⃣Пренебрежение командой и её мотивацией
Что бывает: Выгорание, текучка ключевых специалистов, падение качества, саботаж.
Что делать: Защищать команду от хаоса, понимать мотивацию и карьерных целей. Счастливая команда = эффективная команда.

5️⃣Иллюзия прозрачности и недостаток коммуникации с заказчиком
PM отчитывается на статус-встречах, но команда и заказчик не видят реального прогресса.
Что бывает: Падает доверие заказчика, команда не понимает общего контекста, проблемы обнаруживаются слишком поздно.
Что делать: Регулярные демо для заказчика, открытые канбан-доски, вовлечение бизнеса в процесс («мы делаем вместе», а не «мы делаем для вас»), например, можно разделить с заказчиком свои годовые цели.

6️⃣Оценки «на глаз» и планирование в вакууме
PM сам оценивает задачи и строит план, не консультируясь ни с кем.
Что бывает: Проваленные сроки, нереалистичные планы, потеря доверия.
Что делать: Оценки дает тот, кто будет делать. План утверждает вся команда. Можно прочитать как устроено квартальное планирование в SAFe и взять этот подход за основу. И еще всегда закладывать буфер на непредвиденное.

7️⃣Экономия на тестировании и инфраструктуре
«Потестим потом», «развернём на чем придётся». Отсутствие тестовых ландшафтов, стратегии тестирования, нагрузочных тестов.
Что бывает: Баги в проде, падение систем под нагрузкой, срывы релизов.
Что делать: Инфраструктура и тестовые среды - часть планирования. Качество нельзя «добавить» в конце.

8️⃣Плохая работа с данными и интеграциями
Некорректные исторические данные для миграции, несогласованные глоссарии для отчётности, интеграции «на коленке».
Что бывает: Мусор на входе — мусор на выходе. Отчёты не сходятся, системы не обмениваются данными, переделки = рост бюджета.
Что делать: Заложить работу со справочниками в план с самого начала.

9️⃣Отсутствие управления теми изменениями, которые принесет проект.
Пользователи не готовы, нет обучения, не поменялись регламенты.
Что бывает: Внедренную систему никто не использует, или использует неправильно. Нулевая отдача от проекта.
Что делать: Change Management - отдельная большая работа. Стратегия обучения, коммуникаций и адаптации людей с самого старта проекта.

1️⃣0️⃣Игнорирование рисков до их превращения в проблемы
«Это проблема для нас из следующего года». Непроверенная платформа вендора, редкий стек технологий, регуляторные изменения, зависимость от одного ключевого человека.
Что бывает: Внезапный коллапс, когда уже ничего нельзя сделать.
Что делать: Быть параноиком - это профессионально, коллеги. Вести живой реестр рисков с планами их митигации.

Что забыла? Жду вас в комментариях!