How do great enterprises estimate software development efforts? [closed]

Question

I was learning about how to estimate software development effort, and would like to know how successful enterprises estimate their projects. How they do to know how much time a system will spend to be developed? What are the modern techniques to do this? What are the techniques used by these modern enterprises?

Some articles and interviews of employees of those enterprises would be interesting.

I asked on Project Management site of StackExchange too.

Answer 1

Read Steve McMonnell's Software Estimation - Demystifying the Black Art - http://www.stevemcconnell.com/est.htm for more information on Software Estimation techniques and best practices.

Answer 2

Generally, they'll look at how long similar projects took in the past and use that as their initial baseline, adjusting for any differences along the way. If there isn't a similar project to go by, they basically try to identify all the subtasks with known levels of effort, add them up, and then add a fudge factor.

Then, if they're smart, they take that estimate and multiply it by pi (as one PM I knew put it, an irrational schedule calls for an irrational number). Normally they leave that step out as it tends to result in unnacceptably long schedules.

Answer 3

Ask all the developers who are working on the project. If they disagree how much effort it will be, discuss the cause of the difference of opinion and then re-estimate. Repeat until you have a consistent estimate.

The estimates are based on each developer's knowledge of the system being worked on and similar systems they have encountered previously. As a project and the current team become more settled, the estimates should improve.

Answer 4

They don't pick a specific date, which is the trap too many people fall into.

They start with a wildly inaccurate, best guess.

Something like "3rd quarter 2012"

As they work, they are able to refine the date more and more. Eventually being able to say "We're releasing Sep 22, 2012"

And as they work, if they find their estimate is way off, they adjust it. M$ delays product releases all the time. If it isn't going to be ready, it isn't going to be ready.

Too often in practice I see 9 month and longer projects with go live dates set from Day 1. Shockingly we usually fail to hit those dates. And it's not changed until he week before...even though 2 months in you knew you weren't going to hit the deadline.

Answer 5

Since you are also asking for the tools rather than for "does it work", I'll share some of my experiences gathered at a big (a few thousand people) company:

It depends: internal/external contractor, just a work package, etc.

For Contracts

In the "big company" cost estimates are quite waterfall-ish: you go from the top down to the departments with the most experience in "what the customer wants" and let them do their numbers (the actual methodology will vary here). After that, you ask your QA, Management, Procurement, etc. for their input, add risk & opportunities and you will surely look at your competitors (i.e. adjust your price to the market situation if applicable and possible). In big companies, there usually is not just a "software development effort".

For Work Packages

This varies widely from case to case. I'm sure there are companies forcing their employees to do their estimates in a specific way. Though, in that specific example it's totally individual.

And it can't be THAT bad, since we deliver on time (mostly).

Answer 6

I don't think it's possible to do a decent estimate using a tool other than your brain and some experience.

What you estimate will have so many including factors like the size of your team, how many of your developers will not get sick or leave the company (or both!), the effectiveness of each team member can vary greatly depending on yet again many factors, funding may change depending on yet other factors, unexpected things may happen and the story goes on...

Once you've gotten started with a project you have many tools for managing many of these factors, like SCRUM based tools in various products that gives reports on any detail of the project, and companies like Microsoft uses SCRUM internally. But up front it's not easy to do good estimates.

I think it all boils down to experience. The rest is "guesstimates".

Answer 7

At the core it basically works the same way no matter what process or buzzwords you are using.

1. Divide the project into units.
2. Continue to recursively divide the units into sub-units until the unit is small enough that a somewhat accurate estimate can be given.
3. Identify any shared/duplicated units and merge them.
4. Multiply a weight rating to each unit for buffer time. You may apply buffer time for individual end-point units, higher level units, or even the base unit for the entire project.
5. Determine coupled units that should be developed by the same person. (ie units that would actually be more difficult to implement if split between several people)
6. Do the arithmetic based on number of developers, and coupled units.

Every estimate is a guess based on past experience. The smaller the unit, the more likely the estimate will be accurate.

You are attempting to predict the future. You can get it wildly wrong even if your best attempt at estimation was made.

BTW, it is very different than estimating something like manufacturing output.

For example a robotic machine can produce products at a constant rate. The estimates can be exact. The robot mindlessly follows a process. Software is a process itself. Machines can only follow processes, not create them (at least not effectively to date). So there is the randomness of creation.

The day we figure out how to make robots do all the development work is the day we get exact estimates.