RAID – how the environment affects your project (and how to prepare your team)

When we design a project we hope everything will go as planned. The weather will be nice, the suppliers will bring everything on time, there will be money in the bank, our well-trained staff will finish everything on time and there will be a beautiful rainbow over our work site.

I’m sure we’ve all experienced this many times in our carreers. But every so often, things may go wrong. There may be errors or accidents, or simply things we hadn’t thought of or taken sufficiently into account. Or maybe we were aware that something just like this might happen, but we didn’t really consider what we could or should do in such an event. The fact is, there are many ways in which the context or the environment in which we work may influence our project. The environment in this case doesn't refer just to the natural environment. It is about any factor that can influence your project, including human factors but also political, economic, social, cultural, environmental, etc. This influence may even be positive – great! – but can be negative and it can be expected or unexpected. We must be aware of this and try and prepare for it.

When you use a logical framework-based approach, you will know about the fourth column that contains the risks and assumptions. The good thing about logframes is that they explicitely take the (potential) influence of the environment into account. When you design a project, you understand what is necessary for your activities to be succesful and lead to tangible results that add up to the realisation of the central objective (purpose) of your project. The fourth column and the first column of the logframe have an if…then… relationship: if these pre-conditions hold true then we can do our activities. If we do our activities and the next set of assumptions hold true then the activities will produce the desired results our outputs. If we have all the necessary outputs and the next group of assumptions hold true, we will realise the main objective(s) of our project. And if a final set of assumptions hold true our project will contribute to a greater good.

if...then... relationship between the last and first columns

Identifying assumptions (and risks as a kind of negative assumptions) is important to create awareness about critical success factors that are external to the project and often beyond our control. But how do you deal with actual problems that arise? What possible action can we take? Which alternatives exist? Who should take action? Who can help us? Who or what may obstruct us?

Originally the logical framework was only meant to be used during the planning stage, but gradually it became both a project design and management (including monitoring and reporting) instrument. In the same vein it’s important to consider how you will deal with incertainties and this influence from the environment not only during the formulation of the project, but also during its execution.

One interesting tool is to use a RAID log. The RAID acronym stands for Risks, Assumptions, Issues and Dependencies. LFA, PCM and RBM users will know about risks and assumptions, but RAID identifies two other types of factors: issues (problems that raise during execution) and dependencies (from others or previous projects). These elements are not only four different types of influence; they also occur during different phases of a project.

Risks are events that may have a negative impact on the project. You can try to identify risks as much as possible during the design phase. Risks may or may not occur during the execution phase and it’s therefore important to follow them up. A specific tool that is used in Results Based Management (RBM) for this purpose is the Risk Register.

Assumptions are the situations, events, conditions or decisions which are necessary for the success of the project, but which are largely or completely beyond the control of the project's management. Assumptions are identified during the design phase and at that moment you can think of ways to deal with them so your project can start up. If there are any critical assumptions, it’s possible that you won’t be able to start the project at all – unless you redesign it completely, or postpone it until the circumstances have changed.

Issues are problems that you have to deal with on the very moment they present themselves in order to ensure your project runs smoothly. Issues occur during the execution of the project. They are not things that may occur like risks, but actual problems that you encounter

Dependencies are things (output) that your project needs from another project or partner. It’s also possible that another project depends on output of your project. Dependencies can have an influence during the design phase (because your project can’t start without certain external outputs) or during  the execution phase. They can also influence the course of future projects because they depend on the results of your project.

The RAID log helps you identify possible or actual risks, assumptions, issues and dependencies and plan what action you can take to deal with the situation should it occur. If there is an unexpected issue you can describe what you did to solve for future reference (learning). A RAID log can include the following pieces of information:

  • To identify risks you use the Risk Register (see RBM). It helps you to calculate a Risk percentage based on the likelihood that the event will occur and the impact it would have on the project. Each risk must be described and the steps to take if it occurs can be described (scenario). It’s also important to be clear of who will be responsible in such an event (risk owner). There are different strategies to deal with a risk: you can try to to avoid the risk, reduce or share its consequences, try to transfer the consequences to someone else (insurance company, emergency services) or simply accept the consequences.            
  • The assumptions list includes the reason for the assumption, how you will validate whether it influences your project, how it may impact your project, how you've dealt with this assumption in the design of your project and who is the owner for this process.
  • The issues log includes a description of each issue, the impact it has on the project and how serious this is (does it threathen the realisation of the project). It’s also important to note what you did to deal with the issue (for future learning).
  • The dependencies log specifies the type and possible impact of each dependency, what deliverables you expect and when, how you will deal with the situation if these necessary inputs don't show up and who is responsible for dealing with such a situation (the owner).

If you use Logframer for your project design and management, you will find the RAID log integrated in the Details pane of the fourth column. When you click on an item in the Risks and Assumptions column you can select whether this item is a risk, assumption or dependency in the Details pane on the bottom (if it’s not visible press <Ctrl><D>).

Information for the risk register in the Details pane

Here you can register all the information you need to identify and manage risks, assumptions and dependencies. You won’t find ‘Issues’ in the list because by definition issues can’t be foreseen.

In the ‘Reports’ section of the File toolbar you can either print the risk register, assumptions list or dependencies list or export it to MS Word or Excel. The fact that you can export the Risk Register to Excel is particularly interesting, because it allows you to periodically re-assess your risks and update the list of risks as well as your assessment of the risk level and potential impact over the course of the project. This helps you maintain vigilance for potential risks and also to understand how the risk percentage increases or decreases over time. This will enable you in turn to be prepared and take appropriate action should such an event occur.

Risk register exported to MS Excel

For more information about how to work with risks, assumptions, issues and dependencies in Logframer, see this section in the Logframer manual: Managing Risks, Assumptions and Dependencies.

If you haven't already, you can download Logframer 2.0 from the download page. Logframer is open source software, is completely free and comes with no string attached.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <img>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.