Managing outsourced projects

Abstract

How many times have you seen in a contractor's GANTT chart a long and intriguing bar generically called, “project management,” spanning from the beginning to the end of the project, and then wondered what deliverables should actually produce that task? How many times has your contractor quickly convinced you that a particular deliverable was “90% complete” and then it remained “90% complete” until the end of the project? How many times have you found that the contractor's goal was to “deliver” a new system, while your true goal was to “make your users use” the new system?

These are some of the issues that distinguish the management of outsourced projects, often characterized by a trial of strength between the client and the contractor, in which each party has his or her own goals and expectations and they don't always match

Frequently, these types of projects have been described from the contractor's point of view. This paper instead focuses on the client's point of view and comes from the real-life experience of the author in companies that have chosen to fully outsource the development of their projects, leaving in-house only the management of the relationship with the contractor.

This paper describes, for each of the nine Knowledge Areas in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), one typical issue of managing outsourced projects. For each issue, it first introduces the client's expectations (what the client expects to happen — “the good”); next it illustrates what actually happens (what the unprepared client risks to receive — “the bad”); and then it proposes a suggested approach (what the client should do — “the savvy”). This paper is based on a “deliverable-oriented” approach, in which everything in the project (from the work breakdown structure [WBS] to the lessons learned) is planned and managed, with reference to the deliverables to be produced by the contractor.

What Outsourced Projects Are (and What Outsourced Projects Are Not)

An outsourced project is a “goal-oriented undertaking of multiple tasks, often interdependent in nature, increasingly involving multiple parties, including customer, principal supplier, supply-chain partners (subcontractors), and other third parties to develop or provide products, services or solutions within a given period of time” (Garret, 2005). An outsourced project is typically made up of three main “ingredients:”

• The client (or “customer” or “buyer”), the organization that pays for the “product, the result or the capability to perform a service” (Project Management Institute, 2008) to be built within the project;
• The contractor (or “seller”), the organization that gets payed by the client to build the product, the result or the capability to perform the service needed;
• The contract, “a mutually binding agreement that obligates the seller to provide the specified product or service or result and obligates the buyer to pay for it” (Project Management Institute, 2008). The contract defines the scope of the project, the deliverables to be built, the timing of the main activities, the acceptance criteria and the price to be given to the contractor by the client. There are different types of contract: fixed-price, cost-reimbursable, and time and material. Although this paper focuses mainly on “fixed-price” contracts, it should apply as well to the other types of contracts.

An outsourced project typically differs from an “in-house” project in the fact that either the client hasn't the necessary skills and competencies to build the product needed or that buying the solution is less costly and more effective than building the solution (Wysocki, 2009), so the client decides to ask someone else to plan and execute the project, while keeping the job to validate and accept the final result.

For the purpose of this paper, the following cases are not considered outsourced projects:

• The case of a client buying “time and material” consultants from an external consultancy firm, where the client project manager directly manages the consultants: this is the case of an “in house” project that uses external resources, but is internally managed;
• The case of a client buying serialized products from a supplier (this is not a project at all, because it relates to a product that lacks the “uniqueness” that characterizes a project result).

In an ideal world, the client and the contractor have a common interest: to build a product that is compliant with the requirements of the client, so that the client will get what he or she needs and the contractor, while getting the price agreed on, will continue to do business with the client.

In “hard reality,” the client and the contractor have many conflicting interests, such as:

• Sometimes the real interest of the client is not the product itself (i.e., the “project objective”), but an underlying “business objective” (Weigers, 2003) that he or she wants to reach with the new product. For example, if a client asks a contractor to redesign his or her Internet site, the renewed Internet site itself could be only a means to reaching new customers and expanding the business. In this case, concentrating only on the project objective, without knowing or caring about the real business objective, could lead to a result that is unsatisfactory for the client (e.g., a new Internet site that is not suited for new customers);
• The client wants the best possible quality for the product to be built, whereas the contractor (especially for fixed-price contracts) tends to minimize the effort spent on the project;
• The client expects the contractor to dedicate his or her best resources on his project, whereas the contractor has many projects in execution for different clients; therefore, he or she needs to balance his or her own best resources among these projects.

Although many publications describe outsourced projects from the contractor's point of view, this paper focuses on the client's point of view and comes from the real-life experience of the author in companies that have chosen to fully outsource their projects (mostly software development projects), leaving in-house only the management of the relationship with the contractor.

In the next part of this paper, for each of the nine Knowledge Areas of the PMBOK^® Guide (Project Management Institute, 2008), there is one description of one typical issue of managing outsourced projects. The following format is used to present each issue:

• The Good is what the client normally expects to happen (i.e., the “ideal world”);
• The Bad is the client's perception of what actually happens (i.e., the “hard reality”); and
• The Savvy is the suggested approach (i.e., what the client and the contractor should do to prevent the issue).

