more than consultants. were essentialists. 1 1 improving business analysis and requirements...
TRANSCRIPT
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 11
Improving Business Analysis and Requirements Engineering.
Presented by: Morris Oslin, Trissential, LLCMay, 8, 2008
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 2
Objectives• Identify what exactly business analysis is in terms of it’s
relationship to requirements• What makes good software requirements• What drives good requirements• Roles and Processes in the Business Analysis Maturity
model– Realize the need for separation of duties of roles – Describe the pitfalls of combining the roles– Provide suggestions for avoidance
• Skills and Tools in the Business Analyst Maturity model • Case Study of Business Analysis/Requirements• Basic Improvement Roadmap
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 3
Business Analysis- Definitions
According to WIKIPEDIA@:
Business analysis helps an organization to improve how it conducts its functions and activities in order to reduce overall costs, provide more efficient use of resources, and better support customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary, non-value added work. The person who carries out this task is called a business analyst or BA.
Those Business Analysts who work solely on developing software systems may be called IT Business Analysts or Technical Business Analysts.Significant Cultural Drivers affecting the software project:
According to Trissential good requirements are focused on creating software products by being:
Traceable to the business- map to an explicit business architecture.
Consumable by the technical staff- used entirely and the only source
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 4
Business Analysis and Requirements- Current State
Google “Business Analysis Requirements” you get:
A lot of different training (people)
A lot of different processes
A lot of tools
Which is best?
Most are excellent choices
Which people training, process and tools are best for my organization so we can produce requirements that are traceable and consumable?
It Depends!
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 5
Business Analysis in the Organizational Model
Effective Strategy & Planning
Mind share
B
usine
ss, I
T, Cult
ural
Driver
s
Exceptional Execution
Implem
ented
Mindshare
Requirements Ownership
Business Excellence
BenefitValidation
©2006 Trissential. All Rights Reserved.
Business Analyst
Software Product
Development
Business Processes and Static Model
Business Analyst Leadership
Efficient Management
Accep
ted
Busin
ess
Req
uire
men
ts
Requirements Approach
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 6
Business Analysis in Governance Model & Processes – E1
Bus & ITExecutives
TechnologyArchitecture
BusinessArchitecture
ProgramArchitecture
Facilitate Governance Decisions
Determine Strategy
Decompose StrategyWhy, Why, Why
What’s the Pain/GainCreate the Business Case and ROI
Model the business as Static and In-motion (process)
Technology Form & Fit
IdentificationCategorizationEvaluationSelectionPrioritizationPortfolio BalancingAuthorizationReview & ReportingStrategic Change
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 7
Business Analysis in the Project Management Model –E2
Business Requirements
User and Stakeholder Identification and Profiling
Requirements Approach (based on
Bus. Reqs., User Profiling, and SDLC
used on project)
Business Analysis Leadership
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 8
Business Analysis in Product Development Model- E3
Business and System
Analysis
QualityAssurance and
Testing
RequirementsEngineering
ChangeMgmt
ApplicationArchitecture (as
needed)
Business Analyst Software Product Development
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 9
Business Analysis – Requirements Continuum
The Drivers of Good RequirementsWhere does an organization think they are on the Requirements
continuum?
Where is the organization really at on the Requirements continuum?
Where does the organization want to be on the Requirements continuum?
Extreme Agile:Solution based story
Agile Lite/Iterative:Story with business case
FormalRUP:Use Casedriven
DefenseDepartment(IEEE SRS and Spiral approach)
Waterfall-Requirement Lists orientated
RUP Lite:Use Case driven
Fluid Rigid
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 10
Business Analysis – Requirements Continuum
What are the business drivers that affect the Requirements? (E1)
Operational Scalability
Product speed to market
Cut Operational Costs
Increase Product Profit Margins
Increase Customer Satisfaction
Increase Product Market Share
Regulatory Compliance
Keep the lights on
Explicit versus implicitbusiness knowledge
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 11
Business Analysis – Requirements Continuum
What are the project and cultural drivers that affect the Requirements? (E2)
Physical Location of Project Team(s)
Project Governance: Scorecard and Project Reporting
Executive SponsorshipBusiness Engagement
Residual Knowledge of the Business Architecture
Culture Maturity(ex: Requirements capability)New or Existing Business
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 12
Business Analysis – Requirements Continuum
What are the technology drivers that affect the Requirements?(E3)
Resource Skill Sets
System Complexity:Standalone vs. Integrated
Resource Demand
Development Tools:Example Agile and XML work well
Development Costs
Technology Support Costs
Outsourcing
Residual Knowledge of the Technology Architecture
New or existing Technology
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 13
Business Analysis – Requirements Continuum
So what should the Requirements Continuum be set at for my organization?
The Requirement approach must be chosen on the Situational Needs of the project to produce good requirements.
• The Business Drivers, Technology Drivers, and Cultural/Project Drivers all work together to move the Requirements location on the continuum based on priority.
• The three Drivers fit right into the Essential Business Model.• The Requirements Engineering Process, Tools, and People
(Analysts and Technical staff) must fit the chosen Requirements approach.
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 14
Business Analysis - Roles & Responsibilities
BusinessAnalysis
QualityAssurance
RequirementsEngineering
ChangeMgmt
SoftwareDevelopment
BA
B-Req
Usr-Prf
Req-Apr
B&SA
QA
REAA
CM
Software Product
DevelopmentBusiness Architecture
Business Analysis Leadership
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 15
Business Analysis - Role Comparison
Project Plan Development (Requirements Phase)
Project Plan Execution (Requirements Phase)
Project Time Management (Requirements Phase)
Apply Business Architecture: Scope
Planning, Scope Definition
Document Business Requirements
Drive Requirements Review/Approval
Drive Resolution of Requirements Issues
Scope Change
Overall Project Plan Development
Overall Project Scope
Management
Overall Project Time
Management
Project Cost Management
Project Quality Management
Project Risk Management
Project Procurement
Management
Project Communications
Management
Project Human Resource
Management
Requirements Process Expert
Facilitate Requirements
Gathering
Lead Requirements
Analysis
Develop
Supplementary
Documentation
Partner with IT to
Define Functional
& Non- Functional
Requirements
Compose Business
Rules for Rule
Execution
Manage Business Rules
PM (E2) BA (E3)
Business Architect (E1)
Business Domain Expert (E1)
Create Business Policies
Create Business Rules
Provide and approve Business
Architecture
Provide and approve Business
Requirements
Provide and approve User
Requirements
Approve Functional Requirements
Understand Non Functional
Requirements
Identify Business
Policies
Identify Business
Rules from
Policies
Develop Business
Requirements
Manage the
recorded
Business
Architecture
Business Architect (E1)
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 1616
Role Delineation
Develop Scope
Identify & Engage stakeholders & SMEs
Team
BA
Begin Project
Develop Scope
Develop Phase Schedule & Budget
PM
Ideation
Team
BA
Verify Requirements
Ensure Product Delivery
Analyze Project Results
Close Project
PM
Wrap Up
Team
BA
Identify Business Issues
Manage Requirements changes
Ensure Budget & Schedule Tolerances
Manage WBS, Issues, Project Changes
PM
Development
Team
BA
Elicit How, What, Why from SMEs
Develop DetailedRequirements
Create Schedule & Cost Baseline
Gain Approval for Scope Statement
PM
Discovery
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 1717
Industry Insights
• Where does the BA role live? – Historically IT– Shifting towards business– Jury’s still out
• Where is the BA role going?– Recognition– Training/Certification
• What are the future trends?– IIBA as household name– Degreed programs– Indispensable role
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 18
BA Processes
Source: IIBA BABOK®
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 19
Business Analysis- Maturity Levels
5Optimizing
5Optimizing
4Comprehensive
4Comprehensive
3
Consistent
3
Consistent
2
In-consistent
2
In-consistent
1
Ad Hoc
1
Ad Hoc
Business Architecture models managed well.
Focus Is On Continuous Improvement of BA Process/ Tools with Training.
Strategic Competitive Advantage gained from reuse of Business Architecture from projects.
Business Analyst Role Separation practiced.
Senior Management and IT support Business Architecture and uses it themselves.
Senior BA’s engaged in early Program and Project Management.
Consistent use of Documented Business Analysis Processes as selected by project.
Requirements traceable to the business.
Business Architecture Published on Project basis but not managed for reuse.
Process Role
Business Analysis approach to projects is based on business, IT, and cultural drivers with some difficulty in deciding.
Inconsistent use of documented Business Analysis processes on projects.
Business Analysis tools reused across projects.
Business Analysis approach is one size fits all.
Each project has it’s own Business Analysis tools.
OJT Business Analyst training.
Business Analyst Role Separation is recognized with Business Architecture done for all projects with consistent IT & business support
Business Analyst Role Separation recognized but not as difference maker
Business Architecture initiated occasionally with some business and IT support
Business Analysis Approach selection is routine
Development staff regularly consumes Business Analysis Artifacts.
Development Staff may not always consume Business Analysis Artifacts
Artifacts Business Analyst Role Separation not recognized
Entrepreneurial/Heroic BA efforts
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 20
Business Analyst- Skills Comparison
PM (E2) BA (E3) Business Architect (E1)
“Big Picture” Thinker
Directs the project team
Helps people get things done
Conscience of time and $$
Removes issues/barriers
Possesses management skills
“Big Picture” Thinker
Possesses management skills
Communicates well with
Business Executives
Manage
Business Analysis
Process
Manage Requirements
Artifacts
Communicates well
with SMEs
Manages
interpersonal
relationships well
Interprets Business
Architecture
Details
Correctly
Communicates well
Understands SDLC
Manages interpersonal relationships well
Negotiates
Applies Business
Architecture
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 21
Business Analyst - Maturity Levels
5Bus.
Architect
5Bus.
Architect
4Structure
4Structure
2
Guidance Provided
2
Guidance Provided
1
IT waiter/waitress
1
IT waiter/waitress
Management Practice
Advanced VISIO, WBI Modeler, Enterprise Architect, playbooks as modeling tools.
Integrated Requirement management with modeling tools.
Pictorial business model first (As is, to be).
Static and process pictorial models of the business.
Produce textual view of requirements last.
Tools Skills
Business Modeling Standardized (UML, IDEV, in VISIO or basic modeling tools).
Multiple formats: Use Cases, Stories, SRS.
Requirements management tools.
Problem first then solution approach.
Business or System processes in a business model.
Processes and Scenarios identified in the business model.
Textual and Pictorial view of requirements.
Processes/scenarios identified by system users . .
Typically problem first then solution approach..
Random Business or System scenario driven.
Textual representation of requirements.
Solution first approach-start with screens.
Some business knowledge needed for effective interview.
Difficult to know when analysis is done.
Textual list of requirements with some process links.
Solution first approach-technology priority.
Good personal interviewing skills required.
Extensive business knowledge for effective interview.
Difficult to know when analysis is done.
Textual list of requirements,
3
Categorization
3
Categorization
Capture Business Requirements, User Requirements, Functional and Non-functional requirements in single standard format
Requirements published with tools: Rational products, TFS, Web…
Go ask who, what, when, where, why this way…..
Suggested Questions and formats
Requirements shared in network file system
No suggested questions
Plan interview, conduct interview, recap interview
Requirements stored for personal use
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 22
Business Analysis Case Study
Case Study: Midsize Service Company
Significant Business Drivers affecting the software project:
• Quick time to market
• Changing economic conditions affected project funding
• Subject matter experts and stakeholders in remote locations
Significant Cultural Drivers affecting the software project:
• Departments affected by the software were not mature, nor expected to be mature, in their own processes. This forced IT to own major business processes.
• Project Management Office was immature and typically produced product owners.
• IT had traditionally produced software products then shown the business when it was done. IT managed much of the business model especially in operations.
Significant IT Drivers affecting the software project:
• IT was not well versed in the new technologies = coders that don’t do design
• Developers, BA’s, and PM were contracted resources
• Accountability of Developers to PM was limited
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 23
Business Analysis Maturity Level- Midsize service company
5Optimizing
5Optimizing
4Comprehensive
4Comprehensive
3
Consistent
3
Consistent
2
In-consistent
2
In-consistent
1
Ad Hoc
1
Ad Hoc
Business Architecture models managed well.Business Architecture models managed well.
Focus Is On Continuous Improvement of BA Process/ Tools with Focus Is On Continuous Improvement of BA Process/ Tools with Training. Training.
Strategic Competitive Advantage gained from reuse of Business Strategic Competitive Advantage gained from reuse of Business Architecture from projects.Architecture from projects.
Business Analyst Role Separation practiced.Business Analyst Role Separation practiced.
Senior Management and IT support Business Senior Management and IT support Business Architecture and uses it themselves.Architecture and uses it themselves.
Senior BA’s engaged in early Program and Project Senior BA’s engaged in early Program and Project Management.Management.
Consistent use of Documented Business Consistent use of Documented Business Analysis Processes as selected by project.Analysis Processes as selected by project.
Requirements traceable to the business. Requirements traceable to the business.
Business Architecture Published on Project Business Architecture Published on Project basis but not managed for reuse.basis but not managed for reuse.
Process Role
Business Analysis approach to projects Business Analysis approach to projects is based on business, IT, and cultural is based on business, IT, and cultural drivers with some difficulty in deciding.drivers with some difficulty in deciding.
Inconsistent use of documented Business Analysis processes on projects.
Business Analysis tools reused across Business Analysis tools reused across projectsprojects.
Business Analysis approach is one size fits all.
Each project has it’s own Business Analysis tools.
OJT Business Analyst training.
Business Analyst Role Separation is Business Analyst Role Separation is recognized with Business Architecture done recognized with Business Architecture done for all projects with consistent IT & business for all projects with consistent IT & business supportsupport
Business Analyst Role Separation Business Analyst Role Separation recognized but not as difference recognized but not as difference makermaker
Business Architecture initiated occasionally with some business and IT support
Business Analysis Approach selection is routineBusiness Analysis Approach selection is routine
Development staff regularly consumes Development staff regularly consumes Business Analysis Artifacts.Business Analysis Artifacts.
Development Staff may not consume Business Analysis Artifacts
Artifacts Business Analyst Role Separation not recognized
Entrepreneurial/Heroic BA efforts
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 24
Role Comparison- Midsize service company
Project Plan Development (Requirements Phase)
Project Plan Execution (Requirements Phase)
Project Time Management (Requirements Phase)
Apply Business Architecture: Scope
Planning, Scope Definition
Document Business Requirements
Drive Requirements Review/Approval
Drive Resolution of Requirements Issues
Scope Change
Overall Project Plan Development
Overall Project Scope
Management
Overall Project Time
Management
Project Cost Management
Project Quality Management
Project Risk Management
Project Procurement
Management
Project Communications
Management
Project Human Resource
Management
Requirements Process Expert
Facilitate Requirements
Gathering
Lead Requirements
Analysis
Develop
Supplementary
Documentation
Partner with IT to
Define Functional
& Non- Functional
Requirements
Compose Business
Rules for Rule
Execution
Manage Business Rules
PM (E2) BA (E3)
Business Architect (E1)
Business Domain Expert (E1)
Create Business Policies
Create Business Rules
Provide and approve Business
Architecture
Provide and approve Business
Requirements
Provide and approve User
Requirements
Approve Functional Requirements
Understand Non Functional
Requirements
Identify Business
Policies
Identify Business
Rules from
Policies
Develop Business
Requirements
Manage the
recorded
Business
Architecture
Business Architect (E1)
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 25
5Bus.
Architect
5Bus.
Architect
4Structure
4Structure
2
Guidance Provided
2
Guidance Provided
1
IT waiter/waitress
1
IT waiter/waitress
Management Practice
Advanced VISIO, WBI Modeler, Enterprise Architect, playbooks as Advanced VISIO, WBI Modeler, Enterprise Architect, playbooks as modeling tools.modeling tools.
Integrated Requirement management with modeling tools.Integrated Requirement management with modeling tools.
Pictorial business model first (As is, to be).Pictorial business model first (As is, to be).
Static and process pictorial models of the business.Static and process pictorial models of the business.
Produce textual view of requirements last.Produce textual view of requirements last.
Tools Skills
Business Modeling Standardized (UML, IDEV, in VISIO or basic Business Modeling Standardized (UML, IDEV, in VISIO or basic modeling tools).modeling tools).
Multiple formats: Use Cases, Stories, SRS.
Requirements management tools.Requirements management tools.
Problem first then solution approachProblem first then solution approach.
Business or System processes in a business model.
Processes and Scenarios identified in the business model.Processes and Scenarios identified in the business model.
Textual and Pictorial view of requirements.
Processes/scenarios identified by system users .Processes/scenarios identified by system users .
Typically problem first then solution approach..
Random Business or System scenario driven.
Textual representation of requirements.
Solution first approach-start with screens.
Some business knowledge needed for effective interview.
Difficult to know when analysis is done.
Textual list of requirements with some process links.
Solution first approach-technology priority.
Good personal interviewing skills required.
Extensive business knowledge for effective interview.
Difficult to know when analysis is done.
Textual list of requirements,
3
Categorization
3
Categorization
Capture Business Requirements, User Requirements, Capture Business Requirements, User Requirements, Functional and Non-functional requirements in single Functional and Non-functional requirements in single standard formatstandard format
Requirements published with tools: TFS, Web
Go ask who, what, when, where, why this way…..
Suggested Questions and formats
Requirements shared in network file system
No suggested questions
Plan interview, conduct interview, recap interview
Requirements stored for personal use
Business Analyst Maturity Levels- midsize service company
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 26
Skills Comparison- Midsize service company
PM (E2) BA (E3) Business Architect (E1)
“Big Picture” Thinker
Directs the project team
Helps people get things done
Conscience of time and $$
Removes issues/barriers
Possesses management skills
“Big Picture” Thinker
Possesses management
skills
Communicates well with
Business Executives
Manage
Business Analysis
Process
Manage Requirements
Artifacts
Communicates well
with SMEs
Manages
interpersonal
relationships well
Interprets Business
Architecture
Details
Correctly
Communicates well
Understands SDLC
Manages interpersonal relationships well
Negotiates
Applies Business
Architecture
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 27
Business Analysis Processes & Tools
Business Architecture to support Project, Program and Portfolio Management
Business Analyst Knowledge, Application (Usage)
Execution of Business Analysis output in software development
Business Analysis Maturity Level Assessment
Business Analyst Maturity Level Assessment
Business Analysis Improvement
Roadmap
So what should I do to improve at business analysis?
Typical Business Analysis Assessment Context
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 28
Business Analysis Assessment Scope
Project Management Office
Project
Program
Portfolio
People-
BA rolesProcess Tools
Analysis
Development
le
Testing
E1
E2
E2
E3
E3
E3
Essential Model
Domain
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Business and System Analysis – the organizational glue of software development
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 29
Basic Improvement Roadmap- People
IT as SMEs
FormalizedBusiness Architeture
Development Team
PM
Business Analyst
Marketing
Accounting
Sales
Manufacturing
Business SME’s
• Recognize and Value Business Analyst role separation to gain project efficiencies1. BA function is not a stepping
stone to PM nor Business Architect roles
2. Projects need all three roles for success
3. Each position requires different abilities
4. Don’t wait for role delineation; be a catalyst for change
5. IF in the “multiple role”, create safeguards to reduce project risk
6. Business Analysis, Business Architecture, and Project Management are Essential!
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 30
Basic Improvement Roadmap- Process
Business Model updates
Objectives
Requirements traceable to Business and consumable
by technical developers
Bug fixes
Business Model
Strategy Communication
Products
Business Architecture
Requirements Development Process based on SDLC chosen for
project
Project Management Execution
Business Analysis Process
PM Focus
Build/Test Design InstallRequirements
Product Lifecycle
Business
Analyst Focus
• Formalize the set of sustainable Requirement Development processes, by SDLC, based on business, IT and Cultural drivers.
• Train BAs and PMs on the multiple processes chosen.
• Avoid producing Requirement Artifacts that are not used by Developers by monitoring on a project level basis.
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 31
Basic Improvement Roadmap –Tools
• Business Architecture– Identify the tools that match the level of reusable business
architecture that can be used to describe the business based on business, IT, and cultural drivers. These drivers should also be identified and prioritized for greatest impact.
• Requirements Development– Identify the common set of requirement development tools that
match the level of detail required on a project by project basis.– All tools should enable requirements that are traceable to the
business and consumable by the IT staff.
.MORE THAN CONSULTANTS. WE’RE ESSENTIALISTS. 3232
Questions & DiscussionMorris Oslin952-595-7970