Recognizing expediting
Expediting is when a process is sped up to ensure it completes faster.
Sometimes expediting is well-defined and is part of a service offering: being able to send a package faster, for example, is an important part of a shipping company’s services.
Other times, expediting is done on an ad hoc basis: the requester is the CIO, so people try to move faster than they would otherwise, or the request has been escalated and now it will be handled specially to make sure it’s complete.
A core goal of Lean process improvement is to make problems visible. Expediting needs to exist in the same way that buffer stocks need to exist. (Buffer stocks are the ready-for-the-customer inventory a supplier keeps to make sure customers can receive inventory even if there’s a process breakdown.) However, just like buffer stocks, any time you observe expediting consider that there may be a process issue to investigate.
Here are some examples of expediting:
- Ticket has still not been closed, so the user calls the Service Desk to check on its status. As a result, the Service Desk employee realizes the ticket should have been closed already, and they close the ticket.
- A project manager needs a server for their project, and they are concerned that ordering the server might have a long lead time. The project manager talks to the infrastructure manager and the infrastructure manager promises to hold aside an existing server for the project.
- The CIO has just been asked to provide a timeline for an important project. The CIO follows up with the PMO to get a timeline. The PMO drops what it is doing and starts working on the timeline.
- A new employee is coming on board next month. The manager wants the employee to have everything they need, so they call each area to make sure all tasks are being addressed in a timely manner. They may rely on promises from team managers.
Again, expediting in itself is not horrible, but expediting potentially tells you about how a process is performing.
Expediting because a process has many defects
Sometimes the people performing a process do not know all the steps or they are likely to miss a step. For example, if a new ERP user needs access granted from five different teams, if the process is not well-defined it could be easy to miss one of those five teams.
Expediting in this case–for example, checking in to ensure a process is being performed properly–is a way of getting the desired process outcomes even though the process may not reliably generate its intended outcomes.
In this case, a kaizen-style improvement session that includes the people performing the process and example recipients of the process can help one another understand how the process is currently working. Because it is possible for the process to generate its intended outcomes through expediting, it may be possible to reduce process defects quickly.
Expediting because a process is not in control
When a process is “in control,” then a large percentage of the time the process is producing outputs within a certain range. For example, the length of time that someone talks to the Service Desk may be considered to be under control if there are bounds that can safely be applied to it e.g. the call will take somewhere from 15 seconds to 60 minutes. Then, through process improvement we can try to tighten the control limits or shift the mid-point of the process outputs.
There are frameworks that specifically focus on process control, notably Six Sigma. However, it is uncommon in higher education for many processes to be under control or for people to focus on process control.
If a process is not in control, people often use expediting as a way to force the process to perform a certain way for a particular input. If you observe regular expediting, that’s a possible sign that your is too unpredictable.
In this case, a value-stream mapping activity showing how long the process takes to perform under different conditions may help identify the most erratic steps. This mapping can be done with the people performing the process. For example, you may find that some teams do not check their tickets in a timely manner, and therefore expectations need to be made clearer for those teams.
Expediting due to unclear “levers”
Managers need “levers” or mechanisms to help them make decisions. Should we pursue project A or project B? How do I decide when a project starts? How do I say when an issue is high priority?
When there are not defined levers (such as not having a decision point for when a new project begins), or when the existing levers are out-of-balance (such as if all incidents are considered high priority), managers do not have a good way to make decisions. The only decision left is then to expedite whatever the manager sees is most important.
By making clearer any existing levers and especially the consequences of those levers, you can remove the need to expedite. As a simple example, some vendors require the customer be available 24×7 to respond to any urgent-priority tickets: urgent means the customer thinks it’s urgent enough to be available.
Expediting due to overwork
One of the three types of Lean waste is overburden or overwork. When people have too much to do (e.g. too many simultaneous active projects, too many open tickets) then new work may be delayed. Yet, this new work may be very important and there is a perception that it can’t be delayed.
Expediting new work to take precedence over existing work, also known as prioritization, is unfortunately very common. There can be many root causes, such as scope creep, unclear zones of control, or a vicious cycle due to low perceived value of service. By noticing that expediting is occurring, you have a clue that there’s a root cause to investigate.
I doubt many organizations can escape overwork. That said, the number one thing you can do to address overwork is to meet your promises, and show how any changes affect those promises. If you promised a project would be delivered by January 15, highlight any changes that affect that date and if there are no substantive changes then make sure you meet that date. In other words, see the “processes in control” section above.