Think of the implementation phase of an IT Project.
Exciting, right?
All that pitching, planning and preparation has led to this point! You are ready and raring to go and as you line up the road ahead, your attention will have turned to how you document and communicate within your project. At this point, you are probably thinking about initiating a RAID log. You can knock one up in Excel, one of the most effective tools you can easily create for your project … until now …
RAID logs are pretty cool!! RAID is mentioned in all project methodologies, I can’t think of a Project Manager who doesn’t use one.
However, I also can’t think of a PM who doesn’t also use other documents alongside it. Simplicity is one of the advantages of the RAID log but it is also one of its drawbacks. Risk, Actions, Issues and Dependencies are neatly covered by the RAID log, on one single document but often project teams find that they need other documents that review and record change, decisions, lessons learnt etc.
Your problems can really start when something happens in your project that doesn’t fit into one of these tabs – what then? This is where PMs either turn to a separate document or, worse still, try to keep all this information in their head. The trouble is that with everything going on across your portfolio there’s likely to be a lot going through that head of yours and, being human, PM’s forget! Truth is, what’s not recorded well cannot be monitored, reviewed and acted upon.
Even when things are well recorded on separate documents, maintenance of these many documents can be confusing for clients and stakeholders and it is often in this confusion that mistakes can occur that leak value.
So often, a RAID log doesn’t always give a full and accurate picture of the status of the IT Project.
Many Project Leaders and CIOs said that they needed something more RADICAL.
Appropriately, together with my colleagues at Stoneseed (the IT Project Management, Technical and Service Delivery specialists), we streamlined the management of project related documentation into one RADICAL log.
Let’s break it down;
Stoneseed’s RADICAL log covers;
R – Risks
A – Actions
D – Dependencies
I – Issues
C – Changes
A – Assumptions/Decisions
L – Lesson Learnt
The advantages are many, but chiefly;
1 – Having one document works better for the client …
… and it works better for you. Rather than updating various documents, the RADICAL log gives you real-time transparency. To have all project related info in the same place, a holistic overview provides you with the opportunity for a regular look at everything! It is a living and breathing single document rather than a hunt for information through loads of documents
2 – Using one document means that events are MORE likely to actually get recorded
On this, a Project Manager friend compares RAID logs to when you put the bins out. He says. “We have different bins for recycling paper, card, plastic, glass, garden waste, etc. The other night I had some rubbish that I couldn’t fit into one of these categories! I agonised for a few minutes and then reluctantly threw it into the general bin. In many projects, this has been what has happened to, for example, a valuable lesson that has been learnt. Where do you document that? It’s not a risk or an action, neither is it a dependency nor an issue and yet paradoxically, a lesson learnt could be all of these! So, traditionally, lessons have ended up in the RAID log equivalent of our green bin and have been missed by other project team members.”
3 – You declutter each category
I was asked to help a project team with a floundering project last year. The first thing we did was look through the recorded documentation for clues – from project charter to the delivery into service plan, everything seemed meticulously prepared. Then, we looked at the RAID log and oh my days!! Each category was pages and pages long giving a very unclear instant picture of the health of the project.
At RAID review meetings the team ran through the whole document starting with the risk section which, from memory, was about seven pages. Now, many of the entries were not really risks – more assumptions or concerns that fell into a bit of a RAID grey area. However, because of the RAID methodology, there was nowhere else for the team to register these “grey area concerns” so they had been lumped into ‘risks’. The result was that when the team met on a weekly basis, they only had time to chat through a couple of pages of the whole RAID log (all risk – i.e., stuff that might never happen) and there was insufficient time for proper consideration of actions, issues and dependencies – the real day to day life of the project.
Of course, better prioritisation would have helped. Even using a RAID log there were things this team could have done better. Low-risk projects require that the team spend less time discussing risks versus, for instance, issues, there was a failure in the implementation of this teams RAID log. That said, filtering log entries further using the RADICAL approach means that only bona fide risks make it onto that part of the spreadsheet because there is place elsewhere for grey area concerns.
4 – RADICAL improves response quality
The items in each of category of a RAID log necessitate different follow-up methods. The difference between an “issue” and a “risk”, for example. The former is a cast iron problem – it’s something that needs action, perhaps changes and there will be lessons that can and should be digested. A risk, conversely, is a potential problem, effectively a problem that hasn’t happened yet – it still needs attention, solutions that may never be used must be brainstormed but in many cases, action is not required. On a standard RAID log the results of these brainstorms can get lost at this point – where do you log decisions for future reference if the risk becomes a reality? The RADICAL log provides a natural place to register these decisions.
5 – RADICAL makes you think about the project as a whole.
The RAID log is a brilliant tool and it really focusses your mind on the things that you have entered into those four categories. This can be a problem too. If you were told to notice how many vans, buses, cars and lorries you saw on your commute into work, every time you saw a vehicle from this category your subconscious mind would notice. You may arrive at work having not noticed all the motorbikes, milk floats and tractors you passed.
Much of your project brilliance comes from when your primary attention is focussed elsewhere, that is to say, that your eureka moments tend to come from your subconscious mind as opposed to when you go looking for them. When you limit your main project log to the four categories of a RAID log (and jot down other project events in separate documents) you train that part of your brain to limit awareness and thinking to Risk, Actions, Issues and Dependencies.
Using a RADICAL log extends your project awareness and encompasses a more holistic set of performance criteria.
Having one document, that is living and breathing, means you are always working on it and are, therefore, always aware of what is going on – everywhere!!
In conclusion, it is appropriate that this new approach is called “RADICAL” – project teams using it for the first time say this is exactly how the results feel. It’s exciting! To return to my opening sentence, where I invited you to imagine the implementation phase of an IT Project, exciting is exactly how it should feel. Right?
Leave a Reply