Discussing and Identifying Customer Requirements (agreeing Scope)

Purpose

Agree on key deliverables in the customers requirements and document them

Background

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 stake holders 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 hand over about what we have or haven’t done – and what was expected.

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 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.

“Scope creep” is seen as an industry-wide evil, instead as 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.

Procedure

• 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, time scale, 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).
• 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.
• Requirements. This is a specific skill, almost certainly done by 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 prioritise the wants, needs and expectations. They may also describe some aspects of functionality of the project deliverables.
• 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 stake holders.
• 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.
• Constraints. All projects have constraints – often put there by humans – sometimes by the rules of physics!  A constraint is anything which 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.
• 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.
• Project Organisation. Well, as it is initially – it is likely that changes may be necessary to the roles and responsibilities assigned to individuals.
• 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.
• 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).
• 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 state the amount of funds released at a given point.
• End Product Description. This should include the quality criteria for the product to be acceptable for the customer/user. 
• 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.