create a business analysis center of...

0 © Copyright 2012 Enfocus Solu7ons Inc. All Rights Reserved.

Create a Business Analysis Center of Excellence: Improve Business Outcomes and Innovation

John E. Parker, CVO Enfocus Solutions Inc.

www.enfocussolutions.com


John E. Parker •  Chief Visionary Officer of Enfocus Solu7ons Inc. •  Previous Posi7ons

o  President and CEO of Enfocus Solu7ons Inc. incep7on through February 2013

o  EVP and Cofounder, Spectrum Consul7ng Group o  EVP and CTO, MAXIMUS Inc. o  Outsourced CIO for HSHS (Large Healthcare System) o  KPMG Partner

•  Exper7se o  IT Strategic Planning o  Business Analysis o  Recovering Troubled and Challenged Projects o  Enterprise Architecture o  Development Methodologies (Agile, Waterfall, RUP, Design

First, FDD, TDD) o  Financial and Cost Benefit Analyses o  Business Process Improvement, Reengineering, and

Management

Contact: •  http://enfocussolutions.com •  [email protected]


Why Focus on Business Analysis


Why Focus on Business Analysis?

•  Deliver More Successful Projects o  Eliminate major causes of challenged or failed projects (Poor requirements, Lack of User

Input, Changing Requirements) o  Reduce Scope Creep (Significant cause of project delays and cost overruns)

•  Eliminate Waste o  Less rework – (40% of project costs is related to rework, 70% of this is from poor requirements) o  Eliminate unnecessary func7onality (49% of funcIonality is never used)

•  Deliver More Business Value o  Realize more benefits through Benefits Realiza7on Management (Studies show 3x

improvement when benefits realizaIon is applied) o  Obtain be]er understanding of business needs

•  Achieve Results Faster o  Iden7fy and deliver quick wins o  Deliver high value func7onality earlier through feature priori7za7on

•  Provide BeCer SoluDons o  Gain a be]er understanding of business needs o  Understand various stakeholder perspec7ves o  Achieve higher user acceptance and support


Challenges for Business Analysis

•  New profession – o  Lack of understanding o  Low maturity level o  Significant varia7on in roles and responsibili7es in and between organiza7ons

•  Fragmented repor7ng and organiza7on o  Many different 7tles o  Significant varia7on in roles and responsibili7es o  Organiza7onal placement (Some report to IT, some report to business)

•  Percep7on o  Oben viewed as non-‐strategic (Requirement Writers) o  Value not fully understood o  Development is rapidly to agile: There is no formal business analysis role in agile

•  Integra7on into exis7ng processes o  Project management prac7ces o  Systems development lifecycles o  Business process improvement o  Business units


Business Analysis v Business Analyst Business analysis “is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operaIons of an organizaIon, and to recommend soluIons that enable the organizaIon to achieve its goals.” A business analyst “is any person who performs business analysis acIviIes, no maPer what their job Itle or organizaIonal role may be.” “Business analysis pracIIoners include not only people with the job Itle of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, soXware development, quality assurance, and interacIon design.”

Source: BABOK Version 2, IIBA

Business Analysis is not men7oned once in the the current version of the PMBOK.


Transforming Business Analysis


Business Analysis Improvement Areas PotenDal Benefit Reduce Rework for Plan Driven Projects 10-‐15% of Project Costs

Reduce the Number of Itera7ons for Agile Projects

10-‐20% Savings on Agile Projects

Eliminate Unnecessary Features 20-‐30% of Project Costs

Catch Defects Earlier and Prevent Produc7on Defects

10-‐20% Savings on Project and Maintenance Costs

Achieve Higher Project Success Rates 5-‐10% of Project Poriolio

Deliver Be]er Business Outcomes and Achieve Greater Benefits Realiza7on

1.5 to 2x increase in actual benefits realized

Eliminate Manual Workaround Produc7vity Increase

Be]er Vendor Management and Be]er Leverage of Offshore Resources

10-‐30% Savings in Outside Resource Costs

Deliver Results Faster NPV of Receiving Benefits Earlier

DemonstraDng a High ROI for BA Investment


Reduce Waste from Rarely or Never Used FuncDonality

Source: Standish Group Report at XP Conference 2002 by Jim Johnson

Opportunity: 64% of sobware development is rarely or never used. Outcomes: Savings in development, deployment and maintenance costs RecommendaDons: •  Break solu7on into small chunks that deliver value (Features)

