Project Management

Use this simple process for estimating project duration

Any project manager knows that no project is completed in perfect circumstances. So you should use the following process and techniques if you want to make your schedule estimate as realistic as possible.

If everyone worked eight hours per day on your project, and was absolutely 100% productive for all eight hours, you could easily calculate duration by taking the number of effort hours, divided by the number of resources, divided by the number of hours they work per day. For instance, if an activity was estimated at 80 hours, and you have one person assigned, and that person works eight hours per day, the duration would be (80 / 1 / 8) = 10 days. Likewise, if four people were assigned full time, the duration would be (80 / 4 / 8) = 2.5 days.

Tips in your inbox
Looking for expert IT project management? Get the help you need from TechRepublic's free Project Management newsletter, delivered each Wednesday.
Automatically sign up today!

However, as we all know, those perfect circumstances are not indicative of how work is actually performed. There are many reasons why the duration of the work is different than the effort hours divided by eight. You need to use the following process and techniques if you want to make your schedule estimate as realistic as possible.

  1. Estimate the productive hours per day. The first step is to determine how many productive hours of work you can count on each person working per day over time. The rule of thumb is to use a factor of 6.0 to 6.5 productive hours per day. This takes into account socializing, ramping up in the morning, going to the bathroom etc.
  2. Factor in multi-tasking productivity loss for part-time resources. If one person is working on multiple projects, or perhaps a combination of projects and support, you need to take into account a further reduction in productivity. This reflects the fact that if a person is shared on two or more unrelated efforts, it takes time to stop one and start up another. For instance, if a person is on two projects for 20 hours each week, this might result in a 10% loss of productivity on both projects.
  3. Determine how many resources will be applied to each activity. In general, the more resources you can apply to activities, the quicker they can be completed. Obviously two resources may be able to complete an activity faster than one person (but it may not be twice as fast).
  4. Factor in available workdays. Take into account holidays, vacations and training. This was not included in the productivity factor in the first item, since this non-project time can be scheduled and accounted for in advance
  5. Take into account any resources that are not full time. If you have a resource 50% of the time, it will take that resource at least twice as long to do any individual activity.
  6. Calculate delays and lag-times. Some activities have a small number of effort hours, but a long duration. For instance, if you're counting on vendor resources, you may need to wait until the vendor is ready before you can begin. Another example is the duration required to get a deliverable approved. You may estimate the effort at only a few hours, yet it may take a number of days or weeks to gain the actual approval.
  7. Identify resource constraints. When you build your initial workplan, you identify the activities that can be done sequentially and those that can be done in parallel. If you have enough resources, all of the parallel activities can, in fact, be done in parallel. However, if you don't have enough resources (you rarely do), you'll find that some of the parallel activities need to be done sequentially, since the same resource needs to be assigned. This results in extending the duration further than what you might initially expect.
  8. Document all assumptions. You will never know all the details of a project, so it's important to document all the assumptions you're making along with the estimate.
20 comments
goffd
goffd

For estimates do 3 values: Best case, likely case and worst case. Get estimates from at least 2 people. Then the degree to which they differ is a good indicator of risks and unknowns. Differences between best likely worst indicate that person's confidence or the presence of a risk. Differences between estimates across people indicate there is not a consistent understanding of the task and leads to discussons that can resolve this.

hacchow
hacchow

hoping that someone can point me to other articles supporting the concept of using a 6.5 hour work day (instead of 8 hours) in software development project planning. I need to further convince the board of directors/executives. Many thanks!

shenyl
shenyl

You have mentioned all about efficiency issues. But effectiveness factors will include: Resource Competency to assigned tasks Clear definition of assigned tasks Complexity of project etc

techmail
techmail

You know how long it takes you to perform some task. Is the same amount of time required when that task is delegated? No. Take your time measure, double it, and go to the next higher unit of measure. Example:You delegate a task that you can complete in 2 hours. Question: How long until the task is completed? Double the number: 4 Next higher unit: day Answer: When delegated, a two hour task requires 4 days for completion. I've never seen this bit of timimg included in any project plan, but we've all seen it happen. John

stephen.holland
stephen.holland

