Scope Management of Service and Outsourcing Projects

Max B. Smith, PMP, Compaq Computer Corporation

Introduction

Scope management of Service and Outsourcing projects requires the same methodology and discipline as a traditional project as described in the Guide to the PMBoK. However, there are unique characteristics of Service and Outsourcing projects that require additional tools and methodologies. These characteristics are found in the basic definition of a project and the life cycle of the Service and Outsourcing (SAO) project.

A traditional project, as defined in the Guide to the PMBoK, is “a temporary endeavor undertaken to create a unique product or service.” An SAO project is defined as one “whose end deliverable is a Service.” An Outsourcing Project, then, is “a special case of a Service Project where assets are transferred from the Buyer (Client) to the Seller (Contractor).”

There is no reference to duration in the definition of SAO projects, since they are intended to continue the service indefinitely. The traditional definition is well suited to the initial phase of the SAO project, but it does not suit the later phase because the SAO project transitions into a “Managing Phase” that does not end if the scope is well managed. This extended life cycle of the SAO project is one of the important characteristic departures from the traditional project.

In addition to extended life cycle, a notable difference between the traditional and the SAO project is that the SAO project does not have a final product, in the sense of a building or a computer application. The SAO project is concerned with the implementation of processes that generally support a larger operational function. Implementation occurs when an organization wants to replace existing processes that are not considered to be meeting the objectives of the organization. These processes may have been done internally or by a contractor. The purpose of replacing the deliverer (internal or external) of the processes is for the organization to continue to receive the service at improved levels of efficiency.

The Service Level Agreement (SLA) is the primary focus of the definition of SAO project scope. Of equal importance to this definition is the understanding of the processes by all participants, including their respective roles and responsibilities. How the work is done has enormous influence on project costs, both in the direct delivery of the service and the processes with which the service delivery must interface.

Because the SAO project is usually replacing a previous set of processes, there is a built-in assumption that the previous processes are flawed or inefficient. This creates an expectation that the new processes will be less costly or will better meet service needs (or both). Whether or not these assumptions are valid, there is pressure to change the new processes to resemble the old, since the old processes are familiar to the organization. Change management then becomes essential to the success of the SAO project.

Changes to the SAO project scope come from the normal sources of misinformation about quantities, descriptions, specifications, and the new direction for the project. But, the source of change that is peculiar to SAO projects is this pressure to make the new processes resemble the old. Some of these changes are necessary, but others will be a detriment to both the Client and the Contractor if implemented. Rigorous change management is essential to the success of the project, especially because the extended duration of the project may let seemingly innocuous changes accumulate to create large financial burdens.

SAO Project Life Cycle

The phases of SAO Project Life Cycle used in Compaq Services are Planning, Design, Implementation, and Managing.

The Planning Phase for most SAO projects begins with a Request for Information (RFI) or Request for Proposal (RFP). During preparation of the document, the Client does a substantial amount of basic definition for the project, and the ensuing proposal and contract negotiations essentially complete the planning phase. The Design Phase is normally short for a Service Project and longer for an Outsourcing Project, based on whether the processes are new or relatively standard for the Supplier (Contractor).

The Implementation Phase resembles the resource expenditure profile of a traditional project and is supported by traditional management methodologies and tools. The Managing Phase for an SAO is unique compared to traditional projects. The term Managing in a traditional project means management of planning, design, implementation, and closeout. However, the SAO Project Manager must manage all of these functions while also managing the business, because responsibilities include operational and financial performance as service is delivered.

The SAO Project Life Cycle is graphically represented in Exhibit 1, where it is clear that Scope Management is heavily weighted toward the Managing Phase. The development of the Work Breakdown Structure (WBS) and Statement of Work (SOW) involves defining the component activities to develop a baseline plan so that deviations from the baseline can be clearly articulated and the impact accurately assessed.

<<Insert Exhibit 1>>

The scope must be managed over the entire life cycle. In the initial phases, scope management is similar to the traditional project where the focus is on containment of “scope creep.” In the Managing Phase, the focus must shift to include process improvement that introduces changes in scope that benefit both the Client and Contractor.

Scope Definition

SAO Projects are primarily concerned with processes. Scope definition of a traditional project (development of a SOW) is typically concerned with the whats of the project, and not the hows. The what of an SAO project is associated more with the Service Descriptions and the Service Level Agreements, but it is the how that normally determines who will be the successful bidder. And, it is the how that determines the profitability of the project and becomes a major factor in customer satisfaction.

The Scope Definition of an SAO project must include the SLA, since this is the standard (or specification) for delivery of the service and becomes a contractual obligation. The SLA is the basic reason for the project and must be documented in a clear and concise way. In Computer Service activity, for example, some of the SLAs take the form of time required to respond to a service call and time needed to solve the problem. These are the standards for performance throughout the project, and are frequently described in a table—as shown in the insert in the process flowchart of Exhibit 2.

<< Insert Exhibit 2 >>

