Often, “operations” and “projects” involve separate concerns—but this isn't always the case. The distinction is not as important for those who handle service and outsourcing (SAO) projects, because near the conclusion of implementation, project activities also include operations.
As SAO projects move toward the delivery of service, project managers must focus on moving from “traditional” project activities to those associated with successful operations, such as financial performance (cost and revenue) and quality.
Emphasis on Quality
A number of tools are used throughout projects to examine performance quality (see sidebar: “A Quality Method”). Because SAO projects are process-oriented, they often are best described with process flow diagrams. The statement of work (SOW), which normally describes “what” work the project entails, also will express the quality levels for performance of the service. Usually, these are incorporated into the service level agreement (SLA) and constitute a specification for quality.
Traditionally, customer satisfaction in SAO projects has been determined through surveys, interviews and complaints. Dissatisfaction may exist for a variety of reasons, but most frequently, it comes from a failure to meet the SLA, which is the quantitative specification, usually contractual, for the delivery of the service. It expresses the required end result of the service delivery process but generally has no direct connection to process quality.
During implementation, the quality of the project is judged by the more traditional attributes of project performance: conformance to budget, schedule constraints and the efficiency with which the service delivery processes are implemented. As the project moves into operations, the question “Are the service delivery processes meeting the SLA?” becomes very important, and no one wants to wait for surveys or complaints for the answer.
This is where quantitative reporting of the key process variables' performance can play a major role. Analysis of these measurements will indicate the processes are coming into control and that the control limits (CLs) are aligning with the SLA.
Operational Nature
As implementation is completed, the SAO project is predominately operational; service delivery processes are being performed consistently and the collection of data on key variables can be accomplished. The primary quality tools at this time are:
- Flow charts for definition of the processes
- Control charts for monitoring and predicting event performance.
Other quality tools may be employed, but these will determine the performance of the project relative to the requirements and to establish a basis for continuous improvement. The flow charts should describe the process in a way that indicates the key process variables in the SLA and the steps that affect them. The control charts are necessary to maintain a history of the key process variables so that they may be analyzed to define the CLs and establish that the process is under control.
Service delivery in an SAO project normally is composed of a standard set of processes repeated over and over again. Service delivery processes can be described visually in a flow chart for analysis and optimization. Process descriptions of service delivery should be simple and align with the contractual requirements. The contract, including the SOW, focuses on the work to be performed and the SLA. The process description identifies key variables that correspond to the SLA, showing the interaction of the various stakeholders. In most cases, this involves just the interaction between the service provider and the customer.
A QUALITY METHOD
The characteristics of the SAO project life cycle, particularly the extended manage phase with its operations orientation, allows the use of statistical process control to objectively determine the quality of service delivery. Common tools used to gauge project performance include:
Surveys (Subjective). Surveys establish the customer's sentiment and perceptions, but the results often are late in determining a problem or issue. Surveys also are subject to bias by design of the questions and interpretation of the results.
Measurements (Objective). Measurement of key variables may be subject to error from the measuring process but otherwise portrays an accurate view of the performance of the project. Measurement of key variables offers the opportunity to create control charts that may be used to determine process capability and establish that the process is in control.
Process Flow Charts. Process flow charts are useful tools to document and develop processes. In SAO projects they can provide a view of the steps in the process that indicate the activities of the participants, including the interaction of the customer and the service provider. Each step will have inputs and outputs, and some of the outputs must correspond directly to the variables of the SLA.
Control Charts. Control charts are used to monitor the variation of key process variables. They provide an unambiguous view of the performance of the project. Control charts can be analyzed using statistical techniques to distinguish between special and common cause variation, CLs and process capability, and they provide a common quantitative language for discussing and improving process performance. This statistical analysis forms the basis of SPC of SAO projects.
REMEDIAL PC MAINTENANCE
Consider this example of service delivery for the maintenance of computer equipment that is frequently encountered by Compaq:
The personal computer purchaser (client) requires that the contractor (service provider) offer maintenance of desktop computing equipment but wants to take the first call from an end user. The client also sets the SLA at a level that will satisfy the expectations of the end user regarding response time and resolution time. The process-flow diagram for this situation is shown in Exhibit 1.
The client takes the first call from the end user, and the call is passed to the contractor if the problem appears to be related to the equipment. Frequently, the problem can be fixed during a phone call with the end user, but sometimes a technician must be dispatched to fix the problem. For both scenarios, there are expectations for resolution, and response time and resolution time are defined as the SLA. As service events occur, response and resolution times are recorded (Exhibit 2). Since some don't meet the SLA, there may be an issue.
An evaluation of the events using a control chart and determining the CLs (Exhibit 3) shows that the process will normally deliver events outside the two-hour SLA. This may still be an issue, but there now is an objective basis to review the process and introduce changes that will close the CLs, negotiate adjustment of the SLA or just come to a mutual understanding of the relationship between the capability of the process and the SLA.
Examination of the events suggests that there may have been a change in the process in the neighborhood of Event 8. Recalculation of the CLs is done for events subsequent to Event 8 (Exhibit 4). Recalculation produces revised CLs.
Using these quality tools allows action before customer satisfaction becomes an issue. The flow chart in Example 5 shows that the customer also is involved, so dialogue could include changes to the customer's portion of the process as well as the service provider's activity.
If no process improvement changes were made, it would be difficult to stay competitive with lower costs, greater efficiency or both.
Exhibit 1. Example of Help Desk Process with SLA
This simple process flow diagram shows only the major steps and the key variables, response time and resolution time. Care is taken to distinguish between those steps that are done by the client and the contractor.
Exhibit 2. Sample Events of Resolution Time 1
The recorded events for resolution time 1 (for fix by phone) could look like the table shown. Events 4 and 18 are outside the SLA. There is nothing about the data in this table for Resolution Time 1 events that suggests anything about the capability of the process or for an event greater than two hours abnormal.
Exhibit 3. Control Chart for Resolution Time 1
The control chart is developed by a tool called “VectorMaker” that is included in a course on statistical process control provided to Compaq by Associates in Process Improvement (API), Austin, Texas, USA, accessible at www.apiweb.org. The dashed lines in the control chart are the upper and lower (3 sigma) CLs and are indicative of the process capability. The red line is the two-hour SLA.
Exhibit 4. Control Chart for Recalculated Limits for Resolution Time 1
Event 18 now is outside both the SLA and the UCL. This event is a special cause event that requires an explanation.
The customer wants an accurate description of the processes and methodology that leads to continuous improvement. The process descriptions must show customer involvement, including all steps where the customer and the service provider directly interact. Control charts allow the customer and the service provider to monitor the effect of process changes on the CLs.
When process flow diagrams are developed, key variables must correspond to the SLA. Then, as the control charts predict the CLs, a direct visual comparison can be made between the CLs and the SLA. The process operation itself defines the CL and the SLA as arbitrary values, usually specified in the contract. An initial comparison will tell if the service delivery processes are meeting the contractual agreement or if the service is being over- or under-delivered. This objectively establishes the quality of the service delivery processes, as opposed to subjective surveys.
Traditionally, customer satisfaction in SAO projects has been determined through surveys, interviews and complaints. |
The Fate of Stable Processes
Quality management aims to maintain stable processes. This usually satisfies the letter of the contract, but, if this is done over the life of the contract without process improvement changes, the service provider may find that competitors have introduced innovations that allow the service to be performed better and at a lower cost.
The customer and the service provider both want continuous improvement. When the processes are in control, both must actively work together to identify, test and implement changes to the processes that will either tighten the CLs or reduce costs. A variety of quality tools support this effort and identify prospective changes—but the change management process should handle all modifications overall.
For the Better…
The long life cycle of the SAO project places an increased requirement for good documentation in change management. An overview of the change process is shown in Exhibit 6.
Modifications may be proposed by anyone involved in the project, but the project manager is responsible for seeing that these proposals adequately describe the change, its objectives and impact. If it is agreed that the request is an improvement, then the change proposal is converted to a change order for implementation.
Change orders are reflected in changes to the contractual statement of work. The project manager should maintain a log of all the change proposals, including their status and final disposition. Control charts are analyzed to assess the effects of the change. Generally, the expectation is that either the CLs tighten or they remain the same and the service is delivered at a net lower cost. PM
Max B. Smith, PMP, has managed projects in the information technology, petrochemical, chemical, manufacturing, and aerospace industries. A graduate of the University of California, Los Angeles, Smith founded PMI's Service and Outsourcing Specific Interest Group.
Exhibit 5. Change Management Process for Continuous Improvement
With objective measures, process capability will be redefined to bring about the continuous improvement that is essential to overall customer satisfaction and profitability for the contractor.