1. Неверная оценка проекта.

Почти все заказчики хотят сразу узнать стоимость «ремонта». И это логично с их точки зрения — только поняв объём, они принимают решение о старте проекта.

Как лечить: выделить консультационный этап в отдельный мини-проект. На его основе формируются ТЗ, IDR, бюджет и календарный план.

2. Сопротивление или бездействие персонала заказчика на этапе реализации.

Деньги на проект выделены, но, например, при переходе на новую систему бухгалтерии никто не выделяет время персонала, не увеличивает фонд оплаты труда для обучения.

Как лечить: провести обучение клиента, создать для него центр компетенций.

3. Ошибки при формировании требований заказчика.

Все требования вроде фиксированы и структурированы, но поступили от разных людей и отделов. Люди меняются, и в момент реализации появляются новые участники с другим видением. Нет процедуры отслеживания изменений требований и их официального утверждения.

Как лечить: управление требованиями, формализация процедуры внесения изменений.

4. Отсутствие учёта и документирования изменений и «фич» в проекте.

Проект идёт с отклонениями от согласованного, что нормально. Но никто не фиксирует эти отклонения. При передаче проекта или его сопровождении остаются только устаревшие ТЗ и спецификации, которые уже не отражают реальность. Проект становится кошмаром для поддержки.

Как лечить: несмотря на дефицит ресурсов, фиксировать все изменения в концепции проекта.

5. Недостаточное обеспечение проекта ресурсами.

Сюда входят:

a. Неправильный подбор людей по количеству и компетенциям
b. Привлечение специалистов посреди проекта для «тушения пожаров»
c. Отзыв сотрудников на поддержку старых проектов
d. Отсутствие замены исполнителей
e. Высокая текучесть — уходят знающие, приходят новые

Лечения пока нет. Похоже, это специфика индустрии — «слишком много задач» и срывы сроков.

6. Централизация задач на самых компетентных.

Нет персонала. Есть те, кто знает и делает, и те, кто делает только если им сказали. Ответственные не делегируют, атмосфера в команде не способствует распределению задач.

Лечения пока нет. Видимо, это характерно для ИТ. Хорошие инженеры и программисты — интроверты. Все говорят о создании Agile-команд, но на практике это требует дорогих и редких кадров. Если есть решение — поделитесь.

7. Высокие затраты на поддержку и управление инфраструктурой.

Как бы чётко ни были прописаны правила — где разрабатываем, где тестируем, как выкладываем релизы — всё равно приходится постоянно контролировать, объяснять и наказывать. PM покрывает всё больше задач.

Как лечить: выделение ресурсов на контроль процессов и отражение этих затрат в бюджете.

8. Сложность настройки процесса разработки под конкретный проект.

Каждый проект уникален — по серверам, доступам и т.д. Например, некоторые заказчики создают VPN, через который должны проходить все участники проекта.

Как лечить: выделение ресурсов на планирование и отражение этих затрат в бюджете.

9. Отсутствие итераций в проекте.

Нужно показывать промежуточные результаты, чтобы заказчик понимал, что мы идём в нужном направлении. Но у заказчика нет времени на оценку. Мы продолжаем двигаться вперёд, ведь ему нужны дедлайны, а не отговорки.

Как лечить: введение в проект роли «аккаунт-менеджера», который постоянно на связи с клиентом и вытаскивает нужную информацию.

10. Плохое использование прошлого опыта и отсутствие условий для его накопления.

Когда проект «горит», никто не думает о формировании библиотек и модулей на будущее. В итоге вместо реального производства — вечное изобретение велосипеда.

Лечения пока нет. Есть ли у вас опыт — как замотивировать PM-ов и разработчиков формировать опыт и практики?

Станьте незаменимым проектным руководителем, присоединяйтесь к нашим международным программам сертификации IPMA и Green Project Management!

01.05.2025