The Business Analysis Planning and Monitoring

Related Articles

What is the requirement elicitation? Have you ever participated in these elicitation meetings?

10 hours ago

What is the role of a business analyst in an organization?

10 hours ago

What is requirement prioritization in Business analysis?

1 day ago

The Business Analysis Planning and Monitoring knowledge area needs to be considered as two complementary components.

The BA Planning part focuses on preparing for effective execution of business analysis. A good understanding of project nature, business needs and objectives, as well as the required scale of changes to the existing state within an organisation helps to select an approach which allows performing business analysis in an effective manner, and then develop a solution for the identified needs.

The BA Planning component gets input from Enterprise Analysis as it provides information about the current business landscape and long-term business objectives. The BA Planning component includes analysis of stakeholders, their roles and responsibilities in the project, their needs for information about BA activities, the required level of detail and frequency of communication of the specified information.

All the agreed terms are then reflected in the BA Plan – a document outlining the agreed BA deliverables, schedule of the planned BA activities, approach and techniques to be used, and reporting on BA progress.

The defined BA Plan determines the approach to requirements management and the means of maintaining their traceability. The Requirements Management Plan defines how the BAs’ performance will be measured during the project.

Each iteration of business analysis activities facilitates improvement of the initial planning as more information becomes available.

The BA Monitoring component focuses on ensuring that the planned activities are performed well and the agreed deliverables are produced in line with the agreed schedule. Performance of BA activities is regularly measured against the approved BA Plan and Requirements Management Plan. Where a deviation from the planned results has been identified, a corrective action (re-planning of activities) is taken to restore performance to the agreed level and probably correct the planned activities.

Organizational standards play an important role in planning, establishing performance metrics and reporting on the results.

 

 

 

INTRODUCTION – APPLYING THE BUSINESS ANALYSIS CORE CONCEPT MODEL

Business Analysis Planning and Monitoring

Core Concept         Usage in Business Analysis Planning and Monitoring

Change ——- Determine how change to business analysis results will be requested and authorized.

 Need——— Select a business analysis approach that provides a suitable amount of analysis for the                                       desired change.

Solution—— Evaluate if business analysis performance contributed to successful implementation of a solution.

 Stakeholder ———-Perform stakeholder analysis to account for stakeholder characteristics and reflect their needs.

 Value ————-Use performance analysis to ensure business activities produce sufficient value for the stakeholders.

 Context——— Ensure a thorough understanding of context in order to develop an efficient business analysis approach.

 

Business Analysis Planning & Monitoring

Overview

• Identifying stakeholders
• Defining roles and responsabilities of stakeholders in BA effort
• Developing estimates for BA tasks
• Planning how the business analyst will communicate with stakeholders
• Planning how REQ will be approached, traced and prioritized
• Determining the deliverables that the BA will produce
• Defining and determining BA processes
• Determining the metrics that will be used for monitoring BA work

1 Plan Business Analysis Approach

• Purpose
  • To select an approach to performing BA
  • Which stakeholders need to be involved in the decision
  • Who will be consulted and informed of the approach
• Description
  • Overall x Agile Techniques (elements can be combined)
  • Formal standards x informal (tailored to the needs)
  • If no standards exist, determine how the work will be complited
    • With Project Manager and project team
  • Inputs
    • Business Need – problem, opportunity, risks, timeframe
    • Expert Judment – consultants and prior experiences
    • Organizational Process Assets
      • Methodologies, tools, techniques, templates and deliverables
    • Elements
      • Plan-Driven – PD
        • Minimizing up-front uncertainty
        • Ensuring that the solution is fully defined
        • Maximize control and minimize risks
        • REQ defined before/in advance of implementation
        • Waterfall methods
      • Change-Driven – CD
        • Rapid delivery
        • Short interactions
        • Exploratory
        • Incremental improvement
        • Agile methodologies
      • Considerations
        • Timing of BA Work
          • PD – Focus on elicitation, analyzing, documenting, verifying and communicating requirements
          • CD – Produce na initial list os high-level requirements (requirements envisioning), prioritized and reprioritized
        • Formality and Level of Detail of BA Deliverables
          • PD – Formality and detail
          • CD – Prioritized list of requirements
        • Requirements Prioritization
          • PD – Based on total solution scope
          • CD – Emphasis on effective requirements prioritization methods
        • Change Management
          • PD – Just when necessary, as a “mini-project”
          • CD – Prioritized and selected on the next iteration
        • BA Planning Process
          • It will be integrated into a larger project plan
        • Communication with Stakeholders
          • PD – Forma method, pre-defined forms
          • CD – Frequency of communication, post-implementation
        • Requirement Analysis and Management Tools
          • Shape the selection of BA techniques
        • Project complexity: Factors
          • Number of stakeholders
          • Number of business areas affected
          • Number of business systems affected
          • Amount and nature of risk
          • Uniqueness of requirements
          • Number of technical resources required
        • Techniques

 

•   Decision Analysis
• Process Modelling
• Structured Walkthrough

• Stakeholders
  • Customer, Domain SME, End user and Supplier
  • Implementation SME
  • Project Manager
  • Tester
  • Regulator
  • Sponsor
• Output
  • BA Approach – Team roles, deliverables, BA techniques, timing and frequency of interactions with stakeholders

2 Conduct Stakeholder Analysis

• Purpose
  • Identification of stakeholders, for the project or phase, who:
  • Maybe affected by a proposed initiative
  • Share a common business need
  • Determining stakeholder influence and/or authority regarding the approval of project deliverables
• Description
  • Roles and responsibilities clearly described
  • Stakeholder may be grouped into categories
• Input
  • Business Need
  • Enterprise Architecture
  • Organizational Process Assets
• Elements
  • Stakeholder roles must be identified early to ensure deliverables
    • Identification:
      • Understand who are the stakeholders
      • Can vary between projects, methodologies, organizations
    • Complexity of Stakeholder Group, vary according with:
      • Number and variety of direct end users
      • Number of interfacing business processes and automated systems
    • Attitude and influence, towards:
      • Business goals and objectives
      • Solution approach
      • Sponsor
    • Influence:
      • On the project and in the organization
      • Need for the the good of the project
      • With other stakeholders
    • Authority Levels for BA Work, to:
      • Approve the deliverables
      • Inspect and approve the REQ
      • Request and approve changes
      • Review and approve the traceability structure
    • Techniques
      • General
        • Acceptance and Evaluation Criteria
        • Brainstorming
        • Interviews
        • Organization Modelling
        • Process Modelling
        • REQ Workshop
        • Risk Analysis
        • Scenarios and Use Cases
        • User Stories
        • Scope Modelling
        • Survey/ Questionarie
      • RACI Matrix, describe the roles of those involved
        • [R] – Responsable
        • [A] – Accountable (only one)
        • [C] – Consulted prior to the work and gives input
        • [ I ] – Informed of the outcome
      • Stakeholder Map, visual diagrams
        • Influence x Interest
        • Onion – How involved stakeholder is with the solution
      • Stakeholder
        • Domain SME / Implementation SME
        • Project Manager
        • Tester / Regulator / Sponsor
      • Output
        • Stakeholder List, Roles and Responsibilities
          • List of required roles
          • Names and titles of stakeholders, category, location, special needs
          • Stakeholder influence and interest
          • Documentation of stakeholder authority levels

3 Plan BA Activities

• Purpose
  • Determine the activities that must be performed
  • Deliverables that must be produced
  • Estimate the effort required to perform that work
  • Identify the management tools required to measure the progress of those activities and deliverables
• Description
  • Activities for a given initiative, to:
  • Identify BA deliverables
  • Determine the scope of work
  • Determine which activities the BA will perform and when
  • Develop estimates for BA work
• Input
  • BA Approach
    • Defines the lifecycle, deliverables, templates and tasks:
      • PD – Define requirements as early as possible to reduce uncertainty
      • CD – Define requirements as close to implementation as possible
    • BA Performance Assessment
      • Use prior experiences to determine the effort in performing BA work
    • Organization Process Assets
      • May mandate certain deliverables
    • Stakeholder List, Roles and Responsibilities
  • Elements
    1. Geographic Distribution of Stakeholders
       • Consider physical location of key stakeholders
         • Collocated
         • Dispersed
       • Outsourced development:
         • Requirement documentation and acceptance criteria, or
         • More frequent review sessions

