Get Cute with Predecessors in Microsoft Project

I’ve known about Microsoft Project for a long time, but I’ve never really done anything with it until recently. There are several Project aficionados around the office. I’ve taken a peek here and there at their projects, but I just didn’t see the value. I don’t think I was ready for it. My team recently adopted Project as its primary planning tool, though, and so I’ve been using it more frequently. Little by little, I’m learning and becoming more comfortable with it, and I’m liking it more each day. I’m not a zealot yet, but I may very well be on my way.

The coolest feature I’ve learned about is the Predecessors field for tasks. If you’ve seen project at all, you’ve probably seen this. It allows you to say, “Task A must be finished before Task B, and Task B must be finished before Task C.” That makes sense, but it’s not all that impressive. What’s cool about it, and much less obvious, is that you can specify the dependency type for a predecessor. You can also specify lead time and lag time. These two features allow you to plan for more complex–and realistic–scenarios: “Task A must be finished before Task B, and Task C should start two weeks after Task B is completed.”

That’s all good and well, but how is any of this useful? Well, by using these different dependency types, you can pick the task or milestone that’s most important to your project and build a plan around it. Then, if the date of that all-important item changes, the rest of your plan can adjust automatically.

My team is responsible for creating small, custom projects for our customers. We have a backlog of work, and we want to schedule our development work based on a projected deployment date. We enter the deployment task first and build the plan backward from that. In order to deploy, development needs to be done two weeks before. In order for development to begin, we need a completed design. To create a design, a requirements document must be signed by the customer. And so on.

In Project, that plan might look like this. Note that the dates in italics are calculated from the predecessors.

To create this plan, I picked my targeted deployment date. The development task’s predecessor says, “The deployment task’s start date should be my finish date with 2 additional weeks of lead time.” Similarly, the design task should start so that it will be finished 1 week before the development task is scheduled to start, and the requirements task should be done 1 week before the design task begins.

Now let’s throw a curveball at the plan. Say that something comes up, and the customer needs an upgrade before I can do my deployment. I can insert a new task, and make it the deployment task’s predecessor. Everything else adjusts automatically.

That’s so awesome! I just shifted the entire project plan to reflect a new milestone that nobody ever saw coming.

Author: Adam Prescott

I'm enthusiastic and passionate about creating intuitive, great-looking software. I strive to find the simplest solutions to complex problems, and I embrace agile principles and test-driven development. View all posts by Adam Prescott