Chapter 3 – 3.3 Plan Business Analysis Governance

3.3.1 Purpose

The purpose of Plan Business Analysis Governance is to define how decisions are made about requirements and designs, including reviews, change control, approvals, and prioritization.

3.3.2 Description

Business analysts ensure that a governance process is in place and clarify any ambiguities within it. A governance process identifies the decision makers, process, and information required for decisions to be made. A governance process describes how approvals and prioritization decisions are made for requirements and designs.

When planning the governance approach, business analysts identify:

  • how business analysis work will be approached and prioritized,
  • what the process for proposing a change to business analysis information is,
  • who has the authority and responsibility to propose changes and who should be involved in the change discussions,
  • who has responsibility for analyzing change requests,
  • who has the authority to approve changes, and
  • how changes will be documented and communicated.

3.3.3 Inputs

  • Business Analysis Approach: incorporating the overall business analysis approach into the governance approach is necessary to ensure consistency across the approaches.
  • Stakeholder Engagement Approach: identifying stakeholders and understanding their communication and collaboration needs is useful in determining their participation in the governance approach. The engagement approach may be updated based on the completion of the governance approach.

3.3.4 Elements

.1 Decision Making

Decisions are made throughout the initiative. A stakeholder may serve in various roles in the decision-making process such as:

  • participant in decision-making discussions,
  • subject matter expert (SME) lending experience and knowledge to the decision-making process,
  • reviewer of information, and
  • approver of decisions.

The decision-making process defines what happens when teams cannot reach consensus, by identifying escalation paths and key stakeholders who hold final decision-making authority

.2 Change Control Process

When business analysts develop a change control process, they:

  • Determine the process for requesting changes: specify which requirements and designs the change control process covers and determine whether it applies to all changes or only to changes of a specific size, cost, or level of effort. This process details the steps for proposing a change, when changes can be proposed, who can propose changes and how change requests are communicated.
  • Determine the elements of the change request: identify the information to be included in a proposal to support decision making and implementation if it is approved.

Possible components to consider on a change request are:

  • Cost and time estimates: for each area affected by the proposed change, the expected cost of change is estimated.
  • Benefits: an explanation of how the change aligns with the initiative and business objectives to show how the change adds value. Benefits considered include both financial benefits and tactical benefits such as implications to scope, time, cost, quality, and resources.
  • Risks: an analysis of risks to the initiative, the solution, or business objectives.
  • Priority: the level of importance of the change relative to other factors such as organizational objectives, regulatory compliance requirements, and stakeholder needs.
  • Course(s) of action: the course of action for the change includes an assessment of the components of the change request (cost, time, benefits, risks and priority). It is common to identify several alternative courses, including those recommended by the requester and by other stakeholders so decision makers can make a choice that will best serve the needs of the initiative.
  • Determine how changes will be prioritized: the priority of the proposed change is established relative to other competing interests within the current initiative.
  • Determine how changes will be documented: configuration management and traceability standards establish product baselines and version control practices that identify which baseline is affected by the change.
  • Determine how changes will be communicated: how proposed changes, changes under review, and approved, declined, or deferred changes will be communicated to stakeholders.
  • Determine who will perform the impact analysis: specify who is responsible for performing an analysis of the impacts the proposed change will have across the initiative.
  • Determine who will authorize changes: include a designation of who can approve changes and what business analysis information their authority covers.

.3 Plan Prioritization Approach

Timelines, expected value, dependencies, resource constraints, adopted methodologies, and other factors influence how requirements and designs are prioritized.

When planning the prioritization process, business analysts determine the:

  • formality and rigor of the prioritization process,
  • participants who will be involved in prioritization,
  • process for deciding how prioritization will occur, including which prioritization techniques will be utilized, and
  • criteria to be used for prioritization. For example, requirements may be prioritized based on cost, risk, and value.

The approach should also determine which stakeholders will have a role in prioritization.

.4 Plan for Approvals

An approval formalizes the agreement between all stakeholders that the content and presentation of the requirements and designs are accurate, adequate, and contain sufficient detail to allow for continued progress to be made.

The timing and frequency of approvals are dependent on the size and complexity of the change and associated risks of foregoing or delaying an approval.

The business analyst must determine the type of requirements and designs to be approved, the timing for the approvals, the process to follow to gain approval, and who will approve the requirements and designs.

When planning the appropriate approval process, business analysts consider the organizational culture and the type of information being approved. For example, new systems or processes for highly regulated industries such as financial, pharmaceutical, or healthcare are likely to require frequent and rigorous review and approval of very detailed specifications. For other types of initiatives, a less intensive approval process may be more appropriate and result in a faster implementation.

Planning for approvals also includes the schedule of events where approvals will occur and how they will be tracked. Stakeholder availability, attitude, and willingness to engage determine the efficiency of the approval process and may significantly affect delivery timelines.

3.3.5 Guidelines and Tools

  • Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
  • Business Policies: define the limits within which decisions must be made. They may be described by regulations, contracts, agreements, warranties, certifications or other legal obligations.
  • Current State Description: provides the context within which the work needs to be completed. This information can help drive how to make better decisions.
  • Legal/Regulatory Information: describes legislative rules or regulations that must be followed, and can be used to help develop a framework that ensures sound business decision making.

3.3.6 Techniques

  • Brainstorming: used to generate an initial list of potential stakeholder names who may need approval roles in the defined governance process.
  • Document Analysis: used to evaluate existing governance processes or templates.
  • Interviews: used to identify possible decision-making, change control, approval, or prioritization approaches and participants with an individual or small group.
  • Item Tracking: used to track any issues that arise when planning a governance approach.
  • Lessons Learned: used to find if past initiatives have identified valuable experiences with governance that can be leveraged on current or future initiatives.
  • Organizational Modelling: used to understand roles/responsibilities within the organization in an effort to define a governance approach that involves the right stakeholders.
  • Process Modelling: used to document the process or method for governing business analysis.
  • Reviews: used to review the proposed governance plan with key stakeholders.
  • Survey or Questionnaire: used to identify possible decision-making, change control, approval, or prioritization approaches and participants.
  • Workshops: used to identify possible decision-making, change control, approval, or prioritization approaches and participants within a team setting.

3.3.7 Stakeholders

  • Domain Subject Matter Expert: may be a possible source of a requested change or may be identified as needing to be involved in change discussions.
  • Project Manager: works with the business analyst to ensure that overall project governance aligns with the business analysis governance approach.
  • Regulator: may impose rules or regulations that need to be considered when determining the business analysis governance plan. May also be a possible source of a requested change.
  • Sponsor: can impose their own requirements for how business analysis information should be managed. Participates in change discussions and approves proposed changes.

3.3.8 Outputs

  • Governance Approach: identifies the stakeholders who will have the responsibility and authority to make decisions about business analysis work including who will be responsible for setting priorities and who will approve changes to business analysis information. It also defines the process that will be utilized to manage requirement and design changes across the initiative.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *