Mastering Business Analysis Versatility Adjust Based on Risks

IIBA Southeast Wisconsin Chapter September 24, 2019

Presented by Eugenia C. Schmidt PMP CBAP PMI-PBA

2) Adapt to 6) Bridge 1) Move to 4) Adjust 5) Always 7) Build Up the Life- 3) Consider the Enterprise Based on Focus on the Tool Cycle Uniqueness Capability Mindset Risks Value Chest Approach Gap

Presentation, figures and tables are based on the book “Mastering Business Analysis Versatility”

https://www.jrosspub.com/business/mastering -business-analysis-versatility.html

Adjust Based on Risks identifies different risk classifications that may require the business analyst to modify either the business analysis approach or the overall project approach. Various responses to the risks are recommended depending on the approach.

Risk Key Concepts

Other Risks Risks & (People, Business Business, Analysis Culture) Adjust Based on Risks

Potential Risk & Life- Risks by Cycle Initiative Approaches Type

Not necessarily in this order

• Risks are uncertain events with a possibility of Predictive occurring • Changes may be made to Hybrid decrease the likelihood or Adaptive

potential impact Need for More ControlNeedforMore

• All initiatives have inherent Level of Risk & Complexity risks regardless of approach

Risk and Life-Cycle Approaches

cycle times reflected months as reflected times cycle

- Life

• Addressed formally • Big picture perspective over longer life cycle • Business analysis risks integrated into project management plans • Detailed planning allows for integrating responses into the approach • Progressive elaboration may uncover more risks

• Formally addressed like predictive, but has a fail fast philosophy like adaptive • Introduces prototypes and releases for fail fast approach • The use case is the recommended technique for requirements and risks are associated with each use case

• Fail fast philosophy helps to address risks early and frequently through the iterations • Product backlog grooming can uncover high risk requirements moving them up the backlog • Team members must remember to communicate risks during daily stand-ups and conversations because of lack of formality

• Regardless of approach, a 1) Identify risk management process (formal or informal) is a

5) necessity 4) Communi 2) Control cate Analyze • Collaboration with team members, stakeholders and

3) project managers ensure Respond appropriate balance of controls, responses and monitoring

• Tap into experience and history, similar situations

• Discuss stakeholder concerns during elicitation

• Consider general people and business risks

• Consider different risk types

• Review requirements for impacts

• Evaluate requirement attributes

• Initiative types • Leverage the BACCM™

• Gaps in competencies and capabilities • Lack of domain knowledge • Stakeholder resistance • Lack of decision makers • Unavailability key stakeholders • Changing Business Environment

There are various types or classifications of risk the business analyst must address that affects the ability to successfully:

• Perform business analysis work • Manage product scope • Address requirement alignment expectations • Implement each requirement • Implement a set of requirements • Address the uniqueness of initiatives • Address the uniqueness of industries

Can we successfully perform our BA work?

Performing BA Work Approach with Reason for Risks Highest Risk Occurrence

Lack of domain expertise Predictive, in-house build Learning time, access to domain information Key stakeholder unavailability Hybrid, in-house build Schedule conflicts, priority conflicts

Stakeholder turnover Predictive, Enterprise-wide Organizational instability

Inability to get to solution agreement Predictive Different political agendas

Not getting what you need Predictive Too busy, doesn’t have information, not right person Requirements continue to be too Adaptive Lack of backlog grooming and sizing large discussions in sprint planning sessions

• Move to a different, more iterative or less iterative, approach • Collaborate with experts • Add additional tasks to project plan • Add more formal controls or documents (e.g., a change control process) • Include different or additional techniques

Can we successfully manage product scope?

Managing Product Scope Approach with Reason for Risks Highest Risk Occurrence

