Minimize the project risk - build good business requirements

C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y
Minimize the project risk - build good
business requirements

About me
Areas: Business and System Analysis, Quality
Assurance, IT consulting and trainings.
International experience in banking and insurance
sector.
Customers: leading financial organizations in South
Africa, Netherlands, Austria, Slovakia, Italy and Poland.
Author of several publications in QA and BA area.
Member of REQB and IBAQB.
2/15/2016
2

What we are going to speak about?
Impact of business requirements on IT projects
Gold rules
Writing good business requirements
2/15/2016
3

Do you remember The Chaos Report?
2/15/2016
4
The Chaos Report 2009, Standish Group

Do you remember The Chaos Report?
2/15/2016
5
Generally speaking, the primary reasons for failure are:
Lack of user
involvement
Lack of
management
commitment
Problems
with
requirements
and
specifications
Changing
requirements
Unclear
objectives

What is the REAL problem?
Are those the real problems or just symptoms of
something else?
What can we see in real life?
 Lack of analysis and preparation for a project
 Projects initiated without deep analysis, and
determination of main goals, risks, benefits...
 Projects aim to deliver SOFTWARE, not
SOLUTIONS
 Main success criteria – time and cost
2/15/2016
6

Where is QUALITY?
2/15/2016
7
Cost
ScopeTime
Quality

What is quality?
 ISO 9000 – „Degree to which a set of inherent
characteristics fulfills requirements”
How to assure quality if:
 Stated requirements are not complete?
 Stated requirements have no business value?
 We don’t know how requirements meet business
goals?
2/15/2016
8

The real problem are
requirements...
Business requirements
2/15/2016
9
IllustrationbyJohnTenniel,wood-engravingbyThomasDalziel.
FromChapter6,AliceinWonderlandbyLewisCarroll.

Writing Business Requirements
How to write good business requirements?
Learn from mistakes
Follow best practices!
2/15/2016
10

Writing Business Requirements
Ten Key Principles for Successful
Requirements
Tom Gilb
2/15/2016
11

Ten key principles for successful requirements
1. Understand the top level critical objectives
2. Look towards value delivery: systems thinking, not just software
3. Define a ‘requirement’ as a ‘stakeholder-valued end state’
4. Think stakeholders: not just users and customers!
5. Quantify requirements as a basis for software engineering
6. Don’t mix ends and means
7. Focus on the required system quality, not just its functionality
8. Ensure there is ‘rich specification’: requirement specifications need far
more information than the requirement itself!
9. Carry out specification quality control (SQC)
10. Recognize that requirements change: use feedback and update
requirements as necessary
2/15/2016
12

Understand the top level critical objectives
High-level
requirements (the ones
that funded the project,
the objectives) are
often vaguely stated,
and ignored by the
project team.
2/15/2016
13

Understand the top level critical objectives
Example of Initial Top
Level Objective
Will allow to perform core
banking transaction in
shorter time
2/15/2016
14

Look towards value delivery
Systems thinking, not just a focus on software.
The real aim of a project is delivering realized value
(benefits) to the stakeholders.
Realized value is not the defined functionality!
Value is „the benefit we think we get from something”
(Tom Gilb).
Conventional requirements engineering is not closely
enough coupled with „value”.
2/15/2016
15

Look towards value delivery
What if the requirements do not express value?
 Failure to deliver the value expected
 Even if „requirements” are satisfied!
 Lack of all the other things necessary to actually
deliver full value to real stakeholders on time
2/15/2016
16

Define a „requirement” as a „stakeholder-valued end state”
What a requirement is?
What it is for you, and what it is for your customer?
Define:
 A requirement (a stakeholder-valued end state)
 A requirement specification
 An implemented requirement
 A design in partial, or full service, of implementing a
requirement
2/15/2016
17

Think stakeholders: not just users and customers!
Don’t focus requirements solely on user or customer
needs.
Identify stakeholders.
 A stakeholder is anyone or anything that has an
interest in the system.
 It is not just the end-users and customers.
 Consider: IT development, IT maintenance, senior
management, government, regulation bodies, etc.
Consider thea broader area of stakeholders’ needs and
their values.
2/15/2016
18

Quantify requirements as a basis for software engineering
Are you working in software engineering? Then
practice real engineering!
The problem is the lack of numeric quality
requirements.
Argue with numbers and measures.
Don’t produce requirements specifications consisting
merely of words.
Solution: define, or reuse a definition, of a scale of
measure.
2/15/2016
19

Quantify requirements as a basis for software engineering
Responsiveness:
Ambition: Fast immediate response to any type of user asking for information.
Type: Workload Capacity Requirement.
Scale: Time in seconds from when a defined [User] knows what they want to ask until the
correct necessary information is available to them to carry out a defined [Task].
Past [User = Free Set, Task = Inquiry]: Over one minute. Note: Considered unacceptably
slow.
Goal [User = Responsible Administrator, Task = Any Administration Task]: under 5
seconds?
Goal [User = Phone User, Task = Call Setup]: Less than <2 seconds>
2/15/2016
20
Tom Gilb, Competitive Engineering

Don’t mix ends and means
Perfection of means and confusion of ends
seem to characterize our age.
Albert Einstein
2/15/2016
21

Solutions are more concrete.
Qualities we want are more abstract.
Don’t mix ends and means.
Don’t specify a solution, design and/or architecture,
instead of what you really want – real requirement.
WHY?
2/15/2016
22

Be careful what you ask for,
you might just get it.
2/15/2016
23

If you specify a solution, instead of what you really
want:
 You might not get what you really want
 The solution you have specified might cost too
