We are doing a fair amount of estimating at work right now. We had a long meeting discussing an estimate for a project with heaps of unknowns. We put a decent plan in place for refining it next week on our own, but this book will help a lot I think.
I took a course at OMSE that covered a bit of estimating, but it was far too academic. I flipped through the book from the class I took and while it had some good ideas, it wasn't practical enough. McConnell's book touches on some of the academic approaches, but is very concise and has heaps of practical advise. The best part is it is broken down into 118 "tips" that are the heart of the book. I won't give too much of the book away, but the first tip sums up what is typically the crux of the problem:
Distinguish between estimates, targets, and commitments.
And Steve gives a suggested reading path for people who "need to create an estimate right now" (i.e., me and my team).
I like this book because it is focused on one thing (software estimating) - one absolutely critical thing.
We need more books like this. We can't just have the Mythical Man Month to turn to.
6 comments:
I don't think that estimating is the problem. Senior developers are generally fairly accurate in their estimates. I personally double my immediate instinct and that is accurate much more often than not.
The problem is, as McConnell states, that developers give estimates and management hears commitments. A developer's estimate has a certain variance associated with it, let's say plus or minus ten percent. Management, however, interprets the value given as the guaranteed worst case. Therein lies the rub.
If you are intersted in estimating I would strongly recommend Agile Estimating and Planning by Mike Cohn
10% huh? Sure within an existing project I buy that. Right now we are sizing a medium sized new project that has many many unknowns. We don't even know for sure what the tech stack will be. Fat client? Web? Plug-in model? And there are a lot of org. unknowns. It is almost pointless to do it, but you have to (with lots of assumptions and % confidence disclaimers). We can time box up through the design phase and be reasonably accurate, but after that its a bit of a crap shoot at this point.
Thanks for the tip on the book Tom. I'll check it out. Sadly, Powells does not have it in stock so I can't walk down there and get it today.
Kris,
I'd say there are lots of them. Its the estimate trap. You honestly don't run into this? Executive management wants to know how much its going to cost for the budget. Problem is you don't know in the beginning. So you give an estimate. If you aren't careful, the original number is the budget and if you go over it, you are a failure. We are trying to avoid this by clearly identifying what we know and what we don't know. Also good to identify the logical points where the project can be killed. You have to spend money to narrow the "cone of uncertainty" as McConnell calls it.
Mike
Have you tried using Monte Carlo. I have used it a couple of times on my projects and it works failry well. Allows you vary the estimate depending on how much risk do you think a project has. I actually have developed a small toolkit that allows me to create a probability distribution, that I can then use work with the PMs/Stakeholders to figure out a number that all of us are comfortable with.
Post a Comment