Scope Creep | 5 Tips for a Successful Web Project, Part I

Written By

builtmighty

Reading Time: 2 minutes

As a business owner, engaging a provider to create a new website, design a web app, or make modifications to your existing site can be both exciting and and overwhelming. Site owners can help their projects run more smoothly by keeping the following 5 things in mind:

Understand what Scope Creep is and how it impacts your project
Consider that writing your own content might be harder than you think
Assign a single point of contact for communication/decision making
Make a plan for acceptance testing
Figure out Hosting, Domain Registration and SSLs

Today, we are going to talk about a big one: Scope Creep

At Built Mighty, when we provide scope and design documents, the information in those documents goes hand-in-hand with providing a blueprint for what our team will deliver, as well as the cost and time required for those deliverables. However, a feature set can morph over time. When clients suggest new ideas, that means adjusting the scope of the project with a Change Order. Every time a client requests a change, the following events might occur:

The development team stops their current work to quote the new work
A Change Order is written and sent to the client
Stop Work continues until the signed changed order is received
The Change Order is signed by the client and returned to the agency
Developers may have to undo previously coded work
The delivery date for the project is extended
The price for the finished product goes up

How do you keep scope creep out of your project?

Take the time to share design documents with other stakeholders to get the best possible review and feedback before your development team starts coding. Before diving into the project, think about your long range plans. Ask lots of questions, ensure that your vision is clearly communicated, your problems are addressed, and all your bases are covered. If you don’t see something you need on the Design Doc, speak up!
Whenever possible, defer changes until after the primary objective has been accomplished. Once that’s done, then start talking about new features for Phase 2!

Limiting changes during a project means that your development team is more likely to deliver your project on time and maybe even under budget.

Next post in this series: Writing Your Own Content Might be Harder Than You Think