RAID is a abbreviated name for very important aspects of project time schedule. These stand for Risks, Assumptions, Issues and Dependencies. Everything that fall under these categories must remain top of the mind items for you during the life cycle of the project. One of the surest ways of keeping them on the top of your head is to create documents of the concerns. One quick way to keep it forever in front of you is to have laundry list of the items and keep them in front of you. Share the concerns with your team mates as well as stakeholder higher up. The documents will spell out the concerns for every one of them. Communicating with them, sharing with them keeps the issues on top of their mind map too. Anyone foresees a problem you get an early warning and multiple minds looking at the concerns is obviously better than one.

Risks

Anything that can cause the outcome of your project to fail or get the outcome degraded is a risk. For example, the supplier of a critical component may be in financial trouble and that’s a risk. You have to document all of these risks of course, spelling out problems makes the dimensions of a problem quite clear. Just documenting the risks is not enough.

You have to plan on how to overcome risk if they do happen or a risk mitigation plan. Risk mitigation for the high risk component supplier may be to develop a relationship with another supplier who may be expensive/slightly less in quality levels etc. In case of the company actually going down you have an alternate source which may need a little trade off in terms of cost or quality.

Assumptions

One of the reasons for emphasis on documentation is it tends to let you see where assumptions are involved. Documents must spell out the same. Estimate with some underlying assumption can be disastrous for your project if the underlying assumption is overlooked. Real consequence of making unstated assumption can be understood starkly if we were to sell it as ass-u-me.

Issues

This is the head under which you must consider all the aspects that are not categorized under the risks, assumptions and dependencies and could affect the outcome of your project. Like with these other categories of concerns you must remain aware of the issues consciously so that they do not become a show stopper. Being pro-active is always useful and gives you time to act prior to a problem actually happening.

Dependencies

Time schedule management must take into account all the dependencies. These may be of several forms. One direct dependency could be that the start of a task in your plan may depend on the outcome of another task. This could be internal dictated by the requirements of your own project. If you are party of a larger project, this could be an external dependency and would depend entirely on how well this external task is executed. Availability of resources also may be affected by dependencies if the resources you plan to use are engaged in some other activity.

RAID is a abbreviated name for very important aspects of project time schedule. These stand for Risks, Assumptions, Issues and Dependencies. Everything that fall under these categories must remain top of the mind items for you during the life cycle of the project. One of the surest ways of keeping them on the top of your head is to create documents of the concerns. One quick way to keep it forever in front of you is to have laundry list of the items and keep them in front of you. Share the concerns with your team mates as well as stakeholder higher up. The documents will spell out the concerns for every one of them. Communicating with them, sharing with them keeps the issues on top of their mind map too. Anyone foresees a problem you get an early warning and multiple minds looking at the concerns is obviously better than one.

Risks

Anything that can cause the outcome of your project to fail or get the outcome degraded is a risk. For example, the supplier of a critical component may be in financial trouble and that’s a risk. You have to document all of these risks of course, spelling out problems makes the dimensions of a problem quite clear. Just documenting the risks is not enough.

You have to plan on how to overcome risk if they do happen or a risk mitigation plan. Risk mitigation for the high risk component supplier may be to develop a relationship with another supplier who may be expensive/slightly less in quality levels etc. In case of the company actually going down you have an alternate source which may need a little trade off in terms of cost or quality.

Assumptions

One of the reasons for emphasis on documentation is it tends to let you see where assumptions are involved. Documents must spell out the same. Estimate with some underlying assumption can be disastrous for your project if the underlying assumption is overlooked. Real consequence of making unstated assumption can be understood starkly if we were to sell it as ass-u-me.

Issues

This is the head under which you must consider all the aspects that are not categorized under the risks, assumptions and dependencies and could affect the outcome of your project. Like with these other categories of concerns you must remain aware of the issues consciously so that they do not become a show stopper. Being pro-active is always useful and gives you time to act prior to a problem actually happening.

Dependencies

Time schedule management must take into account all the dependencies. These may be of several forms. One direct dependency could be that the start of a task in your plan may depend on the outcome of another task. This could be internal dictated by the requirements of your own project. If you are party of a larger project, this could be an external dependency and would depend entirely on how well this external task is executed. Availability of resources also may be affected by dependencies if the resources you plan to use are engaged in some other activity.

RAID: Risks, Assumptions, Issues, Dependencies

August 13, 2009
By

RAID is a abbreviated name for very important aspects of project time schedule. These stand for Risks, Assumptions, Issues and Dependencies. Everything that fall under these categories must remain top of the mind items for you during the life cycle of the project. One of the surest ways of keeping them on the top of your head is to create documents of the concerns. One quick way to keep it forever in front of you is to have laundry list of the items and keep them in front of you. Share the concerns with your team mates as well as stakeholder higher up. The documents will spell out the concerns for every one of them. Communicating with them, sharing with them keeps the issues on top of their mind map too. Anyone foresees a problem you get an early warning and multiple minds looking at the concerns is obviously better than one.

Risks

Anything that can cause the outcome of your project to fail or get the outcome degraded is a risk. For example, the supplier of a critical component may be in financial trouble and that’s a risk. You have to document all of these risks of course, spelling out problems makes the dimensions of a problem quite clear. Just documenting the risks is not enough.

You have to plan on how to overcome risk if they do happen or a risk mitigation plan. Risk mitigation for the high risk component supplier may be to develop a relationship with another supplier who may be expensive/slightly less in quality levels etc. In case of the company actually going down you have an alternate source which may need a little trade off in terms of cost or quality.

Assumptions

One of the reasons for emphasis on documentation is it tends to let you see where assumptions are involved. Documents must spell out the same. Estimate with some underlying assumption can be disastrous for your project if the underlying assumption is overlooked. Real consequence of making unstated assumption can be understood starkly if we were to sell it as ass-u-me.

Issues

This is the head under which you must consider all the aspects that are not categorized under the risks, assumptions and dependencies and could affect the outcome of your project. Like with these other categories of concerns you must remain aware of the issues consciously so that they do not become a show stopper. Being pro-active is always useful and gives you time to act prior to a problem actually happening.

Dependencies

Time schedule management must take into account all the dependencies. These may be of several forms. One direct dependency could be that the start of a task in your plan may depend on the outcome of another task. This could be internal dictated by the requirements of your own project. If you are party of a larger project, this could be an external dependency and would depend entirely on how well this external task is executed. Availability of resources also may be affected by dependencies if the resources you plan to use are engaged in some other activity.

Popularity: 46% [?]

Tags:

3 Responses to RAID: Risks, Assumptions, Issues, Dependencies

  1. Umer Zia on January 5, 2010 at 6:47 pm

    Its a very relvant One, Thanx.

  2. Steve Cowell on May 25, 2010 at 8:01 am

    Excellent, clearly put things into perspective. Thank You.

Leave a Reply

Your email address will not be published. Required fields are marked *