•  Assign a BA and Sponsor to each feature •  Priori7ze features and eliminate ones of li]le or no value

•  Define both stakeholder and solu7on requirements

•  Don’t over-‐engineer •  Develop requirements based on the solu7on scope

•  Manage the project based on the solu7on scope

Poten7al Opportunity: 10-‐30% of Project Costs


Reduce Development Rework

Opportunity: •  Data from Carnegie Mellon indicate that

60-‐80% of sobware development cost is rework

•  Requirement defects account for 70-‐85% of rework costs (Source: Sobware Quality Engineering)

•  Errors found late in the development cycle can cost organiza7ons up to 200 7mes more than if detected in requirements phase (Source: IBM)

Outcomes: Savings in development, deployment and maintenance costs RecommendaDons: •  Develop be]er requirements •  Improve requirements valida7on •  U7lize features to develop requirements

Poten7al Opportunity: 10-‐15% of Project Costs

Source: IBM


Achieving a Return from Business Analysis

•  BA Processes cross over mul7ple func7onal areas. BA processes must be defined end-‐to-‐end addressing integra7on with PM, QA, DEV, Customers, and Users.

•  Reduc7on in cycle 7mes is cri7cal for successful Business Analysis. Reduc7on in cycle 7mes requires o  Moving away from Large Requirement Documents to Just Enough Just-‐in-‐Time o  Transi7oning from managing data instead of paper documents o  Breaking projects into small chunks (Features) and delivering to development when

ready (bundles) o  Geong faster feedback by con7nuously reviewing and valida7ng requirements instead

of wai7ng for large documents to be produced •  64% of sobware func7onality that is developed is rarely or never used. This represents significant waste and a big opportunity for cost savings. These savings can be harvested by using features and carefully priori7zing the features.

•  The real benefit from be]er business analysis is delivering be]er business solu7ons that result in be]er business outcomes (Increased Revenue, Lower Costs, and Higher Produc7vity)

•  Developing requirements collabora7vely results in be]er requirements. Be]er requirements achieves less rework, lower costs, and be]er solu7ons.


Times Have Changed!!! It is 7me to Abandon Requirements Prac7ces of the 70s

Area Old Way New Way

Development Lifecycle Waterfall Agile/Kanban

Requirement Format “Shall Statements” User Stories

Requirements Documents Data/Backlog

Messaging Developer Focused Business Focused

Focus Technical Solu7ons Business Outcomes

Requirement Wri7ng Requirements Analyst Collabora7ve Team Effort

Elabora7on All Details Up-‐Front Just Enough Just In Time

Test Cases Developed in Test Phase Developed Up-‐Front and used in DEV and TEST

Requirement Tool Word or Excel Business Analysis Tool


Developing Requirements

The Old Way – Documents •  BRD – Business Requirements Document •  MRD-‐ Market Requirements Document •  URD – User Requirements Document •  FRD – Func7onal Requirements Document •  UIRD – User Interface Requirements Document •  SRS – Systems Requirements Specifica7on

The New Way – Data •  Objec7ves •  Impacts •  Features •  Bundles •  Releases

The New Way – Integrated Database Mul7ple disciplines working together to create an integrated requirement repository that includes business, stakeholder, and solu7on requirements.

The Old Way – MulDple Versions of Paper Documents An single analyst crea7ng versions of requirement documents in Word and then wai7ng for stakeholders to review and approve.

The New Way – Data IntegraDon Requirement data is transmi]ed to applica7on and tes7ng environments electronically.

The Old Way – Paper Documents Sent to Development Large paper documents were sent to Development for building and tes7ng the system

The New Way –Business Value and Outcomes The Old Way – Technical SoluDons


Stakeh

olde

r Re

quire

men

ts

Solu7o

n Re

quire

men

ts

Busin

ess Re

quire

men

ts

Users

Execu7ve Sponsor

Developers

Quality Assurance

Project Manager

Opera7ons & Support

Technical SMEs

Business Analyst Business SMEs

User Experience

Developing Requirements is a Team Sport Transforming Business Analysis Requires More than Just Training Business Analysts


Collaborative Requirements

CollaboraDon is business analysts, business stakeholders, users and technical stakeholders working with together to develop requirements. The various par7es work together by sharing knowledge, learning, and building consensus in terms of what is needed to build the solu7on. One leading consulIng firm found that they were able to capture 93-‐95% of the funcIonality by using a collaboraIve requirements approach versus only 65% when a more tradiIonal interviewing method was used. In addiIon, there was significantly higher user saIsfacIon for soluIons that were built with collaboraIve requirements


