Ask any project manager the reasons why projects fail and one of the reasons cited will definitely be scope creep. But is scope creep really that bad? I don’t think so. Your view of the scope creep will depend on how you manage projects. You can manage projects as a contract or you can collaborate.

I think there will be a scope creep when there is a contract between the solution provider and the consumer. For example, it is notorious in the construction industry. In fact, some contractors want the consumer to change the scope in the middle of the project. That’s their way of making money; it is not like you are going to change contractors in the middle of the project. But if both parties collaborate, then scope creep as a reason for project failure just melts away.

How you define project success

How do you define project success? If your answer is, “a project that is delivered on scope, on budget and on schedule is a successful project”, then you will also be inclined to state scope creep as one of the reasons of project failure. You will also be inclined to undertake the requirements gathering and design exercise upfront. Once the design is done, you will then agree with your customer on the scope, the budget and the schedule. This is a contract. You will also be hesitant to change the scope and will attempt to push back.

The customer on the other hand knows that they will get one chance and will load the solution with features that they may not immediately need. “Who knows when we’ll receive further funding for this project. Let’s load it up with all the features we think we will need”, so the thinking goes. In pursuit of certainty, such contracts using big design upfront drives unintended consequences.

Collaborate. Don’t Contract

The win-win alternative is collaboration. If we think about it, development time is the biggest constraint on projects. We only have so much development time and we need to make the most of it. Adding people to increase capacity is expensive way to boost throughput. You can discover capacity you did not have by being smart about what your team works on. Collaboration entails significant amount of trust between the customer and the solution provider. Lack of trust causes collaboration to break down and we’ll revert back to contracts. Let’s see how collaboration is a win-win situation.

When a project is being proposed and a business case developed, a high level budget is created for the project. One of the variables to take into account while preparing this budget is the “cost of delay” – not ROI, not payback, but “cost of delay”. Cost of delay was introduced by Donald Reinertsen in his book, “The principles of product development flow“. In simplistic terms, there is a cost to not having a product feature at this very moment. Every day we delay its deployment, there is a cost to the business. So there is a trade-off between money (lost revenue) to cycle time. I would recommend reading this book for more insight into cost of delay.

Feature Prioritization & Order of execution

So we now have a budget taking into account the cost of delay. Needless to say, the budget should be lower than this cost of delay for a given time period. With this budget, the project team (includes customer and solution provides) ranks the features in the order of importance to the cost of delay. Features that reduce cost of delay will rank the highest. The team then starts tackling each feature until either the budget runs out or all the features have been completed.

You will notice that the customer team now has the ability to change scope and priorities as new information becomes available during the project. Since we are now collaborating, there is no such thing called scope creep. Everyone is working towards one goal – work on features that significantly reduces the cost of delay. The project success criteria is no longer on scope, on time and on budget. The success criteria now becomes, “deliver a solution to the business that has the maximum impact to the cost of delay” and everyone is working towards that one goal.

Due to this collaboration, the customer team is involved in the decision making process in every step of the way. They can see the impact of scope changes immediately on their budget and their delivery dates. With this approach, you encourage project funding based on a venture capital model. More on this later (another post).

The exceptions

As with everything, there will always be situations when this approach will not work. There are situations when big design upfront is the way to go. There is significant costs of not deciding on the design upfront, like building a bridge for example. However, most IT projects are not like building a bridge. We can afford to delay decision on the design and prototype. Cost of design changes are quite minimal in most IT projects.

In conclusion, going back to my original point about scope creep, remember if there is a contract then you have to worry about scope creep as a project manager. With collaboration, you deliver scope that drive the maximum value to the business. The best part of this is, not all scope needs to be decided upfront. As new information becomes available the team can add, remove or modify scope.

This collaborative process needs a project management and execution system that is tolerant of changes. In my experience, the Kanban board is one good example of such a system that will enable you to deliver the scope while modifying it as new information becomes available. With such a system I say, “Scope creep? Bring it on”.