Counted Beans was an accounting business. Most people think of accounting businesses as fairly boring places, but in this case, most people would be wrong because Counted Beans was a chaotic place to work, and there was never a dull moment. Everything seemed to be more urgent than everything else! And the problem was that there didn’t seem to be any way to stay on top of things.
The main way that jobs were assigned at Counted Beans was a sort of ‘first in, first out’ system – that is, a job was assigned to the next available person. After all, the sooner something was started, the sooner it would be finished. But that meant people were often working on tasks they weren’t all that familiar with, so it either took longer to do each job than it really should, or more people had to be assigned to each job.
All too often, Counted Beans found that their most valuable people were helping on the low-value jobs, hampering added value billables. Compounding the issue, the cost of jobs, reported through the timesheets, were frequently over budget, leading to a large write-off of time as non-chargeable.
The obvious thing to try was assigning jobs to whoever was best at them (a person who had more experience or more specialised skills), and cut down on the non-chargeable waste. That way, Counted Beans could be fairly sure jobs would be done quickly when acted on by their relevant specialist. But the key was those six words: ‘when acted on by their relevant specialist.’ Queues of work built up quickly, with many jobs waiting for the assigned specialist to become available. It got to the point where the lead time for jobs was expanding uncontrollably, even though everyone was working at the jobs at which they were best.
The situation at Counted Beans teetered uncomfortably between both of these extremes. The partners who comprised the management team would try to assign jobs to the appropriate specialists as much as they could. Then, when lead times were getting too high, they would switch to throwing anyone available at jobs, sometimes hiring additional temporary workers, in an effort to get the lead times back down again. It sort of worked, but it seemed like chaos was a constant part of the business.
Matters came to a head one day when the management team realised that they didn’t actually know what jobs were being processed. Sure, they had a list of customers, and they knew the jobs the customers wanted them to do and when the jobs had to be done by. But often when one of the managers went to check on progress for a job, they found that the person it had been assigned to was working on something else entirely.
It wasn’t really the operators’ fault: they were just trying to make progress on a task for a different customer, so that when the customer contacted them to ask where their job was at (which happened often, sometimes repeatedly, especially as lead times got longer), the operator could truthfully tell them that progress was being made on it.
Something had to be changed. It was bad enough operating under what seemed like constant chaos, but for the management team, if the team didn’t even know what was being worked on then things were getting badly out of control. The management team at Counted Beans took the unprecedented step of stopping all new jobs, even for existing customers, until they could get a handle on what was actually happening in their business.
One thing the management team didn’t want to do, however, was just allow any and all jobs into the system whenever someone felt like it. That’s what they’d been doing before, and it had led to all the chaos and confusion that had nearly spun Counted Beans out of control. The management team wanted to be very deliberate about what jobs were being worked on, so that they could maintain visibility of who was doing what.
To control what jobs went into the system, the management team at Counted Beans did two things. Firstly, they chose a ‘gatekeeper.’ The sales team could attract new customers, and customers could supply jobs that would be done, just like normal, but only the gatekeeper could authorise jobs to be worked on. Secondly, all operators were told that they should reject any jobs that came to them from any source except the gatekeeper.
This gating of the release of jobs didn’t go smoothly at first. The office manager who acted as gatekeeper checked every so often on what people were actually working on and how they got it, and they discovered that customers or managers kept on trying to get jobs started even without the gatekeeper’s permission. Often, supervisors or other managers caused this, and there were a variety of justifications for it. Some of the justifications were good: ‘This is an urgent job’ justified bypassing the release rules, especially if there were going to be consequences for customers. Some of the justifications weren’t so good, though: “We have to keep everyone busy,” or “I wanted to get a head start on this job” simply clogged the system up with work-in-progress, and the release rules were there precisely to prevent this happening.
It was easy to see the negative effects when jobs slipped past the release gate. Queues of work started piling up, the feeling of chaos increased, lead times stopped being reliable, and jobs were finished more slowly.
Once the negative effects were pointed out to the rest of the management team, they all agreed that there actually weren’t many good reasons for bypassing the release gate, i.e. only truly exceptional cases. The few good reasons that did exist were noted down and a process was formalised for using one of those reasons to bypass the release gate, which wasn’t expected to happen very often. Everything else had to pass the release rules before the gatekeeper would approve release.
Once the release gate system was in place, and everyone was using it, there turned out to be a lot of benefit. The internal lead time for jobs stabilised, becoming more and more consistent, even given the usual day-to-day variations in workloads for the operators. The average number of recorded hours required for jobs dropped as operators were generally able to finish the jobs they had started rather than being interrupted and reassigned to whichever job was most badly at risk of being overdue, reducing pick-up and put-down time losses. Perhaps the best thing was that it became a lot easier to make promises to customers about lead times and completion dates, for which Counted Beans knew it would keep.
Operating a release gate had started as a way for Counted Beans to increase the visibility of what was being worked on. But, as it turned out, gating the release of jobs made a fundamental difference to their level of control in their business.
