Abstract
Customer Satisfaction with the results of any project depends upon an up-front understanding of the Customer's needs and agreement with the Customer on how the project will address those needs. A precise and accurate Scope of Work is essential to accomplishing these ends. This paper takes a fresh look at developing the Scope of Work for a project, looking at the project from the Customer's perspective. By building a “Project Blueprint” of the Customer's expected experience, you can map required results to project activities and thus define all of the necessary elements in a comprehensive Scope of Work. The Project Blueprint also provides a roadmap for the project team to follow that will lead to Customer Satisfaction.
Introduction
Satisfied Customers. On Time. Within Budget.
Against the odds, project teams frequently find themselves expected to deliver successful projects in the face of uncertain requirements and uncontrolled Customer expectations. The Scope of Work is expected to address these issues, yet developing it has always been a challenge. How do you ensure that you thoroughly address the Customer's needs and accurately explain to the customer how the project will achieve the desired results?
Objective
The objective of this paper is to take a fresh look at developing a Scope of Work, looking at the project from the Customer's perspective. By building a “Project Blueprint” of the Customer's expected experience, you can map required results to project activities and thus define all of the necessary elements in a comprehensive and accurate Scope of Work. The concept of Project Blueprinting is drawn from the Service Blueprinting approach outlined by Lynn Shostack in “Designing Services That Deliver”. (Shostack, 1984)
Applicability
Although the fundamental tenet of this paper – that project success is achieved by meeting customer requirements – applies to all projects, the Project Blueprinting framework for developing a Scope of Work applies most readily to projects that are:
- Services provided for external Customers – since the focus is on understanding the requirements of the Customer (although elements of this approach can certainly be applied to internal projects where the beneficiaries might be considered internal customers), and
- Repeatable small and mid-sized projects – the effort involved may not be cost effective for large one time projects, unless there is a substantial budget for requirements discovery and project planning.
Advantages
There are several advantages to the Project Blueprinting approach:
- The results of the Customer Needs Analysis provide traceability between project results (or activities) and customer requirements.
- The Project Blueprint provides an easy-to-navigate graphical aid in understanding how to execute the project and becomes the foundation for the Work Breakdown Structure and Project Schedule.
- Both the Project Team and the Customer understand the project and its expected results.
Defining Project Scope
Sources of Scope Creep
Scope Creep, or “adding features and functionality without addressing the effects on time, cost, and resources” (PMI, 2004, p 375), is a curse of project managers everywhere. If not addressed, projects can spiral out of control, exceeding both allotted budget and time for the project. Where does Scope Creep come from? Typically, post-contract changes in project requirements arise from any of three areas:
#1 - Unclear requirements – The Customer's needs with regard to project outcomes have not been thoroughly investigated, understood, and documented,
#2 - Poorly set expectations – The Customer has not been informed of the degree to which their needs are going to be satisfied, and those areas that are excluded from the project, and/or
#3 - Lack of Scope Change Management – There is not a process in place to evaluate new requests from the Customer against a requirements baseline to determine if they are included or not.
Arguably, Scope Change Management (#3 above) cannot effectively occur unless you baseline a set of clearly articulated requirements (#1) and the customer understands the extent to which those requirements are going to be addressed (#2). As such, this paper will focus on accurately setting Customer expectations for the expected outcomes of the project as they relate to satisfying requirements.
Components of the Scope of Work
To accurately set Customer expectations, and thus avoid Scope Creep, the Scope of Work must address a number of aspects relating to the project. The terms “Scope of Work”, “Statement of Work” and “Project Scope” are variously used to describe the boundaries and expected outcomes of projects. “Scope of Work” and “Statement of Work” typically address the tasks to be performed, whereas “Project Scope” can also include the deliverables. (Wideman, 2007) For the sake of ensuring that Customers understand the proposed project, the Scope of Work developed in this paper includes elements from all of these:
- Goals and objectives of the project
- Narrative description of the services provided or activities performed
- Customer responsibilities during the course of the project
- Results and deliverables from these activities
- Milestones reached over the course of the project
- Limitations to the project – assumptions and exclusions
Four Steps to a better Scope of Work
The remainder of this paper describes a unique approach for developing a project Scope of Work based upon a Project Blueprint. The proposed approach has four steps as shown in Exhibit 1.
Exhibit 1. Four Steps to Develop the Scope of Work
Step #1: Conduct a Customer Needs Analysis
The first step in developing the Scope of Work is to define the project results necessary to satisfy the Customer's requirements. This is the most critical step, as it defines both the results to be included in the project, and those areas which will be outside of the scope – the exclusions. (There is extensive literature on the topic of how to determine Customer requirements. In this paper the focus is less on how to determine Customer needs and more on what to do with them when they are understood.)
Customer Needs Analysis has three stages, each stage answering a specific set of questions as shown Exhibit 2.
Exhibit 2. Stages of the Customer Needs Analysis
The approach described here has its roots in Six Sigma theory where it is known as the “Critical to Quality Flowdown” (or simply “CTQ Flowdown”) (De Koning, 2007). Exhibit 3 shows an extract of a completed Customer Needs Analysis.
Exhibit 3. Extract from an example Customer Needs Analysis
Stage #1: Needs - Start with a clear statement of the objectives for the project. Then, derive the requirements that support attainment of these objectives. Requirements can take several forms. Among these are:
- Specific tangible deliverables or conditions which must be present at the conclusion of the project – “The server must be installed and configured to meet the application specifications”,
- Customer capabilities which must be present during or at the conclusion of the project – “The customer is prepared for the implementation project”,
- Specifications (or limitations) on how the project is delivered – “Data migration must not impact the live environment during normal business hours”
Typically, there are high-level requirements or categories that are broken down into more detailed specifications. These requirements can be represented in a “tree diagram” as shown in Exhibit 3 above. Be sure to take the requirements analysis to the level of detail required to organize all identified customer needs.
Stage #2: Results - The next stage of the Customer Needs Analysis is to define the necessary project results to satisfy the requirements. This is typically a brainstorming exercise performed by the project team or subject matter experts. The objective of this discussion is to explore each requirement and determine all of the results or conditions which must be present to satisfy it. Similar to root cause analysis, the facilitator might ask the question “What else?” up to five times to make sure the potential project outcomes are fully explored. Be sure to note those requirements that are not going to be addressed by the project or that you are expecting the Customer to satisfy.
Stage #3: Inputs - The final stage, another brainstorming session, seeks to identify all of the pre-requisites, both conditional and tangible required in order to produce the project results. In some cases, the Customer supplies these inputs – “Data center has adequate power”. In other cases, they may be tools required by the team – “Configuration Requirements Template”. Also, inputs might be provided by 3rd parties – “Vendor design review”.
Upon completion, the Customer Needs Analysis documents the relationship between Customer Requirements, Project Results, and Project Inputs. This picture is very suitable for explaining to the Customer how the project results will satisfy their needs.
Step #2: Define the Project Approach
Once the required project results are understood, the next step is to map these results into the major phases, or “Life Cycle” of the project. Almost all organizations have a methodology that they follow for project implementation. Exhibit 4 displays a typical Life Cycle for a technology implementation project.
Exhibit 4. Typical Implementation Life Cycle
Take each of the project results identified in the Customer Needs Analysis and determine in which phase of the project the result will be developed or delivered. In the event that a result relates to method of delivery for a project activity (“Data Migration occurs over a weekend”), associate it with the phase where the activity occurs.
The project architecture that results from this step should be a modular diagram depicting the life cycle phases of the project and the significant results achieved in each phase. This modular approach facilities the development of standard, reusable, project modules, reducing the amount of effort for creating successive Project Blueprints. When appropriate, you can tailor these modules to meet the requirements of specific projects as described in the Capability Maturity Model. (Software Engineering Institute, 2002)
Exhibit 5. Modular Project Architecture
At this point it is important to identify specify entry and exit conditions for each proposed phase of the project. These will serve as triggers for starting the project phase, milestones for project management, and boundaries for developing the Project Blueprint, the next step in this process.
Step #3: Blueprint the Project
The Project Blueprint is a graphical representation of how the project will be delivered from the Customer's perspective. Similar to a “swim-lanes” cross-functional process map, it charts all of the transactions that will occur over the course of the project, both within the Customer's view and outside of it.
By taking a graphical approach, a more precise description of the delivery approach can be created – the who, what, when, where, and how details. This precision will allow for a better understanding within the project team as to how the project will be executed, and it allows for a more accurate Scope of Work to set customer expectations for the project. Exhibit 6, below, is a typical example of a Project Blueprint layout.
Exhibit 6. Project Blueprint Layout
Develop the Project Blueprint in the sequence shown in Exhibit 7:
Exhibit 7. Steps to Develop the Project Blueprint
Upon completion of the draft Project Blueprint, use the results of the Customer Needs Analysis as a checklist to ensure that all required project results have been achieved. Also note whether all of the required inputs have been identified in the blueprint, either as provided by the customer, provided by supporting processes, or as templates to be developed for this type of project. Exhibit 8, below, is an extract of a Project Blueprint for a small IT project.
Exhibit 8. Extract from a completed Project Blueprint
Step #4: Develop the Scope of Work
At this point, you have defined all of the elements required for the Scope of Work. Exhibit 9 outlines the contents of a typical Scope of Work and describes how to develop these elements using the Project Blueprint.
Exhibit 9. Scope of Work Outline
The Project Blueprint also provides the foundation for other key Project Management documents:
- Work Breakdown Structure (Deliverables) – derived from the Physical Evidence lane of the Project Blueprint
- Work Breakdown Structure (Tasks) – derived from the Onstage and Backstage Actions lanes
- Project Schedule – tasks and their relationship are derived from the Customer Experience, Onstage, and Backstage actions lanes. Milestones are developed from the entry and exit conditions identified in Step #3.
Conclusions
Customer Satisfaction with the results of any project depends upon an up-front understanding of the Customer's needs and agreement with the Customer on how the project will address those needs. A precise, accurate, and comprehensive Scope of Work is essential to accomplishing these ends.
By applying the four steps for Project Blueprinting outlined in this paper:
Step #1: Conduct a Customer Needs Analysis
Step #2: Define the Project Approach
Step #3: Blueprint the Project
Step #4: Develop the Scope of Work
you can develop a blueprint for executing a project that focuses on meeting well understood Customer needs. The Project Blueprint also provides a comprehensive roadmap for the project team to follow that will lead to Customer Satisfaction.
A Scope of Work derived from the Project Blueprint contains all of the required elements to set the Customer's expectations accurately with regard to how the project will progress and what the results will be. When new requirements surface, they can be effectively evaluated against the Scope of Work…making unbridled Scope Creep a thing of the past.
