Why Introducing Schedule Optimization is a Bad Idea – At Least Day 1


In today’s field service software market, a key element of all software vendor offerings is a capability known as schedule optimization. All field service software vendors tout the benefits of optimization including reduced travel time, improved utilization, fewer needed resources in the back office and field, improved customer satisfaction, shorter appointment windows, etc., etc. While these benefits are real and achievable, most software vendors today do not recommend the best approach for achieving those alternatives. Since most vendors tie a significant amount of the ROI associated with their proposed business case for a prospect to the benefits of schedule optimization, they are reluctant to suggest alternative approaches. This inherent conflict leads to an over emphasis on the importance of schedule optimization at the expense of establishing sound work order management business practices. Positioning schedule optimization as a mandatory component of an initial project phase often leads to frustration within the service organization especially when the initial attempts at deployment struggle to realize the value promised.

Make no mistake, scheduling optimization’s value is real, important, and can offer competitive advantages to those service organizations that choose to deploy its capability. However, introducing its capability into the service organization should be carefully managed so that you maximize your likelihood of a successful service management system deployment. This paper will examine why including schedule optimization during the initial phase of a field service software deployment unnecessarily increases your risk and will provide a pragmatic approach for service organizations to consider.

Introduction – Optimization is Complex

Let’s face it; optimizing field service personnel’s schedules is a challenging problem. There are dozens of factors that must be considered when selecting the “optimal” resource. Factors such as travel time, labor costs, skill set, customer preference, job duration, inventory availability, service level agreement (SLA) compliance, job priority, appointment windows, and many others must be considered. There is no doubt that it would appear on the surface that automating this decision set as quickly as possible makes good business sense. That approach however, fails to consider the potentially disastrous outcome that introducing scheduling optimization in the early stages of a field service automation project – namely project failure.

Over my career, I’ve had the opportunity to personally observe dozens of optimization implementations from a variety of software vendors. I’ve seen some exceptional implementations and some utter failures. Throughout the years, there are several observations about why optimization implementations succeed and three key factors that contribute to their failure when done in conjunction with an initial introduction of a service management system. The key factors that contribute to optimization project failures are: a) missing the opportunity to revamp inefficient operational business processes, b) overlooking the perceived threats to the jobs of the service staff, and c) minimizing the need to establish a solid foundation of trust in the system upon which future capabilities can be layered. Introducing schedule optimization capabilities without carefully considering these key factors, in my opinion, significantly and unnecessarily increases project risks.

Why is Introducing Optimization Day 1 a Bad Idea?

Focus on What’s Important – Optimizing Your Operational Processes

Any consultant in any industry worth his or her salt will agree that simply making sub-optimal business processes run faster by introducing automation will not yield any benefit. In the case of field service, poorly conceived or broken service processes directly impact the end customer and result in a service experience that misses the customer expectations. Increasing the velocity of sub-optimal processes will only serve to increase the rate at which you miss customer expectations, obviously not a desired business objective. No optimization engine in the world is going to improve broken business processes, that simply isn’t its’ objective. It is imperative therefore that any deployment of field service software be done hand-in-hand with process review and re-engineering.

By choosing to include schedule optimization in the first phase of a project, service organizations will dilute the effort from process re-engineering. Properly implemented schedule optimization requires careful thought, intense focus and a deep understanding of the business. As a result, service organizations typically assign their most experienced and talented analysts to scheduling optimization. Unfortunately it is these same resources that should lead process re-engineering discussions. Since scheduling optimization providers command very high implementation rates for their assistance, the service organization naturally feels compelled to ensure that work is prioritized. This therefore commands a greater time allocation for the experienced resources, at the detriment of process re-engineering.

Carefully examining and re-engineering service business processes will undoubtedly result in operational changes within the service organization. Automating these process changes should be the focus of any initial service software deployment as they will, when properly done, result in the maximum return for the organization. Establishing optimal operational business processes must be the focus.

Psychology of Change

Despite my numerous observations, there no doubt will be service organizations that insist on trying to tackle process re-engineering and schedule optimization implementation when doing their initial deployment of a service management system. These organizations need to therefore realize that it is the very process changes themselves – no matter how small – that become the seeds of doubt for schedule optimization initiatives. Why you ask? Crack open your nearest psychology text book and lets’ look at the behavior of change.

Change is a complex psychological process and was outlined by Frederick Perl’s Change Theory. This theory, in its’ simplest form, states that human beings will support change when they feel included in the change process and are not threatened by the end result. The last element of this theory is critical when it comes to managing change as part of a field service software deployment. Since the well documented basis for schedule optimization is a reduction in dispatchers, field personnel, supervisors or all of above, it is only natural for the service operations staff to feel threatened and therefore to resist this element of the project.

