How to love changes – 3: Scope

< Previous: How to love changes - 2: requirements

In my first post on how to love changes I introduced my tiny process model. In the coming posts I will dig into each of the elements that lead the way from business needs to progress reporting and how to build confidence into project execution.

Scope

If I should designate a single cause of project failure it undoubtedly will be the handling of Scope. If your interpretation of Scope is wrong, all the following steps in the planning process are worthless: Estimation, Sequencing, Scheduling and Control.

Actually it is worse – the following steps are not only worthless; They are dangerous because one might think the Plan is correct and as there is no other Plan, people tend to run the Project by it – pretending they’re in control.

It is like sailing a boat heading for unknown harbor; what good makes a route on a chart then?

What is scope anyway?

The term ”Scope” is difficult. What is it exactly? Is it what the customer (think they) requests? Is it what we build or is it just a guideline of what the project should deliver?

Project literature often leaves this question unanswered. Like “Scope” is self-explanatory.  It is not. Unfortunately, project managers by nature rarely admit that they do not have a clear view of scope and how it impacts the project.

It’s a shame, because it is vital for project success and it is quite simple to understand – but hard to manage.

Here is my take on Scope:

• The customer/project owner has a need to be fulfilled. He does not know how to express this need, so he tries to fence it by making constraints – called: Requirements.
  
• The project team interprets these needs into something that must be delivered in order to achieve the desired change that leads to fulfill the needs of the customer.
• Everything the project has to produce in order to deliver the desired change – is Scope.
• We decompose Scope into smaller manageable sub-projects or products. Each and every part are estimated on cost and duration. Each part of the Scope will be known to some extend and estimated with some uncertainty. This list of products is called Work Breakdown Structure (WBS) or Product Breakdown Structure (PBS) and each item should be uniquely identifiable for traceability purposes.
• When every product in the WBS/PBS are delivered; the Scope is fulfilled and the desired change are implemented. This implies that the constraints (read: requirements) are met as well. The project is now finalized.

In short: Scope covers whatever you need to work on or deliver in order to provide the value expected from the project. "Whatever" also covers leadership, meetings, documentation, 3rd party products, interfacing systems, data migration, establishing customer support and educate staff personnel  - if that is needed to provide the value desired in the business case.

Everything in your project that requires working time or cost are part of your scope. Every change in your project environment are changes to your scope.

What level of scope is desirable?

It is hard to outline a specific desired level of scope definition as each project is different from another. Sometimes the customer/project owner is reluctant to share information or simply is unaware of what they need, and in other projects one could get almost too informed about needs and requirements (read: constraints) that overwhelms the project manager.

Some say that scope should be broken down to one or two weeks of work, or one sprint. PMI states diplomatically that it should be at the lowest manageable level. It really depends of the situation, the information available, and the level of delegation of trust, the desired project model and experience of the team.

You should really challenge your level of detail in your planning. At what level are you going to control your plan anyway? Does the detailed level contribute to project success - or could you delegate responsibility of the task to the people assigned? It's up to your level of confidence in your team. Take an active decision on the value your level of control will give.

It is more important to manage a higher level of scope than having a really detailed level of scope out of control.

Scope control is you major concern

In case you actually succeed getting hand on the scope in a manageable level, you are just started. Usually projects fail soon after - or in the process - of scope definition as changes occur. Typically 25% of the scope will change during the project so design your setup to manage changes!

Protect the scope definition (that is your breakdown structure – PBS/WBS). Hire a Configuration Manager. This role is by default designated to the project manager, as this is the single most important thing to have in control. If someone is fiddling with your scope, they have the hands in your pocket – ruining your budget - and by consequence your project success.

Also remember that every kind of change is a change of scope. Changes to the contract, payment terms, and acceptance terms, meeting interval or change in organization or reporting – are all changes to the project. They all cause extra time/cost in adjusting, changing behavior, risk or extra work. Control it and include it in the project scope as products that must be estimated, planned and produced.

Summary

Scope and change management is your major concern as your budget and plans rely solely on it. Usually Scope is inferior defined; hence, the plans and budget are inferior as well!

It is more important to manage a higher level of scope than having a really detailed level of scope out of control. "Control" is the work you do understand, define, verifying and controlling progress of the scope element (product) to be produced.

Everything in your project that requires working time or cost are part of your scope. Every change in your project environment are changes to your scope.

> Next: How to love changes - 4: Flow sequencing