Use software and project engineering tools to better focus on the needs of your customer and get implementation right.
Throughout the long history of engineering and project management, there have been great successes along with spectacular failures. Modern project management began to undergo serious reforms at the start of the 1900’s and has been evolving ever since. As techniques improved, so did the benefits and, as such, manufacturing started looking for even better tools and methods to improve performance and productivity.
Now, as more industrial automation projects contain significant software elements, traditional project management tools sometimes fall short of providing the best solution. A better methodology is to combine software and engineering project management tools at the beginning of the endeavor and then consistently follow these principles throughout the project duration. The benefits of combining traditional project management and software engineering tools certainly outweigh initial investment, especially considering the potential costs of project rework or collapse.
Many companies employ traditional techniques such as “lessons learned” documents to analyze poorly performed implementations, but there are a variety of methods that can help avoid suffering the same fate on the next project. Lessons learned only helps if the challenges faced relate to the next project. Often, however, there is no direct relationship from one implementation to another, reducing the technique’s effectiveness. This effect has been magnified by advances in technology which can lead to a misapplication of these lessons. Managers can gain a false sense of security using post-project analysis and inadvertently downplay the seriousness of failures, ultimately leading to new ones. Multibillion dollar projects, such as the controversial US Navy ERP Pilot Project, have been scrapped with upper management defending the expense as a great learning opportunity. Unfortunately, lessons learned after the pilot project failure did not prevent the collapse of the entire project several years into the revised attempt.
Many initial project specifications are written from a business perspective with only the business goals in mind. A key objective of business project planning and analysis is to ensure that the requirements are documented, understood and agreed on by all stakeholders. This goes beyond a few kickoff meetings. A good project manager should understand that focusing only on initial specifications, timing and budgets will potentially lead to disaster. Employing a robust requirements elicitation methodology is necessary to draw out what a customer really needs. This is an active effort by the project management team to extract information from all the stakeholders. It is a combination of techniques conducted throughout all project phases, not just at the beginning. Technical and business requirements must be actively drawn out of the customer, discovered in data that has not yet been collected or analyzed or in tests that have not yet been completed. Assumptions embedded in the requirements and potential solutions need to be identified and understood. Not only do the technical aspects need to be fleshed out, but the business needs as well, which in some cases may directly conflict with some technical requirements. To ensure both business and technical needs are met, the correct mix of stakeholders is essential. Those stakeholders responsible for the businesses needs should be aware that many technical solutions exist, each capable of meeting their needs.
Mistakes made in elicitation have been shown many times to be major causes of project failure or abandonment. Rectifying these mistakes can become costly in both rework time and costs. A few top techniques include:
- brainstorming workshops
- process modelling
- interface analysis
- prototyping
- surveys & questionnaires
- observation
- document analysis
- interviews and focus groups
Properly conducted elicitation can go a long way in preventing many types of errors. The fact of the matter is that many customers do not know what they don’t know, and the exact nature of a project is rarely available at the beginning. This is even more evident when dealing with highly technical projects. A customer may ask for a database to be available for specific users to access but not consider creating specifications to address such issues as: access time, number simultaneous users, system load capacity and security. Customers often rely on outsourced technical experts to fill in these gaps without these experts fully understanding the business goals. It is critical that all these stakeholders meet to better clarify the details, with the understanding that aligning technical and business goals is an iterative process that continues throughout the project.
Historically, software development has demonstrated a tendency to target the wrong problem. This is true for autonomous vehicles, aircraft, medical equipment, data handing systems, websites and industrial machine control programming. The root of the problem is not digging deep enough to truly understand a customer’s needs and separate out business goals from the technical requirements necessary to meet those goals. The failure of the Denver International Airport Baggage Handling System is a prime example of what happens when all stakeholder requirements are not taken into consideration and the scope of the project is not entirely understood. After 10 years of delays and millions of dollars spent, the entire project was finally scrapped.
As obvious as this seems, major projects have failed with loses in the millions of dollars because technical and business requirements were not properly separated. There are some techniques, employed in software engineering that may be useful for any project.
Use case scenarios detail the connection between processes (tasks) and the stakeholders. The scenarios describe the interaction between people outside the system boundary and the processes contained within. Quality attribute workshops (QAW) yield enormous amounts of details that would otherwise remain hidden. A QAW not only records technical requirements but also creates scenarios to better define them. For example, a quality attribute that simply states a system must be able to handle 100 simultaneous users can be further decomposed into response times, data integrity, security, encryption and usability. For this to work, the quality attribute must be quantitively defined to allow for meaningful measurement data, progress monitoring and testing.
For instance, a business need may specify that products must ship with a maximum incident rate of 2,500 parts per million, but how this is achieved is not yet determined. Using a camera to detect failures may be one of the technical solutions agreed upon by the project team but how this corresponds to the business goal must be carefully investigated. Proving a vision system can detect failures 99.9% of the time requires an incredible amount of data to be collected and verified. Consider an engine plant producing 1,000 engines per week—how many images must be collected before the camera can be verified to be 99.9% accurate and put into production? The team must understand and accept that standard gage repeatability and reliability (Gage R&R) techniques are difficult or even impossible to apply in these cases. The team must also understand that every time the camera is adjusted, a new verification cycle will begin. What will production do while the vision system is being verified? A QAW would document the technical capabilities of the vision system which can then be compared to the business goal to identify and mitigate the gaps.
Regardless of the tools used, methodology must be logical and meticulous. The importance of elicitation cannot be overstated, for it is the cornerstone of any requirements discussion. Business goals and technical goals need to be aligned and then verified after using specific techniques that relate the business and technical requirements. Adequate study, preparation, a full analysis of the project business needs, and the stakeholder mix will determine which combination of techniques are best suited for the project.
