What reports do you use to track progress of several projects? In particular, what progress visualization techniques do you use?
6 Answers
Actually I can think of two approaches here.
Individual reporting for each project combined in a single place.
Tools like:
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.
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.
-
Portfolio level Kanban board looks good. It seems what I've posted below is quite similar :) Commented Apr 16, 2012 at 15:24
What do you think about this visualization?
-
+1 For creative approach. However if we talk about physical board numbers seem to be difficult to keep them updated all the time. If we think about software it's easier. However different measures would be meaningful for different projects, e.g. for maintenance projects number of bugs and SLA measures would be important while for sandbox R&D venture pretty much irrelevant. Commented Apr 16, 2012 at 15:29
-
What is important for R&D? I think nothing in general, it is just a spike that can't be predicted and measured. Commented Apr 16, 2012 at 15:32
-
The point is: it depends :) Thus the idea that you might want to show different things for different projects. Commented Apr 16, 2012 at 15:35
-
I ask quite concrete question here. Sure it depends. But what exactly YOU want to track for projects that YOU run? Commented Apr 16, 2012 at 15:39
-
Cycle/lead time for tasks. Time spent on tasks. WIP. Percent complete. Estimated completion date. Whole bunch of SLA measures. Budget spent. Coarse-grained project status. Average takt time. Percentage of value demand/failure demand. Change/improvement of most of them. Pick a few in pretty much random manner and you have an answer. Commented Apr 17, 2012 at 19:35
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.
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.
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).
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.