К АлексО Директор - «Все эти проблемы, как правило вытекают из одной причины:
недостаточная обеспеченность проекта ресурсами».

Вы действительно директор? В философии есть закон «перехода количества в качество». В консалтинге, тем более, в практике SAP, в Вашем случае он не работает. С одной стороны можно количественно обеспечить проект ресурсами (финансовыми и людскими), бросить всех на амбразуры… задавить количеством. Вам людей (консультантов) не жалко? По головам своих ресурсов=консультантов идете! Ваши финансы не жалко – я не понимаю, как Вы будете покупать решение проблем? С одной стороны проблема – с другой «сумма в баксах»? Компанию не назовете? Извините, никаких денег у Вас не хватит, если Вы честно ведете бизнес. Это экстенсивный подход к решению проблем. Директор не только должен уметь планировать ресурсы. А как же стратегические решения, конкуренция и развитие? Получается как на рынке… немного SAPа купили…… как тапочки покупаем… Интересно познакомиться с мнением ваших сотрудников, я думаю, они не в курсе, что можно озолотиться! Могу предположить, что у вас очень высокая текучесть кадров, постоянно проходят реорганизации, как в …. Извините, без сравнений. НЕ ВСЕ ПРОДАЕТСЯ И ТЕМ БОЛЕЕ, ПОКУПАЕТСЯ – иногда нет требуемого товара, а именно «РЕШЕНИЯ ПРОЕКТА» ни за какие деньги. И торговаться не с кем. А деньги на покупку золотых специалистов и готового решения - из недоплаченных за реальную работу вашим сотрудникам. Не будет у Вас успешных проектов при таком подходе, конкуренты сожрут

2 Alisa

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

+1
Весьма путаное изложение, в чем суть - абсолютно непонятно.

В точку. Именно потому компания, в которой я тогда работал, сумела получить контракт на тот проект (где работали "бизоны мозгового штурма" ). Компания, в отличии от своего конкурента, взялась сделать "всё" за указанные срок и бюджет.
А конкурент - крупная западная консалтинговая компания, пыталась в договоре формализовать объемы и, в результате, проиграла тендер.
Лишний раз задумаешься, как нужно продавать проекты.

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

Я, кстати, описывал эту проблему:
1) Заказчик постоянно предъявляет претензии к консультанту за несоблюдение сроков и объемов проекта, при этом со своей стороны, как правило, с легкостью их нарушает. Регулярно возникают нарушения регламентов и сроков согласования проектных документов по вине Заказчика. Попытки аппелировать к договору или уставу обычно пресекаются ответом, типа "вы хотите чтобы этот документ был последним, которые вы сделаете на нашем проекте?"
2) Заказчик никогда не ограничивает себя в формулировке требований, даже перед самым продуктивным стартом, что нередко приводит к переносу срока начала проекта. При попытке аппелировать к договору или уставу - см. п.1

вот вот..
Алиса, Вы не мудрствуйте лукаво, а опишите то что волнует в трех словах, буквально в трех словах.

А почему бы и нет? Пусть это будет последний документ в данном проекте.
Почему страшно то ?:)
Конечно, грамотно похоронить проект А, а тут же запустить проект А1, с учетом новых пожеланий заказчика.
Но можно и просто хлопнуть дверью.

Мне кажется нормальной практика формирования ТЗ на первом этапе проекта (as-is или как угодно) консультантами исполнителя. При этом договором должен быть предусмотрен этап пересмотра суммы по договору по результатам ТЗ.

ИМХО Заказчик все равно не способен написать качественное ТЗ, или хотя бы список бизнес процессов. А написать детальное ТЗ исполнителю до заключения догвора тоже проблемно.



шантаж. видимо Закачик в этом случае знал, что у Исполнителя просто нет шансов хлопнуть дверью.

Мне кажется таких случаев меньше, когда помимо руководителя проекта (топ-менеджер) от заказчика есть еще и куратор проекта (ген. дир.).

Тогда концептуальная модель или др. ключевые документы, утвержденые ген. диром уже не так-то легко изменить руководителю проекта (выставить доп. требования.) Разбор полетов на "ковре" покажет его некомпетентность как руководителя.

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

И как именно?
Каково ваше мнение?
Мое мнение - так, как продавала западная компания.

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

Не всегда.
Бывают компании, которые садятся на одного заказчика и "навечно" с одним единственным проектом. Но, это совсем другая тема.

По моему мнению основной источник всех проблем проектов это:
1) нарушение (или отсутствие) комуникаций среди участников проекта.
2) необоснованные предположения о (сроках, объемах, ресурсах и т.д.).

Оба источника лежат в основе общечеловеческих наклонностей: "Приятнее всего свой голос" и "Ожидание метафизической халявы..."

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

Это не головоломка
ИМХО - чтобы иметь буферы надо иметь возможность их адекватно планировать и иметь о них (рисках) исчерпывающую информацию.
А простои... надо знать подробнеее

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

Не зря в армии загружают солдат всем подряд... + контроль.