Is a set of conditions that is required to be met before deliverables are accepted?

DEFINE  SCOPE

After you have collected all the Stakeholder Requirements (your Stakeholders' Needs and Expectations), and placed them on your Stakeholder Register, it will likely be necessary to to "boil down" the Requirements before writing an executable Project Scope Statement

Define Scope

in a Project Scope Statement

Click on Underlined Words for more information and templates

This "boil down" will be necessary because some of the Stakeholder Requirements you have collected likely oppose each other. They might be competing, conflicting, different, mutually exclusive. Some Requirements might just be impossible to perform.This is the time to resolve those conflicts. The process requires working together to decide which requirements will be included in the Project Scope Statement, and therefore in the project.

​

You will want to recall your Power-Interest Grid for appropriate Stakeholder Engagement at this time. Some other tools for resolving Requirement conflicts are found by clicking here.

​

The Project Scope Statement must be extremely clear. This is your Scope Baseline, which cannot be changed without formal approval. One of the most common reasons projects fail is a lack of clarity regarding the expected outcomes. A very clear Scope will help to prevent scope creep, scope change, and will greatly increase your likelihood of project success and Stakeholder satisfaction. It is crucial that all Key Stakeholders in a project have a clear understanding of the Scope. Consider a Structured Walk Through as an effective tool to help define Scope. "If you don't know where you are going, you will probably end up somewhere else".

                            A few DEFINITIONS will be helpful to clarify the process:

Expectation: A one-way desire or perspective that a Stakeholder has about HOW the project will be managed. Expectations must first be discovered then documented so they can be managed. (One Stakeholder's expectation might be that every one of his/her needs will be included in the project!) We manage Stakeholder Expectations by either managing the project as expected or by working with the Stakeholders to help them understand why their expectation cannot be met, so they can adjust their thinking to be in line with how the project will be managed.

Need: A one-way desire or perspective that a Stakeholder has about WHAT the project will deliver. Needs must first be discovered then documented so they can be managed. We manage Stakeholder Needs by either delivering what is expected or by working with the Stakeholders to help them understand why their need cannot be met, so they can adjust their thinking to be in line with what can be delivered.

Requirement: A condition or capability to be present in a product, service, or result to satisfy a stakeholder, a contract, or other formally imposed specification. Requirements include Stakeholder Expectations and Needs. If no stakeholder can be assigned to a Requirement, it might not be a Requirement at all. Not every Requirement will make its way into your project. All Requirements are included in the Stakeholder Register. We manage Stakeholder Requirements of Needs and Expectations by either delivering what is needed, and how it is expected; or by working with the Stakeholders tp help them understand why their Requirements cannot be met, so they can adjust their thinking to be in line with what can be delivered and how the project will be managed.

Scope: The sum of all the products, services, and results to be provided as a project. Used alone, the expressions 'scope', 'total scope' or 'entire scope' mean 'project scope together with product scope'.

Project Scope: The work performed to deliver a product, service, or result with the specified features and functions.

Product Scope: The features and functions that characterize a product, service, or result.

Project Scope Statement: The detailed description of the entire scope including project scope and product scope. It includes major deliverables, assumptions, and constraints, and the work required to create those deliverables. It defines which collected requirements will be included and which collected requirements will be excluded from the scope. The Project Scope Statement also includes the measureables (what will be measured and how it will be measured), including success (or acceptance) criteria, against which success will be determined. The Project Scope Statement enables the project team to perform more detailed planning, guides the project team's work during execution, and provides the basis for evaluating whether requests for changes or additional work are contained within or outside the project's boundaries. 

Structured Walk Through (SWT): A walk and talk through all the attributes of the project's deliverables. It can be a physical walk, on a construction site or through a mock-up, for example. The purpose is to clearly explain the project's outcomes in a way that can be understood by the key Stakeholders for the purpose of gathering feedback or obtaining consensus. The SWT is usually done near the end of design in a conventional design to construction project.

Acceptance Criteria: A set of conditions that must be met before deliverables are accepted.

A FINAL NOTE: You might ask, "Why collect requirements if we know we cannot satisfy all of them ?". Simply put, it is much better to get these potential conflicts out in the open and deal with them, rather than to wait until they fester into something uncontrollable. Or said another way, you cannot manage what you do not know. 

Are the set of conditions that must be met before a deliverable can be accepted?

Which of the following items has to do with conditions that must be met before deliverables are accepted?

What is deliverable acceptance criteria?

What is an acceptance criteria in a project?