1. Maximizing Requirements Value
Throughout
the Product Lifecycle
Tom Grant, Senior Analyst
April 2012
1 © 2009 Forrester Research, Inc. Reproduction Prohibited
2012

2. Delivering customer value is a challenge
Defining and delivering
the value and quality
customers want top the
list of concerns for
AD&D professionals.
Source: Getty Images (http://www.gettyimages.com/)
2 © 2012 Forrester Research, Inc. Reproduction Prohibited

3. Developers build software for people unlike them
3 © 2012 Forrester Research, Inc. Reproduction Prohibited

4. Ever pay $500K for something you didn’t use?
Standish Group • 32% succeeded.
CHAOS Summary • 44% were challenged.
2009 report • 24% failed.
• Iterative: 71% succeeded.
Dr. Dobb’s Project • Agile: 70% succeeded.
Success Survey • Traditional: 66% succeeded.
• Ad hoc: 62% succeeded.
KPMG Global IT • Nearly one-half of the respondents
Project experienced a project failure the year before.
Management • 86% reported losses of as much as 25% of
Survey 2005 targeted benefits across the portfolio.
Even the most conservative
estimates of failure became
unacceptable
4 © 2012 Forrester Research, Inc. Reproduction Prohibited

5. Many problems that start in requirements
 Customer satisfaction
 Waste
 Innovation
 Value stream
 Business growth or transformation
When asked, “Which of the following
would improve your application
development and support
organization?” the most frequent
answer (66%) was “improvement of
requirements practices.”
5 © 2012 Forrester Research, Inc. Reproduction Prohibited

6. It’s easy to lose track of the customer
6 © 2012 Forrester Research, Inc. Reproduction Prohibited

7. It’s easy to lose track of the customer
7 © 2012 Forrester Research, Inc. Reproduction Prohibited

8. It’s easy to lose track of the customer
8 © 2012 Forrester Research, Inc. Reproduction Prohibited

9. How do we fix this situation?
 Make the information more accurate
 Make the information more timely
 Make the insights more profound
 Make the information load lighter
9 © 2012 Forrester Research, Inc. Reproduction Prohibited

10. Accurate
10 © 2009 Forrester Research, Inc. Reproduction Prohibited
2012

11. Feedback loops? Really?
11 © 2012 Forrester Research, Inc. Reproduction Prohibited

12. Eating your own dog food is not enough
Because you’re
not a dog
12 © 2012 Forrester Research, Inc. Reproduction Prohibited

13. Requirements are a toolkit providing different insights
User stories
Enhancement
requests, Traditional
change requirements
requests, ideas Descriptive Actionable
Contextual Themes, epics
Personas, use cases,
business problems
13 © 2012 Forrester Research, Inc. Reproduction Prohibited

14. Contextual information lost at every toss
TESTER
“Out of all the tests I might do,
which represent the software as
DEVELOPER
someone will actually use it?”
“What should the software do?
Within what parameters for security,
performance, etc.?”
UX DESIGNER
BUSINESS ANALYST “What sort of user experience
does the user expect? What
“Here’s the actionable
would really win them over?”
requirement”
14 © 2012 Forrester Research, Inc. Reproduction Prohibited

15. Timely
15 © 2009 Forrester Research, Inc. Reproduction Prohibited
2012

16. The goal: “Just in time” requirements
16 © 2012 Forrester Research, Inc. Reproduction Prohibited

17. When do we need the requirements, really?
LONG-TERM
Entire project/product timeline (years)
MEDIUM-TERM
Next user-relevant landmark (months)
SHORT-TERM
Next dev-relevant
landmark (weeks)
17 © 2012 Forrester Research, Inc. Reproduction Prohibited

18. When do we need the requirements? (examples)
Descriptive Actionable Contextual
Project/product
Long Initial backlog Personas
plan
Re-prioritized
Medium Themes/epics Use cases
backlog
User stories User stories
Short User feedback
(prioritization) (design)
18 © 2012 Forrester Research, Inc. Reproduction Prohibited

19. Profound
19 © 2009 Forrester Research, Inc. Reproduction Prohibited
2012

20. Are we having the best possible conversations?
One-on-one negotiations
between the business
faction and the IT faction
are hardly optimal
20 © 2012 Forrester Research, Inc. Reproduction Prohibited

21. 21 © 2012 Forrester Research, Inc. Reproduction Prohibited

22. INPUT: Change the rules with serious games
 Structured
– Rules, but often no winners
 Purposeful
– Definite outcome
 Time-bound
– By definition, a time-boxed exercise
 Participatory
– Success depends on everyone
participating.
 Egalitarian
– Everyone has an equal opportunity
to participate.
22 © 2012 Forrester Research, Inc. Reproduction Prohibited

23. EXAMPLE: Buy a feature
FEATURE COST SPENT
Android app for activity management $5,000 -
Custom pipeline stages $2,000 $500
More complex lead-scoring options $3,500 -
More canned reports $1,500 $300
Define and manage teams $4,750 $2,000
Easy clean-up of bad or duplicate data $2,500 $2,500
Activity entry via email $3,250 -
Associate teams with prospects $1,250 -
23 © 2012 Forrester Research, Inc. Reproduction Prohibited

24. Light-weight
24 © 2009 Forrester Research, Inc. Reproduction Prohibited
2012

25. More skills and experiences needed
ECONOMICS
COMPUTER
Descriptive Actionable SCIENCE
Contextual
ANTHROPOLOGY
25 © 2012 Forrester Research, Inc. Reproduction Prohibited

26. “Just in time” requirements take skill, resources, tools
 Cultivate the right sources
– EX: Business users, social media,
past requirements, etc. etc.
 Identify the right source to answer
the question
– EX: Do we need insight or
validation?
 Triangulate using multiple sources
– EX: One source provides depth,
another ensures that the answer is
representative
 Deliver the actionable and
contextual content that people need
26 © 2012 Forrester Research, Inc. Reproduction Prohibited

27. Next steps
27 © 2009 Forrester Research, Inc. Reproduction Prohibited
2012

28. How do we fix this situation?
Treat requirements
discipline as more
than a “nice-to-have”
28 © 2012 Forrester Research, Inc. Reproduction Prohibited

29. Discipline is a precondition of collaboration
I love what
you’ve built!
CUSTOMER
SATISFACTION
Wow, we could
have wasted a
lot of time fixing
issues
TRACEABILITY
WASTE
Now we know
something about
why someone
The people who adopts our
write requirements technology
INNOVATION
29 © 2012 Forrester Research, Inc. Reproduction Prohibited

30. Signs of requirements discipline
Do you do retrospectives on requirements?
Do you measure something
more than the number of words?
Do you experiment with your toolkit?
Do you deliver requirements just in time?
30 © 2012 Forrester Research, Inc. Reproduction Prohibited

31. How do you know you’re doing well?
If you treat You might find yourself And you’ll share them
requirements saying . . . with . . .
as a . . .
Necessity “Thank God that’s done. Just the development
Now, on to coding!” team.
Catalyst “Wow, that new persona The next person you’re
made me rethink our trying to convince.
app.”
Commodity “When was the last time Everyone, in a format that
we looked at those user makes sense to them.
stories?”
31 © 2012 Forrester Research, Inc. Reproduction Prohibited

32. How do you know you’re doing well?
“The dev team has
a question . . .” QUALITATIVE
Ask the community.
Call “go to” users or
stakeholders.
Review personas, use
cases, other existing
content.
QUANTITATIVE
Someone can provide
this information in less Collect usage stats.
than a day.
Do a quick poll.
Analyze data from public sources
(blogs, communities, etc.).
32 © 2012 Forrester Research, Inc. Reproduction Prohibited

33. Thank you
Tom Grant
+1 650.581.3846
tgrant@forrester.com
www.forrester.com
© 2009 Forrester Research, Inc. Reproduction Prohibited