The process and interfaces that will be used to deliver the service must be included in the SOW to provide a baseline for the working relationships between the Client and the Contractor. Processes are sometimes difficult to describe, but simple flowcharts embedded in the SOW seem to work best. Flowcharts describe the relationships of the essential activities of the process and indicate clear linkage to interfacing processes and output of deliverables. Interfaces to other processes also should be identified in the flowcharts.

In the example (Exhibit 2), an interface exists when a Client activity leads to a Contractor activity as in “Call Screening engaging the Help Desk” to call the user and diagnose the problem. Information will be passed from the Client to the Contractor. The form and content of this information must be documented so that all parties understand their obligations. For added clarity, the respective roles and responsibilities of the Client and Contractor should be included in the SOW. The SOW is the basic scope definition document, and—when combined with the Terms and Conditions (Ts&Cs)—forms the contractual basis for the project.

Writing the SOW

One of the most frequently asked questions is how to write a Statement of Work. Most of the people who ask are looking for a template in which they can enter information about the project, and thereby easily generate a SOW. In most cases, templates are a poor way to prepare a SOW because they facilitate an inadequate understanding of the Client’s requirements. Templates (or fill-in-the-blanks) SOWs also tend to overlook unique or unusual circumstances that are important to the project.

A better way to prepare the SOW is to start with the WBS, which offers a simplified and comprehensive view of the project where omissions and oversights are more easily identified. The next step is to discuss and assess the risk associated with each activity in the WBS. When this is done properly, it is relatively easy to create the SOW by writing descriptions for the elements of the WBS that adequately defines the work.

A simple format, such as the following, is recommended and adequate for most SAO projects:

Background

Introduction

Summary

Work Elements

Description of Services with Service Level Agreement

Roles and Responsibilities

Assumptions and Limitations

Change Control Process and Procedures

Acronyms, Definitions and Nomenclature

Appendix A – Schedule

Appendix B – Drawings, Maps, Contact Lists, and etc. as needed

Scope Management

As in the preceding discussion, Scope Management is discussed in the context of the SAO Project Life Cycle. In this context, the key elements in the life cycle that have the greatest impact on the Scope include the following: Initiation, Planning, Definition, Verification, and Change Control.

In most cases, initiation of the SAO project begins with the Client, who has an operational activity that he feels can be done by a contractor, or perhaps already has a contractor that he would like to replace. The Client has a good understanding of the service levels needed, but usually has only a vague idea about the processes that can be used by someone else to achieve them. The Client may tender an RFI to see which contractors are credible and can most cost effectively provide the service. Once a number of qualified contractors are identified; the Client will issue an RFP, which is the first substantial component in planning the project.

Scope definition in an RFP is primarily focused on describing the required service levels, the magnitude and locations of work to be performed, and the Client’s organization. It usually will not contain much detail about the processes to be employed, or the work to be performed, because this may prejudice the resulting proposals and could relieve the Contractor of various responsibilities. At this stage, a WBS may be developed, but it will at a high level and somewhat superficial. Similarly, the SOW will not include a lot of detail.

In developing their proposals, contractors perform the next major step in the definition of the scope, since the project is still in the Planning Phase. In this phase there is interaction between the Client and the Contractors, but it is the Contractors who provide the major contribution to definition of the scope. The contractors have read the RFI and RFP and are able to ask clarifying question, thereby expanding the accuracy of the scope. Each Contractor prepares a proposal stating that the required service levels will either be met or an exception will be taken. The proposal also may describe the processes that will be used in the project. Care is taken, however, not to expose confidential aspects of the proposed processes. Descriptions in the proposal develop confidence in the proposed solution, and they also lay the groundwork for a contract. The proposal, in this sense, begins to take the form (and format) of a SOW, although with sales and marketing material included.

A Contractor will then be selected and invited into negotiations that are expected to lead to the award of the SAO Project. At this point, both the Client and the Contractor begin to unveil details relating to the scope of the project that may be in conflict. Negotiations are then conducted to arrive at a mutually-acceptable solution, and the Client and the Contractor will be moved from their optimal understanding of the Scope. Whatever the relative positions, the negotiations will result in a contractual definition of the Scope, a contractual work breakdown structure (CWBS), and a contractual statement of work (CSOW). These are the primary contractual instruments that govern the relationship, and the documents to which the Project Manager must manage the scope of the project.

The Planning Phase tends to end at the time of award. The CWBS and the CSOW become part of the contract and reflect a negotiation of the Scope and Terms and Conditions by parties who may not be intimately involved in the actual delivery of the project. The result is that there may still be false assumptions. Neither party has intentionally done anything wrong; it is just a case of reality developing from engagement. These false assumptions will eventually be disclosed with the implementation of the project and corrected by the change management process. However, a proactive approach can save a lot of time and effort.

