I am an advocate of change for the better, as well as the preservation those things that work well, but there seems to be a lack of good balance between the two these days when it comes to project development in mining. It seems to me that too much gets thrown out with the bathwater as soon as something that seems better comes along.
Hopefully we may yet be able to recall some of those things that worked, as we weave this modern age around us.
There are new embedded philosophies today that differ from where we were a number of years ago. Some of these new philosophies are really stubbornness, inexperience or technical arrogance in disguise, though perhaps some of it is new wisdom.
But, as a colleague of mine noted recently: “We are into a situation where the project that meets its commitments is the exception, not the rule.”
It’s a pretty dismal view of the state of our industry, and it’s no consolation that some other industries share the same fate.
In my previous commentary (T.N.M., June 25-July 1/12) I suggest that almost all of us in the mining industry are responsible for the soaring costs and schedule slippages. But let’s start with just one piece of the puzzle for now: engineering.
I wonder whether things were better in many respects in the past, at least in part, because the manual derivation of project details was more laborious and by its nature included the kind of plodding needed to figure things out virtually from basics.
It seems almost archaic to think of how things were done. For me it was old Jim Cole and his buddy cloistered in a windowless room, doing nothing more than red-lining drawings as they were brought to them to check for mistakes, logic, practicality and anything else they could dredge up from a combined 90 years in the industry that had to count for something.
Then there was my poor old Kurt, who trailed the hallways like a forlorn ghost looking for project team members who could enlighten him on the cost impact of design changes and why there was any deviation from the study. After all, the detailed design was being done by the same people that did the study — so what changed?
Kurt was not just looking for cost changes but also accountability. As the estimator during the study there was no way that he was going to let others just throw away all his good work by flippantly changing their minds as they followed a separate path down the project development road. He pressed them for answers that made sense, and they knew he was coming!
Back in those days, every morning before my work started I would be met by the beaming “gotcha” smile of Mike sitting in a chair opposite my desk. He was one of our project schedulers, and I have to admit, he did things manually — the critical path method — regardless of the complexity. You can imagine how fast his pencil erasers wore down. Boy, he was aggressive but it was all a part of the job and at the end of the day there was no going back on him. He needed everything out of me and the teams, and committed it in schedule form to paper.
Things took longer in those days of manual derivation, and that extra time was used by people to think more before making any commitment.
But wait a second: did it really take longer, or did the extra effort result in fewer iterations, more accountability, and less ‘plugs’ for lack of instant answers? Come to think of it, I seem to recall that the process was pretty fluid and efficient. It certainly didn’t take us longer to engineer or build. Come to think of it, I think it took us less time and it was more accurate.
So what has changed? Well, I suspect that what may be the principal originating culprit is computerization. I know, it’s easy to knock IT but we now have at least 30 years of experience to draw from to form some kind of a theory. And I am pretty sure the introduction of computerization is when the collapse of reason in our industry started – at least when it comes to the costs and schedules of project development.
From the first days of the Intergraph machine — the original CADD apparatus from the early 1980s — I knew there was major change ahead. That poor operator spent the better part of his day stooped over in a black-curtained booth, making unilateral decisions concerning plant layout, using primitive computer tools that had no degree of scale.
No-one questioned his deliverables because it was too difficult to argue with technology in those days.
And that was when it all started to slip away: when we couldn’t easily pour over the drawing as it was created, and put in our two cents’ worth of commentary.
While the industry was destined to become computerized, it was also destined to create amateur designers out of AutoCAD operators. But those drawings sure looked impressive and the team was really starting to churn them out, but have they ever saved money? Well, no. In fact engineering costs have been spiraling ever upwards — but that is the subject for another day.
Then along came the computerization of document production, with Excel emerging as the king of spreadsheets and Word as the queen of word processing. Then databases, policies, procedures, specifications, matrices, and so on, were all being churned out en masse, and the detailed checking and individualization of projects went out the door or down the plug hole.
I think all of us were mesmerized by the professional, if inaccurate, look of things.
Meanwhile, plants were being built based on non-dimensional equipment layouts that compromised access and resulted in more field adjustments; documents were prepared with little more than a glance, let alone a technical review; huge databases of quickly out-dated and often-slanted information were being held together by the slogan “more is better.”
We started to relax back into a posture that said, “It has to be right. The computer says so.”
I recall sitting with an engineering executive once as we tussled over the responsibility for $2-million worth of field corrections needed on about $8 million worth of structural-steel design developed through their latest 3D computerized drafting. He threw a hand in the air and said casually, “Oh c’mon, that’s just chicken-shit stuff.”
I think he missed the point, and things never improved.
Does it sound as though all this is leading to my advocating going back to those days of totally manual labour? Not a chance. But I do advocate a return to basic controls. I mean building in mechanisms based on the same ideology but using the stream-lined tools of today, and most importantly, making everyone responsible for the quality of his or her work.
In the age of computers we have created generations of proficient computer operators but not necessarily ones with the qualities needed to best understand the output.
Here are some ways to improving things: introduce training programs in design offices; introduce regular knowledge-sharing sessions at lunchtime; give owners a cost break for inexperience; take ownership of any capital-cost estimate and schedule you create or inherit; and reintroduce a checking procedure for deliverables.
We need to get back to the principles that were the basis for past years’ proven successes.
Without these principles, capital costs will continue to rise, schedules will continue to slip and the fun will disappear.
— Jay Collins is a professional engineer and president of Vancouver-based Merit Consultants International. www.meritconsultants.net.
Be the first to comment on "Commentary: More on cost overruns on capital development"