Business Analysis and the IIBA Business Analysis Body of Knowledge (BA

Business Analysis and BABOK (Business Analysis Book of Knowledge) :

Business Analysis and BABOK (Business Analysis Book of Knowledge) Alan McSweeney

Objectives:

January 9, 2011 2 Objectives To provide an overview of the importance of business analysis in project success and to introduce the Business Analysis Body of Knowledge concept and structure

Agenda:

January 9, 2011 3 Agenda Business Analysis Requirements Business Analysis Body of Knowledge (BABOK) Establishment of a Business Analysis Function

Business Analysis:

January 9, 2011 4 Business Analysis Business Analysis Set of tasks, knowledge and techniques required to identify business needs and determine solutions to business problems Business analysis is the connecting layer between strategy and systems/technology Solutions Include a systems development component, but may also consist of process development or improvement or organisational change Business Analyst Works as a liaison among stakeholders in order to elicit, analyse, communicate, and validate requirements for changes to business processes, policies, and information systems Understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organisation to achieve its goals

Business Analysis Skills:

January 9, 2011 5 Business Analysis Skills Ability to develop a clear and detailed understanding of: The requirements to solve a business problem, often with a system implementation/solution selection How the proposed system or solution will interoperate or integrate with the existing systems and technology in which the new system will operate How the proposed system or solution fits the existing enterprise architecture and business strategy The business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc.

Roles of the Business Analyst:

January 9, 2011 6 Roles of the Business Analyst Gather requirements Document processes Identify improvement opportunities Document business requirements Act as the liaison between users and system/solution/technical architects

Roles of the Business Analyst:

January 9, 2011 7 Roles of the Business Analyst Gathers data that is unstructured – comments/information/discussions/interviews from/with users) Converts that data into information in a structured format Converts that information into knowledge that is structured and usable Develop requirements for change to: Business processes Information systems Understand business problems and opportunities Provide recommendations for solutions Be an advocate for the business user Work as a liaison among stakeholders

Importance of Business Analysis:

January 9, 2011 8 Importance of Business Analysis A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements Half of all bugs can be traced to requirement errors Fixing these errors consumes 75% of project rework costs 25%- 40% percent of all spending on projects is wasted as a result of re-work 66% of software projects do not finish on time or on budget 56% of project defects originate in the requirements phase of the project Completed projects have only 52% of proposed functionality 75-80% of IT project failures are the result of requirements problems The average project exceeds its planned schedule by 120% 53% of projects will cost 189% of their original estimate 30% of projects are cancelled before completion 50% of projects are rolled back out of production The typical project expends least effort on analysis where most errors originate and whose errors cost most to fix Requirements errors cost the most and that poor requirements are the main cause of software failure

Factors for Project Success:

January 9, 2011 9 Factors for Project Success Effective and targeted project management and systems engineering processes, tools, and techniques Appropriate executive decision making Effective project leadership High-performing teams Collaboration and respect between the business and IT communities Business analysis processes that ensure the development team will have a clear understanding of the customer’s overall business and information needs

IT and Business Analysis:

January 9, 2011 10 IT and Business Analysis IT need to possess expertise in multiple domains IT must prove it can understand business realities- industry, core processes, customer bases, regulatory environment Contribute real business value to their enterprise

Align Business Analysis to Solution Lifecycles:

January 9, 2011 11 Align Business Analysis to Solution Lifecycles Strategy, Business Planning and Business Analysis Project Management Cycle Solution Delivery - Implementation and Deployment Lifecycle Business Concept Initial Discovery Requirements Elicitation Decision to Proceed Requirements Management and Change Management Operations and Use Initiate Plan Execute and Control Close Setup and Prepare Implement Develop Test Deploy Manage Evolve Solution Architecture and Design Solution Architecture Solution Design Solution Specification and Change Management Business Analysis exists in wider context

Business Analysis Challenges :

January 9, 2011 12 Business Analysis Challenges Lack of advance planning for projects and initiatives Lack of formal training for Business Analysts Inconsistent approach to business analysis Outsourcing and relying on external contractors to perform major roles in system development Impatience with the analysis/design/planning process Gap between what Business Analysts are assigned to do and what they should be assigned to do

Why Projects Fail:

January 9, 2011 13 Why Projects Fail Very significant Business/IT pain point All too frequent implementation of IT solutions that fail to meet business requirements Look at the general causes of those failures Look for solutions whose implementation will address those causes Projects fail to deliver solutions that meet requirements because of some combination of some or all of the following conditions Poor understanding of the business need or problem Poorly defined and/or stated requirements Inadequately explored solution options Poor solution design Misalignment between requirements and project scope Poor project planning/execution Poor change management Many of these are related to business analysis and related activities Cannot separate project management, project portfolio management, business analysis and solution architecture

Avoiding Project Failures:

January 9, 2011 14 Avoiding Project Failures Poor understanding of the business need or problem Implement effective requirements elicitation processes Implement business analysis processes and governance Poorly defined and/or stated requirements Gather requirements effectively Communicate requirements clearly to stakeholders Involve all relevant stakeholders appropriately Inadequately explored solution options Implement solution architecture standards and governance Conduct format cost/benefit analyses Reuse existing components Poor solution design Translate requirements into design Validate design Implement solution design standards and governance

Avoiding Project Failures:

January 9, 2011 15 Avoiding Project Failures Misalignment between requirements and project scope Requirements drive scope of project, transition and operational aspects of the proposed solution Translate requirements into IT language Poor project planning/execution Monitor deliverables Ensure quality Implement effective project management and governance Poor change management Implement effective change management and governance Effective change analysis Communicate to the solution team of changes in business requirements Communication to the business stakeholders of variations from the project charter, reflected in an updated business case

Avoiding Project Failures:

January 9, 2011 16 Avoiding Project Failures Poor Understanding Of The Business Need Or Problem Misalignment Between Requirements And Project Scope Inadequately Explored Solution Options Poor Solution Design Poor Project Planning/ Execution Poorly Defined And/Or Stated Requirements Poor Change Management Business Analysis Solution Architecture Project Management Business Analysis Ensure adequate and appropriate resources and involvement during project lifecycle

Aligning the Solutions Being Delivered:

January 9, 2011 17 Aligning the Solutions Being Delivered Need more than project management Not the complete picture Cannot treat project management in isolation Need to ensure that the solution being managed meets business requirements Need to ensure business requirements are captured Need to ensure that solutions are designed to deliver business requirements and comply with organisation’s enterprise architecture Fundamentally the project exists to manage the delivery of the solution that has been designed to meet business requirements that assist with delivery of the business plan

Complete Picture of Project Selection and Delivery :

January 9, 2011 18 Complete Picture of Project Selection and Delivery Business Analysis Programme and Project Management Solution Architecture Project Portfolio Management Structured Capture and Management of Requirements Design of Solutions to Meet Requirements Prioritisation of Projects Delivery of Projects

Frameworks and Methodologies:

January 9, 2011 19 Frameworks and Methodologies Benefits of Adoption Consistency Speed Drives Delivery Ensures Acceptance Productivity Reuse Professionalism Customer Confidence Speed Accuracy Audit Trail Cost Saving Risk Management and Reduction Potential Disadvantages Time to Adopt Cost to Adopt Suitability Too Comprehensive Cost of Use Not Currently In Use Within Risk Use of a business analysis methodology and framework can seem to impose an unnecessary burden but it delivers real benefits

Requirements:

January 9, 2011 20 Requirements

Requirements:

January 9, 2011 21 Requirements A condition or capability needed by a stakeholder to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents A documented representation of a condition or capability Focus on a particular business process or processes Describe the business need or problem and address all the functions associated with their delivery In project terms, requirements are the detailed items necessary to achieve the goals of the project Requirements analysis is key to successful project

Requirements:

January 9, 2011 22 Requirements Objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it It is all about requirements

Requirements Planning and Management:

January 9, 2011 23 Requirements Planning and Management Identify team roles: project manager, business analysts, developers, quality assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc. Identify stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc. Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes Define risk monitoring and management approach for each identified risk Define the requirements and system development method Define the requirements and system development process Manage requirements change and scope: requirements creep is a big problem Define and collect project metrics and reporting mechanisms Other project planning and project management activities

Hierarchy of Requirements – from Enterprise to Project/Initiative:

January 9, 2011 24 Hierarchy of Requirements – from Enterprise to Project/Initiative Solutions delivered by programmes and projects cascade from business vision to ultimate operation and service delivery Solutions delivered by programmes and projects need to be aligned to the overarching business vision and goal Requirements Hierarchy – from Business to Specific Initiatives Delivery and Operation

Analysis and Design Build Bridge From Business to Solution:

January 9, 2011 25 Analysis and Design Build Bridge From Business to Solution Problem Requirement Current State Business Analysis and Solution Design Solution Desired Future State Business Analysis: Elicit Requirements Analyse Communicate Validate Solution Design: Translate Requirements into Solution

Requirements Team:

January 9, 2011 26 Requirements Team Need the perspectives of all parties Requirements need to be verified by those who are contributors in solution definition Is there enough information in the requirements to build a solution that delivers the business case?

Requirements Within Solution Lifecycle:

January 9, 2011 27 Requirements Within Solution Lifecycle V Business Requirements Acceptance Test System Requirements System Testing High-Level Design Integration Testing Low-Level Design Component Testing Install and Implement Define Requirements and Design Solution Deliver Solution and Fulfil Requirements Business Concept Operational Use

Requirements:

January 9, 2011 28 Requirements Business requirements drive strategy, architecture and project/solution implementation Capturing requirements is essential Define key principles/policies/critical success factors for IT Requirements define what is to be delivered Getting requirements wrong has a substantial cost and contributes to the reasons for project failure Requirements on their own are not sufficient: solution must be designed to deliver on requirements Requirements Strategy Architecture Project/Solution Implementation Business Functional Technical Implementation

Requirements Specification:

January 9, 2011 29 Requirements Specification Requirements Specification describes what a system should do Should be produced as early as possible in the development/delivery cycle One of the most difficult aspects of system development/delivery One of the most important tasks of system development/delivery Should focus on the interactions with the user

Where Do Errors in Projects/Initiatives Arise:

January 9, 2011 30 Where Do Errors in Projects/Initiatives Arise Gaps in Requirements Development/ Implementation Solution Design Other Getting requirements right reduce risk of project failure

Relative Cost of Fixing Errors During Project Lifecycle:

January 9, 2011 31 Relative Cost of Fixing Errors During Project Lifecycle Errors/gaps/omissions become significantly more expensive to fix at later stages of project lifecycle

