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