RAID: Risks, Assumptions, Issues, Dependencies
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.
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: 58% [?]

Its a very relvant One, Thanx.
Excellent, clearly put things into perspective. Thank You.
thanks Steve. Keep coming back