Business Analyst Handbook PDF

INFORMATION TECHNOLOGY PRACTICE
APPLICATIONS EXECUTIVE COUNCIL
Business Analysts Handbook

Templates for Key Business Analysis Activities
2012 The Corporate Executive Board Company. All Rights Reserved.
Information Technology Practice
www.executiveboard.com
Applications Executive Council
Content Publishing Solutions
Executive Directors
Shvetank Shah
Warren Thune
Consultants
John Hillery
Andrea Moreland
Production Designers
Todd Burnett
Carolyn Lamond
Managing Directors
Jaime Capella
David Kingston
Senior Analyst
Pallavi Goel
Contributing Designers
Supriya Dhasmana
Mike Jurka
Practice Manager
Mark Tonsetic
Editor
Nidhi Vikram Choudhury
Senior Directors
Miles Gibson
Bill Lee
Alex Stille
Directors
Aron Kuehnemann
Tim Macintyre
Kristin Sherwood
Associate Directors
Christiane Groth
Karolina Laskowska
Alicia Mullery
Candice Kenney Weck
Copies and Copyright
Legal Caveat
As always, members are welcome to an unlimited number of

copies of the materials contained within this handout. Furthermore,
members may copy any graphic herein for their own internal
purpose. The Corporate Executive Board Company requests only
that members retain the copyright mark on all pages produced.
Please contact your Member Support Center at +1-866-913-8101 for
any help we may provide.
The Corporate Executive Board Company has worked to ensure

the accuracy of the information it provides to its members. This
report relies upon data obtained from many sources, however, and
The Corporate Executive Board Company cannot guarantee the
accuracy of the information or its analysis in all cases. Furthermore,
The Corporate Executive Board Company is not engaged in
rendering legal, accounting, or other professional services. Its
reports should not be construed as professional advice on any
particular set of facts or circumstances. Members requiring such
services are advised to consult an appropriate professional.
Neither The Corporate Executive Board Company nor its programs
are responsible for any claims or losses that may arise from a)
any errors or omissions in their reports, whether caused by The
Corporate Executive Board Company or its sources, or b) reliance
upon any recommendation made by The Corporate Executive
Board Company.
The pages herein are the property of The Corporate Executive

Board Company. Beyond the membership, no copyrighted materials
of The Corporate Executive Board Company may be reproduced
without prior approval.
2012 The Corporate Executive Board Company.

All Rights Reserved.AEC2241712SYN
TABLE OF CONTENTS
Overview of the Business Analyst's Handbookiv
Business Analyst Competency Model: Needs Discoveryvi
Business Analyst Competency Model: Technology Managementvii
Business Analyst Competency Model: Relationship Management and Communicationviii
Section 1: Requirements Elicitation1
Section 2: Requirements Management and Analysis15
Section 3: Creating Compelling Business Cases33
Section 4: Providing Accurate Project Effort Estimates47
Section 5: Architecture Management77
Section 6: Designing for Usability93
Section 7: Communications and Change Leadership105
Section 8: Business Relationship Management125
Section 9: Design Team Relationship Management139

iv
OVERVIEW OF THE BUSINESS ANALYSTS HANDBOOK

Five New Imperatives for Business Analysts
As a business analyst, you are uniquely positioned to more broadly see the
changes under way in solutions delivery and corporate IT. You are witnessing
greater externalization of IT services to the cloud. Business partners are taking
more responsibility for technology solutions themselves. There is increasing
pressure for efficiency in delivery.
4. Manage new solutions in the broader architectural context.

The environment is growing increasingly complex with more externalized
solutions delivery. Improve your ability to identify interdependent processes,
and manage change of your projects that reduce the need for costly latestage integration.
What does this mean for you? Weve distilled five new imperatives for the
business analyst role:
5. Enhance your vendor management competencies.

Organizations are growing their reliance on vendors for many kinds of
solutions, especially mobile solutions. Your effectiveness with vendors will
depend on your ability to drive the conversation on business need, not
technical specification.
1. Reshape your engagement approach to reflect business leaders

preferences for risk, benefit, and involvement.
Many business leaders now prefer to lead more in phases of IT projects.
Understand your business sponsors attitudes, and tailor your engagement
techniques appropriately.
2. Shift from requirements gathering to needs discovery and strategic
consultation.
Information-intensive projects are increasing in demand. On these projects
its often difficult to articulate needs, and in many cases needs may simply
be unknown. You must help to uncover needs by using investigative skills.
You need to actively question business sponsors on their articulation
ofstrategic objectives to create stronger business outcomes from projects.
3. Build your usability skills and advocate for the end user.
Usability is increasingly important, particularly for analytics, collaboration,
and mobile projects. Use insights drawn from end-user observation to
actively advocate for users needs in dialogue with the sponsors overarching
goals.

IT PRACTICE
www.aec.executiveboard.com
OVERVIEW OF THE BUSINESS ANALYSTS HANDBOOK (CONTINUED)

How to Use This Handbook
This handbook is organized into nine sections that correspond to the nine areas of the Councils Business Analyst (BA) Competency
Model. Each section provides an overview of the available resources and templates, and guidance on when to apply each. We have also
included guidance on each resources applicability to the scope of a BAs responsibilities.
Hallmarks Shared Business: Applications Requirements Elicitation4

By including business stakeholders from the earliest stages of requirements
planning, Hallmark facilitates a shared sense of ownership and maximizes
the likelihood that requirements will meet customer needs. The requirements
elicitation process is broken into five distinct phases. Each phase defines a clear
delineation between tasks for the business team versus the IT team.
When to Use
To establish ownership and shared responsibility with business partners
Essential
Each of the nine

sections contains
an overview on
the templates
available.
The Handbook
provides guidance
on when to apply
the template or
resource.
Reference
Specialized
Each resource
includes an indicator
of its degree of
applicability to the
BA role.
Essential: Template or resource is applicable to core BA activities (e.g., requirements elicitation).

Reference: Template or resource may be outside BAs direct scope of responsibility but where a BA
is often an important contributor (e.g., portfolio requirements management).
Specialized: Template or resource is outside BAs normal scope of responsibility but directly
applicable in specialized role (e.g., services).
Project Methodology: Recognizing that the BAs role in agile projects often varies, we have included agile-related resources within
each of the nine sections, but each resource is labeled as applicable specifically to agile requirements or agile projects. Resources not
labeled as agile are applicable to a waterfall approach or not dependent on choice of delivery methodology.
IT PRACTICE
BUSINESS ANALYST Competency Model: Needs Discovery

Section 1: Requirements ElicitationAbility to identify a desired future state that addresses a business problem
Level 1: Foundational
Level 2: Practitioner
Level 3: Leader
Precisely and consistently captures business problems and

nonfunctional requirements
Can identify and document emerging business

requirements
Drives consensus for a desired future state that meets the

business problem and enterprise objectives
Prioritizes problems to surface the most critical needs
Can intelligently question business partner and knowledge

worker preferences to identify unique value drivers
Can uncover needs that business partners and end users

would not be able to articulate on their own
Section 2: Requirements Management and AnalysisAbility to manage requirements to the smallest set that will provide the biggest impact in advancing business objectives
Level 3: Leader
Properly prioritizes competing business demands
Properly prioritizes business line and enterprise demands
Understands business process complexity
Can elicit high-level business requirements
Assesses the risks of various solution options to different

options
Accurately translates business requirements into

functionality
Influences business partner requirements in support

ofenterprise objectives
Manages requirements to meet performance expectations
Section 3: Creating Compelling Business CasesAbility to measure and communicate proposed project benefits
Can articulate the business impact of business problems
Understands the organizations economic and revenue

drivers
Understands industry-specific trends that impact the

organization
Clearly articulates benefits in business language
Accurately measures the contribution of IT projects

tobusiness value
Level 3: Leader
Quickly adapts to changes in business strategy
Helps business partners communicate solution value to key

stakeholders
Section 4: Providing Accurate Project Effort EstimatesAbility to quantify project resource requirements
Effectively coordinates project delivery with the project

management office or equivalent

IT PRACTICE
Can manage ambiguity and create accurate project effort

estimates
Accurately quantifies project-specific risks through the
development lifecycle
Level 3: Leader
Recognizes the implications of business strategy changes
Effectively engages project stakeholders in the estimation

process
vi
BUSINESS ANALYST Competency Model: Technology Management

Section 5: Architecture ManagementAbility to create solutions that advance architectural objectives
Understands technology standards and architecture

guidelines
Obtains key input from enterprise architecture groups
to ensure architecture compliance and exception
management
Level 3: Leader
Identifies solution interdependencies
Stays abreast and creates awareness of technology

developments related to a business problem
Can identify commonalities and suggests a consistent

approach across projects in the absence of standards
Can guide solutions options and business partner decision

making to minimize the amount of project investment
divergence from target architecture
Can identify opportunities for creating reusable enterprise

services
Can guide and manages interactions with technology

vendors
Section 6: Designing for UsabilityAbility to design solutions for end-user adoption and productivity improvement
Level 3: Leader
Incorporates usability and user interface techniques when

designing systems
Can engage with knowledge workers in their normal dayto-day environment
Can identify the requirements to ensure end-to-end service

performance from the end users perspective
Understands knowledge workers information needs as

they relate to a potential solution
Can effectively convey knowledge workers preferences to

business partners and design teams
Can gain business sponsor commitment for additional

resources required to ensure usability

IT PRACTICE
vii
BUSINESS ANALYST Competency Model: Relationship Management

and Communication
Section 7: Communications and Change LeadershipAbility to communicate effectively across multiple constituencies to support project and organizational change objectives
Presents ideas in a concise, focused manner
Can guide team decision making
Can work as part of a larger team
Provides business partners with an accurate view

of challenges to end-user buy-in
Surfaces potential impacts of the solution on all

stakeholders
Level 3: Leader
Effectively engages key knowledge workers and business

sponsors in change management activities
Section 8: Business Relationship ManagementAbility to engage business sponsors and contribute to their targeted business outcomes
Level 3: Leader
Sets realistic customer expectations for project delivery

(e.g, schedule, budget, outcome)
Adjusts customer expectations in accordance with

changes in scope
Can influence business partner decision making to

optimize requirements prioritization
Clearly articulates the role of technology in terms easily

understood by business constituencies
Can effectively navigate conflict between multiple business

partners
Builds long-term relationships between multiple business

partners to drive engagement in IT strategy
Proactively resolves customer satisfaction issues
Tailors business partner engagement to business sponsor

risk and value preferences
Section 9: Design Team Relationship ManagementAbility to engage developers to ensure productivity and solution quality
Can listen to and understand technological constraints
Clarifies the business rationale of a solution concept

IT PRACTICE
Creates a vision of project success that drives team

engagement
Shares best practices and process and environmental
knowledge
Level 3: Leader
Educates developers on a projects business context
Effectively collaborates with geographically distributed

teams
viii
Section 1: Requirements
Elicitation

IT Practice
Requirements
Elicitation
Requirements
Elicitation
REQUIREMENTS ELICITATION
Capture High-Level Requirements
Partner with business sponsors to effectively identify a desired future state
that addresses a business problem.
Hallmarks Shared Business: Applications Requirements Elicitation4
By including business stakeholders from the earliest stages of requirements
planning, Hallmark facilitates a shared sense of ownership and maximizes
the likelihood that requirements will meet customer needs. The requirements
elicitation process is broken into five distinct phases. Each phase defines a
clear delineation between tasks for the business team versus the IT team.
When to Use
To establish ownership and shared responsibility with business partners
for each stage of requirements elicitation
To validate high-level functional requirements for new systems
development/legacy systems
Essential
Reference
Specialized
Sabre Holdings Agnostic Needs Statement7

Sabre Holding assesses what should and should not be in a mobile application
by crafting use cases that capture needs, not just mobile-specific requirements.
To isolate the right needs and translate them into features, BAs should use a
questionnaire that challenges business sponsors and users to articulate why
their needs cannot be achieved without a mobile application.
When to Use
To uncover business sponsor and user needs for mobile
To craft use cases for mobile apps requirements
To validate whether a mobile application is the right solution
Essential

IT Practice
Reference
Specialized
IBMs User-Initiated Requirements Specification8

To improve the requirements elicitation process, IBM boosts the usability
of user-provided information by supplying business users a standardized
elicitation template focused on the key attributes of the end product.
When to Use
To capture functional and nonfunctional requirements
To identify the most stable requirement
Essential
Reference
Specialized
Evaluate Requirements
Continually verify requirements individually and collectively against a
standard set of well-known criteria throughout the project lifecycle.
Capital Ones Creating High-Quality Requirements10
Capital One rigorously validates every functional requirement against a
checklist of eight necessary attributes that each must meet. To prevent scope
creep, all approved requirements must be associated with a documented
business need. After making sure that each individual requirement is of high
quality, the entire set of requirements is assessed as a whole against an
additional set of three attributes. These attributes relate to the thoroughness
of the set, the interrelationships between requirements, and the ease with
which the requirements set can be changed.
When to Use
To prevent scope creep of requirements
To define attributes of high-quality requirements
Essential
Reference
Specialized
REQUIREMENTS ELICITATION (continued)

Elicit Unarticulated Needs
Engage in direct observation of knowledge workers to uncover unarticulated
needs and transformational innovation opportunities.
LexisNexiss Uncovering Unarticulated Needs13
LexisNexis focuses on uncovering unarticulated needs directly from knowledge
workers. BAs engage directly with employees to understand pain points or
roadblocks in employees workflow.
When to Use
To assess employees unrecognized needs or identify barriers
in their workflow
Essential
Reference
Specialized

IT Practice
Requirements
Elicitation
Requirements
Elicitation
Capture High-Level Requirements

Hallmarks Shared Business: Applications Requirements Elicitation
Requirements Elicitation Process
Feasibility
Goal
Business-Side
Tasks
Formulate the business

problem and identify all
stakeholders, including
end users.
ApplicationsSide Tasks
Map user base across

organizations.
Determine operational
and problem context
such as mission
scenarios.
Identify similar systems
in the organization.
Identify application
domain and
development experts.
Identify domain and
architectural models.
Assess cost constraints
imposed by the
sponsor.

IT Practice
Solicitation
Analysis
Prioritization
Gather and classify

feature requests from
business partners through
joint-requirements
planning.
Perform an impact
analysis and risk
assessment to address
technical, schedule, and
cost concerns.
Prioritize all requirements

based on business
criticality of the features.
Obtain a wish list from

each party in the user
base.
Perform abstractions
to answer questions of
the form, Why do you
needX?
Determine criticality
of features.
Validation
Integrate requirements
and validate scope
in collaboration with
business partners.
Classify wish
lists according to
constraints (functional,
nonfunctional,
environmental,
design, etc.).
Determine interface
needs for information
that is shared between
business areas.
Estimate the impact of

requirements on cost
and schedule.
Perform risk assessment.
Examine cost of
potential solutions in
light of architectural
andstrategic fit.
Prioritize requirements
based on cost and
dependency.
Identify appropriate
architectural models
that work with current
technology roadmap.
Resolve as many open

issues as possible.
Verify that requirements
are in agreement with
originally stated goals.
Obtain authorization
to move to Application
Design.
Resolve conflicts
and keep consistency
in check.
Capture High-Level Requirements (CONTINUED)

Hallmarks Shared Business: Applications Requirements Elicitation (Continued)
High-Level Requirements Questionnaire for New Development
1. Determine Business Objectives
4. Determine Current Problems
1. What are your goals in developing this system?

2. Who are the key stakeholders and users? Do their goals differ? If so, how?
3. How do the system goals map to business goals?
4. What is the most important business goal of the system?
5. Will the system change the way you are doing things now?
6. Will the system help you be more efficient? How?
7. What are the system deliverables?
8. What will the new system accomplish that is not accomplished manually
orwith other systems?
9. What will the new system do?
1. What are the problems you face without the system today?
2. What problems should this system solve?
3. Do you have to do things manually that you would like to automate?
4. Do you have performance problems that need to change?
5. Do you have functional limitations that you would like to change?
6. Are you using packages that force you to constrain your business functionality
to the boundaries of the package?
7. Which reports do you currently use? What data on the report are important?
How do you use the information?
8. Are there specific bottlenecks to getting at information?
9. How do you analyze the information you currently receive? What type of data
are used? How do you currently get the data? How often do you get new data?
10. What type of ad hoc analysis do you typically perform? Who requests ad hoc
information? What do you do with the information?
2. Determine Future Needs

1. What business requirements will this system address?
2. What information do you need from this system that you dont have now?
3. Is any of this data currently captured in any other corporate system?
4. How would you like to see this information?
5. What functionality do you need from the system?
6. Are the data and/or functionality shared by other (many) business areas?
If so, which?
7. If the reports were dynamic, what would they do differently?
8. How much historical information is required?
5. Determine Criteria for Success

1. What is most important for success of the application?
2. What do we need to accomplish to make this project successful?
3. What do we need to change to make this project successful?
4. What buy-in do we need?
5. Are we lacking any critical elements such as budget, resource allocation,
or support?
6. What are training considerations for developers and users?
3. Determine System Users

1. Who will be using the system?
2. What are the titles and roles of the people who will use the system?
3. What are their levels of expertise?
6. Determine Assumptions and Open Issues

1. List assumptions.
2. List open issues, responsible parties, and resolution date.

IT Practice
Requirements
Elicitation
Requirements
Elicitation

Hallmarks Shared Business: Applications Requirements Elicitation (Continued)
High-Level Requirements Questionnaire for Legacy Systems Development
1. Determine Business Objectives
2. Determine Future Needs
1. Why do you want to redo the system?

2. How will the new version of the system help you?
3. What are your objectives in having this system?
4. Who are the key stakeholders and users? Do their goals differ? If
so, how?
5. How does the system map to business goals?
6. What is the most important business goal of the system?
7. Will the system change the way you are doing things now?
8. Will the system help you be more efficient? How?
9. What are the system deliverables?
10. What will the converted system accomplish that the current
system cannot?
11. Will the output of the converted system be the same or different
than the current system?
12. Will the new system have an additional functionality? What?
13. Will the new system have better performance? To what extent?
14. Will the new system help you be more efficient? To what extent?
15. Will the screens look different? How?
16. What is most important (rank in order of importance)?
Application is easier to use.
Application has nicer front end.
Application has additional functionality (list).
Application is more efficient.
Application is redesigned to better reflect the business.
Same as for new system development
Many of the questions that apply to new

systems development also pertain to
projects involving legacy systems.

IT Practice
3. Determine System Users

Same as for new system development, plus:
1. What is the risk of not converting the system?
5. Determine Criteria for Success
6. Determine Assumptions and Open Issues
1. Who are the most important players in terms of knowledge?
Politics?
2. Is there any existing system documentation? If so, where?
3. Who else should we talk to?
For projects that impact legacy systems,

Hallmark also considers important
questions relating to organizational
behavior and people issues.
Capture High-Level Requirements (continued)

Sabre Holdings Agnostic Needs Statement
Questionnaire for Business and End Users: Mobile Requirements
Business Sponsor Questionnaire
Use Case 3: End User
1. What are you trying to do?

We want to offer a solution to travelers that helps
them manage their travel throughout the trip.
1. Who are you as a potential user? What is your role?

A road trip traveler
2. Why cant you achieve this business objective

without mobile?
While travelers are in-trip, it is often difficult
tocommunicate with them.
3. What is the pain point?
Travelers typically think of trip management
applications during delays or when they are
looking for flight status. We want to expand our
engagement by making life easier for in-trip
travelers.
4. To what degree are you changing an existing
business process?
The travel lifecycle has always had a gap in the
in-trip phase. To move a product or service
into this phase requires a change as well as new
approaches and data.

A business traveler
A leisure traveler
2. What do you need to accomplish?
While in the middle of my trip, I need to know my
hotels amenities and what other events/activities
may be available.
3. Why do you need to do that?
I usually find these items in advance of the trip,
but if I fail to do that, I have difficulty finding the
information.
4. Why cant you accomplish this without mobile
devices? How have you tried to resolve this
need in the past?
While in-trip, access to a PC can be extremely
difficult. Calling for information has proven hit or
miss.

IT Practice
Requirements
Elicitation
Requirements
Elicitation

IBMs User-Initiated Requirements Specification
Business Requirements Elicitation Worksheet
Key Question: What business

problem are you solving with each
requirement?
Requirement
Type
Example: I need to have updates

to customer data available in all
regional offices.
Functional
Requirements
Unique ID
Requirement
Statement
Description
Success
Conditions
Example: The system must be able

to process orders, but it may not
have to provide daily reports.
Stability
Level
BFR1
High (H)Unlikely to change
BFR2
Medium (M)May change based

on business conditions or other
business initiatives
BFR3
Low (L)Likely to change based

on business conditions or other
business initiatives
BFRn
BNFR1
Key Question: What would render

a feature or functionality useless
to you?
Nonfunctional
Requirements
Example: The data would be

useless to me if I cant get it in
fewer than 15 seconds.
BNFR2
BNFR3
BNFRn
Applications Team Filters to Improve Requirements Quality

Applications uses four standard IEEE criteria to improve accuracy
of requirements capture:
A. Unambiguous: The requirement statement has only one possible
interpretation.
B. No Design Impact: The requirement statement does not include
how the requirement should be implemented.
C. Necessary: The requirement statement addresses a business
objective or need.
D. Correct: The requirement statement accurately describes the
functionality to be delivered.

IT Practice
Key Question: How likely is it that

this requirement will not change?
Key Question: How can you tell it

is working correctly?
Example: An e-mail reporting sales
updates is sent to the VP of supply
chain every day at 8:00 a.m.

IBMs User-Initiated Requirements Specification (Continued)
Business Requirements Specification, Illustrative
Business Requirements Specification

I. Business Scope and Objectives
Key questions to ask when reviewing business requirements:

1. What am I solving with this business requirement?
2. Is this business requirement feasible?
3. What scope and/or objectives is this business requirement addressing?
4. What is the acceptance criterion for this business requirement?
5. How do I measure the acceptance criteria?
This section defines the starting reference for a project. This section should help with
the following:
Provide a high-level understanding of what the enterprise is and aspires to
become. It is usually depicted by a brief description on how the organization
intends to achieve its goals and make the desired transition and by what means.
Document events that are the initial stimuli causing the clients business to act.
Describe and quantify the benefits, costs, schedules, and assumptions required
to justify the implementation (if needed).
Success criteria/acceptance criteria ensure agreed-to business requirements

(functional and nonfunctional) are clear and unambiguous. They are also the metrics
that measure success of the project. The objective of this section is to identify and
document success criteria and associated metrics for each business functional and
nonfunctional requirement.
II. As Is Business Process Flows
a. Business Functional Requirements
This section should help with the following:

Contain the graphic representation of the flow of work through a business
process model, narratives that describe the flow, and key process attributes.
Describe a high-level business use case model; this use case model uses
graphical symbols and text (business lexicon) to specify how users in specific
roles will use the system.
Depict the usage and interaction between resources (e.g., hardware, software,
and people).
III. Business Requirements
Business requirements differ from systems requirements. Business requirements can
be identified by the following characteristics:
They support a business scope and/or objective, usually reviewed by executives.
They have a business purpose/focus.
They state what needs to be accomplished using business language.
They are nontechnical.
Business
Functional
Requirement Id
Requirement
Stability Level
(H)High
(M)Medium
(L)Low
Success Criteria
and Associated
Metrics
BFR1
BFR2
b. Business Nonfunctional Requirements
Business
Functional
Requirement Id
Requirement
Stability Level
(H)High
(M)Medium
(L)Low
Success Criteria
and Associated
Metrics
BFR1
BFR2
IV. Assumptions, Issues, and Constraints

IT Practice
Requirements
Elicitation
Requirements
Elicitation
10
Evaluate Requirements
Capital Ones Creating High-Quality Requirements
Individual Requirements Evaluation Criteria
The following attributes should be applied to each requirement

Term
Definition
Guidelines
1. Unambiguous
The requirement has only

one possible interpretation.
Avoid natural language, such as user-friendly, easy, simple,

rapid, efficient, several, state-of-the-art, improved, maximize,
and minimize.
Use a requirements document glossary to capture the
meaning of important terms.
Uncover ambiguity by formally inspecting the requirement,
writing test cases from requirements, and creating user
scenarios that show the probable behavior of a specific piece
of the product.
2. Correct
The requirement accurately

describes the functionality
to be delivered.
Use the source of the requirement as your reference

of correctness, such as the actual business or system
requirements specifications. If the system requirement
conflicts with the corresponding Business requirement,
one of them is incorrect.
Example
For up to eight results, the detailed display format shall be
used. For the remainder, the compressed display format shall
be used.
Ambiguity lies in the phrase for up to eight results. Does
it mean for up to and including eight or for up to and
excluding eight?
A business requirement that states the search function shall

display a maximum of 10 results per page could incorrectly
be recorded in the systems requirements as the search
engine must fetch a maximum of 10 matching records from
the database.
Include the affected areas subject matter expert (SME) when

determining the correctness of requirements.
3. Testable
4. Achievable
The requirement can

be verified through an
inspection or demonstration
to determine whether it can
be implemented properly
in the product.
State each requirement so it can be verified within the

scope of the project using tests or other verification
approaches. If a requirement is not verifiable, questioning its
implementation will be a matter of opinion.
The requirement must be

practical from the standpoint
of compatibility issues
with existing systems and
environments and constraints
of time and budget.
The requirement analyst and the business customer should

work through the elicitation process to agree on what can
and cannot be done technically and what can be done only
at excessive cost or with other trade-offs.

IT Practice
Requirements that are inconsistent, infeasible, or ambiguous

are not verifiable. A requirement that merely states that the
product shall support certain functionality is not verifiable.
The program shall not enter an infinite loop is a nonverifiable and hence not testable requirement.
Evaluate Requirements (CONTINUED)

Capital Ones Creating High-Quality Requirements (Continued)
Individual Requirements Evaluation Criteria (Continued)
Term
Definition
Guidelines
Example
5. No Design
Impact
The requirement states what

is required but not how the
requirement should be met.
Check each requirement to ensure that it does not reflect a

design or implementation decision or describe an operation.
Such requirements are design-dependent.
DO: Design independent requirements.

The system shall enable all employees to update their
time sheets.
Nonfunctional requirements such as system constraints are

an exception.
DONT: Design dependent requirements.

The system shall be composed of three modules, each
reading from and writing to a Microsoft Access database.
The treatment of interface requirements is usually an
exception: The system interface shall adhere to the standard
corporate design.
6. Traceable
The requirement must be

traceable to and from its
source.
Link each requirement to its source. It could be a high-level

system requirement, use case, or a documented stakeholder
requirement.
Link each software requirement to the architecture elements,
design elements, and test cases that are constructed to
implement and verify the requirement.
7. Necessary
The requirement should

document a business need
and should be implemented
by design.
A necessary requirement is one that has been validated by an

owner recognized to have change control authority (such as
the requirements manager). It can be clearly identified with
abusiness case.
8. Documented
A requirement must be
documented for it to be
considered valid.
Verbal, undocumented requirements cannot be adequately

traced, tested, analyzed, or shared across the project team.
Hence, requirements must be documented to meet all the
conditions stated above.
The form of documentation should facilitate electronic
storage and transmission and should be published by the
project manager as early as possible in the project lifecycle.

IT Practice
Requirements
Elicitation
11
Requirements
Elicitation
12
Evaluate Requirements (CONTINUED)

Capital Ones Creating High-Quality Requirements (Continued)
Collective Requirements Evaluation Criteria
The following attributes should be applied to all requirements collectively.

Term
Definition
Guidelines
Example
I. Complete
Requirements must account

for all business needs related
to the project.
Organize the requirements hierarchically to help reviewers

understand the pieces that make up the requirement. It will
then be easier for the reviewers to tell if something is missing.
The use case method works well for this purpose.

Graphical analysis models that show different views of the
requirements can also uncover incompleteness.
Focus on user tasks rather than on system functions during

requirement elicitation. This reduces the likelihood of
overlooking necessary requirements or including
unnecessary ones.
Any appearance of To Be Determined (TBD) in the

requirements document makes it incomplete. Use TBDs
as a standard flag to highlight gaps when it is known that
certain information is missing. Resolve all TBDs before you
develop the part of the product tied to the TBD requirement;
otherwise, it must be documented by the project manager in
the PMM Risk Management Plan.
Consistent requirements agree with other software

requirements or with higher-level system and business
requirements. Research and resolve disagreements among
requirements before development can proceed so it is
understood which of the requirements is correct.
The following requirements are not consistent with each

other:
II. Consistent
No two requirements must

be in conflict with each other.
Review all the related requirements before you modify one.

Inconsistencies can slip in undetected if only the specific
change is reviewed.
III. Modifiable
Requirements specifications
must be open to revision and
durable to change.
The search function shall return results in the order of their

relevance to the searched term.
The search function shall display the most recently created
documents first.
Uniquely label each requirement and express it separately

from other requirements so each can be referred to
unambiguously.
The user should lift the handset; the system shall respond
with dial tone; the user should then dial the seven-digit
phone number of the party the user is trying to reach.
Organize all requirements such that related requirements are

grouped together.
The user should lift the handset; the system shall respond
with dial tone; the user should then dial a 1 followed by the
10-digit phone number of the party the user is trying to
reach.
Create a table of contents, an index, and a cross-reference

listing.
The redundant steps in these two requirements increase

readability but decrease the modifiability. A single change
of step may impact multiple requirements due to the
redundancy of steps.

IT Practice
Elicit Unarticulated Needs

LexisNexiss Uncovering Unarticulated Needs
The Customer Advocate Profile
1. Experience
Recent experience with the workflow performed by the knowledge worker

Was recently employed in the role or participated in the business process
performed by the role
2. Scientific Disposition
Intellectual curiosityExhibits a passion for learning
Observational skillsCan identify patterns in large data and information sets
Problem solvingIs driven to understand the core of an issue
3. Journalistic Aptitude
Interviewing skillsIs able to facilitate and guide discussions with others
Interpersonal skillsThrives in interactions with others
Recognized as a Challenger of the status quoIs able to intelligently question

knowledge worker preferences to identify unique value drivers associated with
the objectives of the role, in a nonaggressive yet an assertive, authoritative way
Customer Advocate Objectives
Engage with knowledge workers in their normal day-today environment.

Uncover and document existing pain points and needs
thatknowledge workers would not be able to articulate
ontheir own.
Good but Insufficient Indicators of Success

for a Customer Advocate
Experience in identifying and evaluating newtechnologies
Experience in gathering and defining business requirements
Survey and data analysis skills
User-experience skills

IT Practice
Requirements
Elicitation
13
Requirements
Elicitation
14
Elicit Unarticulated Needs (CONTINUED)

LexisNexiss Uncovering Unarticulated Needs (Continued)
Interview Guide
Objectives
1. Collect background information on the knowledge worker.
2. Understand a day in the life of the knowledge worker.
3. Observe the knowledge worker in his or her natural work environment.
I. Background
II. Day in the Life
1. Job Position/Title
Describe a typical day for you. Walk me through what time your day normally starts,
typical activities, etc.
2. Business Unit
Name of business unit
Size of business unit
Structure of business unit
How are you personally evaluated?
Who supports you?
3. Tell me about your career/educational background and how you got to where
you are today.
Undergraduate
Graduate school/MBA
Career progression
4. What is your key area of expertise? What would you like to be your key area
ofexpertise?
5. What does your network of peers look like?
6. What extracurricular activities (both job-related and personal) have you
participated in?
7. What is your level of comfort with technology?
8. How do you keep up with new developments in your field?
9. How do you learn about new products or services to help you with your job?
1. What are your hours?

2. Who are the people you typically interact with and how do you interact with them?
3. What do you spend the most time on?
4. What would you like to be spending the most time on?
5. What is a good use of your time and what is not?
6. What would you assign to someone else if you could?
7. Where do you workin the office, at a client site, at home?
8. In your everyday work, what tools/resources do you rely on to make your work
easier?
What tools serve you well and you could not live without?
What tools are less successful?
Can you tell me about a work task that was made a lot easier using a tool that
you purchased?
How did that tool/resource make the job easier?
How do you customize/modify the tools that you use to help you in your work?
(Or can you usually use them off the shelf?)
Is there a product you wish you had that is not available?
9. What resources are available to you, free and paid for?
10. How is success typically measured in your job? How do you tie that success back
to the work you did?
10. What resources do you wish you could have?
11. What is the most important thing you can do well in your job in the eyes ofyour
company/boss/industry?
11. How do you see your job changing in the next five years? What tools/resources will
become more important?
12. When you look back at this job 5 or 10 years from now, how will you decide if you
were successful at it?
IT Practice
Section 2: Requirements
Management and Analysis

IT Practice
Requirements
Management
and Analysis
15
Requirements
Management
and Analysis
16
REQUIREMENTS MANAGEMENT AND ANALYSIS

Prioritize and Track Requirements
Accurately screen and compare requirements based on how well they satisfy
business objectives.
Sabre Holdings Feature Needs-Testing for Mobile Apps18
Sabre Holdings applies a rigorous screening to strip out features that fail
tosatisfy either the business or end-user needs.
When to Use
To screen mobile requirements for fit with business needs
Essential
Reference
Specialized
Discovers Sample Requirements Tracking Document19

Discovers requirements tracking document helps ensure that requirement changes
are reflected in design and test cases and validated by users.
When to Use
To gather requirements iteratively
To identify requirements from business partners, users, and software
requirements
To validate requirements during project review discussions
Essential
Reference
Specialized
Paccars Business ObjectivesDriven Functionality Prioritization20

Paccar uses a numeric scorecard that calculates importance of business
objectives and how each functional capability satisfies a business objective.
The impact score for each functional capability is based on its cumulative
impact on the set of business objectives. Historical data, time and motion
studies, and modeling are used to arrive at this quantification.
1
Pseudonym.

IT Practice
When to Use
To connect business benefits and application functionality
To quantify functional capabilities
To find the best-fit implementation for application functionality
Essential
Reference
Specialized
BCBS-MAs Pairwise Feature Prioritization21

For functionally complex projects, BCBS-MA makes pairwise comparisons
among features to enable the business sponsor effectively prioritize requests
for functionality.
When to Use
To compare and rank order business preferences
To compare and prioritize features
Essential
Reference
Specialized
Fenton, Inc.s1 Functionality ROI Maximization22

Fenton, Inc. quantifies each features impact on a projects business value
components that enables benefit-driven trade-offs.
When to Use
To quantify the value of application functionality
To prioritize features and requirements based on business benefit
Essential
Reference
Specialized
REQUIREMENTS MANAGEMENT AND ANALYSIS (continued)

Manage Requirements Across Business Process Change
Improve Portfolio-Level Requirements Visibility
Customize requirements management methodologies based on projects

architectural impact and end users/customers involved.
Group projects together based on their shared impact on business

processes, and then gather the requirements holistically.
Swiss Res Methodology Decision Map23

Swiss Re aligns the level of effort for requirements management on any given
project with the level of business process change targeted by the project.
CIGNAs Portfolio-Level Requirements Management27

CIGNA takes a holistic view of requirements capture by bundling projects
based on project priority, business process impact, and business process
synergy. A centralized requirements group maps current business processes,
identifies requirements redundancies and gaps across projects, and makes
the appropriate adjustments to enable business process transformation to the
desired future state.
When to Use
To match requirements management effort to business need
To tailor requirements management methodology
Essential
Reference
Specialized
When to Use
To capture portfolio view of requirements
To bundle projects based on shared impact of business processes
To map current business processes, identify requirement redundancies,
andgaps across projects
Drake Corporations1 Voice of the Customer Tool26

Drake Corporation uses a Voice of the Customer planning worksheet to
understand user acceptance issues early and adapt requirements management
accordingly.
When to Use
To assess key stakeholder attitudes
To plan engagement with stakeholders
Essential
Reference
Essential
Reference
Specialized
Specialized
Pseudonym.

IT Practice
Requirements
Management
and Analysis
17
Requirements
Management
and Analysis
18
Prioritize and Track Requirements

Sabre Holdings Feature Needs-Testing for Mobile Apps
Illustrative, Corporate Booking Apps
Candidate Features
Obtains Travel Agency
Contact Information
Updates Traveler Profile Information
Litmus Test
Can we clearly articulate how this feature
meets a business need?
Shops and Books for Corporate

Approved Hotel Rooms
Displays Corporate-Specific Messaging
Holds a Trip for Future Booking
Needs Test 1:
Business Need
Discard Features
Litmus Test
Can we clearly articulate how this feature
meets a high value user need?
Needs Test 2:
End-User
Workflow Need
Discard Features
Usability Criteria
Could use of this feature be severely
impacted by any of the following?
Noise/distractions
Poor lighting
Time pressure
Slow link control protocol connectivity
Complex visuals
Specific mobile device
(e.g., phone versus tablet)
IT Practice
Updates Traveler
Profile Information
Displays Corporate-Specific
Messaging
Obtains Travel Agency
Contact Information
Usability
Criteria
Discard Features
Shops and Books for

Corporate Approved
Hotel Rooms
Holds a Trip for

Future Booking
Prioritize and Track Requirements (CONTINUED)

Discovers Sample Requirements Tracking Document
1
Document
requirements captured
prior to the war room.
UAT ensures that business partners have

validated the changes that were made
throughout the project and facilitates the
speedy formal sign-off at the end of the project.
Requirements Tracking Document

Project Name: Excelsior
Business Sponsor: Jim C
War Room Dates: ---------------
Project Manager: John G
Req. ID
Description
Requirement
Adjustment
Notes
Design
Test
Document Case ID
Changes
Implemented
RS0001
Users should be able to

select the item from the list
of products.
Select multiple
items from the
list.
DD0001
Design
TC0001
UAT
Done
Development
Test Cases
RS0002
RS0003
Make list of all products

available for the user to
select in alphabetical order.
Also group the

products by
their market.
DD0005
TC0003
Design
TC0004
Development
TC0005
Test Cases
--------------------------------
-----------------
-----------
---------
-----------------
RS0004 --------------------------------
-----------------
-----------
---------
-----------------
Use notes column to write down any changes

to requirements during the war room. Dont
waste time formally updating the requirements
document.
Traceability ensures
that changes are
implemented in all
affected areas.

IT Practice
Requirements
Management
and Analysis
19
Requirements
Management
and Analysis
20

Paccars Business ObjectivesDriven Functionality Prioritization
Prioritizing the Impact of Applications Functionality on Fulfilling Business Objectives, Illustrative
High-level requirements
are framed in terms of
business or process
improvement objectives.
Impact assessments and

business process knowledge
result in quantified business
benefits (e.g., 4% decrease in
order-to-ship cycle time).
Strong Impact = 9 Points

Medium Impact = 3 Points
Low Impact = 1 Point
Business Objectives
Reduce Costs
Business Priority Rank:

Low (L), Medium (M),
High (H)
Business Priority Rank
Functional
Capabilities
Increase Revenue
Increase
Engineering
Operations
Efficiency
Improve
Materials Cost
Increase
Engineering
Design Efficiency
Increase
Average
Price
Increase
Customer
Utilization
Decrease
Order-to-Ship
Cycle Time
Impact
Score
Change Order
Event Notification
6.6
Automate Material
Requirements Ordering
4.9
Add Search Capability
5.2
Functional capabilities that

potentially satisfy the high-level
business objectives can run into
as many as 100 for large projects.

IT Practice
Assessment
of impact of
functionality on the
business objective
Impact scores are calculated based on the Business Priority

Rank and the impact of the functionality on each of the
business objectives; top third stay, bottom third are discarded,
and middle third are taken up for further consideration.

BCBS-MAs Pairwise Feature Prioritization
Pairwise Comparison of Features
A. Change Address
1
A
Participants are asked to pick the

feature they consider more important
feature A (Change Address) or feature
B (Change Name); ties are not allowed.
B
A
A
B. Change Name
2
B
Similarly, pairwise comparisons are

made between each pair of features;
the preferred one in each pair is circled.
C
B
D
D
A
A
D
D
B
B
Functionality Ranking
No. of Times
Circled
Business Staff
4 D. Change Status
D
D
D
Feature
C. Reinstate
E
E
E. Transfer
A count of the number of times each feature

is circled across the rows and columns of
the entire matrix is used to rank the features.
Complexity Ranking
Applications Staff
Prioritized Feature List

Project
Sponsor
Business Project
Manager
Which feature is more important to you:
Change Address or Change Name?
Change Name or Reinstate?
Rank Value-Based
Prioritization
Business
Liaison
Cost-Based
Prioritization
Which feature is more

complex to create:
D Change Status
E Transfer
A Change Address
C Reinstate
Change Address or
Change Name?
B Change Name
D Change Status
Change Name or
Reinstate?
E Transfer
A Change Address
C Reinstate
B Change Name
Ranking the complexity of the features

gives the Applications team a handle
on costs, resources, and schedule.

IT Practice
Requirements
Management
and Analysis
21
Requirements
Management
and Analysis
22
Fenton, Inc.s Functionality ROI Maximization
Strong Impact = 9 Points
Computer Telephony Integration Project, Illustrative
Medium Impact = 5 Points

Low Impact = 1 Point
Vertical views
indicate potential
feature gaps and
redundancies.
High-Level
Requirements
Need for
Associates to Talk
with Previously
Inaccessible
Customer
Segments
Need to Provide
Associates with
Critical Customer
Relationship
Information
Business Value Components
Weight is assigned
based on order of
magnitude of the
value.
Efficiency Goals
Value
Weight
Effectiveness Goals
Increased
Use of Call
Automation
Timely
Handling
of Call
Efficient
Call Transfer
to Sales
Reduced
Calls to
Help Desk
Reduced
Call
Escalation
Increased
Customer
Retention
Intelligent
Call
Routing
$500 K
$275 K
$25 K
$100 K
$200 K
$1 M
$5 M
Scores can be
aggregated
to prioritize
requirements.
Feature Score
(Sum of Weight
x Impact)
System Features
System shall identify which customers
to be harvested.
67
System shall have the flexibility to

easily change harvesting instructions.
63
System shall have the ability to

reorder queues based on harvesting
instructions.
43
System shall only harvest the best

customer segments.
51
System shall display customer and call

information to associate.
71
System shall display key customer data

to associate.
83
System shall provide wrap-up for who

and why customer called.
23
Pseudonym.

IT Practice
Manage Requirements Across Business Process Change

Swiss Res Methodology Decision Map
Customer Request Decision Tree
Yes
Small
(< $250 K)
Is this a
one-time
improvement?
No
Improving
Existing
What is the
size of the
change?
Significant
($250 K$2 M)
Changes a Leverage
Point Within the
Existing Paradigm
Order of
Magnitude
(> $ 2 M)
Improving
Existing
What are you

doing to the
process?
Replacing
Existing
Continuous Process
Improvement
Business Process
Improvement
What are you

doing to the
process?
Replacing
Existing
Information
Systems Planning
What is
the impact?
Changes the
Business Paradigm
Yes
Is there a high level of

risk associated with
the improvement?
No
Business Process
Improvement
Radical Process
Improvement
Radical Process
Improvement
Business Process
Improvement
Radical Process
Improvement

IT Practice
Requirements
Management
and Analysis
23
Requirements
Management
and Analysis
24
Manage Requirements Across Business Process

Change (CONTINUED)
Swiss Res Methodology Decision Map (Continued)
Approach Descriptions
Information Systems Planning
Improving the automation of, or information support to, an existing

process
Restructuring information systems for technical efficiency, functional
flexibility, and maintainability
Moving automated support from one platform to another
Improving the integration among information systems
Continuous Process Improvement
Business Process Improvement
Measuring and analyzing the existing process to identify problems for

resolution and other improvement opportunities
Applying left-to-right thinking to evaluate how the parts of the process
contribute to the required outputs and performance
Identifying leverage points with the greatest opportunity for competitive
advantage and performance improvement
Developing a set of improvements that together amount to significant
improvement in such areas as cost, time, and quality.

Installing a quality-oriented culture and set of procedures to encourage

and exploit improvement ideas from workers
Applying left-to-right thinking to evaluate how the parts of the process
contribute to the required outputs and performance
Achieving a series of improvements of smaller magnitude in such areas
ascost, time, and quality that, over the course of time and the scope of
the entire process, amount to significant improvement
Radical Process Improvement

IT Practice
Monitoring the existing process through a rigorous measurement program

to identify problems for resolution
Replacing an existing process with a completely new or a substantially

redesigned one, generally accompanied and enabled by radical changes
inthe use of information technology and people
Applying right-to-left thinking, beginning with required outputs and
deriving the essential process
Actively challenging and rejecting old paradigms by lateral thinking
Achieving order-of-magnitude improvements in such performance
measures as cost, time, quality, and flexibility, either out of competitive
necessity or the desire to leap ahead of the competition
Business Process Reengineering addressing the extreme end of business
process redesign, where the level of scope, impact, and risk is the greatest

Change (CONTINUED)
Swiss Res Methodology Decision Map (Continued)
Requirements Process, Three Stages
Architectural Analysis
Architecture
Planning
Architecture
Design
Business Process Analysis and Design

Architecture
Review
Initiate
Analysis
Deliverables
Gather
Process
Requirements
Model
Process
Design
Review
Process
Design
Business Solution Analysis and Design

Approve
Process
Design
Deliverables
Application Landscape
Business Information Model
Context Diagram
Draft Application Context Diagram
Business Dynamics Models

Requirements Matrix
Business Value Chain
Ownership Assignments
Hierarchies
State Transition Diagrams
Initiate
Analysis
Typical Activities
Discuss project with local architecture

team, obtain any business grouplevel
reference artifacts.
Assess impact of any proposed changes
onexisting architectural environment.
Discuss appropriate timings and number
of governance reviews with Architecture
Governance and Standards team.
Review and familiarize with Business Case
and Project Definition Document.
Initiate business process analysis.

Gather business process requirements.
Model business process design.
Review business process design.
Sign off on business process design.
Model
Process
Design
Review
Process
Design
Approve
Process
Design
Deliverables
Typical Activities
Gather
Process
Requirements
Business Process Models

Logical Data Model
CRUD Matrix
SDL Compliance Statement
Application Context Diagram
Information Flow Diagram
Prototype Screen Flows and Designs
Test Documentation
Use Case Documents
Typical Activities
Initiate business solution analysis.

Gather business solution requirements.
Model business solution design.
Review business solution design.
Sign off on business solution design.

IT Practice
Requirements
Management
and Analysis
25
Requirements
Management
and Analysis
26

Change (CONTINUED)
DRAKE
corporation
Drake Corporations Voice of the Customer Tool

Stakeholder Group Analysis
Challenge
Opportunities
Current Commitment
(SS, S, N, A, SA)
Needed Commitment
(SS, S, N, A, SA)
Probabilities
of Success (PoS)
Possible Strategies
to Improve PoS
Concern they are gaining

more work, not less
Believe the opportunity.
Supportive
Strongly Supportive
90%
Rewarded for
developing, not
replicating applications
Not as attractive as
new productivity
launch
Not tech savvy
Dont see tech service
as a partner
Not on their dashboards
Lab heads asked

for this.
Supportive
Strongly Supportive
70%
Its their vision.
This is a low-risk way to

reach growth targets
and premium source of
marketing campaign
ideas.
Neutral
This is a low-risk way to

reach growth targets.
Neutral
Supportive
40%
Supportive
60%
Pseudonym.

IT Practice
Engage innovators
andearly adopters.
Leadership set
priorities for all of their
work, let some drop.
OUSet TS growth
objectives.
USEngage tech
directors.
Develop new
incentives.
Seek help from
marketer to develop.
Group metrics on
the acceleration
dashboard.
Promote the value
to the executive
conference.
Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY

CIGNAs Portfolio-Level Requirements Management
Group Project According to Shared Impact on Business
Business project priority ranking results in

a list of projects to be completed based on
initial capacity estimates.
The project portfolio is segmented into

groups of projects according to shared impact
on business processes.
Projects are regrouped into delivery

flights based on business need, which
processes they affect, and where in the
process chain their effect is prominent.
Business Priority
Business Process Implications
Business Process Synergy
What is the customers desired

priority and what is our current
delivery capacity?
How much process transformation

will be realized and which processes will
be affected?
What is the delivery impact on business

workflows across dependent business
processes?
1. ERP Finance Upgrade

2. Customer Information Database
3. HIPAA Rights Repository
Customer
Service

7. Benefits Management Portal
Flight
One
5. Receipt Management System

6. Bill Processing System
9. E-Billing Presentation
4. Claim Submission System

Claims
Processing


Flight
Two
8. Medicaid Reporting Repository

General
Accounting

8. Medicaid Reporting
Repository

8. Medicaid Reporting Repository
Flight
Three

For smaller, less-strategic projects,

CIGNA creates alternative paths to
expedite requirements gathering.
IT Practice
Requirements
Management
and Analysis
27
Requirements
Management
and Analysis
28
Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED)

CIGNAs Portfolio-Level Requirements Management (Continued)
Alternate Path for Requirements Delivery
Qualifying Criteria
Approved and funded enterprise projects that meet the following criteria will qualify for the alternate path for requirements development:
Goal is to improve process performance, operating efficiency, and/or cost of a current business process.
Minimal changes to current business process are anticipated.
The change has already been identified and defined by the business area.
Process impacts are limited to 1 to 2 domains, and target specific business functions in either or both of those domains.
Nonqualifying Criteria
Enterprise projects that would not qualify for the alternate path would meet the following criteria:
New technology is anticipated for solution (feeds, data exchanges, etc.).
New business process and/or major reengineered business process is anticipated.
New operations workforce/functions is anticipated to support solution.
PPR Staffing Assumptions

Functional BA resources within Project Process Requirements (PPR) will be assigned to these initiatives.
Functional BA resources will use current is process map as basis for identifying specific process-impacted areas to be worked and will define use cases to outline requirements
forthis portion of the process map.
Functional BA will be responsible for integrating the use cases created for these projects back into the process map, so these detailed changes are not lost amid the larger flight
plan work; process modeler (PM) will work with functional BAs to ensure accurate integration of changes.
Work effort for initiatives on alternate path may need to be revisited if during working these items, the changes are found to have a greater impact on the targeted business
process(es) than originally expected.
To support these projects, BA resources will work these initiatives directlywith expertise spanning appropriate domains.
Proposed Timeline
Timeline for initiatives being addressed in alternate path will run parallel to the PPR flight schedules; specific milestones for each initiative will be negotiated with the PM and domain
lead to confirm schedule for requirements delivery for smaller initiatives following the alternate path.
Use case deliverables will be the artifact to be delivered by PPR resources.
Requirements Traceability Matrix deliverable will be established also by the functional BA(s) working the project, as a means to capture initial project information that summarizes
the needs for the process modification as well as to establish traceable documentation for the change as it moves into design, development, and testing.
Business SME validation will be conducted by the functional BA (informal basis) to confirm detailed changes are accurate and meet the project objectives.

IT Practice

Project Impact Assessment on Should Business Processes
The impact of a project on

a business process step
represents the magnitude
of process transformation.
High Impact
Medium Impact
Low Impact
Customer Service
Claim Correspondence
Accounting
Claim Adjudication
Payment
Check
Fund
Paper
Claim
Electronic ClaimClaim AdjudicationNon-Medical
Claim
Correspondence
Payment
Claims
Processing
Claim Pricing
Medical Claims
Generation
Transfers
Claims
Receipt Process Receipt Process
Check
Fund
Paper
Claim
Electronic ClaimClaim AdjudicationNon-Medical
Claim
Correspondence
Payment
Claim Pricing
Medical Claims
Generation
Transfers
Claims
Receipt Process Receipt Process
M
H
M
Check
Fund
Non-Medical
Paper Claim
Electronic Claim
Claim Pricing
Medical Claims
Generation
TransfersM
Claims
Receipt Process
Receipt Process
MH
H
MM
M
E-Presentation Portal
E-Presentation
Portal System
Flight
Projects
Receipt
Management
E-Presentation
Portal System
Receipt
Management
Customer
Information
Database
MH
M
M
Receipt
Management
System
Customer
Information
Database
Provider
Management
System
Customer
Information
Database
Provider
Management
System
Member
Web Site Redesign
HL
MH
HL
MH
ML
L M
H L
LL
ML L
MH
Provider
System
Member
Web
SiteRights
Redesign
HIPAAManagement
Member
Repository
Member
Website
Redesign
HIPAA
Member
RightsSystem
Repository
Medicaid
Reporting
HIPAA
Member
RightsSystem
Repository
Medicaid
Reporting
LL
LL
MH
Medicaid Reporting System
Similar or redundant system functionality is identified

to consolidate requirements gathering across projects
and expedite requirements elicitation.
MM
L
M
M
L
L
3
M
Multiple process
impacts in a row
indicate process
flow and information
dependencies.
M
4
CIGNA minimizes time spent on each

subsequent flight by building and actively
maintaining business process libraries.

IT Practice
Requirements
Management
and Analysis
29
Requirements
Management
and Analysis
30

Requirements Clarification: Roles, Responsibilities, and Escalation Process
1 As Is Process Modeling
Owner
Process Modelers
15% of Requirements Group
Responsibility
Model as is business processes to
denote the flow of information and
cross-connections among process
segments at all levels.
2 Should Process/High-Level
Requirements
Owner
Senior Business Analysts
Key Deliverables
Responsibility
Business process maps, which highlight

interdependencies within and across
process areas
Capture business process dependencies

in terms of sequential activities to
uncover asis to should business
process variance.
B
If a requirement interdependency is the product
of a new process interdependency, senior
business analysts work with process modelers to
evaluate and resolve the new interdependency
together and update business process maps and
IS/SHOULD Summaries accordingly.

Owner
Functional Business Analysts
Key Deliverables
Responsibility
IS/SHOULD Process Change

Summary, which outlines how process
functionalities interrelate
Elicit detailed requirements consistent

with as is and should business
process models.
Key Deliverables
A
If a new requirement interdependency is uncovered
during the detailed phase, functional business
analysts work with senior business analysts to
update IS/SHOULD Process Change Summaries.

IT Practice
3 Detailed Requirements
Business use cases, which include

activity flows and new process
modifications

Project, Process, Requirements Team Responsibilities by Phase
Project Initiation/
Awareness Meeting
Review project documentation (e.g., project

proposal, project/product description) for
clarity, completeness, and potential domain/
function impact.
Work with Enterprise PM (EPM) to achieve
clarity and completeness of project scope if
needed.
Provide high-level time/cost estimates for
PPR activities to EPM.
Perform a high-level process decomposition
to identify the potential processes impacted
by the project and across projects.
Share outcome from the decomposition
for review with EPMs and subsequently
with matrix partners.
Identify and communicate domain lead to EPM.
Planning
Requirements
Plan and schedule high-level requirements

sessions by domain based on project
decomposition.
Engage business subject matter experts
(SMEs) to support and plan requirements
definition.
Work with EPM to define requirement
kickoff date based on PPR capacity.
Outline/document proposed requirement
gathering dates (high level, process
modeling, and detailed) for review by EPM
and subsequently by matrix partners based
on capacity, project, and process synergies.
High-Level Requirements
Assist with issue resolution, provide

clarification, and respond to questions.
Support scope change management process
and update documentation as needed
Testing
Provide input to any phasing of solutions.

Assist with issue resolution, provide
clarification, and respond to questions.
Update business requirements traceability
document with assistance from System
Analysis to ensure design traces back to
requirements.
Support design documents and walk
through to verify design meets business
requirements.
Support scope change management
process and update documentation as
needed.
Detail Requirements
Facilitate and document high-level requirements and process models focused on

specific processes within a domain (not project specific).
Create requirements traceability matrix based on high-level requirements including
process and project views.
Create Use Case Inventory by process/project and assign owners for completion.
Conduct high-level requirements sessions walkthrough with matrix partners
stressing manual touchpoints and new or eliminated processes based on high-level
requirements.
Identify and document issues; assign owners and facilitate requirement issue
resolution.
Based on completed high-level requirements, assess and update estimates as
needed.
Construction
Design
Provide test support for test scenario

identification and defect resolution.
Conduct end-to-end domain/project review.

Plan and schedule detailed use case sessions.
Create and maintain detailed process models and detailed business use cases.
Build/update process maps and use case library (ongoing).
Ensure appropriate representation in meetings to complete detailed
process models and business use cases (e.g., SME, SA).
Distribute materials and conduct walkthrough of detailed process models.
Distribute materials and conduct walkthrough of detailed business use cases.
Identify and document issues; assign owners and facilitate requirement issue resolution.
Update requirements traceability documents based on detailed requirement activities.
Provide information to project test leads as input to project test strategy.
Support scope change management process and update documentation as appropriate.
Implementation
Provide input for implementation planning.

Provide support for clarifying questions, etc.
Warranty
Provide support for clarifying questions, etc.

IT Practice
Requirements
Management
and Analysis
31
Requirements
Management
and Analysis

IT Practice
32
Section 3: Creating
Compelling Business Cases

IT Practice
Creating Compelling
Business Cases
33
Creating Compelling
Business Cases
34
CREATING COMPELLING BUSINESS CASES

Articulate and Quantify Business Benefits
Measure and communicate proposed project benefits by linking components
of business value to requirements.
Fenton, Inc.s1 Functionality ROI Maximization35
Fenton Inc. itemizes the benefits in the business case, quantifying the value
ofapplication functionality and tracking project ROI trends at the portfolio level.
1. Trace benefits, not just requirements: Explicitly link components of
business value to application requirements and system features so that
they can be traced through the lifecycle.
2. Be an order shaper when it comes to benefits: Compel business
partners to articulate a projects benefits in terms of quantifiable
components that are directly tied to a particular aspect of their
workflow.
3. Prioritize features and requirements based on business benefit: Benefit
is the most meaningful metric for determining a projects value. Be
specific when it comes to quantifying those values.
4. Track ROI at the portfolio level: Only a portfolio view can detect trends
across categories and effectively communicate value delivery at the
enterprise level.
When to Use
To itemize benefits in a business case
To trace benefits through the project lifecycle
To prioritize requirements according to quantifiable benefits
To track project ROI trends at the portfolio level
Essential
Reference
Specialized
McDonalds Business Case Abstract44

BAs are called by the business relationship managers to help create business
case abstracts and prepare any related preproject work, such as helping with
cost estimation.
When to Use
To create business case abstracts
Essential
Pseudonym.

IT Practice
Specialized
Omega Corporations1 Standard Business Case Criteria45

Omega Corporation revises business case review processes for IT projects to instill
business sponsor accountability and emphasize quantifiable, hard business
benefits. The process starts with a standard business case that captures total
five-year costs of ownership, including common hidden costs often overlooked
by business users during business case preparation. These proposals include
architecture compliance, sourcing considerations, and operating requirements,
such as infrastructure costs, maintenance, training, and support.
When to Use
To create a business case proposal capturing hidden requirements
Essential
Reference
Specialized
Citrixs Business Case Summary46

Citrix synthesizes key IT project dataincluding financial metrics, risk
indicators, and business justificationin a one-page format for easy steering
committee review.
When to Use
To create a high-level business summary emphasizing quantifiable
business benefits
Essential
1
Reference
Reference
Specialized
ARTICULATE AND QUANTIFY BUSINESS BENEFITS
Fenton, Inc.s Functionality ROI Maximization

1. Connect Application Functionality to the Drivers of Business Value
Business Value Cascade
Key Challenges
Business Value Realization Steps
Business Case
Business
Value
Mapping
Monolithic business case
Itemizing the
benefits in the
business case
Business Value
Components
2
Component 1
Component 2
Business value drivers are

not connected to specific
business activities.
High-Level
Requirements
Business Activity 1
Business Activity 2
Benefit-Driven
Feature
Prioritization
Quantifying the
value of application
functionality
Business Activity 3
3
System Capabilities
Application
Functionality
1
Application
Functionality
2
Application
Functionality
3
Application
Functionality
4
Business activities dont

tie to specific application
functionality.
Portfolio ROI
Dashboard
Tracking project
ROI trends at the
portfolio level
Pseudonym.

IT Practice
Creating Compelling
Business Cases
35
Creating Compelling
Business Cases
36
ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED)
Fenton, Inc.s Functionality ROI Maximization (Continued)

2. Connect Business Value to Business Process
Expected Benefits from Business Case
Business Value Components
Computer Telephony Integration Project
Component Quantification Template
Efficiency Goals
$7.1 M
Cost
Reduction
Revenue
Increases
$1.1 M
Goal:
a. Increased use of call automation
$500 K
b. Timely handling of call
$275 K
c. Efficient transfer to sales
$25 K
d. Reduced calls to help desk
$100 K
e. Reduced call escalation
$200 K
Target:
74 seconds
Improvement:
11 seconds
Cost Savings:
$275 K
Calculation:
The 11-second improvement is the measurable value

Fenton, Inc. monitors to track benefits realization.
$5 M
Total = $6 M
Computer Telephony Integration Workflow
Illustrative
Efficient transfer
to sales = $25 K
No
Customer opts
for live person.
Customer is
greeted by
name.
One
and
done?
Yes
Increased customer
retention = $1 M
Sales referral
Help ticket
opened
Escalated call
a
1
Increased use of call

automation = $500 K
Pseudonym.

IT Practice
Timely handling
of call = $275 K
Intelligent call
routing = $5 M
390 hours x $13.55 x

52 = $275 K
$1 M
b. Intelligent call routing
Start
85 seconds
Effectiveness Goals
a. Increased customer retention
Customer calls
automated
system.
Baseline:
Total = $1.1 M
$6 M
Timely handling of call
Reduced calls to
help desk = $100 K
Reduced call
escalation = $200 K
Call complete
End

2. Connect Business Value to Business Process (Continued)
Evaluators are asked to provide a brief written

assessment for each of the seven categories and a brief
explanation of the rationale behind their scoring decision.
Discretionary Project Assessment

Categories
Scoring Options
Scoring Guidelines
Quantifiable Business Objectives (QBOs)

Evaluate the projects objectives and needs,
based on its inherent ability to be understood
and documented in a clear, unambiguous, and
verifiable manner.
Objectives and needs are very clearly understood and are verifiable and attainable.
Lack of clarity exists with respect to the projects objectives and needs, or it is uncertain how the business objectives can be verified
or satisfied.
No ability to state project objectives and needs in unambiguous and/or verifiable terms; little certainty on how the project will deliver
real business value.
Evaluate the project for its anticipated impact on

the customer. Indicate whether the customer is
internal or external.
Project implementation is expected to be virtually transparent to the external customer AND the project will have little impact on
internal customers.
Project is expected to have marginal impact on the external customer AND/OR significant impact on the internal customer.
Definition: ImpactAffects the product or service

the customer receives and/or the manner in which
they receive it
Customer Impact
Project is expected to have significant impact on the external customer AND significant impact on the internal customer.
Business Process Reengineering (Cost Reduction)

Evaluate the project for opportunities to reduce
operating costs through the enhancement of
business process performance.
Proper use of technology requires very little workflow integration. Contextual and environmental factors do not weigh significantly
on the ability of the technology component to yield measurable business value.
Marginal opportunities to enhance process performance may exist, but significant gains in business value may not be certain. Also
the projects success likely will not depend on business process enhancements.
Six Sigma and related techniques, focusing on process efficiency and developing robustness against environmental noise, will most
certainly deliver significant business value. Project success may depend on it.
Clear and concise understanding of how the project benefits will result in a positive, quantified impact on the sponsors business
objectives. The benefit impact is supported by precise and verifiable cost and/or revenue data.
A case has been articulated for how the project can yield benefits that will positively impact the sponsors business objectives, but the
benefits are not quantified, and the proposal is not supported by precise and verifiable cost and/or revenue data.
Little or no case has been made for how the project will yield quantifiable benefits that will positively impact the sponsors business.
Project Objectives and Needs

Evaluate the project for an understanding of how
its benefits will translate to a quantified, positive
impact on the sponsoring entitys business
objectives.
Three most important criteria in determining whether intervention is required

1
Pseudonym.

IT Practice
Creating Compelling
Business Cases
37
Creating Compelling
Business Cases
38

Discretionary Project Assessment
Categories
Scoring Options
Scoring Guidelines
Profit Potential (Revenue Growth)

Evaluate the projects or products impact on, or
capacity to generate, profitable revenue growth.
Project objectives are not likely to drive significant, profitable revenue generation. The use of Six Sigma resources is not warranted
based solely on profit potential.
Project objectives may drive significant, profitable revenue generation. The use of Six Sigma resources is likely warranted based
on profit potential.
Project objectives have a large potential to drive substantial, profitable revenue growth. The use of Six Sigma resources is most
certainly warranted based on profit potential.
The project has the full support of the sponsoring entities AND no conflicting needs exist among those entities
(or only one sponsoring entity is involved).
There is moderate support from the sponsoring entities AND/OR there are limited conflicts between the needs
of sponsoring entities.
There is limited support from the sponsoring entities AND there are potentially significant conflicts between the needs
of sponsoring entities.
Normal operations in the target environment will involve very little depth of human interaction with technology AND the number of
human users that directly interact with technology will be relatively insignificant.
Normal operation in the target environment may involve significant depth of human interaction with technology AND/OR the
number of human users that directly interact with technology may be significant.
Normal operation in the target environment will involve significant depth of human interaction with technology AND the number
of human users that directly interact with technology will most certainly be significant.
Sponsor Interdependency
Evaluate the project based on the level
of sponsorship interdependency.
Human Interaction with Technology

Evaluate the project based on the anticipated
degree of human interaction with technology
components in the use environment.
Total Score (Sum of Scores as a Percentage)

Summary
Provide an overall summary of the project and recommendations.
Pseudonym.

IT Practice
Threshold
(4563)
Intervention Required
(3144)
Reevaluate
(730)
No Intervention Required

Efficiency and Effectiveness of Business Process Performance
Business Process
Process Output
Quantifiable Business Objectives (QBO)

Process Efficiency
Speed
A Measure of Net Business Value
QBO opportunity: Measure

and decrease operating costs.
QBO opportunity: Measure

and increase customer value.
Cost Reduction2
Revenue Attainment2
Consistent
Procedures
Waste Rework/
Elimination
Handoffs
of Work Steps
Defect-Reduction
Products/Services
Critical Attributes of Cost
Pseudonym.
Representative list.
Process Effectiveness
Customer-Valued
Products/Services
Critical Attributes of Quality

IT Practice
Creating Compelling
Business Cases
39
Creating Compelling
Business Cases
ARTICULATE AND QUANTIFY BUSINESS BENEFITS (Continued)

3. Quantify Each Features Impact on a Projects Business Value Components
Business Value Translation Template
Business Objective
Intelligent Call Routing
QBO Statement
Increase revenue by $X million/year by routing calls into the call center matching the individual customer need with an associate trained to handle that customers
relationship and $X million from customer retention annually. This strategy is expected to expand customer relationships, retain customer households, and increase
employee engagement.
Problem
Current call routing lacks the ability to match individual customers explicit and implicit needs to a specifically skilled associate trained to handle his or her relationship.
Affected Areas
1. Direct Banking Sales

2. Product Group
3. Service and Specialty Associates
4. External Customers
5. Self-Service Customers
Impact
1. Direct banking sales associates are not able to get more qualified referrals for expansion opportunities.
2. The product group is not able to position and sell its products efficiently within the call center.
3. Service and specialty associates are not presented with enough customer information to make a qualified expansion referral or attempt to save
the customer household.
4. External customers may not receive the most efficient customer service because associates are not trained to handle their specific financial needs.
5. Self-service customers who never opt-out of the IVR are not a population that associates have an opportunity to speak with to explore the needs
of those customers.
Solution
Need
Features
Increase revenue, customer retention, employee engagement, and customer satisfaction and improve the customer experience.
Utilize skill-based call routing and BSR together.
Enable associates to talk to customer base previously untouched (do not call and self-service only).
Need
Need
Need
Need
for associates to talk with customer segments previously not accessible to associates
for select customer groups to have their calls specially routed
to provide the associates with critical customer information pertaining to the customers interaction and relationship
to be able to effectively report on call routing and call harvesting
The system shall identify which customers shall be harvested.

The system shall provide the flexibility to easily change harvesting instructions.
The system shall provide a feedback loop to identify when a call was harvested.
The system shall provide the ability to reorder queues based on harvesting instructions.
The system shall only harvest select, best-of-the-best customer groups out of the IVR.
When the customer is harvested, the system shall route the customer to the correct associate based on the routing instructions.
The system must be able to read harvesting instructions efficiently so as not to impact the customers time to transfer to an associate.
The system shall provide whisper functionality to alert associate that the call is harvested.
Pseudonym.

IT Practice
40
1

4. Track ROI at the Portfolio Level
A Heat Map Representation Clarifies the Distribution of Portfolio ROI
Business Revenue
Customer ValueBase
The size of the bubble

depicts the project return.
Customer ValueCompetitive
Customer ValueDifferentiated
High
Cost-Efficiency/Compliance
Key Advantages
High-impact communication tool
Portfolio pattern recognition
ROI trend monitoring
Business Value
Low
Low
High
Project Cost
Pseudonym.

IT Practice
Creating Compelling
Business Cases
41
Creating Compelling
Business Cases
42

4. Track ROI at the Portfolio Level (Continued)
Business Value Categories
Business Value Category
Definition
QBO Requirements
Customer ValueDifferentiated
Establishes a unique capability for the external customer over ones peers/
competitors based on cost, quality, speed, and/or functionality
VOC illustrates industry gap to meet order of magnitude customer needs.
Ethnography to survey techniques
Predictive market analytics
VOC illustrates companys gap to competitors to meet customer needs.
Focus group to survey techniques
Responsive market analytics
Customer ValueCompetitive
Customer ValueBase
Provides where properties are defined as a enabling minimum capabilities for

