These are the slides from Carey Schwaber's webcast for the Catalyze Community on June 12, 2008. "It’s no secret that in the battle to bring effective business software to market on time and on budget, business analysts are on the front lines. What can business analysts do to improve requirements definition practices and make a difference in project outcomes? Join us as Forrester Senior Analyst, Carey Schwaber, shares a set of 10 practical tips that you can immediately put into action in your organization."

1. Welcome to the Catalyze Monthly Webcast
Thank you for joining today’s webcast – we will start about 3 minutes or
so past the top of the hour.
Questions - Please send a Chat message to the Host and
Panelists if you have any technical questions before or during the
presentation.
Q&A Session – We will have time at the end of the webcast for
Q&A. Please use the Q&A feature to send any questions to the
Host, and we will answer them at the end of the presentation.
Posting Slides and Recording - We will be posting the slides and
recording from the webcast to Catalyze in the next few days.
www.catalyze.org community@catalyze.org

2. 10 Tips To Improve Project Outcomes
Carey Schwaber
Senior Analyst
Forrester Research
June 12, 2008
For internal use only

3. Theme
Business analysts can make
or break a software project.
Forrester has identified ten tips
to help business analysts
improve project outcomes.
3 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

4. Tip No. 10: Define the business-IT division of labor
• Shared responsibilities are too often abdicated
responsibilities
• Too little or too much business involvement is a common
pitfall
• Careful articulation of roles and responsibilities goes a
long way
“Our customer’s attitude is “The business usually
that requirements are our hands IT a document that
problem.” dictates a solution.”
4 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

5. Sample business and IT requirements responsibilities
Business responsibilities IT responsibilities
Develop business requirements that do not
Understand business goals and business context
presuppose design or implementation details
Prioritize requirements based on relative need Identify and employ appropriate techniques to
and available resources define functional and non-functional requirements
Provide signoffs only after carefully evaluating all Communicate about progress toward fulfillment
materials and ensuring thorough comprehension of requirements
Communicate changing business needs and Manage relationships between requirements and
collaborate with development to determine the other life-cycle artifact to ensure fulfillment of
impact of these changes requirements
5 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

6. April 2008 “The New Business Analyst”
Today’s four types of business analyst (two relatively new)
6 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

7. Tip No. 9: Be part of the team
• Cross-functional delivery teams are the most effective and efficient
– Business customer, business analyst, architect, developer, tester,
project manager
– Cross-functional in the sense of including all roles
– Cross-functional in the sense of blurring lines between roles
• No matter where they report, business analysts must behave as part
of the delivery team
• The alternative is not pretty:
– Spending inordinate amounts of time documenting all of the things the
delivery team might need to know
– Throwing requirements over the wall and hoping that the delivery team
will ask questions as necessary
7 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

8. How functional silos and cross-functional teams can intersect
Delivery team
BA Dev
PM Dev Dev Dev Dev Tester Tester
Lead
Business
Architecture Testing
analysis
8 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

9. Tip No. 8: Assess the true impact of change
• The pressure to improve efficiency of business operations drives
software integration, which results in hairy dependencies
• Unmanaged dependencies derail projects time and time again
• Business analysts need to understand and help communicate the
impact that changes have on:
– The application(s) they are made to
– The applications these applications integrate with
• This helps set business expectations about:
– How long certain changes will take to implement
– Why some changes need to be grouped with other changes
9 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

10. Tip No. 7: Understand future as well as present business needs
• The true outcome of a project extends well beyond the initial
implementation, though this is easy to forget
• How well do the deliverables suit business needs not just today but
also tomorrow?
• “Building for change” is one of today’s most pressing IT imperatives
– How easily can software evolve to meet changing business
requirements?
– How independently, if at all, can the business implement changes in
business processes, rules, etc?
• Business analysts can help by:
– Understanding likely areas of business and application change
– Working with development to devise strategies for accommodating
change
– Assuming responsibility for implementing business changes through new
development paradigms like business process management
10 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

11. September 2007 “The Dynamic Business Applications Imperative”
It’s too hard to change business apps
11 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

12. Tip No. 6: Remember non-functional requirements
• Very few IT organizations adequately define non-functional
requirements
– Performance and security are the most glaringly absent
• Lack of expertise in these areas on the project team is no excuse
• Invite individuals with expertise and vested interest in these domains
to requirements sessions
• Make requirements sessions worth their time
– Prepare them
– Engage them
– Follow up with them
12 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

13. www.iRise.com
Peter Indelicato
Senior Product Manager
peter@irise.com
Visualize Your Business
13

14. www.iRise.com
The Problem with
Business Software
Business people can’t interpret text, use cases,
process flows and static screen shots
Business people don’t know what they want
until they see and interact with it
Coded prototypes are too expensive
Global sourcing brings these risks into sharper
focus
“50% of project timelines are now spent on rework.”
Standish Group Chaos Report, 2007
14

15. www.iRise.com
The Impact
Late stage rework
Cost overruns
Project delays
Global sourcing nightmares
Missing features
Extraneous features
Blown business plans
Finger pointing
“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
15

