what's on our minds

Avoiding Scope-creep on Web Projects

Scope-creep is when requests for changes or additions grow outside the requirements and price of the original project agreement. Website projects are the most susceptible to this. It can be simple as extra pages or complicated like adding a login area. The resulting problem isn’t just financial, but often delays. Why? And what can we do about it?

Just the tip of the icebergReason 1: Technical Misunderstandings

When working on the original outline of the project you should discuss specific functionalities to include. Most of us, as website users only see the front end and don’t understand much about the magic behind the scenes that makes it work. Like an iceberg something can seem deceptively simple on the surface, but there’s a lot underneath. There’s often more than one way to do things, and your web developer will choose and plan out the approach they think most suitable. If the client changes their mind on what they want, or either realizes the solution doesn’t quite do what was wanted, changing tack midstream can mean redoing a lot of work.

What’s the answer? Do your utmost to ensure both sides are clear on what’s wanted and what it will actually be. Understand the difference between behind the scenes and user experience. Use examples and demos where possible, explain it to each other like your three years old (especially when alternates are suggested).

Reason 2: Unclear Expectations

I could repeat all of reason 1 here, but unclear expectations aren’t always technical in nature. Who’s supplying the copy? Who’s responsible for proofreading and testing? What has to be finalized before we start the next phase? What will you be able to edit or not? We are posting a video for you but do we need to edit it at all? What’s the schedule and what do you need from whom when to meet it?

The answer to this is much like the previous. However, I would expect your web company to take the lead on setting expectations as they’ve been through many web projects and have probably encountered and learned from expectation problems. They have an m.o. for running these projects. The client may have only been through this once or not much more than that.

Reason 3: New Ideas Come Up Along the WayIdeas come up along the way

As we design, write and develop websites either side may discover possible additions or see opportunities for improvement. This can be great and doesn’t mean it was wrong not thinking of it in the first place. Just remember it may add to the cost and time. As mentioned in reason 1, it may be deceptively simple on the surface, but tricky to execute.

The solution? Estimate cost and time to add the idea and make a judgement call. If it doesn’t seem worth the money or the delay – put it on the Phase II list. The beauty of websites is you can continue to improve and expand!

Remember, you’re on the same side.

Both sides of this deal should try to avoid scope-creep from the beginning by clearly defining deliverables and expectations, and should define in advance how to deal with scope creep should it occur. Sometimes the technical explanations can seem like double-talk, but your web developer should explain it in plain English. If it does happen partway through be understanding, talk it through and work together to solve the issue.

This entry was posted in Building Rapport, Online Strategy, Web Development and tagged , , , . Bookmark the permalink.

2 Responses to Avoiding Scope-creep on Web Projects

  1. Ian Sharp says:

    Business surveys have found that 41% of IT projects failed to deliver the expected business value and Return on Investment. Not the mention 49% of projects suffered budget overruns.

    I think that getting the requirements right before you start is of utmost importance but it is a skill in itself and easy to miss important aspects. Not involving someone with the experience and skills to do a thorough job of documenting, then assessing and prioritising the requirements can lead to serious omissions in the scope of the project. Not that the scope can be perfect and never change, but the quality of defining a project scope can obviously vary.

    I do have a concern with letting a web company set expectations and therefore potentially influence the scope. I believe the requirements should be owned and driven by the business and not a web company. The web company have the technical expertise needed but are not best placed to define what your business is trying to achieve with your web project. I’ve researched and written about scope creep and the reasons behind it, and I would be wary of relinquishing too much of the definition of scope to a third party. Whilst they should be keen to ensure the success of the project too, they also have a an incentive to generate work for themselves. Therefore I would recommend caution with allowing a web company have too much influence on the scope. As with any supplier, you need to know at least enough about the web project to keep them honest otherwise at least be aware of the large amount of trust you are placing in the vendor.

    Web projects these days are key component many businesses and I would advocate that the business owns the requirements and primary responsibility for the success of a web project. If they feel like they do not have the appropriate skills, its not too difficult for them to acquire them.

  2. Thanks so much for your great thorough comment Ian. I agree what you mean about the requirements being owned and driven by the business over the web company. What I meant was that the web company would have more experience in things like processes and common sticking points. For example I know that content generation always takes longer than the client thinks and often changes the site architecture as it’s fleshed out. It’s my job to make sure the knows what to expect, schedule enough time, not jump ahead to building when I know the site chart is likely to change, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *