A Roadmap For Building The Right Solution

www.iRise.
com
A Roadmap for Building the Right Solution
Kurt Bittner
Chief Technical Officer - Americas Presented by:
Ivar Jacobson Consulting
1
1
The Problem with Business Software
 Business goals are poorly understood by IT, &

often by the business itself
 “Requirements” processes often dive too deep,

too early into specifying poorly conceived
solutions
 Cultural divide between business & IT clouds

communication
 Exploring innovative alternatives is slow &

expensive
www.iRise.com
Copyright © 2008, iRise and Ivar Jacobson International

www.ivarjacobson.com 2
The Impact
 Unmet business needs and failed business plans

 Cost and schedule overruns
 Wasted expenditures
 Solutions delivered that remain unused
 Eroded trust between business & IT
 Poor morale and poor retention of skilled staff
“In the last year, 70% of projects failed to meet deadlines,

and 50% of projects fail to meet the needs of the business.
80% of the issues stem from poor requirements.”
Standish Group Chaos Report, 2007
www.iRise.com

www.iRise.com

4
Understand
Desired Outcomes
www.iRise.com

5
IBM Rational Software Development Conference 2008
Supporting Data
 Only 5% of all product returns are defective
• Customers were dissatisfied with a working
product
 60+% of all software projects fail to deliver
on time or desired functionality
• Even on successful software projects, up to
30% of all features are never used
 Lack of understanding of real needs is a key
factor, if not THE FACTOR, in these failures
www.iRise.com
QuickTime™ and a
decompressor
are needed to see this picture.
www.ivarjacobson.com 6 6
Understanding Desired Outcomes (Needs)
 Requirements don’t help you understand the

problem or the opportunity
 Requirements define a solution, sometimes to the

wrong problem
 Problems need to be addressed at their root

causes
• Treating the symptoms can result in temporary relief
• But treating the symptoms is often more complex than
addressing the root cause
 Determining root causes and desired outcomes

takes time & real insight
www.iRise.com

The Effects of Poorly Understood Needs
 Adding features that do not address real needs adds
to:
• Complexity
• Cost of development, testing, adoption & support
• Schedule
All without any real benefit
 Failing to deliver the right solution damages trust and
credibility
• No matter how good the code or the quality of the
solution, if it does not solve the right problem all the
effort is wasted
 But… you cannot expect users or stakeholders to tell

you what they really need… at least not directly
www.iRise.com

Techniques for Understanding Needs
 Problem Analysis Approaches

• 5 Whys
• Fishbone diagrams
• Pareto Charts
• Mind Maps
• Desired Outcomes Analysis
www.iRise.com

Explore Solutions
www.iRise.com

10
Exploring Solutions
 The best approach is to explore solutions
through visualization
 Business analysts, product managers & UE

professionals assemble three dimensional
simulations of possible solutions
 Business and IT stakeholders “test drive” &

provide feedback in rapid, interactive
explorations
 Discussions are more focused & engaging
 Visualization dramatically improves

communication between business & IT
www.iRise.com

The Value of Visualization
 Most people think visually
rather than verbally;
visualization enables
people to be more
creative
 Visualization forces
people to be concrete
about the solution that
they often have in their
heads
 Visualization creates
more interesting
discussions about
possibilities than
“documents”
 Visualization provide a
Visualization converges the vision way to articulate the
solution in in a language
of the solution faster
www.iRise.com
everyone can understand

12
Other Techniques Can Complement Visualization
 For parts of the solution that do

not lend themselves to
visualization, other techniques
can help:
• business process modeling
• domain modeling
• glossary of terms
• financial modeling
 Not all stakeholders will

understand or find these
techniques useful, but for
specialized areas of the domain
they can be helpful
www.iRise.com

13
Evaluate
Alternatives
www.iRise.com

14
Evaluating Alternatives
 Often, a number of possible solutions will need to be evaluated
 Comparing solutions back to the desired outcomes helps to determine
which best meet the needs of the business
 Rough order of magnitude schedule and budget estimates, compared
