Defining RAG statuses

In my work I come across a lot of attempts to explain in simple, one-word ways what the status of a piece of work – usually a project – really is. Much the most popular is the ‘traffic light’ system, or ‘RAG report’ as it’s known around across the IT industry. It’s a great idea: simple, clear and apparently quiet unequivocal.

The only problem seems to that in many organisatons the very definition of Red, Amber and Green is usually, frankly, quite irrational.

A fairly representative set of answers to the question ‘What do RAG statuses actually mean?’ can be found here: http://www.linkedin.com/answers/management/planning/MGM_PLN/186467-1517184. However, there is surprisingly little on the web about this topic, so here are my current thoughts on defining red, amber and green. Nothing radical, but a little more consistent and logical than some of the ideas I have seen floated, especially in the companies I have worked in.

The first question that needs to be answered is what exactly ARG reports are for. If you look at most organisations’ RAG criteria, they are generally defined in terms of percentages or absolute numbers. For example, if a project budget looks like going over by 20%, it’s a Red. I don’t understand this approach, especially in a project-based organisation. One of the basic features of any intelligent project governance approach is to define project-specific tolerances t reflect the project-specific circumstances, known risks, and so on – not to treat them all as though they were peas in a pod.

So when project A is 20% over budget, that may indeed be disastrous, because its agreed budget tolerance is 10%. But project B, which has always been expected to need more re-financing at some point, has a tolerance of 30% (yes, such projects do exist), so overspending by 20% is not, by itself, cause for concern, and certainly not cause for trumpeting a disaster from the rooftops.

So what – or, more precisely, who - are RAG reports for? First and foremost, they are not for everyone. By and large, they are for people who a) know the basic parameters of the project, including its tolerances for budget, delivery, and so on; and b) are in some sense accountable for the project’s success, or at least need to understand its prospects for success. In other words, RAG reports are aimed at people like the project board, quality managers, your PMO and so on.

So what do they need to know about a project that can be usefully and meaningfully communicated in something as simple as a single colour? Really it’s very simple: Do you (the report’s audience) need to do about this work?

So the message the RAG status needs to convey to the reader:

• Green: Everything’s fine, you have more pressing things to worry about, go away.
• Amber: I have problems, but I’m pretty sure I can fix them with what I have available. So nothing to actually worry about yet, but you probably need to keep an eye on what happens next.
• Red: I have real problems and I can’t solve them with what I have available. YOU NEED TO DO SOMETHING.

Hence the RAG definitions I would recommend:

• Green: All aspects of the project are fully under the PM's control using only the project's authorised plan & arrangements (e.g., budget, dependencies, resources, etc.).
• Amber: Additional actions are required, but can be successfully managed within the project's authorised capabilities & tolerances.
• Red: Cannot be resolved within the project's authorised capabilities & tolerances. Requires escalation.

These are very general descriptions, of course, though none the worse for that. By being so general, they make it easier to achieve the consistency that is the basis of good quality management. But at the same time they are probably too abstract (I would not say vague) to be easily sued by busy project managers who aren’t much inclined to debate the finer subtleties of their project’s status.
So in addition to these high-level definitions, here are a few definitions of more detailed RAG statuses, as they relate to particular areas of project management. They are pretty useful tests of the overall status, but always bear in mind that the ultimate test is the above core definitions.
Finance
Green:

• The project's current budget is sufficient for the project, and is expected to remain so.

Amber:

• There are outstanding changes that have yet to be budgeted for.
• The PM does not maintain a record of expenditures.
• Actual and forecast expenditure have not been reviewed/reconciled since the last report.
• The authorised budget is currently being challenged.
• The project is forecast to overspend (including tolerance) but there is a credible path to recovery.

Red:

• The project is forecast to overspend (including tolerance) and there is no credible path to recovery.
• Finances were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.
• The project (or stage) has mobilised without budget authorisation.
• The project is overspent (including tolerance).

Scope & governance
Green:

• The authorised scope is correct, is authorised, meets stakeholder expectations, and is expected to remain so.
• The current governance meets the project's needs, is within our governance framework, and is expected to remain adequate.

Amber:

• The project is not explicitly aligned with an authorised business goal and/or has moved from baseline scope.
• There is at least on open & unauthorised change request (CR).
• Cumulative impact of CRs exceeds original tolerance.
• The authorised scope is forecast to become invalid (e.g., known change in business strategy) but there is a credible path to recovery.

Red:

• The authorised scope is forecast to become invalid and there is no credible path to recovery.
• Scope & Governance was Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.
• The project has started without an authorised scope.
• There is no Project Sponsor/Senior supplier/Senior user on your project board.
• The authorised scope is no longer valid.

Schedule
Green:

• The currently authorised plan and arrangements are sufficient to assure the successful delivery of the project as a whole.

Amber:

• Plan updates are needed to reflect expected changes in activity, scope, CRs etc.
• The project plan has not been revised since the last report.
• A critical path product/milestone has slipped/is forecast to slip, but there is a credible path to recovery.

