CONFIGURATION MANAGEMENT: THE RULE BOOK FOR COMPLEX PROJECTS

by Dwayne Phillips

If you are about to start a large, complex project, there are two things you must do on day one:

1 Write a configuration management plan

2 Have the CEO (president, division chief, whatever) endorse and enforce it so that everyone on the project uses it every day

CONFIGURATION MANAGEMENT IS ...

Configuration management (CM) is communication and coordination that allows people to analyze problems, design solutions, and build and use systems successfully. I, and many of you, have been on many projects that did not heed the above advice. Such projects usually have the following conversations:

"Well, the system engineering staff is supposed to check out the compatibility of that software."

"Says who? Maybe on the last project, but on this one quality assurance has that job. At least that's what I think I heard in the hall. "

and ...

"Oh, you're still working on the XX interface?"

"Sure. That's what we were told three months ago."

"Well, XX is out. We're looking at YY and ZZ. You'd better stop working now and change over. At least that's what I think I heard in the hall."

and ...

"Did you see the new widget Dave is working on? One of the customers caught Dave in the hall and asked him to add a capability to the Y-X subsystem."

"Does anyone else know about this yet? Won't it collide with the YY subsystem? Isn't Dave already behind schedule? How much time will it take him to do this?"

"Don't worry about that. Dave says this is really interesting, and the one customer told him it would save her a few minutes every January when she does her annual report."