the external customera commodity in nature
N/AMay be combined with other business outcomes
Business Revenue
Limited received value gain for the external customer but enabling revenue gain
to the company
Present historical, data-based customer behavior patterns to support proposed

change.
Existing or competitors customers

N/ASelf-explanatory
Consolidation/Acquisition
Acquisition or divestiture activities
Cost Reduction/Avoidance
Pure cost reduction or avoidance play with limited ongoing efficiency gains
Elimination or avoidance of one-time costs
Defensive/Renewal
Renewal of applications/technologies/business processes to maintain

capabilities with limited external customer value or internal efficiency gains
Demonstrate no linkage to customer value or operating efficiency, or cost

reduction/avoidance.
Baseline current state; demonstrate future state achievement to baseline
Must support X number of future capabilities
Measurable expectation of capability achievement
Demonstrate scalability, cost effectiveness, supportability, etc.
Enterprise Capability
Provides where there are optional features for the external customer and/or
failing to match the equivalent capability of peers/competitors will erode ones
competitive standing over time
Provides broad underlying capabilities supporting multiple LOBs, projects, or

future corporate/strategic initiatives
Operating Efficiency
Provides ongoing internal cost reductions or other supporting internal

operational factors (e.g., time to deliver, internal consolidations)
Demonstration of activities that will result in a reduction of ongoing costs (per unit
or total business process)
Regulatory/Compliance
As required by government, internal audits or other regulations with limited

external customer value or internal efficiency gains
Demonstrate ability to maintain current operating efficiency.
Demonstrate effectiveness of compliance solution.
Demonstrate potential financial impact to corporation.
Explain impact to internal or external customers.
Pseudonym.

IT Practice

4. Track ROI at the Portfolio Level (Continued)
Business Value Categories (Continued)
Business Benefit Scorecard
Business
Outcome
Project
Count
Percentage
of Projects
Total
Investments
Percentage
of Investment
Average
Cost per
Project
Cost
Relationship
to Average
QBO $
QBO %
Average
QBO per
Project
QBO $ per
Investments
Business
Revenue
11%
$8,052,504
11%
$1,610,501
85.5%
$25,341,001
7%
$5,068,200
$3.15
Customer
ValueBase
10
5%
$1,520,317
2%
$152,031
8.07%
$4,000,430
1%
$400,043
$2.63
Customer
Value
Competitive
13
12%
$10,314,678
14%
$793,436
42.1%
$86,531,408
23%
$6,656,262
$8.39
Customer
Value
Differentiated
7%
$32,533,255
45%
$6,506,651
345.4%
$168,121,704
45%
$33,624,341
$5.12
Cost-Efficiency/
Compliance
58
65%
$20,600,152
28%
$355,175
18.9%
$91,196,549
24%
$1,572,354
$4.43
Grand Total
91
100%
$73,020,906 100%
$375,191,092
100%
$47,321,200
$5.14
$1,883,559 100%
Pseudonym.

IT Practice
Creating Compelling
Business Cases
43
Creating Compelling
Business Cases

McDonalds Business Case Abstract
Illustrative Example
Real Estate and Construction Cost Project
Real Estate and Construction Cost Project
Objective
Benefits
Provide timely and accurate real estate and construction capital expenditure
information; this will enhance McDonalds ability to optimize investment
decisions, drive down costs, and speed the administration of the closeout of
construction projects.
Solution Summary
Improve investment decisions and strengthen McDonalds leverage with
suppliers during construction project negotiation by:
Providing timely and accurate reporting of real estate and construction

capital expenditure plans, actuals, and projections;
Driving supplier optimization and savings through comparison of project
component costs (i.e., asphalt, concrete, framing); this will strengthen cost
controls by enabling reporting on baseline commodity prices; and
Driving general contractor savings through comparisons of construction
costs and time to complete across multiple projects, phases, building
types, geography, and square footage.
Improve accounting administration efficiencies of existing restaurant

remodels and new site construction by:
Automating creation of capital expenditure reports;

Reducing financial reconciliation effort through improved system
integration;
Reducing project closeout time by improved system integration;
Enabling access to the new application by all key stakeholders, which
includes McDonalds remote workers;
Centralized controls of signing limits for change orders and invoices; and
Centralized system that includes all real estate and construction costs.

IT Practice
Direct/Hard SavingsNone
Indirect/Soft Benefits
Construction supplier optimization and cost avoidance
General contractor optimization and cost avoidance
Improved accounting administration efficiencies
TIB Screens
Business AlignmentMODERATE
Be the most productive provider by achieving G&A and capital
expenditure targets
LeverageMODERATEUS/Corp. solution
Financial StrengthWEAKBenefits are indirect/soft
Risks
Software vendors able to meet McDonalds business requirements

without extensive custom programming
44
Omega Corporations Standard Business Case Criteria

Standard IT Project Business Case
Financial Analysis
Architecture Review
Project Valuation
Payback period
NPV
IRR
ROI
Five-Year CostBenefit Analysis
Benefit Analysis
Software capitalization
R&D tax credit analysis
Detailed cash flow and P&L impact including:
Benefits (e.g., increased revenue, revenue
protection, expense reductions, cost avoidance)
Project costs
Capital (hardware, software, and other)
Expenses
Operating expenses
Support staff
Ongoing maintenance (hardware, software)
Training
Communications, etc.
Project category
Strategic development
Mandated initiatives
Discretionary enhancements
Consistency with IT architecture and data
standards
Opportunities to use existing functionality
Critical timing issues
Opportunity Analysis
Sourcing Review
Project vendor selection process

Opportunities to reuse existing contracts
Offshore development opportunities
Lease-versus-buy analysis
Operations Review
Project description, rationale, intended

functionality
Project steering committee members
Business risks to benefits realization
Technology performance risks
Alternatives considered
Quantifiable cost of not proceeding
Project dependencies on other initiatives
Staffing requirements
Legal, regulatory, compliance considerations
Training requirements
Retirement strategy
Project delivery plan, scheduled milestones
Impact on existing infrastructure, software,

andservice contracts
Ongoing maintenance requirements
Savings and costs associated with
decommissioning assets
Contingency and recovery costs
Security and privacy compliance
Expected service quality
Pseudonym.

IT Practice
Creating Compelling
Business Cases
45
Creating Compelling
Business Cases
46

Cirtrixs Business Case Summary
Enterprise Strategic Goals
The IT organization
compiles the
summary
from existing
business case
documentation.
Business Objectives
IT Objectives
Value and Visibility
Controls
Align IT with Business
High-Level Project Business Case
Multiple Products
Cost Reduction
Support Shared Admin and Ops
Business Intelligence Platform
Customer Leverage
Customer Impact
Be First and Best Citrix Customer
Sponsoring Organization:
Finance
Next-Generation Partnership
Employee Impact
Sponsor:
Submission Date:
George Deaver
8/4/xx
Sustainable Growth
Continuous Improvement
Competitive Excellence
Productivity Gains
IT Team:
Business Intellgence
People Development
Revenue Generating
Ops Excellence Through

Consistent Framework
Provide Best Customer
Experience
Risk Mitigation
Business Rationale
Need to actively manage enterprise data flow using standard data architecture
Establish pilot test platform with engineering group and apply lessons learned.
Duplicate data entry between business unit interfaces reduces data quality,
leading to inefficiencies and missed opportunities
Use internal resources for build and maintenance to build and retain tool competence.
Run in parallel with current platform for two weeks.
Actuals need to be tracked against forecasts to measure performance
Break delivery into phases with initial release not overlapping with break points in strategic
planning cycle.
Project Description
Milestones
This project will accomplish the following:
Project Start
Project Go-Live
Project Close
1. Compare existing software to competitors to determine if we wish to

continue with them or select another vendor.
2. Select vendor and complete contract negotiations.
3. Configure software.
4. Train users.
5. Deploy to production.
Sept.
Jan.
July
Expected Impact
Project Financials
Comments
Total Capital
$200,000 Data entry time reduced: 30 mins/week

= .5hrs * 50 * 40 = 1,000 hrs p.a.
Improved decision making:
median project cost $100,000 * 100 p.a.
* 2% improvement = $200 K
$100,000
Total Expense
$20,000
Total Costs
$120,000
IT Headcount (FTE)
0.50
Total Benefits

IT Practice
Metric Description
Quantification
Use of enhanced functionality for data capture
100%
20% support costs
Percentage migration of data capture to new platform 75%
Will need 2 FTEs for 3 months
Feed of enhanced BI inputs into SAP
Project objectives
are linked to a
predefined list of
enterprise strategic,
business-focused,
and IT-centric goals.
Section 4: Providing
Accurate Project Effort
Estimates

IT Practice
Providing Accurate
Project Effort
Estimates
47
Providing Accurate
Project Effort
Estimates
48
PROVIDING ACCURATE PROJECT EFFORT ESTIMATES

Estimate Resource Requirements
Manage Time and Budget on Agile Projects
Use a resource calculator to estimate resource needs based on elements

of project complexity.
Continually prioritize the product catalog and build contingency buffers into
the plan to set realistic expectations for total cost and duration.
Marriotts Staff Resource Estimation Calculator50

Marriott disaggregates projects into common tasks and uses a calculator
to determine resource needs. Categories are weighted based on relative
complexity to generate an overall score. Using the overall score, the calculator
categorizes projects as requiring low to high labor to complete. For each task,
labor categories directly convert to resource requirements in hours.
Raytheons Earned Value Metrics for Agile Projects53

Raytheon focuses scarce sponsor time and attention on critical risks and
opportunities. Raytheons earned value metrics for Agile projects help teams
to estimate cost and schedule despite the iterative and more ambiguous
direction of Agile projects.
When to Use
To estimate project requirements at each task
To determine resource needs
Essential
Reference
When to Use
To define requirements in a way that helps with project plan and estimate
To make story point estimates for all features
To inform business about potential risks and opportunities
Specialized
Essential
Reference
Estimate Costs and Risks for Agile Projects
Estimate Benefits for Agile Projects
Allocate project funds and establish project schedule based on an analysis

of best-, expected-, and worst-case cost scenarios.
Estimate the value of benefits using an options approach.
TransCanadas Risk-Based Estimation for Agile Projects51

BAs lead the project, breaking down high-level requirements into detailed user
stories, which delineates business rules and their corresponding validation
messages enabling developers to easily connect requirements to unit tests. To
establish a baseline project cost, the time and effort required to develop each
user story is estimated. Project funding is allocated based on the coverage of
cost scenarios: low-risk projects receive expected funding, high-risk projects
receive worst-case scenario funding. Overall, the Monte Carlo simulation allows
for more informed decisions about project funding.
When to Use
To translate high-level requirements into user stories for Agile projects
To help developers connect requirements to unit tests
Essential
IT Practice
Reference
Specialized
Specialized
British Airways and Emergens Initial Value Estimate for Agile Projects58
British Airways estimates the value of major benefits streams and uses these
estimates to prioritize work by Agile teams. As the team releases the solution
on an iterative basis, actual value realization can be used to refine initial
estimates and reprioritize. Understanding that benefits value are not static,
British Airways uses an options approach to control delivery risks.
When to Use
To elicit goals and testable metrics of project realization from business sponsors
To Identify and prioritize benefits for release
Essential
Reference
Specialized
PROVIDING ACCURATE PROJECT EFFORT ESTIMATES (continued)

Estimate Testing Resources
Estimate testing effort by using the probability of discovering an error.
Hartfords Managing Time and Budget Trade-Offs in Testing63
Hartford uses a risk-based method for managing testing. Using the probability
of finding an error, Hartford makes early but accurate estimates of the amount
of testing resources that will be required.
When to Use
To rank test scenarios by level of complexity
To estimate amount of testing resources required
Essential
Reference
Specialized
Estimate Service Cost

Price services based on their consumption patterns.
SKFs Reusable Services for Large-Scale Integrations72
SKF fortifies services for enterprise-wide reuse by pricing service consumption
intensity, rather than individual service usage.
When to Use
To understand consumption patterns when formulating business
requirements
To understand data standards and definitions for services
To have informed conversations with solution architects and Applications
support staff when estimating services
Essential
Reference
Specialized

IT Practice
Providing Accurate
Project Effort
Estimates
49
Providing Accurate
Project Effort
Estimates
50
Estimate Resource Requirements

Marriotts Staff Resource Estimation Calculator
Illustrative
Task Areas
Database Architecture
Capacity Planning/Performance Engineering
Web Engineering
Desktop Certification
User and Device Security
Web-Based Access Control Engineering
1. Application Technology
COTS
Custom
Other (New to Marriott)
Report/Batch Component
Weight 2
2
4
5
3
Score 8
2. Number of Tiers
One
Two
Three
Four
> Four
Weight 1
Deployment Services
Server Builds
Middleware (Application Integration Solutions)
ID Admin and User Provisioning
Security Architecture
WAN Engineering
LAN Engineering
Configuration Management
Infrastructure Application
Access Control Implementation
Functional Support

IT Practice
One
Two
Three
Four
> Four
Weight 1
1
1
2
3
4
Score 1
Weight 4
Score 1
Weight 3
1
2
3
4
Score 8
Weight 4
High
Medium High
Medium
Medium Low
Low
WEB
Fat/Thick
Metaframe
Terminal Services
Weight 2
1
3
4
5
Score 2
Hours and Assessment Areas

Development
Estimate
Requirements
and Performance
36
Test
Script and
Load Test
72
Production
Troubleshoot
Performance
Issues
12
TAM Plugin
AMS Junction
Weight 2
2
3
Score 4
< 5
610
1120
> 20
Weight 5
2
3
4
5
Questions are designed to

determine the complexity
of the project and the
operational environment of
the end product to generate
reliable work estimates.
Score 15
11. Data Requirements

1
3
1
3
Score 3
6. Customization Level
High
Medium
Low
Labor Category
Score 12
10. Number of Business Functions
5. Applications Details
Upgrade to Existing App (Same Functionality)
Upgrade to Existing App (New Functionality)
Replacing Existing Application
New Application to Marriott
Weight 3
1
4
4
3
190210
148189
64147
2263
021
9. Extranet
1
1
2
3
4
4. Number of Interfaces
15
610
1115
> 15
7. User Base
HQ
International
Properties
Res Centers
8. Client Type
3. Number of Unique OS/Platforms
Thin Client Devices and Software
Total Complexity Score
Complexity Drivers: Capacity Planning/Performance Engineering
Project Oversight
Representative Data to Be Generated

Test Seed Data to Be Generated
Weight 5
5
5
Score 25
12. User Volumes (Total Named Users)

4
2
1
Score 8
< 100
100500
> 500
Weight 3
Total Complexity Score
1
2
3
Score 6
93
Categories and answer

choices are weighted for
relative complexity.
Total score is correlated with
estimates of up-front and
ongoing resource needs.
Estimate Costs and Risks for Agile Projects

TransCanadas Risk-Based Estimation for Agile Projects
Business Requirements
Requirements
Feature Breakdown
User Cases
Award a Non-Prearranged
Biddable Offer
1.5 Business Rules: Award a Non-Prearranged Biddable Offer

Name
Type
1.1
Assumptions
1.2
Definitions
Award
Quantity
Integer
Secure Winning Bid

Set Shipping Route
1.3
Process Flows
1.4
Screen Descriptions
1.5
Business Rules
1.6
Developer Comments
Award a Non-Prearranged
Biddable Offer
Developers write
business rule
validation logic
1. This field is editable if the corresponding

checkbox is True (i.e., checked).
2. The amount awarded to a bid cannot be
more than the max bid quantity for that bid.
System Message: Award quantity must not be
greater than max bid quantity.
based on the
defined validation
message
System Message
Validations
Checkbox
Boolean
Validation X
Bid Rate
Decimal
Validation Y
and then write

Pass/Fail unit tests.
Award quantity must not be

greater than max bid quantity.
Pass
Tests when business rules are followed
Fail
Tests that error handling works as
expected when the rules are broken

IT Practice
Providing Accurate
Project Effort
Estimates
51
Providing Accurate
Project Effort
Estimates
52
Estimate Costs and Risks for Agile Projects (continued)

TransCanadas Risk-Based Estimation for Agile Projects (Continued)
Set Shipping Route

Secure Winning Bid
Estimated
Effort (Hours)
Award
a Non-Prearranged
Biddable Best
Offer
Estimated Effort (Hours)
Best
Schemes/Services
Estimated
Effort (Hours)
Best15.00
Schemes/Services
15.00
Integration Migration
Schemes/Services
15.0027.00
Integration Migration
27.00
Architect
Assistance
Integration
Migration
27.005.00
Architect Assistance
5.00
Define
Validation Rules
Architect
Assistance
5.005.00
Define Validation Rules
5.00
Backend
Define
Validation Rules
5.0077.50
Backend
77.50
UI
Backend
77.5049.50
UI
49.50
179.00
UI Total Development Time
49.50
Total Development Time
179.00
Fix
44.75
TotalBug
Development
Time
179.00
Bug Fix
44.75
Bug Code
Fix Review
44.7557.00
Code Review
57.00
Lead Assistance
CodeTech
Review
57.0060.90
Tech Lead Assistance
60.90
Story Time (Effort)
520.65
TechTotal
LeadUser
Assistance
60.90
Total User Story Time (Effort) 520.65
Total User Story Time (Effort) 520.65
Effort estimates include time
for rework and code review.

IT Practice
Low-risk projects receive

expected funding (covering
50% of cost scenarios).
Range estimates allow for

best- and worst-case scenarios.
High-risk projects receive

worst-case funding (covering
90% of cost scenarios).
100%
Expected Worst
Expected Worst
27.00 Worst
52.00
Expected
27.00
52.00
109.00
27.0052.00 52.00
52.00
109.00
11.00 109.00
17.50
52.00
11.00
17.50
11.0010.00 17.5015.00
10.00
15.00
10.00141.00 15.00250.00
141.00
250.00
96.50 250.00
163.00
141.00
96.50
163.00
337.50 163.00
606.50
96.50
337.50
606.50
84.38 606.50
151.63
337.50
84.38
151.63
57.00 151.63
57.00
84.38
57.00
57.00
57.00113.75 57.00208.35
113.75
208.35
1,629.98
113.75930.13 208.35
930.13
1,629.98
930.13
1,629.98
Probability of Cost Scenario (Percentage)
The largest ranges are reserved

for the highly variable cost of
development time.
Monte Carlo Simulation Results
0%
Best
Worst
Project Cost in US Dollars
Manage Time and Budget on Agile Projects

Raytheons Earned Value Metrics for Agile Projects
A Comparison of Agile and Waterfall Lifecycles
Waterfall
Concept
Definition and
Business Case
Approval
Requirements
Definition
Detailed requirements
definition specifies
all of the technical
functionality that must
be built.
Development and
QA/Testing
Design
No iterations; build to the

specifications identified earlier.
Submit change requests if needed.
End-to-end functionality is
delivered late in the cycle.
Deployment
Quality and
value of
functionality is
typically verified
only on release.
Agile
Concept
Definition and
Business Case
Approval
High-Level
Requirements
Definition
Release Scope
Planning
Sprints
Detailed Requirements
Develop
Test
Integrate
Reprioritize
Deployment
1. Gather detailed requirements by defining technical specifics of the features to be built.

2. Force prioritization and keep the total number of points constant: If business partners add to scope, deprioritize a comparable functionality.
3. Prioritize capabilities according to user needs and value.
4. Rescope or cancel requirements if effort to build exceeds benefits: Revisit the backlog to ensure that the business case for building the rest of the
capabilities is still relevant and sound.
5. Front-load pieces of functionality that users can react to (e.g., interface, data displays, reports) to address the I know it when I see it nature of the
client-needs articulation. Allowing users to see early on what capabilities they are getting reduces rework costs since functionality has not yet been
integrated with many systems. Build buy-in and create evangelists.
IT Practice
Providing Accurate
Project Effort
Estimates
53
Providing Accurate
Project Effort
Estimates
Manage Time and Budget on Agile Projects (continued)

Raytheons Earned Value Metrics for Agile Projects (Continued)
To-Dos for Creating Better Project Plan and Estimates
1. Establish Effort Zero Sprints as Contingency Buffers: Raytheon uses two-week sprints
for delivery of Agile projects. Effort zero sprints are planned every five to eight sprints
depending on the complexity of the project.
2. Rebaseline Velocity If Encountering Significant Cost or Schedule Variance for Three
Consecutive Sprints: Rebaseline velocity by adjusting the number of points expected to
be completed by team members per iteration if the project is consistently over or under
budget.
3. Treat Feature Completion as Binary (Y/N): Feature completion comprises of fully
functional, tested, and integrated functionality. Avoid feature 90% done syndrome to
set clear expectations with sponsors and users.
4. Get Customers to Participate in Test and Sign Off on Features: This will reduce
changes later in the lifecycle and increase buy-in.

IT Practice
54

What the Business Sponsor Cares About
A. Will we deliver the requirements to fulfill the

business case?
B. Will we meet time-to-market requirements?
How Agile Delivers
1. Avoid building fallow functionality by incorporating frequent feedback loops

ensuring relevance of requirements that have not been built yet.
2. Avoid scope creep by forcing a prioritization of scope based on expected
value and available capacity.
3. Sequence high-value features to be delivered first and be able to cancel at

any time and be left with a working functionality.
4. Save on cost by not building functionality that is not useful and high value.
C. Are we going to stay within budget?
5. Save on rework cost since Agile is based on delivering discrete chunks of

tested and valuable functionality.
6. Build discrete components early to provide valid estimates for cost to complete.
D. Will we maximize value from the system?
7. Provide end users opportunities early in the project to influence the

implementation, thereby providing a more user-oriented solution and creating
evangelists when the product is released.

IT Practice
Providing Accurate
Project Effort
Estimates
55
Providing Accurate
Project Effort
Estimates
56

Total Project Cost Estimation
Step 1: The User Stories

User stories are the smallest usable and testable pieces that can be completed in one iteration.
Business partners identify use cases for the project and write them in the following format:
As a <role>, I would like to <action>, so that <value>.
E.g.: As a buyer, I would like to save my shopping cart so that I can continue to shop later.
User story indicates the following:
1. Who wants the functionality?
2. What action does the user want to perform?
3. What business value does the user realize once the feature is implemented?
Step 2: Team Poker Estimation

1. Each team member is given a deck of cards with the
same set of Fibonacci numbers (1, 2, 3, 5, 8, 13, 21...).
2. A user story is presented to the team.
3. Each team member selects a card from his or her deck,
representing the number of story points he or she
thinks the feature will require (relative to past features).
4. Everyone reveals their chosen number at once, and
outliers discuss how they arrived at their estimates.
Step 3: Determine Worst-Case, Most Likely, and Best-Case Scenario

Ranges for the Estimates
1
2 3
User Story
Ideal: 3 Points
Expected: 5 Points
Worst: 8 Points
5. Teams can go through multiple rounds of poker for

each story until they achieve relative consensus.
Estimated Range

IT Practice
13
21
Increasing
Complexity

Raytheons Earned Value Metrics for Agile Projects
Feature Backlog Status After Completing One of Four Iterations, Illustrative
Estimate
(Story
Points)
Completed
(Story
Points)
Actual Cost
(Thousands
of Dollars)
Welcome Screen
10
10
15
AdvertSplash Screen
20
20
30
Login Screen
10
10
20
Personalized Google
Ads
20
Catalog Browser
20
Catalog Editor
10
Shopping Basket
Browser
Shopping Card Editor
25
Check-Out Process
20
Invoice Calculation
10
Credit Card Verification
10
PayPal Payment
Handling
20
Order Confirmation
E-Mail
20
Feature
Totals
200
Expected Percent Complete = 25%; Since

