Good PDF

INFORMATION TECHNOLOGY PRACTICE
APPLICATIONS EXECUTIVE COUNCIL®
Business Analyst’s Handbook

Templates for Key Business Analysis Activities
© 2012 The Corporate Executive Board Company. All Rights Reserved.

Information Technology Practice |
Applications Executive Council® Content Publishing Solutions
Executive Directors Consultants Production Designers

Shvetank Shah John Hillery Todd Burnett
Warren Thune Andrea Moreland Carolyn Lamond
www.executiveboard.com Managing Directors Senior Analyst Contributing Designers
Jaime Capella Pallavi Goel Supriya Dhasmana
David Kingston Mike Jurka
Practice Manager Editor
Mark Tonsetic 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 The Corporate Executive Board Company has worked to ensure
copies of the materials contained within this handout. Furthermore, the accuracy of the information it provides to its members. This
members may copy any graphic herein for their own internal report relies upon data obtained from many sources, however, and
purpose. The Corporate Executive Board Company requests only The Corporate Executive Board Company cannot guarantee the
that members retain the copyright mark on all pages produced. accuracy of the information or its analysis in all cases. Furthermore,
Please contact your Member Support Center at +1-866-913-8101 for The Corporate Executive Board Company is not engaged in
any help we may provide. rendering legal, accounting, or other professional services. Its
reports should not be construed as professional advice on any
The pages herein are the property of The Corporate Executive
particular set of facts or circumstances. Members requiring such
Board Company. Beyond the membership, no copyrighted materials
services are advised to consult an appropriate professional.
of The Corporate Executive Board Company may be reproduced
Neither The Corporate Executive Board Company nor its programs
without prior approval.
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.
© 2012 The Corporate Executive Board Company.
All Rights Reserved. AEC2241712SYN
TABLE OF CONTENTS
Overview of the Business Analyst's Handbook • iv
Business Analyst Competency Model: Needs Discovery • vi
Business Analyst Competency Model: Technology Management • vii
Business Analyst Competency Model: Relationship Management and Communication • viii
Section 1: Requirements Elicitation • 1
Section 2: Requirements Management and Analysis • 15
Section 3: Creating Compelling Business Cases • 33
Section 4: Providing Accurate Project Effort Estimates • 47
Section 5: Architecture Management • 77
Section 6: Designing for Usability • 93
Section 7: Communications and Change Leadership • 105
Section 8: Business Relationship Management • 125
Section 9: Design Team Relationship Management • 139

iv
OVERVIEW OF THE BUSINESS ANALYST’S HANDBOOK

Five New Imperatives for Business Analysts
As a business analyst, you are uniquely positioned to more broadly see the 4. Manage new solutions in the broader architectural context.
changes under way in solutions delivery and corporate IT. You are witnessing The environment is growing increasingly complex with more externalized
greater externalization of IT services to the cloud. Business partners are taking solutions delivery. Improve your ability to identify interdependent processes,
more responsibility for technology solutions themselves. There is increasing and manage change of your projects that reduce the need for costly late-
pressure for efficiency in delivery. stage integration.
What does this mean for you? We’ve distilled five new imperatives for the 5. Enhance your vendor management competencies.
business analyst role: Organizations are growing their reliance on vendors for many kinds of
solutions, especially mobile solutions. Your effectiveness with vendors will
1. Reshape your engagement approach to reflect business leaders’ depend on your ability to drive the conversation on business need, not
preferences for risk, benefit, and involvement. technical specification.
Many business leaders now prefer to lead more in phases of IT projects.
Understand your business sponsor’s 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
it’s 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
of strategic 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 sponsor’s overarching
goals.
Applications Executive Council®

IT PRACTICE
www.aec.executiveboard.com

OVERVIEW OF THE BUSINESS ANALYST’S HANDBOOK (CONTINUED)
How to Use This Handbook
This handbook is organized into nine sections that correspond to the nine areas of the Council’s 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 resource’s applicability to the scope of a BA’s responsibilities.
Hallmark’s Shared Business: Applications Requirements Elicitation • 4

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 Reference Specialized
1 Each of the nine 2 The Handbook 3 Each resource

sections contains provides guidance includes an indicator
an overview on on when to apply of its degree of
the templates the template or applicability to the
available. resource. 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 BA’s 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

v
vi
BUSINESS ANALYST Competency Model: Needs Discovery

Section 1: Requirements Elicitation—Ability 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 ■■ Can identify and document emerging business ■■ Drives consensus for a desired future state that meets the
nonfunctional requirements requirements business problem and enterprise objectives
■■ Prioritizes problems to surface the most critical needs ■■ Can intelligently question business partner and knowledge ■■ Can uncover needs that business partners and end users
worker preferences to identify unique value drivers would not be able to articulate on their own
Section 2: Requirements Management and Analysis—Ability to manage requirements to the smallest set that will provide the biggest impact in advancing business objectives

■■ Properly prioritizes competing business demands ■■ Properly prioritizes business line and enterprise demands ■■ Understands business process complexity
■■ Can elicit high-level business requirements ■■ Accurately translates business requirements into ■■ Influences business partner requirements in support
■■ Assesses the risks of various solution options to different functionality of enterprise objectives
options ■■ Manages requirements to meet performance expectations
Section 3: Creating Compelling Business Cases—Ability to measure and communicate proposed project benefits

■■ Can articulate the business impact of business problems ■■ Understands industry-specific trends that impact the ■■ Quickly adapts to changes in business strategy
■■ Understands the organization’s economic and revenue organization ■■ Helps business partners communicate solution value to key
drivers ■■ Clearly articulates benefits in business language stakeholders
■■ Accurately measures the contribution of IT projects
to business value
Section 4: Providing Accurate Project Effort Estimates—Ability to quantify project resource requirements

■■ Effectively coordinates project delivery with the project ■■ Can manage ambiguity and create accurate project effort ■■ Recognizes the implications of business strategy changes
management office or equivalent estimates ■■ Effectively engages project stakeholders in the estimation
■■ Accurately quantifies project-specific risks through the process
development lifecycle

IT PRACTICE

BUSINESS ANALYST Competency Model: Technology Management
Section 5: Architecture Management—Ability to create solutions that advance architectural objectives

■■ Understands technology standards and architecture ■■ Identifies solution interdependencies ■■ Can guide solutions options and business partner decision
guidelines ■■ Stays abreast and creates awareness of technology making to minimize the amount of project investment
■■ Obtains key input from enterprise architecture groups developments related to a business problem divergence from target architecture
to ensure architecture compliance and exception ■■ Can identify commonalities and suggests a consistent
■■ Can identify opportunities for creating reusable enterprise
management approach across projects in the absence of standards services
■■ Can guide and manages interactions with technology
vendors
Section 6: Designing for Usability—Ability to design solutions for end-user adoption and productivity improvement

■■ Incorporates usability and user interface techniques when ■■ Can engage with knowledge workers in their normal day- ■■ Can identify the requirements to ensure end-to-end service
designing systems to-day environment performance from the end user’s perspective
■■ Understands knowledge workers’ information needs as ■■ Can effectively convey knowledge workers’ preferences to ■■ Can gain business sponsor commitment for additional
they relate to a potential solution business partners and design teams resources required to ensure usability

IT PRACTICE

vii
viii
BUSINESS ANALYST Competency Model: Relationship Management

and Communication
Section 7: Communications and Change Leadership—Ability 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 ■■ Effectively engages key knowledge workers and business
■■ Can work as part of a larger team ■■ Provides business partners with an accurate view sponsors in change management activities
■■ Surfaces potential impacts of the solution on all of challenges to end-user buy-in
stakeholders
Section 8: Business Relationship Management—Ability to engage business sponsors and contribute to their targeted business outcomes

■■ Sets realistic customer expectations for project delivery ■■ Adjusts customer expectations in accordance with ■■ Can influence business partner decision making to
(e.g, schedule, budget, outcome) changes in scope optimize requirements prioritization
■■ Clearly articulates the role of technology in terms easily ■■ Can effectively navigate conflict between multiple business ■■ Builds long-term relationships between multiple business
understood by business constituencies partners 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 Management—Ability to engage developers to ensure productivity and solution quality

■■ Can listen to and understand technological constraints ■■ Creates a vision of project success that drives team ■■ Educates developers on a project’s business context
■■ Clarifies the business rationale of a solution concept engagement ■■ Effectively collaborates with geographically distributed
■■ Shares best practices and process and environmental teams
knowledge

IT PRACTICE

Section 1: Requirements
Elicitation

IT Practice

Requirements 1
Elicitation
Requirements
Elicitation 2
REQUIREMENTS ELICITATION
Capture High-Level Requirements IBM’s User-Initiated Requirements Specification • 8

To improve the requirements elicitation process, IBM boosts the usability
Partner with business sponsors to effectively identify a desired future state
of user-provided information by supplying business users a standardized
that addresses a business problem.
elicitation template focused on the key attributes of the end product.
Hallmark’s Shared Business: Applications Requirements Elicitation • 4 When to Use

By including business stakeholders from the earliest stages of requirements ■■ To capture functional and nonfunctional requirements
■■ To identify the most stable requirement
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 Evaluate Requirements
■■ To establish ownership and shared responsibility with business partners Continually verify requirements individually and collectively against a
for each stage of requirements elicitation standard set of well-known criteria throughout the project lifecycle.
■■ To validate high-level functional requirements for new systems
development/legacy systems Capital One’s Creating High-Quality Requirements • 10

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
Sabre Holding’s Agnostic Needs Statement • 7 business need. After making sure that each individual requirement is of high
Sabre Holding assesses what should and should not be in a mobile application quality, the entire set of requirements is assessed as a whole against an
by crafting use cases that capture needs, not just mobile-specific requirements. additional set of three attributes. These attributes relate to the thoroughness
To isolate the right needs and translate them into features, BAs should use a of the set, the interrelationships between requirements, and the ease with
questionnaire that challenges business sponsors and users to articulate why which the requirements set can be changed.
their needs cannot be achieved without a mobile application. When to Use
When to Use ■■ To prevent scope creep of requirements
■■ To uncover business sponsor and user needs for mobile ■■ To define attributes of high-quality requirements
■■ To craft use cases for mobile apps requirements
■■ To validate whether a mobile application is the right solution Essential Reference Specialized

IT Practice

REQUIREMENTS ELICITATION (continued)
Elicit Unarticulated Needs

Engage in direct observation of knowledge workers to uncover unarticulated
needs and transformational innovation opportunities.
LexisNexis’s Uncovering Unarticulated Needs • 13

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

IT Practice

Requirements 3
Elicitation
Requirements
Elicitation 4
Capture High-Level Requirements

Hallmark’s Shared Business: Applications Requirements Elicitation
Requirements Elicitation Process
Feasibility Solicitation Analysis Prioritization Validation
Goal Formulate the business Gather and classify Perform an impact Prioritize all requirements Integrate requirements
problem and identify all feature requests from analysis and risk based on business and validate scope
stakeholders, including business partners through assessment to address criticality of the features. in collaboration with
end users. joint-requirements technical, schedule, and business partners.
planning. cost concerns.
Business-Side ■■ Map user base across Obtain a wish list from Perform abstractions Determine criticality ■■ Resolve as many open
Tasks organizations. each party in the user to answer questions of of features. issues as possible.
■■ Determine operational base. the form, “Why do you ■■ Verify that requirements
and problem context need X?” are in agreement with
such as mission originally stated goals.
scenarios. ■■ Obtain authorization
■■ Identify similar systems to move to Application
in the organization. Design.
Applications- ■■ Identify application ■■ Classify wish ■■ Estimate the impact of ■■ Prioritize requirements ■■ Resolve conflicts
Side Tasks domain and lists according to requirements on cost based on cost and and keep consistency
development experts. constraints (functional, and schedule. dependency. in check.
■■ Identify domain and nonfunctional, ■■ Perform risk assessment. ■■ Identify appropriate
architectural models. environmental, ■■ Examine cost of architectural models
■■ Assess cost constraints design, etc.). potential solutions in that work with current
imposed by the ■■ Determine interface light of architectural technology roadmap.
sponsor. needs for information and strategic fit.
that is shared between
business areas.

IT Practice

Capture High-Level Requirements (CONTINUED)
Hallmark’s 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? 1. What are the problems you face without the system today?
2. Who are the key stakeholders and users? Do their goals differ? If so, how? 2. What problems should this system solve?
3. How do the system goals map to business goals? 3. Do you have to do things manually that you would like to automate?
4. What is the most important business goal of the system? 4. Do you have performance problems that need to change?
5. Will the system change the way you are doing things now? 5. Do you have functional limitations that you would like to change?
6. Will the system help you be more efficient? How? 6. Are you using packages that force you to constrain your business functionality
7. What are the system deliverables? to the boundaries of the package?
8. What will the new system accomplish that is not accomplished manually 7. Which reports do you currently use? What data on the report are important?
or with other systems? How do you use the information?
9. What will the new system do? 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?
2. Determine Future Needs
10. What type of ad hoc analysis do you typically perform? Who requests ad hoc
1. What business requirements will this system address? information? What do you do with the information?
2. What information do you need from this system that you don’t have now?
3. Is any of this data currently captured in any other corporate system? 5. Determine Criteria for Success
4. How would you like to see this information?
1. What is most important for success of the application?
5. What functionality do you need from the system?
2. What do we need to accomplish to make this project successful?
6. Are the data and/or functionality shared by other (many) business areas?
3. What do we need to change to make this project successful?
If so, which?
4. What buy-in do we need?
7. If the reports were dynamic, what would they do differently?
5. Are we lacking any critical elements such as budget, resource allocation,
8. How much historical information is required?
or support?
6. What are training considerations for developers and users?
3. Determine System Users
6. Determine Assumptions and Open Issues
1. Who will be using the system?
2. What are the titles and roles of the people who will use the system? 1. List assumptions.
3. What are their levels of expertise? 2. List open issues, responsible parties, and resolution date.

IT Practice

Requirements 5
Elicitation
Requirements
Elicitation 6

Hallmark’s 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? Same as for new system development
2. How will the new version of the system help you?
3. What are your objectives in having this system? 3. Determine System Users
4. Who are the key stakeholders and users? Do their goals differ? If
so, how? Same as for new system development
5. How does the system map to business goals?
6. What is the most important business goal of the system? 4. Determine Current Problems
7. Will the system change the way you are doing things now?
Same as for new system development, plus:
8. Will the system help you be more efficient? How?
1. What is the risk of not converting the system?
9. What are the system deliverables?
10. What will the converted system accomplish that the current
5. Determine Criteria for Success
system cannot?
11. Will the output of the converted system be the same or different Same as for new system development
than the current system?
12. Will the new system have an additional functionality? What?
6. Determine Assumptions and Open Issues
13. Will the new system have better performance? To what extent?
14. Will the new system help you be more efficient? To what extent? Same as for new system development
15. Will the screens look different? How?
16. What is most important (rank in order of importance)? 7. Determine Current Problems
■■ Application is easier to use.
■■ Application has nicer front end. 1. Who are the most important players in terms of knowledge?
■■ Application has additional functionality (list). Politics?
■■ Application is more efficient. 2. Is there any existing system documentation? If so, where?
■■ Application is redesigned to better reflect the business. 3. Who else should we talk to?
Many of the questions that apply to new For projects that impact legacy systems,
systems development also pertain to Hallmark also considers important
projects involving legacy systems. questions relating to organizational
behavior and people issues.

IT Practice

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? 1. Who are you as a potential user? What is your role?
We want to offer a solution to travelers that helps A road trip traveler
them manage their travel throughout the trip. Use Case 2: End User
2. Why can’t you achieve this business objective
without mobile? 1. Who are you as a potential user? What is your role?
While travelers are “in-trip,” it is often difficult A business traveler
to communicate with them. Use Case 1: End User
3. What is the pain point?
1. Who are you as a potential user? What is your role?
Travelers typically think of trip management
A leisure traveler
applications during delays or when they are
looking for flight status. We want to expand our 2. What do you need to accomplish?
engagement by making life easier for “in-trip” While in the middle of my trip, I need to know my
travelers. hotel’s amenities and what other events/activities
may be available.
4. To what degree are you changing an existing
business process? 3. Why do you need to do that?
The travel lifecycle has always had a gap in the I usually find these items in advance of the trip,
“in-trip” phase. To move a product or service but if I fail to do that, I have difficulty finding the
into this phase requires a change as well as new information.
approaches and data. 4. Why can’t 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 7
Elicitation
Requirements
Elicitation 8

IBM’s User-Initiated Requirements Specification
Business Requirements Elicitation Worksheet
1 Key Question: What business 5 Key Question: How likely is it that

problem are you solving with each this requirement will not change?
requirement? Example: The system must be able
Requirement
Example: I need to have updates Requirement Success Stability to process orders, but it may not
Unique ID Statement
to customer data available in all Type Conditions Level have to provide daily reports.
Description
regional offices. High (H)—Unlikely to change
BFR1
BFR2 Medium (M)—May change based
Functional on business conditions or other
BFR3 business initiatives
Requirements
… Low (L)—Likely to change based
BFRn on business conditions or other
business initiatives
BNFR1
2 Key Question: What would render
BNFR2 4
a feature or functionality useless Key Question: How can you tell it
Nonfunctional
to you? BNFR3 is working correctly?
Requirements
Example: The data would be … Example: An e-mail reporting sales
useless to me if I can’t get it in updates is sent to the VP of supply
BNFRn
fewer than 15 seconds. chain every day at 8:00 a.m.
3 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

IBM’s User-Initiated Requirements Specification (Continued)
Business Requirements Specification, Illustrative
Business Requirements Specification Key questions to ask when reviewing business requirements:
1. What am I solving with this business requirement?
I. Business Scope and Objectives 2. Is this business requirement feasible?
3. What scope and/or objectives is this business requirement addressing?
This section defines the starting reference for a project. This section should help with 4. What is the acceptance criterion for this business requirement?
the following: 5. How do I measure the acceptance criteria?
■■ 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 Success criteria/acceptance criteria ensure agreed-to business requirements
intends to achieve its goals and make the desired transition and by what means. (functional and nonfunctional) are clear and unambiguous. They are also the metrics
■■ Document events that are the initial stimuli causing the client’s business to act.
that measure success of the project. The objective of this section is to identify and
■■ Describe and quantify the benefits, costs, schedules, and assumptions required
document success criteria and associated metrics for each business functional and
to justify the implementation (if needed). nonfunctional requirement.
II. “As Is” Business Process Flows a. Business Functional Requirements
This section should help with the following: Business Requirement Stability Level Success Criteria
■■ Contain the graphic representation of the flow of work through a business Functional (H)—High and Associated
process model, narratives that describe the flow, and key process attributes. Requirement Id (M)—Medium Metrics
■■ Describe a high-level business use case model; this use case model uses (L)—Low
graphical symbols and text (business lexicon) to specify how users in specific
BFR1
roles will use the system.
■■ Depict the usage and interaction between resources (e.g., hardware, software, BFR2
and people).
b. Business Nonfunctional Requirements
III. Business Requirements
Business Requirement Stability Level Success Criteria
Business requirements differ from systems requirements. Business requirements can Functional (H)—High and Associated
be identified by the following characteristics: Requirement Id (M)—Medium Metrics
■■ They support a business scope and/or objective, usually reviewed by executives.
(L)—Low
■■ They have a business purpose/focus.
■■ They state “what” needs to be accomplished using business language. BFR1

