5. My Favorite Analogy

Finally, this is my favorite analogy for helping people grant us permission to have sliding estimates. If you went to a mechanic and said "my car has a rattle. I want you to fix it, but first tell me how much it will cost." What would the mechanic say to this? Probably "Let me take a look at it and I'll give you an ESTIMATE." Interesting. 1. They get to look at it. 2. And at the end all we get is an estimate! Huh. And we say what? "OK."

Now software projects are FAR more complex than car repairs. Yet our teams don't get the same level of courtesy? If we forced the mechanic to give us an estimate (and he didn't just throw us out) he might say "other cars with similar rattles have cost somewhere between x and y, but I just won't know till I get a closer look." So, "Let me take a look at it and I will give you an estimate" is the same as Inception. "And at the end I'll give you an ESTIMATE." NOT "THE EXACT NUMBER ON MY WORD OF HONOR PLEASE VIVISECT ME IF I AM WRONG." Yet somehow we think it means this on a software project. Somehow the definition of "estimate" seems to have changed on us... "Let me take a look at it and I'll give you an estimate." is Inception. And you let all team roles look at it in their own special way, from analysts to testers.

Ok, so while we tremble at the thought of saying this in software, we agree to it for our car. We say "ok." Then what happens? A few hours later our phone rings. "Well, now that we have this thing taken apart, we can see a few other problems in here. Some you really should let us fix now. Others could wait, but would cost you more later 'cause we'd have to take her apart again, which will cost you. What do you think?" So the estimate sometimes changes. And what do we say? "Ok. Go ahead I guess." (note: some of you auto-savy folks may handle this differently, but the rest of us are a little more clueless and so we say
ok.)

That was Elaboration. Once we get our hands into the guts of a project, sometimes we find things out that you could never know till you got inside. Then you re-estimate based on this new knowledge plus the proven capability of the team.

So why do we accept this about cars, but not about software projects? Why do we say "ok" every time the mechanic says these things? Because we deeply understand the VALUE of our car. Sometimes we say "you know what? Forget it." One time I said "How about you just keep the car and we'll call it even on the labor to date?" Then we get a new car. Remember the 80/20 rule above. It only works if the VALUE of the project is well known to both sides. Customers will never go for re-estimates and will never participate in scoping until we PROVE we know the value of what is being built. Again, "Let's Get Real" will help you here, or take our Mastering Requirements Management with Use Cases class. Or both.