Why are business cases so challenging? Improvement programs in Maintenance or Capital Asset Management can be incredibly difficult to “sell” to managers and executives. Even where there is a high level of dependency on physical assets and poor performance, making improvements is a tough sell.
Usually there is an inherent understanding of the functional (operational) value that physical assets deliver – production output, quality of output, timely deliveries, safety, environmental compliance, public image and even security. Getting it right produces revenues, keeps costs down, increases margins, results in fewer accidents and fewer environmental non-compliance incidents. For those of us who understand this, business benefits are “obvious”, but for those who don’t, it is a different story. Different groups speak different “languages”. Your finance people speak in terms of revenue, costs, return on investments. They see things as figures and financial statements. Somehow they need to translate your operational or functional benefits into dollars in order to truly support your ideas.
Credibility
Managers in the maintenance and physical asset management realm have often come up “through the ranks” starting their careers in the trades, as technicians, technologists or as engineers. They are technically savvy and really “get it” when it comes to the assets they are charged with managing. Sadly, those career paths generally lack a business management educational component and any opportunity to be exposed in a more general management role. As technical people – they are tops. As business managers – they are either new to the game or not even players. That is a huge handicap when seeking funding from those who have entire careers in business – they simply speak a whole different language and have a whole different set of values.
Not only are the technical managers outsiders to the “business club” (metaphorically speaking) they often have a spotty track record for success. It’s not because they are incapable, it’s because their success often depends on the actions of people who are outside of their control for success. For example, Maintenance Managers can’t improve schedule compliance no matter how much planner training they do if materials management won’t cooperate and provide materials in a timely manner. They can’t improve reliability performance if operational staff continue to abuse equipment and run it past its capabilities. They can’t achieve high reliability with assets that are engineered to be cheap instead of reliable. Often a promising solution appears, such as a new computerized maintenance system, with lofty promises of massive performance improvements. The maintainers accept the sales pitch, but the system but fail to get the results promised. Success was never dependent on the system alone – there was more to the problem! The system was the only part of the problem that was addressed. So what was missing?
Many complications
Improvements in maintenance and asset management are seldom simple “silver bullet” programs. Sadly however, those who sell various “solutions” in this realm do tend to overstate their cases and make it seem like they do indeed have a “silver bullet”. Computerized Maintenance Systems are often sold this way and many companies have been burned – they might have got the system they paid for, but they didn’t get the results they expected. There are many of these examples so companies are quite skeptical now. They need a good business case that they can believe.
Those computerized maintenance system projects often failed to deliver results for a variety of reasons often boiling down to overly zealous sales efforts and gullibility (or desperation) on the part of the buyers. Review and changes to business processes that cross functional / departmental boundaries must be a part of the program. Merely automating old processes does not improve them and even if this is done, everyone must follow the new processes as intended. Training must be delivered near to the point of go-live and sustaining training must be provided throughout the “life” of the system. People need authority to act commensurate with their level of responsibility. IT departments can’t own the system – they are there to support the business unit, not the other way around.
Other programs also suffer the same fate: root cause analysis, reliability centered maintenance, total productive maintenance, risk based maintenance, planner training, operator driven maintenance, process re engineering, and others. They don’t all fail to deliver results but often they fall short on expectations and often because of overly zealous sales efforts (from outside or even internal to the organization) and very poor implementation or follow-up on implementation. RCM often fails for these reasons. A new maintenance manager who had success elsewhere brings his pet programs to his new company and insists they will deliver the same results. Rarely will the results be the same – there are simply too many differences even among companies within the same industry.
Generally failure of these programs is because they take a “silver bullet” approach – expectations are that the new program will solve all the problems. They won’t and can’t. Then we implement poorly and do little or nothing to sustain the changes once implemented. In this field we need integration solutions that embrace many or even all of those elements to show real results. An umbrella program that includes all or most of these elements is usually needed – and that gets complicated.
Complications can arise in implementation – competition for resources is one such problem. Those are usually easy to handle if project management is strong.
Complications can also arise because of the many interfaces with other parts of the same company and their business processes which may not be changing in step. These are difficult to deal with. Finance, human resources, IT, document management, training, operations, maintenance, engineering, project management, supply chain, stores, etc. all have their own processes and they all interact. Change one and it stands to reason the others should be examined if not also changed, but that often doesn’t happen.
These programs become difficult to describe fully and to justify given all the facets they can entail. Of course the biggest complication is that we don’t know what we don’t know. More on that a bit later.
Those who understand
Generally these people have strong technical backgrounds and work in engineering, reliability, maintenance or in operations (with asset care responsibilities). They understand what the assets do, how they can fail and what to do to keep them running. They see, often first hand, the effects and consequences of failures. They are the first responders when something goes wrong and often get the blame if consequences were severe. They know that many of those events can be avoided and they welcome opportunities to improve the situation, but they usually lack the spending authority to make it happen. They need the approval of those who “don’t understand” to get the money needed to make improvements that will benefit all.
Those who don’t understand
Generally these people have strong financial, human resources, marketing, sales, operational and sometimes even engineering backgrounds. They often work in non-technical roles although engineers who focus only on design and projects (which are highly technical). What is common among them is a lack of exposure to operational physical assets and direct involvement in corrective actions taken to restore production, etc. whenever something goes wrong. They lack the “battle-scars” and understanding that comes with them.
A “translator” is needed – one who understand the technical issues and solutions who is also capable of explaining those in financial terms.
Operational people might have a good appreciation of the technical issues but often they do not understand the details. Their career paths seldom allow them to get into the details along with the technical people. In fact their experience with technical matters is usually centered on failures that occurred and related events or consequences – negative experiences that most would rather forget. Once they are removed from the day-to-day operating environment they can forget. Some organizations are highly structured and their operational people have nothing to do with assets when failed. That falls to a technical department. There are systemic boundaries between operations, maintenance and engineering, and other departments. Operators in these environments often see assets are “theirs to operate” but whenever they fail, they then belong to maintenance. Invariably this produces a frustrating environment for maintainers.
Financial staff, managers and executives are usually removed from the day-to-day operational details. Their work entails looking at money being earned and money being spent – the former is good, the latter is bad (or at best a necessity). What they never see is the money that might have been spent or earned, but wasn’t. Accounting practices only deal with hard dollars. Improvements that avoid failures or enhance performance result indirectly in greater earnings and lower costs. Often those improvements may require a short term investment (spending) to get that longer term benefit. Accounting systems often track costs as material, labor, by department, by account. Those accounts are generally associated with activities or with specific asset classes – rarely with specific assets and rarely with specific programs.
They have no real way of measuring the benefits received nor of attributing them to specific investments.
Despite this lack of a way to measure, they insist (rightly) on demonstration of potential to get a return on every investment before spending is approved and funds allocated. They also tend to cherry pick at program activities to weed out those which may not show enough benefit on their own. Sadly, those activities are often needed to support the real money makers, but because they don’t fully understand this, they ignore it. They simply don’t know what they don’t know – more on this later.
Blaming poor communication
Technical people often blame themselves as being poor communicators of the business case to others. All too often, they just don’t have the right language (business-speak) to get their points across. Business people often want the situation and solution “netted out” to just the bare bones minimum of detail. Technical people are often strong fact finders and have an inherent need to explain things in detail – too much detail for most others.
For instance, if finance wants to know how each element of an improvement program contributes to the whole and specifically how much it contributes, they want to know numbers. To them, each piece of what is being proposed has a cost and a target cost savings or revenue gain – like individual transactions. But the technical person may see the program as a whole with many parts, each interdependent on the other and integrated together. They know that removing a piece endangers the whole so they resist answering how each piece contributes in dollarized terms.
The financial folks are justifiably curious and want to know detail in a way they can understand it. Yet fully understanding “why” takes years of technical training and experience in the field. Explaining it to someone in a short span of time is very difficult and many with strong technical backgrounds are not good at explaining technical concepts in non-technical terms. Netting things out becomes a real challenge.
The business case has to be crystal clear and concise right from the start and it can’t assume that the reader will actually understand the underlying details of why it is so important. Technical necessities must be explained in ways that people can understand. In the technical world where the day-to-day reliability battles are being fought, there is rarely time or competency to be this precise in a business case. The skills needed to be good at the reliability job are vastly different than those to prepare business cases. They aren’t even taught in the same educational programs that each group of people emerged from. Emotional presentations can be made but emotions coupled with a weak business case won’t trump pure business logic.
Getting decision makers to understand (managing upwards)
Sadly there is no easy solution to this dilemma that is often faced by technical managers who only want to do the best they can for their companies. They “know” what needs to be done and sometimes even “how” to do it, but they can’t get started without money that isn’t budgeted and these days they often don’t have much spending authority. Even justifying money in next year’s budget is a challenge because it will require a business case – many get stuck and simply give up. Unfortunately in some cases, closed minded financial and general managers leave them little option.
The financial and general management people cannot be expected to attend much technical training nor to spend time in the field with maintainers and operators living with the problems that need to be solved. So how does the technical manager get his message across? Most financial and general managers are open to hearing about improvements. In fact many will even help their technical people prepare business cases if asked. We need to get them on-side and past the point of “moral support”. Their active support is needed.
A graduated approach can work to move someone towards that point of providing active support and encouragement.
Understanding and education are the keys
Education, but not too much as to lose someone’s attention span, can work wonders if the financial and general management folks are open-minded enough to give it a chance.
Quantitative business cases take a lot of effort and a certain degree of trust in the numbers that are used. It is not unheard of that financial managers reject business cases that are based entirely on figures that came from their own financial systems blaming the inaccuracy of the figures! The first step in education is to provide insight into the problem, solutions that have worked elsewhere and to show the potential for benefits to be generated.
My friend has been having a hard time getting his business organized. It makes sense that working with asset managers would be a good idea! That seems like a great way to ensure that everything is put together nicely.