The 12 month extension was going to get the managers who proposed it fired. So they couldn't actually propose it - thus the cliff.
Instead they needed an alternative. Of course a better discussion would have been a frank reevaluation with the client, with several options and points of trade-off to consider.
But really the best way - presuming everyone is working toward the same ends (NOT a given) - is to identify some kind of MVP/pilot that can been delivered and evaluated and iterated upon. That way you have _some_ kind of success to build upon with the client. This is failure of every badly run waterfall project. Even presuming the original design could be built on time ... how would it know it was actually useful? You also need the more limited success to rebuild trust - otherwise your new estimates will be questioned and looked upon with suspicion. If some tells me an 18 month project is going to take another 12 months, I need to assume the same incompetence really means that the new estimate is behind the curve as well ... not to mention changing requirements in the meantime continuing to push thing things out.
> presuming everyone is working toward the same ends (NOT a given)
I have realized that in many cases neither the decision-makers at the client nor the decision-makers at the consultant/vendor are working towards the ends of a succesful product. Their ends are their careers, and benefit to their careers may be pretty orthogonal to actual product success.
Once when I was working at a place, I had a discussion:
"I think if we use this vendor solution, it's likely to not work very well for our users. I think we have a better chance of meeting our users needs doing it in-house."
"You could very well be right, but if we do it in-house and fail, it'll be our fault, everyone will blame us. Everyone is used to using the vendor for this, it's a decision nobody will blame us for, even if it fails. We're going with the vendor."
In some cases, everyone can in fact have their goals aligned... their goals simply aren't product success.
Instead they needed an alternative. Of course a better discussion would have been a frank reevaluation with the client, with several options and points of trade-off to consider.
But really the best way - presuming everyone is working toward the same ends (NOT a given) - is to identify some kind of MVP/pilot that can been delivered and evaluated and iterated upon. That way you have _some_ kind of success to build upon with the client. This is failure of every badly run waterfall project. Even presuming the original design could be built on time ... how would it know it was actually useful? You also need the more limited success to rebuild trust - otherwise your new estimates will be questioned and looked upon with suspicion. If some tells me an 18 month project is going to take another 12 months, I need to assume the same incompetence really means that the new estimate is behind the curve as well ... not to mention changing requirements in the meantime continuing to push thing things out.