Visually Communicating Project Progress
One of the traits of a great PM is their ability to communicate visually – presenting the progress of a project in a single glance so that one can see if things are going to plan or not. When you look at your world through visual lens that help you solve problems in business in new ways !
Edward Tufte teaches the gift of visualizing information in a way that people can take action on.
Agile teams often place large charts and graphs in their workspaces to radiate important information. It doesn’t matter if you are developing software, delivering IT infrastructure solutions, building a house, hardware products or systems – you can visually see if you project is on track or not.
Agile teams often track project progress through ‘’Burn charts’’ (burn-up, burn-down and cumulative flow) which are a very popular way to give visibility into a project’s progress. Burn Charts are a graphical representation of the work left to be done and of the progress that has been made. The chart is typically drawn to show progress against predictions.
They are extremely simple and astonishingly powerful. They reveal the strategy being used, show the progress made against predictions, and open the door to discussions about how best to proceed, including the difficult discussions about whether to cut scope or extend the schedule.
Uses of Burn Charts
There are two primary uses of a burn charts; planning and monitoring. The burn chart represents either what is intended to be delivered or the amount of effort that is intended to be expended to deliver the agreed upon functionality. The chart represents a plan.
The second primary use of a burn chart (and maybe the most important) is for monitoring and control based on the visual representations of the plan and progress against that plan. At a glance, the chart can tell whether you are ahead or behind schedule which provides the team with the impetus for action. For example, if progress is not being made fast enough additional effort can be brought to bear or scope can be reduced. Alternately, if progress is racing ahead of the ideal line, additional work can be accepted into an iteration.
4 keys to visual charts:
I have found that if you remember the following 4 things about designing your graphs, that you will powerfully present your project progress in the best visual way possible.
1. Keep it Simple …so that anyone reading them knows they can identify why a project is well or not. Simple facts speak louder than clever algorithms.
2. Track work DONE (not in-progress)…since it is only when something is done or complete that it provides value. Think about it…..if a feature is “in-progress”, then you can’t actually use it or demonstrate it. Only when it is complete can you show it has value.
3. Be Honest and Current…don’t use charts to convince your audience of your team’s excellence or mask errors or problems. Display progress and expose problems. And don’t manipulate the honesty of the graphs, otherwise your team will stop trusting and using them to improve their work. Information more than a few days old is typically too stale to have evocative powers.
4. Let your team help….let them help choose what is graphed, so they know what others will publically see, and it is a great team building tool as well. Let them help you determine what is best to track and visually publicize to your audience. It is also a great team building tool as well.
Some samples Charts….And how to Interpret them
In project A, the dotted gray line is the target. In this example, the project is 10 weeks long. Each week we expect to complete 10% of the work and use up 10% of the budget. That’s the ideal scenario. Of course, the real world is different — that’s why we need the other two lines.
- The red line shows how much of the budget has been “burned”. It is based on actual hours worked by the team. In this example, we are three weeks into the project and we’ve burned 40% of the budget.
- The green line shows “percent complete”. It’s based on features completed so far. In this example, only 20% of the features are complete at the end of week 3.
Our sample project is in trouble. We should have used 30% of the budget to complete 30% of the features, but instead we’ve used 40% of the budget to complete 20% of the features. At least we’ve received the bad news early, while we still have time to do something about it.
In Sample 2’s project, the team’s progress (the green line) is lower than expected. We can easily see the reason: the hours worked are low too.
Perhaps team members are being sidetracked by other projects. On a more positive note, the percent completed is closely tracking the budget burned. If things continue like this, the project will be late, but it won’t blow the budget.
SAMPLE 3. Features / Functionality
After each iteration, you mark how much relative work got completed. If today is MAY, then with just two marks on the chart you can see how far slower you are moving than you expected! Yes, that may be bad news, but at least it is ‘’bad news detected early’’, as opposed to ‘’bad news detected too late to do anything about it!’‘
If you plot business value on the vertical axis instead of development effort, you get a chart that properly shows how much value you have delivered over time. Plotting both on the same chart may help remind the team about where the real business value lies in their work.
Work you can graph on a Burn Chart …
- Defects (opened, reopened, closed)
- Features / Functionality
- Hours worked
- Key Milestones
- Tests passed
- and so much more…