Good Money after Bad: Some Projects Should Die

Karl Wiegers
Jul 5, 2019 · 7 min read

“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 projects that suffer a lingering death should have been canceled much earlier. I know of one software project that was terminated after burning through $50 million, another that more than $100 million failed to bring to fruition, and a third that poured several hundred million dollars down the drain with no deliverable. Those projects all went south for different reasons, but it was clear they were going to fail long before people finally decided it was pointless to continue.

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’s hard to pull the plug on a dead-end project, losing all you’ve spent so far, 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 and how. Letting a project slip through a decision checkpoint without having completely satisfied its pass criteria simply defers the technical risk and increases the cost of later failure. Make the many decision points on your project meaningful, so you can invest resources in the wisest way. And occasionally, you might decide that the project simply isn’t worth completing.

Decisions, Decisions

To help avoid the project graveyard, include several key decision points in each project plan. The gates at the end of each stage of a multiphase development life cycle constitute a natural set of such points. Completing an agile iteration also is a logical decision time.

Reviews at these points inform senior management and other key stakeholders about the project’s status, major issues, risks, and prognosis for success. The key stakeholders can then decide whether to continue the project as planned, redirect it in response to technology issues or changing business objectives, or put it out of its misery.

An early decision point comes after an initial exploration of the business case, top-level requirements, and technical feasibility. These insights feed into estimates of the development cost and schedule, so the team can judge whether proceeding as planned makes good business sense. Major decision points need clear and objective criteria, established in advance, for choosing what actions to take.

One of the most important project decisions is to evaluate whether the product is ready to ship. To make this easier, establish release criteria early in the planning process. These criteria should be specific, measurable, and binary: each criterion is either demonstrably satisfied, or it is not.

It can be tough to stick to this analysis when you’re being pressured to ship. A beleaguered manager or marketer might be tempted to overrule unsatisfied release criteria. However, customer dissatisfaction might trump the perceived benefits of an on-time release. As an old saying goes, “The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten.”

Project management also involves many smaller, periodic decisions. For example, scope control requires that stakeholders make hard choices about what goes into the product and what gets omitted or deferred to a later release. If your development process involves a series of short iterations, you need to choose which features or user stories to implement in each cycle. Change requests must be processed, new functionality incorporated into the plan, and risks identified and monitored. Someone has to make all of these decisions. Your project will run more smoothly if you know in advance who those decision makers will be and how they will arrive at their conclusions.

Says Who?

There’s no universal truth about who makes the major decisions on a software project. Your organization’s managers need to identify the 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 expenditures will only make you poorer, not more successful?

The appropriate participants in major project decisions are those people who are accountable for the repercussions of their decisions. This could include people in various roles:

  • Project or program manager
  • Product manager, product owner, marketing representative, or lead customer representative
  • Development manager
  • Technical lead
  • Quality assurance manager
  • Project risk officer

If your product includes both software and hardware components, you’ll also need representatives from the other engineering disciplines involved and from systems engineering.

Your gate review teams must represent the interests of the developing organization and its customers. Large groups have a hard time making decisions, so keep those teams as small as you can. Balance the business and technology perspectives to make sure the decision makers have the information they need.

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. 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 didn’t attend a meeting. This rule helped us deliver the system on schedule.

How to Make the Call

When I joined a new corporate department once, a colleague advised me about interacting with my new manager. “Be sure you’re the last person to talk to John about anything important. He always bases his 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. The group making the decisions chooses one or more decision rules, which define how they’ll reach conclusions.

There’s no single “right” decision rule. Various rules are appropriate for different situations. It depends on how critical the decision is, how many alternatives are available, and how important it is to have participation and agreement by individuals beyond the decision leader. Following are some possible decision rules.

  • Voting. The classic democratic approach: majority rules. A close vote can leave the group polarized, though. If the decision turns out to be less than ideal, people who opposed it might loudly proclaim that they voted against it, so they aren’t responsible for any failure.
  • Unanimity. Unanimity is a variation on voting in which any dissenting votes result in no decision. This is a higher bar than majority-rule voting.
  • Consensus. Consensus doesn’t 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. They can’t make a decision unless anyone who is affected by any part of the decision is 100 percent okay with every aspect of the decision. Sometimes the team must move ahead even if certain participants have lingering misgivings. Consensus is a way to do that.
  • Delegation. In some situations the decision leader gives a single individual the authority to resolve an issue. This works well if the other stakeholders trust the delegate and if he has the appropriate knowledge, expertise, and judgment.
  • Decision Leader Decides. The designated leader of the decision-making group 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’ll know their input was considered.

What Next?

To get started with making better project decisions, follow these three steps.

First, reflect on some of the project team’s recent decisions. Were the right people involved? How did they arrive at each decision? Did they consider the available data and apply some 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? Were any important decisions deferred instead of being made promptly? Did someone higher up the food chain overrule any key decisions?

Next, think about any projects you know of that were — or should have been — canceled before completion. Did the right people make the right decision to cancel the project at the right time? If they didn’t, why not? Was it a problem of political pressure, unrealistic optimism, weak decision-making, inadequate information to make the call in a timely way, or just the inertia of a project underway that keeps on rolling? Can you think of ways that cancellation decision could have been handled more effectively?

Finally, list the major decision points on your current project. Possibilities include baselining a requirements specification, funding continued development, passing a status gate or major milestone, and deciding whether or not to ship. 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. Identify the critical go/no-go points where the team should consider whether to redirect or terminate the project. What criteria could the team used to make that very important decision?

No one likes to admit defeat and conclude that a project should be abandoned, especially after they’ve sunk a lot of money into it. But sometimes that’s the smartest option. Improving 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.

The Startup

Get smarter at building your thing. Join The Startup’s +799K followers.

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +799K followers.

Karl Wiegers

Written by

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +799K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store