Setting Scope in Dimensions

Scope definition is the most contentious, and most useful, of a BAs tasks early in a project. It's a key part of mitigating the project's risks by promoting consensus on aims.

 

Personally I'm most happy when I can promote disagreements over scope within a project. Too often people are using the same language to say two different things, and do not realise there's been a disagreement until too late. A disagreement is proof that I've been successful in bringing this misunderstanding to the surface early, so it can be dealt with during initiation instead of implementation.

 

My favourite way of doing this is by describing scope in three chunks:

• In-Scope: My responsibilities as a project
• Out-Of-Scope: Things that will not be delivered or considered
• Dependent-Scope: Other people's responsibilities, that my project relies on

 

Out-Of-Scope is In-Mind

 

The best way do this is in the out-of-scope section. It's really the only scope section worth mentioning. Seeing a chunk of scope as explicitly out is much more confronting than it not being explicitly included. It's for wishful thinking to take over, and for stakeholders to see what they want "in-scope" if something related is also there, the out-of-scope section removes this false comfort.

 

In Your Scope is Out Of Mine

 

Dependencies on other projects should also go in the scope section. Theses are essentially things your project will not deliver, but is expecting others to do. Inviting the responsible parties from these projects to sign-off on your scope is an opportunity to get disagreements sorted early. Nothing focuses the mind like having to put pen-to-paper on a document that explicitly says what you are responsible for.

 

Multi-Dimensional

 

Explicitly structuring your scope statements around which 'dimension' of scope they refer to can make your scope clearer, encourage you to think about the projects in different ways, and make a point unavoidable by restating it from three or four different angles.

 

Each "dimension" of scope is a single narrow class of items that may be in or out of scope. I've listed a partial brain-dump of the dimensions you could use below.

• Problem: User issues to address or ignore
• Functional: User facing features that are included or excluded
• Non-Functional Requirements: All non-functional requirements can be part of scope, either as area we are targetting to improve, or where we make no promises. (Note that I'm a big fan of phrasing these as negative NFRs - things we can do without is what drives intelligent compromise.)
• System: Which technical systems we are responsible for, or will not change
• Interfaces: System interfaces or integrations that we take responsibility for changing, or normally rely on others for
• Activity: User activity or tasks considered, or ignored (Useful as part of a process when you highlight activities to automate or stay manual)
• Users/Customers: Which user bases are considered, and which excluded
• Organisational: Parts of the organisation whose issues and needs are in scope - very useful when deciding stakeholder and interview lists.
• Legislative: Which parts of law are to be complied with, or whose compliance is a main point of the program
• Deliverables: What documents, sing-offs, or artefacts are included
• Detail: How much details (Descriptive vs Prescriptive) will be included
• Supporting: Which activities or systems will be able to function based on our delvierables. This one's quite useful to say you will produce just-enough to support a particular activity or example (say, estimation) but not enough for another (say, full-build)