■■ They are nontechnical.
BFR2
IV. Assumptions, Issues, and Constraints

IT Practice

Requirements 9
Elicitation
Requirements
Elicitation 10
Evaluate Requirements
Capital One’s Creating High-Quality Requirements
Individual Requirements Evaluation Criteria
The following attributes should be applied to each requirement

Term Definition Guidelines Example
1. Unambiguous The requirement has only Avoid natural language, such as user-friendly, easy, simple, “For up to eight results, the detailed display format shall be
one possible interpretation. rapid, efficient, several, state-of-the-art, improved, maximize, used. For the remainder, the compressed display format shall
and minimize. be used.”
Use a requirements document glossary to capture the Ambiguity lies in the phrase “for up to eight results.” Does
meaning of important terms. it mean “for up to and including eight” or “for up to and
excluding eight”?
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 Use the source of the requirement as your reference A business requirement that states “the search function shall
describes the functionality of correctness, such as the actual business or system display a maximum of 10 results per page” could incorrectly
to be delivered. requirements specifications. If the system requirement be recorded in the systems requirements as “the search
conflicts with the corresponding Business requirement, engine must fetch a maximum of 10 matching records from
one of them is incorrect. the database.”
Include the affected area’s subject matter expert (SME) when
determining the correctness of requirements.
3. Testable The requirement can State each requirement so it can be verified within the “The program shall not enter an infinite loop” is a non-
be verified through an scope of the project using tests or other verification verifiable and hence not testable requirement.
inspection or demonstration approaches. If a requirement is not verifiable, questioning its
to determine whether it can implementation will be a matter of opinion.
be implemented properly
Requirements that are inconsistent, infeasible, or ambiguous
in the product.
are not verifiable. A requirement that merely states that the
product shall support certain functionality is not verifiable.
4. Achievable The requirement must be The requirement analyst and the business customer should
practical from the standpoint work through the elicitation process to agree on what can
of compatibility issues and cannot be done technically and what can be done only
with existing systems and at excessive cost or with other trade-offs.
environments and constraints
of time and budget.

IT Practice

Evaluate Requirements (CONTINUED)
Capital One’s Creating High-Quality Requirements (Continued)
Individual Requirements Evaluation Criteria (Continued)

5. No Design The requirement states what Check each requirement to ensure that it does not reflect a DO: Design independent requirements.
Impact is required but not how the design or implementation decision or describe an operation. “The system shall enable all employees to update their
requirement should be met. Such requirements are design-dependent. time sheets.”
Nonfunctional requirements such as system constraints are DON’T: Design dependent requirements.
an exception. “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 Link each requirement to its source. It could be a high-level
traceable to and from its system requirement, use case, or a documented stakeholder
source. 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 A necessary requirement is one that has been validated by an
document a business need owner recognized to have change control authority (such as
and should be implemented the requirements manager). It can be clearly identified with
by design. a business case.
8. Documented A requirement must be Verbal, undocumented requirements cannot be adequately
documented for it to be traced, tested, analyzed, or shared across the project team.
considered valid. 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 11
Elicitation
Requirements
Elicitation 12
Evaluate Requirements (CONTINUED)

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

I. Complete Requirements must account Organize the requirements hierarchically to help reviewers The use case method works well for this purpose.
for all business needs related understand the pieces that make up the requirement. It will Graphical analysis models that show different views of the
to the project. then be easier for the reviewers to tell if something is missing. requirements can also uncover incompleteness.
Focus on user tasks rather than on system functions during Any appearance of “To Be Determined” (TBD) in the
requirement elicitation. This reduces the likelihood of requirements document makes it incomplete. Use TBDs
overlooking necessary requirements or including as a standard flag to highlight gaps when it is known that
unnecessary ones. 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.
II. Consistent No two requirements must Consistent requirements agree with other software The following requirements are not consistent with each
be in conflict with each other. requirements or with higher-level system and business other:
requirements. Research and resolve disagreements among
“The search function shall return results in the order of their
requirements before development can proceed so it is
relevance to the searched term.”
understood which of the requirements is correct.
“The search function shall display the most recently created
Review all the related requirements before you modify one.
documents first.”
Inconsistencies can slip in undetected if only the specific
change is reviewed.
III. Modifiable Requirements specifications Uniquely label each requirement and express it separately “The user should lift the handset; the system shall respond
must be open to revision and from other requirements so each can be referred to with dial tone; the user should then dial the seven-digit
durable to change. unambiguously. phone number of the party the user is trying to reach.”
Organize all requirements such that related requirements are “The user should lift the handset; the system shall respond
grouped together. 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
Create a table of contents, an index, and a cross-reference
reach.”
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
LexisNexis’s 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 curiosity—Exhibits a passion for learning
■■ Observational skills—Can identify patterns in large data and information sets
■■ Problem solving—Is driven to understand the core of an issue
3. Journalistic Aptitude
■■ Interviewing skills—Is able to facilitate and guide discussions with others
■■ Interpersonal skills—Thrives in interactions with others
■■ Recognized as a Challenger® of the status quo—Is 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 Good but Insufficient Indicators of Success

for a Customer Advocate
■■ Engage with knowledge workers in their normal day-to- ■■ Experience in identifying and evaluating new technologies
day environment. ■■ Experience in gathering and defining business requirements
■■ Uncover and document existing pain points and needs ■■ Survey and data analysis skills
that knowledge workers would not be able to articulate
on their own.
■■ User-experience skills

IT Practice

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

LexisNexis’s 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 1. What are your hours?
■■ Size of business unit
■■ Structure of business unit

2. Who are the people you typically interact with and how do you interact with them?
■■ How are you personally evaluated? 3. What do you spend the most time on?
■■ Who supports you?
4. What would you like to be spending the most time on?
3. Tell me about your career/educational background and how you got to where 5. What is a good use of your time and what is not?
you are today.
■■ Undergraduate 6. What would you assign to someone else if you could?
■■ Graduate school/MBA
7. Where do you work—in the office, at a client site, at home?
■■ Career progression
8. In your everyday work, what tools/resources do you rely on to make your work
4. What is your key area of expertise? What would you like to be your key area easier?
of expertise? ■■ What tools serve you well and you could not live without?
■■ What tools are less successful?

5. What does your network of peers look like?
■■ Can you tell me about a work task that was made a lot easier using a tool that
6. What extracurricular activities (both job-related and personal) have you
you purchased?
participated in? ■■ How did that tool/resource make the job easier?
7. What is your level of comfort with technology? ■■ How do you customize/modify the tools that you use to help you in your work?
8. How do you keep up with new developments in your field? (Or can you usually use them off the shelf?)
■■ Is there a product you wish you had that is not available?
9. How do you learn about new products or services to help you with your job?
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 of your 11. How do you see your job changing in the next five years? What tools/resources will
company/boss/industry? 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 15
Management
and Analysis
Requirements
Management
and Analysis 16
REQUIREMENTS MANAGEMENT AND ANALYSIS
Prioritize and Track Requirements When to Use

■■ To connect business benefits and application functionality
Accurately screen and compare requirements based on how well they satisfy
■■ To quantify functional capabilities
business objectives.
■■ To find the best-fit implementation for application functionality
Sabre Holding’s Feature Needs-Testing for Mobile Apps • 18 Essential Reference Specialized
Sabre Holdings applies a rigorous screening to strip out features that fail
to satisfy either the business or end-user needs.
BCBS-MA’s Pairwise Feature Prioritization • 21
When to Use For functionally complex projects, BCBS-MA makes pairwise comparisons
■■ To screen mobile requirements for fit with business needs
among features to enable the business sponsor effectively prioritize requests
for functionality.
When to Use
■■ To compare and rank order business preferences
Discover’s Sample Requirements Tracking Document • 19 ■■ To compare and prioritize features
Discover’s requirements tracking document helps ensure that requirement changes
are reflected in design and test cases and validated by users. Essential Reference Specialized
When to Use
■■ To gather requirements iteratively Fenton, Inc.’s1 Functionality ROI Maximization • 22
■■ To identify requirements from business partners, users, and software
Fenton, Inc. quantifies each feature’s impact on a project’s business value
requirements components that enables benefit-driven trade-offs.
■■ To validate requirements during project review discussions
When to Use
■■ To quantify the value of application functionality
■■ To prioritize features and requirements based on business benefit
Paccar’s Business Objectives–Driven Functionality Prioritization • 20 Essential Reference Specialized

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

REQUIREMENTS MANAGEMENT AND ANALYSIS (continued)
Manage Requirements Across Business Process Change Improve Portfolio-Level Requirements Visibility
Customize requirements management methodologies based on project’s Group projects together based on their shared impact on business
architectural impact and end users/customers involved. processes, and then gather the requirements holistically.
Swiss Re’s Methodology Decision Map • 23 CIGNA’s Portfolio-Level Requirements Management • 27

Swiss Re aligns the level of effort for requirements management on any given CIGNA takes a holistic view of requirements capture by bundling projects
project with the level of business process change targeted by the project. based on project priority, business process impact, and business process
synergy. A centralized requirements group maps current business processes,
When to Use
identifies requirements redundancies and gaps across projects, and makes
■■ To match requirements management effort to business need
■■ To tailor requirements management methodology
the appropriate adjustments to enable business process transformation to the
desired future state.
Essential Reference Specialized When to Use
■■ To capture portfolio view of requirements
■■ To bundle projects based on shared impact of business processes
Drake Corporation’s1 Voice of the Customer Tool • 26
■■ To map current business processes, identify requirement redundancies,
Drake Corporation uses a Voice of the Customer planning worksheet to
understand user acceptance issues early and adapt requirements management and gaps across projects
accordingly.
When to Use
■■ To assess key stakeholder attitudes
■■ To plan engagement with stakeholders
1 Pseudonym.

IT Practice

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

Sabre Holding’s Feature Needs-Testing for Mobile Apps
Illustrative, Corporate Booking Apps
Candidate Features
■■ Obtains Travel Agency ■■ Shops and Books for Corporate ■■ Holds a Trip for Future Booking
Contact Information Approved Hotel Rooms
■■ Updates Traveler Profile Information ■■ Displays Corporate-Specific Messaging
Litmus Test
Needs Test 1:
Can we clearly articulate how this feature
Business Need
meets a business need?
Updates Traveler
Discard Features
Profile Information
Litmus Test
Needs Test 2:
Can we clearly articulate how this feature
End-User
meets a high value user need? Workflow Need
Displays Corporate-Specific
Discard Features
Messaging
Obtains Travel Agency
Usability Criteria Contact Information
Could use of this feature be severely Usability
impacted by any of the following? Criteria
■■ Noise/distractions
■■ Poor lighting
■■ Time pressure Holds a Trip for

Discard Features
■■ Slow link control protocol connectivity Future Booking
■■ Complex visuals Shops and Books for
■■ Specific mobile device Corporate Approved
(e.g., phone versus tablet) Hotel Rooms

IT Practice

Prioritize and Track Requirements (CONTINUED)
Discover’s Sample Requirements Tracking Document
1 Document 4 UAT ensures that business partners have

requirements captured validated the changes that were made
prior to the war room. 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 Design Test Changes UAT
Adjustment Document Case ID Implemented Done
Notes
RS0001 Users should be able to Select multiple DD0001 TC0001 Design
select the item from the list items from the
Development
of products. list.
Test Cases
RS0002 Make list of all products Also group the DD0005 TC0003 Design
available for the user to products by
TC0004 Development
select in alphabetical order. their market.
TC0005 Test Cases
RS0003 -------------------------------- ----------------- ----------- --------- -----------------
RS0004 -------------------------------- ----------------- ----------- --------- -----------------
2 Use notes column to write down any changes 3 Traceability ensures

to requirements during the war room. Don’t that changes are
waste time formally updating the requirements implemented in all
document. affected areas.

IT Practice

Requirements 19
Management
and Analysis
Requirements
Management
and Analysis 20

Paccar’s Business Objectives–Driven Functionality Prioritization
Prioritizing the Impact of Applications Functionality on Fulfilling Business Objectives, Illustrative
Strong Impact = 9 Points

1 High-level requirements 6 Impact assessments and
are framed in terms of business process knowledge Medium Impact = 3 Points
business or process result in quantified business
Low Impact = 1 Point
improvement objectives. benefits (e.g., 4% decrease in
order-to-ship cycle time).
Business Objectives
Reduce Costs Increase Revenue

2 Business Priority Rank:
Low (L), Medium (M), Increase
Increase Increase Increase Decrease
High (H) Engineering Improve
Engineering Average Customer Order-to-Ship
Operations Materials Cost
Design Efficiency Price Utilization Cycle Time
Efficiency
Impact
Business Priority Rank H M M H H L
Score
Change Order
6.6
Event Notification
Automate Material
4.9
Functional Requirements Ordering
Capabilities
Add Search Capability 5.2
3 Functional capabilities that 4 Assessment 5 Impact scores are calculated based on the Business Priority
potentially satisfy the high-level of impact of Rank and the impact of the functionality on each of the
business objectives can run into functionality on the business objectives; top third stay, bottom third are discarded,
as many as 100 for large projects. business objective and middle third are taken up for further consideration.

IT Practice

BCBS-MA’s Pairwise Feature Prioritization
Pairwise Comparison of Features
A. Change Address
1 Participants are asked to pick the A
1
feature they consider more important— B B. Change Name
feature A (Change Address) or feature
B (Change Name); ties are not allowed. A
A B
2
C C C. Reinstate
2 Similarly, pairwise comparisons are
made between each pair of features; A B C
the preferred one in each pair is circled. D
D D
D D
4 D. Change Status
3 A count of the number of times each feature
A
A B
B C D
D
is circled across the rows and columns of
E E E
E E E. Transfer the entire matrix is used to rank the features.
Feature A B C D E
Functionality Ranking No. of Times Complexity Ranking

3 2 0 4 1
Business Staff Circled Applications Staff
Prioritized Feature List

Project Rank Value-Based Cost-Based
Sponsor Prioritization Prioritization Which feature is more
complex to create:
1 D Change Status E Transfer ■■ Change Address or
Change Name?
2 A Change Address C Reinstate ■■ Change Name or
Business Project Business
Reinstate?
Manager Liaison 3 B Change Name D Change Status
Which feature is more important to you: 4 E Transfer A Change Address

Ranking the complexity of the features
■■ Change Address or Change Name?
5 C Reinstate B Change Name gives the Applications team a handle
■■ Change Name or Reinstate? on costs, resources, and schedule.

IT Practice

Requirements 21
Management
and Analysis
Requirements
Management
and Analysis 22

1
Fenton, Inc.’s Functionality ROI Maximization Strong Impact = 9 Points

Computer Telephony Integration Project, Illustrative
Medium Impact = 5 Points
Low Impact = 1 Point
1 Business Value Components 3 Scores can be

Weight is assigned
aggregated
based on order of Efficiency Goals Effectiveness Goals
to prioritize
magnitude of the
requirements.
value. a b c d e f g
Increased Timely Efficient Reduced Reduced Increased Intelligent
Use of Call Handling Call Transfer Calls to Call Customer Call
2 Vertical views Automation of Call to Sales Help Desk Escalation Retention Routing
indicate potential
Value $500 K $275 K $25 K $100 K $200 K $1 M $5 M Feature Score
feature gaps and
(Sum of Weight
redundancies. Weight 2 2 1 2 2 3 3 x Impact)
High-Level
System Features
Requirements
System shall identify which customers
67
to be harvested.
Need for System shall have the flexibility to
Associates to Talk 63
easily change harvesting instructions.
with Previously
Inaccessible System shall have the ability to
Customer reorder queues based on harvesting 43
Segments instructions.
System shall only harvest the best
51
customer segments.
System shall display customer and call

71
Need to Provide information to associate.
Associates with
System shall display key customer data
Critical Customer 83
to associate.
Relationship
Information System shall provide wrap-up for who
23
and why customer called.
1 Pseudonym.

IT Practice

Manage Requirements Across Business Process Change
Swiss Re’s Methodology Decision Map
Customer Request Decision Tree
Yes Information
Systems Planning
Is this a
one-time
Small
improvement?
(< $250 K) Continuous Process
No Improvement
Improving
Existing Business Process
Improvement
What is the What are you Changes a Leverage
size of the doing to the Point Within the
Significant Existing Paradigm Business Process
change? process?
($250 K–$2 M) Improvement
What is
Replacing the impact?
Existing Radical Process
Changes the Improvement
Business Paradigm
Yes Radical Process

Improving Improvement
Is there a high level of
Existing
Order of risk associated with
Magnitude the improvement? Business Process
(> $ 2 M) What are you No Improvement
doing to the
process?
Radical Process
Replacing Improvement
Existing

IT Practice

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

Change (CONTINUED)
Swiss Re’s Methodology Decision Map (Continued)
Approach Descriptions
Information Systems Planning Continuous Process Improvement

■■ Improving the automation of, or information support to, an existing ■■ Monitoring the existing process through a rigorous measurement program
process to identify problems for resolution
■■ Restructuring information systems for technical efficiency, functional ■■ Installing a quality-oriented culture and set of procedures to encourage
flexibility, and maintainability and exploit improvement ideas from workers
■■ Moving automated support from one platform to another ■■ Applying left-to-right thinking to evaluate how the parts of the process
contribute to the required outputs and performance
■■ Improving the integration among information systems
■■ Achieving a series of improvements of smaller magnitude in such areas
as cost, time, and quality that, over the course of time and the scope of
the entire process, amount to significant improvement
Business Process Improvement Radical Process Improvement

■■ Measuring and analyzing the existing process to identify problems for ■■ Replacing an existing process with a completely new or a substantially
resolution and other improvement opportunities redesigned one, generally accompanied and enabled by radical changes
in the use of information technology and people
■■ Applying left-to-right thinking to evaluate how the parts of the process
contribute to the required outputs and performance ■■ Applying right-to-left thinking, beginning with required outputs and
deriving the essential process
■■ Identifying leverage points with the greatest opportunity for competitive
advantage and performance improvement ■■ Actively challenging and rejecting old paradigms by lateral thinking
■■ Developing a set of improvements that together amount to significant ■■ Achieving order-of-magnitude improvements in such performance
improvement in such areas as cost, time, and quality. 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

IT Practice

Change (CONTINUED)
Swiss Re’s Methodology Decision Map (Continued)
Requirements Process, Three Stages
Architectural Analysis Business Process Analysis and Design Business Solution Analysis and Design
Gather Model Review Approve Gather Model Review Approve

Architecture Architecture Architecture Initiate Initiate
Process Process Process Process Process Process Process Process
Planning Design Review Analysis Analysis
Requirements Design Design Design Requirements Design Design Design
Deliverables Deliverables Deliverables

■■ Application Landscape ■■ Business Dynamics Models ■■ Business Process Models
■■ Business Information Model ■■ Requirements Matrix ■■ Logical Data Model
■■ Context Diagram ■■ Business Value Chain ■■ CRUD Matrix
■■ Draft Application Context Diagram ■■ Ownership Assignments ■■ SDL Compliance Statement
■■ Hierarchies ■■ Application Context Diagram
■■ State Transition Diagrams ■■ Information Flow Diagram
■■ Prototype Screen Flows and Designs
■■ Test Documentation
■■ Use Case Documents
Typical Activities Typical Activities Typical Activities

