IEEE Computer, May 1998
"The Power of Process"
How do you convince people to pay attention to their
software development processes?
The word "process" is viewed as a four-letter word by some
people in the software development community. These people see "Software
Processes" as rigid, restrictive, and inefficient. They hold that the best way to run
a project is to hire the best people you can, give them all the resources they ask for,
and turn them loose to do what they do best. According to this viewpoint, projects that
run without any attention to process can run extremely efficiently. People who hold this
viewpoint imagine a work breakdown over the course of a project like the one shown in
People who hold this view acknowledge that some amount of
"thrashing," or unproductive work, will take place. Developers will make
mistakes, they agree, but they will be able to correct them quickly and
efficientlycertainly at less overall cost than the cost of "Process."
The phrase "software processes" can
mean a lot of different things. Here are some examples of what I mean by "software
- Committing all requirements to writing.
- Using a systematic procedure to control additions and changes to the products
- Conducting systematic technical reviews of all requirements, designs, and source code.
- Developing a systematic quality assurance plan in the very early stages of the project
that includes a test plan, review plan, and defect tracking plan.
- Creating an implementation plan that defines the order in which the products
functional components will be developed and integrated.
- Using automated source code control.
According to the view expressed by Figure 1, adding processes like
these, as is shown in Figure 2, is pure overhead and simply takes time away from
This point of view has intuitive appeal. At the beginning of a project
(shown by the darker shaded areas), a focus on process certainly does take time away from
productive work. If that trend were to continue throughout a project (shown by the lighter
shaded areas), it wouldnt make sense to spend much time on process.
Experienced View of Process
Based on software industry experience, however, for medium and large
projects the trend shown in Figure 2 does not continue throughout the project. Projects
that dont pay attention to establishing effective processes early are forced to slap
them together late, when slapping them together takes more time and does less good. Here
are some examples:
- In the middle of the project, team members agree informally to implement a wide variety
of changes that are proposed to them directly by their manager or customer. They
dont begin controlling changes systematically until late in the project. By that
time, the scope of the product has expanded by 25 to 50 percent or more, and the budget
and schedule have expanded accordingly.
- Projects that dont set up processes to eliminate defects in early stages fall into
seemingly interminable test-debug-reimplement-retest cycles. So many defects are
discovered that, by the end of the project, the "change control board" or
"feature team" may meet as often as every day to prioritize defect corrections.
Because of the vast number of defects, the software has to be released with many known
(albeit low priority) defects. In the worst case, the software might never reach a level
of quality good enough to be released.
- Alternatively, major defects discovered late in the project can cause the software to be
redesigned and rewritten during testing. Since no one planned to rewrite the software
during testing, the project deviates so far from its plans that it essentially runs
without any planning or control.
- Defect tracking isnt set up until late in the project. Some reported defects go
unfixed simply because they are forgotten, and the product is released with known defects
that could have been fixed easily.
- Components developed by different developers are not integrated with each other until
the end of the project. By the time the components are integrated, the interfaces between
components have gotten out of synch, and much work must be done to bring them back into
- Source code revision control isnt established until late in the project, after
developers have begun to lose work by accidentally overwriting the master copies of their
own or each others source code files.
- Because the project is having schedule trouble, developers are asked to reestimate their
remaining work as often as once a week or more, taking time away from their development
When a project has paid too little early attention to the processes it
will use, by the end of a project developers feel they are spending all of their time in
meetings and correcting defects and little or no time extending the software. They know
the project is thrashing. When developers see they are not meeting their deadlines, their
survival impulses kick in and they retreat to "solo development
mode"focusing exclusively on their personal deadlines. They withdraw from
interactions with managers, customers, testers, technical writers, and the rest of the
development team. Project coordination unravels.
Far from the steady level of productive work suggested by Figure 1, my
observation is that the medium or large project conducted without much attention to
development processes typically experiences the pattern shown in Figure 3.
In this pattern, projects experience a steady increase in thrashing
over the course of a project. By the middle of the project, the team realizes that it is
spending a lot of time thrashing and that some process would be beneficial. But by then
much of the damage has been done. The project team tries to increase the effectiveness of
their process, but their efforts hold the level of thrashing steady, at best. In some
cases, the late attempt to improve the projects processes actually makes the
The lucky projects release their products while they are still eking
out a small amount of productive work. The unlucky products cant complete their
products before reaching a point at which 100 percent of their time is spent on process
and thrashing. After spending several weeks or months in this condition, these projects
are typically cancelled when management or the customer realizes that they are no longer
moving forward. If you think that attention to process is needless overhead, consider that
a canceled project has an overhead of 100 percent.
Process to the Rescue
Fortunately, an attention to software development process provides an
alternative to this dismal scenario. When effective processes are used, the project
profile looks like the one shown in Figure 4.
During the first few weeks of the project, the process-oriented team
will seem less productive than the process-phobic team because the level of thrashing will
be the same on both projects and the process-oriented team will be spending a significant
amount of its time on processes. But an investment made in process at the beginning of the
project produces large returns later in the project.
By the middle of the project, the team that focused on process early
will have reduced the level of thrashing compared to the beginning of the project, and
will have streamlined its processes. At that point, the process-phobic team will be just
beginning to realize that thrashing is a significant problem and just beginning to
institute some processes of its own.
By the end of the project, the process-oriented team will be operating
at a high-speed hum, with little thrashing, and performing its processes with little
conscious effort. It will tolerate a small amount of thrashing because eliminating the
last bit of thrashing would cost more in overhead than would be saved. When all is said
and done, the overall effort on the project will be considerably lower than the effort of
the process-phobic team.
Organizations that have explicitly focused on improving their
development processes have, over several years, cut their times-to-market by about
one-half and have reduced their costs and defects by factors of 3 to 10.
Over a 5 year period, Lockheed cut its development costs by 75
percent, reduced its time to market by 40 percent, and reduced its defects by 90 percent
(Alfred M. Pietrasanta, "A Strategy for Software Process Improvement," Ninth
Annual Pacific Northwest Software Quality Conference, October 7-8, 1991, Oregon Convention
Center, Portland, OR).
Over a 6.5 year period, Raytheon tripled its productivity and
realized a return on investment (ROI) in process improvement of almost 8 to 1 (Raytheon
Electronic Systems, Advertisement, IEEE Software, September 1995, back
cover, Hossein Saiedian and Scott Hamilton, "Case Studies of Hughes and
Raytheons CMM Efforts," IEEE Computer, January 1995, pp. 20-21).
Bull HN realized an ROI of 4 to 1 after four years of software
process improvement, and Schlumberger realized an ROI of almost 9 to 1 after 3.5 years of
software process improvement (James Herbsleb, et al, Benefits of CMM Based Software
Process Improvement: Initial Results, Pittsburgh: Software Engineering Institute,
Document CMU/SEI-94-TR-13, August 1994).
NASAs Software Engineering Laboratory cut its average cost per
mission by 50 percent and its defect rate by 75 percent over an 8 year period, while
dramatically increasing the complexity of software used on each mission (Victor Basili et
al, "SELs Software Process Improvement Program," IEEE Software,
November 1995, pp. 887).
Similar results have been reported at Hughes, Loral, Motorola, Xerox
and other companies that have focused on systematically improving their software processes
(Hossein Saiedian and Scott Hamilton, "Case Studies of Hughes and Raytheons CMM
Efforts," IEEE Computer, January 1995, pp. 20-21; Myers, Ware, "Good
Software Practices Pay OffOr Do They?" IEEE Software, March 1992, pp.
96-97; Herbsleb, James, et al, "Software Process Improvement: State of the
Payoff," American Programmer, September 1994, pp. 2-12.).
Heres the best news. The average cost of these improvements was
only about 2 percent of total development coststypically about $1,500 per developer
per year (Herbsleb, James, et al, Benefits of CMM Based Software Process Improvement:
Initial Results, Pittsburgh: Software Engineering Institute, Document
CMU/SEI-94-TR-13, August 1994).
Process vs. Creativity and Morale
One of the common objections to putting systematic processes in place
is that they will limit programmers creativity. Programmers do indeed have a high
need to be creative. Managers and project sponsors also have a need for projects to be
predictable, to provide progress visibility, and to meet schedule, budget, and other
The criticism that systematic processes limit developers
creativity is based on the mistaken idea that there is some contradiction between
developers creativity and the satisfaction of management objectives. It is certainly
possible to create an oppressive environment in which programmer creativity and management
goals are placed at odds, and many companies have done that, but it is just as possible to
set up an environment in which those goals are in harmony and can be achieved
Companies that have focused on process have found that effective
processes support creativity and morale. In a survey of about 50 companies, only 20
percent of the people in the least process-oriented companies rated their staff morale as
"good" or "excellent" (James Herbsleb, et al, "Software Quality
and the Capability Maturity Model," Communications of the ACM, June 1997, pp.
30-40.) The responses listed were consistent across managers, developers responsible for
process improvement, and general senior technical staff members. In organizations that
paid more attention to their software processes, the proportion of people who rated their
staff morale as "good" or "excellent" jumped to 50 percent. And, in
the most process-sophisticated organizations, 60 percent of the people rated their morale
as "good" or "excellent."
Programmers feel best when theyre productive. Programmers dislike
weak leadership that provides too little structure to prevent them from working at cross
purposes and, in the end, causes them to spend more time fixing defects than creating new
software. Good project leadership puts a focus on process that allows programmers to feel
incredibly productive. Developers, their project, and their organization all reap the
About the Author
Steve McConnell is Chief Software Engineer at Construx Software
Builders and Editor of IEEE Softwares "Best Practices" column. This
article was adapted from his book, Software Project Survival Guide (Microsoft
Press, 1998). Contact him at firstname.lastname@example.org.