One of the first things you have to do as an engineering project manager is fully define the scope of work your team is responsible for delivering. You can’t build something unless and until you know exactly what that “something” is supposed to be. Successful project managers predetermine and document precisely what is (and isn’t) going to be delivered; the project’s scope of work is the fundamental piece to defining the overall success of a project. There are two main parts to work scope: 1) the deliverable itself (i.e., Product Scope); and all the supporting project work required to deliver that product (i.e., Project Scope). In this post, I discuss in more detail the differences between the two.
Work Scope Definitions
Perhaps the most important thing you must do as a manager taking on a new project is to define–and document–what it is you’re signing up to deliver. Whether it’s a physical product, a service, or some other tangible thing or result, the clear definition of what you’re agreeing to manage and deliver is the first step to ensuring project success.
And just as important to defining what you’re going to deliver is the documented definition of what you’re not going to deliver, too. In a sense, project management is largely about managing expectations. Defining and documenting your project’s scope is the first step in managing your key stakeholder’s expectations. In other words, at the beginning of a project you need to state explicitly and exactly what “success” will look like at the end of the project.
The clear end explicit definition of the features, functions, and extent of the delivered product is known as the “Product Scope” of the project.
While Product Scope is relatively self-explanatory, there are other specific work that you and your team are going to have to do, perform, and provide as part of the effort of creating and delivering the Product Scope. For example, business and administration tasks, safety management, systems engineering oversight, and quality assurance and control may be required project work efforts needed to support the delivery of the product. But these are not actually tangible parts or components of the delivered Product itself. Even your own time and effort as a PM is required to deliver the Product, but isn’t a physical part of it.
The term used for all of this supporting work required to deliver the product is known as the “Project Scope.”
Combined, Product and Project Scope are the two constituent components of the overall Scope of Work of the project, or Work Scope for short.
There are few things in project management that are absolute, and the definition of what is and isn’t part of your project’s work scope is sometimes open to interpretation (and vigorous debate!). Sometimes this is due to ignorance, or a “this is the way we’ve always done it” mentality. Other times it may be because of specific norms or unique conventions found within a specific industry or field.
For example, some projects define Product Scope as a subset of the overall Project Scope. While this is perfectly acceptable, you do need to be aware of the distinctions, as you may still need to define other terms to describe the non-Product portion of the Project Scope, such as business and administration, safety, and QA/QC when planning the overall Work Scope of the project. This is because these things are often organized, tracked & measured, reported, and/or budgeted differently than the Product work itself. For instance, the earned value of creating the product could be determined completely differently than something like administrative tasks (e.g., physical progress vs. level of effort).
I personally have worked on projects where Product Scope was considered a subset of Project Scope, and all the business, safety, etc work supporting work was called the “non-product project scope.” Yes, yuck. To me, the fact that “product” and “project” are already too similar in spelling and pronunciation is reason enough to eschew this even more confusing terminology. To keep things as simple as possible, I prefer the standard definition of: Work Scope = Product Scope + Project Scope.
The bottom line to all of this is that it doesn’t really matter what you call these things– as long as you’re very clear what you’re going to deliver, as well as what you’re not going to deliver at the end of the project. Managing your stakeholder’s expectations begins with these explicit definitions at the beginning of a project.
Like this post? Hate it? Have something to add? I encourage you to join the conversation in the comments box, below. You can also drop me a line if you prefer. I’d love to hear from you in either format. My email address is MarkHWarner@gmail.com or you can find me on LinkedIn.
MW | Tucson