At the Shutdowns SuperConference in Calgary (8 & 9 Dec 2009) I presented a paper entitled, "Do As Little As Possible, Why Shut Down At All?" The premise is that we often create more work and more downtime that we need to. We do it through poor work identification, doing the wrong type of work and by adding work scope that does not need to be in a shutdown.
The presentation was given to over a 120 maintenance professionals who focus most of their efforts on shutdowns. In the presentation I asked several questions and got some very interesting results. An automated response tracking system provided the statistical results for the questions. Those have been added to the presentation (after the event) and included in the copy you can download at the above link, as well as below.
1. Does you plant or facility schedule work that does not really need to be done a shutdown just because it is convenient?
| Always |
15
|
15.96% |
| Often |
33 |
35.11% |
| Sometimes |
25 |
26.6 %
|
| Rarely |
19 |
20.21% |
| Never |
2 |
2.13 %
|
| Totals |
94 |
100% |
2. Have you experienced forced outages within one week of a plant shutdown?
| Yes |
60 |
60%
|
| No |
32 |
32% |
Not sure
|
8 |
8% |
| Totals |
100 |
100% |
3. Was the cause of the forced outage directly related to the work that was done?
| Yes |
49 |
53.85% |
| No |
21 |
23.08% |
Not sure
|
21 |
23.08% |
| Totals |
91 |
100% |
4. In your opinion, are you more likely to experience forced outages after doing "break in" work or work that was already planned into the Shutdown?
After "break in" work
|
54 |
55.66% |
After "planned" work
|
21 |
21.65% |
Don't Know
|
22 |
22.68% |
| Totals |
97 |
100% |
5. What does downtime cost your company per hour?
$1M or more
|
16
|
17.39%
|
$500k to $1M
|
9 |
9.78% |
$100k to $500k
|
20 |
21.74% |
$50k to $100k
|
12 |
13.04% |
$10k to $50k
|
17 |
18.48% |
Don't know
|
18 |
19.57% |
| Totals |
92 |
100% |
From the statistics gathered in this small survey we can see that shutdowns are quite expensive for most companies (at least those who attended the conference - largely oil and gas companies). We can also see that most add work for convenience, most experience failures shortly after the shutdowns are over, most of those can be attributed to work that was done and that it is most likely to happen with the work that was added to scope after the shutdown began.
It seems evident that we do ourselves a big disservice by adding work to a shutdown that doesn't really need to be there. We do further harm by increasing scope with new "break in" work. That work is a result of a lack of diagnostic scoping work before hand - otherwise most of it would have been identified and planned well in advance. Most companies do an excellent job of planning shutdowns but clearly they are only planning part of what they need to plan and not planning for work
A lot of the post shutdown forced outages are due to work that was done in the shutdown. That points to a couple of factors - quality of the work is one possible culprit. Of course much of the work is done by armies of contractors - people who, almost by definition do not know your plant as well as you do. Perhaps your own oversight efforts to watch them are not working. Quality of work is something to look into here. Another possible culprit is that you are disturbing equipment and systems that are best left alone. Yes, some work must be done in a shutdown because there is no other way that we've thought of yet, but not all of it. If you disturb systems there is a high probability that you'll make mistakes that lead to infant mortality failures. A good analysis using techniques like RCM2 can go a long way to avoiding this.
You put a lot of money into planning and executing these shutdowns; they cost a lot in lost revenues and we add hundreds of thousands, if not millions to their costs by sticking with traditional approaches. RCM2 is far less expensive and will save you a great deal of money. It fits well within our Uptime services offering and is an integral part of it. Why not stop wasting your company's money - get Conscious.