Project Risk Logs are pretty well institutionalised, and we mentioned them in our last blog post. But what about Issue Logs? We've heard Issues defined as an impacted risk, an unknown question that needs answering, or just a general spanner in the works that will cause you to go off-plan.
In our experience, Project Issues pop up so thick and fast that most never even get documented. Clunky Issue tools just aren't agile enough: I recall one which required a lengthy check-out from a Config Management tool, two minutes to load, a pile of error messages to click past, then around twenty fields to complete - before starting the check in process. People just weren't interested, and just didn't bother. But it meant that during the End-of-Project Review it didn't look like there had been any problems along the way as none were documented! This had a double impact of meaning Lessons Learned couldn't be carried out to improve in future, and when questions were asked after it was all over about why the Project was inevitably late or over-budget that all the issues had been forgotten. Cue scraping about through old emails from two years previous from whichever project survivors there were.
We've considered the use of a simple whiteboard for Issues - certainly more user-friendly and will better focus attention in a single office location. But for multi-location delivery this won't work, and we still don't solve the problem of recording issues for future analysis. Other times I've seen Issue Logs emailed to everyone every day (auto-delete?)
A simplified electronic log on a share is most suitable in our experience, with minimal fields to capture the basic Issue information for action and recollection. Check out our own Project Issue Log Template that is available now! What methods have you used to log Issues and maintain focus on them on your Projects?
Stay Healthy! Project Health Check - projecthealthcheck.org
To understand why do Projects Fail and what we need to do differently to stop it happening again.