webinar - maximizing requirements value throughout the product lifecycle
TRANSCRIPT
© 2012 Forrester Research, Inc. Reproduction Prohibited1 © 2009 Forrester Research, Inc. Reproduction Prohibited
Maximizing Requirements Value Throughout the Product Lifecycle
Tom Grant, Senior Analyst
April 2012
© 2012 Forrester Research, Inc. Reproduction Prohibited2
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/)
© 2012 Forrester Research, Inc. Reproduction Prohibited3
Developers build software for people unlike them
© 2012 Forrester Research, Inc. Reproduction Prohibited4
Ever pay $500K for something you didn’t use?
• 32% succeeded.• 44% were challenged.• 24% failed.
Standish Group CHAOS Summary
2009 report
• Iterative: 71% succeeded.• Agile: 70% succeeded.• Traditional: 66% succeeded.• Ad hoc: 62% succeeded.
Dr. Dobb’s Project Success Survey
• Nearly one-half of the respondents experienced a project failure the year before.
• 86% reported losses of as much as 25% of targeted benefits across the portfolio.
KPMG Global IT Project
Management Survey 2005
Even the most conservative estimates of failure became unacceptable
© 2012 Forrester Research, Inc. Reproduction Prohibited5
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.”
© 2012 Forrester Research, Inc. Reproduction Prohibited6
It’s easy to lose track of the customer
Untestedideas
Customers with
too much influence
Inadequate
information
Infrequent contactswith customers
Your best
customer
© 2012 Forrester Research, Inc. Reproduction Prohibited7
It’s easy to lose track of the customer
OVERBEARINGPERSONALITIES
Compartmentalization
Unwillingness tochallenge assumptions
RESISTANCE TO CHANGE
© 2012 Forrester Research, Inc. Reproduction Prohibited8
It’s easy to lose track of the customer
No time for
retrospection
Design errors
Development diverges from
delivery
© 2012 Forrester Research, Inc. Reproduction Prohibited9
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
© 2012 Forrester Research, Inc. Reproduction Prohibited10 © 2009 Forrester Research, Inc. Reproduction Prohibited
Accurate
© 2012 Forrester Research, Inc. Reproduction Prohibited11
Feedback loops? Really?
© 2012 Forrester Research, Inc. Reproduction Prohibited12
Eating your own dog food is not enough
Because you’re not a dog
© 2012 Forrester Research, Inc. Reproduction Prohibited13
Requirements are a toolkit providing different insights
Actionable
Contextual
Descriptive
User stories
Personas, use cases,
business problems
Themes, epics
Enhancement
requests,
change
requests, ideas
Traditional
requirements
© 2012 Forrester Research, Inc. Reproduction Prohibited14
Contextual information lost at every toss
BUSINESS ANALYST
“Here’s the actionable
requirement”
DEVELOPER
“What should the software do?
Within what parameters for
security, performance, etc.?”
TESTER
“Out of all the tests I might do,
which represent the software as
someone will actually use it?”
UX DESIGNER
“What sort of user experience
does the user expect? What
would really win them over?”
© 2012 Forrester Research, Inc. Reproduction Prohibited15 © 2009 Forrester Research, Inc. Reproduction Prohibited
Timely
© 2012 Forrester Research, Inc. Reproduction Prohibited16
The goal: “Just in time” requirements
© 2012 Forrester Research, Inc. Reproduction Prohibited17
When do we need the requirements, really?
LONG-TERM
MEDIUM-TERM
SHORT-TERM
Entire project/product timeline (years)
Next user-relevant landmark (months)
Next dev-relevant
landmark (weeks)
© 2012 Forrester Research, Inc. Reproduction Prohibited18
When do we need the requirements? (examples)
Long Project/product plan Initial backlog Personas
Descriptive Actionable Contextual
Medium Re-prioritized backlog Themes/epics Use cases
Short User stories(prioritization)
User stories(design) User feedback
© 2012 Forrester Research, Inc. Reproduction Prohibited19 © 2009 Forrester Research, Inc. Reproduction Prohibited
Profound
© 2012 Forrester Research, Inc. Reproduction Prohibited20
Are we having the best possible conversations?
One-on-one negotiations between the business faction and the IT faction are hardly optimal
© 2012 Forrester Research, Inc. Reproduction Prohibited21
TIME TO
CHANGE
THE
RULES
© 2012 Forrester Research, Inc. Reproduction Prohibited22
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.
© 2012 Forrester Research, Inc. Reproduction Prohibited23
EXAMPLE: Buy a feature
Android app for activity management
Custom pipeline stages
More complex lead-scoring options
More canned reports
Define and manage teams
Easy clean-up of bad or duplicate data
Activity entry via email
Associate teams with prospects
$5,000
$2,000
$3,500
$1,500
$4,750
$2,500
$3,250
$1,250
FEATURE COST
-
$500
-
$300
$2,000
$2,500
-
-
SPENT
© 2012 Forrester Research, Inc. Reproduction Prohibited24 © 2009 Forrester Research, Inc. Reproduction Prohibited
Light-weight
© 2012 Forrester Research, Inc. Reproduction Prohibited25
More skills and experiences needed
Actionable
Contextual
Descriptive
ECONOMICS
COMPUTERSCIENCE
ANTHROPOLOGY
© 2012 Forrester Research, Inc. Reproduction Prohibited26
“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
© 2012 Forrester Research, Inc. Reproduction Prohibited27 © 2009 Forrester Research, Inc. Reproduction Prohibited
Next steps
© 2012 Forrester Research, Inc. Reproduction Prohibited28
How do we fix this situation?
Treat requirements discipline as more than a
“nice-to-have”
© 2012 Forrester Research, Inc. Reproduction Prohibited29
Discipline is a precondition of collaboration
CUSTOMER
SATISFACTION
WASTE
INNOVATION
TRACEABILITY
The people who
write requirements
I love what you’ve built!
Wow, we could have wasted a lot of time fixing
issues
Now we know something about
why someone adopts our technology
© 2012 Forrester Research, Inc. Reproduction Prohibited30
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?
© 2012 Forrester Research, Inc. Reproduction Prohibited31
How do you know you’re doing well?
If you treat requirements
as a . . .
Necessity
Catalyst
Commodity
You might find yourself saying . . .
“Thank God that’s done. Now, on to coding!”
“Wow, that new persona made me rethink our
app.”
“When was the last time we looked at those user
stories?”
And you’ll share them with . . .
Just the development team.
The next person you’re trying to convince.
Everyone, in a format that makes sense to them.
© 2012 Forrester Research, Inc. Reproduction Prohibited32
How do you know you’re doing well?
“The dev team has
a question . . .” QUALITATIVE
QUANTITATIVE
Ask the community.
Call “go to” users or
stakeholders.
Review personas, use
cases, other existing
content.
Collect usage stats.
Do a quick poll.
Analyze data from public sources
(blogs, communities, etc.).
Someone can provide this information in less than a day.
© 2009 Forrester Research, Inc. Reproduction Prohibited
Thank you
Tom Grant+1 650.581.3846
www.forrester.com