Project Management

Define and schedule tasks in Microsoft Project

It's important to correctly define and schedule tasks when managing your projects. The work breakdown structure will help you organize and manage your project's tasks in Microsoft Project.

When you use Microsoft Project, it’s important to correctly define your tasks and their related information. If you define them badly, you’ll compromise Project’s usefulness for the rest of your project. It won’t matter how well you track actual work and progress. If you begin with a poorly structured plan, you’ll be fighting an uphill battle.

Correctly defining and scheduling your project’s tasks will make your job much easier. You’ll make better use of your resources and give your project a much better chance of succeeding.

I’ll describe some best practices for breaking down your project’s work into groups of well-defined tasks for your resources. It won’t make you an expert overnight, but it will get you started down the right path.

The high concepts: The work breakdown structure
For those new to project management, the work breakdown structure (WBS) might seem to be merely an outline for a project. In fact, the summary task/task relationship in Project looks like an outline for a research paper. While it does end up as a familiar organizational method for grouping your tasks, it’s more than that.

As a management concept, WBS is one of the project manager’s primary tools for ensuring that the project plan contains all the tasks that need to be done and ONLY the tasks that need to be done. This is where the scope statement or statement of work becomes more than a document. The work breakdown structure is where the project manager converts the statement of work into groups of tasks.

There are lots of methods for creating the WBS for a project. I’ll cover the basics, just to give you a taste.

For my example, I’ll look at a software development project and use a method that I call “decomposition,” though some refer to it as “top-down.” It basically breaks down the project into groups, and then breaks those groups down into smaller units, and so on until you’ve reached a satisfactory level of detail for managing the plan.

Start off by thinking about how a software project might be broken down. Often the software development lifecycle can lend a hand in creating the first breakdown by phase. Figure A shows how this first level of breakdown might look in Project. WBS 0 represents the entire project, and WBS 1-5 represent the project’s five phases.

Figure A


Now let’s look at how the Requirements and Design phases can be broken down further. Figure B shows how this might look.

Figure B


Notice the WBS field for these new elements of my project breakdown. I’ve broken Requirements into three chunks and Design into four. At this point, and really at the end of each breakdown cycle, it’s important to ask this basic question: Can all the work that needs to be done within a WBS element fall into the groups or categories of its sub-elements? For instance, in the case of my example, I’d ask myself if all the work needed in the Design phase falls under the sub-elements of Functional Design, Wireframe Mockups, Technical Design, or Functional Prototyping.

If the answer is “yes,” then the four sub-elements of Design are enough for this level. Each of these elements might need to be broken down further, but the first level under Design is complete. If, however, the answer is “no,” and there’s work required in Design that isn’t really covered by the four existing sub-elements, then I’ll need to add more sub-elements to Design to cover it.

The next step is to decide how each of these sub-elements can be broken down. This process of decomposition should continue until the resulting sub-elements are small enough in scope or duration to manage easily.

The last element is called a work package. It’s the place where I’ll assign work to resources. Figure C shows the breakdown of the Functional Requirements element.

Figure C


I may want to break down the 1.1.1 element, Gather Customer Requirements, into sub-elements if it will involve complications like flying in focus groups. Or, if the project is small enough in scope, this level might be sufficient to manage. You can see how I’ve broken down the Develop Requirements Document element into production and review tasks. It’s not likely that these elements will need to be broken down further.

Task/work package sizing and scheduling
Project managers must often follow rules about the size of a work package. This affects the WBS creation process. Many organizations have variations on a guideline called the 4/40 rule or the 8/80 rule. The 4/40 rule says that no work package (task) should be shorter than four hours or longer than 40 hours in duration. The 8/80 rule is the same, but with bigger limits. Under the 4/40 rule, any task estimated to take less than four hours to complete should be rolled up into a larger task, and any task estimated to take more than 40 hours should be broken down into sub-elements (sub-tasks). There are also variations on these rules that use a percentage of the total project duration to create limits on task size.

The reasoning behind these rules is that tasks that are too large are not only harder to estimate accurately, but they’re also more complicated to schedule and track. If you give someone a task that you estimate will take six weeks to complete, the deadline is so far out there that it’s hard for the resource to know exactly how much she has left to do. She’s not likely to realize she’s behind until it’s too late.

On the other hand, if the same task is broken down into one-week chunks, the process becomes easier. If you schedule a task to start on a Monday, you’re more likely to know if you have enough time in the week to complete it. Breaking tasks into one-week chunks also lessens the overall risk for the project. If a one-week task goes bad halfway through, you’ve only lost a few days. If a six-week task goes bad halfway through, you’re going to lose weeks of effort.

The other side is that if a task is sized too small, it’s unduly hard to track and manage. You might also make your resources feel they’re being micromanaged if you give them tasks that take only an hour to complete.

Rules are fine, but it’s best to find a method that works for you, your organization, and your projects. Project Manager and WBS will help you structure the work that needs to be done into the tasks that will make it happen.
0 comments

Editor's Picks