Decision making is a profession
16 December 2011 • Ype Wijnia
policy development, planning
In all asset management problems a decision has to be made. Do we continue maintaining the old machine or will we replace it by a new one? Will we invest in new capacity or will we employ operational measures to increase the capacity of the existing assets? Which manufacturer of assets will we contract? How many spares should we keep in store? Even the target for example to reduce the maintenance cost by 10% will start a quest for finding the maintenance actions that can be postponed without compromising the risk position too much. The statement at the start of the paragraph could also be inverted: if there is no choice to be made, there is no problem.
Thinking about the vital role decision making has in asset management it might come as a surprise that making the right decision receives very little attention in the asset management literature. For example, in the formal requirements of PAS55 the term decision only appears twice. The first requirement which mentions decisions is 4.4.6, stating that the information should be adequate to make the right decision. The second appearance of the term decision is 4.7, stating that the management review output should include decisions on changes to elements of the asset management system. That something could be documented on the way decisions should be made is only mentioned in the second footnote with the asset management strategy (4.3.1). This at least suggests that decision making is a non-issue. If the employees are supplied with the right information and are adequately trained they apparently automatically know how to make the right choice.
Maybe it is just the case in the United Kingdom, where they also are able to do difficult things like driving on the left side of the road, but here in the Low Countries we see that making decisions does not come as natural as one sometimes presumes. A common approach in solving bottlenecks is that an engineer will prepare a project proposal. Only when the proposal is almost finished it will be discussed (by means of submitting a budget request) with higher management. A few things can happen. The engineer can be lucky and stumble upon an accountant. Accountants are predictable people, as they always will ask the same questions:
- Can it be done cheaper?
- Can it be done later?
The engineer can prepare easily for those questions, by requesting a little bit too much budget and by initiating the project early. With some heavy sighing, moaning and frowning the engineer will promise to try his very best to cut costs by 10%, but then the project has to start next year at the latest. Well, accountants may be predictable, but they are not that stupid. Based upon earlier experiences they will presume that the engineer has built in 10% financial margin and 1 year of postponement into the proposal and will not accept the offer made by the engineer but demand more. The arms race of inflated project proposals has kicked off.
The engineer could also have bad luck. This is the case when the proposal is intercepted by a manager who used to be an engineer. It is truly bad luck if that manager was in the same field of engineering. The proposal then will awake the techie in the manager, and the temptation to tinkle with the proposal will be too large to resist. Sometimes it will be small things, just to put his mark, but it can take serious forms. The manager for example formulates functional requirements that demand a complete redesign of the project, or even worse, he will make a radical redesign on the spot. The engineer then is stuck with a design that he does not understand or which can be impossible to construct. The best way of dealing with those decision makers is involving them much earlier in the design of the project, for example already at the kick-off of the project. But what then happens is that the work is delegated upwards. The engineers are hired to make project designs, but all they actually do is working out the details.
The third possibility is that the engineer engages a decision analyst. This is not bad luck anymore, but it would be a true disaster. Where both the accountant and engineer accept the need for the project without even blinking their eyes, the decision analyst questions the need for the project by asking very strange questions. What can go wrong if the project is rejected? What is the problem the project is supposed to solve? What alternatives are available for solving that problem? Those questions are often very difficult to answer. The whole essence of being was reduced to the go/ no-go decision for the project. A blunt rejection could still be attributed to the technical incompetence of management (or just blame marketing for it), but asking for alternatives… That reverberates in the brain. Why would you include worse alternatives in the proposal, adjacent to the presented best solution? This stretches the imagination of the engineer. How bad can the alternative be made before one loses credibility as an engineer. And what if such a purposely bad alternative is chosen anyway? Engineers who meet a decision analyst in the approval of their proposal often run around like living dead. Wars have begun for less, so to say.
Unfortunately for the engineer, the decision analyst has a point. What is the best solution for a problem depends on how the stakeholders value the different effects of the alternative solutions. Even accepting the problem can be regarded as an alternative with its own outcome. By juxtaposing the effects of the alternatives the best option can be determined in discourse with the stakeholders. The best option is what the decision makers perceive as the best option. Best is therefore a subjective qualification.
In practice, it can be very difficult to involve all stakeholders in all decisions. A pragmatic approach is to capture the opinion of the stakeholders in a business value framework which can be used for assessing the projects. To be useful such a framework has to be down to earth, abstractions cannot be measured.
But this is not all that is needed. If this is applied without any other adjustments, the engineers are only confronted at the end of their work with the question about the problem they are solving, which does not seem very efficient. It is better to define in advance what problem is to be solved, so that alternative solutions for the same problem can be developed. It is what we call Chain Reversal in decision making. If you think about this on a more abstract level, it means one first has to know the risks (= collection of bottlenecks) before designing mitigations.
This brings us back to the position decision making has within PAS55. With the emphasis on information and competences PAS55 suggests that the right decision is something objective. But much of the information you need in the decision is not objective at all. Part of the information consist of facts, like numbers, prices, ages, and so on. But whether the problem actually will occur is something in the future and by definition uncertain. Besides, the best option depends upon the valuation of diverse effects and that is also by definition subjective. In such circumstances, the best solution is not always obvious and certainly not objective. It would not be a bad thing to pay a little more attention to the method of reaching decisions. After all, decision making is just a profession.
Ype Wijnia is partner at AssetResolutions BV, a company he co-founded with John de Croon. In turn, they give their vision on an aspect of asset management in a weekly column. The columns are published on the website of AssetResolutions, www.assetresolutions.nl/en/column
<< back to overview
|
