Out Of Scope:Defining different types of scope and their places in a project

woodenBuilding the wooden box

To make a wooden box go to http://www.wikihow.com/Make-a-Wooden-Box (“How to Make a Wooden Box”) and follow the 8 steps:

  1. Choose the wood.
  2. Gather your supplies.
  3. Measure and mark your boards.
  4. Cut your boards, if not already to size.
  5. Assemble the side pieces using a butt joint.
  6. Attach the sides to the base.
  7. Attach a hinged lid to the box.
  8. Fill in any nail holes.

 

Has he gone crazy I hear you ask? Some would say yes but that’s a different story for a different day. Bear with me for a moment. It will make sense, I assure you. Please keep the analogy of the carpenter and the wooden box in the back of your mind as we discuss out of scope and in-scope.

There are two places in a project where scope is defined. High-level scope is defined in the project charter. Low-level scope is defined in the business requirements document.

High-level scope consists of two main elements:

  • Deliverables: Defining your deliverables goes a long way to defining the overall scope of the project.
  • Boundaries: Boundary statements help to separate the stuff that is in scope and out of scope. Examples:
    • We will implement the CRM solution to the Irish geographical region and prove it there before implementing it to the UK geographical region once it meets certain criteria.
    • We will implement a change control model for the Lunar programme and perform a cost/benefit analysis before implementing it for all other programmes.

Back to the carpenter and his wooden box for a moment. Imagine the high-level scope as the wooden box with the outside sides of the box as the boundaries separating what is in-scope and out-of-scope and the inside sides of the box as the deliverables of the project.

Oh, how I hate using phrases like generally speaking or typically but needs must. Generally, once the project starts there are not a lot of requests to change deliverables or boundaries. Most of the change requests are changes to the business requirements.

 

Filling the wooden box

The business requirements help to define the detailed scope from the high-level scope.

We spoke about the inside sides of the box being the deliverables of the project. Business requirements describe the details of these deliverables. Let’s use our analogy again? If the scope is the box with the outside side of the box as the boundaries and the inside sides as the deliverables, the requirements are what you fill in the inside of the box.

There are two types of requirements:

  • Features: these are the characteristics of the deliverables. If you were building a bridge this might include the number of vehicles that the bridge can hold, the strength of the steel, the length of the bridge, the weight that the bridge can hold.
  • Functions: this describes how people, things, stuff interacts with the deliverables and how the deliverable interacts with other deliverables. For example, a financial batch process for processing transactions and within it how billing transactions are processed. In the context of these billing transactions how people input the data into the system to complete an invoice. In this example, we are referencing process, functions and people.

If you remember how the pieces of the box fit together, you’ll have an easier time defining the scope of your project and what’s out of scope for your project. You’ll also build a really nice wooden box for keeping stuff in.