Only One of Four Iterations Completed
Planned Value = Expected Percent
Complete; Total Budget = 25% $175,000 =
$43,750
Actual Percent Complete = Total Number
of Story Points Completed Total Number
of Story Points Planned = 40 200 = 20%
Complete
Earned Value = Actual Percent Complete;
Total Budget = 20% of $175,000 = $35,000
Cost Performance Index (CPI) =
Earned Value Actual Cost = $35,000
$65,000 = 0.53
40
65
Conclusion: Estimate Cost at Completion

Is $175,000 0.53 = $330,188, and We Are
47% Over Budget.
Source: Sulaiman, Sulaiman, Tamara and Hubert Smits, Measuring Integrated Progress on Agile Software Development Projects, Methods & Tools, 20 August 2010, http://www.methodsandtools.com/archive/archive.php?id=61.
IT Practice
Providing Accurate
Project Effort
Estimates
57
Providing Accurate
Project Effort
Estimates
Estimate Benefits for Agile Projects

British Airways and Emergens Initial Value Estimate for Agile Projects
1
2
Discover the
goals of the client
and customer
through interviews.
11
Choose between
competing
and conflicting
stakeholder goals
by ranking goals
against business
value drivers.
9
Explore the process,
define acceptance
criteria, and discover
missing user stories
with what if?
scenarios.
Define user stories

to implement the
steps in the process.
12
Come up with better
solutions by using
innovation techniques.
4
Define the business
value model and
the business value
drivers that will
drive the project.
Discover the
stakeholders and
their goals using a
context diagram.
Elaborate business
processes and the
domain model.
5
Discover the
highest-value
business process
and its supporting
processes.
10
Capture
nonfunctional
requirements with
acceptance criteria
and service levels.
Improve your
process with the
theory of constraints.1
13
Integrate
the customer and
the analyst in
the value stream.
Track progress
and value delivered
across the whole
value stream.
Based on Eliyahu Goldratts 1984 text, The Goal.
Source: Eliyahu, M. Goldratt, Jeff Cox, The Goal: A Process of Ongoing Improvement, (1984), North River Press, 2nd Rev edition (1992), ISBN 0-88427-061-0, 20th Anniversary edition (2004).

IT Practice
58
Estimate Benefits for Agile Projects (CONTINUED)

British Airways and Emergens Initial Value Estimate for Agile Projects (Continued)
Project Breakdown into a Benefits Stream
Illustrative
Tracking Metrics
Project
Paid Seating Project, Business Case: 100%
Value Propositions
(Discrete
Measurable
Objectives Derived
from the Business
Case)
New Revenue
Stream-Seating
Sales
Improve Customer
Experience
Call Center
Efficiencies
Revenue Increase
Revenue Retention
Cost Reduction
Benefits Streams
Basic Online
and Change and
Upgrade Sales
Exit and Other Seat Sales
Principles
Revenue Increase
10%
Revenue Retained
5%
Cost Reduction
3%
Initial Estimate of
Contribution to Business Case
50%
Offline Sales
Basic Online
and Change and
Upgrade Sales
Goals
These benefits are the minimally marketable

feature set that can provide functionality to end
users and will move the business case metrics.
30%
20%
These are initial values only that will be revisited as

benefits tracking provides more information about
customer behavior.
Each project must have business benefits linkable to tracking metrics.
Each project has a small number (fewer than five) of associated value propositions, derivable from impacts on tracking metrics.
Each value proposition is realizable by a benefits stream, defined as a series of releasable feature sets capable of delivering the value proposition.

IT Practice
Providing Accurate
Project Effort
Estimates
59
Providing Accurate
Project Effort
Estimates
Estimate Benefits for Agile Projects (continued)

An Agile Option: XYZ Benefits Stream
Illustrative
1. Initial Value Estimate of Option
2. Cost to Hold
3. Exercising Cost
4. Expiry Date and Conditions
$300 K
$50 K
$100 K
15 March unless market competition

changes
Legend
1. Initial Value
Monetary value estimate is based on assessed contribution

to business benefit.
2. Cost to Hold (Options Buying Price)
Effort to define/document
Effort to determine acceptance tests
Effort to elaborate for the developers to estimate
3. Exercising Cost
Based on the effort estimate

Exercising cost may include switching costs that accrue when an option
is deferred. Switching costs result from the need for a team to ramp up
domain and project knowledge to pick up a deferred release.
4. Expiry Date and Conditions
The date by which the decision must be taken to deliver the release
by a desired date; the expiry date has embedded the lead time necessary
to build the solution for a target release date.

IT Practice
Use the initial value estimate of an option to tentatively

prioritize it on a value proposition roadmap. Revise this value
after each release in a benefits stream.
Calculate the cost to hold to ensure that the initial value
estimate exceeds the cost of formulating the option.
Exercising costs will differ based on teams domain knowledge.

For example, if an option is deferred, it may have a higher
exercising cost when picked up by another team.
Use the expiry date and conditions to understand the timebox

for decision making and any changes that will impact that
expiry date.
60

Continuous Reprioritization Across Releases
Illustrative
3
Initiate
Benefits
Tracking
Develop
and Deploy
4
Obtain Benefits
Realization
Information
from Previous
Releases
5
Reevaluate
Estimated
Benefits on
Future Options
Reprioritize
Benefits
Using benefits realization information, this step

validates and revises the previous estimates of
value of the benefit to the business case.
Initial Value Proposition Roadmap
Final Value Proposition Roadmap
llustrative
llustrative
Change and
Upgrade Seat
Exit and
Other Seat
Sales Online
Exit Row
Seat Sales
Online
Basic Online
Seating Sales
Change and
Upgrade Seat
Basic Online
Seating Sales
Offline
Seating Sales
Release 1
October
Offline
Seating Sales
Release 2
December
Release 3
March
Release 1
October
Release 2
December
Release 3
January
Release 4
April

IT Practice
Providing Accurate
Project Effort
Estimates
61
Providing Accurate
Project Effort
Estimates

Initial Portfolio of Benefits
Voucher Project
Paid Seating Project
Benefit A
Benefit B
Benefit C
Benefit D
Benefit A
Benefit B
Benefit C
Options
Value: 50% of
business case
Options
Value: 30% of
business case
Options
Value: 15% of
business case
Options
Value: 5% of
business case
Options
Value: 50% of
business case
Options
Value: 30% of
business case
Options
Value: 20% of
business case
Options Revaluation
Based on Benefits
Tracking
Reprioritized Portfolio of Benefits
Voucher
Benefit A
Voucher
Benefit B
Paid Seating
Benefit A
Paid Seating
Benefit B
Paid Seating
Benefit C
Voucher
Benefit C
Voucher
Benefit D
Realized
Value: 90% of
business case
Realized
Value: 5% of
business case
Options
Value: 50% of
business case
Options
Value: 30% of
business case
Options
Value: 20% of
business case
Updated Options
Value: 5% of
business case
Updated Options
Value: 0% of
business case

IT Practice
62
Estimate Testing Resources

Hartfords Managing Time and Budget Trade-Offs in Testing
Project Risk Scorecard
Project Selection Criteria
Project 1
Project 2
1. Percentage of Test Cases with Links to Financial Transactions
2. Testers Knowledge of the Application
3. Percentage of Test Cases with Defects in Previous Releases
4. Percentage of Test Cases Requiring Complex Calculations or Logic
5. Percentage of Test Cases Requiring Back-End Process Validations
6. Stability of Requirements
7. Business Criticality of the Project
8. Project Requires Functionality-Based Execution
9. Project Involves Data Warehouse/Data Migration
18/30
23/30
60%
76.66%
10. Project Introduces New Functionality

Total Score
Percentage (Total Score/Maximum Score)
Project 3
Project 4
Project 5
Note: Maximum score equals 30.

IT Practice
Providing Accurate
Project Effort
Estimates
63
Providing Accurate
Project Effort
Estimates
Estimate Testing Resources (Continued)

Hartfords Managing Time and Budget Trade-Offs in Testing (Continued)
Project Risk Scorecard (Continued)
Project Selection Criteria
1. Percentage of Test Cases with Links to Financial Transactions
050%
5090%
90100%
N/A
2. Testers Knowledge of the Application
Strong
Medium
Low
N/A
3. Percentage of Test Cases with Defects in Previous Releases
050%
5090%
90100%
N/A
4. Percentage of Test Cases Requiring Complex Calculations or Logic
050%
5090%
90100%
N/A
5. Percentage of Test Cases Requiring Back-End Process Validations
050%
5090%
90100%
N/A
6. Stability of Requirements
Highly
Medium
Low
N/A
7. Business Criticality of the Project
Low
Medium
Critical
N/A
8. Project Requires Functionality-Based Execution
Yes
No
N/A
9. Project Involves Data Warehouse/Data Migration
No
Yes
N/A
No
Yes
N/A
10. Project Introduces New Functionality

IT Practice
64

Risk-Based Prioritization Tool
PR
Probability Risk Factor (PR)

Test Case Description
1
IR
Impact Risk Factor (IR)
Risk Score
Usage
Frequency
Defect
Prone Areas
Change in
Requirements
Complexity
Business Criticality
IR * PR
16
Sample Test Scenario
2
3
4
5
Scoring Criteria
Probability Risk Factors (PR)
Defect Prone Areas
Highly Defect Prone
Medium Defect Prone
Low Defect Prone
Usage Frequency
Very Frequently Used
Frequently Used
Rarely Used
Changes in Requirements
Frequently Changed
Sometimes Changes
Never Changed
Complexity
Highly Complex
Medium Complex
Low Complex
Impact Risk Factors (IR)
Business Criticality
High
Medium
Low

IT Practice
Providing Accurate
Project Effort
Estimates
65
Providing Accurate
Project Effort
Estimates

Testing Strategy Documentation
1.0 INTRODUCTION
1.1
Background/Summary
1.2 Documentation and References
7.0 TEST MANAGEMENT APPROACH

7.1
Test Environment
7.2 Test Tools
2.0 TEST OBJECTIVES
7.3 Test Data
3.0 TESTING SCOPE
7.4 Test Script/Case Database
3.1 Applications/Functions/Features to Be Tested
7.5 Change Management
3.2 Applications/Functions/Features Not to Be Tested
7.6 Version Control
4.0 DECISIONS, ISSUES, AND CONSTRAINTS

4.1 Decisions
4.2 Issues and Constraints
5.0 ASSUMPTIONS, RISKS, AND CONTINGENCIES
5.1 Assumptions
5.2 Exceptions
5.3 Risks/Contingencies
6.0 TESTING LEVELS AND TYPES
6.1 Unit Testing
6.2 Assembly Testing
6.3 System Integration Testing
6.4 Business Acceptance Testing
6.5 Types of Tests

IT Practice
7.7 Release Management Process/System

7.8 Test Metric Approach
7.9 Defect Tracking
8.0 PASS/FAIL CRITERIADEFECT TOLERANCE
9.0 ROLES AND RESPONSIBILITIES
10.0 ENTRY AND EXIT CRITERIA
11.0 TEST SCHEDULE
12.0 GLOSSARY
13.0 SIGN-OFF AND APPROVAL
66

Testing Strategy Documentation (Continued)
Test Strategy Review Checklist
Section
Section Title
1
2
Checklist Items
Yes
Introduction
Have in-scope and out-of-scope application modules/functions to be tested been

identified clearly?
Scope
6
8
Have in-scope and out-of-scope types of testing been identified?

Has the rationale behind the scope decision been stated?
Test Levels
and Type
Have all the test levels and types been defined?

Have the entry and exit criteria for the applicable types of testing been determined?
Has the requirements analysis process been identified?
10
Has the test process to be followed been defined?
11
Has any exception to the QA framework been documented clearly along with
its rationale?
12
Has the QA automation framework to be followed been defined? (If applicable)
13
14
Comments
Has the intended audience been identified appropriately?

Have all the required documents been identified and referred to for preparing the test
strategy?
NA
Has the project/application overview been documented?
No
Test
Methodology
Has the list of tools and its purpose for various QA activities been identified?
Have the different test environments for different types of testing been identified?
15
Has the test design approach manual and automation been identified for various
types of testing?
16
Has the high-level test data approach been determined?
17
Has the test execution approach that details the testing cycles planned for been
determined?

IT Practice
Providing Accurate
Project Effort
Estimates
67
Providing Accurate
Project Effort
Estimates
68

Test Strategy Review Checklist (Continued)
Section
Section Title
Checklist Items
18
Have test planning activities been outlined clearly?
19
Has the process for change management on how changes are identified,
communicated, and tracked to closure been outlined?
20
Test
Management
21
22
23
24
25
26
27
28
Has the process on version control from development to testing environment been
outlined?
Has the process for defect management been identified?
Roles and
Have all the required roles and responsibilities been clearly stated?
Responsibilities
Have the assumptions and dependencies that underlie the test strategy been
identified?
Assumptions,
Have the risks based on assumptions, dependencies and past data been identified?
Risks, and
Dependencies Are risks being assessed based on their likelihood, and are appropriate mitigations
being determined to avoid the risks?
Test Schedule
References

IT Practice
Does the test schedule contain appropriate timelines, and is it in synch with project plan?
Has the reference to project plan been provided?
Have all the required documents been identified and referred to for preparing
the test plan?
Yes
No
NA
Comments

Test Requirements Traceability Matrix
Item No.
Requirement ID
Requirement Description
Test Condition Name
Test Case Name
Defect ID

IT Practice
Providing Accurate
Project Effort
Estimates
69
Providing Accurate
Project Effort
Estimates
70

Testing Effort Estimation Tool
Complexity of Test Cases

Complexity Type
Complexity of Test Case
Interface with Other Test Case
Number of Verification Points
Simple
< 3 transactions
<3
Average
36 transactions
<3
38
Complex
> 6 transactions
>3
>8
Test Case Classification: Identify the total number of simple, average, and complex test cases for each of the Requirement Classifications in the table below. Refer to the Complexity of Test Cases table to determine the complexity.
Test Case Classification (based on complexity)
Requirement Classification
Simple
Average
Complex
Total
<Functionality/Module 1>
15
12
18
21
24
12
Total
36
36
36
108
Estimate for Total Test Case Points (Note: The Adjustment Factor in the table below is predetermined and must not be changed for every project.)
Test Case Type
Complexity Weight
Adjustment Weight
Number
Result
Simple
72
Average
144
Complex
288
Total Test Case Points

IT Practice
504

Testing Demand Management Tools
Project Resource Mapping
Business Unit Resource Cost Estimation
Illustrative
Illustrative
Business Unit
Project Manager
Name
Assigned
Project
Name
January
2010
Business Unit 1
John
Yes
Project 1
10
Billable Core
Business Unit 1
Kathy
No
Overage on Core $
Business Unit 2
Christina
Yes
Project 7
10
Demand for Flex
Business Unit 2
Karthik
Yes
Project 7
10
Billable Flex $
Business Unit 3
Penny
No
Total Business Unit 1 $
Business Unit 3
Vikram
No
Business Unit 2
Business Unit 4
Penny
No
Demand for Core
Business Unit 4
Vikram
No
Billable Core
Business Unit 4
Jennifer
Yes
20
Over/Under on Core $
50
Demand for Flex
Total Testing Demand
Project 1
Business Unit 1
Jan.
Feb.
Jan.
Feb.
Jan.
Feb.
Demand for Core
Billable Flex $
Total Business Unit 2 $
Business Unit 3

IT Practice
Providing Accurate
Project Effort
Estimates
71
Providing Accurate
Project Effort
Estimates
72
Estimate Service Cost

SKFs Reusable Services for Large-Scale Integrations
Step-by-Step Implementation Toolkit to Sustain Service Reuse
Develop Data-Oriented Service

Definition
Identify service components

using a handful of data
attributes.
Identify Opportunities for

Service Consolidation,
Modification, and Elimination
Use volume and rate of
component and service
consumption to identify reuse
potential.

IT Practice
Build a Price List for Services
Adopt pricing scheme per

service component.
Measure Service Consumption

Use service inbound queue to
count unique message IDs.
Identify cost per service based

on pricing scheme.
Identify Patterns of Service

Usage
Identify which components are

widely used, moderately used,
or not used across services.
Assess the prevalence of
service components across the
portfolio.
Use Existing Billing Structure

to Track Service Consumption
Use existing cost center
structure for applications to
allocate costs to business users
on a monthly basis.
Estimate Service Cost (CONTINUED)

SKFs Reusable Services for Large-Scale Integrations (Continued)
Implementation Cost Model
Implementation and Support Costs per Year
One-Time Costs
Ongoing Costs
$20
$75K
$20K
$75
$20
$150K
$150
$150
$150
Create a Service
Price List
Maintain Catalog
of Services
Make Decisions
About Ongoing
Reuse, Consolidation,
or Elimination
Note: The numbers provided in this cost model should serve as guidance to members; they are not provided by the case company. The numbers
are based on the Councils research, and we encourage members who have additional questions to contact our staff for further discussion.

IT Practice
Providing Accurate
Project Effort
Estimates
73
Providing Accurate
Project Effort
Estimates

Payback on Reusable Services
Service Reusability Model
Service Reusability Assumptions

50
100
25
Data
Transformations
40
Service is consumed by business sponsor, and potentially,

other business units.
When demand for a service is high enough, it is made into a

reusable service.
A conservative estimate of cost avoidance is set at 40% of

the cost to create the initial service. Cost avoidance is not
100% due to the cost of modifying an existing service for a
custom fit and developer time spent finding and learning
about the service.
Typical payback period for a reusable service is 10 minutes;

on average it takes three reuses to break even.
40
External
Connections
40
Internal
Connections
Conversion
to Common
Message
Format
Cost to
Create
One-ofa-Kind
Service
Service
Consumption
Chargeback
Benefits
Cost to
Generalize
and Improve
Service
Performance
Three Months
IT Practice
Cost Avoidance
Due to Reuse
One Month
Six Months
74

Service Cost, Payback, and Consumption Calculator
Costs
Benefits
A. Capital Cost of Building a Service
A. Service Consumption During Its Lifecycle
1. Service development cost per hour (fully loaded labor cost)
$100
2. Estimated number of hours required for one data transformation
100
3. Estimated number of hours required for one internal data

connection
50
4. Estimated number of hours required for one external data

connection
50
5. Estimated number of hours required for one enterprise service bus
50
13. Change in scale of usage due to fortification of service into a

reusable service (total number of requests for a fortified service
divided by total number of requests for the same service before
fortification on an annual basis)
14. Consumption charge per request per service
1,200,000
$0.10
B. Reuse Cost Avoidance

15. Probability that a new user of the service would have asked for
creation of the service, if it had not been fortified for reuse
B. Service Fortification
6. Cost of fortification as a percentage of initial service development
cost
12. Total number of requests for a single-use service per year
0.000001
50%
7. Number of months between initial service creation and service

fortification
8. Duration of time spent on service fortification in number of months
C. Support Costs
9. Expected life of a service in number of months
10. Support cost as a percentage of total lifecycle costs
60
60%
D. Admin Costs
11. Monthly admin cost (fully loaded)
$5,000

IT Practice
Providing Accurate
Project Effort
Estimates
75

IT Practice
Providing Accurate
Project Effort
Estimates
76
Section 5: Architecture
Management

IT Practice
Architecture
Management
77
Architecture
Management
78
ARCHITECTURE MANAGEMENT
Support Business-Led Technology Purchases
Guide business leaders to ask vendors the right questions to unearth the
most likely technology selection pitfalls.
to optimize process maturity. As Alphas BAs develop deep understanding

of processes, they learn to tie requirements to appropriate levels of process
maturity through a three-step process:
1. Define processes before automation.
CareFusions Technology Buyers Guide79

The Technology Buyers Guide, a tool developed by CareFusion, contains
guidelines for business leaders in procuring technology solutions directly from
vendors. It guides them to the right due diligence conversations to unearth
common technology selection and implementation pitfalls.
The Buyers Guide equips business leaders with questions for vendors in four
key categories:
1. Fit with identified business need
2. Automate processes for which a strong business case can be made.

3. Continue automation to improve efficiency as process matures while
avoiding process rigidity.
When to Use
To tie requirements to appropriate levels of process maturity
To use process analytics to make informed technology roadmaps
To prioritize process improvements
Essential
2. Implementation effort
3. Quality of the vendor partnership
When to Use
To manage interactions with technology vendors
To guide and coach business sponsors to make informed technology choices
Reference
Specialized
Balance Process Maturity and Automation

Allow flexibility between automation and processes. Use Business Process
Mapping (BPM) to create a roadmap for automation of processes.
Alphas1 Balancing Process Maturity and Automation83
Alpha determines which processes to automate and at what level, while helping
Pseudonym.

IT Practice
Specialized
Support Service Reuse
4. Financial cost
Essential
Reference
Increase ROI from existing services by reengineering them based on service

usage patterns and data patterns.
DirectTVs Deriving Maximum Value from Existing Technical Services86
DIRECTV identifies critical standard data definitions to reengineer and
orchestrate existing services into higher-ROI service offerings based on
current patterns in data and service usage.
When to Use
To understand data standardization opportunities for services
To identify solution interdependencies
To have informed conversations with architects on service usage patterns
Essential
Reference
Specialized
Support Business-led Technology Purchases

CareFusions Technology Buyers Guide
1. Buyers Guide: Fit with Identified Needs
Part 1: Questions for Self-Reflection
1. Have we defined metrics for assessing the success of this implementation?
2. Do we understand how end users will use this solution?
3. Have we spoken with the likely end users to understand how this would fit
into their existing way of working?
4. How likely is it that the way we use this solution changes over time?
Why Ask These Questions?

It is hard to assess the success of any project that lacks measurable outcomes from the onset.
Business sponsors perceptions of how a solution will be used often diverge from the ways in which they
are incorporated into end users workflows.
Failing to anticipate business change may result in costly adjustments to the solutions later.
Part 2: Differentiating Questions for the Vendor

1. We have identified 23 core problems this solution must resolve for us.
Canyou provide specific examples of how you have addressed these
problems for other clients?
2. What type of preparation (data access, security, special configuration, etc.)
was required to successfully resolve those clients problems?
3. Could we obtain a reference from a customer with the same or a highly
similar problem?

It is very hard to spot the main weaknesses of software solutions during the buying processthey
generally surface during implementation. Therefore, it is common for inexperienced buyers to feel that
they dont understand the potential pitfalls of a solution.
Make customer references truly comparable by ensuring they align to a highly similar problem, rather than
to the product the vendor is offering.
Part 3: Standard Questions for the Vendor

Fit with Identified Business Need
1. How many other organizations use this product?
2. How are your other clients similar and different from us?
3. Can you provide documented case-in-point examples of how other organizations use your product?
4. Can you provide a tailored demo to show how your product will resolve the specific need of our organization?
Functionality
1. Based on the problem we are facing, which functionality of your product will be used most in our organization?
2. Which functionality will we use least?
3. Can you provide examples of functionalities you have added based on client feedback?
Ease of Use
1. How will our staff access the solution?
2. Will our staff be able to use their enterprise ID and/or single sign-on to log into your software?
3. How will our staff pull reports from the software?
Short-Term Versus Long-Term Fit
1. How would our organization have to adapt in the usage of your product in a case of a major business event, (e.g., geographic expansion, M&A, significant increase in staff headcount)?
2. How would you adapt your offering if a competitor offered the same product and services bundle at a lower price point?
3. Which functionalities of your product could be enhanced to meet our specific need more efficiently in future releases?
Overall Grade AF:

