With every project, besides all creative, technical and quality planning, additional analysis is crucial for securing the delivery on the promised date or to ensure the agency is protected against external factors.
Many times, external agency factors play a key role in the success of your project.
Facing all those issues as they came into the picture is not at all productive because they can have huge impacts on:
- your team productivity and spirit
- your profit
- client attitude and feedback
- future sales
RAID (Risks, Assumptions, Issues, Dependencies) is a great analysis that can be done for both internal and external factors of a project. It can be applied to just any project type and it’s usually a mandatory deliverable with any project these days.
If you are not doing RAID analysis on your projects, start today.
RAID can be used as well when doing the time planning of the project as it highlights important milestones that the team must be aware about.
There are multiple methodologies to create the RAID for a project and this analysis is very much dependent to the project type you are preparing it for.
As I want to be super practical I will pick a common example of a project where a RAID analysis would really come in handy.
Let’s imagine the following:
Client is a Pharmaceutical drug multinational company with multiple parallel systems, you are asked to do their e-commerce digital solution UX, Design, User Interface Development and QA. The Backend solution is managed by a third party agency (they are required to use a CMS system that your agency has not yet integrated with) and the Deployments are managed by the Client IT department.
Not to over complicate this piece, let’s asses just some of the external implications — the issues that may come up from the cooperation with other stakeholders of the project.
Let’s look at this from the helicopter. What do we see?
- the project scope is shared with another agency. Overall, your agency will not be fully responsible for the delivery. A project leader must be selected.
- Technical impact. Working with new CMS systems or new UID techniques which are not properly understood by all parties may result in chaos during the integration phase.
- Development and Staging Environments are required to be functional at all times while the project is in development. It would not be too good to loose time fixing them.
- Live Environment must be identical to Development and Staging Environments
- Resource availability.
Examples: The project spans over the summer holidays OR overlaps with other ongoing projects where some of your planned resources are also required. This means a lack of availability that needs to be known and assumed.
- Change requests are also a risk to the overall progress and delivery. Before kick-off be sure that the client is informed about the Agile process that the project will follow and discuss clear change request deadlines and processes.
- The overall project is required to be validated by a state authority (it’s the case of regulated products like Pharmaceutical drugs).
It’s important to be sure that your understanding of the project collaboration, deliverables, etc. are shared by all parties involved.
You need to lock down:
- Who leads the overall project. A Coordinator needs to be selected. Usually, the client selects one of the agencies OR sometimes he selects a third party.
- The team ways of working (stand-up, weekly meetings)
- The project coding standards
- Collaboration/comunication tools (JIRA, Confluence, InVision, Slack)
- Methodology during the integration phase — what will the role of your agency in the integration phase
- BA (Business Analysis) goals
- System performance KPI list
- Agile approach
A beneficial additional exercise to do a RACI matrix ( responsibility assignment matrix — RAM). More here.
Don’t forget the assumption list on the actual work you will deliver.
Issues differ from risks in a way that they can’t be really planned, unlike risks which might turn into issues in the future.
Ideally, if the Risks are well planed and handled, Issues will not trouble you during the project.
Still, let’s think on some real-life examples:
- one key project resource gets ill and affects the productivity of one sprint.
- Client has requested an additional module development which was not initially planned.
This is maybe the most hard part of the RAID planning exercise.
This part is crucial to show and defend the agency against any issue that may arise during the delivery process. Some examples:
- Having all contracts and POs signed and delivered is maybe the first thing you should start with when thinking on dependencies :)
- Receiving all required materials from the client is milestone. It’s an important dependency that may jeopardize your ability to kick-off the project. Don’t forget to set a deadline on that.
- Feedback is an important dependency to be considered. If the client is not responsive it could again endanger your work flow and outcome. Be sure to list that as a dependency.
- As the project timeline is constructed, the delivery of those Epics or Stories that are dependent on other deliveries could also listed as a Risk.
Clear Deadlines have to be set and communicated to the client. If deadlines are not met, the timeline must be adjusted and the client should be notified of the change of the delivery date.
This is fully applicable also in the client relationship as he needs to follow Deadlines as well.
The above is just a starter list. Try to make your list as complete as possible.
Add the RAID analysis to your project process. Allow at least 2–3 days of discovery for it and create a asset that can be shared with the client and the other stakeholders.
Learn from each done RAID. As you collect more and more RAIDs it will be more easy to forecast issues in the future.
Add the RAID to your SoW and get it signed by the client. It will be helpful.