The Critical Steps To s1

Planning and Managing Requirements

Short Name: Business Unit/Program: Version: Document Author: Date: Document Revision Log

Version Date Author Summary of Changes Section A: Project Context Planning Inputs

The following is a list of possible documents, if in existence, that may provide context around the project and input into the planning effort.

Reviewed Inputs Comments / Observations / Notes Y/N

Business Information Business Case Organization Chart Organizational processes & templates for BA work Project Information Existing project documents: Project charter Scope statement Preliminary Project Plan Preliminary Stakeholder List Additional Documents Existing Training Materials Existing Models Existing User Documentation Others??

Business Analysis Approach

The following is a list of general approaches that can impact your planning. Determine the approach

Notes- Recommend to categorize them… Project Approach Impacts to BA planning and work effort Approach (Y/N)

Waterfall Agile Hybrid Section B: Stakeholder Engagement Plan RASCI Matrix R = Responsibility (Who does the work?) C = Consults with (Who do we need to consult and get input from?) A = Accountable (Who approves, makes the decision, signs off?) I = Inform (Who do we need to inform after the work is done?) S = Support (Who supports the business analyst in doing the work)

Authority R A S C I Role Responsible Accountable Support Consult Inform / Approve With

Stakeholder Analysis (Influence-Acceptance) Matrix

High Acceptance

Low Influence High Influence

Low Acceptance Stakeholder Contact List

List the key stakeholders that will provide requirements for this project. Group Category Category Name Email Phone Representing 1 2

Stakeholder Categorization Elements

Stakeholder categorization allows the BA to organize the stakeholders into meaningful categories in order to plan and manage requirements. Determine which categorizes you will need for planning purposes; you may change the categories as needed. You may also want to add your selected categories to your stakeholder contact list as seen in the above table.

Categories Y/N Categories Y/N Geographical locations Group represented Primary / secondary source of requirements Departments / Entities Number of user represented Internal / External Number of processes represented Language Number of systems impacted Time Zones Technology skill level Experienced User Level of influence Level of acceptance Authority levels BA Collaboration Plan

Capture the key collaboration events for your stakeholders. Include their preferences for collaboration, events, frequency, location, tools and mediums. A collaboration event may be conducted for an individual or a group of stakeholders. Medium Tools (wikis, (in- blogs, per Stakeholder Stakeholder(s) online son Name or Event Frequency Location Preferences comm or Group unities virt ) ual )

BA Communication Plan Capture the key communication events for your stakeholders. Include meetings, requirements sessions, requirements reviews, prioritization sessions, requirement activity status, etc.

Communication Event Audience Objective Media / Frequency forma t

Section C: BA Activities Plan

This is a list of common activities that a business analyst may conduct. Each organization and project may have different activities needed. You can use this as a checklist to determine your BA work activities.

Requirements Activity by KA In/Out Comments (Include when, how and with No. of Est. whom) Sessions Hours BA PLANNING . Create BA & requirements plan STRATEGY ANALYSIS . Analyze current state . Analyze future state . Assess risks/challenges in moving to future . Define change strategy (gap analysis, provide recommendations, etc.) ELICITATION . Interviews . Requirements workshop . Focus Group . Survey . Observation . Document analysis . Interface analysis . Prototyping . Research . Mind mapping REQ. ANALYSIS & DESIGN DEFINITION . Analyze & document req. . Business models – Business architecture – Organizational models – Geographical models – Value Stream maps – Value chain/cross-functional models – Context diagrams – Functional decomposition diagrams . Data Models – Class models Requirements Activity by KA In/Out Comments (Include when, how and with No. of Est. whom) Sessions Hours . Process models – SIPOC charts – Process maps – Swimlanes – Data flow diagrams (DFD) – Use case model – Activity diagrams . Others – CRUD matrix – Prototypes/mock-ups – State transition diagrams – Sequence diagrams – Storyboards – User stories . Verify & validate requirements . Define req. architecture . Define design options . Analyze potential value & recommend solution REQ. LIFECYCLE MANAGEMENT . Communicate requirements . Trace requirements . Prioritize requirements . Conduct reviews & obtain approvals . Analyze change requests . Manage documentation BA PERFORMANCE EVALUATION . Measure & analyze BA performance measures SOLUTION EVALUATION (Post Project) . Measure solution performance . Analyze performance measures . Assess solution limitations . Assess organizational limitations . Recommend actions to increase solution value Section D: Requirements Risk Categories Category Examples Planning & . Little or no requirements planning done . Requirements plan does not sync up Monitoring . Stakeholders not identified with project plan Scope . Unclear scope . Not clear on what is in and out of . Scope not well documented scope Elicitation . Inadequate user involvement . Time pressure – not enough time . Requirements are not complete . Documentation . Different interpretations . Includes design elements . Ambiguous terminology . Missing requirements . Not enough detail Analysis . Customers disagree on prioritization . Conflicting requirements . Level of difficulty implementing the req. . Degree of requirements stability . New technology, software, etc. . Little or no modeling done . No as-is models to leverage Validation . Untestable requirements . Requirement not linked/traced to . Requirements not signed off business problem, project objective . Un-reviewed requirements or business objective . Requirements are not verified (not complete enough to allow design to begin) Management . Scope creep . Requirements are not traced . Expanding product (requirements) scope throughout the project . Change process not created or used . Requirements were not baselined . Expanding project scope Section D: BA Risk Register

List identified Risks associated with each Risk Category in the table provided. In the table above are examples of risks that would be appropriate for each section.

# Risk Category Risk Event / Consequence Prob. Impact Risk Risk Risk Response Risk Response Strategy Risk Score Rank Owner (P * I) RR1 Section E: BA Governance Plan

Determine how decisions will be made, work and requirements prioritized, change process, & approval process

Process Exists? Activity (Y/N/Needs Action Plan Modification)

Prioritization process (with criteria and technique used)

Change management process (include who will authorize changes)

Decision making process (include participants, review and approve)

Escalation plan for decision making

Requirements review and approval process

Issues management process Section F: BA Information Management Plan

Checklist

Determine how you are going to manage the business analysis information. The formality of this management plan will depend on the project approach selected (predictive vs adaptive or somewhere in between).

Activity Due Date Action Plan General BA Information Management

Determine organization of BA information

Identify storage and access needs to documentation (repository, version control, audit logs, etc.)

Define formality and level of detail needed by stakeholders

Requirements Management

Define requirement attributes and elements

Develop a traceability matrix

Identify requirements reuse opportunities

Section G1: BA Performance Evaluation Plan Who will Recipient (s) Acceptanc Unacceptabl Measurement Metric Measure / Techniques Source of data capture of metric Frequency e Criteria e Criteria the info information Actual vs. Planned Time Sheets & % deviation from plan 0-5% > 5% BA PM Weekly Business Analysis Hours BA Plan

Section G2: Solution Performance Evaluation Plan Who will Recipient (s) Acceptanc Unacceptabl Measurement Metric Measure / Techniques Source of data capture of metric Frequency e Criteria e Criteria the info information First 3 months Error Number of errors found Number of errors logged by Solution after 0-5 > 5 reporting by BA in production the help desk Owner implementatio the Help Desk n Section H: Issue Log

Capture any outstanding issues that need to be addressed before this plan is complete. Assigned Date Date Action Item / Issue To: Raised Resolved Taken

Section I: Planning Assumptions

Capture the assumptions that went into your plan & determine the impact on any decisions, requirements, or plans that were made based on that assumption

Assumption Impact on decisions, requirements or plans