much or have bad side effects, even if you do get
what you want
 There may be much better solutions you don’t
know about yet
2/15/2016
24

Not:
“The system must print a transaction receipt
for the customer.”
But:
“The customer must be provided with a
transaction confirmation after every
transaction, within 2 minutes after completing
a transaction.”
2/15/2016
25

How then?
Use variation of 5xWhy.
Search for the real need by asking Why?
 Why do you want <the report>?
 Because I really want <specific data> and assume I will get it
through this report.
 Then why do you want <specific data>?
 Because I really want <to calculate X> and assume that is
the best way to get <the report>.
2/15/2016
26

Focus on the system quality, not just its functionality
Quality improvements tend to be the major drivers for
new projects.
What the system must do (function) is important.
But don’t forget about how well it should do it
(qualities).
Focus on the quality requirements, rather than the
functions.
2/15/2016
27

Ensure there is „rich specification”
Far too much emphasis
is placed on the
requirement itself.
Far too little information
is gathered about its
background.
2/15/2016
28

Ensure there is ‘rich specification’
Background specification may include:
 Benchmarks {Past, Record, Trend}
 Owner
 Version
 Stakeholders
 Gist (brief description)
 Ambition
 Impacts
2/15/2016
29

Ensure there is ‘rich specification’
Such information:
 Allows to judge value of the requirement
 Allows to prioritize the requirement
 Help understand risks related with the requirement
 Helps when updating a requirement
 Synchronizes the relationships between different but
related levels of the requirements
 Improves the clarity of the requirement
2/15/2016
30

Carry out Specification Quality Control (SQC)
Apply quality control of requirements against relevant
standards for requirements.
Use quality control checklists.
All requirements and specifications should pass quality
control checks before they are released for use by the
next processes.
2/15/2016
31

Initial quality control of requirements specification
typically identifies 80 to 200+ words per 300 words of
requirement text as ambiguous or unclear.
2/15/2016
32

Use quality criteria – each requirement should be:
Correct
Feasible
Necessary
Prioritized
Unambiguous
Verifiable
Singular
Design independent
2/15/2016
33

Recognize that requirements change
Requirements evolve due to feedback from
stakeholders.
 Stakeholders can give feedback about their
perception of value, based on realities.
 The whole process follows Plan-Do-Study-Act.
Consider factors from outside the system:
 Politics, law, regulations, international differences,
economics, and technology and/or business
change.
2/15/2016
34

Recognize that requirements change
Implement traceability to manage changes in effective
way.
2/15/2016
35
Business goal
Business
requirement
Solution/system
requrement
Solution/system
requrement
Solution/system
requrement
Business
requrement
Solution/system
requrement
Solution/system
requrement

So, how to start...
Implementing the rules
2/15/2016
36

Stakeholders
Who has any interest in the project?
Who can limit the capabilities?
Who will be involved?
2/15/2016
37

Business objectives
Collect and understand business objectives.
Decompose them into smaller, SMART goals.
SMART goals:
 Specific
 Measurable
 Attainable
 Relevant
 Timely (time-bound)
2/15/2016
38

Derive business requirements
Derive business requirements from the goals.
Ensure commitment for each business goal
2/15/2016
39
Business goal
Business
requirement
Business
requirement
Business
requirement
Business
requirement

The requirement statement
Use the structure of the requirement statement:
 The user
 who would like this requirement?
 The result
 what is the result stakeholders are looking for?
 The object
 what is the object the requirement addresses?
 The qualifier
 what is the qualifier that is measurable?
2/15/2016
40

The insurance agent must have information about
any new products one day prior to the product
launch.
Look at the structure of the business requirement.
 The insurance agent  who
 must have information about  what result
 any new products  what object
 one day prior to product launch  qualifier
2/15/2016
41

Don’t determine the solution – just state what needs
to be achieved.
State WHAT, not HOW.
2/15/2016
42

Traceability
Link each business
requirement with
appropriate business
goal.
Link each solution
requirement with
appropriate business
requirement.
2/15/2016
43

Quality Control
Use check lists...
Use standards...
Use best practices...
... to ensure the
requirements are of good
quality.
2/15/2016
44

Summary
The impact of business requirements on the success of
any IT project cannot be neglected
Link business requirements with goals
State requirements in measurable way and ensure they
express stakeholders’ value
Think who wants what, not how
Don’t forget about quality control
2/15/2016
45

Readings
What is Wrong with Requirements – Tom Gilb
http://gilb.com/dl443
Guide for Managing and Writing Good Requirements –
Ivy F. Hooks
The Business ROI for Requirements – Essential Best
Practices for driving Quality – Karl Wiegers
2/15/2016
46

Contact
2/15/2016
47
PRINCE2®, ITIL®, M_o_R®, P3O®, MSP®, P3M3® są zarejestrowanymi znakami handlowymi Cabinet Office. MoV™, MoP™, Swirl logo™ są znakami handlowymi Cabinet
Office. CHAMPS2® jest zarejestrowanym znakiem handlowym Birmingham City Council. PMBoK is a registered mark of the Project Management Institute, Inc. The PMI
Registered Provider logo is a registered mark of the Project Management Institute, Inc.
www.crm.com.pl
KAROLINA ZMITROWCZ
k.zmitrowicz@crm.com.pl
Centrum Rozwiązań Menedżerskich S.A.
Devoteam Consulting
ul. Kłobucka 25, 02-699 Warszawa

Minimize the project risk - build good business requirements

More Related Content

What's hot

Similar to Minimize the project risk - build good business requirements

More from KAROLINA ZMITROWICZ

Recently uploaded

Minimize the project risk - build good business requirements

Editor's Notes