So we've taken a little side-trip into some necessary project management theory and definitions, but it's time to get back to working within Project. Where were we? Oh yeah, we'd made our WBS, determined the scheduling (pick start date or finish date) for our project-as-a-whole, and had begun entering individual project tasks into Project (in any order). We have them listed in the Project task list: now what?
You'll remember that, as I was watching Dux's crash course video about using Project, I grappled a bit with Fixed Duration estimates, Fixed Work estimates, and so forth. And then there was that frolic down Philosophy Lane that I'm not going to rehash now, but if you've been reading over the last few weeks, you'll see what I mean.
Now, we're back to estimating what it'll take to get each project task done. When you open a new project file, Microsoft Project defaults to the Gantt View, and the default estimate type (duration, work, unit) is Duration.
If you have entered a task list that is based on Work rather than on Duration, you can add a column for Work by right-clicking the column header, selecting "Insert Column," and then selecting "Work." That'll slot a Work column right in beside the Duration column. As you're scrolling to the bottom of the column types you're able to add, you'll note that there are approximately seven gazillion types of columns you can add to tweak the values of any task in your list. Here you begin to see how minute MS Project can be, and how flexible. But for now, let's follow the KISS principle and Keep It Simple. If the tasks you're using as a task case estimate Work (as opposed to Duration), go ahead and add the extra column, but don't be tempted to add the alluringly named "Ignore Warnings" column no matter how much you like living on the edge.
It's important to note when you're estimating based on Work rather than Duration that even if a project task will only take a short amount of time or hours, you also have to factor in whether it will be done in a dedicated fashion within that time frame. Sure, it only takes me twenty minutes to book a flight, but is it going to take me a week to find the chance to get online and book it? If a task takes x man-hours to complete regardless of other factors, you might calculate based on Work. But no matter how many hours it will take to complete your task, if there will be a delay in completing it because of other demands on the time of the person working on it –or other factors that affect when it'll get done– you may want to estimate based on Duration rather than Work.
Ultimately, when estimating for tasks, you want to paint as accurate a picture as possible of when a task will realistically be completed, because the completion of tasks is what brings you closer to your goal of successfully completing your project. It's up to you as the PM to determine the appropriate way to estimate each task (whether it falls into the Work column or the Duration column). The more accurate you are with your estimates, the more likely you will be to hit your target on the overall project. And that will make you a good and effective PM. You will look like the BAMF you so totally are when you keep hitting project targets like that.
Beside each task, enter the amount of time or the amount of work required to complete each task in the appropriate column. You can enter it right into the column itself. For instance, one of my tasks is to determine the dates of my trip. I want to give myself plenty of time to look at my schedule and decide, so even though picking the dates won't really take very long, I'm going to allot a week to do it. Therefore, I will enter my estimate in the Duration column. This column's default value is measured in days, or you can enter fractions of days (like .25 day). But you can also add in other measurements of time: typing 1 m will translate to Project as "1 minute." 1 mo equals "1 month." 1 w equals "1 week." And so forth. You can change these values if you slip, and a task that you meant would take "three months" is translated as taking three minutes in Project. Note that "weeks" are business weeks –five days– rather than calendar weeks.
Unlike determining trip dates, which will take little time but might take me a while to get to, most of my other vacation project tasks – booking the flight, packing, driving to the airport, checking in and running the security gauntlet– are going to take a fixed amount of work. So my estimates for those items will go into the Work column. It is entirely reasonable for some of your task estimates to fall in the Duration column while others fall in the Work column. The two columns work independently of each other, but like The Dude's rug, Microsoft Project will tie the whole thing together into a cohesive whole.
Now that everything has been entered into Project and you have your foundation built, you're going to be linking your tasks, which is part of how Project ties the whole room together. But this, too, is a little more involved than simply dumping a bunch of ideas onto a Post-it Note or typing them into a field in a piece of software. So next time, we'll talk about how to link your project tasks, and why you need to do it.
Jul 17 2012, 09:30 AM
Pamela Flora is currently the Marketing and Administrative Coordinator for the D.C.-area office of Innovative-e, Inc., where she has worked since March 2011. She has previously enjoyed work in both the public and private sectors as a technical writer, as well as taking the occasional freelance gig. While her current duties encompass a plethora of tasks both mundane and complex, they did not include project management until recently, when she was given the opportunity to explore project management from an in-the-trenches POV and document the experience in this blog. In her spare time, Pamela likes to hang out with her five kids, paint, write, spend quality time with her DSLR, and, now, read project management books. Though she is only infrequently on Twitter, you may follow her there just in case she feels compelled to tell you what she had for breakfast and you feel the strong desire to know: @puckish222.