Who owns Primary Responsibility for Requirements

Budget % of Target

Time % of Target

FuncDonality % of Target

Stakeholder Time % of Target

IT 162.9 172 91.4 172.9

Business 196.5 245.3 110.1 201.3

Jointly Owned 143.4 159.3 103.7 163.4

Source IAG Business Analysis Benchmark, 2008

Joint Responsibility for Requirements Makes a Big Difference


Agile Development COTS & SaaS

Plan-‐Driven Development (Waterfall)

Process Improvement

Business Analysis




1. Transforma7on Requires Much More than Just Training Business Analysts

3. Achieving Business Outcomes Requires Good Business Requirements

4. Delivering Value Requires Defini7on and Management of Solu7on Scope

2. Organiza7ons Must Transform from Archaic Methods and Processes

6. Defini7on of Stakeholder Requirements is Key for User Adop7on

5. Understanding Impacts and Gaps is cri7cal for Enabling Change

8. Solu7on Assessment and Valida7on Delivers Be]er Solu7ons

7. High Quality Solu7on Requirements and Data Integra7on Reduce Rework


End-‐to-‐End TransformaDon Effec7ve Business Analysis Requires Integra7on into Exis7ng Processes

Project Management

Business Stakeholders Development Quality

Assurance User

Experience Business

Architecture

Business Analysis

•  Successful projects •  Fewer Delays

•  Higher Sa7sfac7on •  Increased Produc7vity •  Less workarounds

•  Less Rework •  Faster Time to Delivery •  Lower Costs

•  Fewer Defects •  Defects Caught earlier

•  Higher quality solu7ons

•  Increased Revenues •  Lower Costs •  Faster 7me to market

•  Business Alignment

• WBS based on features, bundles and releases

•  All 7 requirement types as defined in PMBOK

•  Impact based risk management

•  UCD incorporated into process

•  Ac7ve user par7cipa7on

•  Requirements delivered electronically

•  Par7cipate in elabora7on of requirements

•  Create test cases from acceptance criteria

•  QA for requirements as well as solu7on

•  Con7nuous par7cipa7on

•  Priori7za7on of solu7on scope

•  Scope 7ed to objec7ves •  Improved transparency

•  Requirements traced to architectural components

•  Par7cipate in requirements development

Transforma6on

Outcomes


End to End Improvement Using Business Analysis From Business Need to Business SoluDon

Business Need

Solu7on Concept & Scope

User Needs

Define and Design Solu7on

Build Solu7on

Test Solu7on

Deliver Solu7on

Business Requirements

Solu7on Scope

Stakeholder Requirements

Solu7on Requirements

Transi7on Requirements

Idea7on to Features Features to Requirements Requirements to Value

Solu7on Assessment

Verifica7on & Valida7on

Features Bundles Releases Vision

Development Lifecycle

Business Analysis Lifecycle

Project Management WBS


Stakeholder Analysis and Requirements Developing Stakeholder Requirements Requires Understanding Who the Stakeholders Are

Customer Users Technical Stakeholders

GRC Stakeholders

• Cost • ROI • Strategy • Timeframe • Outcomes • Goals • Objec7ves

• Ac7vi7es • Usability • User/System interac7on

• Process Design • Informa7on Needs • Sales and Marke7ng Needs

Business SME

• Standards • Policies • Controls • Compliance

• Architecture • Support • Business Con7nuity • Security • Capacity


Requirements TransformaDon Developing Good Requirements is at the Core of good Business Analysis

The Goal is to move away from paper: Manage Data not Documents


Business Analysis Process TransformaDon


Requirement Types


Requirement Types Requirement Types Defined in Both PMBOK and BABOK

•  Business requirements, which describe the higher-‐level needs of the organizaIon as a whole, such as the business issues or opportuniIes, and the reasons why a project has been undertaken.

•  Stakeholder requirements, which describe needs of a stakeholder or stakeholder group. •  Solu6on requirements, which describe features, funcIons, and characterisIcs of the

product, service, or result that will meet the business and stakeholder requirements. SoluIon requirements are further grouped into funcIonal and nonfuncIonal requirements: o  Func6onal requirements describe the behaviors of the product. Examples include

processes, data, and interacIons with the product. o  Nonfunc6onal requirements supplement funcIonal requirements and describe the

