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

Технарьские проблемы:

- Очень неправильный изначальный estimate (чаще всего неправильная оценка сложности нескольких крупных задач)

Чаще всего такое происходит в том случае, если кто-то не слишком умелый оценивает проект. Решается чаще всего, тем что это делает не один человек, а два человека, причем хотя бы один из них должен быть хорошо знаком с областью проекта, а второй с большим опытом работы (и estimat’ов).

- Отсутствие технического лидера (или другого опытного человека) на проекте.

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

Решение, просто - добавить технического лидера на проект.

- Развития конечного продукта на базе прототипа.

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

Правильное решение, либо привести прототип к нормальной архитектуре, либо не пытаться съэкономить время на стартование с прототипа.

Бизнес проблемы:

- Установка нереалистично коротких сроков.

Тут все просто. Технари говорят, нам нужно 12 месяцев. Бизнес отделение отвечает - есть только шесть.

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

- Установка завышенных требований к первой версии

Чаще всего это происходит, когда версия номер четыре портируется на другую платформу или копируются чужая программа или пытаются написать идеальную программу.  В таком случае, выпуск проекта очень затягивается, так как идет полировка миллиона кусочков проекта.

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

Даже при портировании нужно разбивать на несколько версий.

- Слишком большое количество разнообразной требуемой функциональности.

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

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

- Малое внимание к проекту

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

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

Источник: блог Виктора Ронина.