Keeping Risks at Bay & the Astute Business Analyst
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” – Mark Twain
Ah, yes, the wit and wisdom of Mark Twain; still rings true over a century later, in the business analyst’s world. More recently, former U.S. Secretary of Defense Donald Rumsfeld had famously talked about “known knowns,” “known unknowns,” and “unknown unknowns.” While Rumsfeld never talked specifically about “unknown knowns,” I believe that Mark Twain effectively filled that gap.
So, what can YOU do about all the risks lurking in the shadows, as the semi-omnipotent (like digging half a hole) business analyst?
I’m sure you all know about the “probability times impact” formula, which tends to be qualitative (i.e. scale of Low to High) in our world, then you propose mitigation responses; but as the BA the pressing question should be how you can share the daunting task of risk analysis and management with the project manager (PM). I see this as a joint effort in that the PM is chiefly entrusted with managing risks affecting time and cost, the BA and PM together manage risks relating to project scope, and the BA is primarily tasked with assessing risks relating to project quality. This stands to reason since the BA is concerned with product scope, whereas the PM is preoccupied with project scope.
So let’s get our hands dirty and dive into some salient aspects of risk. Are you ready?
1. Prioritizing Your Requirements Based on Risk Factors
What if the solution your organization wants to deploy is cutting-edge and entails a certain “leap of faith”? If something has no known precedent or proof of concept, there is an inherent risk to its quality on deployment – chalk that one up under “known unknowns.” (And try not to fret about the “unknown unknowns” while you’re at because let’s face it: you’ve got enough on your plate as it is.) As the BABOKv3 says in Section 5.3 on page 98, “If there is a risk that the solution is not technically feasible, the requirement that is most difficult to implement may be prioritized to the top of the list in order to minimize the resources effort before those resources learn that a proposed solution cannot be delivered.” Sage advice: if you can’t meet the quality threshold, you don’t want to encourage the PM to over-commit resources in vain.
2. The Personnel Dimension of Risk
This is where it gets tricky and sticky. Tricky because people have to be convinced; sticky because they don’t want to budge. It helps to know your organization’s appetite for risk, too.
In doing stakeholder analysis, you have to make sure that the right players – such as SMEs or regulatory stakeholders – can commit themselves to the team effort. If they are only sporadically available, or they are in “fire-fighting” mode all the time, then you might have to take a risk proceeding with certain assumptions until they can be validated. If they find fault with the conceptual solution and your initial requirements, then you’ll want to ensure their continued availability, as their approval is paramount. These are all factors that are known as engagement risk.
3. Assumptions, Constraints, and Dependencies
Typically, risks are documented along with assumptions, constraints, and dependencies for a good reason. It is because from these categories that risks are implied or inferred. As the BA, it may help to maintain a traceability matrix so you can convey potential flaws of assumptions, or whether dependencies have been fulfilled or are likely to be fulfilled – again, you’re more concerned with impacts on product quality, whereas project (and program) management is more concerned about duplication of effort (and costs). Once again, you need to consider the risk appetite of sponsors; that could very well be the impetus for a given constraint!
4. The Big Picture
Many organizations today use ERM or Enterprise Risk Management. These are high-level risk categories that need to be addressed in order to meet strategic imperatives. When you document high-level requirements (HLRs), consider how they may contribute to reducing these risk factors – thus resulting in residual risk. You could show a risk mitigation rating for each block of HLRs (i.e. a scale of Low-High); however, it may be difficult to do a risk rating attribute for each individual requirement. Your HLRs are expected to produce synergies to meet organizational objectives. Consider a formula that factors in priority values, too.
When thinking of the bigger picture, think about sources of risk; they could be more internally induced like culture or restructuring; or more commonly, they could be externally induced such as technology or market factors.
5. Value Realization and Risk
The moment of truth: you need to know if your undertaking has met certain quality thresholds. Has the solution realized its intended value? This is typically measured by metrics or KPIs (Key Performance Indicators). However, risks can ultimately derail your intended benefits; this, I believe, is where the framework of “(un)known (un)knowns” comes into play.
Achieving a reduced risk as an outcome, incidentally, is a benefit unto itself; albeit one that is not easily measured, as say compared to KPIs of increased efficiency, or reduced defects or downtime or complaints. (Section 7 of the BABOK speaks very well to this, by the way.) In this ever-expanding world of business intelligence (BI) and predictive analytics, one can run a “what-if” analysis to experiment with a range of outcomes, which could be based on risks manifesting.
6. Security Requirements
Lastly, some thoughts on security and risk; traditionally, security requirements have been in NFRs (non-functional requirements), or a logical roles matrix – since if anything threatens the CIA (confidentiality, integrity, availability) of your solution (which could be electronic or physical), then you effectively have a risk.
This is where an experienced technical SME, such as a senior designer, can be indispensable in sealing up the cracks in the armor as it were. You may need to introduce requirements that prevent certain malicious behaviors as per their advice.