Mar 11, 2010 Posted by Andy Branch on Mar 11, 2010 in Project Management | 0 comments

Task Estimate Questions

Brady, one of my co-workers, will soon be interviewing a long-time project manager at BYU. The following are the questions he will be asking that he was kind enough to share with me. I thought it would be fun to address these with my own philosophy.

Before diving in I do think one point is worth making as a disclaimer. There are some important differences between PMing at an agency doing client work and PMing internal products/projects. Namely, when you’re a PM over internal projects sometimes business requs are vauge, but the budget and timelines are fixed. That’s a challenge I don’t envy and which, fortunately, we rarely deal with.

What are the specific steps you take for resources estimates on tasks?

1. Ensure we have enough information from the project sponsor. Ask the questions they haven’t thought of. Conduct initial risk analysis and run it by the sponsor.
2. Run all assumptions I make as PM past the project sponsor prior to estimating.
3. Create a task list.
4. Do my best to have the resources doing the work doing the estimations.
5. Ensure the project requirements are understood by resource.
6. Request resource to account for any tasks I may have missed and add them to task list.
7. Compile all resource estimates and “high-level” it (check it against other projects of similar scope and size and make sure nothing seems “off”).
8. Conduct formal and informal reviews with resources during and after the project for critique of estimations.

Do you have standard methodology for document estimate, actual variance?

I do use a common document we’ve created at Rain which lists tasks common to most projects which serves as a start to task lists. This document also contains a worksheet for estimating resources and skillsets required for a project necessary for resource allocation and planning.

How do you estimate resources required for tasks that you don’t have experience with?

If neither I nor personnel on staff have any experience with a needed task we do as much due-diligence as is feasible without budget (usually a few hours to a day or so depending on the project size). With our research we make an informed estimate and then simply double it.

Do you classify previous tasks and use them as references for estimating new tasks?

Absolutely. It would be sheer idiocy to do otherwise. Whether a project is hourly or not, resources are required to track their hours to the nearest half hour to specific tasks in our project management system. When we bid on projects which are similar in scope and business requirements we use these archives to inform our bid.

How do you account for padding? Managerial or individual? Do you oppose padding?

I would oppose padding more if we were having difficulty winning bids. Honestly whether or not I pad depends on how badly we need work at the time. When we have as many projects as we can handle padding on fixed-bid proposals allows us to mitigate our risk.

In general I will always pad if I or resources helping me with estimations have either never done work similar or seem unsure about their estimates. I like to be there with the resources when they are making bids and watch their body language. If they struggle or hesitate with an estimate I want to manage our risk by providing some padding above and beyond what they have provided. When resources are sketchy on estimates they almost always under-bid. On the other hand, when resources are confident with an estimate I trust them.

Another important thing which many consider “padding” but which I do not is accounting for discovery, account management, and quality assurance tasks. I subscribe to the rule of thirds when it comes to software development (with some varience depending on the type of project). 1/3d goes to discovery, design, and prototyping. 1/3d goes to development. 1/3d goes to iteration and QA.

How do you manage resource estimates when you believe they are padding their numbers?

I am very honest with resources and work closely with them in creating project bids. I ask them not to pad but to trust their instincts. I try to have them go with how long a task “feels”. Again, by watching them react to the listed and described task as they think it through I can gauge whether I need to pad their estimate or trust their confidence level. This depends, certainly, on knowing the employee well and having mutual trust which is important for project management anyway.

How do you account for a learning curve? for new technology? for new employees?

I think I covered learning curve and new technology above. Our newer employees often do not have experience providing detailed estimates and being accountable for those estimates throughout a project. I try to get them engaged in the estimation process as soon as possible so they can become skilled at it. An important part of this is helping them to go back and review days, weeks, and even month’s worth of effort from their reports so they can learn how long they take on specific tasks.

But I do not rely on new employees for actual bids if I can avoid it. I will still have them bid, but also with a more experienced employee bidding as well. Of course, it’s important to take into consideration difference in speed and skillset with newer resources vs older, more experienced resources. I will then have them compare bids and talk about and justify their estimates. I find this exercise very helpful.

How do you account for differences in employee productivity?

Differences in employee productivity is less important than work accomplished vs work estimated. Since the goal is to have the resource who will be doing the work being the one who does the estimations, the point is often moot. Gauging and learning from differences between estimates and performance is huge. But managing productivity is another blog post entirely.

How do you handle vague requirements?

If requirements must be vauge (as they often are) I do one of three things, depending on the preference of the project sponsor:

1. Pad the hell out of it so the risk on my end is managed. I want me and the team to feel confident that our numbers are so high that it will never come back to bite us.
2. Take our best and most realistic guess of what the effort will be and procure budget for 1/4th of it. That 4th will pay for the discovery and prototyping. When discovery and prototyping are complete and the sponsor and stakeholders are all happy and have signed-off, we then provide an accurate fixed bid for the remainder of the project.
3. Do the whole thing hourly. There are many tasks I refuse to take-on at a fixed bid. One of these is system-to-system integration when working with a 3rd party that has no well-documented API. We do these tasks hourly every time.

Have you had success with task estimation?

Absolutely. Since adopting this “philosophy” (which is a dynamic and not a static thing) my projects have rarely been over-budget or timeline unless there has been significant changes. Even in those cases, between either our prototyping process (my second approach to vague requirements above) and change orders, we don’t get burned by scope creep much anymore.

Do you make specific estimates or range estimates?

A client or sponsor will always hear the lowest number. I don’t provide ranges. If I have to I provide “~” in front of one number when providing a gut “range” or “scare-away” price. I want to emphasize the importance of this “scare-away” price in agency work. Often too much time is wasted with potential clients in due-diligence when what you thought was a project in the hundreds of thousands and they thought was in the thousands. A lot of time can be saved by throwing out a “gut” number first. But yeah, I hate ranges.

How often throughout the project do you review/update estimates?

Depending on which way we are doing a project (fixed, hourly, prototyped) the answer is different. If we are doing hourly (usually with a retainer agreement) client’s demand rigorous attention to reporting and so it a monthly task of reviewing and updating estimates. With prototyping there is a formal review/update at the conclusion of the discovery phase. With fixed-bids reviews are less formal. Usually they come up when a change-order is required (which is fairly common).