Have you ever wondered how UPS can deliver over 19 million packages a day and delivers 99% of them on-time? UPS’s mastery of the repeatable, measurable and ultimately managed “process” is directly responsible for this day-in, day-out, year after year consistent performance. And, if you have ever asked UPS to do something “special”, you will understand that their process is resolute and immutable, i.e. they won’t do you a favor. If they weren’t uncompromising about their process, they wouldn’t be able to move that many packages with that kind of on-time record.
There have been several times during my career when a company I was working for was unhappy about the reliability or quality of the services they were providing/receiving. Management was unhappy with the lack of reliability because it directly translated into lower customer satisfaction and that is always a bad thing. In each of these cases, I invested much time and energy into changing both the organization and processes so that the outcomes would consistently meet the expectations of the people consuming the services in question.
The first time I was involved in this was a PW where I was a member of the information technology practice practice. We were in business to implement commercial off the shelf software, develop custom software or a combination of both. Independent of which alternative was chosen, the goal was to strengthen our clients’ ability to operate more effectively and efficiently.
Our organization was growing quickly and we needed to make sure that the teams (no matter where in the world they were delivering services) would result in work product that was of consistent high quality. So, our management pulled together a team, of which I was a member, to improve our ability to consistently deliver the highest quality work-products. We felt that refinements and enhancements to our system integration methodology (the process by which we implemented software solutions) would improve the success rate of our implementations. There were several characteristics of this methodology that are common to all the other process improvement implementations I was involved in:
- They depend on a rigorous definition of the steps necessary to do the job—a detailed checklist that includes all the steps necessary to properly complete the work defined by the methodology;
- The organization must buy-in to the methodology and agree to implement it conscientiously. This requires a mix of education, change management (the culture must be accepting of a change in “how things are done”) and leadership;
- Metrics which indicate the degree of success or failure of the process to deliver the expected results must be developed, measurements must be gathered and the degree to which the process produced the desired results must be determined;
- There needs to be a feedback loop which is designed to incorporate field experience (results from the previous bullet point) and therefore improve the process;
- And, in some cases, the methodology is designed to deal with the worst-case situation. In PW’s implementation that meant addressing the most complicated system integration projects. Given a methodology capable of dealing with the most complex situations, it is the task of the project manager to understand which steps are and are not necessary in a particular implementation and scale back the process to be appropriate to the scale of work being performed—i.e. not all of the implementations require the full set of steps that might be required for the worst case.
A small team, led by Kerry Horan, systematically worked through the definition and subsequent implementation of multiple revisions to the methodology. The widespread maturation and adoption of the methodology within PW’s consulting practice was a key factor in our ability to continue the rapid growth of our business while simultaneously improving the work product and client satisfaction.
We were able to ensure that work performed by teams around the world would deliver work-product of consistent quality. This was important, because it empowered PW to effectively and efficiently implement solutions globally, relying on local teams to be able to deliver the work-product that functioned in an integrated and consistent manner whether it was delivered in Detroit or Dusseldorf.
In another situation, the business (in this case Mayer Brown for whom I was the CIO) was not happy with the reliability of key systems that supported client service delivery. The thought was that these systems had to be up non-stop. This was perceived to be important, because the lawyers felt that anything less than that would put them in jeopardy of not being able (at a critical point in a negotiation or litigation) properly service their clients.
The IT staff was literally running themselves ragged trying to keep the systems running—and they were not meeting their goal, not even coming close. I was pretty sure that non-stop computing was not really what we needed, and it would have been prohibitively expensive. But, I understood the basic desire and that the current strategy for providing the needed reliability was not viable and would never satisfy our management.
My first task was to identify what had to change before we were going to be able to (significantly and sustainably) improve the reliability of the systems that supported the business. The list was short:
- Culture—the people had the right attitude, but were not believers in process. They were convinced that if they worked had enough, that they would be able to prevail. This was the hard one. There were employees who were just not constitutionally oriented towards a process driven culture. They had to go;
- Process—we needed to identify the key processes that needed to be defined, documented and implemented. This took a great deal of effort and had to be done while both changing the culture and keeping the systems running;
- People—we needed to change the way people thought about their work. Their job changed from one of being the repository of knowledge and operator of the system to one of being a engineer whose job it is to make sure that the processes are manage performance and optimized to maximize reliability.
- Engineering—clearly the design and implementation of the technology and infrastructure bore some of the blame and large pieces of the infrastructure and configuration of software were reengineered as part of the changes to improve performance and reliability.
Those of you familiar with one of several flavors of quality management will surely recognize what happened in each of these examples. We implemented a regime that enforced managed, repeatable processes and then managed the heck out of them. And, just like the folks at UPS we were able to deliver reliable service that met our customers’ expectations.
In each of the cases sketched out above, we measured what we were doing and used the measurements (as part of a bigger feedback loop) to optimize the processes as part of a continuous improvement program. This is essential, whether you are delivering packages, developing/implementing software, delivering high availability software services to a global organization over a network.
In my next post, I will discuss the very real tension between a process orientation and a “customer service” orientation.
Copyright 2017 Howard Niden
— you can find this (days earlier) and other posts at www.niden.com