webinar - maximizing requirements value throughout the product lifecycle

© 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/)


Developers build software for people unlike them


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


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.”


It’s easy to lose track of the customer

Untestedideas

Customers with

too much influence

Inadequate

information

Infrequent contactswith customers

Your best

customer



OVERBEARINGPERSONALITIES

Compartmentalization

Unwillingness tochallenge assumptions

RESISTANCE TO CHANGE



No time for

retrospection

Design errors

Development diverges from

delivery


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


Accurate


Feedback loops? Really?


Eating your own dog food is not enough

Because you’re not a dog


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


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?”


Timely


The goal: “Just in time” requirements


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)


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


Profound


Are we having the best possible conversations?

One-on-one negotiations between the business faction and the IT faction are hardly optimal


TIME TO

CHANGE

THE

RULES


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.


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


Light-weight


More skills and experiences needed

Actionable

Contextual

Descriptive

ECONOMICS

COMPUTERSCIENCE

ANTHROPOLOGY


“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


Next steps


How do we fix this situation?

Treat requirements discipline as more than a

“nice-to-have”


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


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?


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.


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

[email protected]

www.forrester.com

webinar - maximizing requirements value throughout the product lifecycle

Business

forrester research

reproduction prohibited2012

contextual information

business faction

customer value

business problems13

business users

time requirements16