"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" Steve Pickard
CEO, Founder Working actively with Oracle since the early '90s, Steve has architected and
developed everything from large data-warehouses and decision-support solutions
to award-winning instant Web applications. Steve has degrees in Mathematics and in Management of Information Systems from
Ottawa University.
Before founding Pythian, Steve worked as
a consultant for numerous companies as well as the Canadian government. He
remains the key architect of Pythian's highly sophisticated internal applications and
business process systems.
|
Categories 
