Whenever I post about Maintenance Backlog, and particularly about backlog targets, I always get a similar comment from someone that works in Oil and Gas in the North Sea. The comment is along the lines of "Backlog targets are a waste of time as they (the oft maligned but rarely defined "they") fudge the numbers to meet them and don't actually do any more work."
The belief that organisations manipulate their backlog targets has existed for as long as I’ve worked in the industry, sadly not without justification.
As I’ve posted in the past, “If someone comes up with a new KPI that makes your performance look considerably better than the old one, this is a sign the change should be subjected to heavy scrutiny.”. The reason for scrutiny as opposed to rejection outright is that it's not always a bad think to filter some things out of backlog to make the information clearer.
To help with the heavy scrutiny I thought it I’d share the most common actions I see that will reduce the volume of backlog being reported without actually reducing the amount of outstanding work. I’ll look to give the positive and negative arguments for each whilst also giving my view where I think it might be helpful.
The list, should anyone want to skip is:
1. Removing deferred work from backlog
2. Removing “supporting” hours from backlog. E.g. scaffold erection, isolation hours, scaffold destruct etc.
3. The inclusion of a tolerance for when a PM should be considered to be “in backlog” when not executed in line with the strategy frequency.
4. Not reporting work orders that have not finished being prepped.
5. Removal of all work orders not validated.
6. Removal of “Maintain the equipment” maintenance from safety critical reporting and only reporting verification or “Test the equipment works” from backlog.
7. Not reporting work orders that are partially complete.
8. Reporting by hours or work order count, depending on which is greater.
9. Reporting in weeks based on a theoretical productive time and not actual.
10. Not reporting work that is either in the process of being deferred or has had a change request submitted.
1. Remove deferred work from backlog.
This is the most controversial one first as this is one that sparks an unbelievable amount of debate...
For
The argument for taking deferred work “out of backlog” is that it allows for differentiation between work that has been assessed and has a new latest key risk date assigned (ie. The date by which the work must be done before something bad might happen) and unassessed work that has a key risk date in the past.
Against
Deferred work is work that wasn’t complete by the time an organisation first said that it should be so taking it out is artificially “reducing the backlog”. To avoid this, deferred work should be left in backlog.
My View
This debate, in my opinion, gets hung up excessively on the word “backlog” for some reason. Irrespective of whether it is called backlog or not is almost irrelevant. Both deferred work and undeferred work should be differentiated and reported within organisations as both the FOR and AGAINST arguments have validity in this instance, with neither being wholly correct or wholly wrong.
2. Remove “supporting” hours from backlog. E.g. scaffold erection, isolation hours, scaffold destruct etc.
For
By removing the supporting hours and any destruct hours etc there is complete clarity on how long the actual “main task” will take, giving a better indication of how much “actual work” is required.
Against
Work should include all tasks necessary to do the job. Simply reporting the “main task” in the middle is pointless as it can’t be executed without the support work so taking it out gives a false indication of the amount of effort required to do the work. It also adds no value in terms of risk quantification as the number of hours necessary to do the task often bears no direct relation to the consequence the work is to prevent.
3. The inclusion of a tolerance for when a PM should be considered to be “in backlog” when not executed in line with the strategy frequency.
For
The risk associated with not completing preventative maintenance on time does not immediately escalate if it is not executed in line with its strategy to the day. As a result, a tolerance is added to better indicate how long that preventative maintenance can remain incomplete before a real risk materialises.
Against
1)It’s impossible to predict the exact day that the risk may materialise when a piece of preventative maintenance is not complete in line with its strategy so adding a tolerance based on % of frequency etc adds no real value.
2)If every instance of the work being completed makes use of the tolerance added then this will considerably reduce the volume of maintenance complete.
3)If point 2 is acceptable then the frequency of the PM should simply be extended to avoid over maintaining.
My View
I agree with the against. The simpler a backlog metric can be the better. I’ve spoken to a number of organisations where there are very few people even aware that there is tolerance being applied to the calculation of dates as it’s being carried out by the system in the background for most users.
Also, if an organisation says “This PM should be executed every 6 months” then it is important to see if it is doing so, not if it’s being executed every 6 months + 10%.
4. Not reporting work orders that have not finished being prepped.
For
The hours on any work order where the preparation work has not finished are not yet confirmed as accurate and, as a result, should not be reported.
Against
The work has been confirmed as needing done and the hours captured during the work preparation phase, even if unapproved, represent the best organisational estimate at that time so they should be included.
My View
Some organisations I’ve supported are so firm on this view that they will not even set the key risk date on corrective work until the work order has finished being prepared, never mind include the work order hours estimate.
Whilst I recognise that hours are not accurate until prep is complete, I agree with the against position. Backlog reporting should be based on the best information currently available to the company as this gives the truest indication of the level of effort to resolve. It is preferable to report this as a potential work case than a “best case” that is known to be wrong.
5)Removal of all work orders not validated ( i.e. newly identified work that has not been reviewed by site leadership and confirmed as valid.)
For
Work orders that have not been validated are not confirmed as being legitimate scope to be executed. As there is no confirmed intention to execute they should not be included in backlog figures.
Against
In a high risk industry, the default should be to confirm as safe before inaction, not confirm as unsafe before action. As a result, any work request should be captured within backlog.
My View
I agree with the against position. A non negotiable requirement of an effective risk and work management process is the timely assessment of newly identified instances of risk. If a work request has been sitting long enough to exceed its first nominated Key Risk Date without being validated then this is an unacceptable position for an organisation to be in.
6. Removal of “Maintain the equipment” maintenance from safety critical reporting and only reporting verification or “Test the equipment works” from backlog.
For
This allows clarity on what assurance maintenance has not been carried out, meaning there is complete clarity on which items of safety critical equipment have not been confirmed as in operation.
Against
By omitting the work to maintain the equipment, and to only include the work to test the equipment functions on demand, an organisation only ensures that the equipment worked the last time it was tested, not the next time it will be tested.
7. Not reporting work orders that are partially complete.
For
This allows for increased clarity as the work has already started, hence is likely to be complete soon so the risk is no longer relevant. Filtering these work orders out allows greater focus on the work that is not yet being executed.
Against
Started isn't the same as finished and the risk exists until the work is complete. Also, starting a job might just be preparatory work and not actually do any work to eliminate the risk.
8. Reporting by hours or work order count, depending which is greater
For When Changing To Hours
Work order count does not give an indication of the level of effort to execute the work as one work order could be 30 mins or 100 hours depending on the scope. Reporting in hours gives increased clarity.
For When Changing To Work Order Count
Work order hours does not give an indication of the number of individual instances or risk, as one work order could be 30 mins or 100 hours depending on the scope.
Against
Using either option does not present the full impact on backlog. This is an instance where it should not be an “either or” but instead both should be reported.
9. Reporting in weeks based on a theoretical productive time and not actual.
For
Getting actual wrench time relies on accurate time in motion studies so it is not practical to calculate it every month. It is easier to base a week’s calculation on the best possible achievable wrench time and understand that is the best case.
Against
Most operators vastly overestimate the wrench time that is possible for their teams to achieve. Basing wrench time on an unrealistic figure undermines the quality of the data being reported as it results in an excessively low number of weeks of backlog.
10. Not reporting work that is either in the process of being deferred or has had a change request submitted.
For
Steps have already been taken to remove the work from backlog so it should be removed until it is confirmed it should remain.
Against
Asking for work to be deferred is not the same as the request being approved. The same argument against removing unassessed new work applies. In a high-risk industry, the default should be to confirm as safe before inaction, not confirm as unsafe before action. As a consequence, the outcome is that any work requesting removal from backlog should be included until the request is approved.