© Copyright 1998 Cutter
Information Corp. All rights reserved. This artical originally appeared in the July 1998 issue of Cutter IT Journal, and is reproduced here with permission.
HOW PEOPLE DRIVE THE OUTSOURCING PROCESS
(SOMETIMES OFF THE ROAD)
by Dwayne Phillips
The mechanics of the outsourcing process are known . 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
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
A PROVEN OUTSOURCING PROCESS
A proven process for outsourcing projects exists. Figures 1 through
9 summarize this process (see  and  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 ). 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
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.1 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
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 ).
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
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
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
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
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
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.
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
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
Working with people on outsourcing projects can be wonderful, or it
can break your heart and your project.
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.
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.
1A CSCI is a Computer Software Configuration Item. CSCIs comprise
Computer Software Components (CSCs), which comprise Computer
Software Units (CSUs).
Dwayne Phillips has worked as a software and systems engineer with
the US government since 1980. His principal job is to help
development project managers monitor outsourced developers. He
doesn't know anyone named Pat, Mike, Oliver, or Hubert, but he has
experienced their hard knocks too many times. (He does know someone
nicknamed Scooter.) Dr. Phillips's interests include computer
vision, artificial intelligence, software engineering, and
programming languages. He has a Ph.D. in electrical and computer
engineering from Louisiana State University.
Dr. Phillips can be reached at 2315 Ballycairne Court, Reston, VA
20191-1633, USA. Tel: +1 703 476 1951; E-mail:
Back to Top |
Cutter IT Journal |
Cutter Information Corp.
Cutter IT Journal is published 12 times a year by Cutter
Information Corp., 37 Broadway, Suite 1, Arlington, MA 02474-5552.
Tel. +1 781 641 5118 or + 1 800 964 5118. Fax: + 1 781 648 1950 or + 1
800 888 1816. E-mail: firstname.lastname@example.org. Please contact Megan Nields for
more information or for a free trial subscription.
© Cutter Information Corp. All rights reserved. Unauthorized reproduction in any form, including
photocopying, faxing, and image scanning, is against the law.