2. Type of Project or Initiative, may have a significant impact on the activities that need to be performed, included:
   • Feasibility studies / Process improvement
   • Organization change / Development or outsourced
   • Software maintenance / Software package selection
3. BA Deliverables
   • Basis to identify activities. Some methods:
     • Interviews with stakeholders
     • Review project documentation
     • Review organization process assets
   • Frequently becames a requirements package
4. Determine BA Activities
   • WBS – Work Breakdown Structure
     • Decomposes project scope into smaller pieces
     • Creates hierarchy of work
     • Project -> Interations, releases or phases
     • Deliverables -> Packages
     • Activities -> Smaller tasks
       • This point creates a list of activities
     • List of Activities can be created:
       • Breaking each activities into tasks
       • Dividing the project into phases, interactions
       • Using a previous similar project
     • The elements of each activitie includes:
       • An unique number
       • Description of the activitie labeled with a verb + substantive (Ex: Update REQ documentation)
       • Can include:
         • Assumptions – Considered to be true
         • Dependences – Logical relationships
         • Milestones – Events to mesuare the progress
       • Techniques
         • Estimations
           • Produces an overall assessment of the amount of work
         • Functional Decomposition
           • WBS (project or product)
           • Facilitate an undersanting of the work
           • Enable estimation of tasks
         • Risk Analysis
           • Might impact the analysis plan
         • Stakeholders
           • May participate in the verification and validation of BA deliberables
             • Customer, Supplier, End User, Domain SME
               • Major source of REQ, critical availability
             • Implementation SME
             • Project Manager
               • BA scope is managed as part of overall project scope
             • Operacional Support / Tester / Sponsor
           • Output
             • BA Plan – Description of work scope
               • WBS / Activity List/ Estimates
               • When and how it must be changed in response of changes
             • All tasks have BA plans as an implicity input

4 Plan BA Communication

• Purpose
  • Describe the structure and schedule for comunications
  • Record and organize the activities for setting expectations of BA work, meetings, and others
• Description
  • Determining how best:
  • To receive, distribute, access, update and escalate information
  • Decide which format are appropriate for a initiative
  • Present REQ understandable, clear, concise and accurate
  • Considerations:
    • What, how, for who and when to comunicate
    • Physical location, types of communication, of REQ
  • Input
    • BA Approach
      • Standards and models used for communication
    • BA Plan
      • Deliverables that need to be comunicated
    • Organizational Process Assets
      • Standards and models for use in communication
    • Stakeholders list, roles and responsabilities
      • When information needs to be provided
    • Element
      1. Geography
         • Stakeholders collocated or dispersed
      2. Culture
         • Language barriers
         • Subtle differences of relationship:
           • Natural Commitments x Concerns/Goals:
             • Time and task completion
           • Law x Spirit of the contract
           • Centralized power x Involve all affected
             • Formal and Informal authority

3. Project Type
   • Different deliverables:
     • New software – All REQ included
     • Technology Upgrade –Technical REQ
     • Change in a business process – Process and data REQ, business rules, funcional and technical REQ
     • Software package – Require RFP, business REQ, technical REQ, functional and others

4. Communication Frequency
   • For each type of communication
   • Can vary from stakeholder to stakeholder
5. Communications Formality
   • Level necessary could vary from stakeholder to stakeholder and project phase
   • Tends to be more formal when:
     • The project is unusually large
     • The domain involved is very complex
     • The technology is new to the organization
     • The project is considered to be mission critical
     • The executive sponsor require formality
     • REQ to be subject to regulatory review
     • REQ to be presented in na RFP/RFQ/RFI
   • Techniques
     • Structured Walkthrough
       • Common approaches to requirements communication
       • Time to conduct each walkthrough must be included in the plan
     • Stakeholders
       • Customer and Supplier
       • Domain SME
       • End Use
       • Implementation SME
       • Operational Support
       • Project Manager
       • Tester
       • Regulator
       • Sponsor
     • Output
       • BA communication plan, describes:
         • How, when and why the business analyst will work directly with stakeholders
         • Format, content, medium, level of detail

5 Plan Requirements Management Process

• Purporse
  • To approve requirements for implementation
  • Manage changes to the solution or requirements scope