(How well did we understand what the vendor told us about this category?)

IT Practice
Architecture
Management
79
Architecture
Management
80
Support Business-led Technology Purchases (continued)

CareFusions Technology Buyers Guide (Continued)
2. Buyers Guide: Implementation Efforts
1. What types of existing data will this solution need to access? Do we know
where that data currently resides? How certain are we that we know?
2. Have we tested end users willingness to change their workflows to fit the
tool as is with little or no customization?
3. How many of our best people are we willing to dedicate fulltime to serve as
subject matter experts during solution implementation? Part-time?
4. Will we need to project manage the implementation of this solution? If so,
what experience will be needed by the person in that role?

Out of all the requirements of a vendor solution implementation, data is the most complicated. It is also
the most likely to undermine the potential benefits as a result of the unforeseen amount of integration
required for the solution to work as planned.
Significant modifications to existing workflow frequently result in resistance and requests for
customization, which cannot be achieved without an increase in the implementation effort.
Subject matter expert (SME) involvement during solution implementation is the most commonly
unanticipated bottleneck in project delivery. The time commitment required from SMEs is typically two to
three times higher than originally estimated.

Differentiating Questions
1. How many third-party service providers have you certified in implementing
your product? Would you be comfortable if we talk to some of them
independently?
2. What percentage of your revenue comes from services rather than licensing?
3. If we need to customize, how do you license for development and test
environments?
4. What is the average implementation cost at your different licensing tiers?

Third-party service providers with experience implementing the solution can provide a more honest,
impartial assessment of its strengths and weaknesses, since they typically work with multiple vendors.
If the vendors business model relies heavily on services revenues, it could indicate that the configuration
and integration of the solution is highly complex. It also gives the vendor an incentive to prolong the
implementation by offering customizations.
Many vendors have very strict licensing terms that lead to exploding costs anytime that a client needs
to do customization.

Integration
1. Based on your clients experience, what other standard enterprise systems
does your product need to connect to perform as designed?
2. Which standard enterprise systems need to draw from the data processed
through by your solution?
3. What are the most commonly missed areas of integration for customers who
want to use it like us? For the kinds of uses we are thinking of in the future?
Customization
1. How much customization have your other clients with uses like ours had to
do?
2. Which types of IT SMEs will we need to commit to implementation?
3. How many business SMEs will we need to commit to implementation?
Overall Grade AF:


IT Practice
Training
1. Will you provide initial training on using your product to our staff?
2. Will training focus on an overview of functionalities or be tailored by role?
3. Is there a cap on the type and number of training sessions or support calls included in the contract?
Security
1. Does your product store non-public information about our employees or customers?
2. Would you be open to a third-party vulnerability assessment before we sign an agreement?
3. Would you be open to ongoing third-party vulnerability assessments?
4. In an event of a breach, what would be the most recent version of critical files you would be able to provide?
5. Would you be open to an audit by our internal IT department on your disaster recovery and business
continuity plans?
6. Would you be willing to make adjustments to your current disaster recovery and business continuity plans
based on our IT departments recommendations?

3. Buyers Guide: Quality of Vendor Partnership
1. What specific skills and expertise does this vendor provide that we lack
within our Corporate IT organization?
2. How essential is the business problem that this vendor is helping us solve
to the core operations of our business?
3. What is the minimal level of vendor relationship quality that we are willing
to accept?
4. How do we define a partnership deal breaker?

The probability of a vendor lock-ina situation in which our business becomes dependent on a vendoris
higher if vendor skills and expertise are hard to find inside (or hire into) the internal IT department.
In their efforts to grow their own margins, vendors sometimes lower the quality of service they provide
if their product is key to a clients core business operations.
Inexperienced technology buyers often buy third-party solutions without thinking through what would
cause them to want to terminate an agreement. Defining the deal breakers in advance helps establish
consensus for when to shop for another vendor. It also helps communicate with the vendor what aspects
of the service are most important.

1. How do you measure compliance with your own protocols for notifying your
customers about extraordinary events? (e.g., security events or business disruptions)
2. How do you measure customer satisfaction? Who is the customer?
(End-users, the purchaser, IT?)
3. Are these metrics included in the performance evaluation of your staff?
4. Have you defined standards for issue resolution? Can you share those
standards and your performance against them?

Most vendor products require at least a minimal amount of support. Unavailability of that support at a
critical time (e.g., security events, major disruptions) may significantly impact our business.
Including customer satisfaction metrics in staff performance evaluations ensures that vendor employees
are more likely to provide the desired level of support regardless of their level in the organization.
It is hard to anticipate potential problems with using the vendor solution, but reviewing standard issue
resolution procedures can serve as a proxy for understanding: a) Potential areas of concern,
b) Expected level of service if those concerns materialize.

Service=Level Agreements (SLA)
1. Are your SLAs calculated based on averages over a period of time or on a
single unit of services?
2. Are there exclusions from meeting the defined SLA levels?
Note: SLAs define the availability of the vendors product and the response
time you can expect from the vendor if something goes wrong with the
product or if you have a question.
3. Would you be open to a trail period during which our IT department can
assess your ability to meet SLAs?
Professional and Cooperative Behavior
1. What incentives do you provide your staff to exhibit high levels of customer service?
2. Do you measure and analyze employee satisfaction?
3. What is your companys standard for professional and cooperative behavior?
Effective Communication
1. What is the standard communication process between your company and clients regarding important
issues?
2. What is your internal standard for notifying clients about extraordinary events (e.g., security breaches)?
Proactive Support and Responsiveness
1. What time zones does your staff reside in?
2. Do you monitor over or underutilization of your services to identify and diagnose potential problems?
End-User Support
1. What type of post-implementation training will you provide?
2. Will you provide ongoing support?
Overall Grade AF:


IT Practice
Architecture
Management
81
Architecture
Management
82

4. Buyers Guide: Financial Cost
1. Have we figured out an internal break-even ROI point or a set of assumptions
under which this investment is no longer a good idea? Have we explored how
likely are those assumptions to come true?
2. What would be the non-financial impact of vendor insolvency on our
business? Do we have a contingency plan in case this happens?
3. How comfortable are we with a long-term partnership with this vendor
in which the terms of our agreement cannot be changed?
4. Is this vendor also selling products to our IT organization, which may be able
to provide us with discounts or references?

Many business leaders report that in hindsight, they would have made more explicit assumptions about
the expected ROI from a vendor solution and that they would have altered some of their financial cost
decisions if the assumptions were fully fleshed out.
Like any business, SaaS vendorsboth big and smallcould run into financial trouble. Regardless
of whether the turmoil experienced is temporary or permanent, it will have an impact on its clients.
Vendor lock-ina situation in which our business becomes critically dependent on a vendormay
not be favorable if the partnership is considered a short-term fix to a long-term problem.

1. Based on our current level of need, are we considered a growth account
or a maintain account?
2. How have your prices changed in the last two years? What is likely to happen
to your prices in the next two years?
3. Do you actively scan for areas of under or overutilization to propose contract
modifications based on individual client usage?

Frequently, vendors provide only a partial view into the anticipated future costs of doing business with
them. To avoid surprises, contract negotiation should focus on fully understanding initial costs of entering
into agreement with the vendor, as well as projected costs, their drivers, and their likely direction.

Price Competitiveness
1. What is your unit of measure for the product and service? (e.g., per employee,
per device, per user account, per transaction, enterprise-wide license?
2. What is the billing frequency? E.g., per month, per quarter, per year)?
3. On average, by how much does a customers total spend with you rise
as he or she moves from lower tiers to higher tiers?
4. Are there additional charges for exceeding various parameters, such as storage?
Cost Flexibility
1. How much flexibility will we have to increase or decrease our level
of consumption of your product and services?
2. Are there any contractual minimum payments, such as a minimum monthly
or annual payments?
3. Are there any termination charges?
4. Is there a minimum length of service for a particular unit of measure
(e.g., a user must be active for at least one year?)
Overall Grade AF:

IT Practice
Source of Vendor Profits

1. What is your margin on goods sold versus services sold?
2. How much does an average client spend on professional services with your company?
3. Based on our need and environment, how much custom implementation requiring paid support would
you recommend?
Vendor Stability
1. How long have you been in business?
2. At a high level, what is your companys strategy for the next 12 to 18 months?
BALANCE PROCESS MATURITY AND AUTOMATION
Alphas Balancing Process Maturity and Automation
Investigate Process
Analyze Process
Components
Review workflows.
Interview end users and SMEs.
Identify process components.
Determine current maturity of each process component by assessing:

Current level of automation;
Number of different workflows across the organization;
Lack of clarity about best workflow; and
Amount of change management required to automate.
Decide Whether
or Not to Automate
Select only those components that have significant process maturity,

manual intensity, and lengthy cycle times (e.g., for automation).
Yes
Define requirements for

automation of process
component.
No
Exclude from
technology solution.
Continue Monitoring Process

Consider automating as part of future capabilities consulting with the
business. Any future considerations of automation must be measured
in terms of their ROI in comparison with other enhancement and new
development requests.
Key Question
Will automating this process deliver the best ROI to the business
for the time it will require?
Optional
Create best practice guide for workflow as part of change
management efforts.
Pseudonym.

IT Practice
Architecture
Management
83
BALANCE PROCESS MATURITY AND AUTOMATION (continued)

Alphas Balancing Process Maturity and Automation (Continued)
Using Process Analytics to Inform Technology Roadmaps
Steps
1. Create an IT Business Process
Mapping (BPM) team.
Key Activities and Tools
Identify business process experts within IT.
Adopt a BPM methodology.
Select BPM tools.
Work with customers to select processes to improve.
Create ITbusiness pilot teams.
Map each process.
Use iterative development to execute process improvements.
2. Select pilot BPM projects.
Pseudonym.

IT Practice
Architecture
Management
84
1
BALANCE PROCESS MATURITY AND AUTOMATION (continued)
Alphas Balancing Process Maturity and Automation (Continued)

Using Process Analytics to Inform Technology Roadmaps (Continued)
Steps
3. Create a BPM Center of Excellence.
Create BPM governance structure.
Create a BPM training program to deepen talent bench.
Select initial projects with similar criteria to pilot projects.
Tackle increasingly complex projects as maturity deepens.
Automate mature processes.
4. Expand scope of BPM.
Use data from pilot projects to obtain customer

and management buy-in.
Pseudonym.

IT Practice
Architecture
Management
85
Architecture
Management
86
Support Service Reuse

DirectTVs Deriving Maximum Value from Existing Technical Services
Partial Root-Cause Analysis of SOA Challenges
Objective
Challenges
Subchallenges
Solutions
1
Its hard to know which data
to standardize.
Lack of consistent data

standards and definitions
Its hard to gain consensus

on standard data formats
and definitions.
Narrow down the scope of data

standardization efforts to only the data
elements used by services.
2 Create standard data definitions in the

middle layer (the canonical data model),
rather than resolving standardization
decisions across databases.
3 In addition to identifying commonalities
Improve the value

of existing technical
services (SOA).
in service usage, analyze patterns in

input and output data used by services
to simplify rationalization decisions.
Its hard to identify service

consolidation opportunities.
Too many redundant, low

ROI services
Its hard to set the right

level of service abstraction
(granularity).
Introduce composite services based

on reoccurring data and service usage
patterns.
5 Minimize disruptions in knowledge

Its hard to ensure service
reusability.

IT Practice
transfer about service usage among

design teams through modular service
training.
Support Service Reuse (continued)

DirectTVs Deriving Maximum Value from Existing Technical Services (Continued)
1. Identify Data Standardization Opportunities for Services
All data
Customer, product, account, etc.
Filter 1: Is this data used by integration services?
Yes
No
Go
Filter 2: Does the data exist

in more than one database?
Yes
No
Go
Formulate an enterprise standard

in the canonical data model and
allow provider databases to retain
local variations in definition.
Integrate data into

the canonical data model.

IT Practice
Architecture
Management
87
Architecture
Management
Support Service Reuse (Continued)

2. Resolve Key Data Inconsistencies
Type of Data
Inconsistency
1. F
ormat: Inconsistent
way of recording
identical data elements
2. Value: Inconsistent
data inputs due to poor
data quality
3. D
efinition: Inconsistent
definitions of what a
data element means

IT Practice
ExampleCustomer Data
Action
Database A
Database B
John Smith
Mr. Smith,
John
Define master data standards in the

canonical data model and resolve
inconsistencies between provider systems
through the middleware.
Database A
Database B
John Smith
John Smit
Database A
Database B
John Smith
Alpha
Company Inc.
Identify quick-wins in data quality

improvement through an analysis of data
elements most frequently evoked by
services.
Map consumer systems data definitions
to master data standards in the canonical
data model.
88

3. Maximize the Value from Existing Services
Filter 1: Service usage commonalities
Identify a group of services that perform
the same action (e.g., look up customer
profile).
Filter 2: Data input and output patterns

Identify commonalities in data inputs and
outputs passed between consumer and
provider systems.
Service Name
(Old Services)
Service Description
1. Look_up_
1. L
ook_up_
customer
customer
2. A
ccess
2. Access
Account
Account
3. customer3.2
3. customer3.2
Provides customer information

Provides customer information.
Modifies customer or account

Modifies customer or account
information
information.
4. A
ctivation
Activates access to new

products or services
5. vz3_billing
Submits customer order for

billing
Input data
Output data
Name
Retrieves customer account

Retrieves customer account.
I
I
Service Input and Output Data Elements1

Customer
Phone Customer
Payments
Address
Phone
ID
ID
I
I
Illustration only; a data element can be both an input and an output from a service.
O
O
O
O
O
O
O
O
O
O
I
I
Account
Status
1. Standardization opportunity
An area where a consolidated
service can be created
(e.g., Customer Information)
2. Flexibility needs
Areas where the use case of a
service differs from the use case
of the consolidated service

IT Practice
Architecture
Management
89
Architecture
Management

4. Identify High-Value Composite Services
Data integration patterns: Patterns in data integrated together across different services
Service usage patterns: Patterns in services used together to deliver a functionality
Requests from design teams for new composite services
Reengineered Service Orchestration Analysis

Illustrative
Elements of a Composite
Integration Service
Composite Service Example: A customer

calls the DIRECTV customer service line to
add additional channels to her subscription.
Service Name
(New Services)
Service Description
1. C
ustomer
Information
Provides customer
information
2. V
erify Product/
Service
Eligibility
Retrieves the products

and/or services a customer
is eligible to purchase
3. Update
Account
Modifies customer account

information
4. Verify Address
Confirms customer address

information
5. Process Order
Submits customer order

for billing
6. A
ctivate
Account
Activates access to new

products or services
Data Elements in the Canonical Data Model

Customer

IT Practice
Data Called by a
Consumer System
Account
Product
Service
Orders
Subscriptions
90

5. Promote Continuous Service Education
Key Questions in Integration
Process Flow
Training Tool
What Does It Provide?
Benefits
Key Elements
1. H
ow do I use integration
services?
Integration Services
Usage Guide
An introduction to the
services ecosystem
Defines rules of engagement

for using all integration
services
Common elements and features

and across all services
2. Which set of services are

available to me?
Consumer System
Usage Guide
An access agreement
into a suite of services
exposed for a specific
consumer system
Ensures alignment with

workflows supported by
theconsumer system
3. H
ow do I use a specific
service?
Service-Specific
Interface
Agreement1
A set of detailed
guidelines on how to
use a specific service
Minimizes ambiguity around

how to use a service
4. H
ow do I know the service I
used worked as intended?
Event Notification
Specification
Document2
A set of specifications
for input data,
return messages,
and configuration
information for
asynchronous services
Enables quick asynchronous

communication between
consumer and provider
systems on whether a
particular transaction
succeeded or failed
WSDL (Web Service Definition Language) and XSD (Extensible Markup Language) are also provided
along with the Service-Specific Interface Agreement but are not listed in the document itself.
Event Notification Specifications are not used for synchronous services.
A mapping of business
processes and services a
consumer system is eligible
touse
Service-specific information
such as default expiration
time, usage pattern
(synchronous, asynchronous,
fire and forget, etc).
Standards for input data,

output data, return messages,
configuration)
Notification standards and

guidelines
Required versus optional
message communications

IT Practice
Architecture
Management
91

IT Practice
Architecture
Management
92
Section 6: Designing
for Usability

IT Practice
Designing
for Usability
93
Designing
for Usability
94
Designing FOR USABILITY

Design for the End User
Develop Customer Intelligence
Identify areas to improve usability by surfacing roadblocks in knowledge

workers workflows.
Develop a deeper understanding of customers technology use, needs, and

expectations to bridge business sponsors strategic requirements with end
users functionality needs.
LexisNexiss Uncovering Unarticulated Needs95

Capture knowledge worker pain points in the form of problem statements
that correlate to the impact on productivity. Tie productivity roadblocks to a
knowledge worker role objectives to surface business transformation needs
for translation into technology design. Prioritized productivity roadblocks
undergo a rigorous solution ideation phase, which results in high-fidelity
wireframes and prototypes that become primary input into subsequent design
stages.
When to Use
To surface end-user needs and translate them into technology design
To create a technical solution design tied to end-user productivity
improvements
Essential
Reference
Specialized
Improve System Usability
Kimberly-Clarks Usability Leading Indicators98

Kimberly-Clark selects a small set of metrics designed to track end-user
experience to triage performance problem remediation; they rule out whether
business process design, system performance, or human factors are the source
of poor end-to-end performance.
When to Use
To identify causes of poor system/user performance and improve usability

IT Practice
Standard Chartereds Applications function develops a deeper understanding

of customers and the demands they place on applications through analysis of
service tickets and by soliciting ongoing feedback from end users. Standard
Chartered understands customers technology use, needs, and expectations to
bridge business sponsors strategic requirements with end users functionality
needs.
When to Use
To develop customer intelligence to increase end-user efficiency
To recommend end-user workflow and usability improvements
To bridge business sponsors strategic requirements with end users
functionality needs
Essential
Accurately isolate the cause of performance lapses due to system

performance, user behavior, or business process health.
Essential
Standard Chartereds Leveraging End-User Data to Proactively Deliver

Solutions100
Reference
Specialized
Reference
Specialized
Design for the End User

LexisNexiss Uncovering Unarticulated Needs
Problem Statement for a New Business Development Junior Executive
Illustrative
1.Direction
Minimize
3.Outcome
the number of
interruptions I have
during my work day
to free up time to
identify new opportunities
to find new clients.
Impact on
Knowledge
Worker
Productivity
2.Unit of Measure
Problem-to-Objective Mapping
Illustrative
New Business Development Junior Executive
Importance
Satisfaction
Difficulty
9.5
6.5
High
Role
Objective
1. Improve my daily work experience by extracting the most relevant information in the
shortest amount of time to work efficiently and manage time effectively.
Relevant
Problem
Statements
a. Minimize the number of interruptions I have during my work day to free up time to identify new opportunities to find new clients.
b. Increase the number of contacts I have with clients to improve my sales pipeline.
2. Widen my network of business contacts to start marketing
myself and build a book of business.
6.3
High
a. Minimize the time it takes to build and bring in a book of business to improve my performance against goal.
Anthony Ullwick, What Customers Want: Using Outcome-Driven Innovation to Create

Breakthrough Products and Services, New York: McGraw Hill, 2005.
Importance: 110
Satisfaction: 110
1Not at All Important
1Not at All Satisfied
10Very Important
10Highly Satisfied
Difficulty: High/Medium/Low

IT Practice
Designing
for Usability
95
Designing
for Usability
96
Design for the End User (CONTINUED)

LexisNexiss Uncovering Unarticulated Needs (Continued)
Knowledge Worker Objectives Map
Illustrative for a New Business Development Junior Executive
Very Important
High Difficulty
1. Improve my daily work experience by extracting the

most relevant information in the shortest amount of time
to work efficiently and manage time effectively.
Importance of the Objective
Medium Difficulty
Knowledge Worker Objectives

Identified as Knowledge
Worker Imperatives
2. Identify an interesting market

that would allow me to grow
the business by 10%.
Other Knowledge Worker

Objectives
Importance: 110
3. Widen my network of business contacts to start

marketing myself and build a book of business.
Less Important
1Not at All Important

10Very Important
Satisfaction: 110
High
Low
Satisfaction with the Current Solution(s)

IT Practice
1Not at All Satisfied

10Highly Satisfied
Design for the End User (CONTINUED)

LexisNexiss Uncovering Hidden Productivity Improvement Opportunities (Continued)
Knowledge Worker Imperative-Driven Design Process
Solution
Ideation
Process
Input
Design
Roadmap
Update
Feature
Assessment
Session (FAS)
Pre-Feature
Assessment
Session
Knowledge worker
imperatives
Voice of the knowledge
worker (e.g., interview
scripts and recordings)
Problem statements
associated with the
knowledge worker
imperatives
Knowledge
Workers
Project
Kickoff
Output
Innovation
Team
Customer
Advocate
Product
Champion
Technical
Teams
Enterprise
Architects
Domain
Architects
User-Experience
Team
Prototyping
Team
Design documents
High-fidelity wireframes
High-fidelity service
prototypes
Initial solution concepts

IT Practice
Designing
for Usability
97
Designing
for Usability
98
Improve System Usability

Kimberly-Clarks Usability Leading Indicators
Preemptive Performance Tracking
Potential Problems
Poorly Designed
Business Process
Poor System
Performance
Inefficient Use
Is performance
degradation due
to user inefficiency?
Key Questions
Is the business
process itself
inherently inefficient?
Is the system
performing
as it should?
Does the user know

how to use the
application correctly?
Is the application
too difficult to
use correctly?
Confirming Metrics
User Experience Metrics

IT Practice
Error frequency
by business process
Average end-to-end
response time
9 Number of errors per user
Time spent per screen
Number of processes
executed
10
Ratio of number of processes

completed versus aborted
Average process duration
11 Error frequency by error type
Ratio of actual completion time

versus best practice
Cumulative user sessions

by hour of day
12
Error frequency by functionality

usage
Ratio of process active

time versus idle time
Improve System Usability (continued)

Kimberly-Clarks Usability Leading Indicators (Continued)
Usability Root-Cause Analysis
Too High
Level One
If yes, then proceed
Too Low
Poorly Designed Business Processes

Is the business process efficient?
1 Error frequency by business

processes
2 Time spent per screen

3 Ratio of number of processes
completed versus aborted
4 Ratio of actual process

completion time versus
best practice
Level Two
If yes, then proceed
Poor System Performance

Is the system performing as it should?
5 Average end-to-end
response time
6 Number of processes executed
7 Average processes duration

8 Cumulative user sessions by
hour of day
Level Three
Inefficient Use
Is the application being used efficiently?
9 Number of errors per user

10 Error frequency by functionality
usage
11 Error frequency by error type

12 Ratio of process active time
versus idle time
Patterns of values (signatures) indicate

likely reason for performance lapse.

IT Practice
Designing
for Usability
99
Designing
for Usability
100
DEVELOP CUSTOMER INTELLIGENCE