Hidden scope expansion Predictive Lack of scope visibility, communication and validation Constantly changing requirements Predictive External policies or regulations, unknown requirements Misalignment with strategy or Adaptive Lack of access to information, lack of architecture communication, lack of responsibility Gaps in requirements Predictive Impacted stakeholders not identified, lack of allocated time for elicitation Vendor misinterpreting requirements Hybrid – vendor package Lack of domain knowledge, requirements ambiguous Gold plating- adding functionality not Adaptive Team member passion, learn requested something new

• More visibility of scope through modeling techniques • More communication of scope boundaries and context throughout approach • Determining root causes of changes • Including more prioritization and allocation to releases • Always include an alignment approach • Use a variety of elicitation techniques with cross verification

Evaluate risks that may impact: • Business Requirements – affecting the attainment of benefits or business value • Stakeholder Requirements – affecting the stakeholder’s ability to use the solution • Solution Requirements – affecting the system’s functionality, agreed upon quality attributes or transition • Business Rules - Both behavioral and definitional business rules affecting the quality of processes, policies, regulations, and the integrity of information.

Can we successfully implement EACH requirement?

Consider trade-offs and tolerances for specific requirement risks based on: • Cost, Schedule, Scope and Resources • Legal • Environmental • Technology • Benefit or Value • Dependencies

Can we successfully implement ALL requirements? Look at requirement attributes, have you captured the needed information to assess risks?

Business Impact or Complexity What if high percentage of requirements is HIGH impact, or HIGH complexity? Schedule Constraint Can schedule constraints impact other requirements? Priority What if high percentage of requirements is considered strategic? Volatility What if a high percentage of requirements are likely to change? Others – Cost, Size or Time Tolerances Would you change your business analysis approach or collaborate with the PM to change the project approach?

• Vendor Packages • Process or Data-driven • User-focused • Enterprise-wide • Technology-driven

• Missing Requirements • Evaluating unproven vendor packages • Not addressing the non-functional requirements

Classification Attribute Classification Attribute Classification Attribute Operational Data Integrity Deployment Auditability Development Customizability Performance Availability Efficiency Reliability Data Retention Escrow Robustness Flexibility (a.k.a. Code Protection) (a.k.a. Fault Tolerance) Interoperability Maintainability Security (a.k.a. Compatibility) Reusability Usability Portability Testability (+ Accessibility) Recoverability (+ Disaster Recovery) Scalability Safety Factor

• Silo Thinking • Change Management • Process Failures (Impact to behavioral business rules) • Transition Failures (Transitional requirements address possible failure points)

• Data Integrity (Impact to definitional business rules) – Lack of Data Definitions – Duplication – Data Decay – No Standards – Altered Data or Not Used as Intended • Protecting Privacy

• User-focused Methods • User Behavior Variations • User Skill Set Variation

• Miscommunication of Requirements • Getting to an Agreement • Lack of an Enterprise Architecture

• Review Quality Attributes • Hitting Capacity • Data Loss • Security Vulnerabilities

• Government: policy and regulatory risks • Non-profits: risk associated with funding, resource turnover and lack of formal structures • Manufacturing: risks with enterprise-wide vendor packages and impacts to quality • Services: security and privacy risks

• Assess probability – the likelihood the risk will occur

• Determine impacts and tradeoffs based on type of risk

• Quantify and score to help prioritize- which do we focus on and respond to?

Which risks should you Higher risk scores respond to? will require actions • Determine Risk Score 4 4 8 12 16 3 3 6 9 12

1) Analyze Probability 2 2 4 6 8

1 1 2 3 4

2) Analyze Impact Probability

3) Probability X Impact = 0 1 2 3 4

Risk Score Impact Lower risk scores will likely be accepted

• Review results of analysis • Assign ownership and responsibilities • Plan responses to highly ranked risks • Determine specific actions to implement the chosen response • Allocate budget and time for responses • Develop contingency and fallback plans

Avoid • Eliminate cause

Transfer • Shift to 3rd party

Share • Split ownership

Mitigate • Reduce probability

Accept • Live with it

Provide Contingency or Reserve • Reduce impact

