A change control process that doesn't filter chaff from wheat contributes to scope creep. A sluggish change process raises the risk of delivering products that lack vital, timely functionality.
There is no universal truth about who makes the major decisions on a software project. However, your organization's managers need to identify the project stakeholders who will participate in each such decision early on. Who approves a requirements baseline? Who closes the checkbook when it's clear that additional investment in the project will only make you poorer, not more successful? The appropriate participants in major project decisions are those who are accountable for the repercussions of the decisions. This typically includes people in roles such as:
- project manager
- program manager
- development manager
- technical lead
- quality assurance manager
- product manager, marketing representative, or designated customer representative
- project risk officer
If your product includes both software and hardware subsystems, you'll also need representatives from the other engineering disciplines and from systems engineering. Your gate review teams and change control boards should represent the interests of both the developing organization and its customers. Large groups have difficulty making decisions, so keep the gatekeeper groups as small as you can. Balance the perspectives of the funding sponsors with those of the technologists and the quality engineers to ensure that adequate information feeds into the decision-making process. If a single high-level individual can override a decision made by the designated group, that group does not have the proper roles represented and the proper authority.
Select the decision-makers and their rules of operation to facilitate making rapid and effective decisions. I led one project that involved ten interlocking groups of subject-matter experts in different areas of software engineering and management. These groups were selecting, modifying, and creating documents for a large intranet-based collection of software process assets. At the outset, we agreed that whoever showed up at a meeting of one of these groups would constitute a decision-making quorum. This way, we kept the project moving along quickly, rather than being held up simply because one or two people did not attend a meeting. This rule helped us deliver the system on schedule.
How to Make the Call
When I joined a new corporate department twelve years ago, a colleague advised me about interacting with my new manager. "Be sure you're the last person to talk to John about anything important, because he always bases decisions on the last thing he heard." This didn't seem like an effective decision-making strategy to me.
Reaching individual conclusions is one thing, but major project issues involve multiple stakeholders. Every group that needs to reach closure on an important issue-be it a scope change, ship decision, or project cancellation-needs to define its decision-making process before the group confronts its first significant decision. Ellen Gottesdiener applies a collaboration pattern called "Decide How to Decide" (Software Development, January 2001) to this essential team activity. The group making the decisions selects a decision rule, which defines the way in which they will make their decisions.
Various rules are appropriate for different situations, depending on how critical the decision is, how many alternatives are available, and how much participation and agreement by individuals besides the decision leader is necessary (see also Sam Kaner's Facilitator's Guide to Participatory Decision-Making, New Society Publishers, 1996). High-stakes decisions are best made using a collaborative decision rule, such as consensus or having the decision leader decide after discussion with other participants. The following are some possible decision rules:
- Voting: This is the classic democratic approach, in which the majority rules. A close vote can leave the group polarized.