The Importance Of Scope

In my recent post on Common Ground I mentioned the critical role that a thorough understanding of scope has on establishing common ground for any project or service team.  Given the criticality and the relatively low cost of defining scope you’d think that every project would do an exceptional job of doing it, unfortunately not.

Yesterday I had the opportunity to spend two hours working through the scope of a major activity at work, I was reviewing work that had already taken perhaps 20 hours to develop and based on my review needed many more.  It’s very rare to see even this level of investment in understanding scope, even though it would typically represent less than 0.001% of project cost.

This post is too short to do the justice to the topic, but I thought I would mention a few of the common mistakes that I most frequently see:

1. People assume that they already understand the scope, so they see defining it as something they need to do to just to manage change.  I have never found this to be true, a thorough understanding of scope will always require a lot of discussion and debate
2. People see scope as a list of items to be defined at the start of a project, rather than as a powerful tool to be used throughout the project as understanding evolves and new stakeholders are engaged
3. People think of scope as one dimensional – a list – rather than as a rich knowledge repository that can be filtered and queried from many different perspectives (scope must be defined in a spread sheet or database, never in a document)
4. Project managers think they own the scope, whereas I think Architects should, although it is really a team resource
5. People assume that scope can be defined in one way, whereas often at different stages in the lifecycle and for different stakeholders it may need to exist in various different (consistent) forms
6. People assume they should only list things that are in scope, often listing elements that are out of scope is incredibly useful in clarifying what’s in scope.  Out of scope items that are needed for success are particularly important as these might be dependencies, or customer responsibilities.

Once you have a scope though, what can you do with it, beyond the obvious use of managing change.  This list of endless, but a few examples are useful:

1. Check.  Every area of scope has been costed, architected, developed, tested.  Every area has an operational owner, has operational funding.
2. Custom Views.  For example list all areas of scope that impact security, that have training implications, are new, still need testing
3. Cross correlate.  For example which elements are implemented with which technologies, are developed by team X, operated by team Y, funded as part of project Z
4. Phase.  For example which elements of scope are being delivered as part of phase 1
5. Package. For example which elements of scope are included in the basic service
6. Clarify.  For example list everything needed for success that’s not being delivered by the project but needs to be funded separately by a customer
7. Map.  For example map a customers current state service scope to the planned future state, ensuring a common understanding of what’s new, what’s changing, what’s not going to exist anymore

To achieve these and myriad other uses though the scope needs to be carefully designed.  I will use for this example how to define an IT service offering:

1. List service elements that the owner of the offering is accountable OR responsible for.  These should be described in business terms, i.e. a customer should recognise the need to pay for them
2. Keep service elements at a similar level of granularity
3. For each service element describe the service features that comprise it that a customer will recognise.  Don’t confuse product/technology features with service features.  Service features have an associated service cost, product features come for free when you buy the product/technology.
4. Keep service features at a similar level of granularity but make sure that optional service features are listed and that you can distinguish between technology alternatives that the customer can select
5. Make sure that you can create end to end views linking together service elements and features.  For example create a filter that lists all the service elements that contribute to security, or all of the elements that are required to manage the lifecycle of applications.  These views should provide all the views that customers and key stakeholders will need

The picture is of the river Ribble that I walked along this morning in the sunshine while thinking about the meeting I was going to have today on scope.  I’m writing this post in Caffe Nero, not looking forward to the very chilly walk back along the river tonight.