Estimate task size to allocate resources in Microsoft Project

Task size estimates help you efficiently allocate resources in Microsoft Project. Giving your team members just the right amount of time they need to complete a task gives your project a better chance of succeeding.

This article originally appeared on’s sister site, TechRepublic.

There are two basic ways to estimate task size when creating work breakdown structures (WBS) in Microsoft Project: You can estimate task duration and then let the assignment of resources determine the number of hours of work required, or you can estimate the amount of work needed and let the assignment of resources determine the duration of the task. Either way, Project makes it easy to give your team members the right amount of time to complete their tasks—and give your project a much better chance of succeeding.

In Project, Work is the number of hours (or other time units) of effort required to complete a task, and Duration is the number of days (or other time units) during which the Work will be done. The assignment of resources sets the relationship between Work and Duration. The level of effort (or Units) assigned to the resource to do the task determines the ratio between Work and Duration.

For example, say a project manager estimates that a task will take 80 hours of Work, while another project manager estimates a different task to take 10 days in Duration. They both assign a single resource at 100 percent of his or her available time (100 percent Units) for the span of each task. Both tasks will have the same Work and Duration values, assuming both resources have a working calendar with an eight-hour day.

Project uses the formula Duration = Work/Units to govern the Work-Duration relationship. In the first task, the 80 hours of Work is divided by 100 percent to get 80 hours of Duration. This translates into 10 days, given Project’s default working calendar. For the second task, its 10 days of Duration (80 hours) will be multiplied by 100 percent to get its 80 hours of Work. If either of these tasks had been assigned a resource at 50 percent Units, the outcome would have been cut in half as well. Eighty hours of Work divided by 50 percent is 160 hours of Duration, or four weeks. This is because if a resource works half-time (50 percent Units), it will take him or her four weeks to complete 80 hours of Work.

People differ in their opinions about which method to use. Some estimate Duration, while others estimate Work. I’ve always seen this as six of one, a half dozen of the other because I estimate task size by talking with either those who have been resources on similar tasks, or the resources I know will be working on my project.

If I ask a developer, for example, how many days a task will take, he or she gives me a number based on a full day of work. This is generally somewhere near eight hours in most people’s minds. By giving me a Duration estimate, the developer is also giving me a Work estimate because, in his or her mind, one day equals a given number of hours of work—about eight hours.

From a technical perspective, it doesn’t really matter which way I go in estimating tasks. Project will make sure that, once I’ve assigned resources to the task, the numbers will stay in sync, regardless of the Units I pick. As long as my resources and I agree on the definition of a “day,” “week,” or “month,” we’ll be okay.

Let’s say a developer gives me a Duration estimate of four days. The developer and I both see a day as seven hours of productive working time. As the project manager, I’ve set the Project calendar to have days that are seven hours long, and I’ve set the working hours in the Tools | Options | Calendar dialog box to be seven hours in a day and 35 hours in a week. I enter a Duration estimate of four days. If I assign a resource at 100 percent, the Work will be 28 hours. But if I decide to assign the resource at a different Units value, Project will recalculate the Duration. If I assign the resource to this task at 50 percent, Project will make the Duration equal eight days. The real key here is to make sure that the team agrees upon the definition of a time Unit (day, week, month, etc.) and that this definition is set up correctly in Project.

Where to get estimates
This is one of the hardest parts of being a project manager. Estimates are sticky because you know you’ll be “graded” on how close they were to reality. However, the very nature of a project means that you probably haven’t done it before, or at least not something exactly the same. Here’s a list of things I always try to do in this situation:
  • Make time to meet with the project managers in your organization who have handled a project even similar to yours. Run your WBS, your statement of work, and your other specification documents by them to see if they can give you some estimate ideas. See if you can get copies of their project plans and other project artifacts for reference materials.
  • If you already know which resources will be working on your project, run the whole thing by them. Meet with them (several times if need be) to talk about the scope of the work and how much time they think it will take. This process will not only give you good estimates but also help build team morale by including members in the process. Also, if they helped make the estimates, they can’t blame overruns on you. It builds a sense of ownership that can be very valuable.
  • If you don’t have an established team yet, run your material by anyone you can find who has the skills or background you need. For some industries, there are databases available that estimate the time it takes to perform certain tasks. Check around.

Whatever you do, don’t be the Lone Ranger
Even if you’ve estimated task sizes for a project before, resist the temptation to just make up your own. This is just good policy. Project teams never like having things like task estimates imposed on them from above. Involve them in estimating their task sizes, and the whole project will benefit.