You can't predict the future. That's just stupid.
A few months ago I did (along with the other partners at Fudge) a talk at Northern Digitals about a project that went wrong. It was the worst six months of work we'd ever been through. Sounds dramatic, but it's true.
As far as I'm concerned, most of the problems we encountered were caused by the 200 page functional spec that we laboured over for months. As far as we knew, the client understood and agreed to everything we proposed to build. We had a signature after all. We were very wrong.
The project that went wrong made me re-think our approach to project management, design and build. Everything really. The biggest impact from my perspective came from the adoption of the empirical approach to planning that Scrum provides.
Predictive Planning
Consider this scenario.
You're half way through the project and the client calls. Their business requirements have changed and all of a sudden the project needs to achieve something new. The approved spec doesn't account for this.
Also, the client still wants everything already defined in the spec. Then the really nice bit. They need everything specified, plus the new stuff, but they don't have any extra money to pay for it.
Because the client signed off the initial spec, you're obliged to honour it. The project won't succeed unless the changes are accounted for, but they don't have any money to pay for it. Do you....
- Complete the work free of charge
- Refuse to make the changes without payment
- Honour the original spec without the changes and risk project failure
The only option the client will like is the first.
Empirical Approach
We use Scrum which provides an empirical approach to planning. Many people look at Scrum and assume that we don't plan. That's obviously not the case, we just plan and execute in a different way.
Instead of writing detailed specifications when the project begins, we write user stories. These define a goal but don't define how that goal will be achieved. For example:
"As a user, I want to sign up, so that I receive member benefits."
We don't define how the user will do that yet. We don't need to. Instead, we decide when that story will be worked on, and define it in detail when that time comes (more on that in another post). We then design, build, test and deliver that story. Here are a few benefits to this:
- Something might happen prior to that story being built that affects the way it might work. This could be a change in business requirements or scope. Because we haven't defined it yet, we're able to build it with the whole project in mind.
- While building that feature, something might present itself that makes us re-consider the stories yet to build. Again, we haven't defined this or the remaining stories, so we can adapt.
An important thing to mention is that we're always working on the most important thing. We don't order the build plan based on what's easy or difficult. We work with the client to decide which of the outstanding features they'd like us to work on, based on their business needs.
Conclusion
If you want to deliver the best thing possible, always work on the most important aspect of the project. If predictive planning lets you do this, then great, if not, have a look at an empirical approach.
If you like analogies, then try this:
Predictive planning is like firing a medieval cannon. You load it, aim it, adjust, adjust, adjust, then fire. Hopefully you hit your target. If your target moves, you miss.
Empirical planning is like firing a guided missile. You pick your target and fire. On it's way it adjusts it's course and refines it's path. It doesn't matter if your target moves, because the missile can change direction. You'll smash it to bits.
