Work Order Backlog – Good or Bad?, My Learning Experience at the Largest City on the Texas Gulf Coast.

Is Backlog good or bad? It depends on whom you ask. While I was an IT Business Analyst at the City of Corpus Christi, Texas, from 2006-2016, a big backlog was considered an acceptable situation. It was work that was both "New" work and "Approved" work that will eventually get done, someday…maybe. Because not all work had IBM Maximo Job Plans, even many of the PMs did not have all the necessary data, we counted the number of work orders and not the number of staff-hours or other measurements of time, effort, or cost. Yes, it was a rough estimate, and it included mainly reactive or non-PM work.

We referred to some backlog as "stale" work orders or work orders that have passed their "required by" date. It was work that slipped through the cracks because actual planning and scheduling didn't take place while I worked at this laid back municipality on the Texas coast. Honestly, the departments were not staffed or trained to manage the work at that level because it's a "not for profit" based operation, "production" just wasn't a term that was used very often. However, Service Level Agreements (SLA) were used in some response, and resolution measurements of high visibility incidents. Responding to gas leaks and resolving pot-holes come to mind. These type incidents were recorded on a Balanced Scorecard to measure the organization's effectiveness. We were trying to get better. It wasn't until I worked at Cheniere LNG that I got a better appreciation and understanding of maintenance planning and scheduling done right.

Corpus Christi's IBM Maximo work orders with no SLA might have a "required by" date assigned, but it was a stab in the dark and not very accurate. The value of the work would have to be reconsidered periodically but not regularly. Service Requests were not utilized, and many "New" work orders were never progressed to "Approved" by the owning department. Occasionally, I'd run a query or report and round-up "stale work" for the departments for them to review. (I was assigned to IT, not a planner or scheduler and would be concerned with system performance with the thousands of open work orders). If the work orders were generated by a PM and missed, they would typically tell me to mass close those work orders as "not performed." This stale work conflicted with the "real" work that had value to the department. It's safe to say that not much PM work was happening. Still, many PM's were generated and often frustrated the utility departments because they were not staffed, trained, or funded to do this approved work but had to manage the work orders. Needless to say, we had a lot of equipment breakdowns, particularly on HVAC units, and Water Main breaks were occurring about every 2 hours throughout the city during extreme heat. Corpus Christi also faced some serious water quality problems that took focus away from any routine processes and put everyone in "emergency mode". The vast majority of work was reactive, and critical responsive work would be queued, particularly during the summer months. This was a problem, and everyone considered this emergency work backlog a problem. In all fairness, the City of Corpus Christi's water system has been recently recognized as a Superior Water system and has won some awards regarding conversation. They are on the right track again.

The backlog that was considered as "Planning Backlog" was typically work that was waiting on material. IBM Maximo was not used for material management but solely for costing out the work. The Item master was a static dump of items from a PeopleSoft database and was updated once a week, so that common items, authorized to stock, could be used in actuals reporting on a work order. Occupationally, Material Managers did not exist within the utility or finance departments. The supply situation was usually handled by the folks in the field that performed the work. The foxes were in the hen house, so to speak, and lots of overages and shortages resulted.

The filtering of the backlog was overwhelming, and with employee turnover, the methods changed on how to tackle it. Shutdowns did not occur, so that sorting efficiency wasn't an option. So the backlog situation was never really "clean" there, and a lot of low priority work orders that no one ever intended to complete were "smoked" …poof..gone!..closed with no action.

It takes a disciplined approach to manage backlog work in a CMMS. It's a role that is often managed by a maintainer. It should be a qualified and experienced planner performing backlog management if it's important to you and your organization.

How big should your backlog be? It depends on many factors, and there is no one right answer that fits all. Are you a 24/7 operation, are outages necessary, is seasonal work necessary? Of course, I could go on and on. A significant factor is your management's policy on backlog. We did not have that guidance then. Develop the policy, the process, and the procedures on managing backlog at your organization and follow it. Change it when you need to adjust. You'll find that that sweet spot that's necessary to be productive, efficient, and have the confidence that you're working on the right thing at the right time in the right place to keep your assets up, your systems reliable and keep your customers delighted.