This week I continue the “highlights of highlights” series: I include some excerpts from the Project 2010 Step by Step chapters and elaborate on them. This week: Chapter 2, "Creating a Task List."
In Project, there are several different kinds of tasks. These include summary tasks, subtasks, and milestones. (pg. 23)
The subject of tasks in general is one where there's a big difference between the mechanics of MS Project and your intent as a project manager. Mechanically, the differences between summary tasks, subtasks, and milestones are easy to explain. In the real world of project management, however, these are very different things that serve fundamentally unique roles.
A project plan is essentially a model that you construct of some aspects of a project you are anticipating…(pg. 24)
When I first began to seriously study Project (around 1998), the "Aha!" moment when Project really started making sense to me was when I began to think of Project more like a simulator and less like a database application. A colleague of mine summed it up perfectly: "Project is a database that knows about time." I have found this explanation of Project as a simulator or modeling tool to be highly effective.
Each task has a unique ID number, but it does not necessarily represent the order in which tasks occur. (pg. 27)
I have found that some Project users really fixate on the task ID sequence. They find a task list just looks wrong if the ID sequence doesn’t align with, say, the start sequence of each task. There's really nothing magical about task ID; normally it conveys nothing more than the order in which you entered the tasks. That's all.
Think of a manually scheduled task as an initial placeholder that you can create at any time without affecting the rest of the schedule. (pg. 28)
The feature called manually scheduled tasks is a game changer for Project 2010. It's a really, really big deal. But truth be told I was not a big fan of the feature when I first encountered it. The more I've worked with the feature though, the more I've warmed up to it. My initial though was, "Why bother using Project? I could just record this kind of static and unstructured task information in Excel!" Well genius, yes exactly! My initial complaint turned out to be a great compliment. Now I can record all kinds of unstructured task information right in Project, and then flip the switch either per task or across the entire plan when I'm ready to move to automatic scheduling.
Defining the right tasks to create the deliverable is an essential skill for a project manager...distinguish product scope from project scope. (pg. 29)
This is from a sidebar called "Project Management Focus: Defining the right tasks for the Deliverable." This sidebar relates to what I regards as some of the magic pixie dust that gets sprinkled on great project managers. They have the ability to look at some desired end result and break it into component parts, and then decompose those down into well-defined and understandable work packages (or tasks). In general this focus is called the Work Breakdown Structure (WBS) and is a cornerstone of project management. Indeed WBS is so basic to project management that one valuable bit of advice I was given when prepping for the PMP exam was this: "If you're not sure what the right answer to a question is but one of the choices is WBS, pick it." Good advice.
In Project, phases are represented by summary tasks, and the tasks indented below the summary task are called subtasks. (pg. 35)
This is one of those mechanical explanations I alluded to above that turns out to be so simple to do in Project, but so hard to get right in the real-world project. It seems to be human nature to want to divide big things into smaller components with hierarchical relationships. If you like doing this, good news! There's a place for you in the world of project management! It turns out it's very hard to get right, however. I've seen many (and been responsible for some) projects where all the stakeholders could reach agreement on the desirable end result, but absolutely not agree on how to break that apart into manageable work chunks.
These two tasks have a finish-to-start relationship (also called a link or a dependency), which has two aspects:
- The second task must occur after the first task; this is sequence.
- The second task can occur only if the first task is completed; this is a dependency. (pg. 37)
Well that's the whiteboard definition of task linking with a finish-to-start relationship. We cover the four possible link types: FS, SS, FF and that strange cat SF. In a Start-to-Finish (SF) relationship the start date of the predecessor determines the finish date of the successor.
The project calendar defines the general working and nonworking time for tasks. (pg. 46)
In the book we devote a lot of pages to the mechanics of calendars and working/nonworking time. We do so because it turns out to be a pretty complex but also very useful area of Project. Managing working time effectively is one of the distinct capabilities of Project as compared to, say, Excel.
Previous posts in the "Detailed Commentary" series:
###