Complete View of Requirements Process:

January 9, 2011 32 Complete View of Requirements Process Enterprise Analysis Define the problem Define the solution scope Requirements Planning and Management Plan the requirements capture and management process Requirements Elicitation Gather the requirements Requirements Communication Present requirements Agree requirements Refine requirements Requirements Analysis and Documentation Analyse requirements Identify gaps Refine requirements Solution Assessment and Validation Define solution Ensure the solution meets the requirements

Requirements Capture and Management:

January 9, 2011 33 Requirements Management Capture – Ensure that the new requirements or change requests are captured and notated. Assess – Consider whether the changes will be actioned. Approve or reject. Change – Undertake the changes. Requirements Development Gather – Tasks relating to the initial gathering of requirements (uses numerous techniques). Analyse – Analysing and categorising requirements. Specifying them. Review – Agreeing (with the stakeholders) exactly what the requirements are. Modify if necessary to reach agreement. Gather Analyse Stages and Activities of Requirements Capture and Management Assess Capture Change Assess Capture Change Review Requirements Development Requirements Management STAGES ACTIVITIES Requirements Capture and Management

Communication and Documentation:

January 9, 2011 34 Communication and Documentation Objective is to develop an accurate understanding of the business problem and clearly articulate the solution Key components Communication skills are critical – two ways: not only clearly articulating things verbally and in writing, but also listening effectively Selecting the appropriate models, artifacts and other requirements documents formats Describing models and text artifacts clearly, accurately and concisely Key deliverable: “requirements specification” representing the BA’s “demonstrated understanding” of the business and processes that need to be handled by the system and its necessary capabilities Specifications serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc. Preparing effective presentations for clients and stakeholders

Requirements Classification:

January 9, 2011 35 Requirements Classification Business Requirements High-level statements of the goals, objectives, or needs of the enterprise Reasons why a project has been initiated, the objectives that the project will achieve Metrics that will be used to measure its success. Stakeholder Requirements Statements of the needs of stakeholders Solution Requirements Characteristics of a solution that meet business requirements and stakeholder requirements Functional Requirements Describe the behaviour and information that the solution will manage Non-Functional Requirements Describe environmental conditions under which the solution must remain effective or qualities the solution must have Transition and Implementation Requirements Capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete

Business Analysis Body of Knowledge (BABOK):

January 9, 2011 36 Business Analysis Body of Knowledge (BABOK)

Business Analysis Body of Knowledge (BABOK):

January 9, 2011 37 Business Analysis Body of Knowledge (BABOK) Developed by the IIBA ( International Institute of Business Analysis) - http://www.theiiba.org/ BABOK is the collection of knowledge within the profession of Business Analysis and reflects generally accepted practice Describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution Identifies currently accepted practices Recognises business analysis is not the same as software requirements Defined and enhanced by the professionals who apply it Captures the knowledge required for the practice of business analysis as a profession

Business Analysis Body of Knowledge (BABOK):

January 9, 2011 38 Business Analysis Body of Knowledge (BABOK) Describes in idealised approach to performing the complete range of business analysis activities Can be customised to suit the needs of an organisation and initiative

BABOK Knowledge Areas and Activity Flow:

January 9, 2011 39 BABOK Knowledge Areas and Activity Flow Business Analysis Planning and Monitoring Elicitation Enterprise Analysis Solution Assessment and Validation Requirements Management and Communication Requirements Analysis Underlying Competencies

BABOK Knowledge Areas Structure:

January 9, 2011 40 BABOK Knowledge Areas Structure Each Knowledge Area consists of a set of tasks Each task has inputs and outputs Outputs from earlier tasks can be inputs to subsequent tasks Each task has stakeholders that may potentially participate Each task can use one or more generally accepted techniques that support the practice of business analysis Task 1 Inputs 1 Outputs 1 Knowledge Area Task 2 Task N … Inputs 2 Outputs 2 Inputs N Outputs N … Stakeholders Techniques Stakeholders Techniques Stakeholders Techniques

BABOK Knowledge Areas:

January 9, 2011 41 BABOK Knowledge Areas Business Analysis Planning and Monitoring Determine which activities are necessary in order to complete a business analysis effort Identification of stakeholders, selection of business analysis techniques, the process that will be used to manage requirements, and how to assess the progress of the work Elicitation Work with stakeholders to identify and understand their needs and concerns and the environment in which they work Ensure that a stakeholder’s actual underlying needs are understood Requirements Management and Communication Manage conflicts, issues and changes in order to ensure that stakeholders and the project team remain in agreement on the solution scope Communicate requirements to stakeholders Knowledge gained by the business analyst is maintained for future use Enterprise Analysis Identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business Requirements Analysis Prioritise and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organisation and stakeholders

BABOK Knowledge Areas and Constituent Tasks:

January 9, 2011 42 BABOK Knowledge Areas and Constituent Tasks

BABOK Techniques:

January 9, 2011 43 BABOK Techniques Acceptance and Evaluation Criteria Definition Brainstorming Business Rules Analysis Data Dictionary and Glossary Data Flow Diagrams Data Modelling Decision Analysis Document Analysis Interviews Metrics and Key Performance Indicators Non-functional Requirements Analysis Organisation Modelling Problem Tracking Process Modelling Requirements Workshops Scenarios and Use Cases

Related Business Analysis Skills, Techniques and Frameworks:

January 9, 2011 44 Related Business Analysis Skills, Techniques and Frameworks Agile Development Business Intelligence Business Process Management Business Rules Decision Analysis Enterprise Architecture Governance and Compliance Frameworks IT Service Management Lean and Six Sigma Organisational Change Management Project Management Quality Management Service Oriented Architecture Software Engineering (particularly Requirements Engineering) Software Process Improvement Software Quality Assurance Strategic Planning Usability and User Experience Design

Business Analysis Planning and Monitoring - Tasks :

January 9, 2011 45 Business Analysis Planning and Monitoring - Tasks

Business Analysis Planning and Monitoring Knowledge Area:

January 9, 2011 46 Business Analysis Planning and Monitoring Knowledge Area Identifying stakeholders Defining roles and responsibilities of stakeholders in the business analysis effort Developing estimates for business analysis tasks Planning how the business analyst will communicate with stakeholders Planning how requirements will be approached, traced, and prioritised Determining the deliverables that the business analyst will produce Defining and determining business analysis processes Determining the metrics that will be used for monitoring business analysis work Monitoring and reporting on work performed to ensure that the business analysis effort produces the expected outcomes

Business Analysis Planning and Monitoring - Inputs and Outputs:

January 9, 2011 47 Business Analysis Planning and Monitoring - Inputs and Outputs Plan Business Analysis Approach Business Analysis and Performance Metrics Business Need Enterprise Architecture Expert Judgement Organisational Process Assets Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Plan Business Analysis Approach:

January 9, 2011 48 Task - Plan Business Analysis Approach Plan Business Analysis Approach Business Analysis and Performance Metrics Business Need Enterprise Architecture Expert Judgement Organisational Process Assets Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Plan Business Analysis Approach:

January 9, 2011 49 Task - Plan Business Analysis Approach Focus on minimising up-front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximise control and minimise risk Preferred in situations where requirements can effectively be defined in advance of implementation, the risk of an incorrect implementation is unacceptably high, or when managing stakeholder interactions presents significant challenges Focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution Preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution Plan Driven Approach Change Driven Approach Spectrum of Options

Elements of Task - Plan Business Analysis Approach (1):

January 9, 2011 50 Elements of Task - Plan Business Analysis Approach (1) Timing of Business Analysis Work When the business analysis efforts should occur When tasks need to be performed Will the level of business analysis effort will need to vary over time Will enterprise analysis, requirements analysis, and solution assessment and validation activities will be performed primarily in specific project phases or iteratively over the course of the initiative Formality And Level Of Detail Of Business Analysis Deliverables Will requirements be delivered as formal documentation or through informal communication with stakeholders What is appropriate level of detail that should be contained in these documents Expected deliverables must be defined as part of the approach Requirements Prioritisation How will requirements will be prioritised and how those priorities will be used to define the solution scope Change Management What is expected likelihood and frequency of change Ensure that the change management process is effective for those levels of change Effective business analysis practices can significantly reduce the amount of change required in a stable business environment but cannot eliminate it entirely

Elements of Task - Plan Business Analysis Approach (2):

January 9, 2011 51 Elements of Task - Plan Business Analysis Approach (2) Business Analysis Planning Process Determine the process that will be followed to plan the execution of businesses analysis activities Ensure this integrated with the larger project plan Communication With Stakeholders Decide how communications with regard to project decision-making and approval of deliverables are to be made Requirements Analysis and Management Tools Identify any requirements analysis or management tools that will be used. Project Complexity The complexity of the project, the nature of the deliverables, and the overall risk to the business needs to be taken into consideration

Project Complexity Factors:

January 9, 2011 52 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

Output of Task - Plan Business Analysis Approach:

January 9, 2011 53 Output of Task - Plan Business Analysis Approach Definition of the approach that will be taken for business analysis in a given initiative Specify team roles, deliverables, analysis techniques, the timing and frequency of stakeholder interactions, and other elements of the business analysis process Decision about which organisational process assets will be applied and any decisions made regarding tailoring of the process for a specific situation

Task - Conduct Stakeholder Analysis :

January 9, 2011 54 Task - Conduct Stakeholder Analysis Plan Business Analysis Approach Business Analysis and Performance Metrics Business Need Enterprise Architecture Expert Judgement Organisational Process Assets Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Conduct Stakeholder Analysis :

January 9, 2011 55 Task - Conduct Stakeholder Analysis Identify stakeholders who may be affected by a proposed initiative or who share a common business need Identify appropriate stakeholders for the project or project phase Determine stakeholder influence and/or authority regarding the approval of project deliverables

Elements of Task - Conduct Stakeholder Analysis (1) :

January 9, 2011 56 Elements of Task - Conduct Stakeholder Analysis (1) Identification Who are the stakeholders are and what is the impact of proposed changes on them Understand what needs, wants, and expectations must be satisfied by the solution Requirements are based on stakeholder needs, wants, and expectations Those that are uncovered either late or not at all could require a revision to requirements that changes or nullifies completed tasks or tasks already in progress, increasing costs and decreasing stakeholder satisfaction Complexity of Stakeholder Group Number and variety of direct end users Number of interfacing business processes and automated systems Authority Levels For Business Analysis Work Which stakeholders have authority over business analysis activities for both business analysis work and product deliverables Approve the deliverables Inspect and approve the requirements Request and approve changes Approve the requirements process that will be used Review and approve the traceability structure Veto proposed requirements or solutions (individually or in a group)

