PEOPLE, PROCESS, AND PRODUCT

by Dwayne Phillips

The key to increasing the chances of success on software projects is to maintain the proper relationships among people, process, and product -- the three "Ps." Our community has discussed each P at length, but we rarely address their relationships. When given one or two of the Ps, the challenge is to consider and select the others accordingly.

A DISASTROUS PROJECT

I was once on a project that ended in complete disaster ($18 million down the drain). We were to build a very powerful digital signal processing (DSP) system using parallel processors This required software to control and coordinate data and subroutines on the parallel processors -- a difficult product. The people chosen for the project were DSP experts who knew the details of the processing routines. Management used the strict waterfall process model (requirements, design, code, integration, test system) with control gates between each project phase. The project could not move to the next phase until the previous one was 100 percent complete (no code until the design was done, etc.). Disaster resulted at the integration phase, because the source code components would not integrate.

What went wrong? This was a difficult product, but the people were experts and were using a proven process. The problem was that the three Ps did not fit each other -- the relationships were wrong. The people were wrong for the product. They knew DSP, but they did not know anything about communication and coordination among independent tasks. The process was wrong for the product. No one had ever tied these types of processors together in this architecture. Since the process disallowed coding until design was finished, no one wrote any code to see if the processors would communicate until we were $15 million into the project.

THE FOLLOW-ON PROJECT

I was fortunate to be on the follow-on project to the disaster. The task was to build a very powerful DSP system using parallel processors. This, too, was a difficult task. This time, the people were mediocre programmers who knew some software engineering and a little DSP. We did, however, have access to DSP experts.

Our process involved a series of deliveries. The first product we delivered would perform all the DSP functions correctly but would not use much of the parallel processor power. Each subsequent delivery would use more of the parallel processor power. This process allowed us to learn how to use the parallel processors while providing our customers functional software. All the power of the hardware came in the fourth and final delivery. The follow- on project cost $6 million, and the final system did more than the original system could ever have done.

This project succeeded because the people and process fit the product -- the relationships were right. The project needed people who knew something about communicating processes -- not signal processing, because there were plenty of DSP experts on hand in the customers. The unique hardware architecture required a process that allowed experimentation and learning.

THE THREE Ps

People

The primary element of any project is the people. People gather requirements, people interview users (people), people design software, and people write software for people. No people -- no software.

I'll leave the discussion of people to the other articles in this special issue, except for one comment. The best thing that can happen to any software project is to have people who know what they are doing and have the courage and self-discipline to do it. Knowledgeable people do what is right and avoid what is wrong. Courageous people tell the truth when others want to hear something else. Disciplined people work through projects and don't cut corners.

Find people who know the product and can work in the process.

Process

Process is how we go from the beginning to the end of a project. All projects use a process. Many project managers, however, do not choose a process based on the people and product at hand. They simply use the same process they've always used or misused. Let's focus on two points regarding process: (1) process improvement and (2) using the right process for the people and product at hand. Many people believe that process improvement is the key to increasing your ability to produce software. (For more on software process improvement, see the September 1994 issue of American Proqrammer.) I agree with this, but you must have a process before you can improve it. The Software Engineering Institute's Capability Maturity Model (CMM) is a good starting point [2, 3]. The CMM has a series of levels through which an organization can progress from the chaotic level 1 (Initial) up through level 5 (Optimizing). It can take an organization 9 to 24 months to move from one level to another.

The CMM provides a long-term program for a quality software process. It lays out key process areas that build on practices from lower levels. Successfully addressing the key process areas at each CMM level can help an organization establish and improve its software process. Level 2 of the CMM (Repeatable) requires an organization to have written software process policies and to follow them on every project. It means having a software process. Levels 3 through 5 concentrate on improving the process. The ISO 9000 standards are similar to the CMM in that they concentrate on a quality process. (For more on the ISO 9000 standards, see the February 1992 issue of American Programmer.)

Some people disagree with the order of the CMM's key practices, and these are valid disagreements. If you have process experts on your staff, you can change the order in your organization. If you are like the vast majority of us, however, it is a boon to be given a road map to follow.