• Use a different technique (e.g. changing from interviews to a workshop) • Add “fail fast” techniques (e.g. adding a prototype or proof-of- concept) • Change approach (e.g. less or more iterative) • More controls (e.g. add more traceability or formal procedures) • More robust prioritization criteria and procedures • Bring in experts

• Did the response do what was expected? • Every team member is responsible for communicating risks • Make risks transparent • If potential severity is high, push for action

SomeRisk Management risks identified Plan – Option by 1 the BA are likely to be integrated into 1. (Column A) Identify the risk the2. (Column overall B&C&D&E) project Assess the impact, risks quantify management the weight of the impact, quantify plan the probability, owned calculate by the severitythe PM, but 3. (Column F) Determine response options and list recommended actions - consider Avoid, Mitigate, Transfer, Accept or if a contingency may be needed thedepending BA onmay impact be assigned to monitor them

- Risk Why it is a risk and what is the impact if realized? 1 Communication Action

(Column A) (Column B) Or Additional Controls Needed Severity Severity

(Column E) (Column (Column F)

(Column C) (Column

(Column D) (Column

Impact ( Impact

Probability (1 Probability Impact) X (prob

STRONG RISK CULTURE WEAK RISK CULTURE • Acknowledging the risk • Promoting “groupthink” • Encouraging transparency • Normalization of deviance • Ensuring respect for the risk • Confirmation bias • Building up the culture to effectively • Escalating commitment deal with the risk • Finding consensus on the risk • Sustaining vigilance

• Address risks that impact performance business analysis work, product scope and specific requirements • Life-cycle approaches have various ways of dealing with risk • Each type of initiative will inherently have their own associated risks • Other risks may come from our external environment, people in the organization or business strategies • Certain risk cultures can be detrimental to managing risk

• Schmidt, Eugenia C., (2019), Mastering Business Analysis Versatility: Seven Steps to Advanced Competencies and Capabilities, J Ross Publishing, Inc. Plantation Florida. • Aked, Mark. (November 3, 2003). Risk Reduction with the RUP Phase Plan. IBM. https://www.ibm.com/developerworks/rational/library/1826.html • Gottesdiener, Ellen. (2003). The Software Requirements Memory Jogger, pp. 329-334. Goal QPC. • Kaplan, Robert S. and Anette Mikes. (June 2012). “Managing Risks: A New Framework.” Harvard Business Review Article. https://hbr.org/2012/06/managing-risks-a-new-framework • Krivkovich, Alexis and Cindy Levy. (May 2015). “Managing the people side of risk.” Mckinsey & Company Article. https://www.mckinsey.com/business-functions/risk/our-insights/managing-the- people-side-of-risk

Example complexity and risk identification questions • Have team members done anything like this before (extent of experience)? • Any of the solutions planned to be outsourced? • Are there any political or other external influences impacting the requirement? • How complex is the existing system process that the requirement impacts? • How likely is the requirement to change during the solution development? • Are there any dependencies with other solutions not yet implemented? • How drastic will the requirement affect job procedures or user performance? • Has this vendor solution been used with other customers? • Are there legal ramifications if this requirement is not implemented? • Has the integration of various technologies been done before? • How well do the stakeholders understand the current process? VITINAR © 2019 VITINAR | All Other Rights Reserved 40 About the Presenter

Presenter - Eugenia C. Schmidt, founder and managing partner of VITINAR. Eugenia is a well-known expert, consultant, instructional course designer, and trainer in business analysis, project and program management, project recovery, program/project office setup, information systems, and life-cycle methodologies. Ms. Schmidt worked in various management and technical roles – such as project and program manager, business process manager, risk manager, business analyst, systems analyst, and architect – for several firms, including AT&T, PwC, Lighthouse Consulting Partners, before forming her own business. The presentation is based on Eugenia’s new book, Mastering Business Analysis Versatility: Seven Steps to Develop Advanced Competencies and Capabilities. [email protected] www.linkedin.com/in/eugeniacschmidt