When contemplating risk in a broader context, individuals may either approach it with caution or view it as an opportunity. Where do you stand? Let's delve into this question and discern the distinct role that a Business Analyst (BA) can play in risk management.
Embracing risk as an opportunity enables the creation and refinement of high-quality solutions, ultimately delivering tangible business value. This process is facilitated by a comprehensive understanding of risk's nature, potential sources, impacts, estimations, and treatment strategies. Such considerations are fundamental not only to project management but also to product development.
It's important to acknowledge that no crystal ball can predict the future. Therefore, a thorough grasp of project intricacies and a diligent analysis of potential events, both positive and negative, are imperative.
A lack of comprehension of relevant issues poses inherent risks to a project. Nevertheless, it's crucial to recognize that risk isn't always adverse; it can present opportunities for growth.
While Project and Delivery Managers are primarily responsible for identifying and managing project risks, this responsibility is distributed within Agile teams. A proficient BA should possess adept skills in Risk Management, particularly concerning product-related risks. They should effectively communicate these risks and their corresponding strategies to their team members. A robust Risk Management plan aids stakeholders in comprehending the procedures for risk:
Identified,
Evaluated and analyzed,
Documented,
Controlled and managed.
Reported
Let me provide you with a reference for how a risk response activity could be structured into the following column structure:
Column | Description |
Date added | The date when the record about risk was added. |
Reporter | The reporter is the person who defines the risk. |
Source | Ex: Documentation, scope, specific initiative or epic, etc. |
Dimension | Certain factors that can affect the time, scope, or quality of the product. For example: - Finances (contract) - budget overrun, contract disputes. - Scope - conflicting requirements. - Schedule - delay in agreement. - Quality - errors in work. - EngX - technology scalability issue. - CSAT - product owner dissatisfaction. - Team (work, hiring) - low productivity, long adaptation time for a new employee. - Process - lack of user feedback before launch. |
Effect | Possible effect with detailed description. For example, if the function and user history do not match the DoR, then... |
Treatment strategy | avoid or mitigate or transfer or accept |
Impact | It can be defined quantitatively as money or time, if measurable, or simply as 1 - insignificant, 2 - under control, 3 - significant losses. Don't spend too much time here for precise assessment. Approximate estimation is always better than nothing.) |
Probability | The likelihood in percentage that the risk may occur. |
Risk index | The impact multiplied by the probability; the highest risk index is the highest risk priority from the perspective of others. |
Risk owner | The person responsible for addressing the risk. |
Deadline | The deadline by which the team / responsible person undertakes to address the risk. |
Status | The current risk status as of the date. |
Workaround | I would edit this column, especially when additional important information has to be added to the status. |
Beyond the risk resolved date analysing | This is very interesting information, taken from my experience. As a BA and Product Owner, I managed a table with all the aforementioned parameters. Then, during security audit certification, I was advised to analyze risks within a certain defined period after their reduction or resolution, which may make sense in certain situations, such as when it concerns security. |
It is a pretty long table. Your project might not need all the columns, or it could be split into two or more tables. For example, if you analyzed and estimated risks, you could keep each treatment strategy in a separate table.
As a BA, you should have overall responsibility while analyzing complex epics where more than one team could be involved. Risk analysis and treatment might look like the following structure: You can manage the status of important tasks and use this document to check the status for you and the management team. Look at the best practice examples below.
Highlighted Details:
If the first table, “How a risk response activity could be,” is more about describing the characteristics of risk and is more basic, then the second one is about detailing the selected most significant risk source for your project and analyzing it in detail.
As demonstrated by the example of potential risk points within a single Epic for a project involving different teams, these include:
Requirements that need to be signed off
Technical design readiness
Prototype readiness
HTML readiness
Estimated time required for completion.
Moreover, epics do not always need to be tested on all these risk points. As a BA, I analyzed whether it was appropriate, then marked 'Y' or 'N', which was then highlighted in red. You can simply use a dash where you don’t need those checks. For example, for epic F23 Checkout improvement, it is enough to have the technical design ready and have the epic estimated.
You might be confused by i9, i10. Let me clarify; in this case, it marks automation testing activities so that we can quickly mark by color where we need more attention, or it could be in front of an epic where it's required. Also, we use the color green to signal everything is okay and we can move on, and we use yellow to indicate work in progress. We also use numbers at the top of the table to see how many developers or other specialists work in the team on the epic, and we put '1' where additional capacity is required (for any reason).
However, you may ask: Why did we add the presence of developers as of the date to this analysis? Precisely because their availability and their efficient distribution are also a source of risk, so we can plan the stages of work well within the epic but fail if we do not consider the presence and distribution of developers, UI, or other important specialists. With the help of such a table, blockers can be easily predicted. As you can see, various teams are involved in working on the epic, and another important characteristic is considered - releases. This allows us to see in which release each team is working on tasks within the epic/feature and to prioritize tasks more effectively.
This table is quite detailed and considers not only individual features within Epic but also the number of developers on a given date and release. Additionally, there are other marks by color and numbers that help us quickly figure out where we are. I hope this example proves useful in your risk management work and will encourage you to design your own that will satisfy your specific needs.
In conclusion, you don’t need to be afraid or avoid risk-related discussions, thinking that it is only management’s responsibility. Instead, consider risks as an opportunity to deliver high-quality solutions and meet deadlines through an official risk analysis and management.
Thank you for your attention, and I welcome your thoughts in the comments section below. I trust that my article proves helpful, and I encourage you to apply its context to project activities within the roles of Business Analyst (BA) or Product Owner (PO). Furthermore, don't hesitate to reach out by leaving comments or messaging me directly.
Comments