How do you visualize projects progress?

Question

What reports do you use to track progress of several projects? In particular, what progress visualization techniques do you use?

Answer 1

Actually I can think of two approaches here.

1. Individual reporting for each project combined in a single place.

   Tools like:

   • Burn-up chart
   • Cumulative Flow Diagram (CFD)

   may come handy in this case. Putting them all on a single board/monitor can tell you much about projects status, although information will likely be hard to consume.

2. A better idea for me is visualization on project portfolio level.

   In this case you may use following tools:

   • Portfolio level Kanban board. While it easily shows general project status, you may find it too coarse-grained to give you meaningful information.
   • Red-Yellow-Green reporting is another very general approach, even more coarse-grained than the previous one.
   • Alternative designs. Don't stick to standard methods of showing project status on a board. Such designs may come handy especially when your process or value stream isn't homogeneous and often differ among projects.

As a rule of thumb on project portfolio level you will likely see pretty coarse-grained data. If you need more detailed information it may be a good idea to combine both techniques, e.g. attaching burnup charts/CFDs to portfolio level board (CFD as an index card possibly?). However, from my experience we rarely need such level of details to analyze project portfolio.

Answer 2

What do you think about this visualization?

Answer 3

I use very basic metrics, inspired by earned value.

At the very least I try to:

• Divide my budget amongst all the deliverables.
• List when they're expected to be done (or possibly when they are on the critical path)

Then as the project proceeds, I track progress against the schedule (only counting when things are 100% done) and budget.

You can chart progress on a simple graph. X axis is time, Y axis is cumulative budget earned. One line is plan, the other is actual.

If you have some other measure rather than effort, you can use that instead. For instance if I'm in a test, and I know I have 3 passes of 100 cases each, I create a schedule listing how many complete each day to be "on track", then track against it. I try to bake in the typical S curve: the first few days are slower, the next are very productive, and the last few test cases take a while. Again I have a simple graph of plan versus actual.

It's a No BS system to give you a measure of how things are progressing, and strips out our tendency to be overoptimistic.

Answer 4

Here is an attempt to visualize Teams availability based on their projects. Problem described by Pawel at http://blog.brodzinski.com/2012/04/project-portfolio-kanban-standard-board-not-good.html

Here we see projects grouped by Teams (so each team can work on several projects). Project have end date (it may be a challenge to nail it down, but stil we need something at least barely accurate to forecast anything). We can add planned projects and see spaces (free slots). Also we can add more info on this visualization about project progress, blocking problems, etc.

Answer 5

This is how coming tinyPM 3.0 visualizes projects portfolio (screenshot is taken from early mock, so a few details may differ in the final version, but you get the idea).

Answer 6

Each project has its own RAG status for Time, Cost, Scope, Team and Risk and a calculated overall project status. Based on this we generate RAG dashboards from our PMIS, together with some other info like actuals against budget etc. But these report status, not progress.

We have a number of reviews in our project Lifecycle (Project apporoval, enterprise, functional & technical reviews; approved for release and close), and we have a Kanban board to follow up and manage on which project is where in the process.

We still use a fair number of Gantt charts, both for individual projects as for the portfolio's. These are mainly oveviews of the duration of all projects with the major milestones. We use this to manage interdependencies and overlaps between projects (eg to manage common release dates), and to report on progress (slippage of milestones).

Each project (and project manager) uses its own ways for reporting on specific progress, and this is dependent upon the subject and/or development method, and could be things like

• Burn down charts
• Simple graphs and statistics like conversion or migration numbers from one environment or application to another, number of users trained etc.
• SPI/CPI graphs (Earned Value)
• Test coverage
• Bugs fixed / discovered …

There is no way to aggregate all these different kinds of data; earned value could be an option here but it is not yet applied on all projects or even in a consistent way.

So apart from milestone tracking, we're still far away from consistent progress reporting on an aggregate level.