■■ Discuss project with local architecture ■■ Initiate business process analysis. ■■ Initiate business solution analysis.
team, obtain any business group–level ■■ Gather business process requirements. ■■ Gather business solution requirements.
reference artifacts. ■■ Model business process design. ■■ Model business solution design.
■■ Assess impact of any proposed changes ■■ Review business process design. ■■ Review business solution design.
on existing architectural environment. ■■ Sign off on business process design. ■■ Sign off on business solution design.
■■ Discuss appropriate timings and number
of governance reviews with Architecture
Governance and Standards team.
■■ Review and familiarize with Business Case
and Project Definition Document.

IT Practice

Requirements 25
Management
and Analysis
Requirements
Management
and Analysis 26

1
DRAKE
corporation
Change (CONTINUED)
Drake Corporation’s Voice of the Customer Tool
Stakeholder Group Analysis
Current Commitment Needed Commitment Probabilities Possible Strategies

Challenge Opportunities
(SS, S, N, A, SA) (SS, S, N, A, SA) of Success (PoS) to Improve PoS
Concern they are gaining Believe the opportunity. Supportive Strongly Supportive 90% ■■ Engage innovators
more work, not less and early adopters.
■■ Leadership set
priorities for all of their
work, let some drop.
Rewarded for ■■ Lab heads asked Supportive Strongly Supportive 70% ■■ OU—Set TS growth
developing, not for this. objectives.
replicating applications ■■ It’s their vision. ■■ US—Engage tech
directors.
■■ Not as attractive as This is a low-risk way to Neutral Supportive 40% ■■ Develop new
new productivity reach growth targets incentives.
launch and premium source of ■■ Seek help from
marketing campaign
■■ Not tech savvy marketer to develop.
ideas.
■■ Don’t see tech service
as a partner
Not on their dashboards This is a low-risk way to Neutral Supportive 60% ■■ Group metrics on
reach growth targets. the acceleration
dashboard.
■■ Promote the value
to the executive
conference.
1 Pseudonym.

IT Practice

Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY
CIGNA’s Portfolio-Level Requirements Management
Group Project According to Shared Impact on Business
1 2 3
Projects are regrouped into delivery
Business project priority ranking results in The project portfolio is segmented into
“flights” based on business need, which
a list of projects to be completed based on groups of projects according to shared impact
processes they affect, and where in the
initial capacity estimates. on business processes.
process chain their effect is prominent.
Business Priority Business Process Implications Business Process Synergy

What is the customer’s desired How much process transformation What is the delivery impact on business
priority and what is our current will be realized and which processes will workflows across dependent business
delivery capacity? be affected? processes?
1. ERP Finance Upgrade 2. Customer Information Database 5. Receipt Management System
Customer Flight
2. Customer Information Database 3. HIPAA Rights Repository 6. Bill Processing System
Service One
3. HIPAA Rights Repository 7. Benefits Management Portal 9. E-Billing Presentation
4. Claim Submission System
5. Receipt Management System 5. Receipt Management System 1. ERP Finance Upgrade
Claims
6. Bill Processing System 4. Claim Submission System Flight 3. HIPAA Rights Repository
Processing
6. Bill Processing System Two 8. Medicaid Reporting
7. Benefits Management Portal
8. Medicaid Reporting Repository Repository
9. E-Billing Presentation 1. ERP Finance Upgrade

General 7. Benefits Management Portal
8. Medicaid Reporting Repository
Accounting Flight
9. E-Billing Presentation 2. Customer Information Database
Three
4. Claim Submission System
For smaller, less-strategic projects,

CIGNA creates alternative paths to
expedite requirements gathering.

IT Practice

Requirements 27
Management
and Analysis
Requirements
Management
and Analysis 28
Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED)

CIGNA’s 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
for this 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 directly—with 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
1 The impact of a project on H High Impact

a business process step
represents the magnitude
M Medium Impact
of process transformation. L Low Impact
Customer Service
Claim Correspondence
Accounting Claim Adjudication Payment
Paper
Claim
Claims Claim Electronic ClaimClaim AdjudicationNon-Medical
Correspondence
Processing Check
Payment Fund
Medical Claims Claim Pricing
Receipt Process Receipt Process Claims Generation Transfers
Paper
Claim Claim Electronic ClaimClaim AdjudicationNon-Medical
Correspondence Check
Payment Fund
E-Presentation Portal M
Receipt Process Receipt Process Claims H M
Generation Transfers
Paper Claim Electronic Claim Non-Medical Check Fund
E-Presentation
“Flight” Projects
Receipt Portal System
Management Receipt Process
M MH
Receipt Process Claims H MM
Generation TransfersM
E-Presentation
Receipt Portal System
Management
Customer Information Database M MH H M H MM M
Receipt Management
Customer
Provider System
Information
Management Database
System M H HL MH L M M
Customer
Provider
Member Information
Management Database
System
Web Site Redesign M HL MH L
Provider
HIPAAManagement
Member Web System
SiteRights
Member Redesign
Repository L ML L M H L L
3 Multiple process
impacts in a row
Member
HIPAA Website
Member
Medicaid Redesign
RightsSystem
Reporting Repository LL ML L MH L M indicate process
flow and information
HIPAA Member
Medicaid RightsSystem
Reporting Repository LL LL MH L M dependencies.
Medicaid Reporting System L L H M
2 Similar or redundant system functionality is identified 4 CIGNA minimizes time spent on each
to consolidate requirements gathering across projects subsequent flight by building and actively
and expedite requirements elicitation. maintaining business process libraries.

IT Practice

Requirements 29
Management
and Analysis
Requirements
Management
and Analysis 30

Requirements Clarification: Roles, Responsibilities, and Escalation Process
1 “As Is” Process Modeling

Owner
Process Modelers
15% of Requirements Group
2 “Should” Process/High-Level
Responsibility
Requirements
Model “as is” business processes to
denote the flow of information and Owner
cross-connections among process Senior Business Analysts
segments at all levels. 35% of Requirements Group
Key Deliverables Responsibility 3 Detailed Requirements
Business process maps, which highlight Capture business process dependencies
Owner
interdependencies within and across in terms of sequential activities to
process areas uncover “as is” to “should” business Functional Business Analysts
process variance. 50% of Requirements Group
Key Deliverables Responsibility
IS/SHOULD Process Change Elicit detailed requirements consistent

Summary, which outlines how process with “as is” and “should” business
B process models.
functionalities interrelate
If a requirement interdependency is the product
of a new process interdependency, senior
Key Deliverables
business analysts work with process modelers to Business use cases, which include
evaluate and resolve the new interdependency
activity flows and new process
together and update business process maps and
modifications
IS/SHOULD Summaries accordingly. 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

Project, Process, Requirements Team Responsibilities by Phase
Project Initiation/
Planning Requirements Design
Awareness Meeting
■■ Review project documentation (e.g., project ■■ Plan and schedule high-level requirements ■■ Provide input to any phasing of solutions.
proposal, project/product description) for sessions by domain based on project ■■ Assist with issue resolution, provide
clarity, completeness, and potential domain/ decomposition. clarification, and respond to questions.
function impact. ■■ Engage business subject matter experts ■■ Update business requirements traceability
■■ Work with Enterprise PM (EPM) to achieve (SMEs) to support and plan requirements document with assistance from System
clarity and completeness of project scope if definition. Analysis to ensure design traces back to
needed. ■■ Work with EPM to define requirement requirements.
■■ Provide high-level time/cost estimates for kickoff date based on PPR capacity. ■■ Support design documents and walk
PPR activities to EPM. ■■ Outline/document proposed requirement through to verify design meets business
■■ Perform a high-level process decomposition gathering dates (high level, process requirements.
to identify the potential processes impacted modeling, and detailed) for review by EPM ■■ Support scope change management
by the project and across projects. and subsequently by matrix partners based process and update documentation as
■■ Share outcome from the decomposition on capacity, project, and process synergies. needed.
for review with EPMs and subsequently
with matrix partners.
■■ Identify and communicate domain lead to EPM.
High-Level Requirements Detail Requirements
■■ Facilitate and document high-level requirements and process models focused on

■■ Conduct end-to-end domain/project review.
specific processes within a domain (not project specific).
■■ Plan and schedule detailed use case sessions.
■■ Create requirements traceability matrix based on high-level requirements including
■■ Create and maintain detailed process models and detailed business use cases.
process and project views. ■■ Build/update process maps and use case library (ongoing).
■■ Create Use Case Inventory by process/project and assign owners for completion. ■■ Ensure appropriate representation in meetings to complete detailed
■■ Conduct high-level requirements sessions walkthrough with matrix partners process models and business use cases (e.g., SME, SA).
stressing manual touchpoints and new or eliminated processes based on high-level ■■ Distribute materials and conduct walkthrough of detailed process models.
requirements. ■■ Distribute materials and conduct walkthrough of detailed business use cases.
■■ Identify and document issues; assign owners and facilitate requirement issue ■■ Identify and document issues; assign owners and facilitate requirement issue resolution.
resolution. ■■ Update requirements traceability documents based on detailed requirement activities.
■■ Based on completed high-level requirements, assess and update estimates as ■■ Provide information to project test leads as input to project test strategy.
needed. ■■ Support scope change management process and update documentation as appropriate.
Construction Testing Implementation Warranty
■■ Assist with issue resolution, provide ■■ Provide test support for test scenario ■■ Provide input for implementation planning. ■■ Provide support for clarifying questions, etc.
clarification, and respond to questions. identification and defect resolution. ■■ Provide support for clarifying questions, etc.
■■ Support scope change management process
and update documentation as needed

IT Practice

Requirements 31
Management
and Analysis
Requirements
Management
and Analysis 32

IT Practice

Section 3: Creating
Compelling Business Cases

IT Practice

Creating Compelling 33
Business Cases
Creating Compelling
Business Cases 34
CREATING COMPELLING BUSINESS CASES
Articulate and Quantify Business Benefits McDonald’s Business Case Abstract • 44

BAs are called by the business relationship managers to help create business
Measure and communicate proposed project benefits by linking components
case abstracts and prepare any related preproject work, such as helping with
of business value to requirements.
cost estimation.
Fenton, Inc.’s1 Functionality ROI Maximization • 35 When to Use

Fenton Inc. itemizes the benefits in the business case, quantifying the value To create business case abstracts
■■
of application 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 Omega Corporation’s1 Standard Business Case Criteria • 45
they can be traced through the lifecycle. Omega Corporation revises business case review processes for IT projects to instill
2. Be an order shaper when it comes to benefits: Compel business business sponsor accountability and emphasize quantifiable, “hard” business
partners to articulate a project’s benefits in terms of quantifiable benefits. The process starts with a standard business case that captures total
components that are directly tied to a particular aspect of their five-year costs of ownership, including common “hidden” costs often overlooked
workflow. by business users during business case preparation. These proposals include
architecture compliance, sourcing considerations, and operating requirements,
3. Prioritize features and requirements based on business benefit: Benefit
such as infrastructure costs, maintenance, training, and support.
is the most meaningful metric for determining a project’s value. Be
specific when it comes to quantifying those values. When to Use
■■ To create a business case proposal capturing hidden requirements
4. Track ROI at the portfolio level: Only a portfolio view can detect trends
across categories and effectively communicate value delivery at the Essential Reference Specialized
enterprise level.
When to Use
Citrix’s Business Case Summary • 46
■■ To itemize benefits in a business case
Citrix synthesizes key IT project data—including financial metrics, risk
■■ To trace benefits through the project lifecycle
indicators, and business justification—in a one-page format for easy steering
■■ To prioritize requirements according to quantifiable benefits
committee review.
■■ To track project ROI trends at the portfolio level
When to Use
Essential Reference Specialized To create a high-level business summary emphasizing quantifiable
■■
business benefits
1 Pseudonym.

IT Practice

ARTICULATE AND QUANTIFY BUSINESS BENEFITS
1
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
1
Business Case
Business
Monolithic business case Value ■■ Itemizing the
Mapping benefits in the
business case
Business Value
Components
2
Component 1 Component 2 Business value drivers are
not connected to specific Benefit-Driven ■■ Quantifying the
High-Level business activities. Feature value of application
Requirements Prioritization functionality
Business Activity 1 Business Activity 2 Business Activity 3
3
System Capabilities Business activities don’t
tie to specific application ■■ Tracking project
Portfolio ROI
Application Application Application Application
functionality. ROI trends at the
Dashboard
Functionality Functionality Functionality Functionality portfolio level
1 2 3 4
1 Pseudonym.

IT Practice

Business Cases
Creating Compelling
Business Cases 36
ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED)

1
Fenton, Inc.’s Functionality ROI Maximization (Continued)

2. Connect Business Value to Business Process
Expected Benefits from Business Case Business Value Components Component Quantification Template
Computer Telephony Integration Project
Efficiency Goals Goal: Timely handling of call

a. Increased use of call automation $500 K Baseline: 85 seconds
$7.1 M
b. Timely handling of call $275 K 74 seconds
Cost Target:
$1.1 M c. Efficient transfer to sales $25 K
Reduction Improvement: 11 seconds
d. Reduced calls to help desk $100 K
e. Reduced call escalation $200 K Cost Savings: $275 K
Total = $1.1 M Calculation: 390 hours x $13.55 x
Revenue $6 M
Increases 52 = $275 K
Effectiveness Goals
a. Increased customer retention $1 M
b. Intelligent call routing $5 M The 11-second improvement is the measurable value
Total = $6 M Fenton, Inc. monitors to track benefits realization.
Computer Telephony Integration Workflow

Illustrative c f
Efficient transfer Increased customer
to sales = $25 K retention = $1 M
Sales referral
No
Customer calls Customer is One

Customer opts and Help ticket
Start automated greeted by opened Call complete End
for live person. done? Yes
system. name.
Escalated call
a b g d e
Increased use of call Timely handling Intelligent call Reduced calls to Reduced call
automation = $500 K of call = $275 K routing = $5 M help desk = $100 K escalation = $200 K
1 Pseudonym.

IT Practice

1

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
Discretionary Project Assessment explanation of the rationale behind their scoring decision.
Categories Scoring Options Scoring Guidelines

Quantifiable Business Objectives (QBOs)
Evaluate the project’s objectives and needs, 1 Objectives and needs are very clearly understood and are verifiable and attainable.
based on its inherent ability to be understood
and documented in a clear, unambiguous, and Lack of clarity exists with respect to the project’s objectives and needs, or it is uncertain how the business objectives can be verified
5
verifiable manner. or satisfied.
No ability to state project objectives and needs in unambiguous and/or verifiable terms; little certainty on how the project will deliver
9
real business value.
Customer Impact
Evaluate the project for its anticipated impact on Project implementation is expected to be virtually transparent to the external customer AND the project will have little impact on
1
the customer. Indicate whether the customer is internal customers.
internal or external.
5 Project is expected to have marginal impact on the external customer AND/OR significant impact on the internal customer.
Definition: Impact—Affects the product or service Project is expected to have significant impact on the external customer AND significant impact on the internal customer.
the customer receives and/or the manner in which 9
they receive it
Business Process Reengineering (Cost Reduction)
Evaluate the project for opportunities to reduce Proper use of technology requires very little workflow integration. Contextual and environmental factors do not weigh significantly
1
operating costs through the enhancement of on the ability of the technology component to yield measurable business value.
business process performance.
Marginal opportunities to enhance process performance may exist, but significant gains in business value may not be certain. Also
5
the project’s 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
9
certainly deliver significant business value. Project success may depend on it.
Project Objectives and Needs
Evaluate the project for an understanding of how Clear and concise understanding of how the project benefits will result in a positive, quantified impact on the sponsor’s business
1
its benefits will translate to a quantified, positive objectives. The benefit impact is supported by precise and verifiable cost and/or revenue data.
impact on the sponsoring entity’s business
A case has been articulated for how the project can yield benefits that will positively impact the sponsor’s business objectives, but the
objectives. 5
benefits are not quantified, and the proposal is not supported by precise and verifiable cost and/or revenue data.
9 Little or no case has been made for how the project will yield quantifiable benefits that will positively impact the sponsor’s business.
Three most important criteria in determining whether intervention is required
1 Pseudonym.

IT Practice

Business Cases
Creating Compelling
Business Cases 38

1

Discretionary Project Assessment
Categories Scoring Options Scoring Guidelines

Profit Potential (Revenue Growth)
Evaluate the project’s or product’s impact on, or Project objectives are not likely to drive significant, profitable revenue generation. The use of Six Sigma resources is not warranted
1
capacity to generate, profitable revenue growth. based solely on profit potential.
Project objectives may drive significant, profitable revenue generation. The use of Six Sigma resources is likely warranted based
5
on profit potential.
Project objectives have a large potential to drive substantial, profitable revenue growth. The use of Six Sigma resources is most
9
certainly warranted based on profit potential.
Sponsor Interdependency
Evaluate the project based on the level The project has the full support of the sponsoring entities AND no conflicting needs exist among those entities
1
of sponsorship interdependency. (or only one sponsoring entity is involved).
There is moderate support from the sponsoring entities AND/OR there are limited conflicts between the needs
5
of sponsoring entities.
There is limited support from the sponsoring entities AND there are potentially significant conflicts between the needs
9
of sponsoring entities.
Human Interaction with Technology

Evaluate the project based on the anticipated Normal operations in the target environment will involve very little depth of human interaction with technology AND the number of
1
degree of human interaction with technology human users that directly interact with technology will be relatively insignificant.
components in the use environment.
Normal operation in the target environment may involve significant depth of human interaction with technology AND/OR the
5
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
9
of human users that directly interact with technology will most certainly be significant.
Total Score (Sum of Scores as a Percentage)
Summary
Provide an overall summary of the project and recommendations. Threshold
(45–63) Intervention Required
(31–44) Reevaluate
(7–30) No Intervention Required
1 Pseudonym.

IT Practice

1

Efficiency and Effectiveness of Business Process Performance
Business Process Process Output
Quantifiable Business Objectives (QBO)
Process Efficiency A Measure of Net Business Value Process Effectiveness

QBO opportunity: Measure QBO opportunity: Measure
and decrease operating costs. and increase customer value.
Cost Reduction2 Revenue Attainment2
Speed Consistent Waste Rework/ Elimination Defect-Reduction Customer-Valued

Procedures Handoffs of Work Steps Products/Services Products/Services
Critical Attributes of Cost Critical Attributes of Quality
1 Pseudonym.
2 Representative list.

IT Practice

Business Cases
Creating Compelling
Business Cases 40
ARTICULATE AND QUANTIFY BUSINESS BENEFITS (Continued)

1

3. Quantify Each Feature’s Impact on a Project’s 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 customer’s
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 customer’s 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 ■■ 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 for associates to talk with customer segments previously not accessible to associates
■■ Need for select customer groups to have their calls specially routed
■■ Need to provide the associates with critical customer information pertaining to the customer’s interaction and relationship
■■ Need to be able to effectively report on call routing and call harvesting
Features ■■ 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 customer’s time to transfer to an associate.
■■ The system shall provide whisper functionality to alert associate that the call is harvested.
1 Pseudonym.
IT Practice

