When the project honeymoon ends

I've been advising a large enterprise in the midst of a somewhat complex Web CMS and Component Content Management implementation, and recently participated in a mid-project check-point where the lead systems integrator laid out progress to date. It was interesting how the atmospherics of the project had changed over the course of the year. After an earlier phase that featured a mutual exploration of creative solutions by all the various parties (client, SI, vendor, consultants, etc.), the project now appears to have evolved into an effort by the SI to tightly control their obligations and, at some level, reduce expectations.

Of course, it's the job of the SI to keep scope under control, if they are going to finish on time and under budget. But the tenor of the project has changed. To continue the marriage metaphor that I frequently roll out to describe vendor selection best practices, the honeymoon is long over, baby.
I leave it to real experts (like Graham Oakes) to explain the various ways to keep projects running smoothly and meeting business objectives. It's been my experience, though, that even with the best project controls (and there are some good ones in place here), there comes a time in a systems project where the conversation turns subtlely but fatefully towards what the software package can and can't do, rather than what the business needs to accomplish. It usually starts with the implementation team and soon carries over to everyone else. Some of that attitude is really just being practical, and doubtless some of it reflects exhaustion with the process. A savvy project leader on the customer side recognizes this as a marathon, and keeps reserves of energy to advocate on behalf of original objectives.
To me, this also reinforces the primacy of due diligence and broad testing before you sign on to a solution. In a large project, you are going to encounter surprises and disappointments. The question is, how big...and how often?