Are your software implementation efforts woefully behind? Are your development schedules constantly being compromised by increased demands from other business units? Is the final product so “buggy” your customer is now calling you instead of your project managers? How long can you juggle the constraints of too few resources, too many demands and too little time?
In this article, we will not try and solve all the world’s execution problems but we will look at how some teams are using what I call the Jiffy Lube model of collaboration to meet the concerns of low quality, reduced business value and suffering customer satisfaction. The premise is that focused, well-integrated teams will outperform (from beginning to end) a loose confederation of individuals doing the same task. And, to test that point we’ll apply the model to the high-level processes of a software implementation client’s situation. The final supposition, however, is that the executive’s role must be to continually focus on collaboration instead of achieving a level of high personal acclamation (and that may be too much to ask).
I discovered the Jiffy Lube metaphor while working with a client on a software implementation initiative. They had a great enterprise product which enabled customers an opportunity to better manage human resource benefits more effectively and efficiently. In many situations, my client was willing to make alterations to the product so they could meet the customer’s needs and make the sale more quickly. In addition, the process of configuring the customer’s data sometimes required manual oversight by two experienced technicians: one on the customer’s side and the other on the client’s side. To make things more interesting, the sales people were selling the product with features that were not yet fully developed (planned, but not developed or fully tested). In other words, if the customer asked for a new feature during the sales or implementation phases, they would typically be accommodated. The bottom line was my client had way too many customers in the “queue” versus in full operating mode and they were losing lots of money.
As we began to tackle this problem, I asked my client for a series of “as-is” design workshops, in which members from all the functional areas of sales, development, testing, project management, and client services gathered to define the possible areas for improvement. During one especially heated conversation, one of the more quiet engineers said: “what we have here is a bunch of people individually changing oil on a multitude of cars, never quite finishing the job before moving on to the next, instead of a Jiffy Lube model where teams of people work on each car to complete all of the work.” Unfortunately, one of the more opinionated PM’s diverted everyone’s attention (including mine) by reminding us we had a job to do so let’s get on with it.
Luckily, I went back at the end of the day to the insightful engineer and asked him to be more specific. Here’s what he said:
Right now, we allow our sales people to sell almost any promise they think is required to close a deal with no input from those of us who have to fulfill those fantasies. On top of that our project teams and client service reps intentionally make every customer feel like they are the only one’s we have, which is great for the customer. But each team might be servicing multiple clients at any given time with the same intent of doing everything right now. Then, when the proverbial [stuff] hits the fan everyone looks to the development team to quickly deliver the promised functionality and fix the “bug” problems discovered by the client.
I personally think we would be much better off if we created a “to-be” model in which the sales people assured their promises actually could be met before suggesting them, that each client was treated as if they were in the “queue” and that we, and I mean everyone involved in the implementation process, i.e., the development group, the client service reps, and those of us in development actually acted as a team to assure the implementation experience meets the client’s expectations.
This whole concept came to me when I was sitting in line at my local Jiffy Lube, waiting to get service. Instead of acting like a bunch of independent service agents working on all the cars in line at the same time, which would require lots of time on the part of the service provider and customer, they took us one at a time, contracted for appropriate mechanical services (e.g., they don’t do major engine overhauls for instance), estimated the time it would take, and then went about working on each car as it came next in line. When they get a car onto the rack, the internal teams move between a maximum of three cars at any one time, helping each other where needed. The flow was consistent, predictable and the results were a quality oil change.
While I know what we need to do is a bit more complicated than that, I don’t think it’s much more so.
After hearing his story I thanked him and went immediately to the Executive Sponsor’s office to talk through the implications. It became clear this metaphor could work, but it would take someone high enough in the organization to provide the team with the needed assurance it would take for them to try this more collaborative approach. She readily agreed and even rescheduled her calendar to attend our “to-be” model design workshop the next day.
During the workshop, the team was a bit reluctant to embrace the metaphor because of their concern about cross-functional cooperation. The Executive Sponsor assured them, that if everyone in the room agreed to a more cooperative and collaborative model for implementation, she would take the proposal to her peers for validation and if appropriate be the champion for this new approach. With that assurance the team built their version of the Jiffy Lube model. The sales folks discovered that if they worked well with the rest of the implementation team, they could gain additional “good” references for future client calls. Likewise, the development team found that they could more easily meet new feature requests if they could plan them out in advance, and the project teams and the client service reps were pleased to know the “bugginess” of the code would probably reduce significantly if projects were taken on more incrementally. Basically, everyone found significant reasons to be excited about this approach to a more continuous process flow.
At the end of the meeting we recorded these key working agreements to help the team go forward:
- One Executive Sponsor over a set of project teams
- Development experts assigned to the Executive Sponsor instead of to a specific team
- Project Team leads held daily status meetings with their teams (both internally and externally) and a Project Team coordination meeting each week with the leads from all teams discussing emerging issues and successes.
- Sales engaged both the Developers and Project Team leads before finalizing a new contract;
- Bi-weekly debrief sessions were held to assure the implementation was on schedule, the proposed plan of work for the next two weeks was appropriate, and record major lessons learned during the iteration.
Three months later, the Executive Sponsor called a meeting of all those who had participated in the “to-be” model generation and others who had become interested in their ongoing success. While everything was moving along smoothly, customers were happier with their implementation experience, and the sales team was still engaged, some other organizational challenges were starting to emerge. Specifically, the project teams that did not report to this Executive were still enmeshed in the old way of doing things and on occasion were trying to “steal” people over to their side to complete critical projects. As she said, “this is a critical juncture in our experiment. If we give in to their requests we will reduce our own efficiency, but if we don’t help, we’ll be looked upon as non-team players. And frankly, I’m at a loss about what to do. Does anyone have an idea?”
A funny thing happened, the boisterous project manager who had taken us off this conversation in the first meeting looked at the shy engineer and said “I think you should try our Jiffy Lube model at your level and see what happens – it sounds like your lane in the building is moving along well while other lanes are still trying to change their oil out in the parking lot, all at the same time.” Everyone laughed of course, but the Executive Sponsor thanked her and then led a quick brainstorming discussion about who probably should be involved in that type of discussion.
Our ES then went on to host the high-level conversation but unfortunately, the other executives were not interested in participating and came up with all sorts of excuses why the status quo was sufficient for them. The sad news is that after a year of great success with her teams, but miserable success in extending it further into the organization she left for greener pastures, her teams had to revert back to the old way of “changing oil” and their customers became less satisfied.
The point to this story is that while the Jiffy Lube concept or metaphor for continuous flow is not complicated nor is it very hard to implement, except in terms of coordinating people’s behaviors and motivations, it does require a level of executive involvement and participation. In the end, real change requires organizational support be in place to sustain it.
[Note: the details of this case were consolidated from three client experiences.]
