You have just been selected to manage that big, important corporate project. You realize the project’s charter is nowhere to be found. How do you go about defining your project’s scope?

Your project has a footprint.

Your project’s scope defines the footprint of your project. Like the changing footprint of a human from baby to adult, your project’s footprint will change over the life of your project. Your project’s success is determined by how well you define, communicate, and elaborate that footprint.

A project’s scope defines any required work and only the work that is necessary for the successful completion of your project. It is the sum of deliverables, results, and services that will be produced by your project. Without a proper definition of the project’s result, you’ll be experimenting with project success.

Don’t skip or skimp!

Developing and maintaining a shared understanding of your project is foundational. Defining your project’s scope properly has many benefits that have a direct, positive correlation to project success:

Spend adequate time with your stakeholders and listen to how they describe the project’s result. Don’t rush the process! Capture what you hear in a way that clearly conveys what the project will deliver.

Is it a good scope statement?

Your project’s scope definition is complete when both the product and project scope elements are reflected and integrated. What is the difference? Product scope is measured against requirements and supported by the solution delivery process. Project scope is measured against the work plan and supported by the project management process.

Your project’s scope is well-defined when each stakeholder can see the elements that are important to them and when all stakeholders agree that the project’s scope is complete as well as accurate.

A project’s scope is not the same as the project’s requirements. Scope definition is part of a project management process at project initiation; The requirements definition is part of a solution delivery process addressed in project planning. Requirement definition has one of the biggest impacts on scope definition because the project’s scope and what the business requires must be in alignment.

Bring on the matrix!

I use a tabular approach to scope definition to help stakeholders understand what the project is, what the project might be in the future, and what the project is not. Defining scope in a tabular format allows scope elements to be categorized and bundled, which allows for a detailed review, deeper insights, and at-a-glance synthesis of a lot of information.

If the key deliverable is the setup of Project Management Office (PMO), here’s an abbreviated simple example of how the tabular approach could begin to define the scope of the project. For each scope element, the presence or absence of text in the columns indicates the scope status of that particular element. Descriptive wording can be provided instead of a generic “x” to ensure a shared understanding of complex elements.

Make the columns meaningful for your project. Project result delivered in phases? Add columns for each project phase. Stakeholders undecided about scope elements? Add a column called “Evolving.” Is the general sequencing of scope elements indicated? Add columns called “Next” and “Later” after “In.” Is the word “Out” too strong for your organization’s culture? Use “Excluded” instead.

The more your stakeholders can see project elements of interest to them in your scope statement, the easier it becomes to manage and control your project.

Similar Content:

• The implications of skipping scope definition

• Don’t let your scope definition gather dust!

• Using risk-based thinking to reduce deviation from planned results