Guesstimates vs Estimates 3

[coco86]

Here's a typical scenario... I am called into a meeting, given a five minute (max) description of someone's concept for a new application. Then comes the inevitable question: How long will it take to write that?

How do I get management to understand that without time to analyze the problem and determine the requirements, anything I say is nothing but a guess?


-Coco

 

[PDQBach]

Turn the situation back on them:

Ask "How many people (and which ones) will be assigned to work 100% on the project?"

Now you have them. When they tell you the people, your answer is that you want to discuss it with them because you need their input and until you have that you can't accurately predict how productive they will be.

Actually, it sounds to me as if you're being called into a marketing meeting. If that's true then the second method is to say that you and your boss have agreed that you will only prepare estimates -- verbal or written -- that he has asked you to do. (Naturally, you *do* discuss this approach well in advance with your manager. A good manager will protect his people.)

The third is to say, "Well, I'm up to my eyeballs on other work so I won't be working on it and since they'll be doing the work then you really should ask them."

In short: there's no easy, simple answer and you really haven't given us enough information to help you out.

 

[coco86]

Wonderful suggestions all but they don't really work for me. I guess I should have given you a little background.

See, I'm the only programmer in my organization. This is my first job out of college so I've never worked on a team before and all I know of how things are supposed to work is what I've read in books. Most of the time I'm being asked to do something I've never done before. I usually know it's possible but I need to research how.