• Description
  • Determines the appropriate process for :
    • Requirements change
    • Which stakeholders need to approve change,
    • Who will be consulted or informed of changes,
    • Who does not need to be involved
  • Inputs
    • BA Approach – Appropriate requirements management processes
    • BA Plan – Which deliverables are to be produced and when
    • Organizational Process Assets – Standard template
  • Elements
    1. Repository
       • Method of storing requirements
       • May include whiteboards, word processing documents
       • All approved requirements should be found in a repository
       • Stakeholders need to be able to locate requirements in that repository
    2. Traceability
       • Determine whether and how to trace requirements
       • Based on the complexity of the domain, the number of views of requirements that will be produced
       • Must be done correctly and consistently to have value
    3. Select REQ Attributes
       • Provide information about requirements
       • Allow the requirements team to associate information with individual or related groups of requirements
       • Helps the team efficiently and effectively make tradeoffs between requirements
       • Commonly used requirements attributes include:
         • Absolute reference
         • Author of the requirement
         • Complexity
         • Ownership
         • Priority
         • Risks

4. Requirements Prioritization Process
   • Focuses effort on determining which requirements should be investigated first
   • Based on the risk associated with them, the cost to deliver them, the benefits they will produce, or other factors
     • Formality
     • Establishing The Process And Technique
     • Plan The Participation

5. Change Management
   • Considerations when planning for handling changes:
     • Determine the process for requesting changes
     • Determine who will authorize changes
     • Impact Analysis
     • Plan the wording of the request
       • The requirements process needs to spell out the nature of the components within a request for change. These might include:
         • Cost and time estimates of change
         • Benefits and risks of the change
         • Recommended course of action for change
       • Coordinate Prioritization of Change

6. Tailoring the Requirements Management Process
   • To meet the needs of a specific initiative or project. Factors:
     • Organizational culture
     • Stakeholder preferences
     • Complexity of project, project phase, or product
     • Organizational maturity
     • Availability of resources
   • Techniques
     • Decision Analysis
     • Problem Tracking
     • Risk Analysis
   • Stakeholders
     • Domain SME
     • End User
     • Implementation SME
     • Operational Support
     • Project Manager
     • Tester
     • Sponsor
   • Output
     • Requirements Management Plan, describes the:
       • Approach to be taken to structure traceability
       • Definition of requirements attributes to be used
       • Requirements prioritization process
       • Requirements change process, including how changes will be requested

6 Manage BA Performance

• Purpose
  • To manage the performance of business analysis activities to ensure that they are executed as effectively as possible
• Description
  • Determining which metrics will be used to measure the work
  • How to track, assess, and report on the quality of the work
  • Take steps to correct any problems that may arise
  • May feed into the development of future business analysis plans
• Inputs
  • Business Analysis Performance Metrics
  • Business Analysis Plan
  • Organizational Performance Standards
  • Requirements Management Plan
• Elements
  1. Performance Measures
     • Based on deliverable due dates as specified in the BA plan
     • Metrics such as the frequency of changes to REQ or the number of review cycles required
     • Identify opportunities for improvement
  2. Performance Reporting
     • Can be in written format to provide for archival and tracking
  3. Preventive And Corrective Action
     • Where problems in executing BA activities are occurring
     • Opportunities for improving the BA process exist
     • Engage the necessary stakeholders to identify the correct preventative or corrective actions

• Techniques
  • General
    • Interviews
    • Lesson learned process
    • Metrics and Key Performance Indicators
    • Problem Tracking
    • Process Modelling
    • Root Cause Analysis
    • Survey/Questionaries
  • Variance Analysis
    • Analyze discrepancies between planned and actual performance
    • Determine the magnitude of those discrepancies
    • Recommend corrective and preventive action as required
    • Related to planned versus actual estimates, cost, scope, product expectations
  • Stakeholders
    • Domain SME and End User
    • Implementation SME, Operational Support, and Tester
    • Project Manager
    • Sponsor
  • Output
    • Business Analysis Performance Assessment
      • Comparison of planned versus actual performance
      • The level of effort required to complete BA work
    • Business Analysis Process Assets
      • Recommendations for improvement to the BA process
      • Should be analyzed and documented
      • Lessons learned should be recorded

 

The Business Analysis Planning and Monitoring knowledge area describes the process of how a business analyst determines which activities will be needed to complete the business analysis effort.  The tasks within this knowledge area govern the business analysis tasks in all of the other knowledge areas.