The old adage that “an ounce of prevention is worth a pound of cure” couldn’t be more true in web development. Through recent experiences we’ve found out that it is well worth the effort to go to extremes in planning something out before you build it. Spending an extra 4 hours in planning can literally save 40 hours of development later, if not more. If you’ll indulge me, I’ll share a few stories to illustrate my point.
A project some of us have been involved with had a budget of X, and a scope of Y. It seemed simple enough that the planning was skimped, and the client wanted to get things moving quickly, so everyone just plunged in. Before you know it, there are things that we told would be done one way, and now they’re changing it and wanting it another way, and features A, B and C come out that they never mentioned to us until long after the budget was fixed. We try to make it work, and scope is now 2-3 times where it started out. Time goes on, and it turns out that the final client wanted something different than the decisions and instructions we were given, and wanted features D through H as well. Red flags have been raised several times, and some renegotiation gets 3X the budget to go along with what at the time was 6X the scope. Everyone is unhappy, because more information keeps coming out that we weren’t given, and the client got something different than what they were expecting because the expectation wasn’t made clear at the beginning, when the planning should have happened. Of course now everything is late too, and still not done the way they wanted, so features I through M make it into the mix, along with major changes to 8 of the existing new features. 8 times the original scope and counting, for 3X the original budget, and nobody is very happy.
What did we learn from that? We need to be much more strict about the planning, no matter how much they beg us to just get started, hoping that getting started sooner instead of planning more will get them to the desired destination faster. That’s like getting on the freeway and driving, so that you arrive faster at your destination, before you bother to figure out which direction the destination lies, and what paths might make sense for getting there on the timeline and budget you’re hoping for.
We often share with people a metaphor about their website is a building, and the plans are the blueprints. It’s relatively easy for an architect to move a wall on a blueprint, because he can just change the plan. But once the blueprint is in the hands of the construction company, and they’ve built the building part way, or all the way, it’s harder to move the wall. A client often thinks “I only need to move the wall 6 inches” but unfortunately that doesn’t change the fact that it is a wall, and would probably need to be torn down and rebuilt in the new location. Granted, not every change is moving a wall. Sometimes they want a window over here, or a door there. Sometimes they want to switch around the plumbing or the electrical. Some changes aren’t as major as others, but they all make some kind of difference when you have to redo or undo something. If they have us paint the room red, which we do, and then decide they want it blue, it will probably cost about double at that point to repaint. If they change their mind before the room has been painted, it isn’t a big deal, unless we already bought the red paint for them. The timing of the decision makes all the difference in what costs are sunk and what work has to be done, undone, or redone to make the changes they want.
The big lesson for me has been that it isn’t unreasonable to spend 4 hours planning a project estimated to take 40 hours, or 10 hours on a project that will probably take 100 hours. It is time well spent, because in the end you get done faster, you can be confident that you understood what they wanted, and it is much more likely that it will be done right. When you can get it done right, on time, and on budget, you’ll have happy clients.
Tags: budget, planning, Project Management, scope, wireframe
A couple of articles I read recently that apply here:
They write the right stuff – Web Developers probably don’t need to go this extreme, but I bet following even a couple of the tips in here would help immensely. (It’s a long read, but a good one)
There are no small changes – Another look at what a small change on the front end really means in the back end.
Excellent article Mac. Is 10% an example, or mathematically what you expect for a project?
It depends on the project, but 10% probably applies pretty widely. It usually tends to be less planning on smaller projects, but it really depends a lot on how many variations are possible on what they want to do.
A static site (no content management) has hardly any questions, especially once the full design is figured out and they hand off all the text and images.
Once you add content management, the number of questions goes up a lot.
Add a shopping cart or other e-commerce, and there are questions on top of questions that need to be answered, and you can put a lot of planning into something. Of course, something like that could be easily upwards of 100 or even 200 hours, so 10% is still about right much of the time.
The big point here is that spending half a day, half a week, or sometimes even half a month in planning isn’t usually a waste of time.
To consolidate this plan with your client is as import as the plan itself. Remember him beforehand that to walk through the project has a cost. If the planned changes, the cost changes accordingly.
And, has the buddy above commented, there are no small changes.