Whether you like it or not, requests to modify the requirements are going to come your way on a software project. To keep the inevitable changes from throwing your project into chaos, someone has to make the decisions about which changes to accept and which to reject. The industry-standard term for these decision makers is the change control board, and every project needs one.
The change control board (sometimes known as the configuration control board) has been identified as a best practice for software development. The CCB is the body of people, be it one individual or a diverse group, who decides which proposed requirement changes and newly suggested features to accept for inclusion in the product. The CCB also decides which reported defects to correct and when to correct them. Most projects already have some de facto group that makes change decisions; establishing a CCB formalizes this group’s composition and authority and defines its operating procedures.
A CCB reviews and approves changes to any baselined work product on a project, of which the requirements documents are only one example. Some CCBs are empowered to make decisions and simply inform management about them, whereas others can only make recommendations for management decision. On a small project it makes sense to have only one or two people make the change decisions. At the other extreme, very large projects or programs might use several levels of CCBs. Some are responsible for business decisions, such as requirement changes, and some for technical decisions. A higher-level CCB has authority to approve changes that have a greater impact on the project. For instance, a large program that encompasses multiple projects would establish a program-level CCB and an individual CCB for each project. Each project CCB resolves issues and changes that affect only that project. Issues that affect other projects and changes that exceed a specified cost or schedule impact are escalated to the program-level CCB.
To some people, the term “change control board” conjures an image of wasteful bureaucratic overhead. Instead, think of the CCB as providing a valuable structure to help manage even a small project. This structure doesn’t have to be time-consuming or cumbersome—just effective. An effective CCB will consider all proposed changes promptly and will make timely decisions based on analysis of the potential impacts and benefits of each proposal. The CCB should be no larger and no more formal than necessary to ensure that the right people make good business decisions about every requested modification.
CCB Composition
The CCB membership should represent all groups who need to participate in making decisions within the scope of that CCB’s authority. Sometimes a single individual can make decisions from all these perspectives, but more frequently you’ll need a multifunctional team. Consider selecting representatives from the following areas:
- Project or program management
- Product management or business analyst
- Development
- Testing or quality assurance
- Marketing or customer representatives
- User documentation
- Technical support or help desk
- Configuration management
The CCB for a project that has both software and hardware components might also include representatives from hardware engineering, system engineering, manufacturing, or perhaps hardware quality assurance and configuration management. Only a subset of these people actually need to participate in making the change decisions, although all must be informed of decisions that affect their work.
Keep the CCB as small as possible so that the group can respond promptly and efficiently to change requests. As we’ve all discovered, large groups have difficulty even scheduling meetings, let alone making decisions. Make sure that the CCB members understand their responsibilities and take them seriously. To ensure that the CCB has adequate technical and business information, invite other individuals to a CCB meeting when specific proposals are being discussed that relate to those individuals’ expertise.
CCB Charter
A charter describes the CCB’s purpose, scope of authority, membership, operating procedures, and decision-making process. You can download a suggested template for a CCB charter from http://www.processimpact.com/goodies.shtml. The charter should state the frequency of regularly scheduled CCB meetings and the conditions that trigger a special meeting. The scope of the CCB’s authority indicates which decisions it can make and which ones it must pass on to a higher-level CCB or a manager.
Making Decisions
As with all decision-making bodies, each CCB needs to select an appropriate decision rule and process. The decision-making process description should indicate the following:
- The number of CCB members or the key roles that constitutes a quorum for making decisions.
- Whether voting, consensus, consultative decision making, or some other decision rule is used.
- Whether the CCB Chair may overrule the CCB’s collective decision.
- Whether a higher level of CCB or someone else must ratify the decision.
The CCB balances the anticipated benefits against the estimated impact of accepting a proposed change. Benefits from improving the product include financial savings, increased revenue, higher customer satisfaction, and competitive advantage. The impact indicates the adverse effects that accepting the proposal could have on the product or project. Possible impacts include increased development and support costs, delayed delivery, degraded product quality, reduced functionality, and user dissatisfaction. If the estimated cost or schedule impact exceeds the established thresholds for this level of CCB, refer the change to management or to a higher-level CCB. Otherwise, use the CCB’s decision-making process to approve or reject the proposed change.
Communicating Status
Once the CCB makes its decision, a designated individual updates the request’s status in the change database. Some tools automatically generate email messages to communicate the new status to the originator who proposed the change and to others affected by the change. If email is not generated automatically, inform the affected people expeditiously so they can properly process the change.
Renegotiating Commitments
It’s not realistic to assume that stakeholders can stuff more and more functionality into a project that has schedule, staff, budget, and quality constraints and still succeed. Before accepting a significant requirement change, renegotiate commitments with management and customers to accommodate the change. You might negotiate for more time or staff or ask to defer pending requirements of lower priority. If you don’t obtain some commitment adjustments, document the threats to success in your project’s risk list so that people aren’t surprised if the project doesn’t fully achieve the desired outcomes.
Establishing a small and well-functioning change control board early in a project is an effective way to make sensible business and technical decisions so the project can deliver the maximum benefit with the minimum effort. Someone’s going to make all those decisions anyway. I think it’s best to thoughtfully identify those key players, then give them the charter and the tools to do their job efficiently.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.