Elements of Task - Conduct Stakeholder Analysis (2):

January 9, 2011 57 Elements of Task - Conduct Stakeholder Analysis (2) Attitude and Influence Assess stakeholder attitudes toward and influence over the initiative The business goals, objectives, and solution approach Do they believe that the solution will benefit the organisation? Will the benefits affect them directly? Will the benefits be accrued elsewhere? Are the possible negative effects of the initiative on this stakeholder greater than the rewards? Do they believe that the project team can successfully deliver the solution? Attitude towards business analysis: Do they see value in defining their requirements? Do they present solutions and expect the requirements to be contained in that solution, and believe that this will enable them to avoid requirements definition? Attitude towards collaboration: Have they had success on previous collaborative efforts? Does the organisation reward collaboration? Is the organisation hierarchical in nature, rather than being team-based? Are personal agendas the norm? Attitude towards the sponsor: On cross-functional efforts, do all the subject matter experts support the sponsor? Are there subject matter experts who would prefer another sponsor? Attitude towards team members: Have key members of the project team (including but not limited to the business analyst) built trusting relationships or have there been prior failed projects or project phases involving those people?

Stakeholder Matrix:

January 9, 2011 58 Stakeholder Matrix Ensure stakeholder remains satisfied Work closely with stakeholder to ensure that they are in agreement with and support the change Monitor to ensure stakeholders interest or influence do not change Keep informed; stakeholder is likely to be very concerned and may feel anxious about lack of control High Low Low High Impact on Stakeholder Influence of Stakeholder

Stakeholder Onion Diagram:

January 9, 2011 59 Stakeholder Onion Diagram Solution Delivery Affected Organisational Unit Organisation or Enterprise Affected External Stakeholders Customers, suppliers, regulators, and others Sponsors, executives, domain SMEs, and others who interact with the affected group End users, help desk, and others whose work changes when the solution is delivered Project team and others directly involved with creating the solution

Output of Task - Conduct Stakeholder Analysis:

January 9, 2011 60 Output of Task - Conduct Stakeholder Analysis Stakeholder List, Roles, and Responsibilities List of required roles Names and titles of stakeholders Category of stakeholder Location of stakeholders Special needs Number of individuals in this stakeholder role Description of stakeholder influence and interest Documentation of stakeholder authority levels

Task - Plan Business Analysis Activities :

January 9, 2011 61 Task - Plan Business Analysis Activities Plan Business Analysis Approach Business Analysis Approach BA Performance Assessment Organisational Process Assets Stakeholder List, Roles, and Responsibilities Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Plan Business Analysis Activities:

January 9, 2011 62 Task - Plan Business Analysis Activities Determine the activities that must be performed and the deliverables that must be produced Determine the scope of work for the business analysis activities Estimate the effort required to perform that work Identify the management tools required to measure the progress of those activities and deliverables

Elements of Task - Plan Business Analysis Activities (1):

January 9, 2011 63 Elements of Task - Plan Business Analysis Activities (1) Geographic Distribution of Stakeholders Consider the physical location of key stakeholders on the project Outsourced development project where the development team is physically located time zones away Type of Project or Initiative Type of project or initiative will have a significant impact on the activities that need to be performed Feasibility studies Process improvement Organisational change New software development (in-house) Outsourced new software development Software maintenance or enhancement Software package selection Business Analysis Deliverables List of deliverables is useful as a basis for activity identification Interviews or facilitated sessions with key stakeholders Review project documentation Review organisational process assets

Elements of Task - Plan Business Analysis Activities (2):

January 9, 2011 64 Elements of Task - Plan Business Analysis Activities (2) Determine Business Analysis Activities Define the scope of work and in developing estimates using work breakdown structure (WBS) Activities and tasks creates Activity List

Output of Task - Plan Business Analysis Activities:

January 9, 2011 65 Output of Task - Plan Business Analysis Activities Business Analysis Plan Description of the scope of work, the deliverable Work Breakdown Structure Activity List Estimates for each activity and task How the plan should be changed in response to changing conditions Level of detail associated with the plan is determined by the business analysis approach

Task - Plan Business Analysis Communication :

January 9, 2011 66 Task - Plan Business Analysis Communication Plan Business Analysis Approach Business Analysis Approach Business Analysis Plan(s) Stakeholder List, Roles, and Responsibilities Organisational Process Assets Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Plan Business Analysis Communication:

January 9, 2011 67 Task - Plan Business Analysis Communication Business analysis communications plan describes the proposed structure and schedule for communications regarding business analysis activities Basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications Determine how best to receive, distribute, access, update, and escalate information from project stakeholders Determine how best to communicate with each stakeholder Requirements should be presented in formats that are understandable for the reviewer Must be clear, concise, accurate, and at the appropriate level of detail

Task - Plan Business Analysis Communication:

January 9, 2011 68 Task - Plan Business Analysis Communication Issues What needs to be communicated What is the appropriate delivery method Who is the appropriate audience When the communication should occur Needs and constraints relevant to communication Physical location/time zone of the stakeholders Communication approach for the stakeholder What types of communications will be required (e.g. status, anomalies, issues and their resolution, risks, meeting results, action items, etc.) What types of requirements will be elicited (business, stakeholder, solution, or transition; high level vs. detailed) and how best to elicit them How best to communicate requirements conclusions/packages, including authority level (signoff authority, veto authority, or review only) Time and resource availability constraints

Elements of Task - Plan Business Analysis Communication (1):

January 9, 2011 69 Elements of Task - Plan Business Analysis Communication (1) Geography Communications needed for a team that is collocated will be different from communications required for a project with geographically dispersed stakeholders Culture Cultural issues should also be taken into account when planning communications Attitude to time Attitude to task completion Attitude to contracts Attitude to formal and informal authority

Elements of Task - Plan Business Analysis Communication (2):

January 9, 2011 70 Elements of Task - Plan Business Analysis Communication (2) Project Type Different projects will necessitate different deliverables Extent of documentation needed in a requirements package will vary depending on the project New, customised in-house software development project Upgrading the technology or infrastructure of a current system Change in a business process or new data for an existing application Purchase of a software package Short, focused, agile style iterations of software development Communication Frequency Frequency required by various stakeholders for each type of communication Communications Formality Level of formality needed Varies from stakeholder to stakeholder, project phase to project phase, work within a project phase, and requirements presentation

Outputs of Task - Plan Business Analysis Communication:

January 9, 2011 71 Outputs of Task - Plan Business Analysis Communication Business Analysis Communication Plan How, when and why the business analyst will work directly with stakeholders Stakeholder communications requirements for business analysis activities Format, content, medium, level of detail Responsibility for collecting, distributing, accessing, and updating information

Task - Plan Requirements Management Process :

January 9, 2011 72 Task - Plan Requirements Management Process Plan Business Analysis Approach Business Analysis Approach Business Analysis Plan(s) Organisational Process Assets Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Plan Requirements Management Process :

January 9, 2011 73 Task - Plan Requirements Management Process Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope 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 Assess the need for requirements traceability and determine which requirements attributes will be captured

Elements of Task - Plan Requirements Management Process (1):

January 9, 2011 74 Elements of Task - Plan Requirements Management Process (1) Repository Method of storing requirements, including those under development, those under review and approved Process for adding, changing and deleting requirements should be consistent and clearly understood by all Traceability Determine whether and how to trace requirements Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to have value Select Requirements Attributes Attributes provide information about requirements such as source, importance and other metadata Assists in efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a proposed change Reference Author Complexity Ownership Priority Risks Source Stability Status Urgency Cost Resource assignment Revision number Traced from Traced to

Elements of Task - Plan Requirements Management Process (2):

January 9, 2011 75 Elements of Task - Plan Requirements Management Process (2) Requirements Prioritisation Process Not all requirements deliver the same value to stakeholders Prioritisation focuses effort on determining which requirements should be investigated first, based on the risk, cost to deliver, benefits they will produce or other factors Planning requirement prioritisation ensures that stakeholders determine and understand how requirements will be prioritised throughout and at the end of the business analysis effort Change Management Process for requesting changes Who will authorise changes Change analysis Tailoring the Requirements Management Process Requirements management process may need to be tailored to meet the needs of a specific initiative or project Organisational culture Stakeholder preferences Complexity of project, project phase, or product Number of interfaces, business and/or system impacts or spanning a variety of functional areas Many components and subcomponents, have complex interfaces, will be used by a variety and number of stakeholders or have other complexities Organisational maturity Availability of resources

Output of Task - Plan Requirements Management Process:

January 9, 2011 76 Output of Task - Plan Requirements Management Process Requirements Management Plan Approach to be taken to structure traceability Definition of requirements attributes to be used Requirements prioritisation process Requirements change process, including how changes will be requested, analysed, approved, and implemented

Task - Manage Business Analysis Performance:

January 9, 2011 77 Task - Manage Business Analysis Performance Plan Business Analysis Approach Business Analysis and Performance Metrics Business Analysis Plan(s) Organisational Process Assets Conduct Stakeholder Analysis Plan BA Activities Plan BA Communications Plan Requirements Management Process Manage BA Performance Business Analysis Approach BA Communication Plan BA Performance Assessment Business Analysis Plan(s) BA Process Assets Requirements Management Plan Stakeholder List, Roles, and Responsibilities Inputs Tasks Outputs

Task - Manage Business Analysis Performance:

January 9, 2011 78 Task - Manage Business Analysis Performance Determine which metrics will be used to measure the work performed by the business analyst How organisational process assets governing business analysis activities are managed and updated Performance metrics or expectations for business analysis work

Elements of Task - Manage Business Analysis Performance:

January 9, 2011 79 Elements of Task - Manage Business Analysis Performance Performance Measures Used to set expectations regarding what constitutes effective business analysis Measures enable the business analyst to determine when problems are occurring that may affect the performance of business analysis or other activities or identify opportunities for improvement Performance Reporting Written or informal and verbal Present to various levels of stakeholders and management Preventive And Corrective Action Assess the performance measures to determine where problems in executing business analysis activities are occurring Identify opportunities for improving the business analysis process exist

Output of Task - Manage Business Analysis Performance:

January 9, 2011 80 Output of Task - Manage Business Analysis Performance Business Analysis Performance Assessment Comparison of planned versus actual performance Understanding of root cause of variances from the plan Business Analysis Process Assets Review the process that produced those results Recommendations for improvement to the business analysis process Incorporate into Organisational Process Assets