1

4. Track ROI at the Portfolio Level
A Heat Map Representation Clarifies the Distribution of Portfolio ROI
Business Revenue
Customer Value—Base
The size of the bubble
depicts the project return. Customer Value—Competitive
High Customer Value—Differentiated
Cost-Efficiency/Compliance
Key Advantages
■■ High-impact communication tool
■■ Portfolio pattern recognition
■■ ROI trend monitoring
Business Value
Low
Low High
Project Cost
1 Pseudonym.

IT Practice

Business Cases
Creating Compelling
Business Cases 42

1

4. Track ROI at the Portfolio Level (Continued)
Business Value Categories
Business Value Category Definition QBO Requirements
Customer Value—Differentiated Establishes a unique capability for the external customer over one’s peers/ ■■ VOC illustrates industry gap to meet order of magnitude customer needs.
competitors based on cost, quality, speed, and/or functionality ■■ Ethnography to survey techniques
■■ Predictive market analytics
Customer Value—Competitive Provides where there are optional features for the external customer and/or ■■ VOC illustrates company’s gap to competitors to meet customer needs.
failing to match the equivalent capability of peers/competitors will erode ones ■■ Focus group to survey techniques
competitive standing over time
■■ Responsive market analytics
Customer Value—Base Provides where properties are defined as a enabling minimum capabilities for ■■ N/A—May be combined with other business outcomes
the external customer—a commodity in nature
Business Revenue Limited received value gain for the external customer but enabling revenue gain ■■ Present historical, data-based customer behavior patterns to support proposed
to the company change.
■■ Existing or competitors’ customers
Consolidation/Acquisition Acquisition or divestiture activities ■■ N/A—Self-explanatory
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 ■■ Demonstrate no linkage to customer value or operating efficiency, or cost
capabilities with limited external customer value or internal efficiency gains reduction/avoidance.
■■ Baseline current state; demonstrate future state achievement to baseline
Enterprise Capability Provides broad underlying capabilities supporting multiple LOBs, projects, or ■■ Must support “X” number of future capabilities
future corporate/strategic initiatives ■■ Measurable expectation of capability achievement
■■ Demonstrate scalability, cost effectiveness, supportability, etc.
Operating Efficiency Provides ongoing internal cost reductions or other supporting internal ■■ Demonstration of activities that will result in a reduction of ongoing costs (per unit
operational factors (e.g., time to deliver, internal consolidations) or total business process)
Regulatory/Compliance As required by government, internal audits or other regulations with limited ■■ Demonstrate ability to maintain current operating efficiency.
external customer value or internal efficiency gains ■■ Demonstrate effectiveness of compliance solution.
■■ Demonstrate potential financial impact to corporation.
■■ Explain impact to internal or external customers.
1 Pseudonym.

IT Practice

1

4. Track ROI at the Portfolio Level (Continued)
Business Value Categories (Continued)

Business Benefit Scorecard
Average Cost Average

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

IT Practice

Business Cases
Creating Compelling
Business Cases 44

McDonald’s 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 ■■ Direct/Hard Savings—None
information; this will enhance McDonald’s ability to optimize investment ■■ Indirect/Soft Benefits
decisions, drive down costs, and speed the administration of the closeout of –– Construction supplier optimization and cost avoidance
construction projects. –– General contractor optimization and cost avoidance
Solution Summary –– Improved accounting administration efficiencies
■■ TIB Screens
Improve investment decisions and strengthen McDonald’s leverage with ■■ Business Alignment—MODERATE
suppliers during construction project negotiation by: –– Be the most productive provider by achieving G&A and capital
■■ Providing timely and accurate reporting of real estate and construction expenditure targets
capital expenditure plans, actuals, and projections; ■■ Leverage—MODERATE—US/Corp. solution
■■ Driving supplier optimization and savings through comparison of project ■■ Financial Strength—WEAK—Benefits are indirect/soft
component costs (i.e., asphalt, concrete, framing); this will strengthen cost Risks
controls by enabling reporting on baseline commodity prices; and
■■ Software vendors able to meet McDonald’s business requirements
■■ Driving general contractor savings through comparisons of construction
without extensive custom programming
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 McDonald’s 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

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED) 1
Omega Corporation’s Standard Business Case Criteria
Standard IT Project Business Case

Financial Analysis Architecture Review Opportunity Analysis
Project Valuation ■■ Project category ■■ Project description, rationale, intended
–– Strategic development functionality
■■ Payback period
–– Mandated initiatives ■■ Project steering committee members
■■ NPV
–– Discretionary enhancements ■■ Business risks to benefits realization
■■ IRR
■■ Consistency with IT architecture and data ■■ Technology performance risks
■■ ROI
standards ■■ Alternatives considered
Five-Year Cost–Benefit Analysis ■■ Opportunities to use existing functionality ■■ Quantifiable cost of not proceeding
■■ Critical timing issues ■■ Project dependencies on other initiatives
■■ Benefit Analysis ■■ Staffing requirements
■■ Software capitalization ■■ Legal, regulatory, compliance considerations
■■ R&D tax credit analysis ■■ Training requirements
■■ Detailed cash flow and P&L impact including: ■■ Retirement strategy
–– Benefits (e.g., increased revenue, revenue ■■ Project delivery plan, scheduled milestones
protection, expense reductions, cost avoidance)
–– Project costs Sourcing Review Operations Review
–– Capital (hardware, software, and other)
■■ Project vendor selection process ■■ Impact on existing infrastructure, software,
–– Expenses
■■ Opportunities to reuse existing contracts and service contracts
–– Operating expenses
■■ Offshore development opportunities ■■ Ongoing maintenance requirements
–– Support staff
■■ Lease-versus-buy analysis ■■ Savings and costs associated with
–– Ongoing maintenance (hardware, software)
decommissioning assets
–– Training
■■ Contingency and recovery costs
–– Communications, etc.
■■ Security and privacy compliance
■■ Expected service quality
1 Pseudonym.

IT Practice

Business Cases
Creating Compelling
Business Cases 46

Cirtrix’s Business Case Summary
Enterprise Strategic Goals Business Objectives IT Objectives
The IT organization Value and Visibility Controls Align IT with Business
compiles the
summary High-Level Project Business Case Multiple Products Cost Reduction Support Shared Admin and Ops
Customer Leverage Customer Impact Be First and Best Citrix Customer

from existing Business Intelligence Platform
business case Sponsoring Organization: Finance Next-Generation Partnership Employee Impact
Ops Excellence Through
documentation. Sponsor: George Deaver Sustainable Growth Continuous Improvement
Consistent Framework
Submission Date: 8/4/xx Competitive Excellence Productivity Gains

Project objectives
Provide Best Customer
IT Team: Business Intellgence Experience
are linked to a
People Development Revenue Generating
predefined list of
Business Rationale Risk Mitigation enterprise strategic,
business-focused,
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, Use internal resources for build and maintenance to build and retain tool competence.
and IT-centric goals.
leading to inefficiencies and missed opportunities
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:
1. Compare existing software to competitors to determine if we wish to Project Start Sept.
continue with them or select another vendor. Project Go-Live Jan.
2. Select vendor and complete contract negotiations.
Project Close July
3. Configure software.
4. Train users.
5. Deploy to production.
Expected Impact
Project Financials Comments Metric Description Quantification
Total Benefits $200,000 Data entry time reduced: 30 mins/week
= .5hrs * 50 * 40 = 1,000 hrs p.a. Use of enhanced functionality for data capture 100%
Improved decision making:
median project cost $100,000 * 100 p.a.
* 2% improvement = $200 K
Total Capital $100,000
Total Expense $20,000 20% support costs Percentage migration of data capture to new platform 75%
Total Costs $120,000
IT Headcount (FTE) 0.50 Will need 2 FTEs for 3 months Feed of enhanced BI inputs into SAP

IT Practice

Section 4: Providing
Accurate Project Effort
Estimates

IT Practice

Providing Accurate 47
Project Effort
Estimates
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 Continually prioritize the product catalog and build contingency buffers into
of project complexity. the plan to set realistic expectations for total cost and duration.
Marriott’s Staff Resource Estimation Calculator • 50 Raytheon’s Earned Value Metrics for Agile Projects • 53
Marriott disaggregates projects into common tasks and uses a calculator Raytheon focuses scarce sponsor time and attention on critical risks and
to determine resource needs. Categories are weighted based on relative opportunities. Raytheon’s earned value metrics for Agile projects help teams
complexity to generate an overall score. Using the overall score, the calculator to estimate cost and schedule despite the iterative and more ambiguous
categorizes projects as requiring low to high labor to complete. For each task, direction of Agile projects.
labor categories directly convert to resource requirements in hours. When to Use
When to Use ■■ To define requirements in a way that helps with project plan and estimate
■■ To estimate project requirements at each task ■■ To make story point estimates for all features
■■ To determine resource needs ■■ To inform business about potential risks and opportunities
Essential Reference Specialized Essential Reference Specialized
Estimate Costs and Risks for Agile Projects Estimate Benefits for Agile Projects
Allocate project funds and establish project schedule based on an analysis Estimate the value of benefits using an options approach.
of best-, expected-, and worst-case cost scenarios.
British Airways’ and Emergen’s Initial Value Estimate for Agile Projects • 58
TransCanada’s Risk-Based Estimation for Agile Projects • 51 British Airways estimates the value of major benefits streams and uses these
BAs lead the project, breaking down high-level requirements into detailed user estimates to prioritize work by Agile teams. As the team releases the solution
stories, which delineates business rules and their corresponding validation on an iterative basis, actual value realization can be used to refine initial
messages enabling developers to easily connect requirements to unit tests. To estimates and reprioritize. Understanding that benefits’ value are not static,
establish a baseline project cost, the time and effort required to develop each British Airways uses an options approach to control delivery risks.
user story is estimated. Project funding is allocated based on the coverage of
cost scenarios: low-risk projects receive expected funding, high-risk projects When to Use
receive worst-case scenario funding. Overall, the Monte Carlo simulation allows
■■ To elicit goals and testable metrics of project realization from business sponsors
■■ To Identify and prioritize benefits for release
for more informed decisions about project funding.
When to Use Essential Reference Specialized
■■ To translate high-level requirements into user stories for Agile projects
■■ To help developers connect requirements to unit tests

IT Practice

PROVIDING ACCURATE PROJECT EFFORT ESTIMATES (continued)
Estimate Testing Resources
Estimate testing effort by using the probability of discovering an error.
Hartford’s Managing Time and Budget Trade-Offs in Testing • 63

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
Estimate Service Cost

Price services based on their consumption patterns.
SKF’s Reusable Services for Large-Scale Integrations • 72

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

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 50
Estimate Resource Requirements

Marriott’s Staff Resource Estimation Calculator
Illustrative
Task Areas
Project Oversight Complexity Drivers: Capacity Planning/Performance Engineering Total Complexity Score Labor Category
1. Application Technology 7. User Base 190–210 High

Database Architecture COTS 2 HQ 1 148–189 Medium High
4 4 64–147 Medium
Custom International
22–63 Medium Low
Other (New to Marriott) 5 Properties 4
Capacity Planning/Performance Engineering 0–21 Low
Report/Batch Component 3 Res Centers 3
Weight 2 Score 8 Weight 3 Score 12
Web Engineering 2. Number of Tiers 8. Client Type
One 1 WEB 1 Hours and Assessment Areas
Desktop Certification Two 1 Fat/Thick 3 Development Test Production
Three 2 Metaframe 4 Estimate Script and Troubleshoot
User and Device Security Four 3 Terminal Services 5 Requirements Load Test Performance
> Four 4 and Performance Issues
36 72 12
Web-Based Access Control Engineering Weight 1 Score 1 Weight 2 Score 2
3. Number of Unique OS/Platforms 9. Extranet
Thin Client Devices and Software One 1 TAM Plugin 2
Two 1 AMS Junction 3
Deployment Services Three 2
Four 3 Questions are designed to
> Four 4
Server Builds determine the complexity
of the project and the
Middleware (Application Integration Solutions) 4. Number of Interfaces 10. Number of Business Functions operational environment of
1–5 1 < 5 2
the end product to generate
ID Admin and User Provisioning 6–10 2 6–10 3
3 4
reliable work estimates.
11–15 11–20
> 15 4 > 20 5
Security Architecture
WAN Engineering 5. Applications Details 11. Data Requirements

Upgrade to Existing App (Same Functionality) 1 Representative Data to Be Generated 5
Upgrade to Existing App (New Functionality) 3 Test Seed Data to Be Generated 5
LAN Engineering
Replacing Existing Application 1
New Application to Marriott 3 Categories and answer
Configuration Management
Weight 3 Score 3 Weight 5 Score 25 choices are weighted for
6. Customization Level 12. User Volumes (Total Named Users) relative complexity.
Infrastructure Application
High 4 < 100 1
Medium 2 100–500 2
Access Control Implementation Total score is correlated with
Low 1 > 500 3
estimates of up-front and
Functional Support
Total Complexity Score 93
ongoing resource needs.

IT Practice

Estimate Costs and Risks for Agile Projects
TransCanada’s Risk-Based Estimation for Agile Projects
Business Requirements Feature Breakdown User Cases
Requirements Award a Non-Prearranged 1.5 Business Rules: Award a Non-Prearranged Biddable Offer
Award a Non-Prearranged Biddable Offer Name Type Validations
Biddable Offer 1.1 Assumptions Award Integer 1. This field is editable if the corresponding
Secure Winning Bid 1.2 Definitions Quantity checkbox is True (i.e., checked).
Set Shipping Route 1.3 Process Flows 2. The amount awarded to a bid cannot be
1.4 Screen Descriptions more than the max bid quantity for that bid.
1.5 Business Rules System Message: Award quantity must not be

greater than max bid quantity.
1.6 Developer Comments
Checkbox Boolean Validation X
Bid Rate Decimal Validation Y
Developers write …based on the

…and then write
business rule defined validation
Pass/Fail unit tests.
validation logic… message…
Pass
System Message X
Tests when business rules are followed
Award quantity must not be
greater than max bid quantity.
Fail
Tests that error handling works as
expected when the rules are broken

IT Practice

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

TransCanada’s Risk-Based Estimation for Agile Projects (Continued) Monte Carlo Simulation Results
Low-risk projects receive High-risk projects receive

expected funding (covering worst-case funding (covering
The largest ranges are reserved
Range estimates allow for 50% of cost scenarios). 90% of cost scenarios).
for the highly variable cost of
best- and worst-case scenarios.
development time.
100%
Set Shipping Route
Secure Winning Bid
Award Estimated Effort (Hours)
a Non-Prearranged Biddable Best
Offer Expected Worst
Probability of Cost Scenario (Percentage)

Estimated Effort (Hours) Best Expected Worst
Schemes/Services
Estimated Effort (Hours) Best15.00 27.00 Worst
Expected 52.00
Schemes/Services 15.00 27.00 52.00
Integration Migration
Schemes/Services 15.0027.00 27.0052.00 52.00 109.00
Integration Migration 27.00 52.00 109.00
Architect
Integration Assistance
Migration 27.005.00 52.00 11.00 109.00 17.50
Architect Assistance 5.00 11.00 17.50
Define
Architect Validation Rules
Assistance 5.005.00 11.0010.00 17.5015.00
Define Validation Rules 5.00 10.00 15.00
DefineBackend
Validation Rules 5.0077.50 10.00141.00 15.00250.00
Backend 77.50 141.00 250.00
UI
Backend 77.5049.50 141.0096.50 250.00 163.00
UI 49.50 96.50 163.00
UI Total Development Time 49.50 179.00 96.50 337.50 163.00606.50
Total Development Time 179.00 337.50 606.50
TotalBug Fix
Development Time 179.0044.75 337.5084.38 606.50 151.63
Bug Fix 44.75 84.38 151.63
Bug Code
Fix Review 44.7557.00 84.38 57.00 151.63 57.00
Code Review 57.00 57.00 57.00
CodeTech Lead Assistance
Review 57.0060.90 57.00113.75 57.00208.35
Tech Lead Assistance 60.90 113.75 208.35
TechTotal
LeadUser Story Time (Effort)
Assistance 60.90 520.65 113.75930.13 208.351,629.98
Total User Story Time (Effort) 520.65 930.13 1,629.98 0%
Total User Story Time (Effort) 520.65 930.13 1,629.98 Best Worst
Project Cost in US Dollars
Effort estimates include time
for rework and code review.

IT Practice

Manage Time and Budget on Agile Projects
Raytheon’s Earned Value Metrics for Agile Projects
A Comparison of Agile and Waterfall Lifecycles
Waterfall
Concept
Definition and Requirements Development and
Design Deployment
Business Case Definition QA/Testing
Approval
Detailed requirements ■■ No iterations; build to the Quality and

definition specifies specifications identified earlier. value of
all of the technical ■■ Submit change requests if needed. functionality is
functionality that must ■■ End-to-end functionality is typically verified
be built. delivered late in the cycle. only on release.
Agile
Sprints
Concept Detailed Requirements
High-Level ■■
Definition and Release Scope
Requirements ■■ Develop Deployment
Business Case Planning
Definition ■■ Test
Approval
■■ Integrate
■■ Reprioritize
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

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 54
Manage Time and Budget on Agile Projects (continued)

Raytheon’s 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

What the Business Sponsor Cares About How Agile Delivers
1. Avoid building fallow functionality by incorporating frequent feedback loops

A. Will we deliver the requirements to fulfill the ensuring relevance of requirements that have not been built yet.
business case? 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

B. Will we meet time-to-market requirements?
any time and be left with a working functionality.
4. Save on cost by not building functionality that is not useful and high value.
5. Save on rework cost since Agile is based on delivering discrete “chunks” of
C. Are we going to stay within budget?
tested and valuable functionality.
6. Build discrete components early to provide valid estimates for cost to complete.
7. Provide end users opportunities early in the project to influence the

D. Will we maximize value from the system? implementation, thereby providing a more user-oriented solution and creating
evangelists when the product is released.

IT Practice

Project Effort
Estimates
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 Step 3: Determine Worst-Case, Most Likely, and Best-Case Scenario
Ranges for the Estimates
1. Each team member is given a deck of cards with the
same set of Fibonacci numbers (1, 2, 3, 5, 8, 13, 21...).
1 2 3 5 8 13 21
2. A user story is presented to the team.
Increasing
3. Each team member selects a card from his or her deck, Complexity
representing the number of story points he or she
User Story
thinks the feature will require (relative to past features).
Ideal: 3 Points
4. Everyone reveals their chosen number at once, and Expected: 5 Points
outliers discuss how they arrived at their estimates. Worst: 8 Points
5. Teams can go through multiple rounds of poker for
each story until they achieve relative consensus.
Estimated Range

IT Practice

Raytheon’s Earned Value Metrics for Agile Projects
Feature Backlog Status After Completing One of Four Iterations, Illustrative
Estimate Completed Actual Cost Expected Percent Complete = 25%; Since

