IT PROJECT MANAGEMENT CHAPTER 7

ESTIMATION

HOW TO ESTIMATE SOFTWARE?

How do you estimate how long it will take to develop a project? Lets say you want to decide when to work on it
You want to decide when to work on it You want to fit that into your schedule To do so, you need to know how many hours it will take

ESTIMATION
Estimation involves using the following information in order to make an educated guess about time or resource requirements:
Knowledge of the work required (expertise) Group knowledge
Ask people who know how long it should take

Prior experience

Coming up with estimates as a group is no substitute for expertise, but sometimes expertise is not available Advice from a group is generally more reliable than advice from an individual E.g. it previously took 8 minutes to copy, print, seal, stamp, and address 1000 brochures It should take about 80 minutes to get 10.000 brochures ready E.g. the team has worked on 3 other projects, which were all 25-50% over budget on time Therefore, expect them to go over their own estimates by similar factor

Historical data

ESTIMATION
How creates estimate?
Technically, the project manager does However, the PM is not an expert in all areas (e.g. deliverables)
Thus, the experts need to be consulted when creating estimates The experts are the people who might be asked to do the work It is wise to get a second (or third) option, to offset estimate bloat and over-optimism Estimate should start from the task level, since they are easy to estimate

ESTIMATES
Initially, specify an estimate as a range The range should be large enough that the actual time should be in that range, despite:
Low productivity (less skilled, less motivated) Interruptions Mistake & misunderstanding E.g. 2-3 weeks

As time goes on, the estimate range should narrow down further

This is necessary due to feature creep and other similar practices on all projects

However, the actual duration should still fall within that narrower range This narrowing gives management a better idea of how long it should take On the other hand, the ranges provide a safety net for you

ESTIMATES AS RANGES
If you dont know what the customer wants, so you cant yet make an informed decision

Con: this house should take about 4 months to build Cus: Good!! We have a deal

contractor

customer

ESTIMATES
Upper management does not like estimate ranges To keep them of your back, you can elaborate: E.g.
Susan how long will it take to prepare the development environment? Mike: it should take 2-3 weeks, with a most likely estimate of 13 days.

ESTIMATION UNITS
There are several units in estimation:
Total time:
E.g. it should take 3-4 weeks, with a most likely estimate of 18 days This makes it obvious when the project should be completed E.g. it should take 2-3 person-months, with a most likely estimate of 10 person-weeks This way, you can see how adding people to the project will affect its duration E.g. it should be around 50.000 lines of code This figure can then be used for other estimates, such as total time However, few developers count line of code anymore, so this is not very common Also, not all lines of code are created equal An estimate of the number of inputs, outputs, files, database tables, etc, that an application will require

Human resource utilization (effort)

Line of code (size)

Function points (size/difficulty)

ESTIMATE ADJUSTMENTS
Estimates are constantly refined to narrow the window of completion
Thus, how well the team achieved previous goals can be used as a measure of their performance Project velocity can be used to adjust the estimate of the remaining task

Estimates are often bloated by contractors

If they go over schedule, they dont get paid any extra This can be factored in by observing past estimates and adjusting accordingly

CREATING ESTIMATES
Estimates are created at the bottom, and work their way up
Tasks can be estimate easily The activity duration can be computing by taking the sum of the task durations This allows us to estimate activities that are crossdisciplinary

However, minor deviations in task durations can quickly add up to major deviation in activity duration
This is exactly why to use an estimate range If your range includes the actual duration, it will be difficult to say that you were wrong Creating an accurate estimate from day one is impossible

FORCED SCHEDULES
All too often, upper management will push down estimates or deadline
This deadline might be impossible What criteria did they use to create it?
Business plan, market conditions, etc These things do not talk about the difficulty of creating the software or the required work

However, does that make them wrong?

So what can a project manager do?

Not always! If market or other conditions require that software must be done by a certain date, then it must be
Reign in the requirements so that a project is do able in the specified time Do the most important requirements first, and the least important requirements last