with expected business benefits, are used evaluate the financial worth
of the solution
• Visualizations and other information gathered while exploring solutions
are the primary drivers of these estimates
www.iRise.com

15
Augment
Specification
www.iRise.com

16
Augmenting Specifications
 Visualization helps people to comprehend

how the solution will work -- but sometimes
something more is needed to tie things
together
 Areas that can need more work usually

involve data, process flows, business rules
 Additional scenarios may need to be

visualized as well
www.iRise.com

17
A Map of Requirements Techniques
www.iRise.com

18
Comparing Requirements Techniques
Facilitates Handles inter- Low over- Handles

Technique
discussion dependencies head “flows”
Declarative (Traditional) Moderate Poor Moderate Poor
Scenario-based Good Moderate Poor Good
Model-based Moderate Good Poor Moderate
Prototype-based Good Poor Moderate Good
Testing-based Moderate Poor Good Moderate
Backlog-based Poor Poor Good Poor
The best approach uses an appropriate blend of techniques based

on the complexity of the domain, the domain expertise of the
project team, the degree of cooperation between IT & the
business, the need for enduring documentation, & the degree of
www.iRise.com
governance oversight required.

19
Use Cases and Visualization
 Use cases are useful to capture the usage scenarios, while visualization
is ideal for eliciting feedback & exploring usability issues
 Done in parallel, they complement one another
Basic Flow
The use case begins when the
Banking Customer wishes to pay a
bill online.
{select account}
The system presents the list of
accounts held by the Banking
Customer.
The Banking Customer selects the Movie-making analogy
account from which the bill will be
paid.
{enter Bill Payee information}
The system prompts the Banking
Script
Customer for Bill Payee information.
The Banking Customer provides the
Bill Payee information. Storyboard
{enter amount}
The system prompts for the payment
amount.
www.iRise.com
The Banking Customer enters the

payment amount.
...

20
Using a Domain Model
 The Domain Model is a convenient

mechanism for capturing requirements
about data
 Many tools enable prototypes to be
generated from data models (like the
domain model)
 The domain model is easily integrated
with other requirements approaches
www.iRise.com

21
Using Business Process Models
 Business Process Models are often useful to explore and document
business processes:
• Decision-making processes
• Workflows
• Logistical & Manufacturing Processes
 Not all the interesting things that

a system needs to do can be
visualized
 Explicit consideration of
processes helps to identify
opportunities for simplification
www.iRise.com

Using Models & Visualization Together
 Used correctly, models complement the

visualizations
Data Models
Business Process
Models
www.iRise.com

23
Strategies for Reviews
 Using the visualizations, walk
through scenarios , describing how
the solution will deliver the
desired outcomes
 Bring in other reference material
where needed to supply detail
 Make the sessions interactive
 Look for undiscovered desired
outcomes or ways to improve
processes
 Seek to simplify
Don’t circulate documents! You won’t get good feedback and
you’ll miss the opportunity for an interactive discussion about
www.iRise.com
whether you’ve met the real needs.

24
Choosing the Right Participants
 Select people with a deep understanding of

the process being improved
• People who will be directly affected by the
outcomes produced by the solution
• A small but diverse group of individuals – not
just “lead users” but also, and especially,
“average” users
 Avoid people only indirectly involved in the

solution
 Avoid using the review session for

“information sharing”
www.iRise.com

25
Develop
www.iRise.com

26
Developing Solutions
 Having visualizations & supporting

documentation provides a firm foundation on
which to build
 Keeping open communication with the

business is important - frequent
demonstration and review of working
software builds confidence & allows fine-
tuning of direction
Frequent review of working software is the

www.iRise.com
surest means of keeping a project on track

27
Evaluate
Results
www.iRise.com

28
Evaluating Results
 Testing is essential for closing the loop - it is a

means for evaluating whether the overall
project objectives were achieved
 Testing means more than just making sure

there are no defects - it also means making
sure the solution meets expectations.
• Comparing results delivered against the
desired outcomes will tell you whether you
have delivered the right thing
 Involving the business in the effort,

