Risks, Assumptions, Issues & Dependencies + Scenarios = RAIDS

We cannot truly plan, because we do not understand the future–but this is not necessarily bad news. We could plan while bearing in mind such limitations. It just takes guts.
- Nassim Nicholas Taleb (essayist, scholar, statistician, former trader, and risk analyst as well as author of The Black Swan)

An entrepreneur assumes the risk and is dedicated and committed to the success of whatever he or she undertakes. 
- Victor Kiam (American entrepreneur and TV spokesman for Remington 1926-2001)

In a start-up company, you basically throw out all assumptions every three weeks. 
- William Lyon Phelps (Yale professor, author and speaker 1865-1943)
​
A RAID log or chart is a project management tool to document and track the risks, assumptions, issues and major dependencies inherent in every undertaking. It serves at least four functions: It puts all of these identified items in one place so that they can be reviewed and incorporated into other relevant plans and documents. It provides an overview which facilitates both updating as well as inclusion of new items that were either missed or have just arisen. And fourthly, it provides a starting place for efforts to examine these RAID items with a eye towards mitigation, the development of contingency plans, and the establishment of triggering signals. This is especially important for those items that could have a high impact, while taking into account their probability and timing.

Each of these items i.e. risks, assumptions, issues and major dependencies, tend to be considered as a single item or event (i.e. a competitor is expected to launch their product first, the financing will close this quarter, the production is delayed, or the focus group requires a prototype). I recommend adding an additional category to the RAID log, that of scenarios, which better incorporate a series of interrelated events, hence the RAIDS log. A typical scenario may take a number of paths and incorporate the other items of the RAID log. A typical scenario might be a steep rise in the US-Canadian exchange rate which would effect financing, expenditures and revenue, and whether that would be a long or short-term event to be considered. 

A thorough process to initially identify, as well as periodically review and amend a project’s RAIDS log is a critical first step. Outlined below are definitions and commentary on these five categories. Some redundancy in a RAIDS log is acceptable, as the problems that can arise from omissions are far greater than managing a little redundancy.  

Risks:
Risks are events that may occur and if they do they are likely to have a negative impact on the business. Every risk should be assigned an impact level, a probability of occurring, a timeframe, and one or more leading indicators or trigger signals. Having a competitor launch a similar product before you is a risk as it hasn’t occurred yet. The impact would be high, the probability might be between 25-50%, the timeframe could be within the next 6-9 months, and detectable triggers might include press releases, increased ad spending, hiring additional sales staff, and placing large orders to key component suppliers.   

Assumptions:
​Assumptions are items that are accepted as certain or true, but lack the evidence to make them facts. Assumptions serve to speed up and simplify planning activities by providing data points that would either be time consuming or expensive to research, or perhaps are currently unknown. The problem with assumptions, is that too frequently they are subsequently found to be untrue. This can result in significant unfavourable impacts. In effect, incorrect assumptions become risks and issues! To minimize this problem, four steps should be taken: First, best efforts should be made to identify all of the underlying assumptions in a plan. This can be more difficult than identifying risks, as there is often a fine line between what is perceived as a fact and what is indeed an assumption. Second, assumptions should be assigned an accuracy level (high-medium-low) and the resulting range of impacts accessed. Third, those assumptions, that if not accurate, could have a major impact, should be recategorized and managed as risks to ensure they receive proper attention. Fourth, those remaining assumptions should be further researched or tested with the time, effort and cost expended being relative to their potential inaccuracy and negative impact. Assuming that 10% of your targeted potential customers will purchase your product in Year 1 will drive your manufacturing, inventory, staffing, and of course financials. If it’s more likely between 6-12%, that's a two-fold swing in every aspect. Recategorizing this assumption as the risks of too few sales and potential too many sales orders, might lead you to a phased launch, identifying contract manufactures who could come on line quickly, or a stocking of the upper estimate of just the critical, long lead-time components. If left as an lower accuracy assumption, market research in the form of focus groups or field trials could be considered to strengthen it.

---

Building a financial model is a valuable exercise on many levels. Not only does it provide a guide as to the estimated revenues, costs including development costs and profits, it also encapsulates the overall plan and the majority of the assumptions. A financial model incorporates a lot of timing items including the product launch and sales growth rates. It also incorporates many resource issues including cash flow, staffing, inventory build up and capital requirements. Finally, it incorporates many sales assumptions including market size and penetration, pricing, volumes and the required marketing efforts. While building a financial model, many of the underlying assumptions will become apparent. They can then be tracked, challenged and tested as required.

Issues:
Issues are current problems that need to be addressed. Hopefully, most of them arise from previously identified risks for which some mitigation or contingency planning has already been done. Each issue should be assigned an impact, which is the primary means of prioritizing the urgency as well as the effort (effectively time and cost) that should be brought to bear. If unit or dollar sales are not meeting target, increasing marketing and sales efforts, altering production outputs, or changing the pricing might be considered.

Dependencies:
Most commonly, a task is dependent on a preceding task if it can not be started until the predecessor has been completed (also termed a start-to-finish relationship). A product can not be delivered until it has been both sold and produced. The core tools and associated documentation of project management are Gantt charts, and PERT or network diagrams. A key aspect of these tools is the establishment and tracking of task dependencies. Specifically highlighting the major dependencies as well as the critical path (that sequence of dependent tasks that determine the shortest possible time required to complete the project), ensures that efforts are properly prioritized and resourced. Building and fully testing a working prototype so that it can be available for demonstrating as part of the product announcement at a major industry conference is an example of a critical dependency. As a result, this would be a top priority for the development team.

Scenarios:
A scenario is a postulated sequence of dependent events that incorporates a variety of assumptions (or variables). Scenario planning usually involves the consideration of a key question (often a high impact risk) and a relevant timeframe. From there, a list of driving forces are identified (STEEPLED external analysis is a good starting point), followed by a list of the resulting uncertainties. These are examined and a number of plausible scenarios are developed from which sets of implications, paths and risks are ultimately derived. In effect, each scenario is a story about how the project might unfold. Exploring a variety of scenarios and some possible branches of any given scenario can identify important downstream risks that may be missed by simply listing or brainstorming risks one by one. Disaster scenarios including fires, computer hacks and major spills are examples commonly explored by firms so that appropriate and detailed emergency action plans can be prepared. A scenario to be explored in a new product development project could be the limited availability of a key component as a result of supplier problems. This would raise questions as to whether a second source supplier should be qualified, or whether a strategic inventory of the component should be secured in advance.

- - -
​Having your project team develop a detailed list of items coinciding with the five components of the RAIDS log, i.e. the risks, assumptions, issues, dependencies and scenarios, as well as associated risk mitigation strategies and contingencies should significantly reduce surprises, headaches, so called “fire fighting,” and improve the overall success rate of your project. For more information on prioritizing and mitigating risks see RISK: Identification, Assessment and Contingency Planning.