PM Practice: The Right Way to Track Actuals

Most project managers I know track actuals at a task (e.g., 25% complete) or duration (e.g., 4 days spent, 3 days left) level. Effort (or work) is generally left to be managed by their scheduling tool. The method you choose for tracking actuals affects the ability of your schedule to predict final time, cost, or scope. The problems come when PMs use task-level tracking (low predictive power) in order to manage a project where high predictive power is required (i.e., project milestones are 'set in stone').

Effort is the real currency of most all projects. It measures, in hours, the heads-down work performed by individual members of the project team. It is a key determinant for the duration and cost of most tasks. Project managers that track actuals at an effort level are able to sort out what is causing delays or cost overruns because their project data is more granular. When I track actuals in my projects, I can make smaller, more targeted, corrections in concert with my project team. My projects still slip (after all, we only manage risk, we don't control it), but they do so less often, and usually less dramatically (and therefore more correctable).
Tracking actuals at the effort level is just as easy as other methods. I follow these steps:

1. Each week, my team reports ATD (actuals-to-date), in work hours, for any task that was ongoing at some point during the week. I build my schedules such that each team member will typically work on 1 to 3 tasks per week.
2. For each of these tasks, my team also provides and ETC (estimate-to-complete). Obviously tasks that they completed will have an ETC of 0 hours. Steps 1 and 2 take each team member about 5 minutes a week.
3. I set up a tracking view in my scheduling tool (whatever my client needs me to use) that allows me to apply ATD and ETC to individual tasks every week. There are tons of tools that will automate this process, but even if I do it manually, we are talking 10-15 minutes every Monday morning for a team of 30 people.
4. I save my project plan, updated with last week's actuals, and begin my weekly upkeep (a tidy schedule is a defensible schedule I always say!).

I have taught several hundred project managers the nuts and bolts of this process over the years and those still in the job today couldn't imagine not tracking their actuals another way. Anyone can learn how to do this and the impact on project manager performance is a blast to watch. New project managers gain confidence because they develop a better understanding of their projects. Experienced, capable PMs get a real boost from this method because it helps them validate their intuition about adjustments they may need to make.

Agile adjustment: This practice works with Agile, though you may choose to shorten the interval from a weekly timesheet to a daily verbal report of ATD and ETC. Properly measured, tracking effort can help Agile teams compensate for deficiencies in the organizational implementation of the development method ... but that discussion is for another time.

PM Laws: Ascend the Project Knowledge Slope

One of the truisms of projects is that you know the least about your project (or product) at the beginning and most about it at the end. This fact pervades every aspect of projects and how we manage them:

• When making a decision, you will always know more tomorrow. Some decisions are improved by waiting; some benefit from timeliness over gathering more knowledge. It's not always easy to know which is which.
• Budgets and dates are usually established at the beginning when we know the least about projects. There's a good reason for estimating these early, but it does make things more complicated.
• Project documents are intended to help us ascend the knowledge slope. Docs that help teams and stakeholders to learn collectively work best. Boilerplate text doesn't help.
• You may have planned your project expertly, but it will change almost as soon as you sink your baseline. Do you have a system that helps the plan evolve fluidly in concert with your understanding of the project?

The most successful project managers I've met are the ones that run their projects with awareness that they can't know everything from the get-go. Learning and adjusting will be the norm. The ones I've coached who struggle in the job are often railing against this reality. If you refuse to baseline your plan before your requirements are signed off, you're fighting the curve, my friend.

I Like Projects Because I Like Change

Most change needs the coordinated effort of more than one person and projects are the construct for achieving results from our efforts.

By construct, I mean that the word 'project' is simply the taxonomy we use to describe a way of doing something. If someone tells you, "I worked on a big project last year," what are they really saying?

• I was a key contributor to a significant outcome?
• I was focused on achieving a goal in concert with others?
• I suffered under an inflexible regime in order to keep my job?
• What's on the lunch menu today?

Projects can generate strong emotional reactions - both positive and negative. But projects in their basic form are neutral. They are just of way of getting something done. So, how does it happen that some projects earn the nickname 'crowning achievement' where others are called a 'death march'?

I think it's because at their core projects are human enterprises. They contain all the necessary ingredients for both great (hope, dreams, ambition, conviction) and underwhelming (ignorance, prejudice, ambivalence, conviction) achievement.

Projects engage me because they hold so much promise. They can encapsulate achievement, whether it's building a beautiful house, a useful program, or a better health care system. But they're not easy. The world is chock-a-block full of processes, methodologies, tools, dashboards, and all kinds of 'techniques' to help manage projects. But still, they're not easy. That's because success in projects comes from things that are deeper than dashboards. They come from and through … us.

I've been fortunate to make a decent living helping other people's projects work better. It's fun and rewarding and it lets me get to know some pretty talented clients. I know a project team is on the right track when they let go of the idea that their success is measured by some dashboard ("if we code the status yellow, they'll stomp all over us!"), and start to visualize what they could possibly achieve. It has almost invariably been more than the team initially realized!