At-a-Glance Release Reports

No doubt one of your favourite program management responsibilities is roll-up reporting of all the projects in your organisation. Depending on the size of the company, this can mean you might be tracking a handful of projects, or you might be tracking hundreds of them. Setting up a simple wiki page with a high-level Gantt chart view and a table with some more details can be an effective way to present current status of these projects.





For charts I've been very happily using OmniPlan recently, but I will admit that in my ignorant, pre-Mac past I was an MS Project fangirl. Any project planning tool that has baselining functionality will do the trick. I try to minimise my use of Gantt charts because they are usually too heavyweight for most agile projects. At the program reporting level however, the feedback I've gathered is that people across the company find charts useful for giving a quick visual on when we're likely to release all our products (vs. when we thought we'd release them). This is especially true for everyone downstream of the Development teams, like the Product Marketing guys planning the launch activities, the Support team needing training on the new features, and the VP Sales who'll need to plan her next investment property purchase.

In the chart I'm showing Original Target (lighter shade) and Expected (darker shade) release dates. I use the length of the horizontal bar to indicate the estimated uncertainty in the release date range, rather than force a misleadingly precise single date when we don't have one yet. I only expose the "Actual End" and "Planned End" columns for simplicity, but obviously I'm setting the bar length via the (hidden) "Planned Start" and "Actual Start" columns. And I use the baseline feature to achieve those Original and Expected shades.

My informal (but highly reliable) reporting survey also showed that people want a few more details to support the visual snapshot in the chart. So in the table view, status is indicated by a colour, with a column for some notes, a "dogfood" column to remind everyone to do internal user testing (in addition to regular QA activities), a summary of the top features of the project with links to roadmaps and release notes, and the date of the last release of the product for reference. We currently define the status colours like this:

• GREEN means on track
• YELLOW means the target date is at risk
• RED means the target date will be missed unless something changes.

but of course these can be defined in any way that suits you and your audience. The key to reducing confusion is to define the status indicators clearly and apply them consistently across projects and over time.

I update the chart and the table each week, based on the status updates from each of the project team leads/managers. Every couple of weeks I think "I should really automate this", but each time a nerdy little voice in my head says "But this manual exercise forces you to stay current with the status & issues of each project". Still sorting that out...