Tuesday, March 25, 2008

Progressive Refinement of Estimates (aka The Transmission Repair)

Bookmark and Share

Not too long ago, I had to have the transmission in my vehicle rebuilt. While car troubles are never a pleasant experience, this one created an experience that I think we can apply to many of our software development initiatives. You see, when I walked in to my friendly neighborhood repair shop, I was a bit anxious and really "needed" to know right there on the spot what was wrong with my car and how much it would cost to get it fixed. Oh, and when I would get it back. As you can imagine, it didn't quite play out that way. You see, the transmission guy, being the experienced professional that he is, knew he wasn't in a position to reliably answer those questions - yet. But he also knew how to work with me through a series of activities that would progressively refine our collective awareness of the answers - and ultimately be mutually beneficial. Here's how the story played out.

The Transmission Repair Story

Day 1 - 10AM - The Contact
Transmission's been slipping for a few days, so I head up to see "Ray" the transmission doctor. Walked in the front door and was greeted cheerfully. Explained the symptoms to Ray and asked the obvious questions: 1) What's wrong?, 2) How much will it cost?, and 3) When will it be done? Of course, Ray's been through this with hundreds of customers, and he knows he's not in a position to answer those "ever-so-important" questions. But he knows just what to do, so he explains how the process will work - and how it will meet my needs and get my car back on the road in a jiffy. Ray tells me the next step is to allow him to do a road inspection. He'll drive the car and observe the behavior himself. He'll even do some investigation with the car up on the rack in his shop. He says once he's completed that assessment, he'll give me a call and let me know where we stand.

At my prompting, he lets me know that the trouble could be something simple like contaminated fluid or mechanical adjustments, or it could be a more complicated problem requiring more extensive repair. On the lower end, Ray says it might cost as little as a few hundred dollars. He cautiously points out, however, that major repairs can be well over two thousand.

I anxiously awaited his call.

Day 1 - 3PM - The Engagement
At about 3 that afternoon, Ray calls to give me the update. It's a little bit of bad news, as the early indication is that there is indeed damage in the transmission, and it will need to be repaired. Ray gives me a bit of confidence by explaining what he observed and what that might mean. He is able to correlate his observations to many past experiences and makes me feel good that I'm on a path that many have successfully gone down before. According to Ray, repairs are going to cost between $1100 and $1800, and the correlation to previous work makes me feel confident with this range.

Ray goes on to explain that the next step is for him to get the transmission off the vehicle and onto the bench so he can open it up and look inside. Once on the inside, he'll be able to determine more clearly which parts need to be replaced and what work needs to be done. With that new information, he'll be in a position to give me a more reliable estimate.

Ray says that it's a lot of work to pull the transmission out to take it apart and do the detailed diagnosis. For this work, there will be a charge of $600. If I choose to follow through with the repair, that charge is simply part of the $1100-$1800 estimate. However, after Ray does the diagnosis and comes up with the updated price, if I choose not to proceed with the work (because, for example, cousin Charlie says he'll do it for a couple six-packs), then I'll owe Ray the $600 for his work.

While I'm not too crazy about this idea (it limits my options and makes me commit), I really can't argue against it. It only seems fair. I give the go ahead, and Ray promises to call me with an update within 48 hours.

Day 3 - 11AM - The Commitment
A little less than two days later, Ray has completed the detailed assessment and calls with the news. Along with several other parts, Ray will need to replace the governor pressure solenoid, the servo piston, and the boost valve. I have no idea what any of those things do, but Ray offers to explain in as much detail as I'd like. He wants me to be comfortable and confident in the estimate. With these new parts, his labor, and a couple pieces he has to send out to the machine shop for reconditioning, the revised total estimate is $1700 - $1850 and I can have the car back within 3 days. I give Ray the authorization, and he gets to work.

Day 4 - 2PM - The Change Request
Ray called to tell me he was making good progress on the transmission. It'll be ready for me to pick up tomorrow. That's good news!

He also wanted to let me know about something he'd learned during the repair. Once he had the transmission all apart and cleaned, he noticed that the #4 gear had some pitting on the inner surface of the teeth. He explains that this isn't something that will cause trouble any time soon, but he wanted to present me with the option of taking care of it now while everything is already out on the bench, potentially avoiding a second, more expensive repair at a later date. The part would cost an extra $75 plus $50 for labor. If I opt for the additional work, my revised total grows to $1825 - $1975.

After careful consideration, I decline the additional repair.

Day 5 - 4PM - The Delivery
The car's ready. The total came to $1797, and I can pick it up anytime before 6.

The Lesson

Before getting into the lessons learned in this experience, it might be a good idea to review Ray's process:

1. The Contact - Customer explains the trouble. Ray agrees to spend a couple hours investigating. This investigation will result in an understanding of scope and constraints and provide both Ray and the customer the information they need to make decisions about how to move forward.

2. The Engagement - Ray explains the results of the initial investigation and provides options. Customer agrees to a minimal investment to conduct the more in-depth assessment that will include removing and disassembling the transmission in order to generate a detailed work plan.