continuously throughout the project, ensures
that expectations are being met
www.iRise.com

29
Summary
 Improving results from software projects is
mostly about improving communication
 Clarity about desired outcomes is essential,
but is often overlooked in the rush to
develop solutions
 Visualization of potential solutions is an ideal
way to achieve consensus on how the
solution will deliver the desired outcomes
 Continuous feedback through the
development effort provides a means of
assessing progress
 Testing means more than just verifying that
there are no defects - it more importantly
www.iRise.com
means closing the loop back to business

value
30
About iRise
 7+ years of leadership in visualization

 200+ customers across a broad portfolio
of industries
 World’s first patents awarded for
application simulation (2007, 2008)
 Global community of 10,000+
visualization authors & 25,000+ reviewers
 Backed by Morgan Stanley Venture
Partners & Deutsche Bank
www.iRise.com

31
Proven Success
About Ivar Jacobson International
 Our mission: to help project teams and
organizations be more successful in the way they
develop software
 Our approach: working practice by practice, we
help clients to make dramatic improvements
incrementally
 Our pedigree: we invented use cases, co-
developed the Unified Modeling Language, and
led the early evolution of the Rational Unified
Process
www.iRise.com

32
6
9
Thank you for attending

For further questions, please contact:
Kurt Bittner, CTO

Ivar Jacobson International
kbittner@ivarjacobson.com
Mitch Bishop, CMO

iRise
mbishop@irise.com
www.iRise.com

33

A Roadmap For Building The Right Solution

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Roadmap For Building The Right Solution

Enviado por

Direitos autorais:

Formatos disponíveis

www.iRise.

A Roadmap for Building the Right Solution

 Business goals are poorly understood by IT, &

 “Requirements” processes often dive too deep,

 Cultural divide between business & IT clouds

 Exploring innovative alternatives is slow &

Copyright © 2008, iRise and Ivar Jacobson International

 Unmet business needs and failed business plans

“In the last year, 70% of projects failed to meet deadlines,

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

 Requirements don’t help you understand the

 Requirements define a solution, sometimes to the

 Problems need to be addressed at their root

 Determining root causes and desired outcomes

Copyright © 2008, iRise and Ivar Jacobson International

 But… you cannot expect users or stakeholders to tell

Copyright © 2008, iRise and Ivar Jacobson International

 Problem Analysis Approaches

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

 Business analysts, product managers & UE

 Business and IT stakeholders “test drive” &

 Discussions are more focused & engaging

 Visualization dramatically improves

Copyright © 2008, iRise and Ivar Jacobson International

everyone can understand

Copyright © 2008, iRise and Ivar Jacobson International

 For parts of the solution that do

 Not all stakeholders will

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

 Visualization helps people to comprehend

 Areas that can need more work usually

 Additional scenarios may need to be

Copyright © 2008, iRise and Ivar Jacobson International

Copyright © 2008, iRise and Ivar Jacobson International

Facilitates Handles inter- Low over- Handles

Declarative (Traditional) Moderate Poor Moderate Poor

Scenario-based Good Moderate Poor Good

Model-based Moderate Good Poor Moderate

Prototype-based Good Poor Moderate Good

Testing-based Moderate Poor Good Moderate

Backlog-based Poor Poor Good Poor

The best approach uses an appropriate blend of techniques based

governance oversight required.

Copyright © 2008, iRise and Ivar Jacobson International

The Banking Customer enters the

Copyright © 2008, iRise and Ivar Jacobson International

 The Domain Model is a convenient

Copyright © 2008, iRise and Ivar Jacobson International

 Not all the interesting things that

Copyright © 2008, iRise and Ivar Jacobson International

 Used correctly, models complement the

Copyright © 2008, iRise and Ivar Jacobson International

whether you’ve met the real needs.

Copyright © 2008, iRise and Ivar Jacobson International

 Select people with a deep understanding of

 Avoid people only indirectly involved in the

 Avoid using the review session for