Scope creep

When you are a developer chances are somewhere along the line you encountered scope creep.

What is it?

Scope creep is when you work on a program for a client and the client keeps requesting additions or changes that go out of the scope of the original plan for the program.

This is a problem because when the development of a program starts the requirements are already specified and the quote / price for the development has been accepted and was based on the requirements of the program. When a client requests additional functionality that is not included in the price, it requires more hours of development, thus you or the company loses money on the project as more hours were spent on development than were originally quoted for.

This is not only a problem when it comes to programming but also any type of digital service like graphic design for instance.

How to minimize it?

For the Programmer:

Always start with planning. When you get the requirements for a program from a client create a detailed document of that functionality the program will have and when I say detailed I mean detailed. Every click of a button, every text area that will display a result or data, what data will be displayed and so on.

When the client is happy with the requirements document. That requirements document will then be the scope of the project. Compile that document with a / the contract and state very clearly that any additional requirements / changes that goes out of the scope of the requirements document will be billed accordingly dependent on the time it takes to implement the changes or new functionality.


A question that arises out of the above mentioned is, "How do I know how long will it take to program something?"

The answer to that is, no one can give an exact time of how long development will take. After 10 years of experience even I can't give an exact time frame of how long it will take to program something.

The best way to try and approach this problem is to break the program into smaller segments, each segment can then be "guesstimated" (In case you are not familiar with the term, it is guess and estimate/ed combined) on how long it will take to develop. Count them all together and you have a guesstimate of the entire project.

If you are someone who just started out and still need to get a feel for how long it takes you to develop something, a good way to calculate it is, guess how long it will take you and time that by one and a half (1.5) when it comes to smaller pieces of the program. The larger the piece the more you multiply that time with. Sometimes it can go as high as four times the original guess. Sometimes you might take a little longer than you guessed and sometimes it takes allot less time. In the end, the whole project quote will be close to the quoted price for the time allocated.

For the Client:

If you are a client and interested in helping preventing this, the best way is to be clear in what you want out of the system from the start. Plan every detail and describe it in detail to the project manager.

Just in case you might feel taken advantage of after you read how development time is calculated. There is no need to be alarmed and think the programmer or company is taking advantage of the situation. In the 10 years I have been a commercial developer of custom systems there has not been one time a project was over estimated.

Hopefully this was helpful in your future endeavors.