Effective project management requires an effective feedback loop—measurements of our past, current and foreseeable future performance. These metrics enable teams to make timely, informed decisions.
Unfortunately, many organizations, if they analyze their projects at all, do so in the form of post-project performance reviews. Reviews are fine, but they have some inherent flaws. The most obvious being that as a review, you’re looking at something after it’s happened—it’s a lagging metric.
Reviews are also problematic in that they are almost entirely subjective. We all bring lots of baggage to project reviews. Past experience, our field of expertise and preference for specific tasks all affect reviews. Perhaps the most simple illustration, can be seen in our assessment of time spent on tasks we enjoy versus tasks we dislike. As the saying goes, time flies when you’re having fun, which affects our perception of performance. How we feel about performance is generally skewed by a number of external factors, which conspire to make us poor reviewers of our own work.
When it comes time to review we know if the project landed on time and on budget, but other than that, a review is largely a discussion around what we feel went well, or didn’t go well; where we feel we spent too much time and where we feel we could have spent more time; what we feel were the obstacles and what we feel went smoothly. This is important information, but only when coupled with some hard, objective evidence.
Since reviews really only help us gauge project performance once the project is complete, we also need metrics, which provide us with relevant data mid-project. These real-time metrics enable us to alter course before we encounter problems, rather than reacting when we’ve already hit the iceberg.
One of the main issues with getting timely, relevant information as you’re working on something is the shear administrative effort required to generate and process it. Primitive checklist-style project management tools would require too much effort to capture the data needed and when using tools at the other end of the spectrum, reporting can be so complex only project managers with extensive experience with the tool can use it effectively. What seems to be missing is a tool that generates simple, easy to understand, real-time points of reference—where you’ve been, where you are, and where you’re going.
To do this, the tool would need substantial inputs. It needs to weigh expectations against actual performance and provide analysis. I strongly believe that any tool, which creates more work for workers, is destined to fail, and since processes/tools can not be forced upon workers, they have to make their lives easier, or they simply won’t gain traction (no matter what threats you come up with, or how many signs you put up on the wall). However, a tool, which captures working data autonomously would have the capability observe input, without adding workflow overhead.
Admittedly, that sounds a little science fiction, but in reality it’s fairly straightforward. The same basic actions that we perform during the course of any project management process could provide mountains of data, if it were captured. Adding and checking off tasks, posting comments, resolving bugs, uploading attachments, these are all examples of things we do every day, which could be monitored to generate real-time performance data, all without adding overhead to our process.
In the coming weeks, I’ll be experimenting with collecting this kind data, and using it to generate useful, real-time reporting within my project management tool. Of course, I’ll be keeping you up-to-date by posting more on the subject here.
3 Comments to “Primer: Real-time Project Performance Metrics”
Check out FogBugz from Fog Creek Software — its Evidence-Based Scheduling feature might be the sort of thing you’re looking for.
Interested to see what you uncover!
Corey: I’ve taken a look at Fog Bugz actually, it’s probably the closest I’ve seen to the kind of reporting I’m talking about. One clear distinction I would make though, is that what I’m really interested in is tracking implicit actions, whereas other tools track explicit actions. In other words, utilizing the the stuff we’re already doing to track progress, rather than adding additional steps.