environmental condiIons or qualiIes required for the product to be effecIve. Examples include: reliability, security, performance, safety, level of service, supportability, retenIon/purge, etc.

•  Transi6on requirements describe temporary capabiliIes, such as data conversion and training requirements, needed to transiIon from the current “as-‐is” state to the future “to-‐be” state.

Two Addi6onal Requirement Types Defined in PMBOK

•  Project requirements, which describe the acIons, processes, or other condiIons the project needs to meet.

•  Quality requirements, which capture any condiIon or criteria needed to validate the successful compleIon of a project deliverable or fulfillment of other project requirements.


Requirement Types

Requirement Type Purpose Project Risk Business Requirement Describe why the project is being

undertaken from a business perspec7ve.

Expected business outcomes will not be achieved

Stakeholder Requirements Stated from the user's point of view and describe what is needed for the user to do his or her job.

User needs will not be met resul7ng in refusal to use the system or costly workarounds

Solu7on Requirements (Func7onal and Nonfunc7onal)

Stated from the system's perspec7ve and describes what the system must provide to sa7sfy the business and user requirements.

Results in costly rework, budget and schedule overruns, subop7mal solu7ons that deliver li]le value to the business.

Transi7on Requirements Describe what is needed to transi7on from the current (AS-‐IS) to the the future state (TO-‐BE). Includes such things as data conversion and training requirements.

Systems delays, customer service interrup7ons, costly roll-‐backs

Failure to define Each Type of Requirement is a Major Project Risk


Requirements Model Objec7ves Features



Func7onal Requirements

Nonfunc7onal Requirements


Use Cases Personas

Data Conversion Training

Performance

Presenta7on Data

Usability Flexibility Reliability

Needs Scenarios

Process Logic

Business Rules Interfaces

Support

Standards Security

Business Problem

Impact (Gap) Analysis

Organiza7onal Context

Business Case

Requirement (Shall Statements, Pa]erns, User Stories)

Cut-‐Over

Requirements Elabora7on (A]ributes)

User Experience

Performance Measures

Condi7ons of Sa7sfac7on

Acceptance Criteria

Test Cases

Verifica7ons

Verifica7ons


Why Word and SharePoint do not Work

•  Requirements are more data intensive than document intensive •  Mul7ple people need to work on the requirements at one 7me. This is impossible or very

difficult with a word processor such as Word. It is important to track who and when changes were made.

•  Requirements need to be managed as backlog items to support agile and complex projects o  Development itera7ons o  Different Teams

•  Requirements are more than just text o  Related Business rules o  Visualiza7ons (Process models, data flow diagrams, wireframes etc.) o  Related documents, videos, screenshots, etc. o  Rela7onships and traceability

•  Requirements need to be managed individually and collec7vely o  Priori7za7on o  Bundling o  Lifecycle management

•  Review and valida7on is con7nuous process not a single event like a word document •  Each type of requirement needs different types of data (Pa]erns) •  Requirements need to be traced forward and backwards from the source where they were

created to deployment in the solu7on •  Oben 7me, it is necessary to gather addi7onal data to make a requirement complete, this is

oben done with ac7on items. Trying to track all of these in word/SharePoint can be a nightmare.

Over 70% of OrganizaDons use Word to Develop Requirements


ObjecDves Impacts Features Bundles Releases

Business Outcomes SoluDon Scope Build and Test TransiDon Gaps

Why are we doing this?

What needs to be done?

What will change?

How will the solu7on be built or acquired?

How will the organiza7on transi7on to the new solu7on?

Requirement Containers





Quality Requirements


Quality Requirements


Business Sponsor

Process or Service Owner

Feature Sponsor (SME)

Development Team

Release Team


Work Breakdown Structure Features, Bundles, and Releases fit Perfectly into a WBS


Requirement TransformaDon Summary 10 RecommendaDons to Achieve Breakthrough Performance

1.  Focus on managing data instead of producing paper documents. Use a tool such as Enfocus Requirements Suite™ instead of Word or Excel.

2.  Create and implement a requirements model that includes all the requirement types specified in BABOK and PMBOK.

3.  Develop requirements collabora7vely instead of in isola7on. Share accountability – every Feature should have a sponsor.

4.  Define solu7on scope (Features) before defining solu7on requirements. 5.  Develop requirements itera7vely and incrementally in layers. 6.  Con7nuously review and validate requirements instead of reviewing and