Elicitation - Tasks:

January 9, 2011 81 Elicitation - Tasks

Elicitation Knowledge Area:

January 9, 2011 82 Elicitation Knowledge Area Key task in business analysis Requirements serve as the foundation for the solution to the business Essential that the requirements be complete, clear, correct, and consistent Need to actively engage the stakeholders in defining requirements Requirements are identified throughout the elicitation, analysis, verification and validation activities When initial requirements are used to build and verify model(s), gaps may be discovered Techniques Brainstorming Document Analysis Focus Groups Interface Analysis Interviews Observation/Job Shadowing Prototyping Requirements Workshops Survey/ Questionnaire

Elicitation - Inputs and Outputs:

January 9, 2011 83 Elicitation - Inputs and Outputs Prepare for Elicitation Business Case Business Need Requirements Management Plan Solution Scope Organisational Process Assets Conduct Elicitation Activity Document Elicitation Results Confirm Elicitation Results Elicitation Results Scheduled Resources Stakeholder Concerns Supporting Materials Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities

Task - Prepare for Elicitation :

January 9, 2011 84 Task - Prepare for Elicitation Prepare for Elicitation Business Case Business Need Requirements Management Plan Solution Scope Organisational Process Assets Conduct Elicitation Activity Document Elicitation Results Confirm Elicitation Results Elicitation Results Scheduled Resources Stakeholder Concerns Supporting Materials Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities

Task - Prepare for Elicitation:

January 9, 2011 85 Task - Prepare for Elicitation Ensure all needed resources are organised and scheduled for conducting the elicitation activities Build a detailed schedule for a particular elicitation activity, defining the specific activities and the planned dates

Elements of Task - Prepare for Elicitation :

January 9, 2011 86 Elements of Task - Prepare for Elicitation Clarify the specific scope for the selected elicitation technique and gathers any necessary supporting materials Schedule all resources (people, facilities, equipment) Notify appropriate parties of the plan For event-based elicitation (brainstorming, focus group, interview, observation, prototyping, requirements workshop) ground rules must be established Agree form and frequency of feedback during the elicitation process Agree mechanism for verifying and signing off on the elicited results

Output of Task - Prepare for Elicitation :

January 9, 2011 87 Output of Task - Prepare for Elicitation Scheduled Resources Includes the participants, the location in which the elicitation activity will occur, and any other resources that may be required. Supporting Materials Materials required to help explain the techniques used or perform them

Task - Conduct Elicitation Activity :

January 9, 2011 88 Task - Conduct Elicitation Activity Prepare for Elicitation Business Case Business Need Requirements Management Plan Solution Scope Organisational Process Assets Conduct Elicitation Activity Document Elicitation Results Confirm Elicitation Results Elicitation Results Scheduled Resources Stakeholder Concerns Supporting Materials Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities Supporting Materials

Task - Conduct Elicitation Activity :

January 9, 2011 89 Task - Conduct Elicitation Activity Meet with stakeholder(s) to elicit information regarding their needs Elicitation events takes place - brainstorming, focus groups, interviews, observation, prototyping, requirements workshops Event-based requirements elicitation is highly dependent on the knowledge of the stakeholders, their willingness to participate in defining requirements, and the group’s ability to reach consensus Ensure stakeholders are heard Clarify and possibly restate the requirements to encompass all stakeholders’ perspectives Elicitation is performed - document analysis, interface analysis or distributed (survey/questionnaire) Ensure that the business analyst understands what information should be elicited from the stakeholders

Elements of Task - Conduct Elicitation Activity :

January 9, 2011 90 Elements of Task - Conduct Elicitation Activity Tracing Requirements While eliciting the requirements it is important to guard against scope creep Tracing requirements back to the business goals/objectives helps to validate whether a requirement should be included Capturing Requirement Attributes Documenting requirements attributes such as the requirement’s source, value and priority will aid in managing each requirement throughout its life cycle Metrics Tracking the elicitation participants and the actual time spent eliciting the requirements provides a basis for future planning

Output of Task - Conduct Elicitation Activity :

January 9, 2011 91 Output of Task - Conduct Elicitation Activity Elicitation Results May include documentation appropriate to the technique and capture the information provided by the stakeholder

Task - Document Elicitation Results:

January 9, 2011 92 Task - Document Elicitation Results Prepare for Elicitation Elicitation Results Conduct Elicitation Activity Document Elicitation Results Confirm Elicitation Results Requirements Stated Stakeholder Concerns Inputs Tasks Outputs

Task - Document Elicitation Results:

January 9, 2011 93 Task - Document Elicitation Results Record the information provided by stakeholders for use in analysis For elicitation event (brainstorming, focus groups, interviews, observation, prototyping, requirements workshops) a summary of the output from the event, including issues is produced

Elements of Task - Document Elicitation Results:

January 9, 2011 94 Elements of Task - Document Elicitation Results Written documents and other material

Output of Task - Document Elicitation Results:

January 9, 2011 95 Output of Task - Document Elicitation Results Requirements Stated (Unconfirmed) Describe the stakeholder’s need from the stakeholder’s perspective Stakeholder Concerns (Unconfirmed) Includes issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information

Task - Confirm Elicitation Results :

January 9, 2011 96 Task - Confirm Elicitation Results Prepare for Elicitation Conduct Elicitation Activity Document Elicitation Results Confirm Elicitation Results Requirements Stated (Confirmed) Stakeholder Concerns (Confirmed) Inputs Tasks Outputs Requirements Stated (Unconfirmed) Stakeholder Concerns (Unconfirmed)

Task - Confirm Elicitation Results :

January 9, 2011 97 Task - Confirm Elicitation Results Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs

Elements of Task - Confirm Elicitation Results :

January 9, 2011 98 Elements of Task - Confirm Elicitation Results Review the documented outputs with the stakeholders to ensure that the analyst’s understanding conforms to the actual desires or intentions of the stakeholder

Output of Task - Confirm Elicitation Results :

January 9, 2011 99 Output of Task - Confirm Elicitation Results Requirements Stated (Confirmed) Describe the stakeholder’s need from the stakeholder’s perspective Stakeholder Concerns (Confirmed) Includes issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information

Requirements Management and Communication - Tasks:

January 9, 2011 100 Requirements Management and Communication - Tasks

Requirements Management and Communication Knowledge Area:

January 9, 2011 101 Requirements Management and Communication Knowledge Area Activities and considerations for managing and expressing requirements to a potentially broad and diverse audience Ensure that all stakeholders have a shared understanding of the nature of a solution Ensure that those stakeholders with approval authority are in agreement as to the requirements that the solution shall meet Communicating requirements helps to bring the stakeholders to a common understanding of the requirements Management of requirements assists with understanding the effects of change and linking business goals and objectives to the actual solution that is constructed and delivered Over the long term, ensures that the knowledge and understanding of the organisation gained during business analysis is available for future use

Requirements Management and Communication - Inputs and Outputs:

January 9, 2011 102 Requirements Management and Communication - Inputs and Outputs Manage Solution Scope and Requirements Business Analysis Communication Plan Requirements Requirements Management Plan Requirements Structure Organisational Process Assets Manage Requirements Traceability Maintain Requirements for Re-use Prepare Requirements Package Requirements (Approved) Requirements (Communicated) Requirements (Maintained and Reusable) Requirements (Traced) Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities Solution Scope Communicate Requirements Requirements Package

Task - Manage Solution Scope and Requirements :

January 9, 2011 103 Task - Manage Solution Scope and Requirements Manage Solution Scope and Requirements Requirements Management Plan Solution Scope Stakeholder List, Roles, and Responsibilities Stakeholder, Solution and Transition Requirements Manage Requirements Traceability Maintain Requirements for Re-use Prepare Requirements Package Requirements (Maintained and Reusable) Assess Proposal Solution Allocate Requirements Inputs Tasks Outputs Communicate Requirements

Task - Manage Solution Scope and Requirements :

January 9, 2011 104 Task - Manage Solution Scope and Requirements Secure approval of requirements from those stakeholders who have the appropriate authority Manage issues that emerge during elicitation Baseline requirements after approval Any changes to requirements after baselining, if changes are permitted, involves use of a change control process and subsequent approval Solution scope is required as a basis for requirements management If business needs change during the lifetime of an initiative, the solution scope must also change Changes to the solution scope may also lead to changes in previously approved requirements that may not support the revised scope

Elements of Task - Manage Solution Scope and Requirements :

January 9, 2011 105 Elements of Task - Manage Solution Scope and Requirements Solution Scope Management Assess stakeholder and solution requirements to ensure that they fall within the solution scope Conflict and Issue Management Conflicts often arise when requirements are developed and reviewed Conflicts that affect the requirements must be resolved before formal approval is given to those requirements Presenting Requirements For Review Determine how requirements will be presented to various stakeholders and whether presentations will be formal or informal Assess the requirements, audience, and organisational process assets to determine the level of formality appropriate for business analysis communication When presenting requirements for review and approval, there needs to be enough formality to support the methodology and ensure that the stakeholders will review, understand, and approve them Approval Ensure that the stakeholder(s) responsible for approving requirements understands and accepts the requirements Record decisions

Output of Task - Manage Solution Scope and Requirements:

January 9, 2011 106 Output of Task - Manage Solution Scope and Requirements Requirements (Approved) Requirements which are agreed to by stakeholders and ready for use in subsequent business analysis or implementation efforts

Task - Manage Requirements Traceability :

January 9, 2011 107 Task - Manage Requirements Traceability Manage Solution Scope and Requirements Requirements Requirements Management Plan Requirements Management Plan Requirements Structure Organisational Process Assets Manage Requirements Traceability Maintain Requirements for Re-use Prepare Requirements Package Requirements (Approved) Requirements (Communicated) Requirements (Maintained and Reusable) Requirements (Traced) Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities Solution Scope Communicate Requirements Requirements Package

Task - Manage Requirements Traceability :

January 9, 2011 108 Task - Manage Requirements Traceability Create and maintain relationships between business objectives, requirements and solution components Requirements are related to other requirements, to solution components and to other elements such as test cases Tracing links business requirements to stakeholder and solution requirements, to other artifacts produced by the team and to solution components Traceability is used to help ensure solution conformance to requirements Used to detect missing functionality or to identify if implemented functionality is not supported by a specific requirement When a requirement is changed, the business analyst can easily review all of the related requirements and software components in order to understand the impact of the change

Elements of Task - Manage Requirements Traceability :

