I have always disliked this particular metaphor; it's supposed to help you understand the basic fundamentals of problem solving. How do you eat an elephant? One piece at a time.
However. Who wants to eat an elephant? They're intelligent beings that are actually pretty damn nice to humans (one of the few species that will actually go out of their way to help a human occasionally). Aside from that, the purpose of the metaphor is to make you think of surmounting a huge problem, but in essence it generally makes me queasy because, say, I start eating the elephant at the front right leg...I fill up before I even reach his KNEE. I could consume the entire elephant in small bites, yes, but there's a good chance that by the time I reached his shoulder (assuming an elderly-already-going-to-die-senile-elephant-who-lived-a-good-life-but-with-a-degenerative-disease-that-killing-him-really-saved-him-a-lot-of-pain but which will not infect me, so I don't feel bad about eating him), the rest of him would have gone BAD. Note, this does not make it a horrible project management metaphor--I've had plenty of projects that were a lot like trying to eat a lot of dead rotting elephant. But its not really the best image to have when you're trying to remember something useful and positive.
I would rather eat cake. I'm more of a pie girl, really, but cake has its place. The metaphor works for cake, too, btw: if you ask most people how they eat cake, they do not say they put the entire cake in their mouths at once, struggling to breathe and swallow. They eat cake one piece at a time. I could, in fact, consume an entire cake this way, and, furthermore, would want to.
Cake and elephants aside, however, troubleshooting problems does require breaking them down into smaller pieces.
Here's an example: your group has a reorganization. It now fulfills different functions than it did before, with more people than you had before. Your boss wants to know how much to budget for this team for the next year. You can't grab last years estimates and tweak them to get the right numbers because they really don't apply. Well, you could, but it would be similar to the second option: make stuff up from your gut. There is a time and place for making stuff up based on gut feelings, but deciding budget for the rest of the year is really not one of those times. So, in this case, like the cake, you have to break the problem down into tastier bites and then calculate based on those.
So you look at the number of people and how easily they've done their previous jobs. You assign time per day for the average person (I'm a HUGE fan of booking six hours in a day rather than 8, because I cannot remember the last time I came to work and didn't need to use the bathroom, get something to drink, chat at the water cooler, attend regular meetings or put out multiple unexpected fires...all which eat at that 8 hour day). Then you look at how much of their time per various project you think it will take them to do.
Now, in a perfect world, you take your resulting numbers and consult those people. Frequently they will freak out. "How can I estimate how long it will take me to do something I won't start for another 2 months?" Pretty much, you have to wing it--with budgeting for an entire year, it's better to have some basis for your wild guessing than none at all; responding to your boss with "There are too many unknowns" will not get those unknowns defined for you--they'll get him to make up a number (however he does it) that you have no influence over. So calm the freaky person out, and ask them to eat the cake in small pieces (I would avoid suggesting he/she eat an elephant as I don't think it would help here).
Once you've assured god and country (and everyone on the team) that they will not be held at gunpoint to these numbers, take them to your boss and go over them. Bosses like to cut stuff off they don't understand. While that may reduce the total amount of elephant/cake you have to eat now, you'll be eating moldy cake/rotting elephant in a few months if that money isn't there and you couldn't justify it.
A lot of the time, your boss will tell you he needs those numbers for a meeting in X hours (where X is the amount of time you intended to go out with a friend to lunch, which you suddenly have to cancel). In this case, you can't run the numbers by your team. But you still have to eat the cake/elephant.
In this case, I recommend going through and giving your best guess for time estimates. Go with your gut, knowledge of the person, or, absent that, estimate of an average person learning that job doing it over time. Once you've got it where you think it ought to be, mark all estimates of time up by 20-25%. That should make up for not being able to vet your numbers with your team, but not be too huge an increase as to have your boss freak out (more so than he/she already is, anyway). Next, tell your boss--as you are handing over the numbers--that these are WAGs (Wild Ass Guesses) and not to hold you to them...then follow that up with an email that you can show him/her in a few months when your boss has forgotten his/her promise and wonders why you aren't keeping to "schedule."
So now we've eaten the cake/elephant. Budgeting is just one example where you're going to be asked, as a manager, to make decisions about how long things will take. Your teammates do like to go on vacation, will have sick days, and might want to go to training. All of these require estimates about their current projects--made by them and approved by you--to determine slips in schedule or the best time you can do without someone for a while.
The moral of the story? You will have to make WAGs and to do that and you'll need to break things down into manageable pieces. It's up to you if those pieces where once a pachyderm or of the frosted, baked-good variety. And now I kill this extremely overused metaphor (but don't eat it).
A very Happy Thanksgiving to those of you who celebrate it, and I hope Friday comes fast for those of you who do not.
Stuff an egg in a quail in a game hen in a duck in a chicken in a turkey in a sheep in a cow in the elephant and deep fry that sucker. With bacon. Put out advance notice that it’s going on YouTube and the whole Internet will show up to help you eat that elephant.
ReplyDeleteTime estimation is one of those professional skills that you develop. My own skill in making gut estimates is reliably about a third of the actual time required to actually get the job done. (It’s only half if I don’t need to deal with writing unit tests, but it is not wise to do without unit tests.)
One useful thing in time estimation is getting a feel for where the uncertainty is coming from, and narrowing that down. It’s worthwhile to give your engineers some time to do “proof of concept” code— not even a prototype, just a verification that they know how to tell the computer to do something intricate— just to reduce the uncertainty (which affects both scheduling and morale).
Oh dear. This may explain why I didn't really enjoy project management training. I think estimates are mostly useless. Especially test estimates. I will test it for exactly how much time you give me. Even if you give me a very stupid timeframe, like 1 day, it is still better to have SOME testing over none. I can recommend some things and explain what you get for A time, B time and C time. I can explain that when I say 2 weeks I mean 2 weeks from when the product does X thing and passes Y acceptance test.
ReplyDeleteI believe that when it comes down to it, all we have to decide is what to do with the time we have. That is quite close to my favorite quote from the Lord of the Rings. Go Tolkien. I'm a dork, but I think estimates are pointless. I deal with them like a Sasquatch duct taped to a wall. Get it over quickly and use soothing moisturizer after to soothe. If there is a dependency chain of woe and suffering, I try to draw it out with a weekly schedule so I know what I'm expecting that week and if I get every deliverable I can finish everything on time. I then have a mitigation plan of what to cut when that doesn't happen.
You can say I am the person who sees the house burning down when others think the frosting looks nice. Testers--not always great fun, but kind to a freshly waxed bigfoot.