Проверено на своем опыте! Меня тоже, как менеджера, в самом начале проекта напугала формулрировка, что проект будет фиксед прайс но заказчик (конечный заказчик, а не компания с которой у нас подписан контракт) хочет гибкую разработку. Все было по классике, как и описано в статье выше, мы оценили фичи, написали доку, утвердили объем работ, составили расписание проекта, описали риски и поехали...
И все получилось, вовремя и в срок. Да мы не использовали СКРАМ, так как небыло для этого возможности но мы смогли в самом начале:
• Установили человека, который принимает ключевые решения на стороне клиента и несет ответсвенность за проект — это упростило и ускорило решение сложных или спорных вопросов
• Формализировали работу с посредником — сообщили ему что мы будем работать с конечным клиентом на прямую избегая «скользских» моментов и будем держать посредника в курсе
• Зная конечную дату проекта +/- проект был разбит на 2-х недельные спринты (хотя и разной протяженности по дням) — это помогло отслеживать процесс
• Было составлено расписание еженедельных встречь для отчетности, с менеджерами компании посредника — это дало прозрачность в отношениях (мы работали первый раз) и показало, что мы действительно разбираемся в том, чем занимаемся.
• Была введена демонстрация готовых результатов после каждого спринта — это помогло вовремя изменить структуру приложения и отойти от первоночальной концепции без ущерба для сторон.

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