16. www.iRise.com
The Solution
Visualize before you build
Business analysts, product managers and
UX professionals assemble three
dimensional simulations of business
software
Business and IT stakeholders “test drive”
and provide feedback in rapid, iterative
definition cycles
Dramatically improves communication
between business and IT
“iRise gets business and IT aligned much faster than ever before.”
COO, Global Wealth Organization
16

17. www.iRise.com

18. www.iRise.com
Studio and Reader

19. www.iRise.com
What Can You Simulate With iRise?
New custom development
Enhancements to current systems
Customizations to SAP, Oracle
Mobile applications such as iPhone
Web 2.0 & Rich Internet Applications
19

20. www.iRise.com
Value of Software Visualization
Get to market twice as fast
Virtually eliminate rework
Outsource more new development
Improve customer experience
Discover new innovations
“General Motors has to succeed through innovation.
That’s where iRise leads and that’s the whole philosophy
of the company right now.”
Dr. Richard Frost, Global Director, Information Systems & Services, General Motors
20

21. www.iRise.com
What’s in it for Developers?
Forces the business to articulate what they
want in a language everyone can
understand
Doesn’t let them change their minds in the
middle of a project
Gets business off developer’s backs while
they’re designing, coding, delivering
Virtually eliminates rework
quot;iRise is a rapid, iterative definition solution that helped the bank get the
most out of our Agile development approach. iRise lets us get more done
faster.quot;
Alan Buffington, Executive Vice President, KeyBank
21

22. The iRise Vision
www.iRise.com
By 2020 all business software will be
visualized prior to development, the
same way that visualization is a
common practice in the design of
every car, airplane and
semiconductor today
22

23. iRise Customer Successes
www.iRise.com

24. Tip No. 5: Make requirements painless for the business
• Business engagement in the requirements process is a critical
success factor
• When business customers are frustrated by requirements practices,
they lose faith in the project team and may mentally check out
• But the requirements processes often seem designed to torture
business stakeholders
– One business analyst does dramatic interpretations of 100+ page
requirements documents to keep business customers engaged
– Several businesspeople a telecom report being forced to spend months
on requirements that they know will be obsolete before coding starts
• Business analysts must:
– Stay attuned to business customer satisfaction not just with deliverables
but also with methods
– Take it upon themselves to make the absolute best use possible of
business customers’ time
24 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

25. Tip No. 4: Measure project progress in terms of requirements
• Most companies measure software project progress in terms of
activities
– Requirements complete, design complete, coding complete, etc.
• There is minimal business value in anything other than working
software
• Progressive companies measure software project progress in terms
of fulfilled requirements
– 50% of requirements successfully implemented, from start to finish
• This requires traceability from requirements through to test cases
25 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

26. Burn-down charts measure requirements fulfillment
Stories
26 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

27. Tip No. 3: Don’t rely solely on text
• Text-based requirements are:
– Insufficient, as some things simply can’t be communicated in text
– Inefficient, as they take far longer to consume than visual requirements
– Ineffective, as text often creates a false sense of agreement
• A picture, on the other hand, is worth a thousand words
• Use text-based requirements, but only as a starting point
• Text-based requirements are critical for:
– Non-functional requirements in areas like performance and security
– Labeling units of work
– Compliance purposes
27 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

28. 28 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

29. Tip No. 2: Maximize feedback on requirements
• All defects becomes more expensive to resolve as time passes:
– Architecture, functionality, performance, security, usability
• Defects in requirements have the potential to go unresolved the
longest
• Minimize defects in requirements by maximizing the amount of
feedback you get on requirements
• Maximize feedback by maximizing requirements visibility:
– Posting requirements (in the lunch room, not just on a network drive)
– Inviting Tom, Dick, and Harry to requirements walkthroughs
– Doing frequent demos for projects sponsors and end users
– Delivering working software incrementally
29 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

30. U.S. averages for defect removal efficiency
Defect Removal Delivered
Defect origins
potentials efficiency, % defects
Requirements 1.00 77 0.23
Design 1.25 85 0.19
Coding 1.75 95 0.09
Document 0.60 80 0.12
Bad fixes 0.40 70 0.12
Total 5.00 85 0.75
Source: Capers Jones, Software Assessments, Benchmarks, and Best Practices, Addison-Wesley 2000
30 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

31. Tip No. 1: Invest in future project outcomes, too
• The projects just keep on coming
• Find the time to make changes that improve all project outcomes, not
a single project outcome
• Use this time to investigate, define, and implement changes to
people, processes, and tools
• Set your schedule and budget to allow this, with the expectation that
in doing so you will recoup the time you spend
• In sum:
– Step off the treadmill
– Take time to save time
31 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

32. April 2008 “The New Business Analyst”
Business Analysts Rely Heavily On Informal Training Mechanisms
32 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

33. In summary
10. Define the business-IT division of labor.
9. Be part of the team.
8. Understand and communicate impact.
7. Define future as well as present business needs.
6. Remember non-functional requirements.
5. Make requirements painless for the business.
4. Measure project progress in terms of requirements.
3. Don’t rely solely on text.
2. Maximize feedback on requirements
1. Invest in future project outcomes, too.
33 Entire contents © 2008 Forrester Research, Inc. All rights reserved.

34. Thank you
Carey Schwaber
+1 617.613.6260
cschwaber@forrester.com
www.forrester.com
34 Entire contents © 2008 Forrester Research, Inc. All rights reserved.