The second point to make about process is that different and useful process models exist. We must recognize them and use the one that suits the people and product in our current project, because no one model is best for every situation. The basic (and much-maligned) waterfall model is efficient and effective when you understand the product well. Other process models help when you don't understand the product, because they allow you to explore and learn. But they may be too fancy and a waste of time when your people do understand the product.

I have used several process models on different successful projects. The basic waterfall model involves defining the problem (requirements) and then selecting a solution (design) and building it (code, integrate, test, maintain). This model works when it fits the people and product. Its steps are included in all the other models, with the differences being the order and number of iterations of the steps.

The process model used in the follow-on project described earlier involved a series of deliveries. In this model, each delivery has all the required functions. Each succeeding delivery improves one or more attributes of the product (size, speed, etc.). This process model allows your people to learn how to optimize certain attributes, and it gives the customer a complete product along the way.

Another process model that uses a series of deliveries provides the shell of the system, with only a few functions at first. Ensuing deliveries add more functions. This gives the customer growing capability, allows the builder to succeed month by month, and reduces the time between customer and builder interaction. The customer has some confidence in the builder, the product, and the project, because it is not waiting for some "big bang" to occur out in the future somewhere.

Barry Boehm's spiral model [1] concentrates on evaluating and reducing risk. It is most helpful on innovative projects.

It is possible to use -- and I highly recommend using -- combinations of the preceding process models. Often the product in a project comprises smaller products. There is no reason to use the same process model for each of the smaller products. Use the process that fits the smaller product and the people who are building it.

Product

The product is the result of a project. The desired product satisfies the customers and keeps them coming back for more. Sometimes, however, the actual product is something less.

The product pays the bills and ultimately allows people to work together in a process and build software. Always keep the product in focus. Our current emphasis on process sometimes causes us to forget the product. This results in a poor product, no money, no more business, and no more need for people and process.

Instead of discussing different types of products (compilers, word processors, operating systems), I want to focus on two other aspects of the product. These are (1) the difficulty of the product and (2) the external and internal quality.

The difficulty of the product influences the process needed. "Difficult" is subjective and depends on how familiar your people are with the product. For me, a text editor is a very difficult product, while an intelligent image analyzer is simple. Is the product familiar or new to your people? Is it new to everyone in the world? Is the user interface a major portion of the product? The answers to these questions determine the "difficulty" of the product and the type of process needed.

Difficult products demand process models that allow for experimenting and learning. Easy products call for process models that are simple, straightforward, and efficient (like the waterfall). Difficult products become easier when you bring in people with knowledge of the product.

Keep an eye on the external and internal quality of the product. External quality is what the customer sees. The customer is happy if the product has all the required functions, is easy to learn and use, runs quickly, and doesn't require much disk space and memory.

Internal quality is what the builder sees. High internal quality indicates, among other things, that the design and code are easy to understand and the software is modifiable and portable. When your customer announces he or she is changing hardware platforms and operating environments, high internal quality lets you change the product quickly and easily.

These quality factors also influence the people and process. If portability (internal quality) is important, you need Unix and Macintosh people as well as MS-DOS/MS- Windows people on the project. If these people are not available, you must allow for learning and risk in your process.

GRAPHING THE THREE Ps

Figures 1 through 4 show a graphical view of the three Ps borrowed from Gerald Weinberg [4)). Figure 1 shows one relationship among people, process, and product. The regions depict the difficulty of a product, with products near the origin being easier to build. Easy products do not require much capability from people (vertical axis) or process (horizontal axis). As products move away from the origin, they become more difficult and demand more from your people, your process, or both.

Figures 2 through 4 show that the added capability needed to build a more difficult product can come through different combinations of improving people, process, or both. In each of these figures, the product moves from a difficulty of 1 to 2. Product 2 has the same difficulty in all three figures. In Figure 2, the needed capability comes from people (vertical movement only). This extra capability could be achieved by adding experts or training your people. Figure 3 shows that the same amount of extra capability can come from improving your process instead of your people. Using an incremental delivery model or stretching the schedule are ways to add capability. Figure 4 shows that the extra capability can come from improving both your people and process. This could be done by bringing in a consultant a few hours a week, sending one person to training, using rapid prototyping on one part of the product, using incremental delivery on another, and so on.

The point of the graphs is that building a more difficult product requires more capability from somewhere. You cannot do the same old thing with the same old people and expect something wonderful to happen. You must improve your people, your process, or both.

