Scope creep... some thoughts

A recent discussion randomly landed on the topic of Scope Creep in projects, which got me thinking. This article describes my personal thoughts on Scope Creep in projects, and why "adhering to scope" is inappropriate to measure success. In the spirit of full disclosure, I have never been a Project Manager or run a PMO. I have, however, been a customer of the process across a few organisations.

Every organisation has problems that it needs to solve.? These are usually one of: technical platform maintenance, product development, operational efficiency, or risk management.? Solving a problem requires a commitment of time, energy, and ultimately money.

Most organisations set about solving problems through projects which are started through some sort of artefact that describes:?

1. What the problem is
2. What needs to be done to solve problem
3. What it is costing (or could cost) the organisation by not solving the problem
4. What it will cost to solve the problem

This artefact is usually the “Business Case”.? The “what needs to be done to solve the problem” part of the business case is commonly known as the “Scope”.??

Typically the scope statements are written mostly by someone who is knee-deep in the problem space, and fights the challenges it creates each and every day.? The person writing the scope usually writes in a way that the reader will have a deep level of “presumed knowledge” of the nuances of the problem, which they often don't (and arguably shouldn't), and will often only cover the parts of the problem space that is currently causing the most pain (recency bias).?

As a result the scope suffers from being an insufficient description of what needs to be done.

Projects, once approved, are given to Project Managers to execute.? Good Project Managers are critical to the success of any project in any organisation.

The first activity orchestrated by Project Managers is to do a deeper exploration of the scope with the aim of validating it and adding detail such that something useful can be delivered that tries to solve the problem.??

The outcome of the deep exploration of the scope then becomes the “Agreed Scope” and subsequently the yardstick by which the outcome is measured.? After some further lightweight requirement exploration activity and design work, a detailed view of the resources required and the plan to deliver the outcome is produced by the Project Manager.? This plan will usually include work for even more detailed requirements exploration and design work.

From this point forward any work which is not aligned to the agreed scope is considered “Scope Creep”.? Traditional wisdom says that all scope creep should be rejected as it is not what the plan was based on.? If the scope creep is really important, it should go back to a stakeholder committee who will decide its fate.

This definition of scope creep is founded in the view that the reason for the work being done is now the somewhat rigidly defined project, rather than trying to solve the problem itself.

Fast forward to the end of the project when it has actually been delivered.? Success can be measured in one of two way.? The first is whether it delivered to the agreed scope, time, and budget.? The second is whether it made significant steps toward fully solving the original problem. I don't believe it can be both of these.

When projects are driven by rigidly defined scope, the success of the project is measured through whether it delivered on time, “good” effectively translates into upfront estimation being? accurate.

From this viewpoint, an increase in scope is sometimes subsumable without impact to cost, resources or timelines. This is not thought of as being a bad thing but also not a good thing either. The moment that additional scope cannot be included without affecting cost, resources or timelines it becomes a very bad thing, and certainly worse than just being over-budget on the agreed scope which is just bad planning and contingency management.

When projects are measured on their success in solving the problem, the “heat” is distributed quite differently.

From this viewpoint, what was considered a good result when rigidly adhering to upfront scope definition becomes a negative outcome when measuring against the original intent of actually solving the problem.

Success in this viewpoint is based around solving the problem, or even doing more than just solving the problem with the resources that were assigned to the work.

I would argue that the "good" in the original intent viewpoint is more valuable to an organisation than the "good" in the delivering to scope viewpoint.

This article doesn't discuss the domino effect this would have on how organisations plan resources and finances, and the effect on these two areas should not be underestimated.

Is it time to examine how organisations measure success of work done, so that it is moved from whether it did what the scope said, to whether it solved the actual problem?