Good Money After Bad

[article]
Summary:

Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. Karl Wiegers gives some tips on decision making that can help you avoid this outcome. Karl also shows how to use decision points to keep a good project moving along.

"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.

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09