In virtually every service organization I’ve been associated with, the statement “I know my customers and what they need” has been uttered by a service coordinator or dispatcher. When it comes to schedule optimization, the belief is no different. There is an inherent belief within the coordinator or dispatcher community that no software package, no matter how sophisticated, can really understand the “likes and dislikes” and “nuances” of customers they serve and thus replace what I do. As a result, threatening the coordinator or dispatchers value to the organization, no matter how well intended, becomes a source of resistance.

The question that you need to ask yourself, therefore, is “is introducing scheduling optimization on day 1 worth the potential risks to disruption of service quality to my customers or overall failure of the project?” Our experience indicates that it is not worth the risks, as we’ve seen both outcomes. An undertaking to implement a new service management system in an organization that is poorly automated or requires the overhaul of existing processes will result in tremendous change within the organization. The focus of everyone in the organization therefore, should be on getting those processes established, without concerns for their future security. As a result, management’s job is to ensure the staff does not feel threatened while embarking on this critical organizational change.

A Foundation of Trust

Aside from aligning skills, parts, appointments, etc., one of the outputs of schedule optimization packages are optimized routes such as the one shown below. This route shows the various stops for a field resource during his/her/their day and is the most “visual” output of a schedule optimization engine. In practice, dispatchers often view the individual routes of field staff and as a result see only a slice of the results produced by an optimization engine. The issue is that, no matter how sophisticated the optimization program is, it will always produce a few routes which do not appear visually optimal. This in turn leads to questions such as “why is technician X traveling all over the place” or “why doesn’t engineer Y have any work” or “why did the system send crew Z from point A to B, that’s not how I would have done it”. The problem with each of these questions is that they are viewing the micro result of an optimization, not the overall result of optimization across the entire technician pool. Ok so you say, so why not just show the data across the entire technician pool to “prove” that optimization is working? Again, we need to look at the psychology of what is really being asked to understand why it isn’t really that simple.

With this approach, you are asking someone who doesn’t trust the output of the system (remember the entire system is new and the most visual output presented to a dispatcher is being questioned) on a “micro” level data (individual technician route) to ignore this mistrust and believe that the “macro” level data (all routes across all field staff) is accurate. The fundamental flaw in this thinking is that you haven’t allowed the new system to ‘earn’ the trust of the staff using it.

Any deployment of field service software introduces change to the organization, even if no business processes are improved. Paper processes are being replaced by electronic ones (hopefully re-engineered ones where needed), home-grown data repositories that are “trusted” are being consolidated into new central repositories and mobile technologies are being introduced or radically expanded. All of these changes, not including adding optimization, will severely rattle the foundation upon which the service organization was built. It is imperative therefore to as quickly as possible stabilize that foundation. In doing so, you establish a level of trust associated with the “new way” so that customer service is positioned to improve with the use of the new system. Until you’ve established trust in the new system, why then, shake the foundation and introduce schedule optimization that requires you to prove to your staff that it is working at the same time? It doesn’t make sense and isn’t a pragmatic approach to realizing the true potential schedule optimization can offer an organization.


Lets’ be clear, scheduling optimization is powerful technology and can provide real benefit to service organizations. Its introduction however, must be carefully managed in order to reap those benefits and not adversely impact the service organization. For organizations contemplating an optimization engine for their business, Jolt Consulting Group strongly recommends the development of a strategic technology roadmap as a first step. Development of a technology roadmap should begin with an assessment of existing capabilities that is matched against the organizations strategic business objectives. The outcome is an action plan that can be jointly followed by service operations and IT.

Jolt Consulting Group believes that the development of the strategic technology roadmap should begin with an assessment of existing work order management capabilities. We believe a work order management system is foundational and should include the ability to manually schedule and wirelessly dispatch work orders. In our experience, organizations that are contemplating optimization technology often do not have these foundational capabilities in place and are planning to introduce them together with optimization. For the reasons outlined earlier in this paper, we believe that is a mistake. The focus of the organization should be on establishing a solid foundation – one that is based on sound business processes and a technology platform that is trusted by the organization. This will serve as a platform for introducing future capabilities, such as scheduling optimization as well as others. It will also provide an inherent trust in the new systems ability to support the needs of the business as more complex capabilities are introduced.

We recognize the value and importance of scheduling optimization. However, without proper planning and careful introduction, the intended results will not be achieved. In addition, organizations who attempt to introduce the capability too early risk damaging customer loyalty. In my experience, the most successful service projects recognize the need to stabilize their foundation before adding additional layers of capability. In other words, learn to walk before you run. Jolt Consulting Group therefore believes that organizations should focus on establishing a strong foundation and only then introduce schedule optimization.

Fill out my online form.