Early in my career I learned about and then was tasked with writing capital appropriation requisitions and justifications. When dealing with vendors I often encountered specifications, and technical minutia that overwhelmed me with data that provided little helpful and useful information. Reqs and justifications require compelling, substantiated, and specific facts that define a positive business PROPOSITION meeting the criteria as set by company policy—payback period, breakeven, Return on Asset/Equity/Investment, etc. Today, as I read and write more of these, I am still encountering many examples that miss the mark.
What I look to do now, and what I was taught to do, is to identify the benefits to be delivered by a project, system, or component and specify the function that provides that benefit with the supporting evidence that comes from the items and/or features that deliver the needed functionality. The logical stack-up of this relationship states a clear premise and proves the conclusion, and therefore provides a sound foundation to support the business case with the necessary calculations and information.
Many project proposals are written with a focus on the building, the equipment, the “feeds and speeds,” and all the associated detail that adds up to sounding like an impressive piece of work. And it usually is. However, if the proposal doesn’t fully make the case for achieving the business goals of the project (the reason for making the investment in the effort and taking the risk in the first place), then it is not wise to proceed, and planned projects often get cancelled at that point.
{{cta(‘2862a313-9425-4862-bc60-2dc5b9b0f568’)}}
Recently, a client in the process of undertaking a significant expansion of their production operations received a vendor’s proposal for a half-million-dollar system that was integral to their project’s success. This highly-engineered system is to be the cornerstone and the critical core to the plant expansion objectives.
Unfortunately, the proposal led off by highlighting only “key features” that included reduced energy consumption compared to another technology, a statement about process efficiency, the ability to control some material content in a tight range, delivering consistent performance, and a multi-year warranty. At least they were correct in calling these “features” even though they thought they were presenting “benefits.”
As a recipient and reader of this proposal, my critical eye and my training compel me to ask why I should care about these things? The vendor certainly thinks they’re important, as they were in bold in the center of the first page of the proposal. They were intended to catch my eye, and designed to elicit a very positive feeling towards their offer. That’s not what happened.
The fact is that the success of this particular investment depends upon achieving specific metrics, whereby we achieve a 60% increase in throughput in the plant, reduce downtime by two hours per shift, ease product changeover and clean-ability to half of the current times, and more. Granted, some of the features that the vendor did mention will help deliver these outcomes, but they have left it up to the reader to make the connection and fill in the blanks as to how those features deliver the benefits that this project must have. If the system won’t produce these benefits, then we won’t get the funding and we won’t buy the equipment. The project is only worthwhile if we can be certain to accomplish the goals. This proposal should be helping me make that case, and it’s weak right now.
What I expect, and what serves the needs of this project, is explicit definition of the benefits that I should expect from each of these items, and supporting calculations and specifications to back it up. For instance, if the promised efficiency increase of this offer can be supported with data and I can see the corresponding throughput improvements, then that helps. If the material content control enables quicker cleaning times, or more efficient handling of the product that save set up and maintenance, then show that and give me the corresponding value for my payback calculation. “Consistent performance,” for instance sounds like something that ought to be expected, table stakes, in such a system, not a noteworthy feature. What is the benefit and how is this differentiated from alternatives? I need help and this proposal isn’t giving it to me.
So, if we do figure out that this is the right subsystem or element in our solution for this program, I am left with having to do the translation, the calculations, and it’s more work than it should be. The information I need that makes the technical case that supports the business case that says this will produce a high confidence solution to our production challenges is now out of the hands of the vendor.
Clearly this is not the first time I’ve encountered this challenge; nor will it be the last. I do hope and expect that the program proposal I am involved with will deliver the needed outcomes based on the evidence. Let’s all think about that as we make the case for our capital projects and when selecting our partners.