Feature (Story (Story (Thousands Only One of Four Iterations Completed
Points) Points) of Dollars)
Welcome Screen 10 10 15
Planned Value = Expected Percent
Advert—Splash Screen 20 20 30 Complete; Total Budget = 25% × $175,000 =
Login Screen 10 10 20 $43,750
Personalized Google
20
Ads Actual Percent Complete = Total Number
of Story Points Completed ÷ Total Number
Catalog Browser 20
of Story Points Planned = 40 ÷ 200 = 20%
Catalog Editor 10 Complete
Shopping Basket
5
Browser
Earned Value = Actual Percent Complete;
Shopping Card Editor 25 Total Budget = 20% of $175,000 = $35,000
Check-Out Process 20
Invoice Calculation 10 Cost Performance Index (CPI) =
Earned Value ÷ Actual Cost = $35,000 ÷
Credit Card Verification 10 $65,000 = 0.53
PayPal Payment
20
Handling
Order Confirmation Conclusion: Estimate Cost at Completion
20
E-Mail Is $175,000 ÷ 0.53 = $330,188, and We Are
47% Over Budget.
Totals 200 40 65
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

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 58
Estimate Benefits for Agile Projects

British Airways’ and Emergen’s Initial Value Estimate for Agile Projects
1 2 3 4 5
Choose between
Define the business competing Discover the
Discover the Discover the
value model and and conflicting highest-value
goals of the client stakeholders and
the business value stakeholder goals business process
and customer their goals using a
drivers that will by ranking goals and its supporting
through interviews. context diagram.
drive the project. against business processes.
value drivers.
6 7 8 9 10
Explore the process, Capture
Elaborate business Define user stories define acceptance nonfunctional Improve your
processes and the to implement the criteria, and discover requirements with process with the
domain model. steps in the process. missing user stories acceptance criteria theory of constraints.1
with “what if?” and service levels.
scenarios.
11 12 13
Integrate Track progress

Come up with better
the customer and and value delivered
solutions by using
the analyst in across the whole
innovation techniques.
the value stream. value stream.
1 Based on Eliyahu Goldratt’s 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

Estimate Benefits for Agile Projects (CONTINUED)
British Airways’ and Emergen’s Initial Value Estimate for Agile Projects (Continued)
Project Breakdown into a Benefits Stream
Illustrative Tracking Metrics Goals
Revenue Increase 10%

Project Paid Seating Project, Business Case: 100%
Revenue Retained 5%
Value Propositions New Revenue Improve Customer Call Center
(Discrete Cost Reduction 3%
Stream-Seating Experience Efficiencies
Measurable Sales
Objectives Derived
from the Business
Revenue Increase Revenue Retention Cost Reduction Initial Estimate of
Case)
Contribution to Business Case
Benefits Streams
Offline Sales 50%
Basic Online Basic Online

and Change and and Change and 30%
Upgrade Sales Upgrade Sales
Exit and Other Seat Sales

20%
These benefits are the minimally marketable These are initial values only that will be revisited as
feature set that can provide functionality to end benefits tracking provides more information about
users and will move the business case metrics. customer behavior.
Principles
■■ 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

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 60
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
15 March unless market competition

$300 K $50 K $100 K
changes
Legend
1. Initial Value
Use the initial value estimate of an option to tentatively
■■ Monetary value estimate is based on assessed contribution prioritize it on a value proposition roadmap. Revise this value
to business benefit. after each release in a benefits stream.
2. Cost to Hold (Options Buying Price)

Calculate the cost to hold to ensure that the initial value
■■ Effort to define/document estimate exceeds the cost of formulating the option.
■■ Effort to determine acceptance tests
■■ Effort to elaborate for the developers to estimate
3. Exercising Cost
Exercising costs will differ based on teams’ domain knowledge.
■■ Based on the effort estimate For example, if an option is deferred, it may have a higher
■■ Exercising cost may include switching costs that accrue when an option exercising cost when picked up by another team.
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

Use the expiry date and conditions to understand the timebox
■■ The date by which the decision must be taken to deliver the release for decision making and any changes that will impact that
by a desired date; the expiry date has embedded the lead time necessary expiry date.
to build the solution for a target release date.

IT Practice

Continuous Reprioritization Across Releases
Illustrative
1 2 3 4 5
Obtain Benefits Reevaluate
Initiate Realization
Develop Estimated Reprioritize
Benefits Information
and Deploy Benefits on Benefits
Tracking from Previous Future Options
Releases
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
Exit and Change and

Other Seat Upgrade Seat
Sales Online
Exit Row
Basic Online Seat Sales
Seating Sales Online
Change and Basic Online
Upgrade Seat Seating Sales
Offline Offline
Seating Sales Seating Sales
Release 1 Release 2 Release 3 Release 1 Release 2 Release 3 Release 4

October December March October December January April

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 62

Initial Portfolio of Benefits
Voucher Project Paid Seating Project
Benefit A Benefit B Benefit C Benefit D Benefit A Benefit B Benefit C

Options Options Options Options Options Options Options
Value: 50% of Value: 30% of Value: 15% of Value: 5% of Value: 50% of Value: 30% of Value: 20% of
business case business case business case business case business case business case business case

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

IT Practice

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

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 64
Estimate Testing Resources (Continued)

Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued)
Project Risk Scorecard (Continued)
Project Selection Criteria 3 2 1 0
1. Percentage of Test Cases with Links to Financial Transactions 0–50% 50–90% 90–100% N/A
2. Tester’s Knowledge of the Application Strong Medium Low N/A
3. Percentage of Test Cases with Defects in Previous Releases 0–50% 50–90% 90–100% N/A
4. Percentage of Test Cases Requiring Complex Calculations or Logic 0–50% 50–90% 90–100% N/A
5. Percentage of Test Cases Requiring Back-End Process Validations 0–50% 50–90% 90–100% 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
10. Project Introduces New Functionality No — Yes N/A

IT Practice

Risk-Based Prioritization Tool
∑ PR X ∑ IR
Probability Risk Factor (PR) Impact Risk Factor (IR)

Risk Score
Test Case Description Usage Defect Change in
Complexity Business Criticality ∑ IR * ∑ PR
Frequency Prone Areas Requirements
1 Sample Test Scenario 1 2 2 3 2 16
Scoring Criteria
Probability Risk Factors (PR) 3 2 1
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) 3 2 1
Business Criticality High Medium Low

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 66

Testing Strategy Documentation
1.0 INTRODUCTION 7.0 TEST MANAGEMENT APPROACH

1.1 Background/Summary 7.1 Test Environment
1.2 Documentation and References 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
7.7 Release Management Process/System
4.1 Decisions
7.8 Test Metric Approach
4.2 Issues and Constraints
7.9 Defect Tracking
5.0 ASSUMPTIONS, RISKS, AND CONTINGENCIES
8.0 PASS/FAIL CRITERIA—DEFECT TOLERANCE
5.1 Assumptions
9.0 ROLES AND RESPONSIBILITIES
5.2 Exceptions
10.0 ENTRY AND EXIT CRITERIA
5.3 Risks/Contingencies 11.0 TEST SCHEDULE
6.0 TESTING LEVELS AND TYPES 12.0 GLOSSARY
6.1 Unit Testing 13.0 SIGN-OFF AND APPROVAL
6.2 Assembly Testing
6.3 System Integration Testing
6.4 Business Acceptance Testing
6.5 Types of Tests

IT Practice

Testing Strategy Documentation (Continued)
Test Strategy Review Checklist
Section Section Title Checklist Items Yes No NA Comments

1 Has the project/application overview been documented?
2 Has the intended audience been identified appropriately?
Introduction
Have all the required documents been identified and referred to for preparing the test
3
strategy?
Have in-scope and out-of-scope application modules/functions to be tested been
4
identified clearly?
Scope
5 Have in-scope and out-of-scope types of testing been identified?
6 Has the rationale behind the scope decision been stated?
7 Test Levels Have all the test levels and types been defined?
8 and Type Have the entry and exit criteria for the applicable types of testing been determined?
9 Has the requirements analysis process been identified?
10 Has the test process to be followed been defined?
Has any exception to the QA framework been documented clearly along with
11
its rationale?
12 Has the QA automation framework to be followed been defined? (If applicable)
13 Test Has the list of tools and its purpose for various QA activities been identified?
14 Methodology Have the different test environments for different types of testing been identified?
Has the test design approach manual and automation been identified for various
15
types of testing?
16 Has the high-level test data approach been determined?
Has the test execution approach that details the testing cycles planned for been
17
determined?

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 68

Test Strategy Review Checklist (Continued)
Section Section Title Checklist Items Yes No NA Comments

18 Have test planning activities been outlined clearly?
Has the process for change management on how changes are identified,
19
Test communicated, and tracked to closure been outlined?
Management Has the process on version control from development to testing environment been
20
outlined?
21 Has the process for defect management been identified?
Roles and
22 Have all the required roles and responsibilities been clearly stated?
Responsibilities
Have the assumptions and dependencies that underlie the test strategy been
23
Assumptions, identified?
24 Risks, and Have the risks based on assumptions, dependencies and past data been identified?
Dependencies Are risks being assessed based on their likelihood, and are appropriate mitigations
25
being determined to avoid the risks?
26 Does the test schedule contain appropriate timelines, and is it in synch with project plan?
Test Schedule
27 Has the reference to project plan been provided?
Have all the required documents been identified and referred to for preparing
28 References
the test plan?

IT Practice

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

IT Practice

Project Effort
Estimates
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 0 <3
Average 3–6 transactions <3 3–8
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> 5 5 5 15
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 1 1 2 72
Average 2 2 4 144
Complex 3 3 8 288
Total Test Case Points 504

IT Practice

Testing Demand Management Tools
Project Resource Mapping Business Unit Resource Cost Estimation

Illustrative Illustrative
Business Unit Project Manager Assigned Project January Business Unit 1 Jan. Feb.
Name Name 2010 Demand for Core
Business Unit 1 John Yes Project 1 10 Billable Core
Business Unit 1 Kathy No 0 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 0 Total Business Unit 1 $
Business Unit 3 Vikram No 0 Business Unit 2 Jan. Feb.
Business Unit 4 Penny No 0 Demand for Core
Business Unit 4 Vikram No 0 Billable Core
Business Unit 4 Jennifer Yes Project 1 20 Over/Under on Core $
Total Testing Demand 50 Demand for Flex
Billable Flex $
Total Business Unit 2 $
Business Unit 3 Jan. Feb.

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 72
Estimate Service Cost

SKF’s Reusable Services for Large-Scale Integrations
Step-by-Step Implementation Toolkit to Sustain Service Reuse
1 Develop Data-Oriented Service 2 Build a Price List for Services 3 Measure Service Consumption
Definition ■■ Adopt pricing scheme per Use service inbound queue to
Identify service components service component. count unique message IDs.
using a handful of data ■■ Identify cost per service based
attributes. on pricing scheme.
6 Identify Opportunities for 5 Identify Patterns of Service 4 Use Existing Billing Structure
Service Consolidation, Usage to Track Service Consumption
Modification, and Elimination ■■ Identify which components are Use existing cost center
Use volume and rate of widely used, moderately used, structure for applications to
component and service or not used across services. allocate costs to business users
consumption to identify reuse ■■ Assess the prevalence of on a monthly basis.
potential. service components across the
portfolio.

IT Practice

Estimate Service Cost (CONTINUED)
SKF’s 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 Maintain Catalog Make Decisions

Price List of Services 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 Council’s research, and we encourage members who have additional questions to contact our staff for further discussion.

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 74

Payback on Reusable Services
Service Reusability Model Service Reusability Assumptions
50 40
1 Service is consumed by business sponsor, and potentially,

100 other business units.
25 3
2
Data
Transformations 1 40 2 When demand for a service is high enough, it is made into a
reusable service.
3 A conservative estimate of cost avoidance is set at 40% of

External
Connections
the cost to create the initial service. Cost avoidance is not
100% due to the cost of modifying an existing service for a
40
“custom fit” and developer time spent finding and learning
about the service.
Internal
Connections
4
Conversion 4 Typical payback period for a reusable service is 10 minutes;
to Common on average it takes three reuses to break even.
Message
Format
Cost to Service Cost to Cost Avoidance

Create Consumption Generalize Due to Reuse
One-of- Chargeback and Improve
a-Kind Benefits Service
Service Performance
Three Months One Month Six Months

IT Practice

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) 12. Total number of requests for a single-use service per year 1,200,000
$100
2. Estimated number of hours required for one data transformation 100 13. Change in scale of usage due to fortification of service into a
reusable service (total number of requests for a fortified service
3. Estimated number of hours required for one internal data 2
50 divided by total number of requests for the same service before
connection fortification on an annual basis)
4. Estimated number of hours required for one external data 14. Consumption charge per request per service $0.10
50
connection
5. Estimated number of hours required for one enterprise service bus 50

B. Reuse Cost Avoidance
15. Probability that a new user of the service would have asked for
0.000001
B. Service Fortification creation of the service, if it had not been fortified for reuse
6. Cost of fortification as a percentage of initial service development

50%
cost
7. Number of months between initial service creation and service

3
fortification
8. Duration of time spent on service fortification in number of months 1
C. Support Costs
9. Expected life of a service in number of months 60

10. Support cost as a percentage of total lifecycle costs 60%
D. Admin Costs
11. Monthly admin cost (fully loaded) $5,000

IT Practice

Project Effort
Estimates
Providing Accurate
Project Effort
Estimates 76

IT Practice

Section 5: Architecture
Management

IT Practice

Architecture 77
Management
Architecture
Management 78
ARCHITECTURE MANAGEMENT
Support Business-Led Technology Purchases to optimize process maturity. As Alpha’s BAs develop deep understanding
of processes, they learn to tie requirements to appropriate levels of process
Guide business leaders to ask vendors the right questions to unearth the
maturity through a three-step process:
most likely technology selection pitfalls.
1. Define processes before automation.
CareFusion’s Technology Buyer’s Guide • 79 2. Automate processes for which a strong business case can be made.
The Technology Buyer’s Guide, a tool developed by CareFusion, contains
3. Continue automation to improve efficiency as process matures while
guidelines for business leaders in procuring technology solutions directly from
avoiding process rigidity.
vendors. It guides them to the right due diligence conversations to unearth
common technology selection and implementation pitfalls. When to Use
■■ To tie requirements to appropriate levels of process maturity
The Buyer’s Guide equips business leaders with questions for vendors in four
■■ To use process analytics to make informed technology roadmaps
key categories:
■■ To prioritize process improvements
1. Fit with identified business need

2. Implementation effort
3. Quality of the vendor partnership
Support Service Reuse
4. Financial cost
Increase ROI from existing services by reengineering them based on service
When to Use usage patterns and data patterns.
■■ To manage interactions with technology vendors
■■ To guide and coach business sponsors to make informed technology choices

DirectTV’s Deriving Maximum Value from Existing Technical Services • 86
Essential Reference Specialized 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.
Balance Process Maturity and Automation
When to Use
Allow flexibility between automation and processes. Use Business Process ■■ To understand data standardization opportunities for services
Mapping (BPM) to create a roadmap for automation of processes. ■■ To identify solution interdependencies
■■ To have informed conversations with architects on service usage patterns
Alpha’s1 Balancing Process Maturity and Automation • 83

Alpha determines which processes to automate and at what level, while helping Essential Reference Specialized
1 Pseudonym.

IT Practice

Support Business-led Technology Purchases
CareFusion’s Technology Buyer’s Guide
1. Buyer’s Guide: Fit with Identified Needs
Part 1: Questions for Self-Reflection

1. Have we defined metrics for assessing the success of this implementation? Why Ask These Questions?
2. Do we understand how end users will use this solution? ■■ It is hard to assess the success of any project that lacks measurable outcomes from the onset.
3. Have we spoken with the likely end users to understand how this would fit ■■ Business sponsor’s perceptions of how a solution will be used often diverge from the ways in which they
into their existing way of working? are incorporated into end users’ workflows.
4. How likely is it that the way we use this solution changes over time? ■■ 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 2–3 core problems this solution must resolve for us. Why Ask These Questions?
Can you provide specific examples of how you have addressed these ■■ It is very hard to spot the main weaknesses of software solutions during the buying process—they
problems for other clients? generally surface during implementation. Therefore, it is common for inexperienced buyers to feel that
2. What type of preparation (data access, security, special configuration, etc.) they don’t understand the potential pitfalls of a solution.
was required to successfully resolve those clients’ problems? ■■ Make customer references truly comparable by ensuring they align to a highly similar problem, rather than
3. Could we obtain a reference from a customer with the same or a highly to the product the vendor is offering.
similar problem?
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 A–F:
(How well did we understand what the vendor told us about this category?)

IT Practice

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

CareFusion’s Technology Buyer’s Guide (Continued)
2. Buyer’s Guide: Implementation Efforts

1. What types of existing data will this solution need to access? Do we know Why Ask These Questions?
where that data currently resides? How certain are we that we know? ■■ Out of all the requirements of a vendor solution implementation, data is the most complicated. It is also
2. Have we tested end users’ willingness to change their workflows to fit the the most likely to undermine the potential benefits as a result of the unforeseen amount of integration
tool “as is” with little or no customization? required for the solution to work as planned.
3. How many of our best people are we willing to dedicate fulltime to serve as ■■ Significant modifications to existing workflow frequently result in resistance and requests for
subject matter experts during solution implementation? Part-time? customization, which cannot be achieved without an increase in the implementation effort.
4. Will we need to project manage the implementation of this solution? If so, ■■ Subject matter expert (SME) involvement during solution implementation is the most commonly
what experience will be needed by the person in that role? unanticipated bottleneck in project delivery. The time commitment required from SMEs is typically two to
three times higher than originally estimated.
Differentiating Questions Why Ask These Questions?
1. How many third-party service providers have you certified in implementing ■■ Third-party service providers with experience implementing the solution can provide a more honest,
your product? Would you be comfortable if we talk to some of them impartial assessment of its strengths and weaknesses, since they typically work with multiple vendors.
independently? ■■ If the vendor’s business model relies heavily on services revenues, it could indicate that the configuration
2. What percentage of your revenue comes from services rather than licensing? and integration of the solution is highly complex. It also gives the vendor an incentive to prolong the
3. If we need to customize, how do you license for development and test implementation by offering customizations.
environments? ■■ Many vendors have very strict licensing terms that lead to exploding costs anytime that a client needs
4. What is the average implementation cost at your different licensing tiers? to do customization.
■■ Integration ■■ Training
1. Based on your clients’ experience, what other standard enterprise systems 1. Will you provide initial training on using your product to our staff?
does your product need to connect to perform as designed? 2. Will training focus on an overview of functionalities or be tailored by role?
2. Which standard enterprise systems need to draw from the data processed 3. Is there a cap on the type and number of training sessions or support calls included in the contract?
through by your solution? ■■ Security
3. What are the most commonly missed areas of integration for customers who 1. Does your product store non-public information about our employees or customers?
want to use it like us? For the kinds of uses we are thinking of in the future? 2. Would you be open to a third-party vulnerability assessment before we sign an agreement?
■■ Customization 3. Would you be open to ongoing third-party vulnerability assessments?
1. How much customization have your other clients with uses like ours had to 4. In an event of a breach, what would be the most recent version of critical files you would be able to provide?
do? 5. Would you be open to an audit by our internal IT department on your disaster recovery and business
2. Which types of IT SMEs will we need to commit to implementation? continuity plans?
3. How many business SMEs will we need to commit to implementation? 6. Would you be willing to make adjustments to your current disaster recovery and business continuity plans
based on our IT department’s recommendations?