approving requirements aber large paper documents are completed. 7.  Keep stakeholder requirements separate from solu7on requirements but

trace solu7on requirements to stakeholder requirements. 8.  Adjust the amount of requirement detail (elabora7on) to the needs of the

project. Deliver just enough detail just in 7me for development. 9.  Integrate requirement silos (Business Analysts, Systems Analysts, UCD, QA,

Architects). Mul7ple silos exacerbate communica7on problems and cause delays.

10.  Focus on delivering be]er business outcomes and more value instead of producing piles of paper.


What About Agile Development?


Agile Business Analysis

Product Owner Team Scrum Master

• Priori7ze Backlog • Write Epics, Themes, User Stories •  Elicit Needs from Stakeholders • Define Vision and Scope • Develop Acceptance Criteria (Confirma7ons)

• Define When Done • Define Nonfunc7onal Requirements

• Define Transi7on Requirements •  Ensure User Stories meet Current Business Needs

•  Elaborate User Stories (Conversa7ons)

•  Evaluate solu7ons for user stories (Nego7a7on)

•  Develop Test Cases from acceptance criteria

•  Write User Stories to reduce technical debt

BA Responsibili7es are split between Product Owner and Team



TradiDonal BA Agile BA

Requirements are documented in Use Cases, Func7onal requirements, UI Specifica7ons, and Business Rules.

Requirements are documented in themes, epics, and user stories

Requirements are very specific with very li]le room for nego7a7on

Requirements are nego7able, knowing there are mul7ple ways to solve the problem

Significant effort is placed on geong all the requirements right up-‐front.

Deliver just enough detail just in 7me. Addi7onal details are added during development itera7ons.

Oben, there is a wall between BA and Development

BA is fully integrated in the agile process either working as a Product Owner or a Team Member

Significant effort is devoted to producing large paper documents

Requirements are managed in a backlog

BAs oben dictate the solu7on with li]le room for interpreta7on

The Team and Product Owner work together to explore various solu7ons

Significant amount of 7me is waster geong sign-‐off or approval of requirements

Focus is on ensuring that the requirements address business needs and the requirements reflect business priori7es


Agile Requirements

Requirement Type Agile Requirement

Business Requirements Vision and Scope (Themes and Epics)

Stakeholder Requirements User Story (Card)

Solu7on Requirements User Story (Conversa7ons and Confirma7on)

Transi7on Requirements Release Requirements/Condi7ons of Sa7sfac7on



Objec7ve

Feature

Bundle

Release

Requirement

Objec7ve (Theme)

Epic

Sprint

Release

User Story

Plan-‐Driven Project Agile Project


Agile Requirements TransformaDon Summary Agile Requirements Need Improvement Too!!!

1.  Focus on managing data instead of producing paper documents. Use a tool such as Enfocus Requirements Suite™ instead of Post-‐It-‐Notes.

2.  Create and implement a requirements model that includes all the requirement types specified in BABOK and PMBOK. Remember in Agile Requirements are nego7able, not rigid specifica7ons.

3.  Define Business Analysis Responsibili7es by role: Product Owner and Team. 4.  Focus on ways to keep business stakeholders engaged and ac7ve. The product owner can not do

it all. 5.  Start with Epics and Features not stories. 6.  Maintain three backlogs:

1.  Feature Backlog – Coordina7on with Business Stakeholders (Use Tool such as Enfocus Requirements Suite)

2.  Story Backlog – Coordina7on with Team (Use tool such as Enfocus Requirements Suite™) 3.  Task Backlog – Maintained by Team (Use tool such as JIRA or Rally)

7.  Consider the three C: 1.  Card – User Story 2.  Confirma7on – Test Cases or Acceptance Criteria 3.  Conversa7ons – Design Decisions

8.  Focus on delivering real value. Real value is the delivery of working features to users-‐ not the development of sobware using stories.

9.  Adjust the amount of requirement detail (elabora7on) to the needs of the project. Deliver just enough detail just in 7me for development. Try to minimize the number of development itera7ons by delivering the right amount of detail up-‐front.

10.  Use retrospec7ves and learn by doing. Con7nue to make adjustments as needed throughout the project.


Centers of Excellence


BA Centers of Excellence 3 Stages of Development

Phase 1 Project-‐Centric

Phase 2 Enterprise Focused

Phase 3 Business Strategy