January 9, 2011 109 Elements of Task - Manage Requirements Traceability Relationships Records the dependencies and relationships for each of the requirements Dependencies and relationships between requirements helps when determining the sequence in which requirements are to be addressed Impact Analysis Evaluate the impact of a change When a requirement changes, its relationships to other requirements or system components can be reviewed Allows decision makers evaluate options with facts Configuration Management System Requirements management tool is generally needed to trace large numbers of requirements

Output of Task - Manage Requirements Traceability :

January 9, 2011 110 Output of Task - Manage Requirements Traceability Requirements traceability matrix showing requirements’ relationships to other requirements within the solution scope such that it is relatively easy to identify the effects on other requirements of a change

Task - Maintain Requirements for Re-use:

January 9, 2011 111 Task - Maintain Requirements for Re-use Manage Solution Scope and Requirements Business Analysis Communication Plan Requirements Requirements Management Plan Requirements Structure Organisational Process Assets Manage Requirements Traceability Maintain Requirements for Re-use Prepare Requirements Package Requirements (Approved) Requirements (Communicated) Requirements (Maintained and Reusable) Requirements (Traced) Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities Solution Scope Communicate Requirements Requirements Package

Task - Maintain Requirements for Re-use:

January 9, 2011 112 Task - Maintain Requirements for Re-use M anage knowledge of requirements following their implementation Identify requirements that have the potential for long-term usage by the organisation To facilitate re-use requirements must be clearly named and defined and easily available Maintenance of requirements assists in impact analysis of changes and reduces analysis time and effort

Elements of Task - Maintain Requirements for Re-use:

January 9, 2011 113 Elements of Task - Maintain Requirements for Re-use Ongoing Requirements Requirements that an organisational unit is required to be able to meet on a continuous basis Contractual obligations Quality standards Service level agreements Business rules Business processes Satisfied Requirements

Output of Task - Maintain Requirements for Re-use:

January 9, 2011 114 Output of Task - Maintain Requirements for Re-use Requirements expressed in a form that makes them suitable for long-term use by the organisation Unapproved requirements can be maintained for possible future initiatives

Task - Prepare Requirements Package:

January 9, 2011 115 Task - Prepare Requirements Package Manage Solution Scope and Requirements Business Analysis Communication Plan Requirements Requirements Management Plan Requirements Structure Organisational Process Assets Manage Requirements Traceability Maintain Requirements for Re-use Prepare Requirements Package Requirements (Approved) Requirements (Communicated) Requirements (Maintained and Reusable) Requirements (Traced) Inputs Tasks Outputs Stakeholder List, Roles, and Responsibilities Solution Scope Communicate Requirements Requirements Package

Task - Prepare Requirements Package:

January 9, 2011 116 Task - Prepare Requirements Package Primary objective requirements package is to convey information clearly and in an understandable fashion Create set of requirements to ensure that they are effectively communicated to, understood by, and usable by stakeholders Requirements Specification Presentation Material Process Models and Maps Requirements package should support subsequent phases of initiative activities and deliverables Misunderstandings will adversely affect initiative implementation, leading to re-work and cost overruns, especially if gaps are discovered late in the process

Elements of Task - Prepare Requirements Package:

January 9, 2011 117 Elements of Task - Prepare Requirements Package Work Products and Deliverables Meeting agendas and minutes Interview questions and notes Facilitation session agendas and notes Issues log Work plans Status reports Presentation slides used during the project Traceability matrices Format Depends on initiatives and requirements Select the most appropriate formats to present the material to convey an effective message to those participating in the requirements review process If the purpose of the package is to obtain formal approval, the requirements documentation should be complete in order to prepare the requirements package

Output of Task - Prepare Requirements Package:

January 9, 2011 118 Output of Task - Prepare Requirements Package A requirements document, presentation or package of requirements ready to be reviewed by stakeholders Package can contain all of the project requirements or can be broken into several sub-packages

Task - Communicate Requirements:

January 9, 2011 119 Task - Communicate Requirements Manage Solution Scope and Requirements Business Analysis Communication Plan Requirements Requirements Package Manage Requirements Traceability Maintain Requirements for Re-use Prepare Requirements Package Requirements (Approved) Requirements (Communicated) Requirements (Maintained and Reusable) Requirements (Traced) Inputs Tasks Outputs Communicate Requirements Requirements Package

Task - Communicate Requirements:

January 9, 2011 120 Task - Communicate Requirements Communicating requirements is needed to ensure stakeholders have a common understanding of requirements Includes conversations, notes, documents, presentations, and discussions Concise, appropriate, effective communication requires that the business analyst possess hard and soft communication skills

Elements of Task - Communicate Requirements:

January 9, 2011 121 Elements of Task - Communicate Requirements General Communication Requirements communication is performed iteratively Requirements communication can lead to elicitation of additional requirements Enterprise Analysis Tasks - Business case and solution scoping information is communicated Elicitation Tasks - Communication of requirements may be useful during elicitation activities to help stakeholders identify other related requirements Requirements Analysis Tasks - Requirements are refined, modified, clarified and finalised through effective communication Solution Assessment and Validation Tasks - Assessments of the solution, allocation of requirements to solution components, organisational readiness, and transition requirements all must be communicated Presentations Formal or informal - based on by the objective of the communication and the audience needs Ensure that internal project quality standards have been adhered to Ensure cross-functional fit with other business process areas within the same initiative Obtain business acceptance and sign-off.. Obtain delivery team sign-off.. Obtain testing team sign-off.. Examine solution options with a delivery team Prioritise a set of requirements before proceeding to next project stage Make decisions regarding solution scope

Output of Task - Communicate Requirements:

January 9, 2011 122 Output of Task - Communicate Requirements Communicated requirements understood by stakeholders - what the requirements are and their current state

Enterprise Analysis Knowledge Area:

January 9, 2011 123 Enterprise Analysis Knowledge Area

Enterprise Analysis Knowledge Area:

January 9, 2011 124 Enterprise Analysis Knowledge Area Business analysis activities necessary to identify a business need, problem, or opportunity, define the nature of a solution that meets that need, and justify the investment necessary to deliver that solution Analyse the business situation in order to fully understand business problems and opportunities Assess the capabilities of the organisation to understand the change needed to meet business needs and achieve strategic goals Determine the most feasible business solution approach Define the solution scope and develop the business case for a proposed solution Define and document business requirements (including the business need, required capabilities, solution scope, and business case)

Enterprise Analysis - Inputs and Outputs:

January 9, 2011 125 Enterprise Analysis - Inputs and Outputs Define Business Need Enterprise Architecture Organisational Process Assets Requirements (Stated) Solution Performance Assessment Stakeholder Concerns Assess Capability Gaps Determine Solution Approach Define Solution Scope Define Business Case Business Case Business Need Required Capabilities Solution Approach Solution Scope Inputs Tasks Outputs Assumptions and Constraints Business Goals and Objectives

Task - Define Business Need:

January 9, 2011 126 Task - Define Business Need Define Business Need Enterprise Architecture Organisational Process Assets Requirements (Stated) Solution Performance Assessment Stakeholder Concerns Assess Capability Gaps Determine Solution Approach Define Solution Scope Define Business Case Business Case Business Need Required Capabilities Solution Approach Solution Scope Inputs Tasks Outputs Assumptions and Constraints Business Goals and Objectives

Task - Define Business Need:

January 9, 2011 127 Task - Define Business Need Business need defines the problem that the business analyst is trying to find a solution for High-level statement of issue Used to determine which alternative solutions will be considered, which stakeholders will be consulted, and which solution approaches will be evaluated New business needs can arise in a number of different ways: From the top down - the need to achieve a strategic goal From the bottom up - a problem with the current state of a process, function or system From business management - a manager needs additional information to make sound decisions or must perform additional functions to meet business objectives From external drivers - driven by customer demand or business competition in the marketplace Frequently organisations act to resolve an issue without investigating the underlying business need Question the assumptions and constraints that are generally buried in the statement of the business need/issue to ensure that the correct problem is being solved and the widest possible range of alternative solutions are considered

Elements of Task - Define Business Need (1):

January 9, 2011 128 Elements of Task - Define Business Need (1) Business Goals and Objectives Describes the ends that the organisation is seeking to achieve Longer-term, ongoing, and qualitative statements of a state or condition that the organisation is seeking to establish and maintain Describe briefly S pecific – describing something that has an observable outcome M easurable – tracking and measuring the outcome A chievable – testing the feasibility of the effort R elevant – in alignment with the organisation’s key vision, mission, goals T ime-bounded – the objective has a defined timeframe that is consistent with the business need Business Problem or Opportunity Adverse impacts the problem is causing Define expected benefits from any potential solution How quickly the problem could potentially be resolved and the cost of doing nothing. Underlying source of the problem

Elements of Task - Define Business Need (2):

January 9, 2011 129 Elements of Task - Define Business Need (2) Desired Outcome Not a complete defined solution Describes the business benefits that will result from meeting the business need and the end state desired by stakeholders Proposed solutions must be evaluated against desired outcomes to ensure that they can deliver those outcomes Desired outcomes should address a problem or opportunity and support the business goals and objectives

Output of Task - Define Business Need:

January 9, 2011 130 Output of Task - Define Business Need Business need describes a problem that the organisation is (or is likely to) face or an opportunity that it has not taken, and the desired outcome Guides the identification and definition of possible solutions

Task - Assess Capability Gaps:

January 9, 2011 131 Task - Assess Capability Gaps Define Business Need Solution Performance Assessment Assess Capability Gaps Determine Solution Approach Define Solution Scope Define Business Case Business Case Business Need Required Capabilities Solution Approach Solution Scope Inputs Tasks Outputs Business Need Enterprise Architecture

Task - Assess Capability Gaps:

January 9, 2011 132 Task - Assess Capability Gaps Identify new capabilities required by the enterprise to meet the business need Assess the current capabilities of the organisation and identify the gaps that prevent it from meeting business needs and achieving desired outcomes Determine if the organisation can meet the business need using its existing structure, people, processes, and technology May be needed to launch a project to create capability Change may be needed to the organisation Business processes Functions Lines of business Organisation structure Staff competencies, knowledge and skills, training Facilities Locations Data and information Application systems Technology infrastructure

Elements of Task - Assess Capability Gaps:

