Someone I work with in the UK nuclear industry asks in despair, how come project engineers don’t feel that the whole point of building something is for it to operate? In other words, that construction projects only exist to create something that will be used to deliver products and services.
Why aren’t they interested in the long-term use that comes after construction?
If it really is all about use, they really need to consider what is required to use the asset. They should be interested!
This isn’t just to focus on what service we need to deliver. The asset has no point unless it delivers a service that is needed. Even project engineers can get that.
What we continue to struggle with is getting asset construction engineers and project managers to consider what is needed in order to use it successfully. And this includes providing as-built data – what assets are there to operate – and thinking ahead on operating strategy, and maintenance schedules. It’s designing and building with the operations and maintenance in mind. Designing for operability and maintainability.
In infrastructure, the asset ‘users’ are often not the customers, who may never touch or even see the assets. The people who use the assets are the operators; the people who touch the assets, maintenance.
An engineering design goes through many hands before it impacts on the customer – and if those hands in between are hamstrung by designs that are poor to operate, hard to maintain, and by the incomplete thinking that ‘throws the assets over the wall’ at operations (as we used to say in the UK) without adequate information – what is the point, really?
I believe there may be something called project time, where there is no ‘after’. No ‘and then what?’ – just onto the next shiny thing to build.
What does perfect Asset Management look like? What’s at the top of the mountain we’re climbing?
And what’s a metaphor between friends?
But to some of us it’s more a windy, winding road, over yet more hills, where we sometimes see part of the road up ahead, but never glimpse the end.
Why does this matter? Having recently faced a virtual room full of people saying they would know what to do next, if only someone could describe the end state for them: as though Asset Management is an accomplishment, something you can complete. Done, checklist all checked, and move on?
In contrast, is there a destination for, say, engineering? Although many engineers may not examine what they believe, they surely think of engineering more as a state of mind, a way of thinking, rather than something that gets finished. (And who even has a vision of HR?)
We could describe the top of our mountain as the point where everyone takes it for granted that we think longer term, whole system and lifecycle, use information wisely, and truly embrace uncertainty.
But I don’t think that’s what the metaphor betrays. I think it’s more ‘when we have a complete asset inventory and a strategy for every class’ and can stop thinking about them and move onto something more fun. The way some, at least, appear to think a check the box approach to ISO 55000 is what we need, or even the point.
But, you know, it’s also whether fun to us means continual discovery, the thrill of not knowing and then learning – or getting back to my desk to fill something in.
Roll on, rolling road!
My boss has been heard to say that when they started the company in 1997, he assumed that within a few years we would have figured everything all out and would just be applying the Asset Management manual. Instead, we learn something new on every project… Twenty five years on, that’s certainly true for me.
My old colleague John Lavan described what we have to do as tackling problems, not solving puzzles.
A puzzle is (in his terms) something where you already know what you have to do to solve it. It’s a rule-based game, like school-level mathematics. Apply this methodology and it will come out right.
Whereas we are faced with problems, where we don’t necessarily know what to do, or if there is a good solution.
As soon as we work out a useful approach on something, we’re faced with having to evolve it further. That is, even if we’re lucky enough to have a good way to start.
Fellow Talking Infrastructure Board member Lou takes this further. There are puzzles, which don’t resemble Asset Management, but perhaps some engineers still wish for; problems, which seems to be our AM world; and predicaments, where there maybe isn’t a solution at all.
I’d like to think building an asset inventory is a puzzle that we already know how to solve. Plenty of individuals don’t yet know, of course, but that feels like just an issue of communication.
On the other hand, what’s an effective strategy for Asset Management in a particular organization? We know the principles (alignment to corporate targets, the Six Box Model of elements), but that’s merely the opening tool kit. Making Asset Management business as usual is a problem, still, for just about everyone. Too many variables and different nuances.
Old age is a predicament. And as for climate change? Maybe, given human psychology, it’s a predicament, not simply a problem.
I’ve long been fascinated by the idea that we need ‘bridges’: people who can translate between two domains with different mindsets.
One key gap to bridge is between science and management, as Penny describes https://talkinginfrastructure.com/2022/07/20/science-and-asset-management/ . There are other gaps that affect us in asset decision-making.
In the late 1990s two of us, now very senior IT director Christine Ashton and me, put forward the need for such active translation between IT and business users. IT has always struggled to understand what’s really needed by users, as the users themselves are poor at describing their information and information processing requirements.
Christine and I set up a special interest group in the British Computer Society – an organisation which could do with some translation in the first place – for people who work between IT and business. We had a great time discovering some very good people, who, I am happy to say, generally earned pretty good remuneration for their ability to understand what the users need and turn it into something IT techies could understand (and use). It’s still a rare and precious ability.
And it’s surely still as big a challenge as ever.
Add to that how to bridge between an engineering mindset and business. I train engineers who still radiate – why do I care what the objectives of the organisation are? My job is to do the right thing by the asset, regardless of management.
It’s fascinating in all three cases, because scientists, just like engineers and IT in their different ways, are kinda proud of their ability not to compromise with business and organisational realities.
In particular, the issue of ’embracing’ uncertainty is just so relevant to Asset Management. But we educate scientists, engineers and IT to hanker after 10 decimal places of clarity.
And, I fear, not to ask ‘so what? – or, what happens next?’ as often as they should.
“The worst misunderstandings sometimes happen between different teams within the supposedly same ethnic group, particularly if they [come] from different locations or had different professional training (say, IT workers mingling with engineers)” – Gillian Tett
I have long been fascinated by differences in approach between engineers and Asset Management professionals – how AM is not just another variety of engineering. And, for that matter, why Operations managers don’t think like AMps, or how IT teams look at the world. For instance: what is it that motivates people in IT teams? (Not, I think, the pleasures of making users happy.)
In my own life, I seem to have sharply favoured working with maintenance, or ex-maintenance people, rather than Engineers with Capital E. Because they were very different experiences.
It is not that there have not been engineers who are massively important to me, such as my brother, or my parents’ best friend Ed – but then again, they never acted like typical engineers, and were not very polite about such ‘grey men’ (Ed’s phrase) themselves. That engineering does have its own cultural norms, some quite odd, has been a question for me for many decades.
So my eye was caught by the review of a book by Financial Times editor Gillian Tett, Anthro-Vision: How Anthropology Can Explain Business and Life. About trained anthropologists such as Tett who have found themselves working in businesses, such as Google or GM, or what they would advise governments on dealing with COVID-19.
She describes how anthropology is about both investigating what’s strange, other, exotic, and about the tools to see our own culture/s, to understand what is weird (or even WEIRD) about it. The book has plenty of interesting examples – about Kit Kats in Japan become an indispensable good luck charm for school exams, about dealing with Ebola or ‘CDOs’, as well as more effective advertising and work practices.
But it particularly made me think of how to understand the oddities of current engineering – why is so often tends towards the short term, to silos and uncoordinated stupidity, even resistance to data. Surely none of those attitudes are ‘logical’ – so what is really going on? I take it as given that, like IT, there is a coherent motivation, a vision of what it means to be a good engineer. So how come… that doesn’t play nice with Asset Management, so often?
And then again… what is the culture of Asset Management, developing before our eyes?
Because I also take it that if you don’t try to understand the water you swim in, you also don’t really understand what you are doing – how it might need to change or evolve – and why it gets up the nose of others who don’t share your basic values.
There is always culture, always weird to someone outside it, and managing infrastructure involves several different ones. So we must have anthropology in our Asset Management toolkits, too!
Next: Ethnographic approaches we might use in practice?
Some days, it all feels quite hard. We know that infrastructure Asset Management requires a change in attitudes, in culture, and that’s no fun to anyone who just wants to get on and manage assets well. I teach AM, and always say that the tricky bit is attitudes, using co-operation and longer-term thinking as two culture shifts we need if we don’t have them.
But some days it seems more than this. Why does IT think IT assets are special, and so shouldn’t be subject to the same AM planning and prioritisation processes? Why doesn’t engineering care about information – not just as-built, but the need for any evidence for their decision processes. (“How do we know what benefit we will get from better information?”, an engineering department wrote recently in opposition to a data improvement initiative.) Why is Urban Planning not interested in any conversation about the current state and utilisation of the physical assets, and how did they come to despise maintenance (why does anyone despise maintenance)? Why do operations, executives think they don’t need KPIs? What do they think they are arguing for?
AM is on the side of good, evidence-based rationalism: wanting to do the right thing based on logic and facts. It is very hard for us to deal with people who are not.
Some days it feels rather like attempting to argue with an anti-vaxxer, or a Trump supporter.
Obviously, when they look at us, they don’t see champions of logic and good sense. Maybe they see a threat – but what do they tell themselves? Answers, please….
Recent Comments