Documentation

This is a RACI chart specifically for project initiation documentation — who’s responsible for producing each piece of the paperwork that kicks a project off. It’s based on the chart from Project Management for Dummies (Wiley, 2011), which is one of those books people laugh at but actually contains useful reference material. This particular chart maps out who does what during the initiation phase: the business case, the project brief, the risk register, the stakeholder analysis, and so on. ...

A RACI matrix stops the “I thought you were doing that” conversation before it starts. It’s a grid. Down the left side, you list the tasks or decisions. Across the top, you list the people or roles. Where they cross, you mark what each person’s relationship is to that item: R — Responsible. The person doing the work. A — Accountable. The person who owns the outcome and gets to say it’s done. C — Consulted. The person whose opinion matters before a decision is made. I — Informed. The person who needs to know after the decision is made. Why it matters The most common failure mode on a project isn’t that nobody does the work. It’s that two people think they’re both responsible, or nobody thinks they’re responsible at all. ...

Once you’ve got your stakeholder list — the one from the stakeholder list document, filled in with names, titles, and notes — the next step is to stop looking at it as a flat list and start grouping them. A flat list of twenty names is hard to work with. You can’t send the same email to everyone. You can’t run the same meeting with everyone. You can’t make the same promises to everyone. So you split them up. ...

I picked this up a while back and it’s been sitting in my notes ever since. It’s a risk assessment checklist for software projects — the kind of thing you’d run through before committing to a contract or kicking off a big engagement. The original is a ten-page Word document with checkboxes. I’ve reorganised it here so it’s easier to scan. The categories are roughly in order of how you’d work through them: start with requirements, move through design and implementation, then look at process, people, and external pressures. ...