|
How to provide a better estimation
how do you provide realistic estimates on something when you don’t know how long it will take to complete everything? What if there are problems that you do not yet know how to address. How can you estimate how long it will take when you haven’t solved the problem. Its almost as if you cant provide an estimate until you have planned everything. And how do you then incorporate the planning stage into the estimates? I'd be interested to hear peoples opinions on this.
Jason Williams
Thursday, February 5, 2004
It boils down to a guess. Some guesses are better than others - if you've built something similar before you can probably guess within 50% without too much trouble.
To be cynical, guess a value that's as large as possible yet still gets you the work.
pdq
Thursday, February 5, 2004
I always ask the same questions, but in these days I start to really believe what I read 1000x times, that software creation is a heuristic process, and you cannot make a 100% estimate about how much feature, money and time will you need for the final product.
I usually don't give out estimates only "guesstimates". And trying to increase the accuracy of that.
But it won't solve your problem. So do the usual thing, imagine how many problematic area you will have, what is your client type, know your previous estimates and correctness of those, and then ... and then reestimate periodically.
na/na
Thursday, February 5, 2004
There is a way, but it requires diligence and preparation.
You have to have metrics acquired from past projects, notably your rate of function-point production per developer. This takes into accoutn all their sick days, unexpected problems, surprises with IDEs and compilers, bugs you never expected, flakey drivers, everything... because it is an actual measurement from real life projects in the past.
You then figure the function-point count on the new project. Based on the schedule, you use a fancy formula from one of the exotic project management books or softwares to determine how many of your specific developers with specific talents and fp-rates you need to hit the desired release date.
If you don't have these metrics, you'll have to guess for now and be wrong. But your guess can improve as you adjust your estimate every week based on how far you've gotten and what you havd previously predicted. your starting guess will be based on breaking things down as fine as you can and assigning best guesses to each. Then when your real numbers come in you apply a correction factor to the whole estimate to get the new estimate. And for the next project, you'll have the metrics to apply.
Using these methods can enable you to predict release dates and bug counts of totally new projects to within 10%, even before you know how you are going to solve the problems.
Dennis Atkins
Thursday, February 5, 2004
In this kind of situation it's always an educated guess.
It's very important that you include your assumptions and a variance.
"It will take six months give or take a month or two, but I'm assuming here that you want a barebones system without a lot of fancy extras and I can dedicate a team of 20 men to working on it full time. I can pin down something a little more firm once I've been able to go over the requirements with you."
Coming up with estimates is easier with experience, and the more variables you can pin down the better. Whether or not a new project where you can work on it from scratch or if you're revising a system gives you better control of your variables is pretty situational.
If you have no experience in the area and no clue what's wrong or how spaghetti the code is, then it's pretty impossible to give an accurage estimate. Then you're in a situation where you have a black box.
Stuff goes in to the black box, and what's coming out isn't what you expect. You can't get in to the black box, and you're not familiar enough with the box to know what's going on inside.
Given that it's impossible to know what you'll find once you open the black box, an accurate estimate is impossible, so just give your best guess. Anyone with any maturity will know that you're giving a best guess (especially since you tell them up front that this is a best guess and make them sign contract wavers to that effect).
Of course, the business world has proven over and over again that they'll hold you to your best guess, at which point you get into the situation of wondering whether you should estimate high or low. Estimating high will make you seem more professional when you get it done faster than that, or it could make you seem less professional compared to the people who say they could do it in 1/3 the time.
Lastly, given that with experience comes confidence - i.e. once you've opened a few black boxes you can start to get a sense of what to expect - sometimes it's better to forge ahead from a "managing your career" point of view. Later you can revise your estimate based on what you actually find.
"Well, it turns out it's not a Commodore 64 like I thought but actual tiny people with calculators. They've run out of paper for their calculators, but I can't find anyone who carries it anymore, so I'm trying to track down vendors who can make special spools of paper."
www.MarkTAW.com
Thursday, February 5, 2004
I have two policies:
1. Never give a schedule without a spec. If for some reason,
someone demands a deadline without a spec, I put the
burden on them to defend their deadline, and will be quite
conservative in tailoring the spec to the deadline. Early
on, I will give an extremely rough approximation (ie, within
a quarter), and give a hard deadline for producing the spec
itself.
2. Once I have the spec, I'll always point out that any
and all changes to it change the deadline. If you absolutely,
positively gotta have that new feature, it'll push out the
deadline, and I'll make sure your request and your name is
prominent in the ongoing project plan. If you can't handle
that, your new feature goes into the RFE list in the bug
system...
People don't like this approach as they often argue that
it's "inflexible" - until they realize that we actually meet
our deadlines...
x
Thursday, February 5, 2004
Agreed! You need a spec to do a function point estimate as well, I forgot to mention that. Otherwise you can't figure out how many function points.
Dennis Atkins
Thursday, February 5, 2004
You could always try our time-honored method:
1) Define a goal so vague as to be meaningless
2) Spend 1 - 2 months on MS Project charts and Visio diagrams that are as excruciatingly detailed as they are wrong ("We have 3.625 FTE's on this in March, but ignore wherever it says Bob, because he left.")
3) After this, if anyone mentions the lack of design or specifications again, the Project Manager must say, "we can overarchitect this all day long, but we need something that can ship [to our internal customers]."
4) Claim that whatever was given to the customers at the deadline satisfies our goal.
I am told that we have yet to fail to meet our objectives on schedule.
Devil's Advocate
Thursday, February 5, 2004
I have a hunch that the complicated data collection and algorithms that Dennis suggests won't really give better estimates than an experienced manager/guesser. The problem with the algorithmic method, is that all you are doing is putting a complex equation around fake numbers. If x is a guess, then the result of f(x) is still a guess.
The real key is experience. Once you've worked on a handful or projects, and more so, done the schedules for a handful of projects, you start to get decent at estimating.
I should also say that a key part of it is knowing the development team. If you've got people that you know, your estimates will be much, much better. Otherwise, you have no idea if Programmer A will take 2 weeks to do Task B or 6.
David
Thursday, February 5, 2004
If you can develop a definitive answer to this question, you will probably become wealthy. It took me about 15 years before I could produce estimates within 10%, but I'm a slow learner. Here are the guidelines I use.
1. You will spend 50% of your time debugging. Unless you can absolutely, positively prove otherwise via prior projects, drop the ego and accept this as a fact. Refusal to accept this accounts for more late projects than any other factor. I count the time spent on test-driven design, developing unit tests, and DBC statements (design by contract) as "debugging time". If you spend the majority of your debugging time in beta or post-release, you are doing something wrong.
2. Assumptions are liabilities until they are confirmed. So don't list all your assumptions. Instead, list the unknowns (questions), and understand that the project will not be completed and your estimates will be suspect, until all your questions are answered. Restate your assumptions as questions.
3. Subdivide the project until you have only tasks small enough to complete in 1-2 weeks. Then place these tasks into 3 categories: a) I have already done this and know how to do this b) I need to research and learn how to do this c) I think I know how to do this.
"a" tasks can be accurately estimated.
"b" task estimates are unknown: list your questions and estimate how long it will take to discover the answers.
"c" tasks involve assumptions. Assumptions are danger. "c" tasks also involve ego. Best to restate these tasks as "b" tasks.
4. Prior experience can help. But something that is often overlooked: if you don't know and thoroughly understand what you screwed up on the last project (in terms of estimating), you won't recognize when you are screwing up on the current project. Study your failures, keep a professional diary to help with this.
To summarize, the more unconfirmed assumptions you hold, the more likely the project estimate will blow up in your face. Be aware of your assumptions, restate them as questions, and you will have a good understanding of the risks in your project.
magoo
Thursday, February 5, 2004
^^^
Best estimating post EVAR! :D
Norrick
Thursday, February 5, 2004
Bruce Eckel, in his book "Thinking in Java" has a section "Analysis and Design" in which he says:
"Although it’s a black art, at this point some kind of scheduling can be quite useful. You now have an overview of what you’re building so you’ll probably be able to get some idea of how long it will take. A lot of factors come into play here: if you estimate a long schedule then the company might not decide to build it, or a manager might have already decided how long the project should take and will try to influence your estimate. But it’s best to have an honest schedule from the beginning and deal with the tough decisions early. There have been a lot of attempts to come up with accurate scheduling techniques (like techniques to predict the stock market), but probably the best approach is to rely on your experience and intuition. Get a gut feeling for how long it will really take, then double that and add 10 percent. Your gut feeling is probably correct; you can get something working in that time. The “doubling” will turn that into something decent, and the 10 percent will deal with final polishing and details. However you want to explain it, and regardless of the moans and manipulations that happen when you reveal such a schedule, it just seems to work out that way."
Personally, I follow the same approach as mentioned by "Magoo" above. Break down the problem into as many sub-tasks as possible. For the sub tasks that need more R&D into, build prototypes and then give an estimate. If your manager insists on a rough estimate initially, then tell him/her that you require x number of days to build a prototype and/or try out a few things after which you will be able to give a better estimate. People generally understand this and are willing to give you a few days if in return they can get a better estimate.
For other sub-tasks which do not require any R&D into, you can make an informed guess. Then total the effort estimates of the individual tasks, add your buffers into it and you have the final estimate ready.
T-90
Friday, February 6, 2004
Estimation is for pussies. Just tell the client it will be done when its done. If he gives you shit, tell him you're altering the deal and he should pray you don't alter it further.
Software Engineer
Friday, February 6, 2004
But the client may respond:
"Perhaps I can find new ways to motivate them."
x
Friday, February 6, 2004
It gets better with the years on one condition: you keep your knowledge of current day techniques polished. The worst estimates I see or those made by people that once were developers, like 15 years ago, went into management and never updated their devskills.
It is a "gut feeling" thing, but you have to know how to interpret your gut.
First, do a quick rough breakdown of the project into separate tasks. These should not be very detailed, but just into chunks that you feel comfortable giving a rough estimate for. Then do a very rough planning to discover any obvious sequence bottlenecks. Estimate all the parts in a true optimistic fashion (how long would it take if everything goes perfect and no snags are encountered) and fit them into the rough schedule. This gives you an overall rough estimate.
The next part is very peronal, and really depends on you own character. This is something you discover over time. What works sortof for me is multiplying everything by 4 (remember, my initial estimates are for the most optimistic case).
To be honest I do tend to vary the multiplier depending on things such as familiarity of the team with the development environments, external dependencies, penalties etc.
Just me (Sir to you)
Friday, February 6, 2004
You simply cannot estimate anything beyond a week or two, so don't.
Step 1: Decide, with the person providing the funding, what you will provide first. (Select something that would take no more than a week, but that delivers real value.) Write it, with complete tests that automatically report your success or failure.
Step 2, if they liked the outcome of the previous step enough to fund the next step: Decide, with the person providing the funding, what you will provide next. (Select something that would take no more than a week, but that delivers real value.) Write it, with complete tests that automatically report your success or failure.
At this point, you might have noticed a pattern. If this sounds strange to you, perhaps a visit to the link below will get you started in sensible software development. (To be honest, there's more to it than I've just said, and you need serious discipline and diligence, but above is the rough pattern for success.)
http://www.agilemanifesto.org/
veal
Friday, February 6, 2004
Please, let me drink the magic punch!
Customer: I need you to build me a payroll system to replace our legacy non-Y2K system.
Zealot: I'll tell you what, Come back in a week, and we will see how it is going and go from there - all right dude...
sigh...
Friday, February 6, 2004
Cute straw man. Feeble, too.
Want to learn something? Let's proceed...
Question 1: Are you saying your "payroll system" customer no idea what he wants?
veal
Friday, February 6, 2004
This is a hoot. Some good responses but I think time-honored prevails. I've yet to work at a place that kept ANY records at all on anything other than what the accountant was doing. Honestly. I keep telling people we ought to like start a written history and break out of the oral tradition. Of course writing doesn't not imply value. I've seen too much of what honored mentioned: people just slinging graphs and paragraphs hither thither and those people who don't understand how the docs can be used are the ones insisting the docs exist and why can't "you" use them to hurry up and get this out already when the "this" was never really defined. Oh well. Were it my own company I'd keep a history of estimates, track actual dev time, then do a followup and compare it to our estimate to learn the next time. You will never get enough specs/info before someone wants an estimate so it will be past history, current understanding of customer/project.
Me
Friday, February 6, 2004
No manager wants to write down how late his project was. And, if it's late, it's always because there were new requirements added, requirements that weren't well understood, or some dependency that was lacking. Feature creep also is a big reason why schedules slip.
I've yet to see a project miss it's estimates because the programmers were lazy or stupid.
pdq
Friday, February 6, 2004
> how do you provide realistic estimates on something when you don’t know how long it will take to complete everything?
Provide realistic estimates on the parts which you do know.
> What if there are problems that you do not yet know how to address.
Identify these problem areas. Estimate a range (e.g. "1 to 10 weeks, depending on whether component X works as we're hoping or whether we must rewrite it"). Specify what you must do to make a more accurate estimate ("it'll take 1 day of reading the code and talking to a specialist, before I can give a more accurate estimate on this item"). Consider doing this work early ("I'll do this investigation tomorrow, as part of the work of coming up with a relistic estimate").
> Its almost as if you cant provide an estimate until you have planned everything.
That's a fair comment.
> And how do you then incorporate the planning stage into the estimates?
See above: a little time to estijmate the parts you already know about, and a longer time to estimate the things that require research.
Christopher Wells
Sunday, February 8, 2004
Guys
Thanks for the helpful feedback. I will be pouring over your replies and discussing them with other members of the team. Thanks again.
(oh and good post by Software Engineer ;-)
Jason Williams
Wednesday, February 11, 2004
 Recent Topics
Fog Creek Home
|
