Projects and Risk Granularity

You track software project risk items on an excel spreadsheet. You know you do, don’t lie to me. Even if you have a handful of SaaS and in-house Project Management┬« suites, you still keep that one little private spreadsheet of risks and plans.

So how detailed do you go? How many items do you add into that sheet? And how much value do you get out of communicating those items at the end of the project?

How Much Detail is Too Much Detail in Risk Tracking

We need to start tracking risks before we are able to communicate them. So what level do we identify at? Depending on the sizes of your projects, your approach may be different. For me, tracking risk at each deliverable is perfect. The project level (and program) is too high; context for the risk gets muddled. The task level too granular; risks are repeated and seem arbitrary. At the deliverable, risk items fit with the story.

Level Pro Con
Program Tied to the full vision No context outside of the “100k foot level”
Project Tighter vision; a more defined “need” Still cross over many functional contexts
Deliverable Concrete need; avoiding “vision” abstraction Possible to get into implementation details
Task Can’t get closer to a set of work than this Lacking the tie to an end-game goal

How many to track. Again, your approach may differ; I limit myself to three. This is an absolutely arbitrary rule of thumb; if more than three are needed, consider re-examining the deliverable to see if splitting it up makes sense. Having a small set of risks keeps a focus when it is time to communicate to the team.

So How Much Should be Communicated

Communicate as much as a team can handle, and then a little less. The team has other concerns such as the deliverable at hand, testing, builds breaking, network oddities, and so on. With only so much time in the day, every moment taken away adds frustration. Keeping with platitudes: a little less is a whole lot more.

Never forget the concerns of context switching and partial attention. When a set of ranked items gets large enough, it eventually breaks down into “important” and “not important”. At this point some items are just ignored. The rest either spread attention too thin or create wasted time. Blowing past the schedule makes the whole exercise a moot point. The closer that list size is to zero, and mitigating as much yourself, the smoother the teams’ deliveries will be.

And the Moral of the Story Is…

Keep your risk lists small and your communications even smaller. For the most part, keep it all to yourself. Communicate only one risk per deliverable until that risk is as acted upon as is valuable. Then, move on.

Context switches are killers, and they are all over the place. The team has enough to worry about without adding another fistful of distractions. Having one item to be mindful of per deliverable, a team can be successful. They can be exceptionally mediocre spreading focus across ten.

Written by mackay on November 5, 2013 Categories: Projects Tags: , ,
Comments Off on Projects and Risk Granularity