Standard Chartereds Leveraging End-User Data to Proactively Deliver Solutions
1. Use Multiple Channels to Understand Customer Needs
Sponsor/PM Conversation
Process efficiency
Cost, productivity,
or revenue drivers
Strategic changes
360 View of
the Customer
Customer Survey
Relationship/
engagement
quality
Fit of existing
solutions
Understanding of
business issues

IT Practice
End-User Portal
Functionality
Usability
Workflow
Improvements
DEVELOP CUSTOMER INTELLIGENCE (continued)

Standard Chartereds Leveraging End-User Data to Proactively Deliver Solutions (Continued)
2. Recommend Workflow Improvements
Analyze Service Ticket Data to Achieve Valuable Service Outcomes
Analyze
Service
Ticket
Data
Look for
Leading
Indicators
Service
Outcome
Error Type
Error
Impact
Source
User Group Frequency
Application
functionality
Access
failure
Low
(< 5%
of users)
Missing
patch
Call center
technicians
10x/30 days
Business
process
Incorrect
report
sequencing
High
(> 25%
of users)
Poorly
mapped
process
Business
unit A line
managers
21x/30 days
User
Failed
database
query
High
(> 25%
of users)
Missing data
field and set
Market
researchers
13x/30 days
Number of errors per user group
Error frequency by business process
Enhance End-User Performance
Business Process Improvement
Identify enhancement and/or

customization opportunities
as prioritized and identified
by end users.
Review business process errors

to locate inefficiencies and identify
solutions.

IT Practice
Designing
for Usability
101
Designing
for Usability
102
DEVELOP CUSTOMER INTELLIGENCE (Continued)

3. Bridge Sponsors Strategic Needs and End-Users Requirements
1. Sponsor: Integrate
country-specific
requirements with
current payroll system.
2. Solution Delivery Team:

Deliver analysis to
sponsor.
3. Solution Delivery
Team: Provide
recommendation
based on sponsor
and end-user analysis.
4. Solution Delivery
Team: Provide
recommendation
to sponsor.
5. Business accepts
solution.

IT Practice
Portal
Payroll data only in US dollars

No foreign deduction calculations
Service Analysis
Current payroll system rules and

presentation interface do not align
with the businesss strategic needs.
Analysis
Adding data tables solves short-term need.

Additional data tables dont simplify user interface.
Adding data tables increases current system complexity
and likelihood of service failures and loss in productivity.
Recommendation
Adopt new payroll solution that includes country-specific

extensions to the core application.
DEVELOP CUSTOMER INTELLIGENCE (Continued)

Process Steps
Steps
1. Survey customers to identify

performance gaps.
Conduct a survey of executive leaders and business

sponsors to assess customer satisfaction on critical
performance criteria:
Business engagement and customer relationship
management
Ability to enhance business unit performance
Ability to meet revenue targets
Overall credibility rating
2. Develop multiple voice of

the customer mechanisms
to create a robust view
of customer needs and
priorities.
Build a web-based solution portal where employees

can submit questions, suggestions for new functionality,
and applications enhancement requests.
Make portfolio managers responsible for engaging business
sponsors in a variety of discussions around pain points,
strategic priorities, and market demands to build up
customer knowledge.

IT Practice
Designing
for Usability
103
Designing
for Usability
DEVELOP CUSTOMER INTELLIGENCE (continued)

Process Steps (Continued)
Steps
3. M
ine maintenance and support
data to proactively identify
service opportunities.
4. B
uild credibility by viewing
every customer interaction
as a service opportunity.

IT Practice
Build a retrievable storage system for incident reports

to increase their ability to reuse valuable information.
Create common, searchable data fields for service tickets
to allow for quick retrieval of information about a single
customer or a particular type of service failure.
Analyze service tickets to isolate applications performance
issues occurring from specific user interactions or to identify
trends within a single customer base.
Identify customer behaviors that generate the same
or similar service requests to uncover service
improvement opportunities.
Provide customer relationship training to all staff members.

Focus initial conversations on stabilizing and improving
current service levels (e.g., application availability and
project tracking).
With improving customer confidence, move from providing
tactical and informational updates to engaging customers
in strategic conversations.
104
Section 7: Communications
and Change Leadership

IT Practice
Communications and
Change Leadership
105
Communications and
Change Leadership
106
COMMUNICATIONS AND CHANGE LEADERSHIP

Develop Attributes of an Effective BA
Essential
Reference
Specialized
Engage and challenge business sponsors assumptions.

Potential Attributes of an Effective Business-Facing IT Professional108
Many of the attributes required in sales roles are increasingly applicable to
business-facing IT professionals.
When to Use
To develop skills and behaviors of an effective BA
Essential
Reference
Specialized
When to Use
To understand how different behaviors affect engagement outcomes
Reference
Communication strategies need to be tailored to business leaders

temperaments and posture toward project change and their degree of
influence on project outcomes.
Communication Challenges with Business Leaders114
Representative Profiles109
Like sales reps, BAs may adopt the profile of either a Challenger or a
Relationship Builder.
Essential
Establish Effective Communication with Business Leaders
Business leaders differ in their psychology, values, and assumptions about

technology, placing strains on engagement with BAs. A growing percentage
of business leaders are willing to lead in more aspects of applications
projects.
When to Use
To understand behavioral temperaments of the business sponsor
Essential
Reference
Specialized
Specialized
Deconstruction of a Compelling Teaching Pitch115

Critical Attributes of Challengers111
Typically Relationship Builders are focused on resolving tension and creating
a more collaborative, agreeable environment. On the other hand, Challengers
succeed because they can teach, tailor, and create constructive tension with
the sponsor. The Challengers success is based on the abilities to teach for
differentiation, tailor for resonance, and assert control.
Typically, organizations and individuals overemphasize the risk of being
aggressive. When developing attributes requiring asserting control, BAs must
navigate between excessive passivity and aggression.
When to Use
To develop challenger attributes to create constructive tension in business
engagement

IT Practice
A compelling teaching pitch reframes initial assumptions, showing underlying,

unanticipated problems and building confidence in ITs ability to deliver a new
solution.
When to Use
To build confidence in your ability to deliver a new solution
To build effective communication skills
Essential
Reference
Specialized
COMMUNICATIONS AND CHANGE LEADERSHIP (Continued)

Customer Outcomes Map117
Coca-Colas Building Transparency in Communications121
BAs should tailor their communication approach based on how individual

sponsors define success in their job, in terms of activities, metrics, or
direction of outcome.
Coca-Cola fosters collaboration with business partners by communicating

cost and risk information business partners need to make decisions.
When to Use
To understand business sponsors definition of success
To tailor communication approach based on sponsors context and
outcomes
Essential
Reference
Specialized
The negotiation roadmap demystifies the behaviors of highly successful

negotiators that can be applied for successful negotiations in a low-risk
environment.
When to Use
To develop effective negotiation skills
Reference
Specialized
Ciscos High-Risk Stakeholder Communication Plan120

Cisco builds holistic stakeholder profiles capturing detailed information about
stakeholder expectations and communication preferences. This information is
used to identify high-risk stakeholder segments (e.g., stakeholders with high
influence on project outcomes who actively resist project change).
When to Use
To document stakeholders expectations
Essential
Essential
Reference
Specialized
Plan Change Management Activities

Target change communications based on stakeholder priorities
Negotiation Roadmap119
Essential
When to Use
To improve conversation about business needs and options and costperformance trade-offs.
Reference
NetApps Governance Change Management Campaign122

NetApp identifies how stakeholders workflows will change and their concerns
about the new governance process. They do the following:
Address stakeholders concerns through targeted messaging of key
benefits.
Educate business executives about the initiative at governance forums and
senior staff meetings.
Create a company-level umbrella message about the governance process
change and ensures specific messages for each stakeholder align with it.
When to Use
To effectively engage in change management activities
To develop consistent messaging for change initiatives
Essential
Reference
Specialized
Specialized

IT Practice
Communications and
Change Leadership
107
Communications and
Change Leadership
108
Develop Attributes of an Effective BA

Potential Attributes of an Effective Business-Facing IT Professional
Attitudes
Skills and Behaviors
Leverages Support
Interest in Feedback
Activities
Professional Image
Explores All Options
Outcomes Focused
Knows Value Drivers
Follows Formal Processes
Discretionary Effort
Offers a Unique Perspective
Lead Generation
Tenacity
Two-Way Communication Skills
Analytical Skills
Curiosity
Can Identify Economic Drivers
Experiments with Approach
Can Pitch Strategy
Requests Assistance
Forms Good Partner Relationships

Has Advocates in Partners
Wants to Manage Company

Outcomes
Company Attachment
Can Work with Anyone
Genuine
Accessible to Partners
Passionate About Customers
Flexible

IT Practice
Good Cross-Functional
Relationships
Ability to Work
with the Team
Respects Partner Time
Strategic Agility
Manages Expectations
Knowledge
Can Explain ROI
Product Knowledge
Meeting Preparation
Industry Knowledge
Develop Attributes of an Effective BA (Continued)

Representative Profiles
The Challenger
(27% of Sample)
The Relationship Builder

(21% of Sample)
Always has a
different view
of the world
Understands the
customers business
Loves to debate
Pushes the customer
Builds strong
advocates
in customer
organization
Generous in giving
time to help others
Gets along with
everyone
The Hard Worker

(21% of Sample)
Others
(32% of Sample)
Always willing to
go the extra mile
Doesnt give
up easily
Self-motivated
Interested in
feedback and
development
n = 683 sales reps.

Note: Numbers do not equal 100% due to rounding.

IT Practice
Communications and
Change Leadership
109
Communications and
Change Leadership
110

Representative Profiles (Continued)
While individual differences exist, all respondents can be categorized in terms of their likelihood to exhibit one group
of attributes over the others.
Challenger
Knows Customer Value Drivers
Offers a Unique Perspective
Relationship Builder
Forms Good Customer

Relationships
Discretionary Effort
Can Discuss Money
Outcomes Focused
Two-Way Communication Skills
Attachment to the Company
Tenacity
Can Identify Customer Economic

Drivers
Can Work with Anyone
Project Management Skills
Genuine
Leverages Support
Preparation Before Calls
Follows Formal Sales Process
Curiosity
Interest in Feedback
Learns Everything New
Can Pitch Strategy
Product Knowledge
Accessible to Customer
Knows How Customers

Differentiate
Gives Time to Help Others
Respects the Customers Time
Good Cross-Functional
Relationships
Industry Knowledge
Can Explain ROI of the Sale
Professional Image
Motivated by Goals
Has Advocates in Customers
Can Pressure Customer
Hard Worker
Explores All Options Before

Closing
Experiments with Sales Approach
Requests Assistance
Generates Leads or Prospects
Source: Integrated Sales Executive Councils Rep Skills Diagnostic.

IT Practice
Evaluates Likelihood
of Purchase
Wants to Manage Company

Outcomes

Critical Attributes of Challengers
Challenger Builder Profile
Relationship Builder Profile
The Challenger profile focuses on building

constructive tension in interactions to push
customers out of their comfort zone.
Offers unique perspective

Has two-way communication
skills
Knows customer value drivers
Can identify economic drivers
Is comfortable discussing money
Can pressure the customer
Teaches
The Relationship Builder profile focuses on

resolving tension in interactions to make
situations more amicable and positive and
encourage collaboration.
Forms good relationships
Builds customer advocates
Tailors
Asserts
Control
Builds cross-functional
relationships
Can work with anyone
Is genuine
Is accessible to the customer
Gives time to help others
Respects the customers time
Gets
Along
with
Others
Likeable
Generous
with Time
Implication for the Applications Function

To build Challenger skills, focus on helping business-facing Applications staff teach, tailor, and assert control.

IT Practice
Communications and
Change Leadership
111
Communications and
Change Leadership
112

Critical Attributes of Challengers (Continued)
Teach: Reframe
the way business
partners view their
business and their
needs.
Tailor: Link your

capabilities to business
partners individual
goals.
Teach for
Differentiation
Tailor for
Resonance
Assert
Control
Assert Control:
Openly pursue goals
in a direct but not
aggressive way.
The New High

Performer
Questions to Consider
What should my business-facing
Applications staff teach?
Source: Integrated Sales Executive Council research.

IT Practice
How do I get my business-facing

Applications staff totailor?
How do I get my business-facing

Applications staff toassert
control?
How can I change the behavior

of business-facing Applications
staff?

Critical Attributes of Challengers (Continued)
Subverts goals to the needs

of others
Allows personal boundaries
to be breached
Uses indirect, accommodating
language
Aggressive
Assertive
Passive
Directly pursues goals

in constructive way
Defends own personal
boundaries
Uses direct language
Sales Performance Problem
Pursues goals at the expense

of professionalism
Attacks others personal
boundaries
Uses antagonistic language
Common Sales Leadership Fear
Reps are often too passive with

customers, seeking to resolve
conflict whenever possible.
Tell sales reps to be more assertive

and they may become aggressive.

IT Practice
Communications and
Change Leadership
113
Communications and
Change Leadership

Communication Challenges with Business Leaders
Characteristics
Differentiation
Personality
Views of
Technology
Investments
Likely Reaction
toEngagement
Values
Career Past

IT Practice
Personality traits account for differences in ability to communicate with others, propensity
to seek guidance and help, and ability to make decisions.
Business leaders differ in their views about how technology plays a role in their function/
company role.
Some view technology investments as critical to strategic outcomes, others as ancillary,
andstill others as irrelevant and not worth their time.
Standard engagement strategies from Applications and not received in standard ways by
all business leaders.
Some business leaders see engagement from Applications as a signal of poor performance
and become defensive, others welcome engagement, and still others avoid it all together,
adding additional barriers to Applications.
Personal and career-related values ultimately define what business leaders expect to get
from technology investments.
Some business leaders value large key accomplishments, some value maintaining a
consistent track record, and still others value flying under the radar.
Diverse backgrounds of business leaders challenges Applications to understand the
experiences and goals of countless types of individuals.
Past IT experience, tenure, level, experiences in other industries, and the like can all alter
how communication is received by business leaders about technology.
114

(Continued)
Deconstruction of a Compelling Teaching Pitch
Positive
Emotometer: Level of Customer Excitement
then building back the

customers confidence
in a new solution.
Teaching follows boot

camp theory of shocking
the customer with the
unknown
2. Reframe
First reframing
of unrecognized
problem, need, or
assumption
Neutral
1. Warmer
Building credibility
by reading
their mind and
demonstrating
empathy
breaking down the problem

behind the unknown
3. Rational
Drowning
Gradual
intensification of
the problem, both
in degree and
closeness to the
customer
4. Emotional
Impact
Description of
the psychological
features of the
problem, or
presence in the
individuals workflow,
humanizing the
problem
5. Value
Proposition
A New Way
Delivery of a new
framework for
addressing the
problem; implicitly
tied to the supplier
value proposition
6. Our
Solution and
Implementation
Map
Map of supplier
services or
solutions linked
back to key
teaching points;
highlighted path
to implementation
Negative
Intrigued
Drowning
Involved
Relieved
Customer State

IT Practice
Communications and
Change Leadership
115
Communications and
Change Leadership
116

(Continued)
Teaching Dos and Donts
DONT
DO
Open with the breadth of your

product portfolio and capabilities.
Open with a focus on the customer

and their issues.
Discuss how long your company

hasbeen in the marketplace.
Reframe customers understanding

of their world.
Focus on features and benefits.
Make the sale personal and provide

value to that individual.
Lead with your unique strengths.

IT Practice
Lead to your unique strengths.

(Continued)
Customer Outcomes Map
An IT project has attributes in
the areas of risk, benefits, and
effort required from the business.
Consumer Trade-Offs
Business Leader Trade-Offs
Component Trade-Offs
Features
Risks
Quality
Benefits
Price
Business
Effort
Required
Regulatory Compliance Risk

Business Continuity Risk
Information Security Risk
Hitting Cost and Scope Target

Speed to Market
Direct Benefits Realization
High Data Quality
Total Percentage of Resources

Required
SME Time

IT Practice
Communications and
Change Leadership
117
Communications and
Change Leadership
118

(Continued)
Concept Definition
Customer Outcomes
What an individual customer
is trying to achievehow they
would define success in their job
Activity or responsibility
in need of improvement

IT Practice
Metric used to
measure success
Direction and magnitude

of change necessary

(Continued)
Negotiation Roadmap
Acknowledge
and Defer
Promise closure andseek

permission to have a different
conversation.
Deepen
and Broaden
Expand potential solution

components by surfacing areas
of additional value.
Explore
and Compare
Prioritize solution components

by estimating their relative value
to the customer.
Concede
According to Plan1
Create plan and exchange value

instead of giving it away.
Concede according to plan is a principle that can be applied at any point during the negotiation conversation.
Source: Sales Executive Council research.

IT Practice
Communications and
Change Leadership
119
Communications and
Change Leadership
120

(Continued)
Ciscos High-Risk Stakeholder Communication Plan
Illustrative
Type of stakeholder drives
the nature of communication
plan and the degree of
customization required.
Customized project messages are developed and

cataloged in advance. Key messages include the following:
Elevator Speech
Whats in It for Me?
Change Posture Pitch
Similarly themed messages are

tailored for audience seniority,
level of detail required, and
degree of change resistance.
Stakeholder Segment
Communications Details
Key Message: Whats in It for Me?
High Influence,
Resistant Posture
Target Audience
Senior Consultants, Operations; Operations Back Office Personnel
We recognize the current process

for submitting expense reports
is time-intensive, and turnaround
time is slow. The new system for
submitting expenses will require
less time for report submission, is
more accurate, and will expedite
your reimbursement turnaround
time.
Resistant
Low
Influential
Neutral
Make or Break
Supportive
Impacted
Change Posture
Communication Goal
Closely manage expectations; improve change posture.
Medium
High
Degree of Influence
Level of Detail
High-level budget and schedule communication; detailed
functionality communication
Threats (Real or Perceived)
Delayed rollout
Preferred Mode
Trigger-based e-mail
High Influence,
Supportive Posture
Target Audience
Executive Sponsor; Project Sponsor
Resistant
Low
Influential
Neutral
Make or Break
Supportive
Impacted
Change Posture
Communication Goal
Closely manage expectations; maintain change posture
Medium
High
Degree of Influence
Level of Detail
High-level budget and schedule communication; medium-level
vendor performance communication
Threats (Real or Perceived)
Inadequate user training
Preferred Mode
Weekly status updates; trigger-based phone call

IT Practice
The financial expense system

upgrade will help us achieve
three major goals. It will enhance
our financial tracking capability
for better budget control. The
upgrade will bring us up to
compliance standards for the
next two years. And the more
efficient employee submission
process will offer productivity
gains.
Establish Effective Communication with Business

Leaders (Continued)
Coca-Colas Building Transparency in Communications
Information
System Change
Management
CostBenefit
Analysis
Interdependency
Risk
Capability
Investment
Prioritization
A Transparency Deficit
IT plans system changes based on

its own time schedule, without full
visibility of the impact on business
processes.
IT makes assumptions about the
businesss cost tolerance and narrows
options accordingly.
IT acts as an intake for business

demand, managing dependency
risk as an internal IT matter.
IT responds to all breakdowns

according to SLAs.
IT often underappreciates or is unaware

of the decision-making relevance to
business partners of critical pieces of
information.
Clarifying the Facts
Ideal timing for systems changes

is coordinated with business and
determined by capacity to absorb
change.
IT presents solution options and
lifecycle costs so that business can
make the appropriate trade-offs
between cost and performance.
IT factors dependency risks into
the business case for investment,
giving business partners visibility on
downstream and upstream impact.
IT prioritizes its response to service
disruptions according to business
context and criticality.
IT is proactive in sharing the inputs

that business partners require to
make decisions affecting business
performance with full knowledge
of cost, risk, and available options.

IT Practice
Communications and
Change Leadership
121
Communications and
Change Leadership
122
Plan Change Management Activities

NetApps Governance Change Management Campaign
Stakeholder
Group
Change in Stakeholder Workflow
Senior
Management
Business
Executives
IT Executives
For the first time, the right

information will be visible up to the
CEO level.
Need to be more collaborative with

IT and Finance in planning
Need to align with the new

governance models
Only approved projects will

get done
Share accountability for ensuring

rigorous portfolio prioritization.
Potential Stakeholder
Concerns
Processes may not mature

fast enough and stunt the
companys growth.
IT may not adequately

support the business.
May create more red tape

and reduce responsiveness
Resistance to adoption
Key Benefits Messaging
Better visibility on investments and

returns
Highest priority projects get the

most attention
Increased alignment of investments

to functional strategies
Higher thresholds of investments

at the cross-functional council level
approved by business units
Transformation of PMO from a

policing to an enabling organization
Investments better grouped and

easier to manage
Account
Managers
Need to own the planning process

and the transition to project delivery
More bureaucracy that

slows down work
Fewer fire drills regarding portfolio

and annual planning
Project
Managers
Update costbenefit analysis

template at every project stage gate.
More process steps to

comply with
Easier to communicate with business

partners about projects due to
consistent processes
Process
Owners
Process owner approval no longer

required in project selection due to
streamlined oversight
Lower involvement in
decision making
Visibility into project pipeline and

notification of changes
when they occur
Anticipate potential pushback against the new process

by considering each stakeholders concerns and tailors
change management messaging accordingly.

IT Practice
Plan Change Management Activities (Continued)

NetApps Change Management Campaign Plan (Continued)
Communication
Type
Weekly E-Mails
Capability
Training
Content
Audience
Audience Time
Commitment
10 minutes
Provide context for changes, updates, and action items.
Provide visibility on upcoming events.
End Users and

Business Leaders
Provide training on using new governance and cost

tracking/costbenefit analysis capabilities.
Early Adopters
and Trainers
25 hours
Provide an overview and set context for rollout

capabilities.
End Users and

Business Leaders
12 hours
20+ Phase 1
End Users in 1
Location
3 hours
23 hours
Webinar
Brown Bags
Provide an overview of the complete end-to-end process.
Walk through the project lifecycle and finance process.
Provide opportunity to ask questions and hear from others.
Show how to complete the costbenefit analysis template.
Answer questions and provide any additional guidance.
20+ Phase 1
End Users in 1
Location
Provide an overview of project lifecycle and change order

go-live elements.
End Users and

Business Leaders
2 hours
Assess end-user understanding and concerns.
End Users
30 minutes
Focus Groups
Identify adoption risk areas.
68 Selected
SMEs per
Location
1 hour
Roadshows
Provide update on status.
End Users
23 hours
Share results of adoption evaluation.
Gain input, field questions related to Q1 rollout and future.
One-on-One
Working
Sessions
Webinar
Adoption
Survey

IT Practice
Communications and
Change Leadership
123
Communications and
Change Leadership

IT Practice
124
Section 8: Business
Relationship Management

IT Practice
Business Relationship
Management
125
Management
126
BUSINESS RELATIONSHIP MANAGEMENT

Build an Engagement Strategy127
Help Sponsors See Risk and Value Trade-Offs136
Tailor engagement to business leaders preferences for risk, benefit, and

effort in IT projects.
Clarify risk and value trade-offs.
Business executives fall into four temperaments based on their preferences

and trade-offs for risk, return, and effort in Applications projects.
CareFusions Clarifying Risk and Value Trade-Offs
These pages outline the types of business leaders by temperament and the
defining characteristics of each type.
When to Use
To understand business leaders preferences for project risk and return effort
Essential
Reference
Specialized
Apply CareFusions simple framework to help business leaders visualize risk

