Engineering and IT Insight: Failure is not an option
Taking a "failure is not an option" or "do it right the first time" approach with manufacturing IT projects can hide important information and waste time, especially when workflows are in place to catch and quickly correct an occasional error.
“Failure is not an option” is a great objective, it focuses attention on eventual success and reinforces the importance of succeeding. Although the phrase is reportedly a Hollywood creation for the Apollo 13 movie, it has become a catch phrase for many projects. In life-critical and safety-critical situations, such as life science manufacturing, oil and gas production, refining, and many chemical operations it emphasizes the importance of not making mistakes. It is such a good objective that many project managers also use it as a project strategy and push the concept down to all activities within a project.
When used as an overall objective, Failure Is Not an Option (FINO) is powerful. When used as a project strategy or a project tactic it can be disastrous and is one of the seven bad habits of unsuccessful projects. An alternate form of the strategy is “Do it Right the First Time” (DRFT). As a corporate objective, DRFT is a good target to get to 6-sigma production. As a project strategy, DRFT leads to an inability to make critical decisions and as a project tactic it leads to avoidance of any mistakes no matter how insignificant or easily correctable. The problems with a using FINO or DRFT as project strategies are that they lead to behavior where failures are not reported, project team members will not make any decision that does have guaranteed success, there is excessive non-productive paperwork, and there are multiple meetings with no decisions or action items.
Symptoms of this bad habit are an inability at any level to make the tough project decisions and an avoidance of reporting any bad news. This often means that top level management is never made aware of problems because they said Failure Is Not an Option. If there is a fear of failure, then every decision must be proven correct before it is accepted. FINO and DRFT often demand waterfall development methods in automation projects where all requirements are documented and approved prior to any other activities. These methods make the invalid assumption that all requirements can be known and can be documented without errors. If the project scope is well known and well understood, then this is possible, but a normal automation project will have many unknowns at the start of the project. When there are unknowns or when the requirements can change during the project implementation or when new technology is being implemented, then a more flexible strategy is needed. A flexible strategy or tactic involves iterative development. The SCRUM and AGILE project methods provide this flexibility. Applying the 6-Sigma DMAIC (Define, Measure, Analyze, Improve, Control) cycle to a project can also provide the ability to react to changing conditions and requirements. SCRUM, AGILE, and DMAIC operate on the principle of small steps to reach an optimal solution.
Many project leaders do not understand the need for this flexibility. Due to inexperience or bad experiences, they believe that project problems can be avoided if only the requirements are better documented. They make the assumption that those writing the requirements have a complete understanding of the problem (often not true) and a complete understanding of the possible solutions (usually not true). Analogies can help in explaining to management why this strategy, allowing not mistakes at any phase of the project, is inherently unsuccessful. Image a space flight that requires absolute precision, without any possibility of mid-flight corrections. Most flights would miss their targets. Imagine a sports team that never allows practices, punishes any mistakes on the playing field by immediate removal, and guarantees fans that there will be no mistakes. That team would win very few games and very few fans.
The key point to remember is if you don’t make any mistakes, then you aren’t trying hard enough. The correct solution is not always known at the start of a project, so encourage testing alternate solutions and don’t punish mistakes made for the right reasons. Failure is not an option can be a project objective, but don’t let it become hindrance by preventing discovery of the best project solution.
– Dennis Brandl is president of BR&L Consulting in Cary, NC, www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.
– Engineering and IT Insight – File this under: Bad habits for control engineers – Move past the file cabinet organizational mentality to improve automation system projects. This is fourth in a series of “bad habits to avoid” from the Control Engineering Engineering and IT Insight column.
– Engineering and IT Insight: Are you using the wrong control system tools? – Applying the wrong tools in control system projects can be akin to using stone knives and bearskins. Which of these five misused tools are killing your productivity?
– Engineering and IT Insight: Schedules for engineers – A missing or unrealistic schedule is a bad habit common to unsuccessful projects. Lack of experience in the project space can lead to ballpark estimates and schedule slippage.
– IT and Engineering Insight: Control architecture, who needs it? – If you have a large control software programming project and no control system architect, small changes can lead to dead ends and bad decisions.
– IT and Engineering Insight: Seven habits of unsuccessful projects – Understanding if you are in an out-of-control IT project is important. Here are some traits of failing or soon-to-fail projects. If your project has three or more of these attributes, you need a project "reboot."