On several previous occasions I have been given the opportunity to blog about one of my passions; capital project execution and the application of a Phases and Gates methodology. As we have previously articulated, Phases and Gates is a shared approach to achieving a business goal, usually involving installing or upgrading manufacturing assets, shared between an end user (the owner) and the chosen solution provider. The beauty of working under a method where the project objectives, technical exploration, definition, and then execution are scripted, and the individual steps with respective deliverables or work product are described as part of the contractual agreement, is that the work process framework promotes clear communication, crisp expectations, and a means to collaborate and manage project risk.
At a high level, when we refer to a Phases and Gates project execution approach, we are talking about dividing the entire project implementation workflow from problem statement through commissioned solution into its smaller phases (or logical pieces of work). Phases are separated by decision points (the Gates) where the client is asked to render input and direction back to the execution team. The Gates also provide the context to discuss and manage the project risk associated with each of the discrete steps/phases.
As a client’s selected integrator, our obligation is not just to deliver on our contractual commitments, but to work to ensure that our customer succeeds in his business endeavor. Suppose we delivered a project for which the contract stated that a machine was to be provided that builds a certain number of the client’s parts, at a designated throughput and with certain inspection criteria being met. Once production starts, the customer’s product is put into service, and after some elapsed time, field data becomes available that shows that the product is failing due to a flawed assembly step. As the integrator, the process may have had design review approval and then SAT acceptance, but this delayed problem coming back from the field is clearly an indication that something was overlooked during the technology evaluation and the solution engineering phase. Given that our company was the integrator, this situation would reflect badly on our company, and negatively effect our long term business relationship with this customer. Doing a thorough job of managing all types of project risk, in collaboration with our client, must be a top priority.
One aspect of risk that demands consideration is the possible impact that a potential disruption might have on a project. This impact is typically evaluated with 2 criteria:
1. How severe the negative effective might be.
2. Probability that the disruption will actually occur.
Each project phase may have its own unique risk profile; in our experience, we strive to deal with all identified risks having to do with system design, functionality, and performance during the design phase prior to any of the at risk components being procured or fabricated. It is almost always true that it is less costly to deal with system accommodations or modifications (if required to mitigate risk) while the design is still in the CAD system and not on the shop floor.
As we collaborate with our customer on project risk, we are also cognizant of the influence that early phases can have on risk as compared to later phases. Early project phases, including User Requirements (which are comprised by the customer’s problem statement or opportunity, business goals and objectives, then the needed system performance criteria), and Concept Design (which is made up of technology assessment and selection, system layout, first pass equipment list, controls system architecture, and system budgetary cost and delivery schedule) consume a minor portion of the project’s overall budget, and yet offer the benefit of significant strategic leverage on the project outcome. It thus follows that risk identification and mitigation is also of paramount importance during these formative phases. The potential consequences of selecting a technology, or a solution approach that has a latent flaw which may not be discovered or addressed until the project is in its later execution stages can be disastrous, causing budget over-runs and production start-up delays.
As the project team comes together to perform Gate 2 (Concept Design approval), they will have to deal with a number of outside influencers or pressures that will drive how much risk is carried forward. The most obvious risk drivers are the need to minimize project implementation cost and schedule duration. Other solution dimensions that can result in risk may include selecting an unproven/cutting edge technology as a component of the solution, or selecting automation without considering and preparing the needed operational and maintenance infrastructure (tools and training) in preparation for start up of the new system. A new application of a proven technology can also mask risk, as there is a tendency to rely on past successes rather than study and verify the new use of the machinery.
In many of these situations during the early and formative phases of the project, the team should consider steps that can be taken to reduce or eliminate these potential risks to the outcome of the project. One such tool that is highly effective in allowing the team to assess and engineer risk mitigation solutions for technical issues is Proof of Principle (PoP). PoP can and should be utilized for unproven/cutting edge technologies that are of interest but have no production history; it can also be helpful where an existing technology is being used for the first time in a new application. The concept of PoP is straight forward, and involves taking the time to procure or build a prototype, setting up and running controlled tests utilizing the prototype, analyzing performance data, and then injecting the learnings into the system final design, thereby removing the performance risk from the start up phase of the project.
Unfortunately, we have witnessed occasions where the client has elected not to spend the money or the time to perform PoP on projects where technology risk was present. Sometimes the risk can be dealt with during start up and debug with only minor disruption. However, we have also experienced projects where equipment that does not perform properly needs to be replaced or reworked at significant cost and schedule delay.
In those unfortunate situations, once the team is in the midst of the battle to get into production and deliver the anticipated benefits to the owner, hindsight would suggest that not completing a PoP phase was ultimately a bad bet. In the end, one has to ask, is it worth the risk to carry potential project risk by neglecting to perform PoP?
Want to work with Pete? Contact him today Peter.Sherer@optimation.us.
{{cta(’81d8e030-97be-4420-ab03-a44363808a26′)}}