IT Practice

3. Buyer’s Guide: Quality of Vendor Partnership

1. What specific skills and expertise does this vendor provide that we lack Why Ask These Questions?
within our Corporate IT organization? ■■ The probability of a vendor lock-in—a situation in which our business becomes dependent on a vendor—is
2. How essential is the business problem that this vendor is helping us solve higher if vendor skills and expertise are hard to find inside (or hire into) the internal IT department.
to the core operations of our business? ■■ In their efforts to grow their own margins, vendors sometimes lower the quality of service they provide
3. What is the minimal level of vendor relationship quality that we are willing if their product is key to a client’s core business operations.
to accept? ■■ Inexperienced technology buyers often buy third-party solutions without thinking through what would
4. How do we define a partnership “deal breaker”? 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 ■■ Most vendor products require at least a minimal amount of support. Unavailability of that support at a
customers about extraordinary events? (e.g., security events or business disruptions) critical time (e.g., security events, major disruptions) may significantly impact our business.
2. How do you measure customer satisfaction? Who is the customer? ■■ Including customer satisfaction metrics in staff performance evaluations ensures that vendor employees
(End-users, the purchaser, IT?) are more likely to provide the desired level of support regardless of their level in the organization.
3. Are these metrics included in the performance evaluation of your staff? ■■ It is hard to anticipate potential problems with using the vendor solution, but reviewing standard issue
4. Have you defined standards for issue resolution? Can you share those resolution procedures can serve as a proxy for understanding: a) Potential areas of concern,
standards and your performance against them? b) Expected level of service if those concerns materialize.
■■ Service=Level Agreements (SLA) ■■ Effective Communication
1. Are your SLAs calculated based on averages over a period of time or on a 1. What is the standard communication process between your company and clients regarding important
single unit of services? issues?
2. Are there exclusions from meeting the defined SLA levels? 2. What is your internal standard for notifying clients about extraordinary events (e.g., security breaches)?
Note: SLAs define the availability of the vendor’s product and the response ■■ Proactive Support and Responsiveness
time you can expect from the vendor if something goes wrong with the 1. What time zones does your staff reside in?
product or if you have a question. 2. Do you monitor over or underutilization of your services to identify and diagnose potential problems?
3. Would you be open to a trail period during which our IT department can ■■ End-User Support
assess your ability to meet SLAs? 1. What type of post-implementation training will you provide?
■■ Professional and Cooperative Behavior 2. Will you provide ongoing support?
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 company’s standard for professional and cooperative behavior?

IT Practice

Architecture 81
Management
Architecture
Management 82

4. Buyer’s Guide: Financial Cost

1. Have we figured out an internal break-even ROI point or a set of assumptions Why Ask These Questions?
under which this investment is no longer a good idea? Have we explored how ■■ Many business leaders report that in hindsight, they would have made more explicit assumptions about
likely are those assumptions to come true? the expected ROI from a vendor solution and that they would have altered some of their financial cost
2. What would be the non-financial impact of vendor insolvency on our decisions if the assumptions were fully fleshed out.
business? Do we have a contingency plan in case this happens? ■■ Like any business, SaaS vendors—both big and small—could run into financial trouble. Regardless
3. How comfortable are we with a long-term partnership with this vendor of whether the turmoil experienced is temporary or permanent, it will have an impact on its clients.
in which the terms of our agreement cannot be changed? ■■ Vendor lock-in—a situation in which our business becomes critically dependent on a vendor—may
4. Is this vendor also selling products to our IT organization, which may be able not be favorable if the partnership is considered a short-term fix to a long-term problem.
to provide us with discounts or references?
1. Based on our current level of need, are we considered a “growth” account ■■ Frequently, vendors provide only a partial view into the anticipated future costs of doing business with
or a “maintain” account? them. To avoid surprises, contract negotiation should focus on fully understanding initial costs of entering
2. How have your prices changed in the last two years? What is likely to happen into agreement with the vendor, as well as projected costs, their drivers, and their likely direction.
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?
■■ Price Competitiveness ■■ Source of Vendor Profits
1. What is your unit of measure for the product and service? (e.g., per employee, 1. What is your margin on goods sold versus services sold?
per device, per user account, per transaction, enterprise-wide license? 2. How much does an average client spend on professional services with your company?
2. What is the billing frequency? E.g., per month, per quarter, per year)? 3. Based on our need and environment, how much custom implementation requiring paid support would
3. On average, by how much does a customer’s total spend with you rise you recommend?
as he or she moves from lower tiers to higher tiers? ■■ Vendor Stability
4. Are there additional charges for exceeding various parameters, such as storage? 1. How long have you been in business?
■■ Cost Flexibility 2. At a high level, what is your company’s strategy for the next 12 to 18 months?
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?)

IT Practice

BALANCE PROCESS MATURITY AND AUTOMATION
1
Alpha’s Balancing Process Maturity and Automation
■■ Review workflows.
Investigate Process ■■ Interview end users and SMEs.
■■ Identify process components.
Analyze Process Determine current maturity of each process component by assessing:

Components ■■ Current level of automation;
■■ Number of different workflows across the organization;
■■ Lack of clarity about best workflow; and

Decide Whether
■■ Amount of change management required to automate.
or Not to Automate
Select only those components that have significant process maturity,

manual intensity, and lengthy cycle times (e.g., for automation).
Yes No
Continue Monitoring Process

■■ Consider automating as part of future capabilities consulting with the
Define requirements for business. Any future considerations of automation must be measured
Exclude from
automation of process in terms of their ROI in comparison with other enhancement and new
technology solution.
component. 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.
1 Pseudonym.

IT Practice

Architecture 83
Management
Architecture
Management 84
BALANCE PROCESS MATURITY AND AUTOMATION (continued)

1
Alpha’s Balancing Process Maturity and Automation (Continued)

Using Process Analytics to Inform Technology Roadmaps
Steps Key Activities and Tools

1. Create an IT Business Process
Mapping (BPM) team.
■■ Identify business process experts within IT.
■■ Adopt a BPM methodology.
■■ Select BPM tools.
2. Select pilot BPM projects.

■■ Work with customers to select processes to improve.
■■ Create IT–business pilot teams.
■■ Map each process.
■■ Use iterative development to execute process improvements.
1 Pseudonym.

IT Practice

BALANCE PROCESS MATURITY AND AUTOMATION (continued)
1
Alpha’s Balancing Process Maturity and Automation (Continued)

Using Process Analytics to Inform Technology Roadmaps (Continued)

3. Create a BPM Center of Excellence.
■■ Use data from pilot projects to obtain customer
and management buy-in.
■■ Create BPM governance structure.
■■ Create a BPM training program to deepen talent bench.
4. Expand scope of BPM.

■■ Select initial projects with similar criteria to pilot projects.
■■ Tackle increasingly complex projects as maturity deepens.
■■ Automate mature processes.
1 Pseudonym.

IT Practice

Architecture 85
Management
Architecture
Management 86
Support Service Reuse

DirectTV’s Deriving Maximum Value from Existing Technical Services
Partial Root-Cause Analysis of SOA Challenges
Objective Challenges Subchallenges Solutions
1
Narrow down the scope of data
It’s hard to know which data
standardization efforts to only the data
to standardize.
elements used by services.
Lack of consistent data 2 Create standard data definitions in the

standards and definitions It’s hard to gain consensus
middle layer (the canonical data model),
on standard data formats
rather than resolving standardization
and definitions.
decisions across databases.
3 In addition to identifying commonalities

Improve the value
It’s hard to identify service in service usage, analyze patterns in
of existing technical
consolidation opportunities. input and output data used by services
services (SOA).
to simplify rationalization decisions.
4
It’s hard to set the right Introduce composite services based
level of service abstraction on reoccurring data and service usage
Too many redundant, low (granularity). patterns.
ROI services
5 Minimize disruptions in knowledge

It’s hard to ensure service transfer about service usage among
reusability. design teams through modular service
training.

IT Practice

Support Service Reuse (continued)
DirectTV’s 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 Integrate data into
allow provider databases to retain the canonical data model.
local variations in definition.

IT Practice

Architecture 87
Management
Architecture
Management 88
Support Service Reuse (Continued)

2. Resolve Key Data Inconsistencies
Type of Data
Example—Customer Data Action
Inconsistency
Database A Database B Define master data standards in the

1. F
ormat: Inconsistent
canonical data model and resolve
way of recording John Smith Mr. Smith,
inconsistencies between provider systems
identical data elements John
through the middleware.
Database A Database B Identify quick-wins in data quality

2. Value: Inconsistent
improvement through an analysis of data
data inputs due to poor John Smith John Smit
elements most frequently evoked by
data quality
services.
3. D
efinition: Inconsistent Database A Database B Map consumer systems data definitions
definitions of what a to master data standards in the canonical
John Smith Alpha
data element means data model.
Company Inc.

IT Practice

3. Maximize the Value from Existing Services
Filter 1: Service usage commonalities— Filter 2: Data input and output patterns—
Identify a group of services that perform Identify commonalities in data inputs and
the same action (e.g., look up customer outputs passed between consumer and
profile). provider systems.
Service Input and Output Data Elements1

Service Name Service Description
Customer
(Old Services) Phone Customer Account
Name Address Phone ID Payments
ID Status
1. Look_up_ Provides customer information
1. L
ook_up_ Provides customer information. I I I O O
customer I I I O O
customer
2. A ccess Retrieves customer account
2. Access Retrieves customer account. I I O O
Account I I O O
Account
3. customer3.2 Modifies customer or account
3. customer3.2 Modifies customer or account I I I O I
information I I I O I
information.
4. A
ctivation Activates access to new
I O I O O I
products or services
5. vz3_billing Submits customer order for
I I O O I
billing
I Input data 1. Standardization opportunity

An area where a consolidated
O Output data
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
1 Illustration only; a data element can be both an input and an output from a service.

IT Practice

Architecture 89
Management
Architecture
Management 90

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
Composite Service Example: A customer Integration Service
calls the DIRECTV customer service line to Data Called by a
add additional channels to her subscription. Consumer System
Service Name Service Description Data Elements in the Canonical Data Model
(New Services) Customer Account Product Service Orders Subscriptions
1. C
ustomer Provides customer
Information information
2. V
erify Product/ Retrieves the products
Service and/or services a customer
Eligibility is eligible to purchase
3. Update Modifies customer account
Account information
4. Verify Address Confirms customer address
information
5. Process Order Submits customer order
for billing
6. A
ctivate Activates access to new
Account products or services

IT Practice

5. Promote Continuous Service Education
Key Questions in Integration Training Tool What Does It Provide? Benefits Key Elements
Process Flow
1. H
ow do I use integration Integration Services An introduction to the Defines “rules of engagement” Common elements and features
services? Usage Guide services ecosystem for using all integration and across all services
services
2. Which set of services are Consumer System An access agreement Ensures alignment with ■■ A mapping of business
available to me? Usage Guide into a suite of services workflows supported by processes and services a
exposed for a specific the consumer system consumer system is eligible
consumer system to use
■■ Service-specific information
such as default expiration
time, usage pattern
(synchronous, asynchronous,
fire and forget, etc).
3. H
ow do I use a specific Service-Specific A set of detailed Minimizes ambiguity around Standards for input data,
service? Interface guidelines on how to how to use a service output data, return messages,
Agreement1 use a specific service configuration)
4. H
ow do I know the service I Event Notification A set of specifications Enables quick asynchronous ■■ Notification standards and
used worked as intended? Specification for input data, communication between guidelines
Document2 return messages, consumer and provider ■■ Required versus optional
and configuration systems on whether a
message communications
information for particular transaction
asynchronous services succeeded or failed
1 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.
2 Event Notification Specifications are not used for synchronous services.

IT Practice

Architecture 91
Management
Architecture
Management 92

IT Practice

Section 6: Designing
for Usability

IT Practice

Designing 93
for Usability
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 Develop a deeper understanding of customers’ technology use, needs, and
workers’ workflows. expectations to bridge business sponsors’ strategic requirements with end
users’ functionality needs.
LexisNexis’s Uncovering Unarticulated Needs • 95
Capture knowledge worker pain points in the form of problem statements Standard Chartered’s Leveraging End-User Data to Proactively Deliver
that correlate to the impact on productivity. Tie productivity roadblocks to a Solutions • 100
knowledge worker role objectives to surface business transformation needs Standard Chartered’s Applications function develops a deeper understanding
for translation into technology design. Prioritized productivity roadblocks of customers and the demands they place on applications through analysis of
undergo a rigorous solution ideation phase, which results in high-fidelity service tickets and by soliciting ongoing feedback from end users. Standard
wireframes and prototypes that become primary input into subsequent design Chartered understands customers’ technology use, needs, and expectations to
stages. bridge business sponsors’ strategic requirements with end users’ functionality
When to Use needs.
■■ To surface end-user needs and translate them into technology design When to Use
■■ To create a technical solution design tied to end-user productivity
■■ To develop customer intelligence to increase end-user efficiency
improvements ■■ To recommend end-user workflow and usability improvements
■■ To bridge business sponsors’ strategic requirements with end users’

functionality needs
Improve System Usability Essential Reference Specialized
Accurately isolate the cause of performance lapses due to system

performance, user behavior, or business process health.
Kimberly-Clark’s Usability Leading Indicators • 98

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

Design for the End User
LexisNexis’s Uncovering Unarticulated Needs
Problem Statement for a New Business Development Junior Executive
Illustrative
1. Direction 3. Outcome
Impact on
Minimize… …the number of …to free up time to
Knowledge
interruptions I have identify new opportunities = Worker
during my work day… to find new clients.
Productivity
2. Unit of Measure
Problem-to-Objective Mapping
Illustrative
New Business Development Junior Executive Importance Satisfaction Difficulty

Role 1. Improve my daily work experience by extracting the most relevant information in the
9.5 6.5 High
Objective shortest amount of time to work efficiently and manage time effectively.
Relevant a. Minimize the number of interruptions I have during my work day to free up time to identify new opportunities to find new clients.
Problem
Statements 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
8 6.3 High
myself and build a book of business.
a. Minimize the time it takes to build and bring in a book of business to improve my performance against goal.
Importance: 1–10 Satisfaction: 1–10

1—Not at All Important 1—Not at All Satisfied
10—Very Important 10—Highly Satisfied
1 Anthony Ullwick, What Customers Want: Using Outcome-Driven Innovation to Create Difficulty: High/Medium/Low
Breakthrough Products and Services, New York: McGraw Hill, 2005.

IT Practice

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

LexisNexis’s 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.”
Medium Difficulty
Importance of the Objective
Knowledge Worker Objectives

Identified as “Knowledge
Worker Imperatives”
Other Knowledge Worker
2. “Identify an interesting market
Objectives
that would allow me to grow
the business by 10%.”
Importance: 1–10
3. “Widen my network of business contacts to start 1—Not at All Important

marketing myself and build a book of business.” 10—Very Important
Less Important Satisfaction: 1–10

High Low 1—Not at All Satisfied
Satisfaction with the Current Solution(s) 10—Highly Satisfied

IT Practice

Design for the End User (CONTINUED)
LexisNexis’s Uncovering Hidden Productivity Improvement Opportunities (Continued)
Knowledge Worker Imperative-Driven Design Process
Pre-Feature Feature Design

Solution Project
Assessment Assessment Roadmap
Ideation Kickoff
Session Session (FAS) Update
Input Process Output
■■ Knowledge worker Knowledge Innovation Technical ■■ Design documents

imperatives Workers Team Teams
■■ High-fidelity wireframes
■■ Customer ■■ Enterprise
■■ Voice of the knowledge
Advocate Architects ■■ High-fidelity service
worker (e.g., interview Product Domain
■■ ■■
prototypes
scripts and recordings) Champion Architects
■■ User-Experience
■■ Initial solution concepts
■■ Problem statements
Team
associated with the ■■ Prototyping
knowledge worker Team
imperatives

IT Practice

Designing 97
for Usability
Designing
for Usability 98
Improve System Usability

Kimberly-Clark’s Usability Leading Indicators
Preemptive Performance Tracking
Poorly Designed Poor System

Potential Problems Inefficient Use
Business Process Performance
Is performance
degradation due
to user inefficiency?
Is the business Is the system Does the user know Is the application
Key Questions process itself performing how to use the too difficult to
inherently inefficient? as it should? application correctly? use correctly?
Confirming Metrics
Error frequency Average end-to-end
1 5 9 Number of errors per user
by business process response time
Number of processes Error frequency by functionality
User Experience Metrics 2 Time spent per screen 6 10
executed usage
Ratio of number of processes
3 7 Average process duration 11 Error frequency by error type
completed versus aborted
Ratio of actual completion time Cumulative user sessions Ratio of process “active”
4 8 12
versus best practice by hour of day time versus “idle” time

IT Practice

Improve System Usability (continued)
Kimberly-Clark’s Usability Leading Indicators (Continued)
Usability Root-Cause Analysis
Too High
Level One If “yes,” then proceed Too Low

Poorly Designed Business Processes
Level Two If “yes,” then proceed

Is the business process efficient?
Poor System Performance
1 Error frequency by business Level Three

Is the system performing as it should?
processes Inefficient Use
5 Average end-to-end Is the application being used efficiently?

2 Time spent per screen
response time
3 Ratio of number of processes

6 Number of processes executed 9 Number of errors per user
completed versus aborted
4 Ratio of actual process 10 Error frequency by functionality

completion time versus 7 Average processes duration
usage
best practice
8 Cumulative user sessions by

11 Error frequency by error type
hour of day
12 Ratio of process “active” time

versus “idle” time
Patterns of values (signatures) indicate
likely reason for performance lapse.

IT Practice

Designing 99
for Usability
Designing
for Usability 100
DEVELOP CUSTOMER INTELLIGENCE

Standard Chartered’s 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 End-User Portal
■■ Relationship/
■■ Functionality
engagement ■■ Usability
quality ■■ Workflow
■■ Fit of existing
Improvements
solutions
■■ Understanding of
business issues

IT Practice

DEVELOP CUSTOMER INTELLIGENCE (continued)
Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions (Continued)
2. Recommend Workflow Improvements
Analyze Service Ticket Data to Achieve Valuable Service Outcomes
Error Type Error Impact Source User Group Frequency
Application Access Low Missing Call center 10x/30 days

functionality failure (< 5% patch technicians
of users)
Analyze
Service Business Incorrect High Poorly Business 21x/30 days
Ticket process report (> 25% mapped unit A line
sequencing of users) process managers
Data
User Failed High Missing data Market 13x/30 days
database (> 25% field and set researchers
query of users)
Look for
Leading Number of errors per user group Error frequency by business process
Indicators
Enhance End-User Performance Business Process Improvement
Service Identify enhancement and/or

Outcome Review business process errors
customization opportunities
to locate inefficiencies and identify
as prioritized and identified
solutions.
by end users.

IT Practice

Designing 101
for Usability
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: Portal Service Analysis