THE RELATIONSHIPS OF THE THREE Ps

The following scenarios illustrate how to keep the proper relationships among people, process, and product.

Example 1.: Write a desktop publishing program to run on any Unix platform using the Motif window manager. You are given the product. Your company has a strict methodology using the waterfall model with no iteration. Your company gives you a short deadline and an adequate but not wonderful budget. You are given the process.

Now, what people do you need for this project? The strict process means you must do it right the first time. Therefore you need people with knowledge of this product (some desktop publishing experts and some Unix Motif experts). Attempting this project with rookies would be disastrous, unless your management gives you some freedom with schedule or much more money.

Example 2: Write a desktop publishing program to run on any Unix platform using the Motif window manager. You are given the product. You are given the people -- you must use the 10 programmers on hand. They know Unix and X-Windows, but they have never used Motif and know nothing about desktop publishing. What process will you use?

Your people need training, and there are many risks on this project. You need a creative process, such as spiral development or incremental delivery. Petition your management for a long schedule and extra money for training. Schedule extra time for requirements, because your people don't understand the product. Try to hire experts to train your people and help build the most difficult parts of the product.

Example 3: Write a desktop publishing program to run on any Unix platform using the Motif window manager. You are given the product. You can choose the people and process.

The easy answer is to hire a company that has done this before. Its people know the product and what process works best. As an alternative, you could use this as an opportunity to build up a new group of programmers in your Company Bring in a mixture of new talent, train these people, and adjust the process to fit them. Your company would then have new capabilities for future projects.

Example 4: Management wants you to select a new product from a list of ideas. You can use the people on hand, and you have several process models at your disposal. Which product should you attempt to build? The answer, of course, is the product that will bring the most profit. Included in this profit question are the risk and cost of failure incurred by attempting the wrong product. Which product fits your people's area of expertise? Do you have processes that will help your people build a product outside their area of expertise? Do you have the budget for some consultants and training? Do you have the time for training?

The issues of choosing people, process, and product in these examples may seem trivial. Our industry, however, has had more than its share of failed projects. The $18 million fiasco I related earlier actually happened. The people managing the project were intelligent and experienced, and they had a track record of successes. Nevertheless, they chose people and a process that did not fit the product. In the end, their strict adherence to the process model kept them from checking if the product worked.

RECOMMENDATIONS

Successful software projects don't happen as often as they should. One way to increase their frequency is to achieve the proper relationships among people, process, and product. Given a product to build, choose people and a process that match. Given a product to build and the people to do it, choose a process that matches. Given people who prefer one type of process, try to build only products that match.

The capability to build difficult products must come from people and process. Tougher products require people with knowledge in the product area or doing something different with the process.

Select courageous and disciplined people who know the product and can work in the process. Use a process that allows your people to build the required product. Only attempt to build products within the capabilities of your people and process.

On the other hand, don't use more capability than is needed. Using desktop publishing experts on a text editor is a mistake; they will get bored and leave. The spiral development model is a waste of time and effort if your people are experts on a product. Use the simplest, most efficient process for the people and product.

Think about people, process, and product. You always have some flexibility on a project. Choose people, process, and product so that they will fit one another.

REFERENCES

1 Boehm, B.W. "A Spiral Model for Software Development and Enhancement." Computer, Vol. 21, no. 5 (1988), pp. 61-72.

2 Paulk, M.C., B. Curtis, M.B. Chrissis, and C.V. Weber. Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24. Pittsburgh: Software Engineering Institute, February 1993.

3 Paulk, M.C., C.V. Weber, S.M. Garcia, M.B. Chrissis, and M. Bush. Key Practices of the Capability Maturity Model, Version 1.1, CMU-SEI-93-TR-25. Pittsburgh: Software Engineering Institute, 1993.

4 Weinberg, G.M. Quality Software Management, Vol. 1, System Thinking. New York: Dorset House, 1992.

Dwayne Phillips works as a software, systems, and computer engineer with the U.S. government. He has a Ph.D. in electrical and computer engineering from Louisiana State University. His interests include computer vision, artificial intelligence, software engineering, and programming languages.

Dr. Phillips can be reached at 2315 Ballycairne Court, Reston, VA 20191-1633 (703/476-1951; dwaynephil@aol.com).