Work in web development long enough and you realize no two projects are exactly alike.
Projects I’ve been involved with (around 200 to my best guess) run the gamut from single-page sales pitches to full-blown (and overly complex) social communities. And everything in between.
And there’s a common thread that has run through every one of them: feature creep.
Feature creep, or “scope creep,” happens when a project’s overall scope (and workload) inflates because of unforeseen or unspecified features and functions. The result is usually confusion, frustration and, to varying degrees, the loss of profitability on the project. Mild cases are annoying. Bad cases can throw you into an existential crisis (“Why am I even doing this?” “What’s the point if I can’t turn a profit?” “Maybe I should get the band back together…”)
There are ways to manage this phenomenon, to nip it in the bud before it kills your spirit and profitability.
Expect it
Feature creep will happen. Period.
Consider the parties involved:
The Client
- Knows little about the technology
- Usually isn’t sure exactly what he needs or wants
- Demands a firm, upfront price
The Developer
- Doesn’t want to give away the farm until she’s hired
- Is afraid of spending too much time upfront only to be denied the job
- Has a hard time recognizing what the client hasn’t thought of
There’s a knowledge gap here, and it gets us into trouble. As long as the savvy provide services to the less-than-savvy this will be the case.
So the best way to handle feature creep is to expect it. Treat it as a given. Estimate your costs (materials, hours of labor, etc) and add plenty of breathing room. It may sound terrible to pad your prices, but, between our own innate tendency to underestimate time requirements and feature creep, on a long enough time line you’ll find you aren’t padding at all – you’re budgeting for the inevitable.
Actually do some discovering during the “discovery” phase
Scalability in development means productizing your offerings. It’s the easiest way to increase potential sales volume. Put together packages and sell websites that way instead of spending time customizing every proposal.
The problem is that every project & client is unique – unless you’re cranking out identical WordPress websites for $200 a pop (in which case, carry on – at least until the guy doing it for $150 gains traction).
Spend time with your clients before you’ve quoted them a price. Get into it – their goals, websites they like, features they’ve had in mind, etc. It doesn’t just give you a lot more detail for putting a quote together; it goes a long way in building the relationship (so you’ll be more likely to land the gig). And this is the best time to suggest better ways they can approach the project – before you’ve started.
If you can’t afford to do this as part of your sales process you might want to reconsider your business model. If your margins are so slight that you simply can’t spend any time getting to know the business you’ll be serving you’re either charging too little or your costs are too high.
Be tediously specific on deliverables
Writing proposals sucks. It’s a load of time you could spend doing something more engaging. And when you don’t land the job it seems all for nought. So the tendency to rush through them is understandable.
But the proposal, when you land the job, becomes your project – or at least the basis for it. And to run a profitable development project you had better have done a sound job estimating time/costs.
Why should you write detailed and customized proposals?
- It gives you a much clearer picture of the workload ahead (so you can be more accurate with your quote)
- It shows your clients that price is directly related to actual work (not some vague “web development package”)
- It gives you a place to argue from if you find yourself in the unfortunate position of approaching the client with additional costs when a project is already in motion
If you don’t nail down your scope with as much accuracy as you can you’re leaving holes. And these holes are where feature creep happens – those unspecified deliverables your client asks for that you simply didn’t anticipate.
No ticky, no laundry
Most clients will expect you to be flexible. And to a degree, you should be.
There’s no precise cost/benefit analysis here, but adhering to the letter of your proposals and refusing to budge, even for the small things, won’t do much to build your long-term relationship with the client.
That said, you have to draw the line.
If you find yourself bolting on functions and components you didn’t budget for you’re essentially working for free. And since we’re mostly selling time in the development gig, working for free doesn’t jibe with the business model. It hurts you.
Not to mention free add-ons devalue your time. If you give your clients the idea that the add-ons are no big deal, that they’re not costing you anything, don’t be surprised when they keep showing up with a few more features they’d like to tack-on to the new website.
Sometimes a flat “no” is the only right answer.
None of the above is revolutionary, but action is everything. I’ve seen projects run on to more than three times their budgeted time because the developer couldn’t draw the line. They’d given a few inches, then a foot, then two feet, and eventually they found themselves losing thousands of dollars on the project. Insane, but it happens – and if you don’t lay down the law early on it might happen to you.