The Only Winning Move

[article]
Summary:

Organizations that don't expect and encourage about 20 percent of their projects to be stopped may either be wasting resources or implementing only the safest bets. Denying reality or playing it safe may be the riskiest strategy of all according to industry authority David Gelperin.

At the end of War Games, Joshua has gained full control of America's nuclear strike capability. He has just finished an in-depth analysis of the likely outcomes of various attack scenarios. The "strange game" Joshua refers to is Global Thermonuclear War. Joshua's insight also applies to some software projects, where the only winning move is not to continue to play i.e., to stop (suspend or cancel) the project. In "Project Termination Doesn't Equal Project Failure":  www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf, Barry Boehm argues that cancellation of some projects should be a normal and expected occurrence in well-managed software development organizations. He says that, in a world of rapid change, a 30 percent project cancellation rate may not be high enough.

There are many reasons to stop a project, including:

Environment
New government initiatives or controls may change priorities

Business
The introduction of new products by competitors may redefine goals

Organization
Business reengineering or integration with other organizations may change priorities

Technology
New technologies may make design strategies obsolete

Personnel
Critical stakeholders may not be sufficiently involved or may have serious disagreements with each other, or developer capability may have been misjudged

Innovation is bred in organizations that encourage risk-taking, that expect some stopped projects, and that implement a management strategy of incremental commitment. Incremental commitment anticipates change and learning. Projects are marked by multiple review-points where project status and justification are reevaluated. Projects can be reauthorized, suspended, or cancelled at any review-point. The ability to stop projects before completion is a mechanism for managing quality while taking risks.

As with any human decision, we can get it wrong by stopping work on a project that should continue. More often however, for an array of psychological, social, and cultural reasons, projects continue that should be stopped. We need stakeholders to buy-in to stopping, just as we need them to buy-in to the project. Some projects, like some government programs, seem to develop a life of their own.

Failure to stop a deserving project can result in:

  • Insufficient resources for priority projects
  • Projects that deliver nothing or little-used systems
  • Turnover of key staff, because working on failed projects is a major cause of extreme frustration and burn-out

Organizations that don't expect and encourage about 20 percent of their projects to be stopped may not be taking enough chances or may be wasting significant resources. High-payoff projects are often risky, but "playing it safe" may mean a significant loss of opportunity (e.g., market share to risk-savvy competitors) and may be the riskiest strategy of all. Is your organization taking enough chances? Does it communicate its expectations with a line item in the yearly budget for stopped projects? Have you been on a project that should have been stopped but wasn't? What did you do or wish you had done? Let us hear from you.

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 24
Oct 12
Oct 15
Nov 09