the hidden costs ba world v2 1
DESCRIPTION
Presentation delivered at BA Worlds in Melbourne, July 2010. Looks at the benefits of using a modelling platform to better identify, gather and manage requirements.TRANSCRIPT
The hidden costs of
Visio, Word & Excel
-better requirements at a lower cost
Ben Clohesy
Future State Consulting
Holocentric July 2010
Agenda
• Requirements definition is still difficult
• The traditional approach
• The model-driven approach
• Beyond use cases - the strategic BA
2
Holocentric July 2010
REQUIREMENTS DEFINITION
3
Holocentric July 2010
4
System delivery success
• Implementation costs were found to average 25% over budget, 40% of the projects failed to achieve their business case within one year of going live (Conference Board Survey 2001)
0
10
20
30
40
50
60
70
80
90
100
Robins-Gioia
2001
Meta Group
2001
Deborah
Weiss - Meta
Group 2003
Standish
2010
% Project failure
Robins-Gioia 2001
Meta Group 2001
Deborah Weiss - Meta
Group 2003
Standish 2010
Holocentric July 2010
5
Specs to save CIO necks
Karen Dearne
NOVEMBER 14, 2006
“With two out of every three projects failing to
produce any discernible benefits whatsoever, it's
only a matter of time before boards are forced to be
more accountable for their inability to apply
strategies and the massive waste, estimated at up
to one-third of total capital expenditure.
“Based on overseas estimates, the cost of
terminated projects in Australia in 2002-03 was
$1.4 billion, while another $3.2 billion was spend on
projects that delivered no benefits.“
I.T. Matters – at least until everyone can get this right!
Holocentric July 2010
6
Why do projects fail so often?
• Poor communication among customers, developers, and users
• Unrealistic or unarticulated project goals
• Badly defined system requirements
• Inaccurate estimates of needed resources
• Poor project and risk management
• Stakeholder politics
• Commercial pressures
• Use of immature technology
• Sloppy development practices
• Inability to handle the project's complexity
Not engineering
Not requirements management
It‟s all about
definition and co-ordination!
IEEE Spectrum, September, 2005
95% of the time it's a project management
issue. The managers of these projects set
out the requirements at the beginning of a
project and they get it wrong (IDC, 2004)
…the market places a disproportionate
emphasis on tools for requirements
management. The real opportunity lies in
requirements definition… (Forrester, 2006)
Holocentric July 2010
THE TRADITIONAL APPROACH
7
Holocentric July 2010
All the usual suspects...
8
Requirements
Vendor Information
e.g. Use Cases
Business Case
Visio Process
Diagrams
User Training
Materials
Process
Metrics
Requirements
&
Specifications
Policy and
Procedures
Holocentric July 2010
THE MODEL-DRIVEN APPROACH
9
Holocentric July 2010
10
Process Modeling is the key
• Roles emphasise a „People view‟ of process.
• Personal level of responsibility for work unit output
• Key link in chain of requirements responsibility
Holocentric July 2010
The difference ...
• Engage business representatives – better quality requirements
• Greater functionality to verify the integrity of your requirements
• Model as single repository used to derive all the information you need – no more documentation nightmares
• Impact analysis to manage change
11
Holocentric July 2010
12
Project Model
Business Process Model
System Requirements Model
Project
Model
Business Outcomes AssumptionsBusiness ConstraintsCapabilities External Document
References
MeasuresMetricsRisks
Business Process
Model
Business Process Area Diagrams Business Process Diagrams Process Roles Process Steps
System Requirements
Model
Build
Buy
System Features Functional Requirements Non Functional
Requirements
System Use
Case Model
Information
Model
Rules Register
User Interface
Model
System Process
Diagrams
System Requirements Overview
Holocentric July 2010
13
Holocentric July 2010
Case Study
• Traditional vs. model-based approach
• The consulting firm:
• Cost: $2.5 million
• 6000 requirements in excel, word
• Model-based team:
• Cost: $0.55M
• Of the 6000, 1500 were invalid, unnecessary or duplicated
• 450 were missing14
Holocentric July 2010
15
System Requirements Modeling
Business Requirements Modeling
Business Case Inputs
«Project Model»
Assumption
«System Model»
System Use Case
«Business Process Model»
Process Role
«User Interface Model»
Dialog Message
«System Model»
System Actor
«Project Model»
Business Constraint
«Project Model»
Capability Usage Diagram
«Project Model»
Metric
«Information Model»
Information Set
«Rule»
Rule Set
«Project Model»
External Document Reference
«Business Process Model»
Process Step
Screen Flow Node
{abstract}
Competency
{abstract}
«Rule»
Rule
«Project Model»
Project Scope Diagram
«Business Process Model»
Business Process Diagram
«System Model»
System Process Diagram
«User Interface Model»
Screen
«Project Model»
Measure
«System Requirement»
Functional Requirement
«System Model»
System Use Case Diagram
«User Interface Model»
Screen Flow Diagram
Information
{abstract}
«Information Model»
Information Field
«System Requirement»
Non Functional Requirement
Capacity
{abstract}«System Requirement»
System Feature
«Project Model»
Capability
«Information Model»
Information Structure Diagram
«Business Process Model»
Business Process Area Diagram
«Project Model»
Business Outcome
«Project Model»
Risk
Gaugable
{abstract}
Constrainable
{abstract}
Capability Utilizer
{abstract}
Capability Element
{abstract}
Rule Subject
{abstract}
Supplementary
System Diagram
{abstract}
Accelerator Item
{abstract}
Linkable
{abstract}
Constrained ByConstrained By Gauged ByGauged By
**
**
**
**
**
UtilizesUtilizes
**
**Characterized ByCharacterized By
****
ImplementsImplements
**
**
Elaborated ByElaborated By
**
**
Governed ByGoverned By
**
**
Elaborated ByElaborated By
**
**
Subject OfSubject Of**
**
GroupsGroups
1..*1..*
**
**
RequiresRequires
**Operates OnOperates On
** **
Refined ByRefined By**
**
ComprisesComprises
**
**
Enabled ByEnabled By**
**RequiresRequires
**
**
Measured ByMeasured By
**
**Proceeds ToProceeds To
**
**
RealizesRealizes
**
Holocentric July 2010
DEMONSTRATION
16
Holocentric July 2010
RACI Matrix
17
Holocentric July 2010
Impact Analysis - Requirements
18
Holocentric July 2010
Impact Analysis - Measures
19
Holocentric July 2010
20
Drawing versus Modeling
• Isolated „flat‟ drawings – difficult to maintain model integrity
• Difficult to analyze across the full spectrum of a business
• Little re-usable content
• Challenging to maintain on an ongoing basis
Holocentric July 2010
Holocentric July 2010
Joining the dots
22
The ‘How’
The ‘Who’, ‘When’ and ‘Where’
The ‘Why’
Policy
Positions
System
Requirements
Business Processes
Business Processes
implement the policy intent
Business processes also provide
a meaningful context to define
accurate system requirements
Functional
Specification
Holocentric July 2010
BEYOND USE CASES- A MORE STRATEGIC ROLE FOR BA’S
23
Holocentric July 2010
From process mapping
24Generally used to “map” the “AS-IS” and/or “TO-BE” process in a
more visual way. Thought be easier to communicate to the workforce
Holocentric July 2010
How do we train users on
the new system?What happens when the
system doesn’t work?
25
How do we use the system?
How will it impact my role?
Will it still ensure we
adhere to the regulations?
Does everyone have
the same access?
What is the process to be followed?
What official documentation
do I need to know about?
Will it do what we need it to
do?
What manual tasks and
other systems will we need
to use?
Model the Process
- Using Role Based Notation
- Identify Enabling and Supporting Systems- Highlight manual Tasks
- Link to Business
Requirements
- Link to External Documents
- Create and Link Use Cases
- Create and Link
System Roles
- Create and Link
Regulations
- Rate the process for
Business Continuity
- Create Training Material
within the Model
To modelling
Holocentric July 2010
To training
26
Holocentric July 2010
27
Process
Policies & Procedures
Business Requirements
Use Cases
Regulations
To regulations
Holocentric July 2010
Tangible Benefits
• Requirements refinement and validation
• At very little cost
• Creation of framework to generate Material for Training
• At very little cost
• Creation of framework to generate Material for Change Programs
• At very little cost
• Processes and Documents reflect Regulations
• At very little cost and with high integrity
• Creation and capture of Use Cases
• Applications Vendor provide “software steps”
• Manage Applications functionality
• Synchronisation of all key Project work
Furthermore, model-based information is maintainable28
Holocentric July 2010
29
System Requirements Modeling
Business Requirements Modeling
Business Case Inputs
«Project Model»
Assumption
«System Model»
System Use Case
«Business Process Model»
Process Role
«User Interface Model»
Dialog Message
«System Model»
System Actor
«Project Model»
Business Constraint
«Project Model»
Capability Usage Diagram
«Project Model»
Metric
«Information Model»
Information Set
«Rule»
Rule Set
«Project Model»
External Document Reference
«Business Process Model»
Process Step
Screen Flow Node
{abstract}
Competency
{abstract}
«Rule»
Rule
«Project Model»
Project Scope Diagram
«Business Process Model»
Business Process Diagram
«System Model»
System Process Diagram
«User Interface Model»
Screen
«Project Model»
Measure
«System Requirement»
Functional Requirement
«System Model»
System Use Case Diagram
«User Interface Model»
Screen Flow Diagram
Information
{abstract}
«Information Model»
Information Field
«System Requirement»
Non Functional Requirement
Capacity
{abstract}«System Requirement»
System Feature
«Project Model»
Capability
«Information Model»
Information Structure Diagram
«Business Process Model»
Business Process Area Diagram
«Project Model»
Business Outcome
«Project Model»
Risk
Gaugable
{abstract}
Constrainable
{abstract}
Capability Utilizer
{abstract}
Capability Element
{abstract}
Rule Subject
{abstract}
Supplementary
System Diagram
{abstract}
Accelerator Item
{abstract}
Linkable
{abstract}
Constrained ByConstrained By Gauged ByGauged By
**
**
**
**
**
UtilizesUtilizes
**
**Characterized ByCharacterized By
****
ImplementsImplements
**
**
Elaborated ByElaborated By
**
**
Governed ByGoverned By
**
**
Elaborated ByElaborated By
**
**
Subject OfSubject Of**
**
GroupsGroups
1..*1..*
**
**
RequiresRequires
**Operates OnOperates On
** **
Refined ByRefined By**
**
ComprisesComprises
**
**
Enabled ByEnabled By**
**RequiresRequires
**
**
Measured ByMeasured By
**
**Proceeds ToProceeds To
**
**
RealizesRealizes
**
A meta model
...everyone
should
have one
Holocentric July 2010
Summary
• A model driven approach can help drive business outcomes quicker and more accurately than disconnected documents.
• As BA’s our job is not to write documents – it’s to help ensure that the business outcomes are achieved.
30