All your tasks have been entered into Project and you've estimated how many man-hours they'll take (Work), or how long the Duration of each task is. That's all been your computing power. Now it's time to help Project work its magic to help you. What we're going to do today is link our project tasks within Project.
But first, there's one thing I should have told you a few entries ago, back when you were first entering your tasks into Project. I didn't realize at the time just how important it was until I started linking my tasks together, so I didn't realize I needed to share it with you. Fortunately, it's an oversight that is easy to fix. You should always have a generic task called "Start" (or something similar) and a generic task called "Finish" in your task list. Start and Finish will not be action-oriented tasks; they are anchors to hold your project tasks together. Each task on your list needs a predecessor or a successor; your Start task lets your first action-oriented task have a predecessor, and your Finish task lets your ultimate action have a successor. You don't want any of your project tasks to be left hanging on their own, without both a predecessor and a successor — this will mess up the accuracy of your project calculation. Go ahead and add the Start and Finish items to your task list if you're playing along and don't have them already.
Before you start linking your tasks, you have to schedule them all. "Wait, wait," you're saying. "Didn't we just do that?" Well, we did estimates for each project task, but we have to give them all context within the general project schedule, the start date or finish date you determined when you first opened up Project.
In Project 2010, you can manually schedule each task, which offers you some flexibility if you have a hard deadline you're trying to meet on any given task, but setting hard dates for each task can make adjusting your project down the road tricky if something comes up in the course of your project (and it always will). So for the purpose of keeping it simple, today we're going to let Project fix our scheduling for us automatically. Select your whole task list and all its info by clicking the blank header cell above the row numbers and to the left of your column headers. This operates a lot like Excel does when you want to highlight an entire spreadsheet. Click that blank cell, and it should highlight (in black) all the rows and columns in the View pane.
Once you've highlighted everything, go to the Task menu item and select the Auto Schedule button on the Ribbon.
Hey, look! Once you've given the project tasks context within the whole project by scheduling them all, Project populates the Gantt chart on the right of your screen! Never mind that I feel like I need a Rosetta Stone to really get a lot of useful information out of a Gantt chart. And never mind that my Gantt chart is not really useful until I establish some dependencies.
Well, OK, let's fix that dependency issue by linking some of our tasks. There are multiple ways of doing this, as is the case for doing pretty much anything with any Microsoft product. Dux, in his video about using Project, likes switching from the Gantt Chart view (which is what we've been using this whole time) to the Network Diagram view in order to make linking projects a more visual experience. He shows you how to do that here.
I, on the other hand, am not a very visual person with regard to diagrams and charts (which is probably why I have so much trouble getting anything useful out of a Gantt chart even after it shows dependencies). I would prefer to link my tasks the non-visual way.
In order to do that, within the Gantt Chart view, select two project task rows (select one row, and then hold the CTRL button as you select the second row), and then, in the Task Menu item, select the link button in the Schedule section of the Ribbon. It's a picture of a little chain link, handily enough. If you accidentally link two tasks that shouldn't be linked, never fear – there is a little unlink button just to the right of the link button.
How do you determine which tasks are linked? Well, basically, you're establishing the order in which things need to be done. For instance, in planning my vacation, I couldn't really book tickets until I had decided what dates I was going to be there, so I linked those two items. Booking my tickets logically follows deciding when my vacation is going to be.
And while I could pack at any time (in fact, I am already packed for my next TBD vacation! But this is mostly because I am lazy and haven't completely unpacked from my last vacation), it doesn't make sense to pack until after I've booked my tickets and made any other purchases I need to make for my trip. So I will link "pack" to the task that needs to happen just before I start packing.
For my vacation, all the items on my task list occur in kind of a linear progression. I select when I'm traveling, then I book my tickets, then I pack, then I go to the airport, and then I do all the fun airport-related stuff until I board my plane, which is the milestone marking the conclusion of my project. But for some projects, your dependencies may not be as linear as my vacation project tasks are.
For example, let's say your project requires that you secure funding. Securing funding is one of your project tasks. Once you've gotten the money, though, there are several things that can happen: with that funding in place, you can hire new staff to work on the project. You can also buy equipment that you need for the project. You can also pay for a study you must perform prior to implementing the project. Those three post-funding tasks are not linear or dependent in any way on each other — they're three parallel project tasks, each dependent on the funding being secured. So, instead of each of those three tasks being linked together one after the other in a chronological fashion (though in practice, one task may follow another instead of them occurring simultaneously), each one will be linked to the "secure funding" task. "Secure funding" is the predecessor task for each of the other three tasks.
You may also have recurring tasks that aren't necessarily dependent on previous tasks to happen first, like status meetings. You'll probably want to have status meetings before you secure your funding, as well as periodically throughout the project. Your status meeting task won't be linked to "secure funding" or to "hire new staff," though you'll probably have status meetings both before and after each of those tasks. Therefore, the predecessor to your "status meeting" tasks will be your placeholder "Start" task, and the successor will be the "Finish" placeholder, to ensure that your status meeting task isn't left adrift in your task list scheduling.
There. Now you've made an important step toward creating dependencies. You have created dependencies. We'll talk more about dependencies in the next exciting installment.