Preface
This blog post is one in a series of 10 based on a presentation I developed, “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain.”
Top Ten List
In the process of writing the Project Step by Step books (starting with the 2000 edition and continuing through the current edition) with my co-author Tim Johnson, I observed first-hand some of the problems Project users encounter. Some of these problems are straight-forward gotchas in the software, but many common problems were really about how people define, understand and practice project management. In this and the other posts in this series, I’ll guide you through each of the top ten problems new or inexperienced project managers encounter, and what you can do to help identify and address these problems.
Problem #9: Enter fixed dates instead of linking tasks
The default view in Project is the Gantt Chart, and the part of that view to the left is a table--the Entry Table by default. The table exposes several columns, each of which is labeled with a field name. In the default view you might see six or so columns. Two of these columns are labeled "Start" and "Finish" and for any given task you are free to enter a date into either or both fields, or pick a date from the handy drop-down date-picker.
TIP Click the screenshot image to see a larger view.
But let me offer you some unsolicited advice about setting the Start or Finish date values: in most cases, don't do it! I know the date fields are right there in front of you, and often you do indeed know when you think some task should start or finish. So what's the harm in just setting those dates in the Project UI? It seems so easy, even inviting. Resist, my friend! Fight the temptation.
This relationship is constraining me
Let's work through a problem to get to the bottom of this. In the following illustration I've entered my initial task list and sequenced them by entering start dates.
So far so good, right? I know when I want my project to begin (or end), and I know the durations of the tasks. Now I've scheduled them to fit within the overall timeframe I want.
Not so fast. In fact, what I've really done is apply constraints to the tasks. A constraint is something that prevents or limits the ability of the scheduling engine in Project from earning its keep. Indeed, the scheduling engine is for the most part the reason why Project fetches such a premium cost compared to, say, everyone's favorite number cruncher Excel. Project's scheduling engine can crunch date- and duration-based math problems like nobody's business.
Need proof? Quick, try this little problem in Excel--how many working days between August 2, 2010 and November 24, 2010? Did you figure it out yet? Me neither. It turns out that unless you're really good with some fairly esoteric worksheet functions and formulas in Excel, it's very, very difficult to answer such questions. This leads to all kinds of inaccuracies when people rely on a tool like Excel for calculating durations and resource capacity, but I'll save that discussion for a later post. Back to our math problem. Answering this question in Project is pretty straightforward, and I do so at the end of this post.
Daisy-chaining my way to happiness
The alternative to setting specific dates for tasks is to link the tasks. Linking tasks accomplishes a couple of important things:
· When I link two tasks, I establish a logical relationship between them. When I apply the default finish-to-start (FS) task relationship, for example, I am saying in effect that the completion of the first task (called the predecessor) logically drives or initiates the start of the second task (called the successor). Normally but not always the successor task follows the predecessor task in time.
· Make the start and finish dates (but not duration) of the successor task dynamic. As the start or finish date or duration of the predecessor task changes, that change ripples through the successor task. For a chain of linked tasks, a schedule change to any task affects all successor tasks.
Linking tasks rather than applying constraints (for example by setting start or finish dates) allows the scheduling engine in Project to most fully do its job. Here's one example how.
Let's say that I know that I need to complete the task "Hold auditions" no later than Friday, October 29 because after that date I lose access to the audition location. Although I have linked the first three tasks with FS relationships, I go ahead and select the finish date for the "Hold auditions" task:
Notice the little calendar icon in the Indicators column? I'll point to it:
Well surprise. Even though what I did was set a finish date for the task, the effect was to set a "finish no earlier than" or FNET constraint on the task. You might of expected to see a "finish no later than" or FNLT constraint, since I did specify the task's finish date, after all. But that's not how Project sees it. When I set the task's finish date, Project took that to mean that I was picking the earliest possible finish date, so it dragged the finish date to October 29, and the task's 5-week duration caused its start date to be scheduled for September 27. If I change the task's duration, it's start date will move, but the finish date will stay put.
This may be counterintuitive, but hold on it gets worse. At this point I have a project start date, three tasks linked sequentially, and the fourth task pinned by its finish date courtesy of the FNET constraint. I'll also link the remaining tasks following "Hold auditions." Let's say I'm able to reduce the duration of the "Develop script" task by a week. Great--I should be able to wrap up this whole phase of work a week earlier. After reducing the duration of the "Develop script" task by one week, I get this result:
Good news for the first three tasks, which were rescheduled. However the "Hold auditions" task remain right where I pinned it, finishing no earlier than October 29.
Of course the effect I wanted was to pull the entire chain of tasks in by one week. To do so, but still be aware that I need to finish the Hold Auditions task no later than October 29, I'll take a different tack. Undo back to my original duration, but this time I'll just link all four tasks together:
Note that even though I linked "Pick locations" with "Hold auditions," I still needed to manually remove the FNET constraint on "Hold auditions." I did so by selecting a constraint type of "As Soon As Possible" in the Task Information dialog box.
To finish my schedule compression, I'll also adjust the task relationship between "Hold auditions" and "Develop shooting schedule" such that "Develop shooting schedule" will start at the halfway point of the "Hold auditions" duration.
But I'm not done yet. To record my need to wrap up the "Hold auditions" task by October 29, I'm going to set a deadline on the task. I do so in the Task Information dialog box:
Notice the little down arrow indicator at the end of the Gantt bar for the "Hold auditions" task. Now let's see what happens when I cut a week from the "Develop script" task:
Now I get the result I expected--the chain of tasks is pulled in by one week. That deadline indicator is still sitting on October 29, though. It's a simple graphical indicator that I intend the task to end by that date.
If the task should be scheduled to end beyond the deadline date, say due to the duration of the "Develop script" task increasing, then I get a different indicator:
I'm deadline-driven
The missed deadline indicator is easy enough to spot. The most important thing though is that it leaves me, the project manager, in control with regard to how I may want to solve the missed deadline. My options include compressing task durations elsewhere, or perhaps overlapping some tasks. But it's my decision. Project handled the number crunching with date and duration values, and leaves me in charge of the important decisions.
Oh yeah. Remember the math problem introduced above?
How many working days between August 2, 2010 and November 24, 2010?
One way to answer it is to simply create a task, specify the August 2 start date, and then guestimate the duration until you reach the November 24 end date:
83 days, it turns out.
Hands-on with Project Step by Step
To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.
Gantt chart views and tables
- Project 2007 Step by Step: "Customizing Views," pg. 235.
- Project 2003 Step by Step: "Exploring Views," pg. 13; "Customizing Views," pg. 214.
Linking tasks
- Project 2007 Step by Step: "Linking Tasks," pg. 48; "Adjusting Task Relationships," pg. 137.
- Project 2003 Step by Step: "Linking Tasks," pg. 43; "Adjusting Task Relationships," pg. 123.
Setting deadlines
- Project 2007 Step by Step: "Setting Deadline Dates," pg. 160.
- Project 2003 Step by Step: "Entering Deadline Dates," pg. 144.
###
Comments