As for my manager, he's one of the worst offenders. We've had many discussions on the subject. On the one hand, he tells me to just pad my estimates (which doesn't really help because I still have no idea what the real time frame is) and on the other hand, if I give him a number that he thinks is too high, he accuses me of being "difficult". He seems to think I should have learned how to give an accurate estimate in college.

The applications I'm being asked to design are mostly for in-house solutions to situations that arise. If I don't get them done on time, it only hurts my reputation. Occasionally, though, I'm asked to do something for an external client. Those are the worst, of course, because the job is usually bid based on my guess.




-Coco

 

[PDQBach]

In the red corner: Rock.
In the blue corner: Hard Place.

In the middle: You.

You're in a lose-lose situation. You can't say "All the text books and the stuff I've looked at on the internet say that any estimate at this stage is +/- 50%." Fact is: the text books and the internet do say that.

You can't say "This is my first job out of college and I'm still learning." Fact is: it is.

The best you can do, I think, is to give an estimate and add "But when I get further into the project, I will revise it and give you a more accurate estimate."

You could try developing your own algorithm. I did one for a language you've never heard of that basically took the number of files (one day each), number of transaction types (one day each) and number of reports (1 day each). There were a few other factors which had days or hours assigned to them. Then I validated it against work I'd already done and made some mods to my algorithm.

You could use a similar approach. Start with 1 day per screen, 1 day per table, 1 day for help screens, 1 day per report (it *always* takes a day to get a report to line up correctly) and see how accurately it works on projects you've already done and then modify it as appropriate. Remember: this is not just coding time we're estmating; this is coding, testing, compiling, debugging.

Remember to add time for end user documentation, your own department documentation, time for developing the distribution/installation file(s).

As a rule of thumb: for every 8 hours you are at work, you are productive for 5-6 of them. The rest get lost in downtime, administrivia, shop talk, meetings, coffee runs. So, when you get the number of days, those are "100% dedicated" and you are not 100% dedicated.

You could also add "Let's allow two days for your department staff to do end user acceptance and a day for me to fix any bugs that they might find. If you want anything changed, that will increase the estimate. This looks like a really interesting project ... shall I get started on it now?"

One thing you should get started on: an updated resume.

 

[coco86]

Thanks for the insight. Developing an algorithm is a good idea. At least it would give me a concrete way of approaching the issue.

The truth is, I actually do really like my job. I guess I just feel a little misunderstood sometimes. I also struggle with my own self doubts. I'm often tempted to estimate a job at what I think it should take based on my own opinion of what I'd personally pay for said program, and I'm notoriously cheap. With no real frame of reference to know how long others would take to do the same project, I tend to beat myself up a lot--rightly or wrongly, I don't know.

Thanks again for the words of wisdom

-Coco

 

[buitenhek]

Dear Coco,

"Dear Boss, you can have the program quick, accurate or cheap. Pick 2!"

Since you have successfully produced software before (you're still working)you can guestimate development time based on the average previous efforts. If it is something you think you can knock out quick, guess 1.25x. If it sounds hard-guess 1.5x and if easy..guess 2.0x. No Joke.

Since firefighting mode seems prevalent at your company, you should not be penalized for finishing earlier.

Good luck.
Peter Buitenhek

 

[Guest_imported]

This reminds me of something I heard about weather-forecasting. Someone asked a friend, a TV weather-forcaster, where they get the "75% chance of rain tomorrow" from. Answer was, that there are 4 forecasters on that TV station, and 1 of them disagrees.

On a more serious note, there are some methodologies. One we were told about recently is a thing called COCOMO (-2 now I think) which uses a database of history in "similar" applications to guage time and other resources. Over time, this gets refined with the actuals from your organisation. But it's very complex from what I saw, highly statistical, and not for the numerically challenged I think.

Jim Brown,
Johannesburg,
South Africa.
My time is GMT+2

 

[coco86]

Peter

You're so right about doubling the estimate for the ones that seem easy. Those are the ones that most often seem to bite me in to butt. Of course, I've also usually only been given about 25% of the actual requirements.

Jim

Your story is humorous. When I was a teenager, I wanted to be a meteorologist. This primarily because of my facination with weather patterns but also because where else can you be wrong most of the time and still keep your job? Well apparently, this is it

I read something on the Internet that suggested asking the person who wants to know how long it will take: "How long does it take you to get home from work?" The answer is likely to be something like "about 20 minutes?" A little probing will reveal that sometimes, depending on traffic, it can take 10-15 minutes longer. The point is that if they can't accurately predict how long it will take to do something they do every day, how can we predict how long it will take to do something we've never done. Perhaps the next question should be "Okay, how long would it take you to get to my house?"

-Coco

 

[johnherman]

Well now I have to throw my 2 cents in. I am a meteorologist (via the Air National Guard) and a Project Manager (via my civilian career). First, the science of meteorology is well known and easily solvable by computer - 7 partial differential equations in 7 unknowns, HOWEVER, there is not enough input data to make accurate forecasts. 7-10 days out is about the best we're going to be able to do as far as weather forecasting, and being wrong could simply be the result of one or more very significant weather events slipping through our observation network.

Now, to the more difficult science of predicting project completion. First, any good project manager will add 20% slack to an estimate, and I agree with Peter Buetenhek as far as going into doubling if necessary. I realize that you may have established a standard by providing estimates on short notice, but perhaps you need to step back and ask them to let you consider the project and get back to them later that day. Unfortunately, saying something like "my first guestimate is 3 days" will result in your being held to 3 days even if later that day you increased the duration to 5 days. Remember to mark at least 2 days each month as non-working days, either because of sickness, personal appointments, company obligations, inclement weather, etc. In addition to scheduled holidays and vacation. In addition to the estimate. Further, the last week of the year rates ZERO productivity. Anything that gets accomplished then is a "gift".

You really need to stop giving the estimates in the meeting and prepare a brief "Concept" or "Charter" or "Scope" document before making an estimate. In fact, you can use that as your excuse the next time you miss a deadline and then respectfully request that you be given time to complete the "Concept/Charter/Scope" document in order to obtain agreement from the "Idea Man" that this is what is being requested before actually giving your estimate. It also gives you time to look for hidden glitches or other difficulties.

Good Luck.

Sometimes the grass is greener on the other side because there is more manure there - original.

 

[cjowsey]

As you have pointed out, guestimating is an inexact science and those face to face on the spot meetings are always difficult to deal with.

You can make it better for yourself in the future if you keep a record of how much time (both elapsed days and actual effort) you put into your projects. Then in several months when you are asked, you can turn around and say &quot;This sounds quite like project ABC which took <n> days&quot;. The more you measure, the better you will be able to tighten up your estimating process and make it much more repeatable which is what we are all aiming for.

Secondly, if you suspect that the manager or business user is not giving you the full details on the project up front (and they almost never do), get them to document their requirements. It is great how sitting down and writing can really make a person see the bigger picture and the little hurdles at the same time. You can make life easier for everybody by providing them with a document template and ask them to fill it in.

Hope this helps,
Clive

 

[coco86]

Clive-

Getting the user to document their requirements is something I've been trying to do lately. However, I'm meeting resistance to the tune of &quot;I don't have time to do that, can't you just figure it out?&quot; and &quot;We've never had to do this before, why now?&quot; This is especially difficult when the person is an upper level manager.

How do I convince them of the value of what I am asking? Most of them have no idea what I do. Often times they think they are asking for something very simple when in reality, it is extremely complex.

-Coco

 

[ponderworks]

Ok, here's something I've used very successfully lately. It is a combination of things that have already been said. Start by finding out who will be the user of whatever you are programming.

Talk to that person (however briefly) about what they want, when they want it, and what it should do. Write it up as best you can.

Sit down with any good spreadsheet package and in one column put the name of each subset of code or function you will be creating.

In the column after it, put your best guess as to how long it will take.

In the next column put the word &quot;Low&quot;, &quot;Medium&quot;, &quot;High&quot; to indicate whether that piece in your opinion will be easy, moderate, or complex to do.

In the next column take your original estimate and...
If low, copy it to this column
If med, multiply your estimate by 1.5
If high, multiply your estimate by 2

Assuming you are working on it full-time, you can just add up the time and see how long.

Don't forget to add time for acceptance testing. I'd start with about 50% of the total dev time.

The result will likely not be an &quot;accurate&quot; estimate. What you will have is a primitive form of metrics based estimate you can measure your performance against. When the project is done, see how well the prediction matched up with reality. Wherever you were off, adjust the model accordingly. Keep using the same adjusted factors until you are seeing some correlation between estimate and reality.

I actually have done this a couple of times with good results over time. Accurate estimating is a process based on metrics tracked over time. It takes discipline and attention to detail most organizations just don't have.

Good luck.

 

[ponderworks]

Ok, here's something I've used very successfully lately. It is a combination of things that have already been said. Start by finding out who will be the user of whatever you are programming.

Talk to that person (however briefly) about what they want, when they want it, and what it should do. Write it up as best you can. MAKE THEM SIGN IT.

Sit down with any good spreadsheet package and in one column put the name of each subset of code or function you will be creating.

In the column after it, put your best guess as to how long it will take.

In the next column put the word &quot;Low&quot;, &quot;Medium&quot;, &quot;High&quot; to indicate whether that piece in your opinion will be easy, moderate, or complex to do.

In the next column take your original estimate and...
If low, copy it to this column
If med, multiply your estimate by 1.5
If high, multiply your estimate by 2

Assuming you are working on it full-time, you can just add up the time and see how long.

Don't forget to add time for acceptance testing. I'd start with about 50% of the total dev time.

The result will likely not be an &quot;accurate&quot; estimate. What you will have is a primitive form of metrics based estimate you can measure your performance against. When the project is done, see how well the prediction matched up with reality. Wherever you were off, adjust the model accordingly. Keep using the same adjusted factors until you are seeing some correlation between estimate and reality.

I actually have done this a couple of times with good results over time. Accurate estimating is a process based on metrics tracked over time. It takes discipline and attention to detail most organizations just don't have.

Good luck.

 

[cjowsey]

Coco,

In answer to the question &quot;Can't you just figure it out?&quot; a good response would go along the lines of &quot;If I had your knowledge and experience to just figure it out, then I would be working alongside you and not in a graduate IT role.&quot; You need to find the right level of flattery to let senior managers realise the difference in skills and business experience.

To answer the question of why start documenting requirements now, my answer would be &quot;We do not have a good record of getting our estimates right and we need to fix this. Mostly the reason for poor estimating seems to be incomplete requirements definition. Let's tighten this up and make everyone look better.&quot;

If the management people think they are asking for something very simple which in fact is relatively complex, there is an gap in understanding and interpretation that needs to be addressed. I have used a variant of ponderworks' concept a few times where we have produced an agreed list of features and functions and then got technical, business and management people to put in their own estimates. Discussing the differences between estimates can help to bring everybody together in an effective non-confrontational way.

Clive

 

[coco86]

Oh, I like that! Very good responses. Thanks for the input.

-Coco