Nine Outsourcing Tips for Nine Knowledge Areas

1. Scope: Keep the “Empty Boxes” out of Your WBS

The Good: The client normally expects the contractor to present a comprehensive WBS, which enlists all the deliverables necessary to build the product. Furthermore, the client expects that the WBS will contemplate task and deliverables for all the applicable Project Management Knowledge Areas (e.g., Risk Management, Communication Management, Human Resource Management, etc.).

The Bad: Often, the WBS presented by the contractor is full of “generic” work packages such as “Project Management,” “Risk Management,” and “Communication Management” (Exhibit 1), but it is not clear what the specific deliverables to be produced in each work package are. These generic WBS elements are often “empty boxes,” because they do not produce any deliverable: they are useless for monitoring and controlling, because there is no way to measure their progress. The main cause of these “empty boxes” is that the contractor wants to demonstrate to the client that he has properly taken account of all the project management aspects but he is reluctant to commit himself to any of the specific deliverables needed to carry out these tasks. For the same reason, the contractor tends to omit the description of any of the “ancillary project deliverables, such as project management reports and documentation” (PMI, 2008).

Exhibit 1 – A WBS with “Empty Boxes”

The Savvy: To avoid the problem, ask yourself: “What are the specific deliverables I will need to build the product and to operate it?” and request a “truly deliverable oriented” WBS; in other words, a WBS in which the lowest elements (or “work packages”) are “true” deliverables. For example, if there is a work package generically called, “Project Management,” it should be further decomposed in all the specific project management deliverables you expect from the contractor (e.g., “Project Management Plan,” “Issue Register,” etc.). Similarly, if there is a work package called generically, “Communication Management,” it should be decomposed in all the specific communication deliverables to be provided by the contractor (e.g., “Communication Plan,” “Project Monthly Newsletter,” “Monthly Stakeholders Meeting Minutes,” etc. (Exhibit 2).

At the end of this process, you should have gotten rid of all the WBS elements that do not have a measurable deliverable (that is a “truly deliverable oriented” WBS): this will be the foundation of the capability to objectively measure the progression of the project.

Exhibit 2 – A “Truly Deliverable Oriented” WBS

2. Quality: No Quality Without Metrics

The Good: The client normally expects the contractor to produce “high quality deliverables”; similarly, the contractor tends to fill his bid with “high quality” promises and references that demonstrate the “quality” he is capable of delivering.

The Bad: When the time of the final delivery of the product comes, no one agrees on the meaning of the word “quality” (Weigers, 2007). The client tends to get the maximum out of the product, whereas the contractor has the interest to consider as a “change request” every deviation from the actual built product: this translates into endless negotiations between the two parties.

The Savvy: The only way to avoid misinterpretation in the meaning of quality is to define in advance and in a measurable way what the expected quality of every deliverable to be produced is. The key words of the previous sentence are “in advance,” “measurable way,” and “for each deliverable,” which means that, before starting to build the product (or better, if possible, before awarding the contract), the client should define, for each deliverable (and also for each “ancillary project deliverable”), the way he will measure quality. This means finding one or more metrics that will be used to measure the quality of each deliverable, where a metric is a numerical value assigned to an attribute (e.g., the response time of a system to a specific input, the number of bugs found in a software module, the number of testing iterations expected, etc.). This is hard work for the client, but it pays off when it is time to evaluate the final product, because it avoids any dispute in accepting the product and also it makes clear to the contractor when each deliverable is ready to be submitted, reducing the temptation of “gold-plating.”

3. Time: Plan to Rework to Avoid Reworking the Plan

The Good: The client expects the contractor to submit every deliverable in advance, so he will have adequate time to review and approve it. The client claims that the time needed to review and approve each deliverable is correctly taken into account in the GANTT chart produced by the contractor.

The Bad: Often the project GANTT chart produced by the contractor has only one bar for each deliverable; therefore, the contractor takes all the time planned to produce the deliverable and submits it near the last day—little or no time remains for the client to review, correct, and approve the deliverable. If the project has an “immovable” deadline, this results in the following dilemma for the client: accept a faulty deliverable or delay the project? This situation implies two common omissions: the first is that the activity of approving a deliverable takes time and the second is that the first version of a deliverable almost always needs something to be corrected. The average project manager spends about 80% of his or her time on unplanned rework (McConnell, 1998). In his professional experience, the author has never been given a first version of a project deliverable that was perfect and that didn't need some kind of correction; so, omitting to plan at least one rework cycle is condemning us to reworking the plan!

Exhibit 3 – “One GANTT bar” deliverables

The Savvy: In order to reduce the risk of project delays, the policy to plan adequate time for the rework cycle of each deliverable is very effective (Weigers, 2007). In the author's professional experience, the consistent use for each deliverable of the following sequence of activities has proved particularly useful:

• Production
• Review
• Correction
• Approval

The key aspect here is to break down the GANTT bar of each deliverable into four separate GANTT bars, one for each of the previously enlisted activities. Furthermore, for the riskiest deliverables (e.g., the deliverables that are likely to contain defects, like software modules, functional requirements specifications, etc.), a good practice is to plan more than one “review-correction-approval” cycle, in order to take into account the higher probability of finding new defects in each cycle.

Exhibit 4 – The “review-correction-approval” cycle for each deliverable

4. Cost: The “90% Complete” Syndrome

The Good: The client expects he can objectively judge the progress of the project. He is also confident that, in the execution phase of the project, he and the contractor will easily agree on the completeness percentage of the deliverables.

The Bad: Close to the planned delivery date, the contractor affirms that the project is “almost 90% complete,” but then it remains “almost 90% complete” until the end; this is commonly known as the “90% complete” syndrome. The causes of this problem are as follow:

• To judge the progress of the project, only a rough impression is used;
• The closeness of the delivery due date optimistically alters the perception of the remaining work to be done; and
• There is a natural discomfort of the contractor's project manager to communicate a delay to the client.

Furthermore, the client and the contractor have a huge different perception of the completeness of the product: the client has a 0%-100% scale (i.e., because the product can't be used until it is finished, the client considers it 0% complete until the final acceptance), whereas the contractor has a perception of the completeness of the product that's proportional to the man hours spent working on it divided by the man hours estimated.

The Savvy: A way to overcome the “90% complete syndrome” is to apply the following practice:

1. Assign to each deliverable of the WBS a fraction of the total cost of the project, proportional to the number of man hours estimated for of each deliverable; and
2. Assess the completeness of each single deliverable, using an objective completeness criterion.

There are many kinds of objective completeness criteria and the following ones are the most common:

• 0-100: the deliverable is 0% complete until final acceptance;
• 50-50: the deliverable is 50% complete at the start of production and it gets 100% at final acceptance; and
• Units complete: the percentage of completeness of the deliverable is proportional to the number of a particular unit produced (e.g., the number of the lines of code, the number documentation pages, etc.).

Given the “deliverable review cycle” presented earlier (production, review, correction, and approval), in the author's professional experience, the following deliverable completeness criteria are the best compromises between the two parties’ expectations:

• 20% when the contractor starts working on the deliverable;
• 60% when the client finishes the review and the contractor has to make only minor corrections to the deliverablet; and
• 100% when all the comments have been incorporated and the deliverable is approved by the client.

In this way, the contractor gets a consistent advance payment at the beginning of the work (20%), he gets more than half of the value of the deliverable when he has to make only minor corrections to the deliverable (60%), but he's still motivated to make all the corrections to get the client's final acceptance (100%)..

5. Procurement: The Carrot and the Stick

The Good: The client always expects the contractor to strive to deliver on time. He assumes that the principal interest of the contractor is to make the client happy, despite the cost necessary to achieve his satisfaction.

The Bad: In a fixed-price contract, if the contractor starts spending more than was planned, he will begin to lose money and, if there are no penalties, he will progressively leave the client to “his destiny.” This is a common situation that arises when the contractor has failed to estimate the effort of the contract and there is no way he can cut the scope to accommodate for the mistaken estimates. The effect is that, in the beginning, the client will notice that the more valuable resources of the contractor will show up less often, while, at the end, when it will become clear to everyone that the initial estimates where mistaken, the contractor will leave only novice resources to work on the project.

The Savvy: In order to reduce the risk of getting practically abandoned by the contractor, remember to incorporate in a fixed-price contract a balanced set of bonuses and penalties (i.e., “carrots and sticks”): the bonuses encourage the contractor to deliver in advance, and the penalties discourage the contractor to endlessly delay the delivery. For example, you could think of a financial bonus for each day the contractor delivers in advance and at the same time a financial penalty for each day of delayed delivery. The same concept could be replicated with regard to the quality of the deliverables: for example, you could contemplate a bonus/penalty for the limited/excessive defectiveness of the deliverables (like software modules).

6. Communication: No Sponsor, No Party!

The Good: The client expects that once a new product is delivered, users will love and use it. There is a natural tendency in the client to assume that the final users of the new product will love it, just because it has been designed to fulfill their needs and it works just “as designed.”

The Bad: Often the new product goes live, but the final users don't want to use it. The causes of this rejection could be very different, like the natural resistance to change, cultural issues, communication deficiency, and so on. This is especially true in the cases of internal projects, where users are “forced” to embrace a new system and to change the way they work, without any evident benefit. Moreover, the principal interest of the contractor is to satisfy his direct client: he has no immediate interest in satisfying the final users of the product to be built.

The Savvy: In the author's professional experience, the key factor in getting user acceptance is upper management sponsorship: “No sponsor, no party!” You should strive in every way to get upper management sponsorship or no one will follow you. Of course it is important to dedicate attention to communication and organizational change management, but without a committed sponsor, no user will ever consider embracing any change: If the boss doesn't believe in the proposed change, why should the final user do so?

7. Human Resources: Put the Contractor in Your Shoes

The Good: The client expects the contractor to share the same goal. A comprehensive statement of work has been compiled and a detailed contract has been stipulated, so the work to do is clear to all the involved parties.

The Bad: Although the contractor's objective is to deliver a new product (i.e., the “project objective,” like a new information system, a new process, etc.), the (often unstated) client's goal is to reach a “business objective.” Clients start projects to reach business objectives like increasing revenues, cutting costs, complying with regulations, etc., not just building a new product. If the contractor isn't conscious of the real business objective, there is a high risk that the product he will build won't help to reach it.

The Savvy: You should try to “put the contractor in your shoes.” This could be done in two ways: first by clearly explaining your business objective to your contractor and, second, by linking contractor penalties and bonuses to the achievement of your business objective. For example, if your business objective is to increase sales by 10% and you plan to reach this increment by developing a new customer relationship management software, you should contemplate a percentage of the payment of the contractor at the delivery of the new system and a percentage after six months from the delivery, only if the sales have increased by at least 10%. In this way, the contractor will strive to build a customer relationship management software that will attract new customers, helping you to reach your business objectives.

8. Risk: Risk Management Should Have a Cost

The Good: The client and the contractor have identified a lot of risks and, after that, qualitative and quantitative analyses have been made to prioritize the “riskiest risks.” A risk response plan for each identified top risk has been developed: the client expects to be secure from any “known unknowns.”

The Bad: In “hard reality,” although there is a detailed risk register containing a long list of prioritized risks and correspondent risk response plans, no actual time and money are set aside to put the risk response plans in action. Similarly, no risk mitigation activities are incorporated in the project GANTT to reduce the probability of the risk and, similarly, there are no buffers to compensate for the delay, when the risk materializes. This is a situation that happens, for example, when the project GANTT is developed and approved (sometimes even included in the contract!) before completing the risk response plan.

The Savvy: To avoid bad surprises during project execution, risk response plans should be incorporated into the project GANTT (e.g., adding risk response tasks) and in the project budget (e.g., adding budget for risk response tasks). Of course, in this way, the total length of the project is likely to increase (just as the total project cost), but by doing so, the savvy project manager will probably soundly. In fact, in the rare case of not having any risk to materialize, the project probably will be completed before time and under cost. In the usual case of the materialization of some risks, the project manager has the time and budget to handle it.

9. Integration: No Checklist, No Lessons Learned!

The Good: At the end of the project, a “project retrospective” has been done with all the stakeholders involved (internal and external). A long list of “lessons learned” has been developed and saved in the “lessons learned database,” so the client expects to repeat successful practices and to avoid mistakes in the next project.

The Bad: When the next project begins, no one looks into the huge lessons learned database and the same mistakes are repeated again and again. This happens mainly because it is very time consuming to find the right lesson learned for the specific work you have to do at the moment. Furthermore, in the beginning of a new project, the project team is oriented to the future and looking back to previous projects seems only like a way to distract from the work to be done.

The Savvy: In the author's experience, the best use of your “lessons learned” is doing the following:

1. Relate every lesson to a specific type of deliverable (e.g., classify lessons for time plans, lessons for budget, lessons for risk response plans, etc.)
2. Create a checklist for each type of deliverable (a kind of “deliverable checklist”; e.g., “Time Plan Checklist,” “Budget Checklist,” “Risk Response Plan Checklist”, etc.)
3. Incorporate the lessons learned in all the relative “deliverable checklists”

In this way, you will have a deliverable checklist for each of the planned deliverables. Before working on a specific deliverable, it will be very easy to open the checklist and see how the experience from the past can help you with the specific work you have to do at the moment. Given the number of previous experiences to take into account and the frequent lack of time in executing projects, one could say that “if a lesson is not in the right checklist, you have not learned it”.

Conclusions

Managing outsourced projects is quite different from managing “in house” projects and requires adequate skills and knowledge to pursue a win-win strategy rather then ending up with wasteful conflicts between client and contractor.

Because of the author's professional experience, this paper intentionally focuses on the “client's point of view,” but by no means does this paper intend to blame the figure of “the contractor” or to assume that the client is “the good” and the contractor is “the bad.” It must be stated that a successful outsourced project can only result from a “win-win” relationship (Covey, 1990) between the client and the contractor and that only a “savvy” balance of the interests of both the parties can lead to a mutual satisfactory project result.