and value trade-offs. Such a tool is part of the education/consultation for
business leaders who want to take a more active leadership role in IT projects.
When to Use
To evaluate business leaders risk and value preferences
Essential
Reference
Specialized
Understand Business Sponsors Temperaments135
Track Changing Business Priorities137
Four elementssensitivity to benefits, aversion to risk, desire for control,

and measures of successdefine a unique business leader temperament.
Attain an enterprise wide view of changing business priorities.
These pages highlight a strategic guide to identifying business leader

temperaments and key probing questions to identify a business leaders
profile.
When to Use
To tailor communication approach based on sponsors profile
Essential

IT Practice
Reference
Specialized
CareFusions Business Trends Insight Map

Use CareFusions insight map approach to capture trends across business
leaders that are valuable to Applications strategic planning and demand
management.
When to Use
To create an enterprise-wide view of changing business priorities
Essential
Reference
Specialized
BUILD AN ENGAGEMENT STRATEGY

Four Distinct Dimensions Where Business Executive Temperaments Think and Act Differently
The importance of three dimensions
desire for control, aversion to risk,
and lure of returnseach defines
how individuals measure success.
Lure of Returns
The strength of the belief that ones
self-management of a project is
necessary to capture returns
Aversion to Risk
How willing a person is to take
onincreased risk in self-managing
aproject
Each temperament displays

a distinct behavior on each
of these dimensions, with
each having a unique profile
based on these dimensions.
Preferences
along
these three
dimensions
drive success
measures.
Success Measures
How a person views and
measures past successes
and defines success for
afuture project
Desire for Control

How important self-managing
ITprojects is to an individual

IT Practice
Management
127
Management
128
BUILD AN ENGAGEMENT STRATEGY (continued)

Archetypes of Business Leaders by Temperament
Business leaders with rational risk/
reward approaches to self-managed
solutions who want to work with
Applications in a new way
The
Opportunists
The
Entrepreneurs
51%
23%
The
Abdicators
The
Cowboys
11%
15%
Low
Willingness to Self-Manage Solution
High
n = 181 business leaders.
Business Leader (Self-)Management of Solutions Delivery: Business takes primary responsibility

for performing or managing solutions delivery activities traditionally performed by Corporate
IT (e.g., selecting and procuring tools, vendor selection, project management, vendor
management).
Source: AEC 2011 Survey of Business Executives, May 2011.
IT Practice

Business Executives Fall into Four Temperaments Based on Their Preferences and Trade-Offs for Risk, Return, and Effort in Applications Projects
Low
Openness
to Persuasion
High
The Abdicators (11% of Sample)
The Opportunists (51% of Sample)
They want to do what they do and think IT should do IT.
Reformed Abdicators looking for opportunities to do it

themselves
Psychographics
Avoiding management of IT projects at all costs

Unswayed by the lure of high project returns
Low
Top Concern
Can be lured by high returns to self-manage projects

Avoiding risky IT projects at all costs
Top Concern
Want to protect their time above all else
Demographics
Psychographics
Most concerned about getting the full scope of what they want
Demographics
Typically have 5 to 15 years of work experience
Typically have 5 to 15 years of work experience
Desire
for Control
The Cowboys (15% of Sample)
The Entrepreneurs (23% of Sample)
See applications solutions as critical and need to control them;

impatient
Can look like Cowboys but have more rational desire to control
projects; want to hit home runs and are willing to take risks to
do it
Psychographics
Psychographics
Want to self-manage IT projects at all costs

Insensitive to risk
Top Concern
Speed to market most important motivator
Demographics
Typically have 16 to 25 years of experience
Will do it themselves for higher returns, even if taking on risk

Will do what it takes to attain business outcomes
Top Concern
High
Most concerned about achieving business case/outcomes
Demographics
Typically have 16 to 25 years of experience

IT Practice
Management
129
Management

Engaging the Abdicators
The Abdicators
Sensitivity to Returns
Id rather stick to my day job. Im sure IT can make the project more successful than I can.
Aversion to Risk
Technology is your job. I break computers just by looking at them.
Success Measures
If I turn on my computer, it works and its easy to usethats a success.
Driver: Abdicators only want to focus on their

domain of expertise andare uninterested in it
projects.
Toughest ScenarioTraditional Engagement

Practical Example: You are having difficulty in
securing business leaders input on an ITled project
where you need active business sponsorship.
Challenger Response
Teach
Tie Engagement to
Regulatory or Strategic
Risks: Give examples of how
the Abdicators personal
engagement will lower risks on
corporate-level issues larger
than the project and closer to
his or her daily concerns.

IT Practice
Tailor
Tie Project Success to the

Success of Their Daily Work:
Abdicators want to focus
on their domain only; tie
engagement to project success
and how that will improve their
ability to work.
Assert Control
Use Their Time Efficiently:

Explain what you will do to
respect their time and use it
efficiently.
130

Engaging the Opportunists
The Opportunists
We think we can get what we want by doing this ourselves, but I wanted to consult with you to make sure.
Aversion to Risk
I really want to make sure I first have a good handle on the risks I may encounter with this project.
Success Measures
Im proud of my track record. If things go smoothly and I learned something, it was a success.
Driver: Opportunists overestimate the risks

or underestimate the possible returns
from self-management.
Toughest Scenario: Bolstering Their Confidence

Practical ExampleConcerned with potential risks, a
business executive is in danger of missing an opportunity
to obtain new capabilities because Applications resources
are not available in a timely way to support the project.
Challenger Response
Teach
Have Concrete Examples: Explain

how risks have been managed in
the past.
Explain the Impact of Their

Involvement: Speak about how
self-management increases the
likelihood of achieving the scope
or speed to market they desire.
Tailor
Assert Control
Plan the Main Pain Points: Lay

out a concrete support plan up
front, demonstrating how they
can count on Applications if
problems arise.
Be Specific: Understand exactly
what they want from a solution,
and tie self-management directly
to achievement of those goals.
Provide a Coach: Access to

personal support will reassure
them.
Address Alternatives: Make

the alternative (Applicationsmanaged projects) less desirable
by playing up time delay and
increased risk of missing business
case or of not achieving scope.

IT Practice
Management
131
Management

Engaging the Entrepreneurs
The Entrepreneurs
There is a real opportunity here, and we need to capture it while we can.
Aversion to Risk
I understand theres risk if we do this, but I can live with that.
Success Measures
Ill never forget that big contract we won back in 95...
Driver: Entrepreneurs underappreciate the risks

associated with self-management or overestimate
the impact on returns.
Toughest Scenario: Pulling Them Back from the Ledge

Practical ExampleA business leader is attempting to
participate aggressively in a high-return project but is
blind or indifferent to enterprise risk.
Challenger Response
Teach
Introduce Strategic Risks: Tie

the impact of strategic risk,
such as customer information
loss or brand damage, directly
to Entrepreneurs expressed
business objectives.
Make Use of History: Use
concrete examples of past
situations or projects where
similar risks have caused project
failure.

IT Practice
Tailor
Amplify Risks: Make expected

returns seem less than expected
risks from self-management.
Assert Control
Focus on Achieving the Business

Case: This is Entrepreneurs
greatest concern. Discuss how
they need Applications help to
reach that goal.
132

Engaging the Cowboys
The Cowboys
We cant wait for IT. We need to move on this now.
Aversion to Risk
I dont need any help in managing this project. I have all the people and resources I need.
Success Measures
People didnt think we could do it, but we pulled it off.
Driver: Cowboys distrust Applications ability

to meet their needs.
Toughest Scenario: Reigning in Risk

Practical ExampleA business leader is convinced
that a vendor product is the key to quickly solving a
significant business problem and wants it delivered
regardless of risk or cost.
Challenger Response
Teach
Correct the Past: Acknowledge

any past failures, if they exist,
andexplain what steps have
been taken to improve.
Tailor
Assert Control
Diminish Speed Expectations:

Tie risks and complexities of
a go it alone approach to
schedule and speed-to-market
impacts.
Infiltrate the Team: Find a key

lieutenant and win him or her
over tohelpmake your case.
Govern: If all else fails, govern

by going to a higher authority
and explaining what is at risk.

IT Practice
Management
133
Management
134

The Abdicators
The Opportunists
You probably are dealing with an Abdicator if
You probably are dealing with an Opportunist if
They strongly defer to you as the experts and expect you to supply all the
initiative and answers.
Toughest Scenario
It is difficult to engage them on a traditionally run project.
Do
Use their time efficiently.
Tie their effort to high-risk avoidance.
Tap into their concerns about regulatory compliance.
Beware of
Confusing them with the Opportunists; they are not very motivated by returns
and cannot be persuaded to self-manage.
They emphasize how smoothly past successes went and show pride in meeting
expectations.
Toughest Scenario
They are scared of risks when Applications does not have resources to pursue
their opportunity.
Do
Address their specific fears, offering concrete steps you or they can take.
Understand exactly what they expect from the solution.
Address how self-management raises the odds of achieving specific objectives.
Beware of
Confusing them with the Abdicators; their reluctance comes from concerns about
risk, not unwillingness to self-manage.
The Cowboys
The Entrepreneurs
You probably are dealing with a Cowboy if
You probably are dealing with an Entrepreneur if
You do not know what they are doing. They talk evasively/vaguely about their
initiatives.
Toughest Scenario
They are putting the enterprise at risk and simply will not listen.
They measure past success mostly by the size of the outcome.
Toughest Scenario
They gamble with enterprise risks to chase high returns.
Do
Find their key lieutenant and win him or her over. Try to win over the Cowboys
team.
If all else fails, govern. Go to a higher authority and explain what is at risk.
Do
Amplify their perception of risks they have expressed concern about.
Introduce new strategic risks to them, e.g., loss of customer information, direct
financial loss, and brand impact.
Connect risks concretely to not achieving the business case.
Beware of
Confusing them with the Entrepreneur; their eagerness is fueled by a desire
tocontrol, and they will not listen to Applications.
Beware of
Confusing them with the Cowboys; Entrepreneurs actually can be reasoned with
and persuaded.

IT Practice
Understand Business Sponsors Temperaments

Business Leader Discussion Guide
Decision Factors
Success Measures
Control
Framing Language
Discovery Questions
I typically ask people four things to

make sure we use our resources in the
way theyll most benefit from. One is
to understand the background and
experiences theyre bringing to the table.
Its likely a lot.
Second, I need to understand your

thinking about how youd like to finish
the project from here, and how youd
prefer to be working with us and with
your vendors.
Benefits
Third, I need to understand what your

vision is for this project to help me adopt
your views of the benefits andwork with
you to get to the outcomes you envision.
Risk
Fourth, I need to understand in your own

words what your perceptions of the risks
here are. I want to know how we can best
complement your skills and experiences
here.
What to Listen For
What is the greatest success so far in your career?

How did that project come about for you?
Why was it important to the company?
What was the benefit to you?
Was there a point during the project when the risks
started to seem high to you?
You are trying to understand how they

measure success and what motivates them
to get involved. There is an opportunity
here to get them to talk about how theyve
viewed or handled trade-offs in the past, in
asubject area that is comfortable for them.
Where are you in the project lifecycle?

In your ideal scenario, how much support would you
likefrom us on this?
Do you feel prepared for conversations with IT vendors?
What worries you about them?
I have to check on our resources to support you right
now. Would you be willing to delay this project to wait
for resources to come free? (If so, for how long?)
You are seeing how impatient or passive

they are, how much they worry about things
they dont know, and what their first instinct
is about ceding control.
Why is this something youve identified as a priority?

Whose idea was this and why are you working on it?
What does the company (or your group) expect to
getout of the project?
What do you hope to get out of the project?
You are looking for the amount of thought

theyve put into understanding potential
benefits the degree of excitement they have
about the benefits, and how attached they
are to a vision for what the solution and
outcome should be.
Have you done something like this before?

What risks are most worrying you?
Whats at stake for you on this project?
Whats the impact on the project if one of the risks
youworry about comes to pass?
Do you like to figure things out as you go along
or plan up front?
You are trying not only to gauge what risks

they perceive, but how they perceive the
magnitude of risk and how they weigh the
risks against potential benefits personally
and for the company.

IT Practice
Management
135
Management
136
Help Sponsors See Risk and Value Trade-Offs

CareFusions Clarifying Risk and Value Trade-Offs
Illustrative
1. Strategic Risk to the Company
Loss of sensitive company information
Brand or reputation damage
Direct financial loss
Constraints of a Sample Solution
High
4. Effort
IT and business fulltime equivalent required
for implementation and
maintenance
Business subject matter
expert time commitment
Estimated amount
of customization
Estimated amount
of integration
Low
High
High
Low
High
3. Risk to the Project

Operational stability (e.g., downtime)
Vendor financial stability
Percentage of service-level
agreements (SLAs) met
Effectiveness of vendor disaster
recovery plan
IT Practice
2. Business Outcome Attainment Risk

Likelihood that key functionality is
missing or fails to work as intended
Sensitivity to schedule delays
Sensitivity to budget overruns
Risk to productivity or revenue
improvements
Track Changing Business Priorities

CareFusions Business Trends Insight Map
Illustrative
Customer
Data
Management
Customer
Data
Management
Supply Chain
Management
Customer
Data
Management
Strategic
Sourcing
Research and
Development
Customer
Data
Management
Contract
Management
Strategic
Sourcing
Strategic
Sourcing
Strategic
Sourcing
Medical
Devices
Finance
Research and
Development
Strategic
Sourcing
Sales and
Marketing
Consider an enterprise project.

Assess the business case
for standardization.
Revise skills forecasts.
Customer
Data
Management
Supply Chain
Management
Customer
Data
Management
Potential Actions for Applications
3. Experimentation with a Given Capability
2. Major Changes Within a Business Unit
1. Surge in a Capabilitys Importance
Customer
Data
Management
Strategic
Sourcing
Customer
Data
Management
Customer
Data
Management
Contract
Management
Strategic
Sourcing
Strategic
Sourcing
Strategic
Sourcing
Medical
Devices
Finance
Research and
Development
Sales and
Marketing
Revise SLAs for the business unit.
Revisit investment levels.
Supply Chain
Management
Reassign staff to project and re-scope

job descriptions.
Customer
Data
Management
Strategic
Sourcing
Sales and
Marketing
Customer
Data
Management
Customer
Data
Management
Contract
Management
Strategic
Sourcing
Strategic
Sourcing
Medical
Devices
Finance
Investigate if there is an unarticulated

need not addressed by existing solutions.
Understand business drivers
of experimentation.
Legend
Experimentation with
a business capability
indicates its importance
is rising.
Experimentation with
a business capability
indicates its importance
isdiminishing.
The direction of
importance of
experimentation with
abusiness capability
is uncertain.

IT Practice
Management
137
Management

IT Practice
138
Section 9: Design Team

Relationship Management

IT Practice
Design Team
Relationship
Management
139
Design Team
Relationship
Management
140
Design Team Relationship Management

Drive Team Collaboration and Engagement
Periodically assess the key behaviors and perceptions that drive virtual and
Agile team effectiveness to continually improve team performance.
Volvos Virtual Team Effectiveness Assessment141
Rather than focus exclusively on collaboration tool offerings, Volvo applies
NetAges framework to measure specific attributes of effective team
behavior.
When to Use
To understand attributes of effective team behavior
To effectively establish collaboration across team members
Essential
Reference
Specialized
Standard & Poors Common Delivery Framework for Agile

Development142
S&Ps framework standardizes governance, management, and engineering
for stakeholder roles, processes, and artifacts.
When to Use
To synchronize dependencies between roles, processes, and artifacts
on a distributed Agile team
Essential

IT Practice
Reference
Specialized
Intergraphs Agile Cultural Change Management143

Intergraph uses the pulse survey to understand each teams reaction to the
new methodology.
When to Use
To understand teams perception of change
Essential
Reference
Specialized
Drive Team Collaboration and Engagement

Volvos Virtual Team Effectiveness Assessment
1
Strongly
Disagree
Somewhat
Agree
Strongly
Agree
Teams fall into one of four maturity

levels based on their score:
Goals: How Aligned Is This Teams Understanding of Goals, Actions, and Expected Results?
Cooperative Goals
Interdependent Tasks
Concrete Results
Everyone has the same picture of overall purpose.

Team discusses, agrees, and reviews clear, simple goals.
Chaos
(132)No shared understanding
of objectives or contributions of
individual team members
Everyone follows the same process for doing similar work.

Team looks for ways to interconnect and improve work processes.
Everyone understands the deliverables.
Team develops and reviews measures and milestones for deliverables.
Operational Consensus
(3354)Focused on methods
of work and timelines
Links: How Comfortable Is the Team with Communicating Internally?

Multiple Media
Boundary-Crossing
Interactions
Trusting Relationships
A variety of media is available and accessible.

Team uses collaboration tools consistently and creatively.
Team Alignment
(5587)Development of team
relationships to overcome
organizational boundaries
Team has collaboratively established operating agreements that are actively applied.
Team actively implements strategy for engagement across organization boundaries.
Team has high level of trust.
Team members build social capital through multiple connections.
Shared Accountability
(88120)Shared leadership
for achieving team objectives
Time: How Clear Are Project Timelines and Milestones?

Common Calendar
Interrelated Projects
Awareness of Phase
Team has clear milestones and schedules of dates.

People are aware of ongoing key team dates and cultural calendar.
Task timelines are collaboratively established.
Team adapts to rapidly changing conditions.
Team has clear view of its lifecycle and current phase.
People discuss team processes and suggestions for improvements.
People: How Familiar Is the Team with Roles and Responsibilities?

Independent Members
Shared Leadership
Integrated Levels
People have the freedom and flexibility to do their work.

The team continuously clarifies roles, responsibilities, and competencies needed.
Leadership is widely distributed and shifts as needed.
Individuals are encouraged to lead and to follow as appropriate.
Key system interdependencies are clearly articulated (looking up, down, and across boundaries).
People are encouraged to talk across levels.

IT Practice
Design Team
Relationship
Management
141
Design Team
Relationship
Management
DRIVE TEAM COLLABORATION AND ENGAGEMENT (CONTINUED)

Standard & Poors Common Delivery Framework for Agile Development
1
Specifies expectations for governance and management:

people, process, and documentation
GOVERNANCE
Steering and Reporting
OPPORTUNITY
(Assessment)
What is the
business problem
or opportunity?
Business Sponsor
Project Proposer/Champion
Tech Management
Business Project Manager
MANAGEMENT
Planning and Evaluation
Objective
Get a project
funded.
Get a project
scheduled.
Opportunity Phase
Summary Meeting
Rapid Response Team
Project Proposal
Funding Memo
Project PlanLevel 0
Opportunity Phase
Summary/Sign-Off
ENGINEERING
Define, Build, and Test
Project Proposer
Business Analyst
Subject Matter Expert
ArchitectsEnterprise,
Application, Data,
Data Services
Business Problem and

Needs Analysis
Perform High-Level
Risk Analysis
Scope Analysis
Project Planning
Begin RFP Process
High-Level Technical
Feasibility Analysis
Level 0 Estimate (+/-200%)
VisionInitial
Project Proposal
VisionInitial
ScopeHigh Level, Initial
Project Proposal
Risk ProfileInitial
Request for Proposal (RFP)
Timebox
Synchronization Sprint
Defines the documentation

options the team should be
considering at each phase
Synchronization Planning

IT Practice
Synchronization Interface
Specification
Creates a critical
synchronization phase
to ensure functionality
is delegated in a way that
ensures usable software
when brought together
Ensures the
business context
will be captured
and cascaded to
all team members
142
DRIVE TEAM COLLABORATION AND ENGAGEMENT (CONTINUED)

Intergraphs Agile Cultural Change Management
Agile Adoption Pulse Survey
Much
Better
Better
Same
Worse
Much
Worse
Strongly
Positive
Positive
Neutral
Negative
Strongly
Negative
1. How would you rate how much the team accomplished in the past sprint?
2. How would you rate how well Scrum helps clarify the goals of what the team was supposed to deliver?
3. How would you rate your perception of how much business value your team produced in the past sprint?
4. How would you rate the quality and fit for purpose of what the team produced using the Scrum methods?
5. How would you rate the level of collaboration within the team?
6. How would you rate your perception of how much wasted/throwaway work happened in the sprint?
7. How would you rate your overall feelings about using Scrum?
8. How would you rate the training received for sprint planning?
9. How would you rate the usefulness of the sprint-planning sessions?
10. How would you rate the usefulness of the daily stand-up meetings?
11. How would you rate the usefulness of the sprint review sessions?
12. How would you rate the effectiveness of the sprint retrospective?
13. How do you feel about moving into a common room?
14. If the decision were solely up to you, would your team continue using Scrum?
Yes
No

IT Practice
Design Team
Relationship
Management
143

IT Practice
Design Team
Relationship
Management
144

Business Analyst Handbook PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Business Analyst Handbook PDF

Загружено:

Авторское право:

Доступные форматы

INFORMATION TECHNOLOGY PRACTICE

APPLICATIONS EXECUTIVE COUNCIL

Business Analysts Handbook

2012 The Corporate Executive Board Company. All Rights Reserved.

Information Technology Practice

Applications Executive Council

Content Publishing Solutions

Copies and Copyright

As always, members are welcome to an unlimited number of

The Corporate Executive Board Company has worked to ensure

The pages herein are the property of The Corporate Executive

2012 The Corporate Executive Board Company.

2012 The Corporate Executive Board Company.

OVERVIEW OF THE BUSINESS ANALYSTS HANDBOOK

4. Manage new solutions in the broader architectural context.

5. Enhance your vendor management competencies.

1. Reshape your engagement approach to reflect business leaders

Applications Executive Council

OVERVIEW OF THE BUSINESS ANALYSTS HANDBOOK (CONTINUED)

Hallmarks Shared Business: Applications Requirements Elicitation4

Each of the nine

Essential: Template or resource is applicable to core BA activities (e.g., requirements elicitation).

BUSINESS ANALYST Competency Model: Needs Discovery

Precisely and consistently captures business problems and

Can identify and document emerging business

Drives consensus for a desired future state that meets the

Prioritizes problems to surface the most critical needs

Can intelligently question business partner and knowledge

Can uncover needs that business partners and end users

Properly prioritizes competing business demands

Properly prioritizes business line and enterprise demands

Understands business process complexity

Can elicit high-level business requirements

Assesses the risks of various solution options to different

Accurately translates business requirements into

Influences business partner requirements in support

Manages requirements to meet performance expectations

Can articulate the business impact of business problems

Understands the organizations economic and revenue

Understands industry-specific trends that impact the

Clearly articulates benefits in business language

Accurately measures the contribution of IT projects

Quickly adapts to changes in business strategy

Helps business partners communicate solution value to key

Effectively coordinates project delivery with the project

Applications Executive Council

Can manage ambiguity and create accurate project effort

Recognizes the implications of business strategy changes

Effectively engages project stakeholders in the estimation

BUSINESS ANALYST Competency Model: Technology Management

Understands technology standards and architecture

Identifies solution interdependencies

Stays abreast and creates awareness of technology

Can identify commonalities and suggests a consistent

Can guide solutions options and business partner decision

Can identify opportunities for creating reusable enterprise

Can guide and manages interactions with technology

Incorporates usability and user interface techniques when

Can engage with knowledge workers in their normal dayto-day environment

Can identify the requirements to ensure end-to-end service

Understands knowledge workers information needs as

Can effectively convey knowledge workers preferences to