Contact Us for a Free Trial Subscription Read a Sample Issue

HOW PEOPLE DRIVE THE OUTSOURCING PROCESS
(SOMETIMES OFF THE ROAD)

by Dwayne Phillips

The mechanics of the outsourcing process are known [1]. Knowing what to do when is only part of the challenge. The three big problems (as Jerry Weinberg says) are people, people, and people. Therefore, use a basic, proven process and remind your people to remember the people.

PAT, MIKE, AND THE OUTSOURCING DILEMMA

Pat, a maturing project manager, has begun a two-year multimillion-dollar software project. Pat does not have the resources needed for an essential part of the software. She sees a 12-month, million-dollar outsourcing project as the only way to obtain the software.

Mike, Pat's manager, has been through several outsourcing projects and does not like them. Some failed, some succeeded, and the successes were stressful. Outsourcing means turning over an important project to someone outside your control.

The main problem with outsourcing is communication. Outsourcing projects have an additional set of people -- the outsource developers. More people mean more lines of communication, more opportunities for miscommunication, and more misunderstandings and mistakes. Mistakes are much harder to see and fix in outsourced projects.

Nevertheless, Mike realizes that outsourcing is the only way to obtain the needed software in this project. He agrees to the outsourcing project but requires Pat to use a proven outsourcing process and pay close attention to people issues. Those people issues are what caused stress and problems on past outsourcing projects.

A PROVEN OUTSOURCING PROCESS

A proven process for outsourcing projects exists. Figures 1 through 9 summarize this process (see [1] and [4] for a complete description of these concepts). Figure 1 shows the parties involved. The developer is building software for the users. The developer uses the outsource developer to provide all or part of the product. Each of these three parties has a upper management. Pat is our developer, Mike is her manager, Oliver will be the outsource developer, and Hubert is the user.

Figure 1: The parties involved in an outsourced project

Upper Management    Upper Management    Upper Management

Users               Developer           Outsource Developer

Figure 2 shows the outsourcing process. This looks like a waterfall because the waterfall contains the basic steps of any project (requirements, design, build, and test). There are endless variations on the waterfall, and prototyping, evolutions, and spirals can fit in this framework (see [2]). Each stage of the process ends with a major review in which Oliver convinces Pat and Mike that his people have completed the tasks necessary to move forward with the project.

The final step of each stage creates a detailed plan for the next stage. Managing an outsourced project is impossible without detailed plans.

Between the Contract Initiation Review (CIR) and the Preliminary Design Review (PDR), Pat and Oliver must agree on the requirements. Oliver then needs to map the requirements into an architecture or high-level design. Figure 3 illustrates this mapping.¹ The mapping tells Pat that the software will satisfy the requirements and, furthermore, what parts of the software will satisfy which requirements. This map is another key to a successful outsourcing project.

---

Figure 4: Earned value tracking

---

Figure 5: Tracking schedule via completion of tasks

---

Figure 6: Tracking effort via planned and actual man-hours

---

Figure 7: Tracking software size via planned and actual size

---

Figure 8: Tracking and staffing via planned and actual people on the project

---

Figure 9: Tracking quality via found and corrected errors

---

Figures 4-9 show the type of information that Oliver should present to Pat during the project at Monthly Status Reviews (MSRs). The goal of these reviews is to show progress on the product in relation to the plan. Oliver must report on the size of the product, the effort expended (cost), the quality of the product, and progress toward meeting the schedule (see [3]).

This is the process Mike directs Pat to use. He also reminds her to watch people issues, which means ensuring the right motivation, explaining and meeting expectations, staying focused, and obtaining status information.

MOTIVATION: WHY YOU DO THE THINGS YOU DO

The first people issue in outsourcing is motivation. Everyone on the project must want everyone else to succeed. This is not a naïve mom-and-apple-pie statement. Mike has seen projects in which the different parties hated one another. Those projects consumed time and money and delivered nothing usable.

Hubert must want Pat and Oliver to build a great product. Otherwise, he will not tell them what he needs. Pat must want Hubert to be delighted with the product and Oliver to make a profit. Otherwise, she will shortchange both. Oliver must want Hubert to be thrilled and Pat to look like a heroine. Otherwise, he will not have any future business.

No one can succeed alone. If Oliver's people define success as collecting paychecks, they will not do the extra work required to please Pat and Hubert. If Pat wants to squeeze every ounce of life from Oliver by making his people work unpaid overtime, she will receive a product made by tired people (with lots of hidden problems). If Hubert does not answer the endless questions from Pat and Oliver, they will deliver him a crippled product.

Outsourcing projects require the right motivation. These projects involve many strangers working in different places, and often different cities. A sense of urgency and desire is essential.

GREAT EXPECTATIONS: I THOUGHT YOU WANTED IT THIS WAY

Mike knows that the right motivation is necessary but not sufficient for everyone to deliver what everyone else expects. He has seen people bring products to others, only to be greeted with looks of disbelief. Misunderstandings abound in outsourcing projects.

Pat will be in the middle on this issue. First, Hubert will tell her what he wants, but not what he expects. Pat must use prototypes and demonstrations to learn what Hubert expects. These come during the activities prior to CIR. Between CIR and PDR, Pat and Oliver will repeat these activities.

Pat also has the burden of proof in her relationship with Oliver. In the statement of work, or SOW (see Figure 2), Pat tells Oliver what she expects -- what she legally expects. But Mike knows that even lawyers cannot require people to deliver what is really expected. For example, Pat expects to see a software requirements specification (SRS) from Oliver. She says this in the SOW and even requires the SRS to be in a specific standard format. She must also visit Oliver and show him exactly what she has in mind. She must visit Oliver again to review the SRS as Oliver's people are drafting it. Pat can never assume that Oliver understands what she wants. Pat must state and restate her expectations about every product in the project. Mike knows this may wear Pat out, but he will push her to do it. Mike has been burned many times before.

