You have just been selected to manage that big, important corporate project: establish a project management office (PMO). You realize the project’s charter is nowhere to be found. How do you go about defining your PMO project’s scope?
Your PMO 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 PMO project’s success is determined by how well you define, communicate and elaborate that footprint.
A project’s scope defines all the work required, and only the work required, to complete your project successfully. It is the sum of deliverables, results and services that will be produced by your project. Without a proper definition of the PMO project’s result, you’ll be experimenting with project success.
Don’t skip or skimp!
Developing and maintaining a shared understanding of your PMO 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 result. Don’t rush the process! Capture what you hear in a way that clearly conveys what the PMO will deliver.
Is it a good scope statement?
Your PMO’s scope definition is complete when both 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 PMO 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 and 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; requirement definition is part of a solution delivery process addressed in project planning. Requirement definition has one of the biggest impacts on scope definition, because what the business requires and the project’s scope must be in alignment.
Bring on the matrix!
I use a tabular approach to scope definition to help stakeholders understand what the PMO is, what the PMO might be in the future and what the PMO is not. Defining scope in a tabular format allows scope elements to be categorized and bundled, which allows for detailed review, deeper insights, and at-a-glance synthesis of a lot of information.
Here’s an abbreviated, simple example of how the tabular approach could begin to define the scope of a project delivering a PMO (there are about 150 scope elements to evaluate when defining a PMO). For each scope element, the presence or absence of text in the columns indicates that element’s scope status. Descriptive wording can be provided instead of a generic “x” to ensure shared understanding of complex elements.
Make the columns meaningful and aligned with your PMO. Project result delivered in phases? Add columns for each project phase. Stakeholders undecided about scope elements? Add a column called “Evolving”. Is general sequencing of scope elements is 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.