3. The Commitment - Ray explains what he learned during the in-depth assessment and provides a reliable estimate for the repair along with details about when he can deliver. Customer agrees to the terms of Ray's plan.

4. The Delivery - Ray completes the work and delivers on-time and on-budget. Customer is satisfied.

It seems Ray has this process nailed down. He avoided making a commitment (or asking me to) before there was a reasonable level of understanding of the work that would be required, and he walked me through each step of the process right up to the final successful delivery. While there were steps in that process that I really wish could have worked differently, I knew I had to be reasonable. For example, in that first interaction ("The Contact"), it wouldn't have done a bit of good for me to pitch a fit and throw a temper tantrum in an attempt to get Ray to cave and tell me exactly what was wrong and what it would cost. Likewise, Ray knew it would be just as unreasonable to avoid giving me a cost estimate as early in the process as possible. If he couldn't (or wouldn't) give me an estimate (even a wide range) at "The Engagement" stage, I surely wouldn't enter into the arrangement, and I'd have to take my business elsewhere. Throughout the process, we agreed to collaboratively work through a series of well-specified milestones. Each step resulted in the addition of new information and yielded an increasing ability for each of us to understand what we were getting ourselves into - and what we could each expect to receive in return.

Applying the Lesson

Let's be encouraged to apply the same reasonable and responsible sort of process to software delivery. Our customers can understand why precise estimates are not possible when there is little or no data, and we can understand that it is absolutely essential that we provide estimates that can be used for coarse-grained business planning as early as possible. All too often, this devolves into an emotional tug-of-war where nobody wins.

We all come out ahead when we design processes like Ray's and work collaboratively to step through a progression of estimates that become more and more reliable as a project unfolds and new data becomes available.

One last thing. You may be interested in comparing Ray's process to the Rational Unified Process, in which you'll immediately be able to draw simple parallels:

"The Engagement" = The Life Cycle Objective Milestone (LCO)
"The Commitment" = The Life Cycle Architecture Milestone (LCA)
"The Delivery" = The Initial Operational Capability Milestone (IOC)

These milestones give us a good framework for the reasonable and responsible collaboration that makes Ray's process a success.


Christy ~ Central Air said...

Brian, what a brilliant illustration. Loved it! Sorry to hear about your car troubles, though.

Firebrand Architect® said...

Excellent analogy - great bridge to set expectations between technical and non-technical stakeholders.

Brian Sondergaard said...

Glad you guys found this useful. It's proved to be very helpful to translate concepts like these (e.g., estimation) into real world personal experiences that more people can relate to.



Sundeep said...

Hi Brian,

Excellent article and analogy. But you sound like THE "reasonable" customer of my Dreams! Here is how it works with some tougher customers.

The CONTACT – Customer comes up with business requirements requiring a software solution. I explain how a typical SDLC works and offer to scope out the requirements. Customer insists on a ballpark in order to even begin scope, citing budget constraints (a.k.a reluctance to commit to $600). I provide a ballpark based on my best judgement & experience even as political pressure is also added to the request (a.k.a come on! you can do the entire thing for a couple of six-packs, can't you?).

The ENGAGEMENT – Customer agrees to scope effort after receiving the ballpark. Despite written disclaimers about the ballpark, the customer has mentally converted ballpark into hard estimate. I perform the scope and come up with a detailed estimate. It turns out that the requirements include significant and unanticipated work. Estimate is close to or just over the max range of the ballpark eating up practically all of the contingency built into the ballpark. Customer points out that work was approved based on estimate. I point out that I provided a ballpark. Customer wins argument since customer is always right. And we go into project execution with zero contingency. And what if something else comes up? (a.k.a in financial software a bad #4 gear is usually NOT an ok to have situation). More tough negotiations, of course!

The key to this deadlock and perhaps the real challenge is for the customer to agree to commit to the initial investment in scope. However with the current economic situation in the US, the year 2009 will probably be more of the same.

Anonymous said...

Interestingly one of the key things that I note in Ray's method is his use of estimating in ranges. Since few project management tools accept ranges as estimates I think that this leads to a lot of the problems that @Sandeep is noting.

When you give an estimate as a range you get several benefits:

1) It is hard to mistake it for a commitment or promise.
Saying $200 - $2000 as Ray did at the first contact gives you much more information about how the project is likely to proceed.

2) The estimate's uncertainty can be narrowed over time by doing work.
Ray did this and made it clear that you would be charged for the effort required to do the investigation.

3) It helps move the discussion from an adversarial negotiation to a cooperative investigation of possibilities
You could have tried to browbeat Ray, but he could have rightfully said, "I just don't know yet." This would have been a reasonable and understandable response that is really hard to argue with.

Both I and my CEO have written a bit about this same thing on our company blog, both about estimating in realistic ranges and how accounting for project uncertainty is not the same as risk buffer.

The idea of "progressive refinement" is key to delivering both reliably and with high quality. Without the ability to refine your estimates as you learn more about what the scope and difficulty of the work is you can quickly find yourself backed into an unobtainable schedule.

Anonymous said...

And as it to understand