The result of these conversations is people going in different directions as if they were on different projects. Sometimes we can bring everyone back on track, and sometimes we cannot. In any event, we have wasted time and effort. Even worse, people have hurt feelings (Why didn't anyone tell me?) and distrust management (How can these guys be so disorganized?). Project managers have looked everywhere except CM to find answers to these communication problems and to stop creeping featurism.

CM is the single most misunderstood topic in software. CM is seen as change prevention, and since change is inevitable in software projects, CM must not be realistic. It has been misused and abused and is widely hated. Because of these perceptions and experiences, the term CM is banned in many places. Since CM is unmentionable, many CM Practices have been spread throughout other parts of software engineering. A recent article by Gerald Weinberg [3] is one such example. Weinberg states the problems caused by ever-growing requirements ("perpetual pregnancy") and correctly calls for getting the requirements inputs, outputs, and process under control. Most of what Weinberg recommends would be covered in a good CM plan.

CM practices need to be under the CM umbrella. Of course, spreading the tasks out across a project is better than throwing them away. Keeping them all together, however, greatly improves the coordination they provide.

A good CM plan is the rule book for the project, and "good" means written according to the standard [2 ]. I know - nobody wants to read and abide by some standard. Standards are for bureaucrats and bookshelves, while we work in the real world. Our world, however, is one of complex projects. We must admit that the projects are too difficult for us and that we need a big dose of organization and discipline.

The CM plan states who is who, defines their boundaries (areas of responsibility), and lays out the lines and means of communication among the groups. This reduces confusion ("QA has that job ... I think") and cross talk ("One of the customers caught Dave in the hall"). Because it contains such fundamental information, it is essential to have the CM plan in place on day two of the project.

The CM plan describes:

1. Baselines

2 Activities

3 People

Let's take a brief look at these, considering the claims made earlier. Tutorials are available [1, 4], and I strongly recommend studying the standard [2].

Baselines

Every project has baselines, whether we admit it or not. Figure 1 shows a common system of baselines (yes, this looks like a waterfall). This diagram shows what baselines exist and that each baseline depends on all the others. This diagram does not dictate the process for creating the baselines. We can use rapid prototyping, RAD, evolutionary, or spiral processes. Whatever process or paradigm we use to analyze a problem and attempt a solution, we produce a set of intellectual products. We are much better off if we capture these products, give them names, and use them as baselines.

Baselines are the objects of all CM activities. They are stable platforms for future work. They are concrete, specific, visible items. Much of software is ideas in our heads. We cannot see the ideas in each other's minds. The baselines are something solid that we can see, discuss, analyze, and test.

The early baselines are documents and databases. They exist when the key project people sign on the dotted line. Later baselines are source code and executables that exist after inspections and tests.

You cannot manage changes to something that does not exist. Baselines exist; we can change them or prevent changes. Without them anything goes, and people walk around saying, "At least that's what I think I heard in the hall."

One of the most important properties of baselines is that they permit tracing:

"Why are we coding routine XX?"

"Because the design baseline calls for it as part of the YY subsystem."

"Why is there a YY subsystem?"

"Because the requirements baseline says the customer needs a YY subsystem."

Any routine that does not trace back through the baselines is a creeping feature and should be stopped - today! Would a programmer spend time and money on routines that are not essential? If they are interesting routines and one of the customers talks about it in the hall, you bet your project she would.

Activities

The four principal CM activities are:

1 Identification

2 Control

3 Status accounting

4 Audits

Identification takes ideas, puts them into packages, and names them. It makes the invisible visible. All of the requirements are pulled together, put into a document, and given a name (functional baseline), date, and version number. Now there is something that everyone can see, analyze, discuss, test, and so on. If we don't identify something, we cannot manage it, It will grow, change, and choke the project.

Control manages the things (baselines) we have identified. Control does not prevent change, it examines proposals for change, traces the effects through the baselines, and makes informed decisions (yes/no/modify the proposal). Controlled projects do not have creep - they have managed change. Configuration control boards (which I discuss later) make these decisions.

Status accounting is a regular check on progress. The CM staff (more on that later) checks what is being done as a service to management. Programmers are supposed to move completed routines from a personal area to a test area when ready. The CM staff looks at the test area weekly to see what is there. Status accounting is a line of communication between those working on the project and the project manager and upper management. The CM staff lets you know that Dave's assigned routine is not in his area but some mysterious widget routines are. This is not Big Brother looking over someone's shoulder. large, complex projects have hundreds of people working in different locations, and the project manager cannot visit everyone personally every day.

Audits record what exists. They are another line of communication between reality and the project manager. An audit of a design document checks to see if it exists, meets standards, and is complete (addresses A requirements). An audit of a delivery (hardware and software) records the items it contains. As in status accounting, the CM staff performs the audits. The CM staff is made up of outsiders who see things from a fresh perspective. Without audits, people waste time and energy debugging code when the problem is that the latest delivery of libraries does not contain the version that everyone assumes is there.

People

Now to the most important part of CM - the people. There are three basic groups of people related to CM:

1 Configuration control boards

2 CM staff

3 You (the project manager) and your staff

The configuration control boards (CCBS) identify and manage the baselines. A CCB is not a group of graybeards removed from the project who delight in requiring paperwork and saying no. Customers and developers sit on the CCBS. When you hear CCB, think of people responsible for their part of the product. This is their baby. The CCBs are focused groups in which the right people work out the right issues in difficult, substantive, exhausting meetings. People who do not have a direct interest in this part of the project are kept out.

The CCB studies any suggested changes to its baseline. If the suggestion is internal to the baseline, the CCB decides its fate. If, however, the suggestion can change the external interface of the baseline, then other, affected CCBs become involved. The project manager brings the CCBs together to discuss how the suggested change in one baseline traces through to the other baselines.

This is communication and coordination. Decisions are made by the people directly involved with the issues, not people wandering the halls. These are technical and business decisions ("Yes, this suggestion will improve the product, but it will increase cost by 10 percent and delay market release by four months").

Chaos rules if CCBs don't exist. Everyone has an opinion on everything (end users want to pick the programming language), and decisions seem to happen on their own. People learn how to force issues to go their way when it appears that the decision is going against them. I have seen people come in on Sunday afternoon and make configuration changes because they knew the changes would never be approved.

The CM staff works for the project manager and upper management. CM staffers perform status accounting and audits, as well as help with meetings and physically keep the baselines. They save the project from drowning in details.

Now we come to the project manager - you and me. Ideally, the project manager is the cheerleader. We hope to spend our time enabling people to analyze, design, build, test, and use software. Software projects, however, comprise countless details that no one person can grasp. CM and the CM staff bundle the details into packages that are easier (not easy) to corral.

Without a CM staff, the project manager is always running around trying to gather all the baseline and product details and turn ideas into documents, databases, and baselines; inspect delivered goods; see what the programmers are programming; and on and on. The countless details soon overcome him or her

The overwhelmed project manager will not be able to spend time and energy on what is important: the people in the project and the problems they are tackling. This is CM's greatest benefit. It organizes people, baselines, and activities so everyone can concentrate on communicating with people and solving technical problems.

CM WORKS

Proper use of CM organizes people and baselines so the right people discuss the right issues and the project manager spends time helping people solve technical problems. Even after skimming through this article, many will not believe this claim. I, and most of you, have been subjected to the "just say no" bureaucracies and management straight-jackets that some people call CM. After such experiences, it is no wonder we feel that CM cannot possibly help with dynamic software projects.

The CM plan is a rule book and should be enforced as such. What we must understand about this rule book is that we write the rules to fit our organization and project. We decide how best to apply the principles of CM. We decide which people are responsible for which parts of the project and when the various groups meet to ensure they are all on the same page.

Using CM properly will not make it any easier to fit a library of adaptive filters into the memory available on a geosynchronous communications satellite. It will, however, help us keep out creeping features, ensure that needed routines make it into the product, and keep decision making out of the halls.

Write the rule book on the morning of day one.

Have the CEO endorse and enforce it on the afternoon of day one.

Thereafter, all you have to do is cheer your people on and tackle the technical problems.

REFERENCES

1 Berlack, Ronald. Software Configuration Management. New York: John Wiley & Sons, 1992.

2 IEEE Guide to Software Configuration Management, ANSI/IEEE Standard 1042-1987. Los Alamitos, CA: IEEE Press, 1988.

3 Weinberg, Gerald M. "Just Say No! Improving the Requirements Process." American Programmer, Vol. 8, no. 10 (October 1995), pp. 19-23.

4 Whitgift, David. Methods and Tools for Software Configuration Management. New York: John Wiley & Sons, 1991.

Dwayne Phillips is a software and systems engineer with the U.S. government. He is not a CM professional and does not earn any direct income from CM. He is a project manager who has found that a good undemanding and proper use of GM is very helpful on projects large and small.