Webreakstuff's blog on design, development and strategy. Click here to subscribe.

Web applications: Fight scope creep

Fred Oliveira on February 6, 2006

Building web-apps One of the most important parts of building an application is actually just that - building the application. It follows that particular attention should be given to the process of planning and elaboration of a timeline. Many projects take longer than expected to complete, with never-ending iteratings and constant adding of new features. Ever wondered why that happens? Keep reading.

From an idea to development

You have a great idea, you want to make it into an application. You have a stable picture in your mind of what you want the application to accomplish. You gather a team to build it. You try your best to make sure the picture you have in your mind is passed on to everyone else on the team. You fail, problems ensue.

The planning stage in a development process is constantly overlooked. People assume (particularly in a start-up, loose environment) that planning is unnecessary, a waste of time or (and this is extremely frequent) something that can always be interleaved with development. Truth is, this sort of behavior leeds to the developer’s worst enemy: scope creep.

Defining scope creep

Here’s Wikipedia’s definition of scope creep, as of this writing:

Scope Creep (also called “requirement creep”) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, and controlled.

Typically, the scope increase consists of either new products or new features of already approved products. Hence, the project team drifts away from its original purpose. Because of one’s tendency focus on only one dimension of a project, scope creep can also result in a project team overrunning its original budget and schedule. As the scope of a project grows, more tasks must be completed at the same cost and in the same time frame as the original series of project tasks.

Fighting the bastard

Fighting scope creep is quite simple, really. Plan, plan, and plan. Make sure you (or your team) and the client know what the intended purpose of the web application is, and that you agree on it - to the finest of detail. Make sure your vision and the client’s vision is one and the same, not the intersection of one-another.

Vision

Remember that a project must be built in close connection and discussion with a client, whoever it may be. In fact, even if you’re doing something for yourself, make sure you don’t ask yourself about new features. You’re not experiencing a multiple personality disorder: it is innate for humans to wonder about the “what if’s” of development all the time. “What if I could add this super cool feature?” - Say no, even to yourself, if saying yes will be walking away from the vision.

Putting it together

In sum, scope creep delays projects, messes project budgets, diminuishes developer productivity and ruins client satisfaction. Fighting it is simple - it requires planning, prior to writing the first line of code, to make sure the vision of the application is the same for client and implementor. Agree on the features beforehand, and aim for the same goals. Do it right, and it wont bite you in the butt.

Remember to say no, keep your vision in focus and don’t allow it to blur with “what if’s”. You’ll build better, tighter applications - and you’ll be happier doing it.


Comments on this post

Fredrik

At my company we often do the exact opposite; we welcome and embrace the scope creep as one of our own.

The reason? We get paid by the hour, and the more hours we can sell the more money we can make from the project. When the client says “What if I could add this super cool feature?” we reply “Of course! (we’ll just put it on the bill)”. We just have to make sure to allow for extra development in the original enquiry.

There are obvoius drawbacks though; you must be pretty tolerant as a developer because your project can change at any time, plus it messes with your time planning. It has happend a few times that I just have had to throw away the past week’s work and start from scratch because a major change in the project definitions has just arisen.

So by embracing the scope creep you can potentially make more money, but at the cost of a loss of focus and an increased risk of delayed deadlines.

Francis Dupuis

I have a little dragon that we call ‘Screep’ that gets awarded to the person who is doing their best to scope creep a project. It sits on your monitor peering down at you as a reminder that as much as we love features, we also love shipping product…

Jess

Fredrik, I see your point, but what about client satisfaction? My experience is that clients come with all sorts of weird ideas and the more you say “yes, ofcourse” to these ideas, the more the client will think that they are geniouses at coming up with ideas. And hence a badder application. When a client comes up with a new idea for the application I really consider the value of that new idea. And if I come to the conclusion that the addition would be bad for the end product I advise the client not to do it. After all, we are the experts, not the client.

Fredrik

Jess, you are right! Clients often come with some bad ideas, and that’s why it’s so important for us as developers to maintain a good relationship with them. If they trust our expertise we can often reach a mutual agreement through discussion. The fact that the client comes with a new request probably means that they feel something is lacking or should be adjusted. If we analyse the reason behind the request we might be able to pick up something we hadn’t thought about.

I suppose it’s the friction between the client’s and the developer’s minds that creates great applications (or something) :)

Nickster

Jeez, have you guys never heard of Agile development?
Planning, planning, planning is all well and good, but in all businesses, things change. Plan everything you like, but I guarantee that in 1 week, 1 month or 6 months something will change and all your careful planning will turn out to be a waste of time.
There’s a great military maxim I end up quoting (probably too much):
No plan survives contact with the enemy.
So, accept that change is part of the business of application development and use a methodology that can deal with it - an Agile one!

Fred

Oh, but you’re right, accepting change is necessary to cope with clients and delivering projects - because you can never assume you’re 100% right at the first try.

Still, there’s a fine line between what’s valuable change and change that could be avoided, though - and even agile development (which I’m an advocate and practicioner of) needs a variable amount of planning depending on the project. Thinking otherwise is a grave mistake.

Francis

I think far too many people get agile and ad-hoc development mixed up. Agile (which we use) is about delivering functional software…something that scope creep can impact.

hermeshandbags

Marvelous. Thanks, will spread this among my friends!

Something to say?