The Art Of Scope Management

Scope Planning and Project Scope Development

Creating and agreeing the REQUIREMENTS for a project are only part of the story (what the project is going to do – an important part!)

It’s equally important to agree what the BOUNDARIES are of any undertaking and these must show what the project is NOT going to do.

These elements are bound together and are called the Project Scope Statement which details the project objectives, end-products (deliverables), and requirements. The Scope must be agreed with all concerned, and used to create the project plan ‘baseline’. Once agreed, the scope sets the expectations of all stakeholders so they are clear about what they are going to get when the project is finished.

The last thing we want is a disagreement at project handover about what we have or haven’t done – and what was expected. I have found that many projects fail – not because Requirements were not met – but because of difference of opinion about what the project was to deliver.

Most projects are triggered by some form of requirements document. These are central to success and lead to the project developing some form of functional specification against which the project outcome is designed. But in my experience, not enough effort is spent getting a joint agreement on these documents, and that is where a scope planning and scope development play a key part.

It is also important to recognize the need to have “living documents”. The complex relationships between the Requirements, Specification, Design, Development, Business Case, Project Plan, and the risk/Issue/Change Logs prove that ALL documents should be reviewed and refined on a continuous basis during the project. Not because you want to – but because you MUST!

“Scope creep” is seen as an industry-wide evil, instead of being viewed as the natural corollary to change control. There is a little-known technique that beats all others hands-down for laser-focussed scope planning and development. It’s this. At the very beginning of project planning, agree what the end-product along with the major products are to be. This is best defined by using the Product Description Technique, and only then determine the tasks and resources.  I describe this in detail within my Project Management Training Toolkit ( click here  )

Okay? Now let’s run through the key areas in turn of what should be included in the Scope Statement:

1. Project Objectives – what the project is to do. These should be quantified and measurements agreed. Typically the measurements will include one or more of, cost, timescale, quality, or business benefits. You will have heard of the SMART acronym for each objective: Specific, Measurable, Accurate, Realistic and tangible, Time-bound (time frame plus date).
2. Deliverables (end-Products). Each should have a Product Description written. This contains descriptions of the purpose, composition, derivation, and the quality criteria for it to be acceptable to the customer.
3. Requirements. This is a specific skill, almost certainly done by the specialist team, the customer, users, etc. But it is the responsibility of the project manager to make sure they are captured and agreed. Requirements quantify and prioritize the wants, needs, and expectations. They may also describe some aspects of the functionality of the project deliverables.
4. Project Boundaries. Care must be taken here. This should focus on what is to be excluded from the scope in terms of requirements, objectives, and deliverables. It’s a good idea to create a draft boundary document and circulate it for comments. Or perhaps generate the document from within a meeting with key stakeholders.
5. Product Acceptance Criteria. This should document the WHAT and the HOW that will be carried out as part of agreeing successful project closure. It must be the Customer/Users perspective. The actual criteria used can be taken from a wide choice of aspects, and may include elements such as ease of use, reliability, operating costs, performance data, etc. This should also include HOW the objectives, deliverables and other outcomes of the project are to be approved.
6. Constraints. All projects have constraints – often put there by humans – sometimes by the rules of physics! A constraint is anything that impedes the project team s work. The obvious choices may include, time, cost, quality, key milestone dates or logistics, standards, procedures, directives, compliance, legal and law, health and safety, technology, etc. Whatever. Get them down and agreed – then plan accordingly.
7. Assumptions. In a nutshell, anything you believe to be true. Do not use this section to capture a load of disguised risks (although stated assumptions may lead to generated risks). Documenting them at the start of a project helps test these assumptions and get them agreed. Should these assumptions prove to be false at a later date, these captured statements can be used as a basis to plan and manage the way forward.
8. Project Organisation. Well, as it is initially – it is likely that changes may be necessary to the roles and responsibilities assigned to individuals.
9. Initial Risks. Any known risks at this time. It is helpful to include an initial risk analysis so that readers can get a ‘feel’ for each risk.
10. Milestones. These may be externally dictated and/or internally created as a result of planning by the project manager. Be sure to have them represent significant points of achievement (or key decision points such as an end-stage assessment).
11. Funding Limitations. This is different to cost constraints. It refers to the availability of money to finance the project, and this may have an impact on cash flow. It may state key dates when funds are available, these may be dictated by certain completion criteria, and it also states the number of funds released at a given point.
12. End Product Description. This should include the quality criteria for the product to be acceptable for the customer/user.
13. Specification Document. This is usually derived directly from the Requirements document. It is usually highly detailed and created by the specialist team along with input from the customer and users.Final thoughts.

    Okay, it’s quite a list. Getting the scope correctly and accurately documented is a tremendous aid to ensuring a successful project. But let’s consider a small to medium complex/risk type of project. ALL of the above could be driven as an interactive meeting agenda. The project manager could manage the meeting (don’t forget to invite all interested parties), and capture the agreements.  An hour or so later the PM could e-mail all attendees a neat documented scope statement for their final comments and sign-off.