Deliver analysis to ■■ Payroll data only in US dollars ■■ Current payroll system rules and
sponsor. ■■ No foreign deduction calculations presentation interface do not align
with the business’s strategic needs.
3. Solution Delivery Analysis

Team: Provide
■■ Adding data tables solves short-term need.
recommendation
■■ Additional data tables don’t simplify user interface.
based on sponsor
■■ Adding data tables increases current system complexity
and end-user analysis.
and likelihood of service failures and loss in productivity.
4. Solution Delivery Recommendation

Team: Provide ■■ Adopt new payroll solution that includes country-specific
recommendation
extensions to the core application.
to sponsor.
5. Business accepts
solution.

IT Practice

DEVELOP CUSTOMER INTELLIGENCE (Continued)
Process 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
■■ Build a web-based solution portal where employees
to create a robust view can submit questions, suggestions for new functionality,
of customer needs and and applications enhancement requests.
priorities. ■■ 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 103
for Usability
Designing
for Usability 104
DEVELOP CUSTOMER INTELLIGENCE (continued)

Process Steps (Continued)

3. M
ine maintenance and support
data to proactively identify
■■ Build a retrievable storage system for incident reports
service opportunities. 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.
4. B
uild credibility by viewing
every customer interaction
■■ Provide customer relationship training to all staff members.
as a service opportunity. ■■ 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.

IT Practice

Section 7: Communications
and Change Leadership

IT Practice

Communications and 105

Change Leadership
Communications and
Change Leadership 106
COMMUNICATIONS AND CHANGE LEADERSHIP

Develop Attributes of an Effective BA Essential Reference Specialized
Engage and challenge business sponsors’ assumptions.
Establish Effective Communication with Business Leaders
Potential Attributes of an Effective Business-Facing IT Professional • 108
Communication strategies need to be tailored to business leaders’
Many of the attributes required in sales roles are increasingly applicable to
temperaments and posture toward project change and their degree of
business-facing IT professionals.
influence on project outcomes.
When to Use
To develop skills and behaviors of an effective BA
■■
Communication Challenges with Business Leaders • 114
Essential Reference Specialized 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
Representative Profiles • 109
projects.
Like sales reps, BAs may adopt the profile of either a Challenger® or a
Relationship Builder. When to Use
■■ To understand behavioral temperaments of the business sponsor
When to Use
To understand how different behaviors affect engagement outcomes
■■

Deconstruction of a Compelling Teaching Pitch • 115
Critical Attributes of Challengers • 111 A compelling teaching pitch reframes initial assumptions, showing underlying,
Typically Relationship Builders are focused on resolving tension and creating unanticipated problems and building confidence in IT’s ability to deliver a new
a more collaborative, agreeable environment. On the other hand, Challengers solution.
succeed because they can teach, tailor, and create constructive tension with When to Use
the sponsor. The Challenger’s success is based on the abilities to teach for ■■ To build confidence in your ability to deliver a new solution
differentiation, tailor for resonance, and assert control. ■■ To build effective communication skills
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

COMMUNICATIONS AND CHANGE LEADERSHIP (Continued)
Customer Outcomes Map • 117 Coca-Cola’s Building Transparency in Communications • 121
BAs should tailor their communication approach based on how individual Coca-Cola fosters collaboration with business partners by communicating
sponsors define success in their job, in terms of activities, metrics, or cost and risk information business partners need to make decisions.
direction of outcome. When to Use
When to Use ■■ To improve conversation about business needs and options and cost-
■■ To understand business sponsor’s definition of success performance trade-offs.

■■ To tailor communication approach based on sponsor’s context and
outcomes Essential Reference Specialized

Plan Change Management Activities
Target change communications based on stakeholder priorities
Negotiation Roadmap • 119
The negotiation roadmap demystifies the behaviors of highly successful NetApp’s Governance Change Management Campaign • 122
negotiators that can be applied for successful negotiations in a low-risk
NetApp identifies how stakeholders’ workflows will change and their concerns
environment.
about the new governance process. They do the following:
When to Use ■■ Address stakeholders’ concerns through targeted messaging of key
To develop effective negotiation skills

■■
benefits.
■■ Educate business executives about the initiative at governance forums and
senior staff meetings.
■■ Create a company-level “umbrella message” about the governance process
Cisco’s High-Risk Stakeholder Communication Plan • 120 change and ensures specific messages for each stakeholder align with it.
Cisco builds holistic stakeholder profiles capturing detailed information about When to Use
■■ To effectively engage in change management activities
stakeholder expectations and communication preferences. This information is
■■ To develop consistent messaging for change initiatives
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

IT Practice


Change Leadership
Communications and
Develop Attributes of an Effective BA

Potential Attributes of an Effective Business-Facing IT Professional
Attitudes Skills and Behaviors Activities Knowledge

■■ Leverages Support ■■ Professional Image ■■ Can Explain ROI ■■ Product Knowledge
■■ Interest in Feedback ■■ Explores All Options ■■ Meeting Preparation ■■ Industry Knowledge
■■ 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
■■ Wants to Manage Company ■■ Requests Assistance
Outcomes ■■ Forms Good Partner Relationships
■■ Company Attachment ■■ Has Advocates in Partners
■■ Can Work with Anyone ■■ Good Cross-Functional
■■ Genuine Relationships
■■ Accessible to Partners ■■ Ability to Work
■■ Passionate About Customers with the Team
■■ Flexible ■■ Respects Partner Time
■■ Strategic Agility
■■ Manages Expectations

IT Practice

Develop Attributes of an Effective BA (Continued)
Representative Profiles
The Challenger® The Relationship Builder The Hard Worker Others

(27% of Sample) (21% of Sample) (21% of Sample) (32% of Sample)
■■ Always has a ■■ Builds strong ■■ Always willing to

different view advocates go the extra mile
of the world in customer ■■ Doesn’t give
■■ Understands the organization up easily
customer’s business ■■ Generous in giving ■■ Self-motivated
■■ Loves to debate time to help others ■■ Interested in
■■ Pushes the customer ■■ Gets along with feedback and
everyone development
n = 683 sales reps.
Note: Numbers do not equal 100% due to rounding.

IT Practice


Change Leadership
Communications and

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 Relationship Builder Hard Worker
■■ Knows Customer Value Drivers ■■ Forms Good Customer ■■ Motivated by Goals

Relationships
■■ Offers a Unique Perspective ■■ Discretionary Effort
■■ Has Advocates in Customers
■■ Can Discuss Money ■■ Outcomes Focused
■■ Attachment to the Company
■■ Two-Way Communication Skills ■■ Tenacity
■■ Can Work with Anyone
■■ Can Identify Customer Economic ■■ Project Management Skills
Drivers ■■ Genuine ■■ Leverages Support
■■ Can Pressure Customer ■■ Good Cross-Functional ■■ Preparation Before Calls
Relationships
■■ Can Pitch Strategy ■■ Follows Formal Sales Process
■■ Accessible to Customer
■■ Product Knowledge ■■ Curiosity
■■ Gives Time to Help Others
■■ Knows How Customers ■■ Interest in Feedback
Differentiate ■■ Respects the Customer’s Time
■■ Learns Everything New
■■ Industry Knowledge
■■ Evaluates Likelihood
■■ Can Explain ROI of the Sale of Purchase
■■ Professional Image ■■ Experiments with Sales Approach
■■ Explores All Options Before ■■ Requests Assistance
Closing
■■ Generates Leads or Prospects
■■ Wants to Manage Company
Outcomes
Source: Integrated Sales Executive Council’s Rep Skills Diagnostic.

IT Practice

Critical Attributes of Challengers
Challenger Builder Profile Relationship Builder Profile
The Challenger profile focuses on building The Relationship Builder profile focuses on
constructive tension in interactions to push resolving tension in interactions to make
customers out of their comfort zone. situations more amicable and positive and
encourage collaboration.
■■ Offers unique perspective ■■ Forms good relationships

Gets
■■ Has two-way communication Teaches ■■ Builds customer advocates Along
skills with
■■ Builds cross-functional
Others
relationships
■■ Knows customer value drivers
Tailors
■■ Can identify economic drivers ■■ Can work with anyone
Likeable
■■ Is genuine
■■ Is comfortable discussing money
Asserts
■■ Can pressure the customer Control ■■ Is accessible to the customer
■■ Gives time to help others Generous
with Time
■■ Respects the customer’s time
Implication for the Applications Function
To build Challenger skills, focus on helping business-facing Applications staff teach, tailor, and assert control.

IT Practice


Change Leadership
Communications and

Critical Attributes of Challengers (Continued)
Teach: Reframe Teach for

the way business Differentiation
partners view their
business and their
needs.
Tailor: Link your Tailor for Assert Assert Control:

capabilities to business Resonance Control Openly pursue goals
partners’ individual in a direct but not
goals. aggressive way.
The New High

Performer
Questions to Consider
What should my business-facing How do I get my business-facing How do I get my business-facing How can I change the behavior
Applications staff teach? Applications staff to tailor? Applications staff to assert of business-facing Applications
control? staff?
Source: Integrated Sales Executive Council research.

IT Practice

Critical Attributes of Challengers (Continued)
Passive Assertive Aggressive
■■ Subverts goals to the needs ■■ Directly pursues goals ■■ Pursues goals at the expense
of others in constructive way of professionalism
■■ Allows personal boundaries ■■ Defends own personal ■■ Attacks others’ personal
to be breached boundaries boundaries
■■ Uses indirect, accommodating ■■ Uses direct language ■■ Uses antagonistic language
language
Sales Performance Problem Common Sales Leadership Fear
Reps are often too passive with Tell sales reps to be more assertive
customers, seeking to resolve and they may become aggressive.
conflict whenever possible.

IT Practice


Change Leadership
Communications and

Communication Challenges with Business Leaders
Characteristics Differentiation
Personality ■■ Personality traits account for differences in ability to communicate with others, propensity
to seek guidance and help, and ability to make decisions.
Views of ■■ Business leaders differ in their views about how technology plays a role in their function/
Technology company role.
Investments ■■ Some view technology investments as critical to strategic outcomes, others as ancillary,
and still others as irrelevant and not worth their time.
Likely Reaction ■■ Standard engagement strategies from Applications and not received in standard ways by
to Engagement 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.
Values ■■ 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.
Career Past ■■ 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.

IT Practice

(Continued)
Deconstruction of a Compelling Teaching Pitch
…then building back the
Teaching follows boot customer’s confidence
camp theory of shocking in a new solution.
Positive the customer with the
unknown… 6. “Our
Solution and
Implementation
Map”
2. “Reframe”
“Emotometer”: Level of Customer Excitement
Map of supplier
First reframing
…breaking down the problem services or
of unrecognized solutions linked
problem, need, or behind the unknown…
back to key
assumption teaching points;
highlighted path
3. “Rational 5. “Value to implementation
1. “Warmer” Drowning” Proposition—
Building credibility Gradual A New Way”
by reading intensification of Delivery of a new
Neutral their mind and the problem, both framework for
demonstrating in degree and addressing the
empathy closeness to the problem; implicitly
customer tied to the supplier
4. “Emotional value proposition
Impact”
Description of
the psychological
features of the
problem, or
presence in the
individual’s workflow,
humanizing the
problem
Negative
Intrigued Drowning Involved Relieved

Customer State

IT Practice


Change Leadership
Communications and

(Continued)
Teaching Do’s and Don’ts
DON’T DO
Open with the breadth of your Open with a focus on the customer
product portfolio and capabilities. and their issues.
Discuss how long your company Reframe customers’ understanding

has been in the marketplace. of their world.
Focus on features and benefits. Make the sale personal and provide
value to that individual.
Lead with your unique strengths. Lead to your unique strengths.

IT Practice

