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 12, "Tracking Progress on Tasks and Assignments."
However, planning is only the first phase of managing your projects. After the planning is completed, the implementation of the project starts—carrying out the plan that was previously developed. (pg. 257)
The big distinction between Project user segments is planning vs. tracking. I can't cite exact data but my observation is that most Project users use the application to plan their projects, but a far smaller percentage also track progress. That's a shame, as it is in tracking (and responding to) actual work that Project's feature set really shines.
Ideally, projects are implemented exactly as planned, but this is seldom the case. In general, the more complex the project plan and the longer its planned duration, the more opportunity there is for variance to appear. (pg. 257)
Recently I've been deeply immersed in the Agile framework of project management, and the bad guy of Agile is waterfall--potentially the type of highly detailed, long view plans that one might very well create with Project. I think there is a legitimate issue here. The approach we generally prescribe in the Step by Step book isn't formal Agile, but certainly not rigid waterfall either. This is a subject I'll explore more in the future.
As a project manager, you must determine what level of tracking best meets the needs of your project plan and stakeholders. As you might expect, the more detailed the tracking level, the more effort required from you and the resources assigned to tasks. (pg. 258)
I suspect one reason why many Project users do not track progress is they're turned off by the complexity of the UI relating to tracking. In the Step by Step book we take methodical approach to introducing the reader to the various levels of tracking progress, and try to illustrate the pros and cons as we go.
In a usage view, you see work values at two different levels of detail: the total value for a task or assignment and the more detailed timephased level. These two sets of values are directly related. (pg. 265)
We make extensive use of the Task Usage view in this chapter as a means of recording time-phased actuals. When you want the greatest level of detail possible, a usage view is the way to go.
Tracking a task’s actual work complete value is more detailed than entering a simple percentage complete on a task. However, neither method is as detailed as entering timephased actual work for tasks or assignments (as you will see in the next section). There’s nothing wrong with tracking actual work at the task or assignment level (or simply entering a percentage complete value, for that matter) if that level of detail meets your needs. (pg. 268)
This passage reiterates that the different levels of tracking introduce both usage differences in Project's features, and relate to different levels of communications needs. Ultimately there's no value in tracking progress if you keep the results to yourself. Tracking details add value when they are shared with resources and other project stakeholders. A key skill of project management is properly dialing in just enough tracking detail to give the team actionable data, but not too much data that the key points are lost in the noise.
Regardless of the data collection methods you might use, be aware that resources might have some concern about how their actual work values might reflect on their overall performance. You may need to communicate to resources that schedule actuals help in managing the schedule, but performance evaluation is a business management focus, not a project management one. (pg. 274)
This passage appears in a sidebar entitled "Project Management Focus: Collecting Actuals from Resources." I personally have had difficulty collecting timely and accurate actuals from resources. I learned to convey the message that actuals help us all (i.e. the entire team) manage the project, and as a project manager that's my focus--not individual performance. Ultimately each individual's performance has a cumulative effect on overall team performance in project execution, but the correct framing of the issue can go a long way in getting accurate actuals from resources.
Previous posts in the "Detailed Commentary" series:
Part 1, Simple Scheduling
- Chapter 2, "Creating a Task List"
- Chapter 3, "Setting Up Resources"
- Chapter 4, "Assigning Resources to Tasks"
- Chapter 5, "Formatting and Sharing Your Plan"
- Chapter 6, "Tracking Progress on Tasks"
Part 2, Advanced Scheduling
- Chapter 7, "Fine-Tuning Task Details"
- Chapter 8, "Fine-Tuning Resource Details"
- Chapter 9, "Fine-Tuning Assignment Details"
- Chapter 10, "Fine-Tuning the Project Plan"
- Chapter 11, "Organizing Project Details"