PostHeaderIcon Defining Scope using Deliverables

The Whole is the Sum of its Parts

The Whole is the Sum of its Parts

Project scope is most frequently described in a narrative format, often termed a scope statement. While this may convey a broad sense of what the project will set out to accomplish, a narrative alone runs the risk of being at best insufficiently detailed and at worst ‘fluffy’ and incomplete with all the inherent dangers of ambiguity (see Ambiguity Kills Projects).

3 Steps to Clarify Scope

An effective definition of scope needs to include a formal description of the project deliverables. These are the primary outputs that result from the work performed – what will be there at the end of the project that is not there at the beginning. There are three steps to describing the deliverables completely:

1 – Identify the Major Deliverables
What are the largest, most significant outputs of the project?
These are the major deliverables, that when combined, should comprise ALL delivered outputs and reflect the full scope of the project. Since deliverables are “things” they should have noun or noun/adjective titles, e.g:

Release-Ready Software  |  Prototype Hardware  |  Trained Staff  |  Assessment Report etc.
– they are not activities with verbs (those will be defined later in the WBS).

2 – Describe Deliverable Features and Exclusions
What exactly will be delivered? What will not be included?
The Is/Is Not technique is the best way to define deliverable boundaries, by capturing the attributes that a deliverable “is” (or includes) and those that it “is not” (or does not include); e.g. for a deliverable “Business Model Analysis Report” we might have:

IS – Current marketing assessment, Competitor analysis, Customer needs study, etc.
IS NOT – Plan for an alternative business model, Supplier capability study, etc.

3 – Define Deliverable Completion Criteria
How will you know when the deliverable is finished?
These criteria are crucially important (see Completion Criteria ensure Done means Done); aligning expectations up front among customer, stakeholders and team will avoid painful conflict later in the project. For example:

– Six copies of report in spiral-bound hardcopy provided to Steering Committee for review
– Key findings presented in PPT format to Executive Management in a half-hour briefing.

Bridging the Gap between SOW and WBS

Deliverable descriptions make for sound scope management and effective change control. They exploit and enhance the Statement of Work narrative to provide real benefit in several ways:

  • Give the project scope some solid structure
  • Align expectations among stakeholders
  • Establish the basis for customer validation of outputs
  • Bridge the gap between the initial scope narrative and the detailed WBS
  • Help ensure that all WBS tasks are comprehensively identified (e.g. completion criteria will often point to needed WBS activities).

Undefined deliverables => unclear scope => undeliverable project.

  • Delicious
  • Facebook
  • Twitter
  • LinkedIn
  • Digg
  • Google
  • Reddit
  • StumbleUpon
  • Technorati
  • RSS Feed

9 Responses to “Defining Scope using Deliverables”

  • nick gogerty says:

    An excercise that may help test the efficacy of scope is to test falsifiability. Like a good science a good scope document should be falsifiable in the Baconian scientific tradition. Testing this should be simple and be done before signing off on the scope document. Testing a few statements or potential scope creep litmus tests should be used, so that a loose scope isn’t signed off on. Happy statements are antithetical to effective scope statements that all agree on. Many may at first be uncomfortable stating the negatives used in the test, but it is a good item to check off before signing off on the scoping document. Without constraints in scope, things are open ended wish lists.

  • Nürnberg says:

    Diese Webseite hat mich ernsthaft exzellent auf eine gute Idee gebracht und ist prima geschrieben .

  • Justin says:

    Great information. I particularly like point number two where you mentioned about the is/is not formula. This simple formula is a great way to highlight the benefits and also let people know exactly what this plan is not intended to do. Also point number three is a very valid point as well. I think having little checkpoints along the way to show the tasks have been completed is a great way to operate any project. Thanks for the info.

  • Thanks Justin – in a complex world its gratifying (and a relief!) that simple concepts still offer profound, positive impact in defining, planning and managing projects.

  • isabella says:

    I haven’t encountered deliverables since I am not involved in project management. But this post clearly emphasized how to clarify the scopes. It is also interesting how deliverable could bridge any gaps of SOW and WBS.

  • Justin says:

    This is a really helpful article. Sometimes I find it hard to define my project and find it most annoying to reading project scopes that are flowered by adjectives and doesn’t really give insight as to what the project can realistically deliver. Awesome guide. Thanks!

  • Thanks Justin – I fully concur.
    There is an art to writing clearly and concisely and using simple but powerful tools to assist, especially when the mind is full of thoughts and ideas.
    I believe this is a critical PM skill.

Leave a Reply