BigVisible Blog

I like electronic tools but have found their efficacy to be rather limited when it comes to capturing project risks and having people actively manage those risks. Often I come across Project Managers who are really good at documenting every conceivable risk but who aren’t as conscientious at proactively managing those risks. Sometimes, formal risk documents are used as a CYA mechanism instead of as a means for driving down project risk.

I found that a large information radiator for displaying project risks and issues has been well received by clients. The version I use is a simple 2×2 matrix. The two columns are used to classify items as Business or Technology related; the two rows to show whether the items are Execution or Coordination related — teams that aren’t smitten by the categories are free to change the headings to whatever makes sense in their context. Concentric rectangles denote when the effect of a risk will be felt.

Sample Risk Radar Chart

Items in the inner-most rectangle (or square or circle) identify current issues (risks that have come to fruition) or risks that will become issues within the next two sprints if not handled. The next outer rectangle shows risks that the team foresees materializing within the next 4 sprints. Longer timeframe risk items go outside the 4 sprint rectangle.

Color coding helps denote the severity/impact of the risk. Reds and Oranges affect the project more negatively than the Yellows and Greens. The Sunburst item in this case was a showstopper that was going to bring the project to a complete halt. The areas on the extreme right were for items that weren’t deemed worthy of being tracked on the risk-radar board just yet or for risks that had been taken care of.

For teams the goal was to handle risks before they became issues. Ideally, the innermost rectangle should be empty — teams should be proactively mitigating risks and taking care of them before they get into the innermost “Next 2 Sprint” rectangle.

We used large foam boards and masking tape for creating these risk-radar charts. The chart was prominently displayed in the team room and could be referred to during meetings.  The light weight foamboards made it easy for one person to carry the chart from one room to another if a meeting was being held elsewhere. Pictures taken with a digital camera were emailed to off-site participants.

Once a week, the Product Owner and ScrumMaster would meet with the development and QA managers and with business and IT stakeholders to review progress and roadblocks. During this hour long session, the group would discuss the issues and risks starting from the innermost rectangle.

This meeting served four purposes: (1) as a risk escalation mechanism, (2) as a mechanism for managers and stakeholders to remove impediments that were too big for a team to resolve on it’s own, and (3) as a mechanism for moving away from the existing one-way status reporting culture — managers and stakeholders were expected to report on progress (or lack thereof) on items they had publicly taken ownership of during the previous meeting, and (4) as a way for keeping managers from harassing the teams to “go faster”.

The reason this chart worked surprisingly well was: (1) it was always in everyone’s face and was hard to ignore, (2) managers had insight into risks and impediments and could proactively smoothen the way for the teams, (3) managers realized that teams could not go faster until the issues were taken care of.

Try it out on your next project and let me know what you think. Ideas for improvement will be highly appreciated.