the risk management technique is going to be about identifying risks of your proposed changes, classifying these risks, and then identifying what the mitigations are.
- Make a list of all of the risks.
- going from your baseline architecture to your target architecture.What are the possible things that can go wrong?
- One of the risks could be the project goes over budget: always going to be a risk that something does happen along the way. Or it takes longer than you expect.
- going from your baseline architecture to your target architecture.What are the possible things that can go wrong?
TOGAF Standard has two levels of Risks:
- Initial Level of Risk
- what is the threat or the risk that exists if you did nothing to mitigate against it.
- If you are thinking that the project is going to take longer than you expected, but you don't generally do anything to try to make it finish on time.
- Then this is your categorization of how severe and how serious that risk is.
- Residual Level of Risk
- The residual level risk is what remains that you're not able to mitigate or you're not willing to mitigate.
- So one example is Client Acceptance Risk
- If you develop the solution, but when you go to deploy it, the clients don't accept this solution.
- So how do you measure the level of risk?
- What's the likelihood of this being coming true or not?
- If you consider it being just slightly likely or somewhat likely, what can you do to mitigate this in Client Acceptance Risk?
- How to mitigate it?
- You can conduct early and frequent communications would be one of the mitigations.
- you can do early demos of the solution or get them involved in crafting the solution.
- The residual level risk is what remains that you're not able to mitigate or you're not willing to mitigate.
If one of your wisks does come true, how do you evaluate how serious it is?
So not all risks are super serious. But some of them are extremely serious.