Scope Compared 1Credit: Cory Stophlet, Jan 2015

As we’ve covered many areas of the project management process or discipline and the term Scope is used quite often. This concept is at the foundation of a project. In the lessons for Scope Management, Scope Statement and Scope Creep, we clearly defined the content of scope, why it exists and how it is used in defining the project end-state. Now we will briefly talk about the concept of Scope as a view for the management of the project versus the resulting Product/Service as an output of project. Don’t worry, this will not be a long read. Much of scope control, as you will see, is accomplished in Change Control, Risk Management, Quality Control, and Scope Verification.

[Note:  Scope Verification will be address is another separate lesson/article because of its inter-relation with Quality Management functions, Project Completion and Close-out responsibilities.]

What’s What: Project versus Product

The Scope of a Project is in reference to all the features, functions, deliverables and requirements towards managing and leading the project. Project scope includes the activities necessary in defining the desired outcome of the project. In-scope may include meeting requirements, performance reporting requirements, documentation requirements, procurement and contracting plans and anything relative the project management processes. Out-of-scope might be: how a product is assembled, construction procedures or methodology, and may or may not include software/hardware solutions.    

The Scope of the Product still involves deliverables; however, as Project Managers (PM), we must think in terms of what the customer/client/sponsor expects to find at the end of the project road: a complete “product and/or service” that is made up of pieces and parts, features and functions. When you buy a new car do you think about and require the dealership to have the manufacture submit the operational, quality control, production reports before you purchase a vehicle? No. We go to a dealership with a desire for a type of vehicle, maybe we have a list of specifications we desire as the customer. For example: we might have a list that includes 2-door or 4-door, SUV, truck or sedan, a specific color, entertainment accessories, interior materials, and even a detailed owner’s manual, etc. These are product deliverables and not project deliverables.

In both Product and Project Scope what is in-scope is immediately an element that must be included in the Scope Verification process of the project outcome. Scope Verification comes into play as a measure of whether or not the Product is fully delivered successfully. Projects rarely go along without a hic-cup or problem that causes some aspect of the project scope to go askew. I’ve managed a lot of projects and something always slips no matter how hard you and the team work to avoid problems; problems will occur, costs will increase, time schedules will slip, and the BIG ONE – customers change their minds and want more stuff. 

In other words, it may be in-scope for the Project to stay within a specific budget and time span, and yet, things do happen and can for a budget of the full delivery of the product is determined and measured by what is in- and out- of the product scope.

Scope Compared 2Credit: Cory Stophlet, Jan 2015

This will be covered more in this PM series; but for now, let’s focus on the “pieces and parts” thought process.        

Deliverables are like objectives, they are:

  • Qualifiable:  Can be defined in terms that allow the PM and customer to determine whether or not the defined scope has been achieved. Think descriptive terms.
  • Quantifiable:  Can be defined in terms of numbers of quantities, leading or aid in defining duration and cost estimates, duration and cost actuals, leading to measurable requirements. Think in numbers terms.
  • Measureable:  Can define the technical requirements and identify variances/variations from the cost, duration, scopes in terms of requirements; this includes cost measures, schedule measures, and specific performance measurements. Think detailed technical data and data input for measuring the deliverables pieces and parts in performance reporting, as well as cumulative performance reporting. 
  • Documented:  Everything IS PUT In Writing; and it’s okay and preferable to have separate documents for deliverables, sub-deliverables, and individual elements, pieces and parts that create the overall deliverable(s). This includes technical design requirements, technical specification requirements, engineering documents, construction/building blue-prints, etc.

Project Deliverable Items

Think about what it will take to manage the project: what tangible items will be required; what will be produced by the “act” of managing the project. Here are some items to consider including as project deliverables.

Performance Tracking and Reporting

Does the client/customer/sponsor have a particular project or product performance tracking requirement or method? Most PMs will use some form of Earned Value Analysis; however, some businesses have other means and methods they prefer so you need to be sure to account for those requirements; they are deliverables. Taking the desired end-state measured against the actual current-state at any given time throughout the project and making intelligent estimations of the future-state. Identifying variations and determining effects on the deliverables, the product as well as the project.

There are many different ways to track and display project tracking information, to include: measurements, evaluations and estimates, current and future-state. Common tools or methods include: spreadsheets, project management software, worksheets, and network precedence diagrams, business or organization specific web applications and intranet pages are also very common. Businesses that run many projects as a matter of routine will often have their own website/intranet site for PMs and teams to post their status information so that every stakeholder has access to the same information and in the same format. These standardized reporting tools also make it easier for the project sponsor, as well as anyone in the organizations hierarchy, to check on the progress of a project in real-time (or as close as possible to real time).  

Periodic performance meeting documentation including meeting minutes, handouts, meeting announcements, and attendee records. These meetings and briefings (formal) should be included among the scope deliverables. Even if the client/customer/sponsor does not state so, these formal meetings and briefings are crucial for effective communications with all stakeholders. Therefore, this is one time when I highly suggest that you, as the PM, inject that deliverable into the plan.

Design documents,[2] technical documents, architectural blue prints, software design specifications, parts specifications, user manuals. Be sure to establish the documentation deliverable method, as in, make sure to indicate whether it is to be in hard copy or soft copy, i.e. a CD, DVD, or Flash drive/devices.

Other Documents:

  • Training documentation and course material for employees, users, operators, and maintainers (repair/routine care).
  • Change Control documentation that includes all relative correspondence relating to justifications, agreements, modifications, approvals and disapprovals.   
Scope 4Credit: Cory Stophlet, Jan 2015

Product Breakdown Structure is depicted by using a Product Breakdown Structure (PBS), Technical Breakdown Structure, Engineering Breakdown Structure, Software Breakdown Structure, Architectural Diagrams, Blue Prints, and pretty much anything that provides all the pieces and parts needed to create the output of the project.

Scope 5Credit: Cory Stophlet, Jan 2015

Project Scope is depicted using a Project Breakdown Structure (PBS) and with the Work Breakdown Structure (WBS). Instead of reiterating what has already been covered on the various breakdown structures, I'll refer the reader to those previously published articles.[1][2][3]

Scope 6Credit: Cory Stophlet, Jan 2015 Scope 7Credit: Cory Stophlet, Jan 2015

Don’t Confuse this with SOW

Scope of Work (SOW) is inclusive of activities and deliverables needed to achieve all or a part of the product and project. It can include the work to create a deliverable as well as any reporting requirements.   

We manage projects –We create products. And we cannot manage or control either unless we’ve clearly defined the deliverables, along with the standards that must be achieved.  {Change Control} If we don’t have a clear definition as to what is in-scope, we will not recognize when something is out-of-scope; thus, wasting time and resources.

Analyze project scope and product scope separately, and then reconcile the two results. Product risk will always affect the management of the project; however, project management activity risk may not affect the product. For example, a specific reporting requirement or alteration to the team members might have an effect on the Project Scope it will not necessarily have an effect on the Product Scope.  

How does the concept of In Scope and Out of Scope work with Project versus Product Scope? 

The goal is the same:  to identify and clarify those functions, elements, pieces and parts. This will lead to the function of Scope Verification:  ensuring that all identified project/product deliverables have been completed satisfactorily.

Food for thought:  Poor scope definition equals higher project costs and loss of schedule control.