За последние 20 лет через мои руки прошло множество IT-проектов. И почти всегда причина проблем оказывалась не в технологиях и не в командах.

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

Первая — недооценка проекта на старте.

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

В любом проекте есть то, чего заранее не знаешь, и под это обычно закладывают резерв. Проблема в том, что резерв часто занижают. А когда реальный объём отклонений оказывается больше, чем заложили, проект начинает требовать ресурсов, которых уже нет. Вот тогда он «захлёбывается».

Вторая — отсутствие проактивного управления.

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

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

Третья — коммуникация.

Большинство задержек, простоев и взаимных недопониманий — это не конфликты и не некомпетентность.

Это плохо выстроенная коммуникация внутри команды и между командой и заказчиком.

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

Основная работа руководителя проекта — это не технические решения. Это качественная, регулярная, прозрачная коммуникация без задержек и недосказанности.

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

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

Если хотите пройтись по своему текущему проекту и посмотреть, где сейчас нет ясности, пишите @dm_bocharov.

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

➡ Прежде чем запускать проект, полезно честно ответить на 6 вопросов про состояние вашего IT.

➡ А если задача - вернуть время команды через автоматизацию, вот как внедрять ИИ, чтобы не попасть в ловушку «успешного пилота», который так и не стал рабочим инструментом.

📌 Впервые на канале? Начните с закрепа.