Scope creep – the surreptitious phenomenon that plagues so many software projects (and any other project as well). But so many times it cannot be avoided. Best practices dictate that to avoid this it is important to sign off on a scope baseline before development starts – where both parties (supplier and customer) have understood the scope as of that point and they have understood what each other has understood! Following that any change to scope is accounted for and one or both of the other 2 constraints of a project, cost and time, are updated.

But real world is not as copybook as that!

So many times a customer does not realize that something very crucial is needed in the scope unless they the end product or a pretty close prototype of the end project. In some cases the project does not even make sense without this feature/need. Or, something new has changed since the project got started and now new features or changes are needed to the original scope to make everything work. Most development companies will say “sure we can do this but it will be change requests and cost an additional X and/or the timeline will get changed by Y days.” For the innocent customer, who really had no control or idea at inception, this could break their budget, bank and eventually lead to a failed undertaking.

One may argue that agile methods could help. But agile is a methodology, a culture and does not provide guidelines to this issue. Some may say that a well drafted contract will help – but how does that make the project successful when there are cost or schedule overruns or the developer is choked by a demanding customer?

Well here are a few points that could help!

(1) Discuss upfront about scope creep with your customer. Talk about how it can affect the project constraints (scope, cost and time). Having a separate discussion topic about this can go a long way in the end.

(2) When scope increases and it is important to stick to the planned schedule, the increased scope can be handled by crashing the project with more resources which increases cost for the developer. Keeping a project reserve upfront is a good idea. Why not make it transparent to the customer? “Let’s keep 10% of the total budget as a reserve in case scope changes midway.” Most professionals will like that rather than sign on a gray line!

(3) You may already be doing agile developments with multiple release cycles. Sometimes it could be possible to move some of the changes to a phase 2 or a version 1.5. It can buy some time which allows for better planning.

(4) You might be able to trade off some scope (what?) – yes let me explain. You may be able to have some involvement from the customer’s in-house resources in the development. Of course this needs to be agreeable by both parties and planned carefully and any risk should be managed accordingly. But there are advantages. For one, the customer is part of the development and there is more buy-in by end users when they are part of the creation! It also helps to balance the workload.

(5) From the customer’s standpoint, if the budget is not stretchable and scope needs to increase, they could transfer some of the extra cost incurred by the developer into a future project. In such cases funds may be released as an advance on the next project. It is not the best of situations, but when a project is near completion and there is a deadlock, it is ok to be a bit creative! Similarly from the developers standpoint, if costs need to be contained, they could revisit the original scope and see what can be shaved off for the current project.

The reality is that scope creep is difficult to avoid. But how we manage that is the game changer. In the end it is not about winning – it is about delivering a project that is successful in the eyes of the customer.


Roni Banerjee

roniRoni has 16 years of experience in leading small to large scale IT projects for various markets. Roni successfully founded 2 companies spanning multiple locations and time-zones. He rolls up his sleeves and gets into software development anytime you ask him and database development is his passion – we call him “our sequel junkie”! Roni has a Bachelor’s in Engineering, his very valued PMP and is close to finishing his Global MBA from the coveted Warwick Business School in the UK. When asked about his personal life he says “We, my wife and 2 boys, live in the picturesque Hudson Valley region of New York. A Yankees and New York Giants fan, I also enjoy strumming my guitars every day, mixing recipes from different cultures when I get some time and hack away during an occasional round of golf.”

Write a comment:

Your email address will not be published.