January 9, 2011 133 Elements of Task - Assess Capability Gaps Current Capability Analysis Gather enterprise architecture information about the current state of the areas of the organisation affected by the business need Assess against the desired objectives to determine whether the organisation currently has the capability to meet the business need Assessment of New Capability Requirements If current capabilities are insufficient to meet the business need, identify the capabilities that need to be added Develop the models and other descriptive information about the future vision and describe the future state of the organisation Identify gaps in organisational capabilities that need to be filled to support the business vision, strategy, goals and objectives Assumptions Can be difficult to prove that the delivery of a new capability will meet a business need Identify assumptions and ensure they are clearly understood so that appropriate decisions can be made if the assumption later proves invalid

Output of Task - Assess Capability Gaps:

January 9, 2011 134 Output of Task - Assess Capability Gaps An understanding of the current capabilities of the organisation and the new capabilities (processes, staff, features in an application, etc.) that may be required to meet the business need

Task - Determine Solution Approach:

January 9, 2011 135 Task - Determine Solution Approach Define Business Need Required Capabilities Assess Capability Gaps Determine Solution Approach Define Solution Scope Define Business Case Business Case Business Need Required Capabilities Solution Approach Solution Scope Inputs Tasks Outputs Business Need Organisational Process Assets

Task - Determine Solution Approach:

January 9, 2011 136 Task - Determine Solution Approach Determine the most viable solution approach to meet the business need in enough detail to allow for definition of solution scope and prepare the business case Describes the general approach that will be taken to create or acquire the new capabilities required to meet the business need Identify possible approaches, determine the means by which the solution may be delivered (including the methodology and lifecycle to be used) and assess whether the organisation is capable of implementing and effectively using a solution Utilise additional capabilities of existing software/hardware that already is available within the organisation Purchase or lease software/hardware Design and develop custom software Add resources to the business or make organisational changes Change the business procedures/processes Partner with other organisations, or outsource work to suppliers

Elements of Task - Determine Solution Approach:

January 9, 2011 137 Elements of Task - Determine Solution Approach Alternative Generation Identify potential options as possible to meet the business objectives and fill identified gaps in capabilities Include the option of doing nothing as well as investigating interim solutions alternatives that may allow the organisation to buy time Assumptions and Constraints Assumptions may affect the chosen solution should be identified Question assumptions and constraints to ensure that they are valid Ranking and Selection of Approaches Analyse the operational, economic, technical, schedule-based, organisational, cultural, legal and marketing feasibility Capture consistent information for each option to make comparison easier and review to ensure accuracy and completeness Used weighted scoring to reflect relative importance of objectives

Output of Task - Determine Solution Approach:

January 9, 2011 138 Output of Task - Determine Solution Approach Description of the solution approach that will be taken to implement a new set of capabilities Solution approaches describe the types of solution components that will be delivered (new processes, a new software application, etc.) May also describe the methodology and approach that will be used to deliver those components

Task - Define Solution Scope:

January 9, 2011 139 Task - Define Solution Scope Define Business Need Required Capabilities Solution Approach Assess Capability Gaps Determine Solution Approach Define Solution Scope Define Business Case Business Case Business Need Required Capabilities Solution Approach Solution Scope Inputs Tasks Outputs Assumptions and Constraints Business Need

Task - Define Solution Scope:

January 9, 2011 140 Task - Define Solution Scope Define which new capabilities a project or iteration will deliver Conceptualise the recommended solution in sufficient detail to enable stakeholders to understand which new business capabilities an initiative will deliver Solution scope will change throughout a project, based on changes in the business environment or as the project scope is changed to meet budget, time, quality, or other constraints The scope of analysis (the organisational unit or process for which requirements are being developed) that provides the context in which the solution is implemented The capabilities supported by solution components, such as business processes, organisational units, and software applications The capabilities to be supported by individual releases or iterations The enabling capabilities that are required in order for the organisation to develop the capabilities required to meet the business need.

Elements of Task - Define Solution Scope:

January 9, 2011 141 Elements of Task - Define Solution Scope Solution Scope Definition Describe solution in terms of the major features and functions Detail solution interactions with people and systems outside of its scope Define the business units that will be involved Describe business processes to be improved or redesigned, process owners, and IT systems and other technology that will likely be affected Implementation Approach Describe how the chosen solution approach will deliver the solution scope Describe the implementation approach Provide a roadmap that indicates the timeframe in which a capability can be expected Dependencies Define major business and technical dependencies that will impose constraints to the effort to deploy the solution, including dependencies that may exist between solution components

Output of Task - Define Solution Scope:

January 9, 2011 142 Output of Task - Define Solution Scope Solution scope that defines what must be delivered in order to meet the business need The effect of the proposed change initiative on the business and technology operations and infrastructure

Task - Define Business Case:

January 9, 2011 143 Task - Define Business Case Define Business Need Solution Scope Stakeholder Concerns Assess Capability Gaps Determine Solution Approach Define Solution Scope Define Business Case Business Case Business Need Required Capabilities Solution Approach Solution Scope Inputs Tasks Outputs Assumptions and Constraints Business Need

Task - Define Business Case:

January 9, 2011 144 Task - Define Business Case Determines if the organisation can justify the investment required to deliver a proposed solution Describes the justification for the project in terms of the value to be added to the organisation as a result of the deployed solution when compared to the cost to develop and operate the solution Defines how the initiative is expected to achieve organisation objectives Lists the constraints associated with the proposed project Defines the estimated budget and expected cash flow Describes alignment with strategies established by the organisation Lists the methods and rationale that were used for quantifying benefits and costs States assumptions

Elements of Task - Define Business Case:

January 9, 2011 145 Elements of Task - Define Business Case Benefits Estimates the benefits to the organisation of the recommended solution in terms of both qualitative and quantitative gains Non-financial benefits such as improved staff morale, increased flexibility to respond to change, improved customer satisfaction, or reduced exposure to risk should be stated with care Benefits should relate back to strategic goals and objectives Costs Estimate of the total net cost of the solution Total cost of ownership to support the new solution and consequential costs incurred by others Risk Assessment Determine if the proposed initiative carries more risk than the organisation is willing to tolerate Solution feasibility risks Technical risks Financial risks Business change and organisational risks Results Measurement Defines how those costs and benefits will be assessed and evaluated

Output of Task - Define Business Case:

January 9, 2011 146 Output of Task - Define Business Case Presents the information necessary to support a go/no go decision to invest and move forward with a proposed project

Requirements Analysis Knowledge Area:

January 9, 2011 147 Requirements Analysis Knowledge Area

Requirements Analysis - Inputs and Outputs:

January 9, 2011 148 Requirements Analysis - Inputs and Outputs Prioritise Requirements Business Case Business Need Requirements Organisational Process Assets Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder, Solution and Transition Requirements Inputs Tasks Outputs Requirements Management Plan Stakeholder Concerns Stakeholder List, Roles and Responsibilities Solution Scope

Task - Prioritise Requirements:

January 9, 2011 149 Task - Prioritise Requirements Prioritise Requirements Business Case Business Need Requirements Organisational Process Assets Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder, Solution and Transition Requirements Inputs Tasks Outputs Requirements Management Plan Stakeholder Concerns Stakeholder List, Roles and Responsibilities Solution Scope

Task - Prioritise Requirements:

January 9, 2011 150 Task - Prioritise Requirements Ensures that analysis and implementation efforts focus on the most critical requirements Decision process used to determine the relative importance of requirements Importance can be based on their relative value, risk, difficulty of implementation, or on other criteria Priorities used to determine which requirements should be targetted for further analysis and to determine which requirements should be implemented first

Elements of Task - Prioritise Requirements (1):

January 9, 2011 151 Elements of Task - Prioritise Requirements (1) Basis for Prioritisation Business Value - based on cost-benefit analysis of their relative value to the organisation Business or Technical Risk – based on the highest risk of project failure Implementation Difficulty - selects requirements that are easiest to implement first Likelihood of Success – focus on the requirements that are likely to produce quick and relatively certain successes Regulatory or Policy Compliance - prioritises requirements that must be implemented in order to meet regulatory or policy demands imposed on the organisation Relationship to Other Requirements - not of high value but may support other high-priority requirements and therefore may be a candidate for early implementation Stakeholder Agreement - Consensus on which requirements are most useful or valuable Urgency – prioritise requirements based on time sensitivity

Elements of Task - Prioritise Requirements (2):

January 9, 2011 152 Elements of Task - Prioritise Requirements (2) Challenges Non-Negotiable Demands - stakeholders attempt to avoid difficult choices, fail to recognise the necessity for making tradeoffs, or desire to rank all requirements as high priority Unrealistic Tradeoffs - solution implementation team may intentionally or unintentionally try to influence the result of the prioritisation process by overestimating the difficulty or complexity of implementing certain requirements

Output of Task - Prioritise Requirements:

January 9, 2011 153 Output of Task - Prioritise Requirements Set of prioritised requirements has an attribute that describes its relative importance to stakeholders and the organisation Each requirement should have an assigned priority. The priorities may apply to a requirement or to a group or related requirements

Task - Organise Requirements:

January 9, 2011 154 Task - Organise Requirements Prioritise Requirements Business Case Business Need Requirements Organisational Process Assets Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder, Solution and Transition Requirements Inputs Tasks Outputs Requirements Management Plan Stakeholder Concerns Stakeholder List, Roles and Responsibilities Solution Scope

Task - Organise Requirements:

January 9, 2011 155 Task - Organise Requirements Create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives Relationships and interdependencies among requirements adds complexity Organised requirements needs to clearly depict the inherent relationships between requirements

Elements of Task - Organise Requirements:

January 9, 2011 156 Elements of Task - Organise Requirements Levels of Abstraction Requirements can be articulated at different levels of abstraction Described as what needs to be done Express at whatever level of abstraction is appropriate for the audience Requirements tools can also determine the level of abstraction used when defining requirements Model Selection Determine the types of models required to describe the solution scope and meet the informational needs of stakeholders Objective of developing a model is to simplify reality in a way that is useful Usually necessary to develop multiple models using different modelling techniques to completely analyse and document requirements User Classes, Profiles, or Roles - categorise and describe the roles that directly interact with a solution Concepts and Relationships - define the objects, entities or facts that are relevant to the business domain and what relationships they have with other concepts Events Processes - sequence of repeatable activities executed within an organisation Rules - enforce goals and guide decision-making

Output of Task - Organise Requirements:

January 9, 2011 157 Output of Task - Organise Requirements Organised structure for the requirements and a documented set of relationships between them

Task - Specify and Model Requirements :

January 9, 2011 158 Task - Specify and Model Requirements Prioritise Requirements Requirements (Stated) Requirements Structure Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder, Solution and Transition Requirements Inputs Tasks Outputs

Task - Specify and Model Requirements :

