One of the fun things about my job is that often I find myself knitting together multiple disparate systems and scheduling philosophies. In this case, I’m working with a client on a field scheduling problem, and we’re identifying how the multiple constituencies within the organization can collaborate to deliver a high level of service to the customer base — while at the same time ensuring an appropriate level of cost.
From a very macro level, we are now trying to solve an equation for two optima: 1) How do I deliver world-class service to a customer base that needs responsive, predictable performance, 2) while at the same time juggling crews and equipment such that I am ensuring maximum capital utilization?
When we are solving for one or the other optimum, life is simple. I can simply get more resources than I need, have them sit idle and waiting for the work to pass through — in which case the work doesn’t get delayed. Or I can schedule the crews according to their optimal schedule — which may not respect commitments to my clients (the classic “cable man” or “appliance delivery” scenario).
We see the same discussion in other domains. For example, from some of the discussions I’ve participated in within the last couple of weeks:
- In IT, I have a limited number of testing resources. I need to run all of my projects through this testing bottleneck; hence, I want to structure the project to reduce the time between design and release while also optimizing the use of my testing resources.
- From a more macro IT portfolio sense, managers struggle with committing resources to projects before the projects actually can demonstrate a need for resources.
- In drilling, we have a limited number of rigs that must run from well to well performing drilling activities. Meanwhile, each well requires a series of activities to get ready for the rig arrival. Bringing the rig in too early simply means that it sits idle.
- In oilfield maintenance scheduling, I’m working through a backlog of maintenance tickets and trying to ensure efficient crew utilization. (Ok, this is not a perfect comparison, as we lose a bit of the deterministic element, but it’s still in the rough ballpark of the discussion.)
Theory of Constraints provides us some guidance here. In ToC we would identify the bottlenecked resources, such as the crews, and then ensure that the deterministic scheduling approach creates a backlog of work in front of them. In other words, the bottlenecked resources are always used.
Schedule Challenges
First, let’s look at how to approach this via scheduling. The basic gist is that the deterministic schedule only predicts an early readiness date for the construction crew to start their work and then identifies a window within which they will perform the work. The length of that window is then defined by the anticipated volatility and workload of the crew schedule. (Which would mean that the more work they have — or the more variables that would be expected, say, during a season where weather disruptions are to be expected — would mean we would want to lengthen that estimated window.)
As the readiness date approaches, the deterministic schedule dates may be adjusted based on real-time field conditions. At a defined milestone, the readiness status is handed off to the construction team, who then slots the work into the schedule for the next planning period, i.e. two weeks or one month.
This means a few things:
- We need to treat the construction date within our deterministic schedule as a target, but not a specific date on which work will be done.
- We need to identify a triggering task or condition prior to that date that indicates the work is ready to be scheduled within the construction scheduling queue.
- We need to have a separate scheduling queue for the constrained resource, such as a process to define when work is ready to enter the queue and how that queue interacts with the overall logic of the deterministic scheduling model.
- We need a way of assessing readiness for the work to be put into the construction scheduling queue. If the work isn’t ready, we don’t want to waste everyone’s time scheduling construction.
Communication Challenges
From a communication perspective, we need to ensure that the systems or groups communicate specific data between themselves. Using the model above, that would look something like this. (And feel free to substitute any relevant constituency for “Crew” in this picture: IT testing resources, drilling rigs, etc.)
The key here is to recognize the respective value that both perspectives have on the fundamental problem — that we’re attempting to solve an equation for both speed and efficiency. Therefore, we need to build a system that includes people, process and technology and that can solve — and reconcile — for both.
A version of this article originally appeared on Andrew Lavinksy’s blog, Project Epistemology.
Image courtesy of Rude Health via a Creative Commons ShareAlike 2.0 Generic (CC BY-SA 2.0) license.