Red:

• A critical path product/milestone has slipped/is forecast to slip, without a credible path to recovery.
• Schedule was Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.
• The project (or stage) has started without an approved plan.
• Unfinished work that should already have been complete has yet to be rescheduled.
• Work is underway that is not on the authorised plan.

Resources
Green:

• The current stage has named, agreed resources and the resource requirements for the project as a whole are agreed.

Amber:

• The plan includes over-committed resources.
• The project lacks (or is forecast to lack) resources needed for successful delivery, but there is a credible path to recovery.

Red:

• The project lacks (or is forecast to lack) resources needed for successful delivery, and there is no credible path to recovery.
• Resources were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.
• Plan contains tasks without predecessors or successors.
• Plan contains tasks in the current stage without assigned resources.
• The plan for the current stage is not fully resourced.
• The plan for the project as a whole does not identify at least resource types.

Risks & issues
Green:

• All known risks and issues can be managed within the current project arrangements & capabilities.

Amber:

• At least one severe risk/issue is unlikely to be resolved as planned.
• The project has escalated at least one risk.

Red:

• The project has no effective risk/issue log.
• Risks & Issues were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.
• The risk/issue log has not been reviewed since the last report.
• At least one severe risk/issue is unlikely to be resolved as planned.

Dependencies
Green:

• All dependencies for the project as a whole have been formally defined and agreed.

Amber:

• Not all dependencies for the project as a whole have been formally defined.
• Not all dependencies for the project as a whole have been formally agreed on both sides.
• An external dependency on the critical path has slipped (or is forecast to slip), but there is a credible path to recovery.

Red:

• Dependencies were Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.
• An external dependency on the critical path has slipped (or is forecast to slip), and there is no credible path to recovery.
• Not all dependencies for the current stage have been formally identified and agreed with the responsible managers.
• The project plan does not identify all external dependencies and deliveries.

This multiplicity of criteria raises a key point: how many RAG statuses should your project have? Personally, I would strongly advocate using several RAG indicators at once. This not only gives your readers some idea of what questions they should be asking next, but they also allow organisations such as quality management or your PMO to compare reports from all their projects to identify hotspots and bottlenecks in the existing process that would perhaps benefit from a little company-wide improvement.

Exactly which areas you chose to RAG is up to you, of course. But what ever they are, they should be the areas you regard as the best indicators of project success and failure. That’s why I tend to start with the set above: in my experience, it is because dependencies and resourcing and all the rest tend to be the areas that drag a project under. You should chose your own, and test them every six months or so to see whether trends in individual RAG statuses did indeed predict success and failure. A few quick statistical tests using Excel is all you need (though what you use to replace unhelpful tests or unexplained failures is more speculative – a bit of an experiment).

Of course, this leaves a very important point unclear. If one particular facet of my work – the dependencies, for example, or the risks – is red but the rest are green, how do I calculate the overall status?

It is very tempting to fudge things here. If it’s mostly Green with just one Red, can’t we take a sort of average and call it Amber? No, we can’t – and the reason is simple. All the RAG criteria suggested above are individually capable of wrecking your project. Or if they aren’t they should not be on your list of questions. So if any of them is Red, the project as a whole is Red too.

One more detail. All the above RAGs are based on objective information (though no information in business is safe from manipulation). But there is one area of subjecting knowledge this leaves out: the manager’s own expectations of success. This is an important factor: a project manager faced with reds and ambers but who still expects to deliver as planned either has something interesting to tell you or needs to re-learn the basics of project management. Either way, I always include a ‘deliverability’ RAG – the PM’s assessment of how likely they are to succeed. The basic definitions of each colour are the same, and here are a few things PMs should ask themselves when setting their deliverability RAG:
Deliverability
Green:

• You are confident that the project will deliver as planned and authorised, without disproportionate risks.

Amber:

• You are not confident that the project will deliver as planned and authorised, but there are viable methods for recovering from this.

Red:

• You are not confident that the project will deliver as planned and authorised, and there are no viable methods for recovering from this.
• Deliverability was Amber in the last report and no recovery plan has yet been agreed to return those particular problems to Green.

I have found this a very useful and workable system, even down to the fact that it makes the supporting tools really easy to build. It takes practically no knowledge of spreadsheets to calculate the overall RAG status of a piece of work based on this system. No complex look-ups of percentages of values or conditions: if it’s red down below, it’s Red on top. Simple, effective, and above all else it tells its audience exactly what they want to know – What do I need to do?

Free stuff - no, really

After a long absence, here we are again. Part of the time away has been spent creating a new website, which will be of little interest to most people except for the Downloads section.

Unlike most such pages, this one really is designed to give you free stuff, not just adverts for myself. Knowing full well that this is good stuff (well, good enough for other people to pay me for it) and not wanting to let it fall into oblivion, I thought I’d just give it away. Really.