The Design Phase is very short on an SAO Project and the substantial portion of Design is the planning documents, RFI, RFP, and Proposal. But these documents do not completely define the design, particularly in regard to process interfaces. Mr. Jelson Ghigonetto (WKS LIMS in Sao Paulo) inserts a project activity immediately after award of the contract where the project team works directly with the Client team and end-users to review and clarify ambiguities in the scope. Any changes that they develop can be incorporated into the CWSB and CSOW. There is a tremendous advantage in catching such changes early in the life cycle before work commences, since the successful outcome of a project is largely determined by appropriate activities early in the project cycle. Verification/validation of the scope immediately after award, and before work commences, is one of these activities.

The Implementation Phase in an SAO project is concerned with initiating the services that are described in the CSOW. Impact to scope definition comes from Change Requests, which are part of the Change Management Process. Change Management during implementation is focused upon adjusting the services to best satisfy the client. The Contractor has proposed optimal conditions for the delivery of services that have been refined in a number of different Client environments; however, Client environments will never be identical and some adjustment is required. Some of this will be identified in the negotiation and scope verification processes, but some residual will remain and can be incorporated into the CSOW via the change process.

The evaluation and assessment of each change should include clear determination that the net result of the change is a benefit to the Client, since one of the reasons that the Client initiated the project was to implement improved and more efficient processes. If Changes are implemented that alter the Contractor’s processes solely to accommodate Client’s interfacing process; there is a real possibility that there will be no net gain in efficiency for the Client. That is why the Change Processes include a dialog between the Client and Contractor Project Managers to assess and agree on the net impact of each change. It is often the case that it is more effective to change a Client’s operation or process than that of the Contractor.

An example of a change process is shown in Exhibit 3. This is simplified, but adequate for most situations. The effectiveness of change management is realized only when it is rigorously applied, and the process should begin with Change Order Zero to reconcile the SOW with the results of contract negotiations. Change management continues for the life of the project where the Project Manager and Client representative processes Change Requests and Change Orders. It is important for the Project Manager to keep a log of the Change Requests/Orders.

<< Insert Exhibit 3 >>

At the conclusion of the Implementation Phase, service is being delivered in accordance with the SLA and the work transitions from project activities to the activities of managing business operations of service delivery.

In the Managing Phase, the CSOW should be a well-established basis for service delivery, and mismatches between Client and Contractor processes should have been corrected. Service delivery should be consistent with the Service Level Agreements. In this phase “managing” means managing the status quo of the CSOW, almost. If managing the service delivery is constrained to a static CSOW, then it won’t be long before the Client is looking for a new contractor who can further reduce costs. Experience has shown that every process can be improved in some way, and evolving technology ensures that there is always an opportunity for process improvement.

During the Managing Phase the Project Manager has the opportunity to productively use Quality tools, such as Statistical Process Control (SPC). By this time the implementation is complete and the work has transitioned to managing service delivery. The implementation phase may have taken several days, or even years in the case of a large global service or outsourcing project. The conclusion of the transition to the Managing Phase is observed when the service requirements represented by the SLA are being met consistently. A good practice is to maintain Control charts on the measurable service levels. This is useful in establishing consistency and it also provides data with which the service processes may be evaluated and improved. The process orientation of SAO projects and the opportunity to use quality tools and methodologies for continuous process improvement can provide continuing benefit to the Client and maintain profitable operation for the Contractor.

Summary

SAO Projects are a growing segment in the spectrum of project management. Managing the scope of an SAO project is similar to that of a traditional project. The skills and training that a project manager acquires from traditional project management apply to SAO projects. A comprehensive WBS and SOW form the foundation for the project, and become the reference for all parties to measure compliance to requirements and performance of activities. The characteristics that make SAO projects different are (1) the result of the project is service, which is implemented via processes, and (2) a Managing Phase that can extend the life cycle indefinitely as long as the service is competitive and meets the SLAs.

Because an SAO project is concerned primarily with processes, it is appropriate to describe the processes in a summary fashion within the SOW. This is most conveniently done with simple process diagrams. The key required attribute of these diagrams is that they show where contractor activity interfaces with client activity. Where this occurs, the information transfer and the respective roles and responsibilities need to be defined.

The early phases in the life cycle of an SAO project can be extremely short. This tends to compress the time for planning and increase the risk of errors and omissions that can have detrimental effects on the delivery of the service and the project. Extra effort should be made to take time to jointly (Client and Contractor) verify the plan, the processes and their interfaces prior to the commencement of work.

Change Management is a critical feature of an SAO project. During the early life cycle phases, change management is focused on constraining activity to the SOW or modifying the SOW with agreed-upon changes. In the Manage Phase, the focus of change management shifts to include introducing change through process improvement. This is an opportunity for the Project Manager to emphasize the use of Quality tools (such as Statistical Process Control) to facilitate process improvement.

SAO project success, like success on any project, depends on disciplined scope management. It starts with a good foundation, which is an SOW that defines the SLA and the relevant information about the processes to be used in delivering the service, and then rigorously managing change to the scope as service is delivered.