Good Money After Bad

"Did you hear about Randy's brilliant investment strategy? He just bought more stock in TechnoWizard.com, even though he lost his shirt on his first batch of stock."

"Randy must be nuts. Now he's throwing good money after bad."

As with financial investments gone sour, many software projects that suffer a lingering death should have been canceled much earlier. I recently learned of one project that was canceled after spending $50 million, another one that $100 million failed to bring to fruition, and a third that poured several hundred million dollars down the drain with no deliverable. Projects that don't promptly change direction when market or technical realities dictate will maintain their financial burn rate without yielding much return on the investment. Although it is hard to pull the plug on a project with a weak business case, failing to do so does indeed throw good money after bad.

A well-managed project passes through numerous important decision points. Sometimes it isn't clear who makes these decisions or how they are made. A project that flows through a decision checkpoint without having completely satisfied its pass criteria simply defers the technical risk and increases the financial risk of later failure. Make the many decision points on your project meaningful, so you can confidently invest resources in the wisest way.

Decisions, Decisions
Your project should include several planned decision points. The "gates" at the end of each stage of a multiphase product development lifecycle provide a natural set of such points. Gate reviews inform senior management, marketing, and other key stakeholders about the project's status to date, major issues and risks, and the prognosis for moving ahead. At these gates, the stakeholders will decide whether the project should continue as planned, be rescoped or redirected in response to business objectives or technology issues, or be terminated.

A critical early decision point comes after an initial exploration of requirements and technical feasibility. These insights feed into estimates of the development cost and schedule, to judge whether proceeding as planned makes good business sense. Major decision points need clear and objective criteria, established in advance, for deciding what actions to take.

One of the most vital project decisions is to evaluate whether the product is ready to ship. To make this easier, establish release criteria early in the planning process (yet another decision-making activity). These criteria should be specific, measurable, and binary: each criterion is either demonstrably satisfied or it is not. It can be hard to stick to this analysis when you're being pressured to ship. However, if a beleaguered manager or marketer overrules an indication from the release criteria that the product isn't ready for prime time, customer dissatisfaction might trump the perceived benefits of an on-time release. If the release criteria indicators are overruled and the product is shipped anyway, tune up the process for making release decisions on the next project.

Project management also involves a myriad of smaller, ongoing decisions. For example, scope control requires stakeholders to make tough choices about what goes into the product and what is omitted or deferred to a later release. If your development process involves a series of small iterations, you need to choose which features or user stories to implement in each cycle. Bite off too much and your customers might have to wait longer than planned for the next release.

Begin with a clear scope definition, so the stakeholders can determine if proposed functionality really belongs in this iteration. Sound processes for change control and requirements prioritization help ensure that each release delivers the maximum value within your schedule and resource constraints. 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.

Says Who?
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. If the decision turns out to be less than ideal, don't be surprised if people who opposed it loudly proclaim that they voted against it. Unanimity is a variation on voting in which the presence of any dissenting votes means that a decision is not made. All participants must be in lockstep. 
• Consensus: Consensus does not mean that everyone involved with the decision fully supports the decision. It means they can all live with it, that their major concerns have been addressed. Some organizations are so driven to achieve agreement that they become paralyzed, unable to make a decision unless anyone who is affected by any part of the decision is 100 percent okay with every aspect of the outcome. While it's great if we all agree, sometimes the team has to move ahead despite the lingering misgivings of certain participants. If the team deadlocks, they can negotiate further or invoke a secondary decision rule, such as having the decision leader make the choice. 
• Delegation: In some situations, the decision leader gives a single individual the authority to resolve an issue. This accelerates the decision-making process and can work well if the delegate is trusted by the other stakeholders and has the right knowledge, experience, and judgment. 
• Decision Leader Decides: The designated leader of the decision-making team makes the call, either with or without discussion with other participants. Gathering input from others, such as a list from the QA manager of risks arising from premature release, enhances the commitment the other stakeholders have in the outcome. Even if they don't agree with their decision, they know their input was considered.

Your Turn
To get started with making better project decisions, list the major decision points on your project, such as baselining a requirements specification, funding continued development, passing a status gate or major milestone, deciding whether to ship, and accepting the product. For each, identify your project's decision-makers and the other people who provide input that helps the decision-makers make good choices. Describe the decision-making process or the decision rule for each of these situations.

Now, reflect on some recent decisions that the team made. Were the right people involved? Did they consider the available data and apply the decision rule as intended? In retrospect, were they good decisions? If not, why not? Did the decisions help the project succeed or merely prolong its stay on life support? Evaluating how your team makes decisions will help ensure that the right people make the best choices to keep your organization from throwing good money after bad.