Project Management

Project Management Central

Please login or join to subscribe to this thread

Managing RAID in large program
Dear PM Community,

Would like to ask you for best practices to manage RAID in a large program/project.

So far approaches are not working well.

Main Issue :

RAID file is getting very big as there are many streams and people involved in the program (hundreds of items on RAID). Obviously many actions and issues are interdependent. Not talking, people are mixing risks with issues, and concerns. Overall it is getting not manageable.

It is hard to control content and make sure communication is happening between the originator and the owner of the item.

Questions:

1) How regularly should RAID be reviewed?
2) Should the review be done on the program level or first by different streams than on the program level? (I am afraid of spending too much people's time on this)
3) Should review dedicated to content or just statistics (new, closed, pending)

What are your best practices/approaches for the process?

Thank You in Advance!
Sort By:
Marek -

Would suggest you review PMI's standard for program management as well as the Risk Management standard as both documents provide some insights on this.

From a practical perspective, I found separate RAID logs at the component (e.g. project) level with a flag indicating whether visibility was needed at the program level was useful. That way, the program manager could track and communicate the items which were meaningful to program-level stakeholders such as a steering committee and the individual project managers could focus on all the items relevant to their own projects.

Kiron
...
1 reply by Marek Rudnicki
Jan 15, 2022 9:25 AM
Marek Rudnicki
...
Hi Kiron,

Thank You for this practical tip. Noted.
Yes, we do have a process that some of the RAID items can be escalated on Program Level, if not managed on Stream level, but there are so many interdependencies that almost 50% are escalated. It still makes it 200+.
We need to reduce this number.

My other idea is to limit to the bare minimum people who can post on RAID. Now 20 - I want it to be only stream leaders - 7. Not sure people will love me.

Any other practical approaches from anybody are welcomed.

PS. My role in the program is temporary to help the program to get more efficient. So this is how I found this poor RAID log situation.
Jan 14, 2022 5:02 PM
Replying to Kiron Bondale
...
Marek -

Would suggest you review PMI's standard for program management as well as the Risk Management standard as both documents provide some insights on this.

From a practical perspective, I found separate RAID logs at the component (e.g. project) level with a flag indicating whether visibility was needed at the program level was useful. That way, the program manager could track and communicate the items which were meaningful to program-level stakeholders such as a steering committee and the individual project managers could focus on all the items relevant to their own projects.

Kiron
Hi Kiron,

Thank You for this practical tip. Noted.
Yes, we do have a process that some of the RAID items can be escalated on Program Level, if not managed on Stream level, but there are so many interdependencies that almost 50% are escalated. It still makes it 200+.
We need to reduce this number.

My other idea is to limit to the bare minimum people who can post on RAID. Now 20 - I want it to be only stream leaders - 7. Not sure people will love me.

Any other practical approaches from anybody are welcomed.

PS. My role in the program is temporary to help the program to get more efficient. So this is how I found this poor RAID log situation.
Risks, Assumptions, Issues and Dependencies (RAID). I don't agree with grouping these elements together as it leads to confusion and misunderstanding. I recognise that they are related. Assumptions lead to risks, risks become issues when a risk event occurs and issues can result in new risks when not dealt with in a timely fashion.

In order to mitigate misunderstandings one has to define the terms and the process to be followed to develop and apply RAID. Assuming the terminology and process is known and consistent with all the stakeholders is a risk which invariably leads to issues - and the cycle continues.

I prefer to see RAID as a bottom up process or hierarchy - the bottom being detailed to serve the needs of the front line participants. Each subsequent level then selects the key elements that may impact their decisions and actions as well as elements that are not recognized at, or impact, the lower levels. Thus you have multiple RAID logs, each relevant to a specific management level. Everyone participates in the process but not everyone contributes directly to the high level RAID log.
...
1 reply by Marek Rudnicki
Jan 16, 2022 10:53 AM
Marek Rudnicki
...
Great Reply Peter!
This is what I was hoping.

Yes, the most confusing part is RISK. I found that the items named RISK in the log are more concerns or not understood dependencies between different streams.
They are not typical risks

Thanks
First I would say, don't let someone else's clever acronym rule your business. Like Peter, I don't find the classic RAID a useful grouping. I manage dependencies in a separate interface control process, and I find risks and assumptions an awkward and arbitrary grouping. Actions and Decisions however may be conveniently grouped with their respective RIO items.

Managing the tool and cadence are important with 200+ risks. You need to have some type of gatekeeping process to ensure the data entry is consistent, and to avoid duplication.

As for cadence, all risks should be reviewed periodically so they are not ignored. That might mean a dedicated review monthly at the program level for major risks, with half the total list reviewed bi-weekly at the project level.

Risks with high impact or near proximity should be reviewed more regularly. If a risk handling plan has Friday for a test completion that should bring the risk from High to Medium, it should be reviewed in a timely manner even if that is you the PM, calling up the risk owner to see if the test is on plan and whether it passed.

