Igniting Initial Optimization Program Adoption

Thursday, August 12, 2021

Once you have a working optimization prototype program that has been tested and embraced by one or more users under field conditions, it is time to roll out the program to the organization and be sure that the right people are using it daily. Because the best optimization opportunities address decisions that are made repeatedly across the organization, scaling up often means motivating and training a large group of dispersed people.

At Marriott, for example, it meant introducing the program to thousands of sales managers who were making group reservations in hundreds of hotels. For Bill Boga at UPS, it meant spending a year on the road, giving weeklong workshops to introduce the software used in the Feeder Scheduling Optimization System (Feeder SOS) in more than 65 UPS districts. Getting software to make smart decisions can be a challenging task; getting large groups of people to use software correctly can be just as challenging, if not more so.

The first major challenge in scaling-up is igniting initial program adoption. Begin at a point that maximizes your chances of success and expand from there. At Marriott, it was a select set of hotels that had computer systems that produced the data needed to fuel the Group Pricing Optimizer (GPO). At UPS, when Bill Boga set out to expand the use of the feeder-scheduling software, he initiated the project in Chicago because the district had called and invited him to visit. In each case, the first introduction was characterized by a timely intervention in a situation where minimum resistance was expected.

Typically, the introduction of the software requires significant education, which may include topics beyond merely how the software works. Managing change is one such topic, especially for an organization’s leaders. At Marriott, Sharon Hormby understood the importance of equipping leaders with a framework and skills to drive and support change. She knew that the GPO was going to require significant changes in how sales managers did their job.

To meet the challenges, the team decided to begin rolling out the system by immersing the company’s leaders—hotel managers, regional directors of revenue management, and regional sales directors—in a two- to three-day training program, rather than by training the sales managers who were going to be the actual users of the software. In each region, Hormby invited the sales leaders to be involved in delivering the training. “This was really big,” she reports, “… because these were the top sales leaders, who got the big bonuses each year. There they were, up on the stage with us. With them on board, it made it a lot harder for others to resist.”

The training was designed to immerse the leaders in the software so they could understand—and support—what the sales teams would be doing. But software was not the first agenda item. Hormby and her team had developed a half-day workshop on change management principles. Change, after all, was what the company’s leaders had to think about and focus on. The message to them was clear: introduction of the software represented a significant change and needed to be managed accordingly. Once the company’s leaders were on board, Hormby and her team turned to training the salespeople.

UPS’s Boga also knew that that he was going to face resistance when he and his team introduced the Feeder SOS, even though top management had issued a mandate stating that every district must use the software. Mandate notwithstanding, Boga would be hard pressed to convince seasoned UPS schedulers, many of whom had started their career driving trucks, that the software could schedule the routes more effectively than they could. He did not expect many easy converts.

An additional challenge that Boga faced was the quality of the data that the scheduling program needed from each district. They were chock-full of errors. A great deal of work was going to be needed to clean up and correct each district’s data before the routing program could generate good solutions. The “junk-in, junk-out” state of affairs created a perfect opportunity for new users of the software to dismiss its recommendations and stop using the program.

To address the problem, Boga structured a weeklong workshop that he eventually led in all the UPS regions. At each stop, Boga asked the district schedulers to bring real data with them and to be prepared for a challenging working session. At the beginning of each workshop, Boga introduced the software and then instructed participants to use their own data to generate solutions. This included teaching participants how to clean and tweak their data to improve the solutions they were generating. The night before the final day of the workshop, Boga reviewed every set of schedules generated during the week and put together a spreadsheet that displayed each participant’s solutions, including what the software suggested were the minimum and maximum cost savings that could be achieved.

In the final session, Boga reviewed every district’s data on an overhead screen, asking whether the district scheduler thought the new computer-generated schedule was workable. If the answer was yes, Boga responded, “Great! When will you be able to implement it?” If a scheduler answered no, Boga asked for an explanation. If the scheduler continued to resist, Boga suggested that the reason the solution wasn’t correct was because the scheduler’s data were in poor shape and needed to be cleaned up. Boga let the scheduler know that they would be meeting after the cleaning had been done. This would put the onus on the scheduler, not the software system.

In thinking about such educational activities, keep in mind the many reasons that people resist turning their decisions over to a computer. Beyond job security, there are issues of self-esteem, role definition, self-interest, and a common need by almost all of us to maintain control over our environment.

Remember, also, that the people being introduced to the software during this phase of a project typically have not been involved in its development or testing. Low involvement often leads to low commitment. During the rollout, project teams must be wary of the dreaded “kiss of yes”: employees who say yes but mean no and continue doing exactly what they have always done.

This post is excerpted from The Optimization Edge: Reinventing Decision Making to Maximize All Your Company's Assets (McGraw Hill) by Steve Sashihara, www.optimizationedge.com.