The Hidden Costs Ba World V2 1

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


REQUIREMENTS DEFINITION

3


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


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!


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)

http://www.ieee.org/portal/site/iportals


THE TRADITIONAL APPROACH

7


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


THE MODEL-DRIVEN APPROACH

9


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


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


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


13


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


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


Process Step

Screen Flow Node

{abstract}

Competency

{abstract}

«Rule»

Rule

«Project Model»

Project Scope Diagram


Business Process Diagram

«System Model»

System Process Diagram


Screen

«Project Model»

Measure

«System Requirement»

Functional Requirement

«System Model»

System Use Case Diagram


Screen Flow Diagram

Information

{abstract}


Information Field


Non Functional Requirement

Capacity

{abstract}«System Requirement»

System Feature

«Project Model»

Capability


Information Structure Diagram


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

**

**


**

**

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

**


DEMONSTRATION

16


RACI Matrix

17


Impact Analysis - Requirements

18


Impact Analysis - Measures

19


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


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


BEYOND USE CASES- A MORE STRATEGIC ROLE FOR BA’S

23


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


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


To training

26


27

Process

Policies & Procedures

Business Requirements

Use Cases

Regulations

To regulations


Tangible Benefits

• Requirements refinement and validation

• At very little cost

• Creation of framework to generate Material for Training


• Creation of framework to generate Material for Change Programs


• 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


29

System Requirements Modeling

Business Requirements Modeling

Business Case Inputs

«Project Model»

Assumption

«System Model»

System Use Case


Process Role


Dialog Message

«System Model»

System Actor

«Project Model»

Business Constraint

«Project Model»

Capability Usage Diagram

«Project Model»

Metric


Information Set

«Rule»

Rule Set

«Project Model»

External Document Reference


Process Step

Screen Flow Node

{abstract}

Competency

{abstract}

«Rule»

Rule

«Project Model»

Project Scope Diagram


Business Process Diagram

«System Model»

System Process Diagram


Screen

«Project Model»

Measure


Functional Requirement

«System Model»

System Use Case Diagram


Screen Flow Diagram

Information

{abstract}


Information Field


Non Functional Requirement

Capacity

{abstract}«System Requirement»

System Feature

«Project Model»

Capability


Information Structure Diagram


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

**

**


**

**

Governed ByGoverned 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


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

The Hidden Costs Ba World V2 1

Documents

Transcript of The Hidden Costs Ba World V2 1