ARIaD - The Basics

Often in project management it is the PM who is fully conversant with the methodology and standardised processes required to deliver the projects. How do you ensure your stakeholders understand what you are doing? On many occasions our key stakeholders have never worked as a project manager and are not familiar with the processes, jargon and terminology.

I want to explore the basics of the ARIaD. For me, a fundamental part of project management that many PMs assume is common knowledge throughout the organisation, or with clients.

ARIaD is an acronym of:

Assumptions
Risks
Issues
and
Dependencies

Being able to articulate and communicate what you mean by these is the key to ensuring they are understood and resolved by all.

Let's start with assumptions. What is a Project Assumption?t Something we make, which, if not validated might get us into hot water further down the line. It may be something we just take for granted that will stay the same, or be availale to us. It might be something we have to assume, because the answer isn't all that clear yet.

Imagine a project delivering a software deployment with bespoke development. The project team scope out the change and drafts a high level plan giving an approximate delivery date for stakeholders. The delivery date is based on various assumptions that are yet to be validated. A few examples:

• An assumption that the required resources will be available across all teams
• An assumption that there will be a test environment available at the required time
• An assumption that the bespoke developments laid out in the initiation document are achievable within the agreed costs

Try and be mindful of those that you are your team may be making unconsciously. Talk through the detail and work with the project team to document all these assumptions, analyse in further detail and have them formallly validated. I've personally made the mistake of ticking one off as validated over a cup of coffee, only to find that the guy wasn't really the right person to confirm. A few wobbly knees and sleepless nights over that one and a mistake that hopefully won't be repeated! Raise them in your team meetings, get input from your stakeholders and ensure you have agreement all round before you close one off.

Risks. Again, another project basic that is frequently misunderstood by stakeholders, especially those who do not work generally in a Project Management environment.

A risk is something that might feasibly happen that will cause you a problem on your project. It might result in the costs increasing, or it might result in missing deadlines, or it might result in not getting the desired outcome at the end of the project. There are numerous articles all over the internet (not to mention formal risk handling methods of Prince 2 etc). The basic thing you need to know about your risk? It's all in the correct wording:

1. What is the risk? e.g There is a risk that there may be insufficient test resources available due to other projects ongoing at the same time.

Yes and? So what does that risk mean to the project and to stakeholders?

2. What is the impact of the risk i.e. the problem that will happen if this isn't addressed is that we will not be able to test the product within our desired timeframe which will result in slipped deadlines and probably additional costs as resources are required to stay on the project for longer

3. How can we mitigate the probability of this risk occurring? Perhaps restablish priorities. The only way we can ensure this doesn't happen is to get the testbed booked with our name on it.

4. How can we reduce the impact if the risk does materialise? Okay. We maybe can't mitigate the probability for whatever reason. Sometimes these things are just outside our control - Insufficient budget, too few resources, our project just isn't the big priority project etc. If we can't mitigate the probability we need to mitigate the impact. By this I mean plan for *it* happening. What would this plan look like? Can we reschedule other work? Can we do our other phases any faster? Can we talk to our stakeholders and amend delivery dates without significantly impacting costs? Can we negotiate with our stakeholders for additional budget to ensure we can get the resource (assuming it can be made available) This might be in the form of a contingency plan, or it might escalate into an issue, for which you already have an agreed action plan.

It doesn't really matter what methodology you are following, whether it's a long winded waterfall, Agile, applied Prince 2 or any other formal inhouse method. Risks need to be addressed on all projects, discussed openly and regularly as part of your weekly meetings, daily scrum (as part of your release plan)


Issues. Unless you are enormously fortunate and in complete control of every aspect of your project, then issues will occur throughout the lifecycle of the project.

An issue is anything that is affecting your project here and now, or you know will definitely affect your project in the near future. Something is, or will block the success of your project and the blockage needs to be managed. The degree of which the issue might be causing a problem is dealth with below. To unblock, the issue needs to first be analysed

• Categorise. Is it a lack of resource? Is it a technical issue? Is it a problem with the design? Is it an issue with a third party supplier? Catagorising your issue will help you identify who can solve it.
  
• Identify - Identify who raised the issue and when it was raised
• Describe - Ensure you get a detailed, jargon free description of exactly what the issue is and how it is impacting your project
• Assign - Assign the risk to an owner. This person might not actually be able to solve the issue themselves, but they take responsibility for ensuring it gets resolved. This person is likely to be closest to the resources who can solve the problem and either has authority or a strong escalation route.
• Prioritise - Assign a priority status- High, Medium or Low. A high priority issue is one which will affect your ability to deliver to time, cost and quality outside your tolerance. A low priority might be a small impact that can be simply resolved.
• Resolution date. All issues need a resolution date - the date the issue must be resolved by.
  

Don't take them personally, keep calm, don't panic and don't point fingers of blame. Just keep a level head and ensure they are managed through to resolution.

Dependencies. Again, there are countless articles on the internet on the technicalities of dependency management. Basically, a dependency is something external that we depend upon being delivered for our project to be a success. For example, for our testing to even start we depend upon the freeing up of resources from another project. We might want to rollout some software that relies on another platform/version upgrade being delivered prior to our implementation.

How formal your dependencies need to be documented is largely down to the size, nature and criticality of the projects and the organisation. At the very least, they should be logged and each log comprise the following basic information.


Description of the dependency and why you are dependant upon it
Donor - The name of the project/area/team you are dependent upon and accountable owner
Beneficiary - The project(s) that will benefit from the donor delivery
Date of delivery - the date the donor will deliver their project

As your project cannot succeed without this dependency being satisfied, your stakeholdes will need to be fully aware. It makes sense to stay close to the status of the other project so you can be aware of any issues or risks that might impact their ability to deliver on the required date. Keep talking to them.

The key is correct understanding and articulation, communication and regular review.