Интересно, сколько раз вы сталкивались в жизни с ситуацией, когда менеджер проета описывает неудачный проект, и объясняет, где он повел себя некорректно?
У меня такие случаи были единичными. Обычно виноваты плохо думавшие разработчики, невнимательные тестеры, придирчивые клиенты.  А менеджер весь белый и пушистый.
А такой ли уже пушистый???
Вот лишь несколько заметок из недавнего прошлого.  Конечно это не исчерпывающий список, а только пара ошибок, которыми страдают менеджеры проектов (с которыми я знакома), и которых следовало бы избегать:
1.    Не надо смотреть на заказчика, как на потенциального противника, который только и ждет, как бы тебя обвинить в некомпитентности или подловить на ошибке   ------ всегда помните, что клиент заинтересован в положительном завершении проекта значительно больше, чем исполнитель. Зачастую оборонительная позиция менеджера, боящего любой поправки или критического замечания, очень буксует проект.
2.    Не стоит думать, что клиент ничего не понимает в программировании, не может ничего нормально установить, и только поэтому у него не работает программа, которая прекрасно функционирует у вас. ---- Стоит более критично смотреть на собственную команду. Чем больше вы настаиваете, что это ошибка инсталляции и конфигурирования у клиента, тем больнее будет признавать собственные промахи.  У нас был примечательный случай, когда мы отдали клиенту оттестированное у нас приложение, а у клиента оно даже не билдилось. После нескольких писем с описанием предположительных ошибок конфигурирования на стороне клиента оказалось, что у нас в коде затесался прописанный путь к одной из баз данных тестового сервера. Позор!!!
3.    Не стоит во всем винить стороннее приложение с которым приходится работать. Если в ходе разработки вы однажды нашли баг на серверной стороне приложения, с которым приходится интегрироваться, это не означает, что у вас идеальный код, а работать приходится бог знает с чем. Воспользуйтесь здравым смыслом. Если бы тот злополучный сервер был бы настолько глючным , вряд ли бы он был популярным коммерческим продуктом. Попросите своих разработчиков еще раз перепроверить их логику.
4.    Не ждите, что клиент умеет читать ваши мысли, или помнит детально всю историю ваших обсуждений проекта. Зачастую клиент тратит на ваш проект 5-10% своего времени, а в голове держит еще огромный перчень задач. Поэтому всегда предоставляйте клиенту всю информацию, необходимой для принятия решения на данном этапе, в самом сжатом виде. Опять же из опыта работы с именитым западным клиентом. Мы пытались найти решение сложной проблемы в проекте, но на подход к решению накладывались сильные ограничения. Клиент отверг один подход, затем второй. После недели

Когда я начинала работать, нас топ менеджер и наставник в одном лице часто спрашивал, как мы считаем, в чем основная цель нашей работы. Звучало множество вариантов – разработать хорошую программу, уложиться в срок... А он отвечал, что главное – make our clients happy:)