Scope creep affects each area of a web project; the team paying for it, the team building it, the team managing it, etc. When the requirements change and hours get tacked on to a pre-estimated project, tensions rise because one team paying for the project doesn't want to pay for those extra hours, while the team building it doesn't want to work for free. But what if there was a way to control scope creep and even use it to create a better product?
"It's a bad plan that admits of no modification."
~ Publilius Syrus
What is scope creep?
Alright, so let's define scope creep for a second. It's best defined as when over the course of a project, requirements grow and change, and there are unexpected additions requested. The problem is that your 30K redesign can turn into a 60K redesign.
It's caused by poorly defined initial requirements, changing requirements, poor communication, etc. The list could go on, but one commonality they all have? It's because of lack of control and direction.
It doesn't have to be a bad thing though. I think that only traditional web design won't allow for it. You have a fixed budget on fixed features, but things change. You begin to realize that some features you thought were needed actually won't have any effect on engagement or UX at all and other new ones might.
So the real problem?
It seems that the traditional web design model just isn't built to consider updates until after the intial requirements are completed. In this case, you're either stuck with the pre-estimated hours and whatever they will give you or you have to pay extra for a pivot.
Avoiding some of the negatives
I'd say to best way to avoid the negative of scope creep would be to create a retainer model. The purpose of the retainer model is to create an ongoing relationship and make continuous improvements to the product. So if new ideas come up the hours will be allocated to the monthly budget.
This helps the designers/developers receive consistent compensation for the hours they are putting in, and the client won't over pay for additional hours.
How can scope creep help a project?
When building out a strategy for your website, you'll probably do a lot of thinking on who your personas are and what journeys they will go on. Ideally, in this phase, you'll create a requirements lists and rank each piece. How does each feature or requirement affect how the visitor will engage with the site? Does it actually made sense to have that feature?
I see scope creep as just the evolution of a project. After seeing how users begin interacting with your site, you can make educated decisions about how your requirements will change. The keyword here is educated decisions. If you plan on changing the requirements, there should be some form of data backing that decision. Those subjective changes are what end up stressing everyone out.
I think the most important point I'm trying to make is that things, plans, and requirements change. It's happened it past projects, existing projects, and it will probably happen in the future too.
Want some tips on creating a better redesign strategy? Click the image below.