As for efficiency, Do Not use your risk review meetings as a "Voyage of Discovery" and the sole source of coordination. It should summarize the coordination that occurred Prior to the review. As the PM, my core team reviews the RIO list prior to project team reviews, ensures actions are ready to be addressed, and sets the agenda knowing what is pertinent this cycle. If the risks get elevated to the Program level, we review at the project or work stream level prior to the higher level review.

Finally, if you are only reviewing statistics, you're just playing the game of putting data on a screen to pretend you are managing. Managers will look at the statistics, nod sternly but unless you are actively managing trends, late burn-downs, etc. you are unlikely to get much positive as a result. The managers will intentionally hide the forest behind the trees to avoid personal accountability. The data should be driving actions.
...
1 reply by Marek Rudnicki
Jan 16, 2022 10:56 AM
Marek Rudnicki
...
So many good practical tips, Keith. Thanks!
For large programs I recommend only maintaining executive level & cross-functional risks and issues on the log. All other items can be managed at a project level that tends to be more tactical and localized. Additionally, similar to Peter's recommendation, I like to keep assumptions, dependencies, etc... managed separately since for large efforts it can be overwhelming and lead to "analysis paralysis."
...
1 reply by Marek Rudnicki
Jan 16, 2022 11:00 AM
Marek Rudnicki
...
This is a great suggestion. Jonathan,

My very first "cleanup" action will be to separate logs from the program level (managed by PMO) and from OpCo level (managed by stream lead). And possibly split Riks/Issues from Dependencies /Actions.

Thanks!
Jan 15, 2022 11:16 AM
Replying to Peter Rapin
...
Risks, Assumptions, Issues and Dependencies (RAID). I don't agree with grouping these elements together as it leads to confusion and misunderstanding. I recognise that they are related. Assumptions lead to risks, risks become issues when a risk event occurs and issues can result in new risks when not dealt with in a timely fashion.

In order to mitigate misunderstandings one has to define the terms and the process to be followed to develop and apply RAID. Assuming the terminology and process is known and consistent with all the stakeholders is a risk which invariably leads to issues - and the cycle continues.

I prefer to see RAID as a bottom up process or hierarchy - the bottom being detailed to serve the needs of the front line participants. Each subsequent level then selects the key elements that may impact their decisions and actions as well as elements that are not recognized at, or impact, the lower levels. Thus you have multiple RAID logs, each relevant to a specific management level. Everyone participates in the process but not everyone contributes directly to the high level RAID log.
Great Reply Peter!
This is what I was hoping.

Yes, the most confusing part is RISK. I found that the items named RISK in the log are more concerns or not understood dependencies between different streams.
They are not typical risks

Thanks
Jan 15, 2022 12:01 PM
Replying to Keith Novak
...
First I would say, don't let someone else's clever acronym rule your business. Like Peter, I don't find the classic RAID a useful grouping. I manage dependencies in a separate interface control process, and I find risks and assumptions an awkward and arbitrary grouping. Actions and Decisions however may be conveniently grouped with their respective RIO items.

Managing the tool and cadence are important with 200+ risks. You need to have some type of gatekeeping process to ensure the data entry is consistent, and to avoid duplication.

As for cadence, all risks should be reviewed periodically so they are not ignored. That might mean a dedicated review monthly at the program level for major risks, with half the total list reviewed bi-weekly at the project level.

Risks with high impact or near proximity should be reviewed more regularly. If a risk handling plan has Friday for a test completion that should bring the risk from High to Medium, it should be reviewed in a timely manner even if that is you the PM, calling up the risk owner to see if the test is on plan and whether it passed.

As for efficiency, Do Not use your risk review meetings as a "Voyage of Discovery" and the sole source of coordination. It should summarize the coordination that occurred Prior to the review. As the PM, my core team reviews the RIO list prior to project team reviews, ensures actions are ready to be addressed, and sets the agenda knowing what is pertinent this cycle. If the risks get elevated to the Program level, we review at the project or work stream level prior to the higher level review.

Finally, if you are only reviewing statistics, you're just playing the game of putting data on a screen to pretend you are managing. Managers will look at the statistics, nod sternly but unless you are actively managing trends, late burn-downs, etc. you are unlikely to get much positive as a result. The managers will intentionally hide the forest behind the trees to avoid personal accountability. The data should be driving actions.
So many good practical tips, Keith. Thanks!
Jan 15, 2022 1:02 PM
Replying to Jonathan Hanley
...
For large programs I recommend only maintaining executive level & cross-functional risks and issues on the log. All other items can be managed at a project level that tends to be more tactical and localized. Additionally, similar to Peter's recommendation, I like to keep assumptions, dependencies, etc... managed separately since for large efforts it can be overwhelming and lead to "analysis paralysis."
This is a great suggestion. Jonathan,

My very first "cleanup" action will be to separate logs from the program level (managed by PMO) and from OpCo level (managed by stream lead). And possibly split Riks/Issues from Dependencies /Actions.

Thanks!
Do you have an owner assigned to each of your risks, assumptions, issues and dependencies? And, no, I don't mean a project stream or team manager. I mean the manager who is responsible for the result. That will give you an idea of the level of details you need.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The one thing that can solve most of our problems is dancing."

- James Brown

ADVERTISEMENT

Sponsors