Architect Toolkit RAID Analysis

In this article, I will share one of the essential toolkit that should be used as soon as a project starts. It is RAID which stands for Risks, Assumptions, Issues and Dependencies.

In my experience, risks and issues related to architecture design that occurred in later state of project often due to lacking of proper analysis work in the initial stage. You may argue that it would depend on scale or project type. Alright! Let’s think about this as a toolkit from architectural perspective, from medium to enterprise level in which you as system architecture needs to make sure the healthy and alignment of the whole ecosystem upon any change.

Let’s look at another perspective. As project or program manager / director, will you accept any project plan without a report of risks, assumptions, issues and dependencies analysis ? The answer is certainly No if you are playing your role. 🙂

Enough for long-winded opinion. In the next section, I promise to make it be short and sweet by briefly describing the goal of each steps and following with list of questions which by answering that will provide you or your project team a nice RAID analysis report.

Let’s read on.

Risks Analysis

It aims to let stakeholders know the key areas of uncertainty then allow the project team to develop risk mitigation plans.

Questions:

• What risk cause project to be delayed or not delivered ?
• Is there any s/w dev skills not currently employed in your areas ?
• Are new technologies required that the company is not familar with ?
• Is there any specific contracting needs ?
• Is there any scaling needs that business not willing to pay for ?
• Is there any lower environment need that will not be fulfilled ?
• Is there any not funded testing efforts ?
• Is there any significant business risks being introduced ?

Assumption Analysis

Capturing assumptions before project starts helps levels-set people’s thinking about the architecture and serve as the issue resolution later on when the problem arises.

Questions:

• What assumption being made ?
• Do you assume that you can successfully develop some new capacity ?
• Do you assume that certain group will do particular part of their work ?
• Do you assume that certain refactoring will occur with an existing system ?
• Do you assume that certain integrations will be required or will explicitly not be supported ?
• Do you assume some research and development needs to occur ?

Issues Analysis

The key objective of this step is to give project a sense of what area of the architecture have not been resolved and need to be dealt with in the future.

Questions:

• What are areas of the architecture that have not been resolved ?
• What areas of the architecture have not been finalized ?
• Any areas of technology that you or your team have any concern of known problem ?
• Are there contractual issues in play ?
• Has a key resource recently moved to another part of the company ?
• Is the deadline for delivery overly aggressive ?

Dependencies Analysis

Dependencies are anything that the architecture depends on including items, projects and tasks. Dependencies need to be clearly stated and made visible to the executive staff. It helps them to manage dependencies for you as it’s their interests.

Questions:

• What project are you dependent on for your project to complete ?
• What licensing agreements are you dependent on to provide needed functionality ?
• What purchases or other procurement needed ?
• What business arrangement needed ?
• What hardware needs to be purchased or operationalized ?
• What infrastructural software needs to be operationalized ?
• Is software integration with specific tools or services required ?

Hope you enjoy it.

Until we meet again, happy designing and coding.