When enough is enough, please just stop

Engineering and IT Insight: Knowing when to stop a software project is among the most difficult things to do in manufacturing IT or with control software; no one wants to be associated with failure. Yet ignoring obvious evidence will just make it worse. Here how to know if it is time to stop, reboot, or restart.

11/15/2012


One of the hardest tasks in any software project is deciding when “enough is enough” and it is time to stop the project, stop spending money, and either reboot or restart. This is a hard decision because no one wants to be associated with a failure. Aside from a no-hitter baseball game and a 300 score in bowling, there are very few things in life that are 100% successful. Admitting that a project is failing—or even just participating in a failed project—is painful, and most people will work very hard to not admit failure, even ignoring obvious evidence.

It is important to understand what constitutes a failed software project. A software project is a failure when the delivered system doesn’t meet the critical requirements. Few projects meet all of their requirements, but there are usually a set of critical requirements that must be met for the system to be usable and cost effective. Many projects fail because the critical requirements change during project execution and the changes cannot be supported. Other projects fail because the wrong technology was chosen, the technology was not ready for deployment, or the project team did not know how to use the technology. Some projects fail because their critical requirements were impossible to meet or were internally conflicting. There are thousands of reasons for failure, so it may be hard to determine why a project is failing, but it is easy to determine if it is failing.

Project team members often know

Project team members usually know when they are on a failing project. They spend their time trying, in vain, to make the system meet its requirements. Project managers usually know when they are on a failing project because they see continual delays in the project schedule, with no believable expectation of ever finishing. Often executive management also knows that the project is failing, because of schedule slips and costs that keep rising. Despite the fact that everyone knows the project is failing, projects frequently seem to take on a life of their own and no one knows how to stop the project without putting their careers at risk.

Human psychology helps explain why we seem to get into these situations. People are consistently overly optimistic; they overestimate the probability for success and underestimate the probability for failure. We do not learn from generalizations and statistics, but by internalizing experience from individual stories.

See the book “Thinking, Fast and Slow” by Daniel Kahneman for an excellent presentation on how we make decisions. Even if you know intellectually that 10%-30% of software projects fail, it is still almost impossible to apply that knowledge to the failure probability for your specific project. If you can imagine executing the same project 10 times, and there is a 20% probability of any project failing, then 2 out of 10 times you should stop the project. It is difficult to internalize that knowledge and admit that this time may be one of the two failures.

Dig in, see these clues

Software projects differ from other projects because the work product is usually not visible until near the end of the project. It is easy to see progress in construction projects: holes are dug, concrete is poured, and frames are raised. In electronic projects, prototypes are built and tested, parts lists are generated, and machines are built. You can see the progress in physical projects and determine if progress is being made. You only need to look at half-finished buildings and bridges, or unfinished prototypes to see examples of physical projects that have been stopped. With software there is usually nothing concrete to look at except for a lot of documents and presentation slides. You have to dig into the project deliverable schedule to see if a software project is failing.

Look for clues that your project is failing. Has your 6-month project been going on for over 2 years? Have you used up your reserve budget, and are you continually asking for more funding? Has your project team claimed 90% complete for over 50% of the project timeline? Has your vendor repeatedly claimed that the problems will be solved in the next release, but they never are? Have your users been continually changing requirements in ways you have not foreseen, with no letup in sight? Has your project been going on so long that the technology is now obsolete and not supported? These are strong indications that the project is failing and drastic action is needed.

One common tactic for stopping a project is to “declare success” and move on to the next project. Usually this comes about with a reissue of the requirements, removing those that cannot be met, even if they were critical requirements. This allows everyone involved to “save face” and not be associated with a failure. The unintended consequences of this tactic are that you don’t learn from the mistakes made, and you get to repeat them on the next project. A better tactic is to have an independent review board that evaluates projects on a regular schedule to determine if they are on track and should continue, or if they should be stopped.

Avoid blame, learn from experience

The independent review board should not assign blame but should force an “after action review” for any stopped project with all team members as a learning exercise. This review should be performed on all projects, not just those that seem to be failing. This helps the board members learn to differentiate projects in trouble but savable, from those that cannot be saved and should be stopped. Board members learn by internalizing the experience from individual stories. Setting up a general company policy with well-defined procedures for project reviews is the key to stopping projects before they become failures.

There is no magic bullet that makes it easy to decide when and how to stop a project. It takes courage to admit that mistakes were made and that lessons can be learned so the same mistakes are not repeated. Stopping projects may be the hardest decision that a manager or executive must make, but if you are sure that the project is failing, deciding to stop sooner rather than later is the best decision you can make.

- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, content manager CFE Media, Control Engineering.

http://www.controleng.com/it



No comments
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.