(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
■■ Regulatory Compliance Risk

Features Risks ■■ Business Continuity Risk
■■ Information Security Risk
■■ Hitting Cost and Scope Target

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

Price Effort Required
Required ■■ SME Time

IT Practice


Change Leadership
Communications and

(Continued)
Concept Definition
Customer Outcomes
What an individual customer
is trying to achieve—how they
would define success in their job
Activity or responsibility Metric used to Direction and magnitude

in need of improvement measure success of change necessary

IT Practice

(Continued)
Negotiation Roadmap
Acknowledge Deepen Explore Concede

and Defer and Broaden and Compare According to Plan1
Promise closure and seek Expand potential solution Prioritize solution components Create plan and exchange value
permission to have a different components by surfacing areas by estimating their relative value instead of giving it away.
conversation. of additional value. to the customer.
1 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


Change Leadership
Communications and

(Continued)
Cisco’s High-Risk Stakeholder Communication Plan
Illustrative
Customized project messages are developed and
Type of stakeholder drives cataloged in advance. Key messages include the following: Similarly themed messages are
the nature of communication ■■ Elevator Speech tailored for audience seniority,
plan and the degree of ■■ What’s in It for Me? level of detail required, and
customization required. degree of change resistance.
■■ Change Posture Pitch
Stakeholder Segment Communications Details Key Message: What’s in It for Me?

High Influence, Target Audience “We recognize the current process
Resistant Posture Senior Consultants, Operations; Operations Back Office Personnel for submitting expense reports
is time-intensive, and turnaround
Communication Goal
time is slow. The new system for
Closely manage expectations; improve change posture.
submitting expenses will require
Change Posture
Supportive
Make or Break
Level of Detail less time for report submission, is

Influential
Impacted
Neutral High-level budget and schedule communication; detailed more accurate, and will expedite
Resistant
functionality communication your reimbursement turnaround
Low Medium High Threats (Real or Perceived) time.”
Degree of Influence Delayed rollout
Preferred Mode
Trigger-based e-mail
High Influence, Target Audience “The financial expense system
Supportive Posture Executive Sponsor; Project Sponsor upgrade will help us achieve
three major goals. It will enhance
Communication Goal
our financial tracking capability
Closely manage expectations; maintain change posture
for better budget control. The
Change Posture
Supportive
Make or Break
Level of Detail upgrade will bring us up to

Influential
Impacted
Neutral High-level budget and schedule communication; medium-level compliance standards for the
Resistant vendor performance communication next two years. And the more
Low Medium High Threats (Real or Perceived) efficient employee submission
Degree of Influence Inadequate user training process will offer productivity
gains.”
Preferred Mode
Weekly status updates; trigger-based phone call

IT Practice

Establish Effective Communication with Business
Leaders (Continued)
Coca-Cola’s Building Transparency in Communications
Information A Transparency Deficit Clarifying the Facts

System Change ■■ IT plans system changes based on ■■ Ideal timing for systems changes
Management its own time schedule, without full is coordinated with business and
visibility of the impact on business determined by capacity to absorb
processes. change.
Cost–Benefit ■■ IT makes assumptions about the ■■ IT presents solution options and

Analysis business’s cost tolerance and narrows lifecycle costs so that business can
options accordingly. make the appropriate trade-offs
between cost and performance.
Interdependency ■■ IT acts as an intake for business ■■ IT factors dependency risks into

Risk demand, managing dependency the business case for investment,
risk as an internal IT matter. giving business partners visibility on
downstream and upstream impact.
Capability ■■ IT responds to all breakdowns ■■ IT prioritizes its response to service

Investment according to SLAs. disruptions according to business
Prioritization context and criticality.
IT often underappreciates or is unaware IT is proactive in sharing the inputs

of the decision-making relevance to that business partners require to
business partners of critical pieces of make decisions affecting business
information. performance with full knowledge
of cost, risk, and available options.

IT Practice


Change Leadership
Communications and
Plan Change Management Activities

NetApp’s Governance Change Management Campaign
Stakeholder Change in Stakeholder Workflow Potential Stakeholder Key Benefits Messaging

Group Concerns
Senior ■■ For the first time, the right ■■ Processes may not mature ■■ Better visibility on investments and
Management information will be visible up to the fast enough and stunt the returns
CEO level. company’s growth. ■■ Highest priority projects get the
■■ IT may not adequately most attention
support the business.
Business ■■ Need to be more collaborative with ■■ May create more red tape ■■ Increased alignment of investments
Executives IT and Finance in planning and reduce responsiveness to functional strategies
■■ Need to align with the new ■■ Higher thresholds of investments
governance models at the cross-functional council level
approved by business units
■■ Only approved projects will
get done
IT Executives ■■ Share accountability for ensuring ■■ Resistance to adoption ■■ Transformation of PMO from a
rigorous portfolio prioritization. policing to an enabling organization
■■ Investments better grouped and
easier to manage
Account ■■ Need to own the planning process ■■ More bureaucracy that ■■ Fewer fire drills regarding portfolio
Managers and the transition to project delivery slows down work and annual planning
Project ■■ Update cost–benefit analysis ■■ More process steps to ■■ Easier to communicate with business
Managers template at every project stage gate. comply with partners about projects due to
consistent processes
Process ■■ Process owner approval no longer ■■ Lower involvement in ■■ Visibility into project pipeline and
Owners required in project selection due to decision making notification of changes
streamlined oversight when they occur
Anticipate potential pushback against the new process

by considering each stakeholder’s concerns and tailors
change management messaging accordingly.

IT Practice

Plan Change Management Activities (Continued)
NetApp’s Change Management Campaign Plan (Continued)
Communication Content Audience Audience Time

Type Commitment
Weekly E-Mails ■■ Provide context for changes, updates, and action items. End Users and 10 minutes
Business Leaders
■■ Provide visibility on upcoming events.
Capability ■■ Provide training on using new governance and cost Early Adopters 2–5 hours
Training tracking/cost–benefit analysis capabilities. and Trainers
Webinar ■■ Provide an overview and set context for rollout End Users and 1–2 hours
capabilities. Business Leaders
Brown Bags ■■ Provide an overview of the complete end-to-end process. 20+ “Phase 1” 3 hours
End Users in 1
■■ Walk through the project lifecycle and finance process.
Location
■■ Provide opportunity to ask questions and hear from others.
One-on-One ■■ Show how to complete the cost–benefit analysis template. 20+ “Phase 1” 2–3 hours
Working End Users in 1
■■ Answer questions and provide any additional guidance.
Sessions Location
Webinar ■■ Provide an overview of project lifecycle and change order End Users and 2 hours
go-live elements. Business Leaders
Adoption ■■ Assess end-user understanding and concerns. End Users 30 minutes
Survey
Focus Groups ■■ Identify adoption risk areas. 6–8 Selected 1 hour
SMEs per
Location
Roadshows ■■ Provide update on status. End Users 2–3 hours
■■ Share results of adoption evaluation.
■■ Gain input, field questions related to Q1 rollout and future.

IT Practice


Change Leadership
Communications and

IT Practice

Section 8: Business
Relationship Management

IT Practice

Business Relationship 125

Management
Business Relationship
Management 126
BUSINESS RELATIONSHIP MANAGEMENT

Build an Engagement Strategy • 127 Help Sponsors See Risk and Value Trade-Offs • 136
Tailor engagement to business leaders’ preferences for risk, benefit, and Clarify risk and value trade-offs.
effort in IT projects.
Business executives fall into four temperaments based on their preferences CareFusion’s Clarifying Risk and Value Trade-Offs
and trade-offs for risk, return, and effort in Applications projects. Apply CareFusion’s simple framework to help business leaders’ visualize risk
These pages outline the types of business leaders by temperament and the and value trade-offs. Such a tool is part of the education/consultation for
defining characteristics of each type. business leaders who want to take a more active leadership role in IT projects.
When to Use When to Use

To understand business leaders preferences for project risk and return effort
■■ To evaluate business leaders’ risk and value preferences
■■
Essential Reference Specialized Essential Reference Specialized
Understand Business Sponsors’ Temperaments • 135 Track Changing Business Priorities • 137

Four elements—sensitivity to benefits, aversion to risk, desire for control, Attain an enterprise wide view of changing business priorities.
and measures of success—define a unique business leader temperament.
CareFusion’s Business Trends Insight Map
These pages highlight a strategic guide to identifying business leader
Use CareFusion’s “insight map” approach to capture trends across business
temperaments and key probing questions to identify a business leader’s
leaders that are valuable to Applications’ strategic planning and demand
profile.
management.
When to Use
When to Use
To tailor communication approach based on sponsor’s profile
■■
■■ To create an enterprise-wide view of changing business priorities


IT Practice

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 returns—each defines
how individuals measure success.
Lure of Returns
Each temperament displays
The strength of the belief that one’s a distinct behavior on each
self-management of a project is of these dimensions, with
each having a unique profile
necessary to capture returns
based on these dimensions.
Preferences Success Measures

Aversion to Risk along
these three How a person views and
How willing a person is to take
dimensions measures past successes
on increased risk in self-managing
drive success and defines success for
a project
measures. a future project
Desire for Control

How important self-managing
IT projects is to an individual

IT Practice


Management
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 The
Opportunists Entrepreneurs
51% 23%
The The
Abdicators Cowboys
11% 15%
Low High
Willingness to Self-Manage Solution
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
Openness
Low High
to Persuasion
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
Low
Psychographics
■■ Avoiding management of IT projects at all costs
■■ Unswayed by the lure of high project returns ■■ Can be lured by high returns to self-manage projects
Top Concern
■■ Avoiding risky IT projects at all costs
Top Concern
■■ Want to protect their time above all else
Demographics
■■ 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; Can look like Cowboys but have more rational desire to control
impatient 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 ■■ Will do it themselves for higher returns, even if taking on risk
■■ Will do what it takes to attain business outcomes
Top Concern
Top Concern
■■ Speed to market most important motivator
Demographics
High ■■ Most concerned about achieving business case/outcomes
Demographics
■■ Typically have 16 to 25 years of experience
■■ Typically have 16 to 25 years of experience

IT Practice


Management
Management 130

Engaging the Abdicators
The Abdicators
Sensitivity to Returns
“I’d rather stick to my day job. I’m 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 it’s easy to use—that’s a success.”
Driver: Abdicators only want to focus on their Toughest Scenario—Traditional Engagement

domain of expertise and are uninterested in it Practical Example: You are having difficulty in
projects. securing business leaders’ input on an IT–led project
where you need active business sponsorship.
Challenger Response
Teach Tailor Assert Control
■■ Tie Engagement to ■■ Tie Project Success to the ■■ Use Their Time Efficiently:
Regulatory or Strategic Success of Their Daily Work: Explain what you will do to
Risks: Give examples of how Abdicators want to focus respect their time and use it
the Abdicator’s personal on their domain only; tie efficiently.
engagement will lower risks on engagement to project success
corporate-level issues larger and how that will improve their
than the project and closer to ability to work.
his or her daily concerns.

IT Practice

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
“I’m proud of my track record. If things go smoothly and I learned something, it was a success.”
Driver: Opportunists overestimate the risks Toughest Scenario: Bolstering Their Confidence
or underestimate the possible returns Practical Example—Concerned with potential risks, a
from self-management. 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
■■ Have Concrete Examples: Explain ■■ Plan the Main Pain Points: Lay ■■ Provide a Coach: Access to
how risks have been managed in out a concrete support plan up personal support will reassure
the past. front, demonstrating how they them.
can count on Applications if
problems arise.
■■ Explain the Impact of Their ■■ Be Specific: Understand exactly ■■ Address Alternatives: Make
Involvement: Speak about how what they want from a solution, the alternative (Applications-
self-management increases the and tie self-management directly managed projects) less desirable
likelihood of achieving the scope to achievement of those goals. by playing up time delay and
or speed to market they desire. increased risk of missing business
case or of not achieving scope.

IT Practice


Management
Management 132

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 there’s risk if we do this, but I can live with that.”
Success Measures
“I’ll never forget that big contract we won back in ’95...”
Driver: Entrepreneurs underappreciate the risks Toughest Scenario: Pulling Them Back from the Ledge
associated with self-management or overestimate Practical Example—A business leader is attempting to
the impact on returns. participate aggressively in a high-return project but is
blind or indifferent to enterprise risk.
Challenger Response
■■ Introduce Strategic Risks: Tie ■■ Amplify Risks: Make expected ■■ Focus on Achieving the Business
the impact of strategic risk, returns seem less than expected Case: This is Entrepreneurs’
such as customer information risks from self-management. greatest concern. Discuss how
loss or brand damage, directly they need Applications’ help to
to Entrepreneurs’ expressed reach that goal.
business objectives.
■■ Make Use of History: Use
concrete examples of past
situations or projects where
similar risks have caused project
failure.

IT Practice

Engaging the Cowboys
The Cowboys
“We can’t wait for IT. We need to move on this now.”
Aversion to Risk
“I don’t need any help in managing this project. I have all the people and resources I need.”
Success Measures
“People didn’t think we could do it, but we pulled it off.”
Driver: Cowboys distrust Applications’ ability Toughest Scenario: Reigning in Risk

to meet their needs. Practical Example—A 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
■■ Correct the Past: Acknowledge ■■ Diminish Speed Expectations: ■■ Infiltrate the Team: Find a key
any past failures, if they exist, Tie risks and complexities of lieutenant and win him or her
and explain what steps have a “go it alone” approach to over to help make your case.
been taken to improve. schedule and speed-to-market
impacts.
■■ Govern: If all else fails, govern
by going to a higher authority
and explaining what is at risk.

IT Practice


Management
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 ■■ They emphasize how smoothly past successes went and show pride in meeting
initiative and answers. expectations.
Toughest Scenario Toughest Scenario

■■ It is difficult to engage them on a traditionally run project. ■■ They are scared of risks when Applications does not have resources to pursue
their opportunity.
Do
■■ Use their time efficiently. Do
■■ Tie their effort to high-risk avoidance. ■■ Address their specific fears, offering concrete steps you or they can take.
■■ Tap into their concerns about regulatory compliance. ■■ 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 Opportunists; they are not very motivated by returns Beware of
and cannot be persuaded to self-manage. ■■ 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 ■■ They measure past success mostly by the size of the outcome.
initiatives.
Toughest Scenario
Toughest Scenario ■■ They gamble with enterprise risks to chase high returns.
■■ They are putting the enterprise at risk and simply will not listen.
Do
Do ■■ Amplify their perception of risks they have expressed concern about.
■■ Find their key lieutenant and win him or her over. Try to win over the Cowboy’s ■■ Introduce new strategic risks to them, e.g., loss of customer information, direct
team. financial loss, and brand impact.

■■ If all else fails, govern. Go to a higher authority and explain what is at risk. ■■ Connect risks concretely to not achieving the business case.
Beware of Beware of
■■ Confusing them with the Entrepreneur; their eagerness is fueled by a desire ■■ Confusing them with the Cowboys; Entrepreneurs actually can be reasoned with
to control, and they will not listen to Applications. and persuaded.

IT Practice

Understand Business Sponsors’ Temperaments
Business Leader Discussion Guide
Decision Factors Framing Language Discovery Questions What to Listen For
“I typically ask people four things to ■■ What is the greatest success so far in your career? You are trying to understand how they
make sure we use our resources in the ■■ How did that project come about for you? measure success and what motivates them
way they’ll most benefit from. One is ■■ Why was it important to the company? to get involved. There is an opportunity
Success Measures
to understand the background and ■■ What was the benefit to you? here to get them to talk about how they’ve
experiences they’re bringing to the table. ■■ Was there a point during the project when the risks viewed or handled trade-offs in the past, in
It’s likely a lot.” started to seem high to you? a subject area that is comfortable for them.
“Second, I need to understand your ■■ Where are you in the project lifecycle? You are seeing how impatient or passive
thinking about how you’d like to finish ■■ In your ideal scenario, how much support would you they are, how much they worry about things
the project from here, and how you’d like from us on this? they don’t know, and what their first instinct
prefer to be working with us and with ■■ Do you feel prepared for conversations with IT vendors? is about ceding control.
Control
your 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?)
“Third, I need to understand what your ■■ Why is this something you’ve identified as a priority? You are looking for the amount of thought
vision is for this project to help me adopt ■■ Whose idea was this and why are you working on it? they’ve put into understanding potential
your views of the benefits and work with ■■ What does the company (or your group) expect to benefits the degree of excitement they have
Benefits
you to get to the outcomes you envision.” get out of the project? about the benefits, and how attached they
■■ What do you hope to get out of the project? are to a vision for what the solution and
outcome should be.
“Fourth, I need to understand in your own ■■ Have you done something like this before? You are trying not only to gauge what risks
words what your perceptions of the risks ■■ What risks are most worrying you? they perceive, but how they perceive the
here are. I want to know how we can best ■■ What’s at stake for you on this project? magnitude of risk and how they weigh the
Risk complement your skills and experiences ■■ What’s the impact on the project if one of the risks risks against potential benefits personally
here.” you worry about comes to pass? and for the company.
■■ Do you like to figure things out as you go along
or plan up front?

IT Practice


Management
Management 136
Help Sponsors See Risk and Value Trade-Offs

CareFusion’s Clarifying Risk and Value Trade-Offs
Illustrative
1. Strategic Risk to the Company Constraints of a Sample Solution

■■ Loss of sensitive company information
■■ Brand or reputation damage
■■ Direct financial loss
High
4. Effort 2. Business Outcome Attainment Risk

■■ IT and business full- ■■ Likelihood that key functionality is
time equivalent required Low missing or fails to work as intended

for implementation and High High ■■ Sensitivity to schedule delays
maintenance ■■ Sensitivity to budget overruns
■■ Business subject matter ■■ Risk to productivity or revenue

Low
expert time commitment improvements
■■ Estimated amount
of customization
■■ Estimated amount
of integration
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

Track Changing Business Priorities
CareFusion’s Business Trends Insight Map
Illustrative
1. Surge in a Capability’s Importance 2. Major Changes Within a Business Unit 3. Experimentation with a Given Capability
Customer Customer Customer

Data Data Data
Management Management Management
Supply Chain Customer Supply Chain Customer Supply Chain Customer

Management Data Management Data Management Data
Customer Contract Customer Contract Customer Contract

Customer Data Management Customer Data Management Customer Data Management
Data Management Data Management Data Management
Strategic Strategic Strategic Strategic Strategic Strategic Strategic Strategic Strategic

Sourcing Strategic Sourcing Sourcing Sourcing Strategic Sourcing Sourcing Sourcing Strategic Sourcing Sourcing
Sourcing Sourcing Sourcing
Research and Sales and Medical Finance Research and Sales and Medical Finance Research and Sales and Medical Finance
Development Marketing Devices Development Marketing Devices Development Marketing Devices
Potential Actions for Applications Potential Actions for Applications Potential Actions for Applications
■■ Consider an enterprise project. ■■ Revise SLAs for the business unit. ■■ Investigate if there is an unarticulated
need not addressed by existing solutions.
■■ Assess the business case ■■ Revisit investment levels.
for standardization. ■■ Understand business drivers
■■ Reassign staff to project and re-scope
of experimentation.
■■ Revise skills forecasts. job descriptions.
Legend
Experimentation with Experimentation with The direction of

a business capability a business capability importance of
indicates its importance indicates its importance experimentation with
is rising. is diminishing. a business capability
is uncertain.

IT Practice


Management
Management 138

IT Practice

Section 9: Design Team
Relationship Management

IT Practice

Design Team 139

Relationship
Management
Design Team
Relationship
Management 140
Design Team Relationship Management

Drive Team Collaboration and Engagement Intergraph’s Agile Cultural Change Management • 143
Intergraph uses the pulse survey to understand each team’s reaction to the
Periodically assess the key behaviors and perceptions that drive virtual and
new methodology.
Agile team effectiveness to continually improve team performance.
When to Use
Volvo’s Virtual Team Effectiveness Assessment • 141 To understand teams’ perception of change
■■
Rather than focus exclusively on collaboration tool offerings, Volvo applies

NetAge’s 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
Standard & Poor’s Common Delivery Framework for Agile

Development • 142
S&P’s 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

IT Practice

Drive Team Collaboration and Engagement
Volvo’s Virtual Team Effectiveness Assessment
1 3 5
Strongly Somewhat Strongly

Disagree Agree Agree
Goals: How Aligned Is This Team’s Understanding of Goals, Actions, and Expected Results? Teams fall into one of four maturity
levels based on their score:
Cooperative Goals ■■ Everyone has the same picture of overall purpose.
■■ Team discusses, agrees, and reviews clear, simple goals. –– Chaos
Interdependent Tasks ■■ Everyone follows the same process for doing similar work. (1–32)—No shared understanding
■■ Team looks for ways to interconnect and improve work processes. of objectives or contributions of
Concrete Results ■■ Everyone understands the deliverables. individual team members
■■ Team develops and reviews measures and milestones for deliverables.
–– Operational Consensus
Links: How Comfortable Is the Team with Communicating Internally? (33–54)—Focused on methods
Multiple Media ■■ A variety of media is available and accessible. of work and timelines
■■ Team uses collaboration tools consistently and creatively.
–– Team Alignment
Boundary-Crossing ■■ Team has collaboratively established operating agreements that are actively applied. (55–87)—Development of team
Interactions ■■ Team actively implements strategy for engagement across organization boundaries.
relationships to overcome
Trusting Relationships ■■ Team has high level of trust. organizational boundaries
■■ Team members build “social capital” through multiple connections.
–– Shared Accountability
Time: How Clear Are Project Timelines and Milestones?
(88–120)—Shared leadership
Common Calendar ■■ Team has clear milestones and schedules of dates.
for achieving team objectives
■■ People are aware of ongoing key team dates and cultural calendar.
Interrelated Projects ■■ Task timelines are collaboratively established.
■■ Team adapts to rapidly changing conditions.
Awareness of Phase ■■ 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 ■■ People have the freedom and flexibility to do their work.
■■ The team continuously clarifies roles, responsibilities, and competencies needed.
Shared Leadership ■■ Leadership is widely distributed and shifts as needed.
■■ Individuals are encouraged to lead and to follow as appropriate.
Integrated Levels ■■ Key system interdependencies are clearly articulated (looking up, down, and across boundaries).
■■ People are encouraged to talk across levels.

IT Practice

Design Team 141

Relationship
Management
Design Team
Relationship
Management 142
DRIVE TEAM COLLABORATION AND ENGAGEMENT (CONTINUED)

Standard & Poor’s Common Delivery Framework for Agile Development
1
Specifies expectations for governance and management:
people, process, and documentation
GOVERNANCE MANAGEMENT ENGINEERING

Steering and Reporting Planning and Evaluation Define, Build, and Test
2
Ensures the
OPPORTUNITY ■■ Business Sponsor ■■ Project Proposer ■■ Architects—Enterprise, business context
(Assessment) ■■ Project Proposer/Champion ■■ Business Analyst Application, Data, will be captured
■■ Tech Management ■■ Subject Matter Expert Data Services
■■ Business Project Manager and cascaded to
What is the all team members
■■ Business Problem and ■■ High-Level Technical
business problem ■■ Opportunity Phase Needs Analysis Feasibility Analysis
or opportunity? Summary Meeting ■■ Perform High-Level ■■ Level 0 Estimate (+/-200%)
Risk Analysis
Objective ■■ Rapid Response Team ■■ Scope Analysis ■■ Vision—Initial
■■ Get a project ■■ Project Proposal ■■ Project Planning ■■ Project Proposal
funded. ■■ Funding Memo ■■ Begin RFP Process
■■ Get a project ■■ Project Plan—Level 0
■■ Opportunity Phase ■■ Vision—Initial
scheduled.
Summary/Sign-Off ■■ Scope—High Level, Initial
■■ Project Proposal
■■ Risk Profile—Initial
L H ■■ Request for Proposal (RFP)
Timebox
Synchronization Sprint
4
Defines the documentation Synchronization Planning
Synchronization Interface
options the team should be Specification
considering at each phase

3
Creates a critical
synchronization phase
to ensure functionality
is delegated in a way that
ensures usable software
when brought together

IT Practice

DRIVE TEAM COLLABORATION AND ENGAGEMENT (CONTINUED)
Intergraph’s Agile Cultural Change Management
Agile Adoption Pulse Survey
Much Much
Better Same Worse
Better Worse
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?
Strongly Strongly
Positive Neutral Negative
Positive Negative
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 143

Relationship
Management
Design Team
Relationship
Management 144

IT Practice


Good PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Good PDF

Enviado por

Direitos autorais:

Formatos disponíveis

INFORMATION TECHNOLOGY PRACTICE

APPLICATIONS EXECUTIVE COUNCIL®

Business Analyst’s Handbook

© 2012 The Corporate Executive Board Company. All Rights Reserved.

Executive Directors Consultants Production Designers

Copies and Copyright Legal Caveat

Overview of the Business Analyst's Handbook • iv

Business Analyst Competency Model: Needs Discovery • vi

Business Analyst Competency Model: Technology Management • vii

Business Analyst Competency Model: Relationship Management and Communication • viii

Section 1: Requirements Elicitation • 1

Section 2: Requirements Management and Analysis • 15

Section 3: Creating Compelling Business Cases • 33

Section 4: Providing Accurate Project Effort Estimates • 47

Section 5: Architecture Management • 77

Section 6: Designing for Usability • 93

Section 7: Communications and Change Leadership • 105

Section 8: Business Relationship Management • 125

Section 9: Design Team Relationship Management • 139

© 2012 The Corporate Executive Board Company.

OVERVIEW OF THE BUSINESS ANALYST’S HANDBOOK

2. Shift from “requirements gathering” to needs discovery and strategic

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

Hallmark’s Shared Business: Applications Requirements Elicitation • 4

Essential Reference Specialized

1 Each of the nine 2 The Handbook 3 Each resource

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

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

BUSINESS ANALYST Competency Model: Needs Discovery

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

BUSINESS ANALYST Competency Model: Relationship Management

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Level 1: Foundational Level 2: Practitioner Level 3: Leader

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

Capture High-Level Requirements IBM’s User-Initiated Requirements Specification • 8

Hallmark’s Shared Business: Applications Requirements Elicitation • 4 When to Use

development/legacy systems Capital One’s Creating High-Quality Requirements • 10

■■ To craft use cases for mobile apps requirements

Essential Reference Specialized

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

Elicit Unarticulated Needs

LexisNexis’s Uncovering Unarticulated Needs • 13

Essential Reference Specialized

Applications Executive Council®

© 2012 The Corporate Executive Board Company.

Capture High-Level Requirements

Feasibility Solicitation Analysis Prioritization Validation