As the old project management axiom goes, just because it takes one woman 9 months to have a baby, doesn't mean you can get it made sooner by adding more women. Two pieces I will add here don't forget PERT analysis of your estimate. PERT gives you a higher quality more robust effort estimate. PERT says: E = (L+4M+H)/6 Where: E = Effort Estimate L = Lowest Estmate M = Median H = Highest If you have a new team of inexperienced resources then ylou may wish to change the formula to take this into account - (L+M+4H)/6. If you have a very experienced team you may want to push your estimate the other way, the formula becomes - (4L +M+H)/6. You can then factor the other impacts to duration such as: Annual Leave: 1 2/3 days Project Meetings: 1 day Travel to/from meetings: 2 hrs Telephone Calls: 1 day (30 Mins a day) Emails: 1 day (30 mins a day) People Care: 1/2 day Corporate matters: 2 hrs Contingency: 1/2day All numbers are per month. This is approximately 6 days of unproductive time (not work on project deliverable) If there are 21 days availale for for work then the actual productive hours (working on project deliverables) is 15 days. PF = 15/21 = .71 PF = Project Productivity Factor D = E / PF D = Duration Using the formula for 80 hours D = 80 / .71 D = 113 hours (rounded up) If you use MS Project or similar using the effort and duration columns the project end date and total duration will calculate. To use MS Project effectively I recommend getting training and some books.

Ivy Clark
Ivy Clark

We should also include the time needed to document the requirements/specifications. For existing systems, new requirements should be added onto existing system documentation, to ensure they remain relevant.

Ivy Clark
Ivy Clark

We should also include the time needed to document the requirements/specifications. For existing systems, new requirements should be added onto existing system documentation, to ensure they remain relevant.

sfessey
sfessey

may sound like a stupid question and I am not a slave to MS Project but I am expected to have a project plan in that format. Is there a way to do this in Project or is it a case of getting the calculator out and then plugging the resulting duration into the application?

generapharm
generapharm

You should factor in the Mythical Man Month. As the number of people involved in a task increases the lines of communication increase and the project slows down.

Goodwisj
Goodwisj

Agree with most of the steps - 13 years after commencing the role of PM I find that they all stand the test of time. I believe that team performance is also important... How efficient is the team in the specific project (team = one or more resources involved in a task or workpackage). If you believe that the team is 80% efficient in the particular subject matter then divide the time determined so far by 0.8.... If you have a guru then you may find that they are 110% efficient compared with the normal run of things - so divide the time determined so far by 1.1, etc. Also including the risk profile for the project may make things more accurate - good old Monte Carlo analysis is a good way to go.... cheers Steve

Tony Hopkinson
Tony Hopkinson

double it and add ten. Even if you get the 80 hours morphed into a date expected when factoring in the resource. Eighty was a guess, just something to bear in mind.

onbliss
onbliss

...in the real world. Also, I have noticed resources spending time in "whiteboarding" and/or other design/discussion meetings because s/he has the domain/technical knowledge (essentially the go-to person). The larger a team gets, the more we get to see this.

jcjr031064
jcjr031064

How much weight do we assign for resource Competency to assigned tasks, clear definition of project? How do we put them in the formula to compute for the estimates?

onbliss
onbliss

You bring a great point. In the analysis and design phases, one of the deliverables is the physical document (so to speak); rarely is time alloted for writing/creating those documents. I think an organization should come up with the required documentation for each phase, and derive a multiplier from past projects/experience. This multiplier can be used to get the total time for a phase. Example: If the multiplier is 1.25 (25% time ) for the requirements phase and 1.2 (20% time) for the design phase. Then the time estimates should be multiplied to get the time-effort for a phase.

tkitching
tkitching

You can setup the amount of work hours for each resource per day. This is an option available when first setting up the project plan and can be modified during the project. Use the help feature supplied in MSproject for more details.

norris1976
norris1976

Software development is a complex and creative art. It is hard to put an estimate on things with these points as people are not machines. Although the points will point in you in roughly the right direction, you can only really estimate by learning as you go. Agile methodologies use a term called Velocity: using the performance from previous iterations (or previous projects if the team is the same) to improve the accuracy of estimations as the project moves along. Personally, I think it is the only way to take the mythical black magic out of estimating.

Ivy Clark
Ivy Clark

Yup, happens to my team a lot... sometimes, each of these meetings take 3 hours! So having 2 meetings in a day, really makes it difficult (impossible) to be productive. But how much time should we buffer?

stephen.holland
stephen.holland

E = (L+4M+H)/6 Where: E = Effort Estimate L = Lowest Estmate M = Median H = Highest If you have a new team of inexperienced resources then you may wish to change the formula to take this into account - (L+M+4H)/6. If you have a very experienced team you may want to push your estimate the other way, the formula becomes - (4L +M+H)/6.

sfessey
sfessey

I have just started as a PM having been an IT manager for several years. I know the basics but it is a steep learning curve and making decisions based on what are no more than estimates is a daunting task. I am certainly learning as I go but this is a major hardware refresh project and they have nothing at all saved from the last time they did such a thing so it is basically open book. I have a myriad of resources on PM techniques etc so plenty to read - what I want is a mentor but that is what I use this forum for :)

Editor's Picks