At your (professional) service

A blog on software professional services and more by Chuck D'Antonio

The end of the project honeymoon

The CMS Watch Trendwatch blog had a post yesterday on when the project honeymoon ends. We’ve all experienced this—when our relationship with clients shifts from “how can we help them succeed” to “how do we keep from bleeding money.” I think a big part of this is our failure to estimate well, and the fact that we prepare a big statement of work up from (BSOWUF? cf. BDUF).

At Acquia we use Scrum for product development and I want it to figure prominently in our PS delivery methodology as well. I’m not sure that the honeymoon never ends with an agile method, but I think the disappointments and the defensiveness of traditional methods are minimized. During the course of an agile project, you have regular feedback on progress, all validated with working software. I have still felt the honeymoon end when looking at features of our software, but it starts anew in a week or three when the next sprint begins.

Agile methods reduce the expectations of the honeymoon period as well. A colleague once explained her arranged marriage to me by explaining that she and her husband started out knowing that they needed to work on their relationship and make it work; my wife and I started out madly in love and able to do anything together. The honeymoon is bound to end when you go into a new relationship—business, personal, or otherwise—without acknowledging the real work, compromises, and negotiation ahead. Agile methods bring this work out in the just like the arranged marriage.

Does the project honeymoon have to end? I think it does, unless you avoid the artificial expectations that create it with practical, evidence-based methods like Scrum and other agile methods.

0
Your rating: None

No responses to “The end of the project honeymoon”