Топ ошибок в управлении проектами и как их избежать

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

Екатерина Синица, старший эксперт направления по развитию персонала Лиги Цифровой Экономики, разбирает пять распространенных управленческих ошибок и объясняет, как их избежать.

На старте заказчик обычно ставит глобальную цель: оптимизировать процессы, снизить затраты, увеличить прибыль. Например, компания хочет увеличить продажи на 20 % и для этого решает внедрить новую CRM-систему. И в таком случае в договоре на оказание услуг по внедрению CRM или в менее формальных документах по проекту может быть указана цель: «Увеличение продаж». Но этого делать ни в коем случае нельзя. Ошибочно полагать, что одно только внедрение системы автоматически приведет к росту бизнес-показателя — результат зависит от множества факторов, на которые исполнитель не влияет. Поэтому важно заранее четко разделить ответственность:

1) Исполнитель отвечает за внедрение системы, соответствие техническому заданию и соблюдение сроков этого внедрения.

2) Заказчик несет ответственность за достижение собственных бизнес-целей.

Если не обозначить эти границы, возникнет недопонимание. Заказчик может ожидать, что исполнитель обеспечит рост продаж, хотя тот отвечает только за создание инструмента.

Что делать: однозначно разделить зоны ответственности и понять, «что будет сделано» в проекте и «зачем». Ответственность за второй вопрос всегда остается на заказчике. Оптимально, если в проекте выстроен «треугольник власти»:

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

2. Заказчик. Отвечает за постановку требований и приемку результата. Человек, которому больше всех нужен результат и который будет пользоваться полученным решением после окончания проекта.

3. Спонсор. Отвечает за обеспечение ресурсами на реализацию проекта. Владелец ресурсов — представитель руководства компании-исполнителя.

Исполнитель в лице руководителя проекта и спонсора создает только само решение, а бизнес-эффект от его использования достигается заказчиком.

Еще одна распространенная ошибка при постановке цели проекта — отсутствие четких критериев приемки, в том числе и сроков. Если стороны не обсудили, что именно и к какой дате необходимо сделать, сдача результатов заказчику неизбежно растянется.

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

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

Что делать: формулировать цель по SMART. Это создаст четкие ориентиры: что нужно сделать, как измерить успех, когда должен быть готов результат. Например, «доработать интерфейс для повторных продаж» — слишком размытая формулировка, которую заказчик и исполнитель могут понимать по-разному. «Внедрить систему уведомлений о промоакциях к 30 сентября 2025 года» — более удачная, так как создает однозначные ожидания у всех участников проекта.

При сборе и последующем контроле выполнения требований к проекту поможет трехуровневая модель:

1. Бизнес-требования. Ответ на вопрос «зачем» — нужен для выработки наилучшего решения, но, как правило, недостижим в рамках проекта.

2. Пользовательские требования. Основной массив требований, реализация которых входит в границы проекта.

3. Функциональные требования. Детальные требования к решению и результат их анализа, являющийся постановкой задачи на разработку.

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

Пропустив этот этап, руководитель лишает себя «запаса прочности» по времени, бюджету и ресурсам. Каждый пропущенный риск может обернуться неуправляемым кризисом, в котором у команды не будет пространства для маневра.

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

Что делать: при постановке целей выявить максимум допущений и рассмотреть их как риски:

- Оцените вероятность и возможный ущерб от того, что допущение не сработает.

- Создайте планы реагирования на наиболее вероятные и существенные риски.

- Заложите резервы времени и ресурсов там, где плана реагирования у вас нет.

- Каждые 2–4 недели пересматривайте список рисков и корректируйте меры реагирования.

Так вы сможете сохранять контроль даже в условиях неопределенности.

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

Со временем руководитель учится замечать больше рисков и точнее их оценивать. Но иногда возникают «слепые пятна» — области, где мы не видим ничего дальше свершившихся фактов. Так бывает, когда руководителю проекта не хватает компетенций, а рядом нет надежного эксперта, с которым можно посоветоваться. Отсюда происходит миф, что руководителем должен быть «технарь». Считается, что он допустит меньше ошибок благодаря высокой экспертизе. Однако это заблуждение. В современном мире мало кто действительно способен разобраться во всех технических аспектах проектов. Хорошо понимая одну область, «технарь» может плохо видеть или вовсе игнорировать другие сферы. Более того, позиция «крутого эксперта» иногда мешает вовремя обратиться за поддержкой и посмотреть на проблему с разных сторон.

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

Схожая ошибка может проявиться в оценке последствий рисков. Эффект Даннинга — Крюгера в действии: новички склонны к опасному оптимизму («Все легко получится!»), а чуть более опытные слишком тревожны («Это чересчур сложно!»). Оба подхода искажают реальную картину и вредят проекту. В первом случае команда просто не готова к проблемам, а во втором — ресурсы уходят на борьбу с маловероятными сценариями.

Объективность в оценке рисков достигается применением проверенных методов и коллективной экспертизой, а не интуицией или личным прошлым опытом.

Что делать: структурировать риски. Например:

- Составьте матрицу рисков, где каждый фактор оценивается по вероятности и влиянию на проект.

- Классифицируйте риски по категориям: внешние, организационные, технические, управленческие.

- Ориентируйтесь на исторические данные, параметрические оценки и коллективную экспертизу.

Так вы сможете более объективно рассчитать резервы времени и ресурсов и выстроить взвешенный план реагирования на угрозы проекту.

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

Итог прост: успех проекта определяется задолго до его завершения. Чем больше внимания вы посвятите формулированию четких целей, распределению ответственности и продуманной работе с рисками, тем более предсказуемым и эффективным будет результат.