January 9, 2011 159 Task - Specify and Model Requirements Analyse expressed stakeholder desires and/or the current state of the organisation using a combination of textual statements, matrices, diagrams and formal models Create specifications and models to analyse the functioning of an organisation and provide insight into opportunities for improvement Facilitate development and implementation of solutions, facilitating communication among stakeholders, supporting training activities and knowledge management, and ensuring compliance with contracts and regulations

Elements of Task - Specify and Model Requirements :

January 9, 2011 160 Elements of Task - Specify and Model Requirements Text Describe the capabilities of the solution, any conditions that must exist for the requirement to operate, and any constraints that may prevent the solution from fulfilling the requirement Matrix Documentation Tabular representation of information in a uniform structure that can be broken down into elements that applies to every entry in the table Models Graphical simplified representation of a complex reality Formal models use modelling standards (UML) Capture Requirements Attributes As each requirement is specified and modelled, the required and relevant attributes are captured Improvement Opportunities Identify opportunities to improve the operation of the initiative Automate Or Simplify The Work Improve Access To Information Reduce Complexity Of Interfaces Increase Consistency Of Behaviour Eliminate Redundancy

Output of Task - Specify and Model Requirements :

January 9, 2011 161 Output of Task - Specify and Model Requirements Requirements analysed, modelled and specified

Task - Define Assumptions and Constraints:

January 9, 2011 162 Task - Define Assumptions and Constraints Prioritise Requirements Business Case Business Need Requirements Organisational Process Assets Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder, Solution and Transition Requirements Inputs Tasks Outputs Requirements Management Plan Stakeholder Concerns Stakeholder List, Roles and Responsibilities Solution Scope

Task - Define Assumptions and Constraints:

January 9, 2011 163 Task - Define Assumptions and Constraints Assumptions are factors that are believed to be true but have not been confirmed Identify and document assumptions, confirm their accuracy, and identify and manage risks related to the ability of a solution to meet the business need Constraints are defined as restrictions or limitations on possible solutions - aspects of the current or planned future state that may not be changed Document any restrictions or limitations to the solution design, construction, testing, validation and deployment

Elements of Task - Define Assumptions and Constraints:

January 9, 2011 164 Elements of Task - Define Assumptions and Constraints Assumptions Anything that is believed to be true but that has not actually been verified Source of potential project risk May also reflect an understanding of how desired outcomes are likely to be achieved Business Constraints Limitations on available solutions, or an aspect of the current state that cannot be changed by the deployment of the new solution Examine to ensure that they are accurate and justified Technical Constraints Architecture decisions and limitations that are made that may impact the design of the solution May create a situation where a requirement cannot be met using the current solution approach or by a solution component

Output of Task - Define Assumptions and Constraints:

January 9, 2011 165 Output of Task - Define Assumptions and Constraints Documented and verified assumptions and constraints Assumptions and constraints will limit potential solution options and will be monitored for potential changes While they are not technically requirements, they can be managed and communicated in a similar manner

Task - Verify Requirements:

January 9, 2011 166 Task - Verify Requirements Prioritise Requirements Business Case Business Need Requirements Organisational Process Assets Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder, Solution and Transition Requirements Inputs Tasks Outputs Requirements Management Plan Stakeholder Concerns Stakeholder List, Roles and Responsibilities Solution Scope

Task - Verify Requirements:

January 9, 2011 167 Task - Verify Requirements Ensure that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work Requirements that do not meet quality standards are defective and must be revised Final check by the business analyst and key stakeholders to determine that the requirements are: Ready for formal review and validation Provide all the information needed for further work based on the requirements to be performed

Elements of Task - Verify Requirements:

January 9, 2011 168 Elements of Task - Verify Requirements Requirements Quality Cohesive - support the overall initiative purpose and scope Complete - represents all relevant requirements with each requirement self-contained without any missing information Consistent - do not contradict each other or describe the same requirement using different wording and with the same level of detail Correct - defects in requirements will lead to defects in the resulting solution Feasible - requirements must be implementable within the existing infrastructure, with the existing budget, timeline and resources available Modifiable - grouped in order to be modifiable Unambiguous - must not allow for multiple divergent valid interpretations Testable - must be a way to prove that a requirement has been fulfilled Verification Activities Check for completeness Ensure all triggers and outcomes have been accounted for Check for consistency across all requirements models and representations Ensure the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organisation

Output of Task - Verify Requirements:

January 9, 2011 169 Output of Task - Verify Requirements Verified requirements are of sufficient quality to allow further work based on those requirements to be performed

Task - Validate Requirements:

January 9, 2011 170 Task - Validate Requirements Prioritise Requirements Business Case Stakeholder, Solution and Transition Requirements Organise Requirements Specify and Model Requirements Define Assumptions and Constraints Verify Requirements Validate Requirements Assumptions and Constraints Requirements Structure Requirements (Prioritised) Requirements (Validated) Requirements (Verified) Stakeholder and Solution Requirements Inputs Tasks Outputs

Task - Validate Requirements:

January 9, 2011 171 Task - Validate Requirements Ensure all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need Ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements Stakeholders will have different, conflicting needs and expectations that may be exposed through the validation process and will need to be reconciled

Elements of Task - Validate Requirements (1):

January 9, 2011 172 Elements of Task - Validate Requirements (1) Identify Assumptions May not be possible to prove that implementation of the requirement will result in the desired benefit May be necessary to make assumptions as there are no similar previous experiences to rely on Assumptions need to be identified and defined so that associated risks can be managed Define Measurable Evaluation Criteria After defining the benefits that will result from the implementation of a requirement, define the evaluation criteria that will be used to evaluate how successful the resulting change has been after the solution is deployed Determine Business Value Assess individual requirements (and associated implementation features) to determine if they deliver business value Requirements that do not deliver direct or indirect value are strong candidates for elimination Business value can be delivered through requirements that support compliance with regulatory or other standards, alignment with internal standards or policies of the organisation, or increased satisfaction for stakeholders, even if those things do not have a direct measurable financial benefit

Elements of Task - Validate Requirements (2):

January 9, 2011 173 Elements of Task - Validate Requirements (2) Determine Dependencies for Benefits Realisation Not all requirements contribute directly to the end result desired by the organisation and described in the business case Evaluate Alignment with Business Case and Opportunity Cost Each requirement must be traceable to the objectives in the business case and should minimise the opportunity cost of implementation Requirement that are not aligned with the business case should be defined and approved in a separate business case or considered for removal from the solution scope Opportunity cost refers to the benefits that could have been achieved with an alternative investment

Output of Task - Validate Requirements:

January 9, 2011 174 Output of Task - Validate Requirements Validated requirements are those that can be demonstrated to deliver value to stakeholders and are aligned with the business goals and objectives If a requirement cannot be validated, it does not benefit the organisation or it does not fall within the solution scope, or both

Solution Assessment and Validation Knowledge Area:

January 9, 2011 175 Solution Assessment and Validation Knowledge Area

Solution Assessment and Validation - Inputs and Outputs:

