“Tell me how you’ll measure me, and I’ll tell you how I behave” – Eliyahu Goldratt
“Tell me how you’ll measure me, and I’ll tell what damn fool things I’ll do to make the measurement look good.” – Tony Rizzo
He goes on to say:
“No amount of sophistication is going to allay the fact that all your knowledge is about the past and all your decisions are about the future.” – – Ian E. Wilson
Actuals are water under the bridge. What matters is what remains, and whether the time and money that remain are sufficient for the work that remains and its uncertainty. And when talking about internally resourced projects like most IT shops, funny money costs associated with “actual” resource or PM hours are the last thing I’d worry about in trying to manage a project. Focus on the dependencies, the time, and the behaviors, and the money will be what it needs to be.
Water under the bridge they may be. And I find that (real) actuals from previous projects can prevent some poor decisions when starting new projects.
Say you are handed a feature set, a budget and a delivery date.
If you have actuals from past projects, you can look back at projects of similar size and character and see if you’ve ever succeeded in delivering that size and scope within those constraints. If history tells you that the organization has never come close to a similar goal, perhaps you can get real about your prospects this time. Sometimes looking at the past can save you from committing to a project that has the smallest possible non-zero chance of meeting scope/date/quality goals.
Agile projects look at past actuals frequently — every iteration. In each planning session, they look at the number of story days completed in the last iateration. And they don’t sign up for more stories than they were able to complete in the last iteration. (Keith Ray has a nice article on how agile projects build feedback into the process. I hope we’ll see it in public soon!)
The hapless project manager in Shooting Yourself in the Foot could be using actuals to get real about his prospects for delivering (as Frank points out).
Why bother with all this actuals stuff? When we know that what we were able to accomplish in the past, we are less likely to commit to an impossible project in the present. Then perhaps the people how want the the project will start believing us when we say we can deliver by X date. And that’s one way to start influencing the trust dynamic in the organization.