There are not many projects in this world that have not faced Scope Creep at some point in their execution cycle. Whether you like it or not, most of us have to deal with Scope Creep in one project or the other.
Even I have faced Scope Creeps on some of my projects. As I dealt with them, I learned that there are some common reasons for these to happen and how I could have avoided them.
Since most of my career has been in designing web applications, today I am going to discuss Scope Creep in the context of developing web applications.
So lets begin.
What Exactly is Scope Creep?
By definition,
Scope Creep is addition of features or requirements to a product or project that were not previously scoped in or agreed upon.
When you start out building a web application, there are many things that you may consider, like what the application is supposed to do, what features it is supposed to have, how the user is supposed to interact with your application etc.
Once these things are finalized or agreed upon in your team or with the client, you formally document them and these form the scope of your project. These are the set of things that you have committed to build for the product or the client.
Your entire team starts working on the product. But along the way, one of you get a genius new idea that you think the client or the customers will love. Or the client gets an idea that they want you to incorporate into the project. This new additional feature or requirement is now to be scoped in.
This is what is called as Scope Creep.
Your existing scope has to now expand and accommodate the new feature or the requirement.
An Example of Scope Creep
In one of my projects, we were asked to develop a Content Management application that was supposed to store all the product data of the customer.
The application wasn’t a full-blown Content Management system as such. It was just supposed to enable the customer to save the product related data files, version control these files and send them for approval to various approvers.
We sat down with our client for understanding the requirements and after a few discussions the requirements were narrowed down to the following:
- Users should be able to upload all types of digital files
- All files should be versioned controlled
- User should be able to send the files for approvals
- Approvers should be notified that a file is awaiting their approval
- Approvers should be able to approve the files
- Once approved, the files should be marked as approved
- Each file needs to be secured. All files should not be visible to all users etc.
The actual requirements were a lot more than these. But in essence, this is what they needed.
With the requirements clear, we documented each of the requirements as a scope item and got it approved from the client.
We then created the initial wireframe of the user interface so that we could get that validated from our client. We detailed each and every step a user would have to take to upload a document into the application and version it.
The clients looked at it and liked it. “Just one minor change is needed.” said the client’s Project Manager.
“All of our employees use a single-sign-on for all of our applications. Your application also needs to use the same single-sign-on. We don’t want employees to create one more username and password to remember.”
Though technically the change was minor, we had not designed for it. Nor did we scope in the efforts to integrate our application with the customer’s existing single-sign-on service.
But since the requirement was something which we could not say no to, we decided to go ahead with it.
My development team being one of the best I had worked with; made good progress in the first 10 days or so on the file upload feature. Once the first iteration of the development was complete, we deployed our code on the test server so that the client could use it and give feedback.
The feedback was excellent from the client. But then, one of users asked why he was not able to compare the different versions of the files.
“Well, that wasn’t discussed earlier.” I said.
“But all of the versioning tools allow the users to compare the files!” said the user.
“Not all do that. This kind of a feature is quite common for repositories that store software codes. But you will be storing product data files which will be mostly 2-D or 3-D drawings, cost sheets, specifications etc.” I said.
“Yes, while that is true, one of our department that works on Embedded Designs do have some code files and even those will be stored into the application. So a mechanism to compare files is needed.” said the client’s Project Manager.
Since I had wrongly assumed that they will not store such files, I had to agree to look into this feature request.
After a few iterations, we were able to deliver all the features that the client wanted. But we had clearly exceeded our deadline and the overall project cost had just shot up sharply. We hardly made any profit from this project.
Though, I have just given counts of two such incidents where new features and requirements were added to the original scope of the project, there were a few more. The Scope Creep was substantial.
So, did I learn anything from this?
I did actually. Say “No” to everything once the scope is frozen 🙂
Jokes apart. Let us analyze the reasons for this Scope Creep.
Reasons for Scope Creep
Here are the top 5 reasons for Scope Creep to happen that I learned from this project and a few others.
1. Incomplete Requirements Gathering
Requirements Gathering is one of the most important phase in any product development. If you fail to gather all the requirements then the product is never going to satisfy your customer no matter how good the design is.
In the above case, I failed to gather the requirement to integrate our application with client’s single-sign-on service.
Though the overall impact was not much in my project, you might not be that lucky.
2. Incorrect Requirement Analysis
Once all the requirements are gathered, it is imperative that you sit down and analyze each and every one of them.
Understanding each requirement will help you to get a better idea of what needs to be built, how you can build it and how much efforts are going to be needed.
In the above example, I failed to analyze that the users might want to compare the versioned files.
This was not straight forward to analyze but there will be instances where you can easily figure out what all additional things would be needed by the users to work with a feature. For example, a feature that does not allow all users to access all files, need to have some kind of Security Roles and Privileges built into it.
3. Incorrect or Ambiguous Scope Definition
Many of the times, the scope is defined in such a way that it is incorrect or it is ambiguous.
For example, I could have incorrectly documented that the client just wanted to upload the files into the application without specifying that versioning was needed. Someone reading the scope would have thought that there is no need for versioning the files.
Or I could have documented that the versioning of files needs to be created for all of the product data files. This is ambiguous because now the person reading the scope document will not be able to understand what to do with the non-product data files. Should we version them or not.
4. Gold Plating
All of us have a tendency to just add that one more feature which will make our application stand out from its competitors. This is called Gold Plating.
We do it with the best of the intentions but ultimately it all adds up to increase the scope. And the truth is, most of the times those extra features add no value to our customers. But yet we never think of this.
Luckily, in my project this did not happen. But then that is not the case with all projects.
5. Changes in Business Environment
Business environments keep on changing and these can increase the scope of a project. Example of changes in business environments can be Tax Law changes, Labor Union functioning etc.
In one of the projects, we were building a Procurement application that was supposed to raise orders on the suppliers of the client so that they can supply the necessary raw materials.
During the development phase of the application, the client added a new product to their product line and now wanted the application to raise the orders for that product too.
We did not anticipate this business change to take place at the client’s end but ended up adding it to the scope of the project because it had now become a business requirement.
How to Avoid Scope Creep
There are a number of things I can list to avoid Scope Creep. But what I have learned over all these years is that there are only 3 things that you need to be good at to avoid Scope Creep or should I say, to control Scope Creep.
These 3 things are:
- Define
- Document and
- Control
Define
You need to be really good at defining every major and minor aspect of the product or project.
Define the requirements clearly, define the analysis of those requirements properly, define the scope of the project clearly, define the features of the product accurately and the list goes on.
The more you try to define everything you are working on, the better the clarity of the project specifications or product features will be.
Document
Definition of every aspect is not sufficient. You need to document these definitions too.
It is extremely important that you document each and every fine point that you can think off while gathering the requirements and jotting down the scope of the project or product.
The documentation not only needs to cover every aspect but should also be unambiguous to the person reading it. At a later stage in the development cycle, what you have documented comes in handy to refer back to.
Control
Definition and Documentation will go for a toss if you do not control the scope actively in the development phase.
Resist that urge to add that one groundbreaking feature if it was not part of the original scope. Discuss with the customer that what is being asked now is an additional feature and you will run into the risk of delaying the project.
The Control phase takes a lot of soft skills to negotiate with your clients and your team.
What If Scope Creep in Inevitable
Lets face it. Everything that I have just said to avoid Scope Creep sounds good in theory. But practically, it does not always work out this way.
Your client might keep insisting that the new feature or requirement is extremely important to them and that they are ready to delay the project if you can accommodate that one thing for them.
In such cases, it is better to create a Change Request and track such requests separately.
Even while writing the Change Request, make sure you define, document and control it properly. Otherwise the Change Request will also face a Scope Creep 🙂
Over to You
I hope you have now fully understood what Scope Creep is, why it happens and how to avoid it.
So the next time your product launch or project gets delayed do not be surprised. Scope Creep just might be the cause of it.
Have you ever faced Scope Creep? I would love to hear your story. Do let me know in the comments below.
And as always, if you have benefitted from this article, do share it with your friends. I would really appreciate it.
