In recent past articles, we have enjoyed blogging about some of the aspects of how to successfully undertake and deliver capital projects. We have noted that a sound methodology to accomplish this can be found in a process we dubbed “Phases and Gates,” where the project work that streams from the customer’s initial project request for an installed and commissioned solution is divided up into manageable steps with predetermined decision points. Our content has talked about the need for Requirements, the benefits of Conceptual Design, and the case for Preliminary Engineering.
These are all early phases or pieces of work to set the stage for a low risk project execution (when equipment is purchased or built, installed, and then commissioned). These early work activities are designed to increase project knowledge and mitigate risk by researching technology, defining project scope, performing engineering calculations for system sizing, and planning appropriate project management tasks.
Front End Loading
However, let’s take some blogging license and back up our discussion to talk a little about our client’s initial Problem Statement or Opportunity. This is one of the four early phases that occur before any funds are spent on equipment, bricks, or mortar. These four phases, sometimes grouped together and referred to as Front End Loading, are powerful tools that promote scope determination, project technical definition and understanding, risk mitigation, and a predictable project outcome, before the heavy capital spending begins. As we say in the industry, project obstacles are easier solved on paper than in steel and concrete. The four Front End Loading phases are:
- Client Problem Statement/Business Case: This phase is owned and provided by the customer, and articulates the WHY of the project: why the project is of strategic business importance. The customer should capture why the project expenditure is justified, and the benefits that are expected.
- User Requirements: This document outlines WHAT needs to be accomplished and how the customer will measure project success. The User Requirements should be owned (or approved) by the client, but can be jointly documented with the assistance of an outside consultant or service provider
- Concept Design: This phase describes HOW the project requirements will be met, and the business case satisfied. It involves selecting the appropriate solution platform and a first pass project impact statement for cost, schedule, and risk. It is recommended that this phase be a collaboration between the client and the integrator/solution provider.
- Preliminary Engineering: This phase further DEVELOPS THE PROJECT SCOPE. It is intended to quantify/size the significant process components and mitigate risk such that fixed price bids can be obtained. This work is typically performed by the integrator/solution provider.
Sharing the business case for a project
Now, with all of that as background, let’s create a fictitious project to consider our question of the day: whether or not it is advisable for a client to share his business case with his solution provider. Our company, Acme Products, produces cleaning chemicals and bottles them in 1 and 2.5 gallon sizes for commercial use. At the end of the Acme production line is a manual packaging operation (utilizing 3 people per shift) that erects cases, loads 4 or 6 bottles into the cases based on size, seals the case, and loads cases on pallets for outgoing shipment. Acme management has determined that there is good business reason to automate this packaging step, and has had one of their process engineers put together an RFP (Request for Proposal) to have several local integrators propose solutions to this problem. The RFP stresses throughput and yield. No financial justification is mentioned in the bid document.
OK, here’s what happens. Three quotes are received back, the equipment selections that make up the various solutions are varied, but unfortunately the costs of all 3 exceed the allotted budget and undermine the ROI of the business case. What should the Acme team do now?
Why financial justification matters
What none of the bidders have visibility into is the client’s justification. They assumed that since the process is presently being done manually, that labor reduction is driving the project. The weights of the cases are below OSHA limits for lifting, so the suppliers all assumed that health and safety were not reasons for the request.
What now becomes material to the future success of this investment are the details behind what the client is trying to accomplish. If the project is to go forward, and the benefits realized, a more interactive discussion needs to take place between the solution provider and the client to determine what the actual drivers are, and how to prioritize the equipment spending to maximize the return on investment against these drivers.
Many times a customer will view these details as business confidential, and will be reluctant to share this information with a supplier. It is helpful in this situation to have an ongoing relationship and some trust built so this reluctance can be overcome (a NDA can also alleviate this concern). Let’s say for the sake of argument that the primary driver is avoidance of spills that have been experienced due to manually loading of cases and dropped bottles that leak.
What the client did not share was the cost of reporting these spills, cleaning them up, and the HSE risk associated with exposure to the spilled chemicals. Knowing this, a system integrator could then offer to simplify the case sealing and palletizing steps and concentrate on the automatic case erection and bottle loading. Now the expected project cost can be reduced, and the primary justification met.
Sometimes, in order to preserve a successful project outcome, collaboration with a trusted automation partner may be required, even in the very early stages of the capital project. An established business relationship that fosters collaboration in these instances can be invaluable.