FOCUS: STAY WITH THE PLAN, EVEN WHEN YOU CHANGE IT

Oliver must keep his people focused on doing the tasks in the plan. There are many things happening in a software firm, and people drift. Programmers, wonderfully creative and imaginative people, wander off into creative and imaginative problems instead of working on planned tasks.

Mike once worked with a lead programmer nicknamed Scooter. Scooter was keeping his programmers on schedule in an outsourcing project. He was called out of the office for seven working days, and on his return, he learned that his programmers had completed only two days of work. They had been very busy handling various and sundry problems. They had not, however, focused on the tasks in their plan.

Focusing on and staying with the plan does not mean following the road off a cliff. Pat, Mike, and Oliver will probably need to change the plan several times during the project. The next section explains the right way to make those changes and the reasons for making them. Nevertheless, everyone must work to the current plan. When the plan changes, work to the new current plan.

This tendency to drift has a greater effect in outsourcing projects. Oliver has a contract to deliver software on a date for a price. If his people lose focus, they will be late and over cost. That will reflect badly on his entire company, not just on him and his team. His company could lose many future contracts.

Oliver must talk to every one of his people every day. He needs to know what each of them is doing, if they are progressing, if they are having problems, if they are tired, if they need a break, and so on. At the end of each week, Oliver must know what tasks have been completed, when they started and finished, how many person-hours they required, and how many errors were found and corrected in the product.

Mike knows that Oliver can drift off course. Therefore, Mike requires Pat to know where Oliver is at on a monthly basis. Pat, in turn, must have Oliver report this status to her monthly.

STATUS: SEEING IS BELIEVING AND THEN ACTING

Mike reminds Pat of the basic management formula:

management = plan + status + action

Oliver creates the plans for each phase of the project at the end of the prior phase (see Figure 2). The plan is tied to Figure 3. That figure shows the software Oliver is producing -- the CSCs and CSUs. The plan shows how to complete each part of the software (CSUs) and combine them into larger parts (CSCs) until the whole (CSCIs) is complete. Therefore, progress on the plan is progress on the software. If it is not, the plan is wrong and must be corrected.

Planning is not popular among software people. If an organization refuses to create detailed plans, it should not engage in any part of an outsourcing project. The plan is a realistic (not optimistic) baseline of when people will do what to produce the needed software.

Oliver must report status against the plan. Oliver provides the status to Pat at the MSRs in the plots of Figures 4 through 9. These figures, and the numbers behind them, show the size of the product, the effort expended (cost), the quality of the product, and progress toward meeting the schedule.

The need to communicate monthly status against the plan is an important reason why Oliver must talk to every one of his people every day. That daily status rolls up into weekly status, which rolls up into monthly status. If Oliver waited until the end of the month to collect status information, it would take him a week, and the information would be too old to be useful.

The monthly status tells Pat how far Oliver is ahead of or behind the plan. This information tells everyone when the project will end and how much the software will cost -- if no one takes action.

The reason for reporting status against the plan is to allow Pat and Oliver to make timely, intelligent decisions about the remainder of the project. If one area of the software is easier than expected, they can shift people to another part that is harder than expected. If all the software is harder than expected, they can reduce requirements or obtain more time and money. Mike has learned the hard way that obtaining more time and money is difficult. He has also learned that it is easier if you ask for the time and money early in the project and have real numbers to back up your request.

The wrong reason for gathering status information is to place blame. Pat and Mike are included in action decisions because they, not just Oliver, are responsible for the success or failure of the project. They chose Oliver for the outsourcing effort. They approved his proposal, his plan, and his concept for the software. If Oliver fails, Pat and Mike share the responsibility. Finger pointing does not work in outsourcing. This goes back to the motivation. Either everyone succeeds or everyone fails.

CONCLUSION

Outsourcing projects are difficult because they involve more people from more organizations than inhouse projects. This increases the need for communication and the opportunities for miscommunication and mistakes. There are processes that help with this situation. These processes, however, do not guarantee success, since nothing guarantees success in endeavors that involve so many people.

I've learned a few things to watch for with people in outsourcing projects:

1. Work with people who want everyone to succeed.

2. Never assume that someone else understands what you want.

3. Keep people focused on the task at hand.

4. Obtain regular, frequent status information that shows progress on the product.

5. Use the status information to make timely, intelligent decisions.

Working with people on outsourcing projects can be wonderful, or it can break your heart and your project.

REFERENCES

1. Marciniak, John J., and Donald J. Reifer. Software Acquisition Management. New York: John Wiley and Sons, 1990.

2. Phillips, Dwayne. "How to Make a V-Shaped Spiral -- and Vice Versa." American Programmer, Vol. 10, No. 8 (August 1997), pp. 23-26.

3. Putnam, Lawrence H., and Ware Myers. Measures for Excellence: Reliable Software on Time, Within Budget. Englewood Cliffs, NJ: Prentice Hall, Yourdon Press, 1992.

4. SPMN. The Program Manager's Guide to Software Acquisition Best Practices. Arlington, VA: US Department of Defense Software Acquisition Best Practices Initiative, The Software Program Managers Network, 1996.

NOTE

¹A CSCI is a Computer Software Configuration Item. CSCIs comprise Computer Software Components (CSCs), which comprise Computer Software Units (CSUs).