January 9, 2011 176 Solution Assessment and Validation - Inputs and Outputs Assess Proposed Solution Assumptions and Constraints Enterprise Architecture Solution (Constructed, Deployed or Designed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Outputs Solution Options(s) Solution Performance Metrics Solution Scope Stakeholder Concerns Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment Requirements (Prioritised and Approved)

Task - Assess Proposed Solution:

January 9, 2011 177 Task - Assess Proposed Solution Assess Proposed Solution Assumptions and Constraints Enterprise Architecture Requirements (Prioritised and Approved) Solution (Constructed, Deployed or Designed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Solution Options(s) Solution Performance Metrics Solution Scope Stakeholder Concerns Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment

Task - Assess Proposed Solution:

January 9, 2011 178 Task - Assess Proposed Solution Assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements Determine if the solution delivers enough business value to justify its implementation

Elements of Task - Assess Proposed Solution:

January 9, 2011 179 Elements of Task - Assess Proposed Solution Ranking of Solution Options Define solution scoring criteria – simple or complex Assess and score solutions against criteria Top-rated solution or solutions are then investigated in greater detail Identification of Additional Potential Capabilities Solution options may offer capabilities to the organisation above and beyond those identified in the requirements or the original business case Determine if these capabilities are of immediate value or have the potential to provide future value

Output of Task - Assess Proposed Solution:

January 9, 2011 180 Output of Task - Assess Proposed Solution Assess the value delivered by each proposed solution If multiple options are available, a recommendation of the best solution should be made. A recommendation to terminate the initiative may be given if no solution delivers enough value to justify being implemented

Task - Allocate Requirements:

January 9, 2011 181 Task - Allocate Requirements Assess Proposed Solution Assumptions and Constraints Enterprise Architecture Solution (Designed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Solution Options Solution Performance Metrics Solution Scope Stakeholder Concerns Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment Requirements (Prioritised and Approved)

Task - Allocate Requirements:

January 9, 2011 182 Task - Allocate Requirements Allocate stakeholder and solution requirements among solution components and releases in order to maximise the business value given the options and alternatives generated by the design team Allocation is supported by assessing the tradeoffs between alternatives in order to maximise benefits and minimise costs Business value of a solution changes depending on how requirements are implemented

Elements of Task - Allocate Requirements:

January 9, 2011 183 Elements of Task - Allocate Requirements Solution Components Business solutions generally consist of multiple components Each component implements a subset of the requirements Allocation of requirements to solution components is a primary driver of the cost to implement the solution and the benefits delivered by it Release Planning Plan decisions about which requirements will be included in each solution release/phase/iteration Ensure all parties understand the consequences to the organisation based on the planned schedule of releases and identify the solution capabilities that will deliver the greatest business value Understand organisational restraints or policies that must be adhered to in any implementation, including constraints such as freeze periods for implementation, general company policies, and any phased-in activities

Output of Task - Allocate Requirements:

January 9, 2011 184 Output of Task - Allocate Requirements Requirements are allocated and associated with a solution component that will implement them

Task - Assess Organisational Readiness:

January 9, 2011 185 Task - Assess Organisational Readiness Assess Proposed Solution Assumptions and Constraints Enterprise Architecture Solution (Designed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Solution Options(s) Solution Performance Metrics Solution Scope Stakeholder Concerns Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment Requirements (Prioritised and Approved)

Task - Assess Organisational Readiness:

January 9, 2011 186 Task - Assess Organisational Readiness Assess whether the organisation is ready to make effective use of a new solution Describe the effect the new solution will have on an organisation and whether the organisation is prepared for the change that the solution implementation will cause Understand what changes will occur in the organisation area, technical infrastructure or processes and how these affect other organisation units or operations

Elements of Task - Assess Organisational Readiness:

January 9, 2011 187 Elements of Task - Assess Organisational Readiness Cultural Assessment Determine whether stakeholder groups genuinely want the change to be successful Assess the attitudes of key stakeholder groups and their willingness to accept change Determine if stakeholders understand the reasons that a new solution is being implemented Determine if stakeholders view that solution as something that will be beneficial and if they understand the reasons why a new solution is required Operational or Technical Assessment Determine if the organisation is able to take advantage of the capabilities provided by the new solution Evaluate whether stakeholders are prepared to make use of the new solution Determine if training has been performed, whether new policies and procedures have been defined, whether IT systems required to support it are in place, and whether the solution is capable of performing at a required level Stakeholder Impact Analysis How change will affect stakeholder groups

Output of Task - Assess Organisational Readiness:

January 9, 2011 188 Output of Task - Assess Organisational Readiness Organisational readiness assessment specifying whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively May lead to revisions in solution or project scope

Task - Define Transition Requirements:

January 9, 2011 189 Task - Define Transition Requirements Assess Proposed Solution Organisational Readiness Assessment Requirements (Stated) Solution (Designed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment Solution (Deployed)

Task - Define Transition Requirements:

January 9, 2011 190 Task - Define Transition Requirements Define requirements for capabilities needed to transition from an existing solution to a new solution During the transition period the orgamisation may need to operate both solutions in parallel Transition requirements are elicited, analysed, managed, and communicated by performing the same tasks as for other requirements

Elements of Task - Define Transition Requirements:

January 9, 2011 191 Elements of Task - Define Transition Requirements Data Data used by the old solution may need to be transferred or archived Rules for conversion will need to be developed, and business rules may need to be defined to ensure that the new solution interprets the converted data correctly Ongoing Work Will work will be ongoing in the old version of the solution at the time the new version is implemented Evaluate options for managing this ongoing work such as finishing existing work using the current solution and starting new work in the new solution, holding the processing of new work for a period of time, or converting all work at the time of implementation Organisational Change Process for managing the people side of change related to the solution

Output of Task - Define Transition Requirements:

January 9, 2011 192 Output of Task - Define Transition Requirements Transition requirements define the capabilities that must be developed in order for the organisation to successfully transition between solutions Transition requirements must be verified, validated, managed and communicated

Task - Validate Solution:

January 9, 2011 193 Task - Validate Solution Assess Proposed Solution Assumptions and Constraints Enterprise Architecture Solution (Constructed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Solution Options(s) Solution Performance Metrics Solution Scope Stakeholder Concerns Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment Requirements (Prioritised and Approved)

Task - Validate Solution:

January 9, 2011 194 Task - Validate Solution Validate that a solution meets the business need and determine the most appropriate response to identified defects Ensure the delivered solution meets the business needs on an ongoing basis Problems that are identified through solution validation will be reported and prioritised for resolution

Elements of Task - Validate Solution:

January 9, 2011 195 Elements of Task - Validate Solution Investigate Defective Solution Outputs Identify defects in a solution or solution component by looking at cases where the outputs from the solution are below an acceptable level of quality Assess Defects and Issues Identified defects are reviewed to assess the effect that they will have on the operation of the organisation Determine the severity of the defect, the probability of the occurrence of the defect, the severity of the business impact, and the capacity of the business to absorb the impact of the defects

Output of Task - Validate Solution:

January 9, 2011 196 Output of Task - Validate Solution Known problems that exist in the solution

Task - Evaluate Solution Performance:

January 9, 2011 197 Task - Evaluate Solution Performance Assess Proposed Solution Identified Defects Enterprise Architecture Solution (Deployed) Allocate Requirements Assess Organisational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Inputs Tasks Solution Options(s) Solution Performance Metrics Solution Scope Stakeholder Concerns Assessment of Proposed Solution Identified Defects Mitigating Actions Organisational Readiness Assessment Requirements (Allocated) Transition Requirements Solution Performance Assessment Solution Validation Assessment Requirements (Prioritised and Approved)

Task - Evaluate Solution Performance:

January 9, 2011 198 Task - Evaluate Solution Performance Evaluate functioning solution to understand the value they deliver and identify opportunities for improvement Investigate how a solution is actually used after it is deployed, and assessing the effect it has had, both positive and negative Post-implementation assessment when performed immediately following the completion of a project

Elements of Task - Evaluate Solution Performance:

January 9, 2011 199 Elements of Task - Evaluate Solution Performance Understand Value Delivered By Solution Gather the metrics that describe the performance of the solution Over or under-performance against targets may be investigated to identify a root cause and determine an appropriate response Over-performance may indicate that resources devoted to the solution can beused elsewhere, or that the value of the solution to the business was underestimated Validate Solution Metrics Ensure that business goals and objectives are aligned to the solution metrics Identify and define appropriate metrics Solution Replacement or Elimination Is it necessary to consider the replacement of a solution or solution component because: Reached the end of its useful life, services are being insourced or outsourced, the solution is not fulfilling the business goals

Output of Task - Evaluate Solution Performance:

January 9, 2011 200 Output of Task - Evaluate Solution Performance Solution performance assessment that escribes how the solution is performing in relation to business goals and objectives

BABOK Knowledge Areas and Tasks:

January 9, 2011 201 BABOK Knowledge Areas and Tasks

Underlying Competencies:

January 9, 2011 202 Underlying Competencies

Analytical Thinking and Problem Solving:

January 9, 2011 203 Analytical Thinking and Problem Solving Creative Thinking Involves generating new ideas and concepts, as well as finding new associations between or new applications of existing ideas and concepts Decision Making Includes gathering information relevant to a decision, breaking down the information relevant to a decision, making comparisons and tradeoffs between similar and dissimilar options, and identifying the option that is most desirable Learning Learning about a domain passes through a set of stages, from initial acquisition and learning of raw facts, through comprehension of their meaning, to applying the knowledge in day-to-day work, and finally analysis, synthesis, and evaluation Problem Solving Defining a problem involves ensuring that the nature of the problem is clearly understood by all parties and that underlying issues are visible Systems Thinking Systems theory and systems thinking suggest that the system as a whole will have properties, behaviors and characteristics that emerge from the interaction of the components of the system, and which are not predictable from an understanding of thecomponents alone

Behavioural Characteristics:

January 9, 2011 204 Behavioural Characteristics Ethics Requires an understanding of the standards that should govern behaviour and the willingness to act to ensure that behaviour meets those standards Personal Organisation Involves the ability to readily find files or information, timeliness, management of outstanding tasks, and appropriate handling of priorities Trustworthiness Stakeholders must trust the business analyst to behave ethically and to perform business analysis work effectively

Business Knowledge:

January 9, 2011 205 Business Knowledge Business Principles and Practices Business principles are those characteristics that are common to all organisations with a similar purpose and structure Industry Knowledge Understanding of the competitive forces that shape an industry and of major trends impacting the industry will help shape business requirements Organisation Knowledge Understanding of the business architecture of the organisation being analysed Solution Knowledge Familiarity with the workings of solutions will enable easier identification and recommendation if changes that can be implemented easily while still providing concrete benefits

Communication Skills:

January 9, 2011 206 Communication Skills Verbal Communications Enable business analysts to effectively express ideas in ways that are appropriate to the target audience Teaching Required to ensure that business analysts can effectively communicate issues and requirements and to ensure that the information communicated is understood and retained Written Communications Necessary for business analysts to document elicitation results, requirements, and other information for which medium-to-long term records are required

Interaction Skills:

January 9, 2011 207 Interaction Skills Facilitation and Negotiation Facilitate interactions between stakeholders in order to help them resolve disagreements regarding the priority and nature of requirements Leadership and Influencing Be effective in formal and informal leadership roles, in order to guide others investigating requirements and to help encourage stakeholder support for a necessary change Teamwork Be able to work closely with other team members to effectively support their work so that solutions can be effectively implemented

Software Applications:

January 9, 2011 208 Software Applications General-Purpose Applications Office productivity applications to document and track requirements Specialised Applications Modelling, diagramming and requirements management tools to support the development of formal models, and in some cases, their validation and implementation as well

Establishment of a Business Analysis Function:

January 9, 2011 209 Establishment of a Business Analysis Function

Business Analysis :

January 9, 2011 210 Business Analysis Business analysis is currently where project management was ten or more years ago We all know of it, we know we need it, but it is often unclear exactly what a business analyst does or what value they bring to the business The key benefit of adopting a consistent and robust framework in business analysis is the enablement of genuine benefits realisation through a solution which actually meets the business need BABOK is a key enabler to implementing effective business analysis framework and processes

Business Analysis Centre of Excellence (BACOE):

January 9, 2011 211 Business Analysis Centre of Excellence (BACOE) Business Analysis Issues No methodology or common practices Inconsistently defined role of business analyst Skill set not sufficient to support implementing a structured business analysis methodology Disparate enterprise knowledge Projects being staffed with external consultants Unsuccessful attempts in the past Inconsistent Project failures and problems due to analysis defects Short analysis cycles Business analyst value hard to measure Desired State Robust business analysis methodology has become the way to do business across the organisation Business analyst role clearly defined and supported through the Business Analysis Centre of Excellence Business analyst demonstrating proficiency in key competencies Requirements defects reduced substantially Improved mix of internal Business analyst and external consultants

Key Benefits:

January 9, 2011 212 Key Benefits Establishing enterprise standards, procedures, governance Standardising infrastructure, development methods, and operational procedures Increasing business agility to adapt quickly as the environment changes Reducing risk, complexity, redundancy, and support complexity Aligning business and IT Enabling re-use and faster time-to-market Reduced project failures and problems due to requirements and analysis defects

Structure of a BACOE:

January 9, 2011 213 Structure of a BACOE

Effective BACOE Function:

January 9, 2011 214 Effective BACOE Function Identify and understand the business problem and the impact of the proposed solution on the organisation’s operations Document the complex areas of project scope, objectives, added value or benefit expectations, using an integrated set of analysis and modeling techniques Translate business objectives into system requirements using powerful analysis and modeling tools Evaluate customer business needs, thus contributing to strategic planning of information systems and technology directions Assist in determining the strategic direction of the organisation Liaise with major customers during preliminary installation and testing of new products and services Design and develop high quality business solutions Select the projects that will give the greatest business benefit and then ensure project success Contribute to overall business growth and development

More Information:

January 9, 2011 215 More Information Alan McSweeney alan@alanmcsweeney.com