•  Be]er requirements •  Business requirements •  Stakeholder requirements •  Solu7on requirements •  Transi7on requirements

•  Focus on end-‐to-‐end processes •  Business Analysis •  Project Management •  Quality Assurance •  Development •  Test •  Business Units

•  Project Manager and Business Analyst Project Life Cycle Collabora7on

•  Consistent applica7on of Improved prac7ces and techniques

•  Transi7on from requirement documents to managing data

•  Business Architecture •  Business process design and improvement

•  Delivering Business Outcomes •  Business Value Maximiza7on •  Enterprise poriolio Management •  Benefits Realiza7on

•  Outcome driven innova7on •  Value crea7on •  Compe77ve advantage •  Breakthrough concepts •  Strategic priori7za7on


RecommendaDons for CreaDng a BA-‐COE

•  Do not create an Island – Focus on Integra7on o  Business Units – Execu7ves, SMEs, and Users o  Project Management o  Systems Development Lifecycle o  Quality Assurance o  Technical SMEs – Architects, Security, Opera7ons, Support

•  Do not repeat the Mistakes of the Last 40 Years o  Focusing Solely on Solu7on Requirements o  Delivery Technical Solu7ons vs. delivering Business Outcomes o  Producing Large Paper Requirement Documents o  Crea7ng Big Requirements Up Front (BRUF) o  Not Developing Requirements Collabora7vely o  Stakeholder Review and Approval vs. Stakeholder Engagement

•  Focus on Six Key Components o  Strategic Alignment o  Governance o  Processes and Prac7ces o  Informa7on Technology o  Skills and Competencies o  Culture

•  Don’t Take on Too Much Too Fast


What is Needed to Build Business Analysis Capability?

Strategic Alignment Governance Processes &

PracDces

InformaDon Technologies

Skills & Competencies Culture


Strategic Alignment Business Analysis COE

Defined BA Role Project Management Alignment

SDLC Alignment

Business Alignment

Role and responsibiliIes of the BA must defined and clearly understood by all.

BA Processes and PracIces, including reporIng

relaIonships must align and support project management

processes.

BA Processes and Prac7ces must align and support systems development

processes

Business Analysis services must support the needs of

the business.

Best pracIce examples of BA arIfacts such as

requirements, problem statements, visions, etc.



Strategic Capabili7es

Core capabiliIes should be idenIfied, a gap analysis conducted, and a program developed to build BA

capabiliIes


Governance Business Analysis COE

Execu7ve Support

Measurement Funding

COE Charter

Strong ongoing ExecuIve Support is required

EffecIve KPIs should be in place to measure COE

performance

COEs require funding to pay for staff development, technology, and support

Clear objecIve and responsibiliIes should be defined including defined reporIng relaIonships






Processes and PracDces Business Analysis COE

Business Analysis Framework

Business Analysis Prac7ce Guidelines

Business Analysis Techniques

Business Analysis Visualiza7on Methods

Example Ar7facts

Methodology that describes the tasks for performing business analysis acIviIes

Guidelines for performing business analysis acIviIes defined in the framework

Alter the way business analysis tasks are performed or describe a specific format for the output of a task.

Describe how to improve the communicaIon of business analysis arIfacts through graphic visualizaIons.






InformaDon Technology Business Analysis COE

Knowledge Management

Business Analysis Sogware

CollaboraDon

Share knowledge on business processes, pracIces and domain

knowledge

Provide automated support for business analysis processes

Enable collaboraIon between business and technical stakeholders

Reusable Objects

Reusable BA ArIfacts that can be reused among projects


Skills and Competencies Business Analysis COE

Competency Model

Learning & Professional Development

Reference Library

A defined competency model is needed to guide individual BA

development

The COE should offer ongoing educaIon to

build BA skills.

Comprehensive resources on a variety of topic should be available for BAs to learn and

grow.



Culture Building Effec7ve BA Capabili7es Requires Significant Changes to Culture

ExecuDves Technical Stakeholders

Business Stakeholders

ExecuIves should see BA as strategic to the organizaIon and

essenIal for project success

Technical Stakeholders should clear value from bePer requirements and see less rework and

frustraIon.

Comprehensive resources on a variety of topic should be available for BAs to learn and

grow.


Project Managers

Project managers should see the BA as essenIal partners for delivering successful projects.

Business Analysts

BAs must view themselves as more than just requirement

writers.


Q&A

Contact: John Parker http://enfocussolutions.com [email protected]