Estimating Principles

There are some basic principles you ' l l utilize when formulating these time estimates. Dirst of all, you won t be the one who estimates the time for a given activity. Assign this duty to the team member who' l l be working on the activity; that person is the expert in this area, not you. However, you need to caution the people who are providing estimates that they should use average production time for a given activity and not try to get within a nanosecond of the activity' s actual duration. If you lack a resource for a given activity, try to get an outside expert to give you the estimate. Get all the estimates before you total them up.

Be sure that you factor in things that might affect your time estimates — things such as overtime that people need to work in order to accomplish the activity. It ' s important to let project members know that it is critical for you to be notified if there are changes to time estimates.

You should always have your time estimates reviewed by someone who understands the activities involved but who is objective about those estimates. It doesn 't help to have someone review your time estimates who has a bone to pick regarding the project.

Tip A vendor' s technical support person may be able to back up certain time estimates.

You shouldn' t perform the review process with the wrong attitude. Don ' t be suspicious that your estimators are lying; you are simply validating that their estimate is close to the mark. Think of it as having two people count your poker winnings. Remember that the time estimate you put to the project impacts the scope and that you don' t want to modify the scope unless you absolutely have to, so when you put the time estimate out there, you want it to be correct.

There are things that the project manager can do to facilitate good time estimates. Validate the criteria by which the estimator went about giving you the estimate. Also, when you resolve issues with your estimates, do so with the smallest first. The reason you do this is because one activity ' s estimate may have ballooned due to an enlarged estimate from a component task or predecessor activity. The two feed off each other, so if you go back and correct the first, smaller, estimate, the second one may adjust itself downward.

Be vigilant about revisiting time estimates. Try to determine potential risks that may arise from estimates. Team leads don' t usually remember to add time to their estimates for administrative overhead (such as time cards and documentation). You can safely add 25 percent to your team leads ' estimates in order to account for this shortfall. You should automatically add this on top of the time already given you. Time estimates that seem far out of range should be questioned; it doesn ' t cost anything to ask a person if he ' s sure of that time estimate—it could've been a typo.

Many projects need a fudge factor—a percentage that you add to a time estimate in order to give yourself a comfortable zone in which to work. Some project managers recommend that if you ' re a skilled PM but your team is not experienced at project processes, you should multiply all time estimates by a fudge factor of 1.5 to 2. If you' re not an experienced PM and your team is inexperienced as well, you might want to consider a fudge factor of 3 (that is, add 200% to your estimate). In other words, if your total project estimate for a given project is 30 days, and you' re skilled but your project team is not, then you might quote a total of 45-60 days for project completion. However, if you are new to the project management process and so is your team, then you might quote a total of 90 days for project completion.

Also, be sure to add some time, perhaps 10 to 25 percent, for quality control.

Some key things to remember are that your project time estimates will be inputs to your project management software. Finish your time-estimating process before keying activities into your project management software or developing your schedule. Acknowledge that your time estimates are based upon resource availability. Also try to acknowledge how your time estimates will affect your cost estimates. If a contract software developer costs you $225/hour, an underestimation of just 10 hours means that your activity cost skyrockets by $2,250. Be careful to acknowledge the impact that your procurement process will have on time estimates.

Finally, understand that your time estimates will be affected by nonproject budget cycles. For example, perhaps your project will need to have a couple of new software developers start working on May 23, a Thursday. However, HR isn't willing to start new people every day—it' s more efficient to do paperwork and conduct orientation for several people at once. They ask that you bring in new hires only on the first Monday of a payroll cycle; the cycle begins on the first and fifteenth of each month. Because of these restrictions, you either have to start these new coders on May 20, or you won' t be allowed to bring them on board until June 3.

Let' s take time to review for a minute. You start your project by gathering the requirements and applying a metric to those requirements so that you can judge how successfully you' ve met them. You also have list of deliverables that the requirements are characteristics of.

Next you identify the various phases needed to produce a deliverable, break each phase down into its distinct activities, and then subdivide the activities into the tasks needed to finish one activity. When you finish this examination, you can turn it around into a build-up flow, like so:

As a result of this breakdown, you come up with a list of folks for each task, activity, and phase—at least one person for each—and you ask them to provide you with their time estimates for each task. Note that you have a lot of leeway in the manner that you note who the people are that are working on the project. For example, I' ve seen project plans where all the people working on a phase are mentioned in the phase section. Then, the

people who are working on an activity or task are mentioned again at those levels, like so:

Project Segment

Team

Memb

ers

Phase A

Bob,

Carol,

Ted,

Alice

Activity A

Bob,

Carol

Task A

Bob

Task B

Carol

Activity B

Alice, Ted

Task C

Alice

Task D

Ted

This shows you that these four folks are all working on the same phase, and the individuals working on the various activities and tasks are identified. Sometimes phases are listed as simple titles with no associated duration or people, just to serve as placeholders for various divisions of the project. The names are then only included in the activities and tasks.

Where there are gaps in the resource list, you' re going to have to come up with a workaround. Perhaps you talk to one of the resources involved in another task to see if they can take on an additional task. Or you might consider a contractor to fill in. Or you might have a vendor or business-partner relationship that can provide a resource.

Was this article helpful?

0 0

Post a comment