Moving from Requirements Order-Taker

to Business-Enabler

David Marsh

March 25, 2013

What’s About to Happen?

• What is the problem?

– And why is it an important one to solve?

• Some order-taking scenarios

• A better approach

• Specific techniques designed to enable business/service

success

The Problem: Consequences of public

sector failure are higher than private sector

• Governments typically have deeper pockets: result is that they

incur higher losses

– “a billion-plus of taxpayer’s money went to essentially

nothing.” (Lt. Gen. Charles Davis on recent USAF logistics

software project failure )

– US government is spending $81 billion/year on IT as of 2012

• Estimated that $20 billion of this is wasted per year

(Darrell Issa, Chairman of Senate Committee on

Oversight and Government Reform)

– The UK Office of National Statistics reported that public

service productivity fell 3.2% between 1997 and 2007; at the

same time annual ICT spending was between £13-21 billion

per year (according to Dr. Martin Read)

The Problem: Consequences of public

sector failure are higher than private sector

• Difficultly quantifying the benefits of public sector projects:

results in a tougher decision on when to quit spending money

• National security may be jeopardized

• Freedom of Information (FOI) access and Auditors: failure

made public

– Ontario’s Social Assistance and eHealth systems are

examples

• The problems tend to affect many people: private sector

comparisons include AT&T’s switching problems affecting 60K

long-distance customers in 1990 and 100K LinkedIn passwords

hacked in 2012

My point: the cost of failure is high

Requirements cited as the reason for failure

• Reasons vary, but at the top of everyone’s list are:

– Unrealistic or unarticulated project goals

– Badly defined system requirements

• Incomplete requirements

• Changing requirements and specifications

• Of course there are other reasons as well... but the point is that

we need to “get better at requirements”

– But why are requirements so bad?

Some typical reasons

• “No one told us they needed that”

– Ontario social assistance system was incapable of raising

rates (cost to fix: $10 million)

• “Nebulous requirements”

– The USAF logistics system failure example

• “Hi, we need a new field... status... child table”

– It seems to start off so innocently

• “We are not allowed to question the business – it offends them”

– IT departments do as they are told, acting as pass-

throughs rather than value-add organizations

A better way: an engineering approach

Technical

capabilities

Business goals

and needs

Detailed software

requirements

Detailed technical

specifications

Understand root

causes and discover

real business needs

Explore and evaluate

alternative solutions

that meet the needs

Traditional techniques for eliciting

requirements

• Designed to identify root causes of problems:

– Pareto (fishbone) diagrams

– 5-Whys

– Brainstorming

• Designed to understand a domain:

– Data modeling

– Interviews and observation

– Process and organizational modeling

• Confirm business goals/vision

• Designed to define software requirements:

– Use case modeling/user stories

– Non-functional requirements elicitation

My preferred techniques

• Understanding problems and desired outcomes

– Ensure how we measure we are successful at

resolving/achieving these

• The “spirit” of use cases

– Use cases happen to be documented, but they are not

documents

• Repeating back incorrectly or differently

– When people get a little miffed they tell you what they really

need

• Throwing real situations at requirements and draft designs

– Early feedback using real world scenarios

Problems and Desired Outcomes

• 2 questions I ask:

– What about the current approach is preventing you from

doing your work?

– 6 months after the project is complete, someone asks you,

“Was it successful?” What measures do you use to tell them

yes or no?

• The output of these sessions (samples follow) become the

driving forces behind the project

Sample Problem Statements

The problem of Affects The impact of which is A successful solution would

Restricted store

hours due to

municipal

regulations and labor

restrictions

Customers The inability to access

the store when needed

Enable customers to access

merchandise whenever they need to, no

matter where they are.

Marketing, Sales Loss of positive brand

image since our products

are not available to our

customers when they

need them

Reestablish a strong brand image by

making our store the first place to look

when renovating.

Excessive inventory

carrying costs

Supply Chain

Operations

Limited ability to

carry large items in

stores

Limited ability to

carry large

quantities of all

items in stores

Enable our store to market all

household and hardware items, no

matter how large.

Facilitate “direct-from-supplier”

delivery.

Sample Desired Outcomes

Desired

Outcome

Objectives Priority Evaluation Criteria

Increased

Efficiency

No lost documents Must The number of tickets opened to find lost

documents on accounts is 20% of what it is before

the system is deployed.

Improved inspection review

process

Must The turn-around time for reviews of inspections

must be 60% of what it is before the system is

deployed.

Service center team members

re-assigned

Must Due to elimination of paper files, all staff

responsible for handling these can be re-assigned

to other work

Reduction in

Operational

Cost

Elimination of the binders

means that auditors do not

have to travel to the field

offices for audits; thus a

reduction in the travel budget

Must The travel budget for audit is currently $27,600 for

the year 2010; this must go away in 2011

Remote machines are no

longer needed

Should The 54 remote machines are removed from field

offices

Eliminate sending documents

to Iron Mountain, on a go-

forward basis

Must No documents sent to Iron Mountain for accounts

effective 1 June 2010 and onwards.

The “spirit” of use cases

uc Inv oicing Use Cases

Invoicing System

Inv oice Submitter

Submit Inv oice

Approv e Purchase

Order

Reconcile PaymentsPayment Manager

Paymenrt System

This is not a

function. It

reprsents a

goal and a

story.

The story has a

usual set of steps

(basic flow,

linear) and rare/

exceptional/

abnormal

alternatives

(lateral).

• The use case model actually reflects

the selected alternate solution

Summing up

• There is a higher risk that government projects fail to deliver

value, and the consequences of that failure can be exceedingly

high

• “Requirements” cited as the reason for failure

– Often due to pass-through order taking

– Real analysis of the business goals and exploration of

alternative solutions is key to turning this around

• There is hope: there are proven techniques for becoming a

“business-enabler” instead of an “order-taker”

Thank You!

Questions?