Sometimes Less is More and More is Futile
Updated: Oct 28, 2019
In early project development the goal is always to find solutions to a problem. Whether that problem be economic, regulatory, safety issue, or whatever; the project development team members are the problem-solvers tasked with finding the most suitable solution. For most of us, doing the front-end loading (FEL) research and analysis to identify the problem and uncover a creative solution is our calling. We love what we do, and we work to do it to the best of our abilities.
One of the biggest challenges we face in the FEL process is holding the course and working through the process despite a myriad of pressures – schedule constraints, management whims, resource limitations, etc. Without strong leadership these pressures may lead the project team to deviate from a reasonable approach to project development to what many call a ‘fast-tracked FEL’. Fast-tracked FEL quickly becomes a hodge-podge of tasks and checklists. As Ed Merrow says in Episode 5 of the Innovate iPM Podcast, “Front-end loading is not a mechanical process. Front end loading is a creative process and that absolutely is dependent on the quality of the team.” With the rush of urgency by the team and the project stakeholders to ‘check the boxes’, there is no space left for the creativity required to do the job well.
The all too familiar cart appears in front of the horse, then the horse runs it over and smashes it to pieces. Too much? If we fail to execute the FEL work properly, we will fail to identify the root-cause of the problem. Blind to the root-cause, we deliver very precise data on a ‘solution’ that does not meet objectives. This precise data on the wrong scope creates expensive problems that are difficult to overcome.
Why?
Wandering down the wrong path in FEL gives the project team a false sense of accomplishment and unearned confidence. This is bad mojo for the rest of the project. The false sense of accomplishment is usually reinforced by doing more than is needed for the FEL process. And doing more is harmful to the health of the project and pointless without the appropriate level of study and analysis.
Example: Getting more product to a distribution terminal
Imagine being tasked with debottlenecking a terminal line to reduce product loading times and stopping at just increasing the capacity of a pump and pipe flow without considering electrical load. It’s a simple and silly sounding scenario but these kinds of amateur miscalculations happen every day in industrial project organizations. Once the team homes in on that part of the solution they start getting to work to resize the pump, get a quote, determine tie-ins, resize lines. Maybe they build a model and start adding foundations and structural elements. They are proud of the output of their work – the model, the drawings, and, dare I say, bill of materials. They say, “well we were only looking for +/-30%, but really we think we’ve put in enough effort that we are probably +/-10%” and then go for funding. Let’s say they go for the total installed cost budget of $500,000.
Because they failed to do an electrical load study, they only find out later that the MCC cabinets are already to full capacity and can’t handle the 750hp motor they specified without adding another bus and cabinet. Cost of project just increased by $175,000 or 35%, just over their initial commission of +/-30% and to the detriment of the budget.
It is possible in the rush of getting it done the P&ID haven’t been vetted to the right decision-makers. They find out after funding that the tie-point location is off by 500 feet because they are on the wrong side of a valve and can’t make a cut-in like they originally thought. Cost of project just increased another $52,000 or 10.4%. Now we are 45.5% over our original study – the one that was used to fund the project despite project development standard operating procedures.
The worst part – it turns out a simple change to the impeller and small storage vessel would have resolved the debottleneck issue at a significantly lower cost. The project team did a great job at sizing the pumps, designing foundations, specifying instruments, etc. for the wrong scope of work. This project was budgeted on the wrong solution. This scope only nominally improves the problem without extra storage capacity. Money was unnecessarily spent. Opportunities to invest that capital elsewhere are no longer possible. This project has failed to meet the objective.
In the end the team has wasted valuable time, effort, and resources. Not only were the physical and talent resources wasted, but there was an unseen loss of opportunity that should also be considered when determining how successful the project outcome was. The team only got by because over-worked middle managers rubber stamped a package with a false IRR. There were all kinds of problems with this scenario. The most fatal was that the team believed estimate accuracy level is defined solely on level of effort in design and engineering. The PM probably drug up when he realized the ship was sinking and someone else had to do the dirty work of picking up the pieces and trying to salvage as much as they could. Someone may have lost their job and ruined their reputation in the process.
Solutions:
Determine the root problem early and start off on the right foot to a solution
Be candid about the risks of fast-tracking a project scope. Be realistic about deadlines and don’t be afraid to request extensions. As an old-timer once told me – they’ll forgive you for being late, they will never forgive you for being wrong.
Build the right team, engage the stakeholders early, give people decisions to make
Don’t let the plan stifle creativity. Remember you are on mission to provide the best possible solution to a real problem. You can accomplish the plan and still lose the mission. Being flexible and willing to change course will help succeed with the mission.
Address all risks – don’t exclude them until you can confidently do so
These are my thoughts and thoughts I’ve collected from people whose experience and wisdom are greater than my own. I have no doubt there are more ideas and practices to improve your chances of success in the early phase of project development. What are yours?