"What do you mean you need to push back the launch date?"
Says the CEO. Says the CFO. Says the user community. CTOs, CIOs, and all officers who oversee major development projects have had to deliver the dreaded message. But a deadline for the sake of a deadline is a dangerous pitfall that can consume an entire project and stymie it to the point that it never launches. Over the years I've come up with six simple rules that help deadlines become more meaningful, while keeping the developers, the user community, the CFO and the CEO all satisfied.
1.Always have minor version control throughout development. Group functional requirements into minor versions so that core functionality is prioritized and so that the entire development team is generally active on the same minor version.
2.Always target minor version releases every 2 to 4 weeks.
3.Always begin testing immediately once each minor version is complete.
4.Always prioritize bug-fixing to the highest level upon the completion of any testing.
5.Never allow a problematic functional enhancement to be a showstopper. Negotiate with the user community and the CFO or CEO for a delay in, or removal of, the delivery of that functionality.
6.Always launch the product on time - as long as the most recent fully completed minor version is functionally equivalent or better than the current production system. Launch it, no matter how far you are from 100% complete.
So I want you to launch an incomplete application?
Let's just call it "functionally challenged". This is what I call the 70% solution. The deadline doesn't move and the developers deliver a fully tested, bug-fixed version on time and within budget. This gives management the opportunity to evaluate further investments into application functionality while reaping the benefits of any developments to date.
Don't blame the developers.
It's more likely a project runs over budget and over deadline because of optimistic cost planning or scope creep than poor developer skills. Following these rules ensures delivery of the best product the development team can achieve within a set budget or period of time. Even in an environment where scope creep becomes a factor, escalating requirements can be scheduled into minor versions so they never hold back the launch of the "functionally challenged" application.
Testing? Who needs testing?
So you didn't follow the six rules, you're past the code freeze date, and you're supposed to be in final testing but there are still more things to implement. The user community and the CEO want to know if you'll be able to launch on time regardless. That's when it hits you— if only we could "streamline" the testing phase we could still make it. Very bad idea. The cost of backing out due to insufficient testing can cost more than the project itself. Recently I witnessed a botched implementation of a customer service application that almost cost the company in question its three largest clients—and millions of dollars.
Work your mediation magic.
Application development managers have to be part negotiator and part magician. They need to keep all sides happy, even if product expectations and budget restrictions are in conflict. No one really wants the 70% solution, but everyone can live with it. And when no one's 100% happy, you know you're probably doing it right.
Read more in Case in Point: "The Thursday Rule"