Right now it has tools and training materials for lessons learnt systems, stakeholder management, various aspects of methodology, and so on.

I plan to add to it occasionally. The main areas will be methodology, quality, and governance, but I have a good deal else. And if you have any requests, I may have something I could post just for you.

How good is DSDM?

I recently initiated a discussion on LinkedIn entitled How good is DSDM? Although there was (unsurprisingly) a consensus that DSDM was A Good Thing, we were collectively unable to come up with much hard data until Jennifer Stapleton – a past Technical Director of the DSDM Consortium – kindly offered me some data from Xansa (bought by Steria in 2007) and British Airways. Xansa’s data is especially interesting, as it covers a number of clients (including BT) and Xansa was, at that time, the world’s largest DSDM practice.

The gist of the data is that DSDM offers huge improvements in productivity, team size, delivery time and project quality. Here are the basic graphs (not as contemporary as I'd like, but still solid data):

Moving to Agile - Identifying the truly essential documentation

A crucial feature of migrating to Agile is identifying the irreducible documentation needed to support the process. For many Agile practitioners the very notion of a fixed documentation suite will raise their hackles, but there are many stakeholders, not all of whom are not directly involved in the delivery process, but all have interests that must be taken into account.

To name only the most obvious, there are three general classes of stakeholders, each with their own distinct information needs:

1. The delivery team itself
2. The business
3. Operations, compliance and support

These groups are already often poorly served by waterfall processes; the risk is that Agile’s understandable and largely justified desire to take an axe to the great mass of pointless documentation will result in them being served still worse. So…

The delivery team

Well, obviously. And generally speaking the Agile assumption that there is, by default at least, no need for internal project documentation, holds good. Why would I need to write down what I can tell everyone in a tenth of the time? Why write down anything at all if its lifetime is likely to average 15 days?

But less obvious, is it in fact the case that they need nothing? In very simple projects, yes, it usually is, but in a more complex programme – for example, a dozen Agile workstreams flowing into a common integration/release cycle – they may well need a good deal more. The PM is likely to be unavailable (doing programme-level duties at meetings and forums) and when they return to base, unable to convey everything by word of mouth.

Then the standard criterion applies – fitness for purpose. But in a project of any significance (size or importance), that rule is unlikely to result in their being no documentation at all. Add to that the other reason why documents exist – because the project is innovative, organisationally complex, heavy with technical or regulatory content, and ‘pure’ Agile starts to look a bit thin. Absolutely never create more documentation than are strictly needed, but don’t assume that the minimum set is zero. That is usually wishful thinking.

Business stakeholders

Yes, a properly empowered business rep should allow you to dispense with almost all external review and approval, but even in the most benign environment, there are likely to remain yet higher level reports. Much as most of us would like to dispense with this too (why don’t they just have faith in us?) but ultimately projects exist solely because they serve the interests of the organisation as a whole, and someone up there really does need to know what you are up to. So there is all but bound to be some form of reporting.

However, taking a constructive approach to this can also encourage those to whom reports are due – PMOs, line managers, HR, finance, direct reports to senior stakeholders, etc. – that they don’t really need the detail they are probably accustomed to. Reporting strictly by exception is the starting point, as it is that, rather than no reporting at all, which is the true corollary of empowerment. Using the move to Agile to rationalise reporting isn’t a bad idea either.

Operations, compliance and support

Now we come to the groups who are most in need to solid documentation and most likely to be neglected. In many organisations the needs of operations, service transition and support teams are already poorly met, and Agile is unlikely to do them any favours. Nevertheless, it is crucial that their needs are met, and these go far beyond touching base with them or even having them represented on the project. They will spend far more on the delivered system than the developers, and the better equipped they are to manage the delivered solution, the better for everyone.

Operations, compliance and support will make up the great majority of all but the most superficial IT projects (e.g., throwaway web pages or transient rate changes), and their needs are not only substantial but also penetrate deeply into the heart of what is being developed. They all need to be consulted about the original requirements (e.g., to define SLAs) and strategy (e.g., to ensure sustainability), they all need early warning of what, functionally and technically, is coming down the track, they all need to know what exceptions have arisen as the original requirements/backlog is progressively shaped and re-shaped, and they all need to be aware of the (now multiple) schedules for release.

Conclusion

So what does this all add up to?

1. There is a very great deal of documentation that genuinely can be thrown away – and good riddance. It adds nothing but dead weight to the project and should be discarded whenever possible. Which is remarkably often.
2. Quite a lot of other stuff needs to be transformed. It is very likely that groups such as administrative functions (PMOs, HR, finance) will have to change the way they think about projects and how they are reported on, but it is unlikely that they will eschew reporting altogether. Nor should they. Likewise for business stakeholders – they need to assign real power to their business representatives within the project, but they are unlikely abandon all visibility. And given their responsibilities, how wise would it be?
3. Finally, there are those who will need what they have always needed. But if you don’t give operations and support what they need, they probably won’t notice much: by and large they aren’t getting it now either.