business analyst handbook.pdf

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

INFORMATION TECHNOLOGY PRACTICEAPPLICATIONS EXECUTIVE COUNCIL®

Business Analyst’s HandbookTemplates for Key Business Analysis Activities

www.executiveboard.com

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

LEGAL CAvEAT

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

Executive DirectorsShvetank ShahWarren Thune

Managing DirectorsJaime CapellaDavid Kingston

Practice ManagerMark Tonsetic

Senior DirectorsMiles GibsonBill LeeAlex Stille

DirectorsAron KuehnemannTim MacintyreKristin Sherwood

Associate DirectorsChristiane GrothKarolina LaskowskaAlicia MulleryCandice Kenney Weck

COPIES AND COPYRIGHT

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

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

INFORMATION TECHNOLOGY PRACTICE

APPLICATIONS EXECUTIVE COUNCIL®|CONTENT PUBLISHINg SOLUTIONS

ConsultantsJohn HilleryAndrea Moreland

Senior AnalystPallavi Goel

Production DesignersTodd Burnett Carolyn Lamond

Contributing DesignersSupriya DhasmanaMike Jurka

EditorNidhi Vikram Choudhury


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

APPLICATIoNS ExECuTIVE CouNCIL®IT PRACTICEwww.aec.executiveboard.com


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 changes under way in solutions delivery and corporate IT. You are witnessing greater externalization of IT services to the cloud. Business partners are taking more responsibility for technology solutions themselves. There is increasing pressure for efficiency in delivery.

What does this mean for you? We’ve distilled five new imperatives for the business analyst role:

1. Reshape your engagement approach to reflect business leaders’ preferences for risk, benefit, and involvement. Many business leaders now prefer to lead more in phases of IT projects. understand your business 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.

4. Manage new solutions in the broader architectural context. The environment is growing increasingly complex with more externalized solutions delivery. Improve your ability to identify interdependent processes, and manage change of your projects that reduce the need for costly late-stage integration.

5. Enhance your vendor management competencies. organizations are growing their reliance on vendors for many kinds of solutions, especially mobile solutions. Your effectiveness with vendors will depend on your ability to drive the conversation on business need, not technical specification.

v



OVERVIEW OF THE BUSINESS ANALYST’S HANDBOOK (CONTINUED)

How to Use This Handbook

Hallmark’s Shared Business: Applications Requirements Elicitation • 4By 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

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.

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.

Each of the nine sections contains an overview on the templates available.

Each resource includes an indicator of its degree of applicability to the BA role.

31 The Handbook provides guidance on when to apply the template or resource.

2

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

https://aec.executiveboard.com/Members/Popup/Download.aspx?cid=101156050


vi



BUSINESS ANALYST COMPETENCY MODEL: NEEDS DISCOVERYSection 1: Requirements Elicitation—Ability to identify a desired future state that addresses a business problem

Section 2: Requirements Management and Analysis—Ability to manage requirements to the smallest set that will provide the biggest impact in advancing business objectives

Section 3: Creating Compelling Business Cases—Ability to measure and communicate proposed project benefits

Section 4: Providing Accurate Project Effort Estimates—Ability to quantify project resource requirements

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Precisely and consistently captures business problems and

nonfunctional requirements ■■ Prioritizes problems to surface the most critical needs

■■ Can identify and document emerging business requirements

■■ Can intelligently question business partner and knowledge worker preferences to identify unique value drivers

■■ Drives consensus for a desired future state that meets the business problem and enterprise objectives

■■ Can uncover needs that business partners and end users would not be able to articulate on their own

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Properly prioritizes competing business demands■■ Can elicit high-level business requirements ■■ Assesses the risks of various solution options to different

options

■■ Properly prioritizes business line and enterprise demands■■ Accurately translates business requirements into

functionality■■ Manages requirements to meet performance expectations

■■ understands business process complexity■■ Influences business partner requirements in support

of enterprise objectives

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Can articulate the business impact of business problems ■■ understands the organization’s economic and revenue

drivers

■■ understands industry-specific trends that impact the organization

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

to business value

■■ Quickly adapts to changes in business strategy■■ Helps business partners communicate solution value to key

stakeholders

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Effectively coordinates project delivery with the project

management office or equivalent

■■ Can manage ambiguity and create accurate project effort estimates

■■ Accurately quantifies project-specific risks through the development lifecycle

■■ Recognizes the implications of business strategy changes■■ Effectively engages project stakeholders in the estimation

process

vii



BUSINESS ANALYST COMPETENCY MODEL: TECHNOLOgY MANAgEMENTSection 5: Architecture Management—Ability to create solutions that advance architectural objectives

Section 6: Designing for Usability—Ability to design solutions for end-user adoption and productivity improvement

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ understands technology standards and architecture

guidelines■■ obtains key input from enterprise architecture groups

to ensure architecture compliance and exception management

■■ Identifies solution interdependencies■■ Stays abreast and creates awareness of technology

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

approach across projects in the absence of standards

■■ Can guide solutions options and business partner decision making to minimize the amount of project investment divergence from target architecture

■■ Can identify opportunities for creating reusable enterprise services

■■ Can guide and manages interactions with technology vendors

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Incorporates usability and user interface techniques when

designing systems■■ understands knowledge workers’ information needs as

they relate to a potential solution

■■ Can engage with knowledge workers in their normal day-to-day environment

■■ Can effectively convey knowledge workers’ preferences to business partners and design teams

■■ Can identify the requirements to ensure end-to-end service performance from the end user’s perspective

■■ Can gain business sponsor commitment for additional resources required to ensure usability

viii



BUSINESS ANALYST COMPETENCY MODEL: RELATIONSHIP MANAgEMENT AND COMMUNICATIONSection 7: Communications and Change Leadership—Ability to communicate effectively across multiple constituencies to support project and organizational change objectives

Section 8: Business Relationship Management—Ability to engage business sponsors and contribute to their targeted business outcomes

Section 9: Design Team Relationship Management—Ability to engage developers to ensure productivity and solution quality

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Presents ideas in a concise, focused manner■■ Can work as part of a larger team■■ Surfaces potential impacts of the solution on all

stakeholders

■■ Can guide team decision making■■ Provides business partners with an accurate view

of challenges to end-user buy-in

■■ Effectively engages key knowledge workers and business sponsors in change management activities

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Sets realistic customer expectations for project delivery

(e.g, schedule, budget, outcome)■■ Clearly articulates the role of technology in terms easily

understood by business constituencies■■ Proactively resolves customer satisfaction issues

■■ Adjusts customer expectations in accordance with changes in scope

■■ Can effectively navigate conflict between multiple business partners

■■ Tailors business partner engagement to business sponsor risk and value preferences

■■ Can influence business partner decision making to optimize requirements prioritization

■■ Builds long-term relationships between multiple business partners to drive engagement in IT strategy

Level 1: Foundational Level 2: Practitioner Level 3: Leader■■ Can listen to and understand technological constraints ■■ Clarifies the business rationale of a solution concept

■■ Creates a vision of project success that drives team engagement

■■ Shares best practices and process and environmental knowledge

■■ Educates developers on a project’s business context■■ Effectively collaborates with geographically distributed

teams



1

Section 1: Requirements Elicitation

REqUIREMENTS ELICITATION



2

REQUIREMENTS ELICITATION

Capture High-Level Requirements

Partner with business sponsors to effectively identify a desired future state that addresses a business problem.

Hallmark’s Shared Business: Applications Requirements Elicitation • 4By including business stakeholders from the earliest stages of requirements planning, Hallmark facilitates a shared sense of ownership and maximizes the likelihood that requirements will meet customer needs. The requirements elicitation process is broken into five distinct phases. Each phase defines a clear delineation between tasks for the business team versus the IT team.

When to Use ■■ To establish ownership and shared responsibility with business partners for each stage of requirements elicitation

■■ To validate high-level functional requirements for new systems development/legacy systems


Sabre Holding’s Agnostic Needs Statement • 7Sabre Holding assesses what should and should not be in a mobile application by crafting use cases that capture needs, not just mobile-specific requirements. To isolate the right needs and translate them into features, BAs should use a questionnaire that challenges business sponsors and users to articulate why their needs cannot be achieved without a mobile application.

When to Use■■ To uncover business sponsor and user needs for mobile■■ To craft use cases for mobile apps requirements■■ To validate whether a mobile application is the right solution


IBM’s User-Initiated Requirements Specification • 8To improve the requirements elicitation process, IBM boosts the usability of user-provided information by supplying business users a standardized elicitation template focused on the key attributes of the end product.

When to Use■■ To capture functional and nonfunctional requirements■■ To identify the most stable requirement


Evaluate Requirements

Continually verify requirements individually and collectively against a standard set of well-known criteria throughout the project lifecycle.

Capital One’s Creating High-quality Requirements • 10Capital one rigorously validates every functional requirement against a checklist of eight necessary attributes that each must meet. To prevent scope creep, all approved requirements must be associated with a documented business need. After making sure that each individual requirement is of high quality, the entire set of requirements is assessed as a whole against an additional set of three attributes. These attributes relate to the thoroughness of the set, the interrelationships between requirements, and the ease with which the requirements set can be changed.

When to Use■■ To prevent scope creep of requirements ■■ To define attributes of high-quality requirements





https://aec.executiveboard.com/Members/Popup/Download.aspx?cid=10670097&s=TC_BusAnalysis




3

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 • 13LexisNexis 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



https://aec.executiveboard.com/Members/Popup/Download.aspx?cid=101031709&s=TC_Mobile_Apps_Dev



4

CAPTURE HIgH-LEVEL REQUIREMENTS

Hallmark’s Shared Business: Applications Requirements ElicitationRequirements Elicitation Process

goal Formulate the business problem and identify all stakeholders, including end users.

Gather and classify feature requests from business partners through joint-requirements planning.

Perform an impact analysis and risk assessment to address technical, schedule, and cost concerns.

Prioritize all requirements based on business criticality of the features.

Integrate requirements and validate scope in collaboration with business partners.

Business-Side Tasks

■■ Map user base across organizations.

■■ Determine operational and problem context such as mission scenarios.

■■ Identify similar systems in the organization.

obtain a wish list from each party in the user base.

Perform abstractions to answer questions of the form, “Why do you need x?”

Determine criticality of features.

■■ Resolve as many open issues as possible.

■■ Verify that requirements are in agreement with originally stated goals.

■■ obtain authorization to move to Application Design.

Applications-Side Tasks

■■ Identify application domain and development experts.

■■ Identify domain and architectural models.

■■ Assess cost constraints imposed by the sponsor.

■■ Classify wish lists according to constraints (functional, nonfunctional, environmental, design, etc.).

■■ Determine interface needs for information that is shared between business areas.

■■ Estimate the impact of requirements on cost and schedule.

■■ Perform risk assessment.■■ Examine cost of potential solutions in light of architectural and strategic fit.

■■ Prioritize requirements based on cost and dependency.

■■ Identify appropriate architectural models that work with current technology roadmap.

■■ Resolve conflicts and keep consistency in check.

DERF 04-1873

Catalog # AEC12LF8P5

Title Optimizing the SDLC

Feasibility AnalysisSolicitation Prioritization Validation




5

CAPTURE HIgH-LEVEL REQUIREMENTS (CONTINUED)

Hallmark’s Shared Business: Applications Requirements Elicitation (Continued)High-Level Requirements Questionnaire for New Development

1. Determine Business Objectives

1. What are your goals in developing this system?2. Who are the key stakeholders and users? Do their goals differ? If so, how?3. How do the system goals map to business goals?4. What is the most important business goal of the system?5. Will the system change the way you are doing things now?6. Will the system help you be more efficient? How?7. What are the system deliverables? 8. What will the new system accomplish that is not accomplished manually

or with other systems?9. What will the new system do?

4. Determine Current Problems

1. What are the problems you face without the system today?2. What problems should this system solve? 3. Do you have to do things manually that you would like to automate?4. Do you have performance problems that need to change?5. Do you have functional limitations that you would like to change?6. Are you using packages that force you to constrain your business functionality

to the boundaries of the package?7. Which reports do you currently use? What data on the report are important?

How do you use the information?8. Are there specific bottlenecks to getting at information?9. How do you analyze the information you currently receive? What type of data

are used? How do you currently get the data? How often do you get new data?10. What type of ad hoc analysis do you typically perform? Who requests ad hoc

information? What do you do with the information?

5. Determine Criteria for Success

1. What is most important for success of the application? 2. What do we need to accomplish to make this project successful?3. What do we need to change to make this project successful?4. What buy-in do we need?5. Are we lacking any critical elements such as budget, resource allocation,

or support?6. What are training considerations for developers and users?

6. Determine Assumptions and Open Issues

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

2. Determine Future Needs

1. What business requirements will this system address?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?4. How would you like to see this information? 5. What functionality do you need from the system?6. Are the data and/or functionality shared by other (many) business areas?

If so, which?7. If the reports were dynamic, what would they do differently?8. How much historical information is required?

3. Determine System Users

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

DERF 04-1873






6

DERF 04-1873




Hallmark’s Shared Business: Applications Requirements Elicitation (Continued)High-Level Requirements Questionnaire for Legacy Systems Development

1. Determine Business Objectives

1. Why do you want to redo the system?2. How will the new version of the system help you?3. What are your objectives in having this system?4. Who are the key stakeholders and users? Do their goals differ? If

so, how?5. How does the system map to business goals?6. What is the most important business goal of the system?7. Will the system change the way you are doing things now?8. Will the system help you be more efficient? How?9. What are the system deliverables? 10. What will the converted system accomplish that the current

system cannot?11. Will the output of the converted system be the same or different

than the current system?12. Will the new system have an additional functionality? What?13. Will the new system have better performance? To what extent?14. Will the new system help you be more efficient? To what extent?15. Will the screens look different? How?16. What is most important (rank in order of importance)?

■■ Application is easier to use.■■ Application has nicer front end.■■ Application has additional functionality (list).■■ Application is more efficient.■■ Application is redesigned to better reflect the business.

2. Determine Future Needs

Same as for new system development

Many of the questions that apply to new systems development also pertain to projects involving legacy systems.


1. Who are the most important players in terms of knowledge? Politics?

2. Is there any existing system documentation? If so, where?3. Who else should we talk to?

3. Determine System Users



Same as for new system development, plus:1. What is the risk of not converting the system?

5. Determine Criteria for Success


6. Determine Assumptions and Open Issues


For projects that impact legacy systems, Hallmark also considers important questions relating to organizational behavior and people issues.




7


Sabre Holdings’ Agnostic Needs StatementQuestionnaire for Business and End Users: Mobile Requirements

Business Sponsor Questionnaire

1. What are you trying to do?We want to offer a solution to travelers that helps them manage their travel throughout the trip.

2. Why can’t you achieve this business objective without mobile?While travelers are “in-trip,” it is often difficult to communicate with them.

3. What is the pain point? Travelers typically think of trip management applications during delays or when they are looking for flight status. We want to expand our engagement by making life easier for “in-trip” travelers.

4. To what degree are you changing an existing business process?The travel lifecycle has always had a gap in the “in-trip” phase. To move a product or service into this phase requires a change as well as new approaches and data.

Use Case 3: End User

1. Who are you as a potential user? What is your role?A road trip traveler


1. Who are you as a potential user? What is your role?A business traveler


1. Who are you as a potential user? What is your role?A leisure traveler

2. What do you need to accomplish?While in the middle of my trip, I need to know my hotel’s amenities and what other events/activities may be available.

3. Why do you need to do that? I usually find these items in advance of the trip, but if I fail to do that, I have difficulty finding the information.

4. Why 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.

DERF 11-3557

Catalog # AEC1035611SYN

Title ST: Mobility Study




8


IBM’s User-Initiated Requirements SpecificationBusiness Requirements Elicitation Worksheet

Requirement Type Unique ID

Requirement Statement Description

Success Conditions

Stability Level

Functional Requirements

BFR1

BFR2

BFR3

…

BFRn

Nonfunctional Requirements

BNFR1

BNFR2

BNFR3

…

BNFRn

Key Question: What business problem are you solving with each requirement?

Example: I need to have updates to customer data available in all regional offices.

1

Key Question: What would render a feature or functionality useless to you?

Example: The data would be useless to me if I can’t get it in fewer than 15 seconds.

2

Key Question: How likely is it that this requirement will not change?

Example: The system must be able to process orders, but it may not have to provide daily reports.

High (H)—Unlikely to change

Medium (M)—May change based on business conditions or other business initiatives

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

5

Key Question: How can you tell it is working correctly?

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

4

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.

3




9


IBM’s User-Initiated Requirements Specification (Continued)Business Requirements Specification, Illustrative

Business Requirements Specification

I. Business Scope and Objectives

This section defines the starting reference for a project. This section should help with the following:

■■ Provide a high-level understanding of what the enterprise is and aspires to become. It is usually depicted by a brief description on how the organization intends to achieve its goals and make the desired transition and by what means.

■■ Document events that are the initial stimuli causing the client’s business to act.■■ Describe and quantify the benefits, costs, schedules, and assumptions required

to justify the implementation (if needed).

II. “As Is” Business Process Flows

This section should help with the following:■■ Contain the graphic representation of the flow of work through a business

process model, narratives that describe the flow, and key process attributes.■■ Describe a high-level business use case model; this use case model uses

graphical symbols and text (business lexicon) to specify how users in specific roles will use the system.

■■ Depict the usage and interaction between resources (e.g., hardware, software, and people).

III. Business Requirements

Business requirements differ from systems requirements. Business requirements can be identified by the following characteristics:

■■ They support a business scope and/or objective, usually reviewed by executives.■■ They have a business purpose/focus.■■ They state “what” needs to be accomplished using business language.■■ They are nontechnical.

Key questions to ask when reviewing business requirements:1. What am I solving with this business requirement?2. Is this business requirement feasible?3. What scope and/or objectives is this business requirement addressing?4. What is the acceptance criterion for this business requirement?5. How do I measure the acceptance criteria?

Success criteria/acceptance criteria ensure agreed-to business requirements (functional and nonfunctional) are clear and unambiguous. They are also the metrics that measure success of the project. The objective of this section is to identify and document success criteria and associated metrics for each business functional and nonfunctional requirement.

a. Business Functional Requirements

Business Functional Requirement ID

Requirement Stability Level(H)—High(M)—Medium(L)—Low

Success Criteria and Associated Metrics

BFR1

BFR2

b. Business Nonfunctional Requirements

Business Functional Requirement ID

Requirement Stability Level(H)—High(M)—Medium(L)—Low

Success Criteria and Associated Metrics

BFR1

BFR2

IV. Assumptions, Issues, and Constraints




10

EVALUATE REQUIREMENTS

Capital One’s Creating High-Quality RequirementsIndividual Requirements Evaluation Criteria

The following attributes should be applied to each requirement

Term Definition guidelines Example

1. Unambiguous The requirement has only one possible interpretation.

Avoid natural language, such as user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize.

use a requirements document glossary to capture the meaning of important terms.

uncover ambiguity by formally inspecting the requirement, writing test cases from requirements, and creating user scenarios that show the probable behavior of a specific piece of the product.

“For up to eight results, the detailed display format shall be used. For the remainder, the compressed display format shall be used.”

Ambiguity lies in the phrase “for up to eight results.” Does it mean “for up to and including eight” or “for up to and excluding eight”?

2. Correct The requirement accurately describes the functionality to be delivered.

use the source of the requirement as your reference of correctness, such as the actual business or system requirements specifications. If the system requirement conflicts with the corresponding Business requirement, one of them is incorrect.

Include the affected area’s subject matter expert (SME) when determining the correctness of requirements.

A business requirement that states “the search function shall display a maximum of 10 results per page” could incorrectly be recorded in the systems requirements as “the search engine must fetch a maximum of 10 matching records from the database.”

3. Testable The requirement can be verified through an inspection or demonstration to determine whether it can be implemented properly in the product.

State each requirement so it can be verified within the scope of the project using tests or other verification approaches. If a requirement is not verifiable, questioning its implementation will be a matter of opinion.

Requirements that are inconsistent, infeasible, or ambiguous are not verifiable. A requirement that merely states that the product shall support certain functionality is not verifiable.

“The program shall not enter an infinite loop” is a non-verifiable and hence not testable requirement.

4. Achievable The requirement must be practical from the standpoint of compatibility issues with existing systems and environments and constraints of time and budget.

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




11

EVALUATE REQUIREMENTS (CONTINUED)

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


5. No Design Impact

The requirement states what is required but not how the requirement should be met.

Check each requirement to ensure that it does not reflect a design or implementation decision or describe an operation. Such requirements are design-dependent.

Nonfunctional requirements such as system constraints are an exception.

DO: Design independent requirements.“The system shall enable all employees to update their time sheets.”

DON’T: Design dependent requirements.“The system shall be composed of three modules, each reading from and writing to a Microsoft Access database.”

The treatment of interface requirements is usually an exception: “The system interface shall adhere to the standard corporate design.”

6. Traceable The requirement must be traceable to and from its source.

Link each requirement to its source. It could be a high-level system requirement, use case, or a documented stakeholder requirement.

Link each software requirement to the architecture elements, design elements, and test cases that are constructed to implement and verify the requirement.

7. Necessary The requirement should document a business need and should be implemented by design.

A necessary requirement is one that has been validated by an owner recognized to have change control authority (such as the requirements manager). It can be clearly identified with a business case.

8. Documented A requirement must be documented for it to be considered valid.

Verbal, undocumented requirements cannot be adequately traced, tested, analyzed, or shared across the project team. Hence, requirements must be documented to meet all the conditions stated above.

The form of documentation should facilitate electronic storage and transmission and should be published by the project manager as early as possible in the project lifecycle.




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 for all business needs related to the project.

organize the requirements hierarchically to help reviewers understand the pieces that make up the requirement. It will then be easier for the reviewers to tell if something is missing.

Focus on user tasks rather than on system functions during requirement elicitation. This reduces the likelihood of overlooking necessary requirements or including unnecessary ones.

The use case method works well for this purpose. Graphical analysis models that show different views of the requirements can also uncover incompleteness.

Any appearance of “To Be Determined” (TBD) in the requirements document makes it incomplete. use TBDs as a standard flag to highlight gaps when it is known that certain information is missing. Resolve all TBDs before you develop the part of the product tied to the TBD requirement; otherwise, it must be documented by the project manager in the PMM Risk Management Plan.

II. Consistent No two requirements must be in conflict with each other.

Consistent requirements agree with other software requirements or with higher-level system and business requirements. Research and resolve disagreements among requirements before development can proceed so it is understood which of the requirements is correct.

Review all the related requirements before you modify one. Inconsistencies can slip in undetected if only the specific change is reviewed.

The following requirements are not consistent with each other:

“The search function shall return results in the order of their relevance to the searched term.”

“The search function shall display the most recently created documents first.”

III. Modifiable Requirements specifications must be open to revision and durable to change.

uniquely label each requirement and express it separately from other requirements so each can be referred to unambiguously.

organize all requirements such that related requirements are grouped together.

Create a table of contents, an index, and a cross-reference listing.

“The user should lift the handset; the system shall respond with dial tone; the user should then dial the seven-digit phone number of the party the user is trying to reach.”

“The user should lift the handset; the system shall respond with dial tone; the user should then dial a 1 followed by the 10-digit phone number of the party the user is trying to reach.”

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.




13

■■ Engage with knowledge workers in their normal day-to-day environment.

■■ uncover and document existing pain points and needs that knowledge workers would not be able to articulate on their own.

■■ Experience in identifying and evaluating new technologies

■■ Experience in gathering and defining business requirements

■■ Survey and data analysis skills

■■ user-experience skills

good but Insufficient Indicators of Success for a Customer Advocate

ELICIT UNARTICULATED NEEDS

LexisNexis’s Uncovering Unarticulated NeedsThe Customer Advocate Profile

Customer Advocate Objectives

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

DERF 11-3302


Title ST: Educating Business Leaders




14

ELICIT UNARTICULATED NEEDS (CONTINUED)

LexisNexis’s Uncovering Unarticulated Needs (Continued)Interview Guide

I. Background

1. Job Position/Title

2. Business unit■■ Name of business unit■■ Size of business unit■■ Structure of business unit■■ How are you personally evaluated? ■■ Who supports you?

3. Tell me about your career/educational background and how you got to where you are today.

■■ undergraduate■■ Graduate school/MBA■■ Career progression

4. What is your key area of expertise? What would you like to be your key area of expertise?

5. What does your network of peers look like?

6. What extracurricular activities (both job-related and personal) have you participated in?

7. What is your level of comfort with technology?

8. How do you keep up with new developments in your field?

9. How do you learn about new products or services to help you with your job?

10. How is success typically measured in your job? How do you tie that success back to the work you did?

11. What is the most important thing you can do well in your job in the eyes of your company/boss/industry?

12. When you look back at this job 5 or 10 years from now, how will you decide if you were successful at it?

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

II. Day in the Life

Describe a typical day for you. Walk me through what time your day normally starts, typical activities, etc.

1. What are your hours?

2. Who are the people you typically interact with and how do you interact with them?

3. What do you spend the most time on?

4. What would you like to be spending the most time on?

5. What is a good use of your time and what is not?

6. What would you assign to someone else if you could?

7. Where do you work—in the office, at a client site, at home?

8. In your everyday work, what tools/resources do you rely on to make your work easier?

■■ What tools serve you well and you could not live without?■■ What tools are less successful?■■ Can you tell me about a work task that was made a lot easier using a tool that

you purchased?■■ How did that tool/resource make the job easier?■■ How do you customize/modify the tools that you use to help you in your work?

(or can you usually use them off the shelf?)■■ Is there a product you wish you had that is not available?

9. What resources are available to you, free and paid for?

10. What resources do you wish you could have?

11. How do you see your job changing in the next five years? What tools/resources will become more important?

DERF 11-3302






15

Section 2: Requirements Management and Analysis

REqUIREMENTS MANAGEMENT AND ANALYSIS



16

REQUIREMENTS MANAgEMENT AND ANALYSIS

Prioritize and Track Requirements

Accurately screen and compare requirements based on how well they satisfy business objectives.

Sabre Holding’s Feature Needs-Testing for Mobile Apps • 18Sabre Holdings applies a rigorous screening to strip out features that fail to satisfy either the business or end-user needs.

When to Use ■■ To screen mobile requirements for fit with business needs


Discover’s Sample Requirements Tracking Document • 19Discover’s requirements tracking document helps ensure that requirement changes are reflected in design and test cases and validated by users.

When to Use ■■ To gather requirements iteratively■■ To identify requirements from business partners, users, and software requirements

■■ To validate requirements during project review discussions


Paccar’s Business Objectives–Driven Functionality Prioritization • 20Paccar 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.

When to Use ■■ To connect business benefits and application functionality■■ To quantify functional capabilities■■ To find the best-fit implementation for application functionality


BCBS-MA’s Pairwise Feature Prioritization • 21For functionally complex projects, BCBS-MA makes pairwise comparisons among features to enable the business sponsor effectively prioritize requests for functionality.

When to Use■■ To compare and rank order business preferences■■ To compare and prioritize features


Fenton, Inc.’s1 Functionality ROI Maximization • 22Fenton, Inc. quantifies each feature’s impact on a project’s business value components that enables benefit-driven trade-offs.

When to Use ■■ To quantify the value of application functionality■■ To prioritize features and requirements based on business benefit


1 Pseudonym.









17

REQUIREMENTS MANAgEMENT AND ANALYSIS (CONTINUED)

Manage Requirements Across Business Process Change

Customize requirements management methodologies based on project’s architectural impact and end users/customers involved.

Swiss Re’s Methodology Decision Map • 23Swiss Re aligns the level of effort for requirements management on any given project with the level of business process change targeted by the project.

When to Use■■ To match requirements management effort to business need■■ To tailor requirements management methodology


Drake Corporation’s1 voice of the Customer Tool • 26Drake Corporation uses a Voice of the Customer planning worksheet to understand user acceptance issues early and adapt requirements management accordingly.

When to Use■■ To assess key stakeholder attitudes■■ To plan engagement with stakeholders


Improve Portfolio-Level Requirements Visibility

Group projects together based on their shared impact on business processes, and then gather the requirements holistically.

CIGNA’s Portfolio-Level Requirements Management • 27CIGNA takes a holistic view of requirements capture by bundling projects based on project priority, business process impact, and business process synergy. A centralized requirements group maps current business processes, identifies requirements redundancies and gaps across projects, and makes the appropriate adjustments to enable business process transformation to the desired future state.

When to Use■■ To capture portfolio view of requirements■■ To bundle projects based on shared impact of business processes■■ To map current business processes, identify requirement redundancies, and gaps across projects


1 Pseudonym.







18

Needs Test 1: Business Need

Discard Features

Discard Features

Discard Features

Needs Test 2: End-User Workflow Need

Usability Criteria

Shops and Books for Corporate Approved

Hotel Rooms

Candidate Features■■ obtains Travel Agency Contact Information

■■ updates Traveler Profile Information

■■ Shops and Books for Corporate Approved Hotel Rooms

■■ Displays Corporate-Specific Messaging

■■ Holds a Trip for Future Booking

Litmus TestCan we clearly articulate how this feature meets a high value user need?

Litmus TestCan we clearly articulate how this feature meets a business need?

updates Traveler Profile Information

Displays Corporate-Specific Messagingobtains Travel Agency Contact Information

Holds a Trip for Future Booking

Usability Criteria Could use of this feature be severely impacted by any of the following?

■■ Noise/distractions■■ Poor lighting ■■ Time pressure ■■ Slow link control protocol connectivity■■ Complex visuals■■ Specific mobile device (e.g., phone versus tablet)

PRIORITIzE AND TRACK REQUIREMENTS

Sabre Holding’s Feature Needs-Testing for Mobile Apps Illustrative, Corporate Booking Apps

DERF 11-3557


Title ST: Mobility Study




19

PRIORITIzE AND TRACK REQUIREMENTS (CONTINUED)

Discover’s Sample Requirements Tracking Document

Requirements Tracking Document

Project Name: Excelsior

War Room Dates: ---------------

Business Sponsor: Jim C

Project Manager: John G

Req. ID Description Requirement Adjustment Notes

Design Document

Test Case ID

Changes Implemented

UAT Done

RS0001 users should be able to select the item from the list of products.

Select multiple items from the list.

DD0001 TC0001 Design

Development

Test Cases

RS0002 Make list of all products available for the user to select in alphabetical order.

Also group the products by their market.

DD0005 TC0003 Design

TC0004 Development

TC0005 Test Cases

RS0003 -------------------------------- ----------------- ----------- --------- -----------------

RS0004 -------------------------------- ----------------- ----------- --------- -----------------

Document requirements captured prior to the war room.

1 UAT ensures that business partners have validated the changes that were made throughout the project and facilitates the speedy formal sign-off at the end of the project.

4

Use notes column to write down any changes to requirements during the war room. Don’t waste time formally updating the requirements document.

2 Traceability ensures that changes are implemented in all affected areas.

3

DERF 09-2746


Title ST: Business Engagement




20

Business Objectives

Reduce Costs Increase Revenue

Increase Engineering operations Efficiency

Improve Materials Cost

Increase Engineering

Design Efficiency

Increase Average

Price

Increase Customer utilization

Decrease order-to-Ship

Cycle Time

Business Priority Rank H M M H H L Impact Score

Functional Capabilities

Change order Event Notification

6.6

Automate Material Requirements ordering

4.9

Add Search Capability 5.2


Paccar’s Business Objectives–Driven Functionality PrioritizationPrioritizing the Impact of Applications Functionality on Fulfilling Business Objectives, Illustrative

Strong Impact = 9 Points

Medium Impact = 3 Points

Low Impact = 1 Point

High-level requirements are framed in terms of business or process improvement objectives.

1

Business Priority Rank: Low (L), Medium (M), High (H)

2

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

3 Assessment of impact of functionality on the business objective

4 Impact scores are calculated based on the Business Priority Rank and the impact of the functionality on each of the business objectives; top third stay, bottom third are discarded, and middle third are taken up for further consideration.

5

Impact assessments and business process knowledge result in quantified business benefits (e.g., 4% decrease in order-to-ship cycle time).

6

DERF 04-1873






21


BCBS-MA’s Pairwise Feature PrioritizationPairwise Comparison of Features

Feature

No. of Times Circled

1

B

A 2

C C

A B C

D D 4

A B C D

E E E E E. Transfer

B. Change Name

A. Change Address

D. Change Status

C. Reinstate

Project Sponsor

Business Project Manager

Business Liaison

A B C D E

3 2 0 4 1

A count of the number of times each feature is circled across the rows and columns of the entire matrix is used to rank the features.

Which feature is more complex to create:

■■ Change Address or Change Name?

■■ Change Name or Reinstate?

3

2

A

A

A

B

BD D D

DE

1 Participants are asked to pick the feature they consider more important—feature A (Change Address) or feature B (Change Name); ties are not allowed.

Similarly, pairwise comparisons are made between each pair of features; the preferred one in each pair is circled.

Which feature is more important to you:■■ Change Address or Change Name?■■ Change Name or Reinstate?

Functionality RankingBusiness Staff

Complexity RankingApplications Staff

Prioritized Feature List

Rank Value-Based Prioritization

Cost-Based Prioritization

1 D Change Status E Transfer

2 A Change Address C Reinstate

3 B Change Name D Change Status

4 E Transfer A Change Address

5 C Reinstate B Change Name

Ranking the complexity of the features gives the Applications team a handle on costs, resources, and schedule.

DERF 06-4680

Catalog # AEC16ONPFX

Title Boosting Productivity Study




22

Business Value Components

Efficiency goals Effectiveness goals

aIncreased Use of Call Automation

bTimely

Handling of Call

cEfficient

Call Transfer to Sales

dReduced Calls to

Help Desk

eReduced

Call Escalation

fIncreased Customer Retention

gIntelligent

Call Routing

Value $500 K $275 K $25 K $100 K $200 K $1 M $5 M Feature Score (Sum of Weight

x Impact)Weight 2 2 1 2 2 3 3

High-Level Requirements System Features

Need for Associates to Talk with Previously Inaccessible Customer Segments

System shall identify which customers to be harvested.

67

System shall have the flexibility to easily change harvesting instructions.

63

System shall have the ability to reorder queues based on harvesting instructions.

43

System shall only harvest the best customer segments.

51

Need to Provide Associates with Critical Customer Relationship Information

System shall display customer and call information to associate.

71

System shall display key customer data to associate.

83

System shall provide wrap-up for who and why customer called.

23


Fenton, Inc.’s Functionality ROI Maximization Computer Telephony Integration Project, Illustrative

Strong Impact = 9 Points

Medium Impact = 5 Points

Low Impact = 1 Point

Weight is assigned based on order of magnitude of the value.

1

vertical views indicate potential feature gaps and redundancies.

2

Scores can be aggregated to prioritize requirements.

3

DERF 04-1873



1 Pseudonym.

1




23

Swiss Re’s Methodology Decision MapCustomer Request Decision Tree

MANAgE REQUIREMENTS ACROSS BUSINESS PROCESS CHANgE

Is this a one-time improvement?

What is the size of the change?

Small

(< $250 K)

order of Magnitude

(> $ 2 M)

Improving Existing

Replacing Existing

Changes a Leverage Point Within the Existing Paradigm

Changes the Business Paradigm

Improving Existing

Replacing Existing

Yes

No

Yes

No

Information Systems Planning

Continuous Process Improvement

Business Process Improvement


Radical Process Improvement




What are you doing to the process?

Is there a high level of risk associated with the improvement?

What is the impact?

What are you doing to the process?Significant

($250 K–$2 M)

DERF 06-4680






24


■■ Measuring and analyzing the existing process to identify problems for resolution and other improvement opportunities

■■ Applying left-to-right thinking to evaluate how the parts of the process contribute to the required outputs and performance

■■ Identifying leverage points with the greatest opportunity for competitive advantage and performance improvement

■■ Developing a set of improvements that together amount to significant improvement in such areas as cost, time, and quality.

Information Systems Planning

■■ Improving the automation of, or information support to, an existing process

■■ Restructuring information systems for technical efficiency, functional flexibility, and maintainability

■■ Moving automated support from one platform to another

■■ Improving the integration among information systems

Continuous Process Improvement

■■ Monitoring the existing process through a rigorous measurement program to identify problems for resolution

■■ Installing a quality-oriented culture and set of procedures to encourage and exploit improvement ideas from workers

■■ Applying left-to-right thinking to evaluate how the parts of the process contribute to the required outputs and performance

■■ Achieving a series of improvements of smaller magnitude in such areas as cost, time, and quality that, over the course of time and the scope of the entire process, amount to significant improvement


■■ Replacing an existing process with a completely new or a substantially redesigned one, generally accompanied and enabled by radical changes in the use of information technology and people

■■ Applying right-to-left thinking, beginning with required outputs and deriving the essential process

■■ Actively challenging and rejecting old paradigms by lateral thinking

■■ Achieving order-of-magnitude improvements in such performance measures as cost, time, quality, and flexibility, either out of competitive necessity or the desire to leap ahead of the competition

■■ “Business Process Reengineering” addressing the extreme end of business process redesign, where the level of scope, impact, and risk is the greatest

Swiss Re’s Methodology Decision Map (Continued)Approach Descriptions

MANAgE REQUIREMENTS ACROSS BUSINESS PROCESS CHANgE (CONTINUED)

DERF 06-4680






25

Architectural Analysis Business Process Analysis and Design Business Solution Analysis and Design

Architecture Planning

Architecture Design

Architecture Review

Initiate Analysis

gather Process

Requirements

Model Process Design

Review Process Design

Approve Process Design

Initiate Analysis

gather Process

Requirements

Model Process Design

Review Process Design

Approve Process Design

Deliverables

■■ Application Landscape■■ Business Information Model■■ Context Diagram■■ Draft Application Context Diagram

Deliverables

■■ Business Dynamics Models■■ Requirements Matrix ■■ Business Value Chain ■■ ownership Assignments■■ Hierarchies■■ State Transition Diagrams

Deliverables

■■ Business Process Models■■ Logical Data Model■■ CRuD Matrix ■■ SDL Compliance Statement■■ Application Context Diagram■■ Information Flow Diagram■■ Prototype Screen Flows and Designs■■ Test Documentation■■ use Case Documents

Typical Activities

■■ Discuss project with local architecture team, obtain any business group–level reference artifacts.

■■ Assess impact of any proposed changes on existing architectural environment.

■■ Discuss appropriate timings and number of governance reviews with Architecture Governance and Standards team.

■■ Review and familiarize with Business Case and Project Definition Document.

Typical Activities

■■ Initiate business process analysis.■■ Gather business process requirements.■■ Model business process design.■■ Review business process design.■■ Sign off on business process design.

Typical Activities

■■ Initiate business solution analysis.■■ Gather business solution requirements.■■ Model business solution design.■■ Review business solution design.■■ Sign off on business solution design.

MANAgE REQUIREMENTS ACROSS BUSINESS PROCESS CHANgE (CONTINUED)

Swiss Re’s Methodology Decision Map (Continued)Requirements Process, Three Stages

DERF 06-4680






26

Challenge OpportunitiesCurrent Commitment (SS, S, N, A, SA)

Needed Commitment (SS, S, N, A, SA)

Probabilities of Success (PoS)

Possible Strategies to Improve PoS

Concern they are gaining more work, not less

Believe the opportunity. Supportive Strongly Supportive 90% ■■ Engage innovators and early adopters.

■■ Leadership set priorities for all of their work, let some drop.

Rewarded for developing, not replicating applications

■■ Lab heads asked for this.

■■ It’s their vision.

Supportive Strongly Supportive 70% ■■ ou—Set TS growth objectives.

■■ uS—Engage tech directors.

■■ Not as attractive as new productivity launch

■■ Not tech savvy

■■ Don’t see tech service as a partner

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

Neutral Supportive 40% ■■ Develop new incentives.

■■ Seek help from marketer to develop.

Not on their dashboards This is a low-risk way to reach growth targets.

Neutral Supportive 60% ■■ Group metrics on the acceleration dashboard.

■■ Promote the value to the executive conference.

DRAKEcorporation

1MANAgE REQUIREMENTS ACROSS BUSINESS PROCESS CHANgE (CONTINUED)

Drake Corporation’s Voice of the Customer ToolStakeholder Group Analysis

1 Pseudonym.

DERF 06-4680






27

Projects are regrouped into delivery “flights” based on business need, which processes they affect, and where in the process chain their effect is prominent.

The project portfolio is segmented into groups of projects according to shared impact on business processes.

Business project priority ranking results in a list of projects to be completed based on initial capacity estimates.

Business Process Synergy

What is the delivery impact on business workflows across dependent business processes?

5. Receipt Management System

6. Bill Processing System

9. E-Billing Presentation

1. ERP Finance upgrade

3. HIPAA Rights Repository

8. Medicaid Reporting Repository

7. Benefits Management Portal

2. Customer Information Database

4. Claim Submission System

Business Process Implications

How much process transformation will be realized and which processes will be affected?










Customer Service

Claims Processing

General Accounting

Flight one

Flight Two

Flight Three

Business Priority

What is the customer’s desired priority and what is our current delivery capacity?










IMPROVE PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY

CIgNA’s Portfolio-Level Requirements ManagementGroup Project According to Shared Impact on Business

321

For smaller, less-strategic projects, CIGNA creates alternative paths to expedite requirements gathering.

DERF 06-4680






28

Qualifying CriteriaApproved 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 CriteriaEnterprise 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 AssumptionsFunctional 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 TimelineTimeline 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.

IMPROVE PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED)

CIgNA’s Portfolio-Level Requirements Management (Continued)Alternate Path for Requirements Delivery

DERF 06-4680






29

Customer Service

Claim Correspondence Claim Adjudication Payment

Paper Claim Receipt Process

Electronic Claim Receipt Process

Medical ClaimsNon-Medical Claims

Claim PricingCheck Generation

Fund Transfers

E-Presentation Portal M H M

Receipt Management System M H M M

Customer Information Database H M

Provider Management System L H L

Member Web Site Redesign M

HIPAA Member Rights Repository L L M L

Medicaid Reporting System L L H M

Accounting






Fund Transfers





Member Web Site Redesign M



Claims Processing






Fund Transfers“Flight” Projects





Member Website Redesign M




CIgNA’s Portfolio-Level Requirements Management (Continued)Project Impact Assessment on “Should” Business Processes

H High Impact

M Medium Impact

L Low Impact

The impact of a project on a business process step represents the magnitude of process transformation.

Similar or redundant system functionality is identified to consolidate requirements gathering across projects and expedite requirements elicitation.

Multiple process impacts in a row indicate process flow and information dependencies.

CIGNA minimizes time spent on each subsequent flight by building and actively maintaining business process libraries.

3

2

1

4

DERF 06-4680






30

“As Is” Process Modeling

Owner

Process Modelers 15% of Requirements Group

Responsibility

Model “as is” business processes to denote the flow of information and cross-connections among process segments at all levels.

Key Deliverables

Business process maps, which highlight interdependencies within and across process areas

“Should” Process/High-Level Requirements

Owner

Senior Business Analysts 35% of Requirements Group

Responsibility

Capture business process dependencies in terms of sequential activities to uncover “as is” to “should” business process variance.

Key Deliverables

IS/SHouLD Process Change Summary, which outlines how process functionalities interrelate

Detailed Requirements

Owner

Functional Business Analysts 50% of Requirements Group

Responsibility

Elicit detailed requirements consistent with “as is” and “should” business process models.

Key Deliverables

Business use cases, which include activity flows and new process modifications


CIgNA’s Portfolio-Level Requirements Management (Continued)Requirements Clarification: Roles, Responsibilities, and Escalation Process

If a requirement interdependency is the product of a new process interdependency, senior business analysts work with process modelers to evaluate and resolve the new interdependency together and update business process maps and IS/SHOULD Summaries accordingly.

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.

DERF 06-4680



3

2

1

B

A




31


CIgNA’s Portfolio-Level Requirements Management (Continued)Project, Process, Requirements Team Responsibilities by Phase

■■ Review project documentation (e.g., project proposal, project/product description) for clarity, completeness, and potential domain/function impact.

■■ Work with Enterprise PM (EPM) to achieve clarity and completeness of project scope if needed.

■■ Provide high-level time/cost estimates for PPR activities to EPM.

■■ Perform a high-level process decomposition to identify the potential processes impacted by the project and across projects.

■■ Share outcome from the decomposition for review with EPMs and subsequently with matrix partners.

■■ Identify and communicate domain lead to EPM.

■■ Plan and schedule high-level requirements sessions by domain based on project decomposition.

■■ Engage business subject matter experts (SMEs) to support and plan requirements definition.

■■ Work with EPM to define requirement kickoff date based on PPR capacity.

■■ outline/document proposed requirement gathering dates (high level, process modeling, and detailed) for review by EPM and subsequently by matrix partners based on capacity, project, and process synergies.

■■ Provide input to any phasing of solutions. ■■ Assist with issue resolution, provide

clarification, and respond to questions.■■ update business requirements traceability

document with assistance from System Analysis to ensure design traces back to requirements.

■■ Support design documents and walk through to verify design meets business requirements.

■■ Support scope change management process and update documentation as needed.

■■ Facilitate and document high-level requirements and process models focused on specific processes within a domain (not project specific).

■■ Create requirements traceability matrix based on high-level requirements including process and project views.

■■ Create use Case Inventory by process/project and assign owners for completion.■■ Conduct high-level requirements sessions walkthrough with matrix partners

stressing manual touchpoints and new or eliminated processes based on high-level requirements.

■■ Identify and document issues; assign owners and facilitate requirement issue resolution.

■■ Based on completed high-level requirements, assess and update estimates as needed.

■■ Conduct end-to-end domain/project review.■■ Plan and schedule detailed use case sessions.■■ Create and maintain detailed process models and detailed business use cases.■■ Build/update process maps and use case library (ongoing).■■ Ensure appropriate representation in meetings to complete detailed

process models and business use cases (e.g., SME, SA).■■ Distribute materials and conduct walkthrough of detailed process models.■■ Distribute materials and conduct walkthrough of detailed business use cases.■■ Identify and document issues; assign owners and facilitate requirement issue resolution.■■ update requirements traceability documents based on detailed requirement activities.■■ Provide information to project test leads as input to project test strategy.■■ Support scope change management process and update documentation as appropriate.

■■ Assist with issue resolution, provide clarification, and respond to questions.

■■ Support scope change management process and update documentation as needed

■■ Provide test support for test scenario identification and defect resolution.

■■ Provide input for implementation planning.■■ Provide support for clarifying questions, etc.

■■ Provide support for clarifying questions, etc.

Project Initiation/Awareness Meeting Planning Requirements Design

High-Level Requirements Detail Requirements

Construction Testing Implementation Warranty

DERF 06-4680






32




33

Section 3: Creating Compelling Business Cases

CREATING COMPELLING BUSINESS CASES



34

CREATINg COMPELLINg BUSINESS CASES

Articulate and Quantify Business Benefits

Measure and communicate proposed project benefits by linking components of business value to requirements.

Fenton, Inc.’s1 Functionality ROI Maximization • 35Fenton Inc. itemizes the benefits in the business case, quantifying the value 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 they can be traced through the lifecycle.

2. Be an order shaper when it comes to benefits: Compel business partners to articulate a project’s benefits in terms of quantifiable components that are directly tied to a particular aspect of their workflow.

3. Prioritize features and requirements based on business benefit: Benefit is the most meaningful metric for determining a project’s value. Be specific when it comes to quantifying those values.

4. Track RoI at the portfolio level: only a portfolio view can detect trends across categories and effectively communicate value delivery at the enterprise level.

When to Use■■ To itemize benefits in a business case■■ To trace benefits through the project lifecycle■■ To prioritize requirements according to quantifiable benefits■■ To track project RoI trends at the portfolio level


McDonald’s Business Case Abstract • 44BAs are called by the business relationship managers to help create business case abstracts and prepare any related preproject work, such as helping with cost estimation.

When to Use■■ To create business case abstracts


Omega Corporation’s1 Standard Business Case Criteria • 45omega Corporation revises business case review processes for IT projects to instill business sponsor accountability and emphasize quantifiable, “hard” business benefits. The process starts with a standard business case that captures total five-year costs of ownership, including common “hidden” costs often overlooked by business users during business case preparation. These proposals include architecture compliance, sourcing considerations, and operating requirements, such as infrastructure costs, maintenance, training, and support.

When to Use■■ To create a business case proposal capturing hidden requirements


Citrix’s Business Case Summary • 46Citrix synthesizes key IT project data—including financial metrics, risk indicators, and business justification—in a one-page format for easy steering committee review.

When to Use■■ To create a high-level business summary emphasizing quantifiable business benefits


1 Pseudonym.








35

Business Activity 3Business Activity 2Business Activity 1

Application Functionality

1


2


3


4

Business value Components

Component 2Component 1

High-Level Requirements

System Capabilities

Business Case

Business Value Cascade Key Challenges Business Value Realization Steps

■■ Itemizing the benefits in the business case

■■ Quantifying the value of application functionality

■■ Tracking project RoI trends at the portfolio level

Business Value

Mapping

Benefit-Driven Feature

Prioritization

Portfolio ROI Dashboard

Monolithic business case

Business value drivers are not connected to specific business activities.

Business activities don’t tie to specific application functionality.

1

2

3

DERF 07-3567

Catalog # AEC18FJCvL

Title AER Day 2 ST

ARTICULATE AND QUANTIFY BUSINESS BENEFITS

Fenton, Inc.’s Functionality ROI Maximization1. Connect Application Functionality to the Drivers of Business Value

1 Pseudonym.

1




36

Expected Benefits from Business CaseComputer Telephony Integration Project

Computer Telephony Integration WorkflowIllustrative

Efficiency goals

a. Increased use of call automation $500 K

b. Timely handling of call $275 K

c. Efficient transfer to sales $25 K

d. Reduced calls to help desk $100 K

e. Reduced call escalation $200 K

Total = $1.1 M

Effectiveness goalsa. Increased customer retention $1 M

b. Intelligent call routing $5 M

Total = $6 M

Business Value Components Component Quantification Template

Cost Reduction

Revenue Increases

$1.1 M

$6 M

$7.1 M

Goal: Timely handling of call

Baseline: 85 seconds

Target: 74 seconds

Improvement: 11 seconds

Cost Savings: $275 K

Calculation: 390 hours x $13.55 x 52 = $275 K

EndCall completeCustomer is greeted by

name.

Customer opts for live person.

Customer calls automated

system.

No

Yes

one and

done?

Escalated call

Sales referral

Help ticket opened

Increased use of call automation = $500 K

Timely handling of call = $275 K

Intelligent call routing = $5 M

Reduced calls to help desk = $100 K

Reduced call escalation = $200 K

a b g

Efficient transfer to sales = $25 K

c

d e

Increased customer retention = $1 M

f

Start

The 11-second improvement is the measurable value Fenton, Inc. monitors to track benefits realization.

DERF 07-3567


Title AER Day 2 ST

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED)

Fenton, Inc.’s Functionality ROI Maximization (Continued)2. Connect Business Value to Business Process


1

1 Pseudonym.



37

Categories Scoring Options Scoring guidelines

Quantifiable Business Objectives (QBOs)

Evaluate the project’s objectives and needs, based on its inherent ability to be understood and documented in a clear, unambiguous, and verifiable manner.

1 objectives and needs are very clearly understood and are verifiable and attainable.

5 Lack of clarity exists with respect to the project’s objectives and needs, or it is uncertain how the business objectives can be verified or satisfied.

9No ability to state project objectives and needs in unambiguous and/or verifiable terms; little certainty on how the project will deliver real business value.

Customer Impact

Evaluate the project for its anticipated impact on the customer. Indicate whether the customer is internal or external.

Definition: Impact—Affects the product or service the customer receives and/or the manner in which they receive it

1Project implementation is expected to be virtually transparent to the external customer AND the project will have little impact on internal customers.

5 Project is expected to have marginal impact on the external customer AND/oR significant impact on the internal customer.

9Project is expected to have significant impact on the external customer AND significant impact on the internal customer.

Business Process Reengineering (Cost Reduction)

Evaluate the project for opportunities to reduce operating costs through the enhancement of business process performance.

1Proper use of technology requires very little workflow integration. Contextual and environmental factors do not weigh significantly on the ability of the technology component to yield measurable business value.

5 Marginal opportunities to enhance process performance may exist, but significant gains in business value may not be certain. Also the project’s success likely will not depend on business process enhancements.

9 Six Sigma and related techniques, focusing on process efficiency and developing robustness against environmental noise, will most certainly deliver significant business value. Project success may depend on it.

Project Objectives and Needs

Evaluate the project for an understanding of how its benefits will translate to a quantified, positive impact on the sponsoring entity’s business objectives.

1 Clear and concise understanding of how the project benefits will result in a positive, quantified impact on the sponsor’s business objectives. The benefit impact is supported by precise and verifiable cost and/or revenue data.

5 A case has been articulated for how the project can yield benefits that will positively impact the sponsor’s business objectives, but the 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.

Evaluators are asked to provide a brief written assessment for each of the seven categories and a brief explanation of the rationale behind their scoring decision.

Three most important criteria in determining whether intervention is required

DERF 07-3567


Title AER Day 2 ST


Fenton, Inc.’s Functionality ROI Maximization (Continued)2. Connect Business Value to Business Process (Continued)

Discretionary Project Assessment


1

1 Pseudonym.



38



Categories Scoring Options Scoring guidelines

Profit Potential (Revenue growth)

Evaluate the project’s or product’s impact on, or capacity to generate, profitable revenue growth.

1 Project objectives are not likely to drive significant, profitable revenue generation. The use of Six Sigma resources is not warranted based solely on profit potential.

5 Project objectives may drive significant, profitable revenue generation. The use of Six Sigma resources is likely warranted based on profit potential.

9Project objectives have a large potential to drive substantial, profitable revenue growth. The use of Six Sigma resources is most certainly warranted based on profit potential.

Sponsor Interdependency

Evaluate the project based on the level of sponsorship interdependency.

1The project has the full support of the sponsoring entities AND no conflicting needs exist among those entities (or only one sponsoring entity is involved).

5 There is moderate support from the sponsoring entities AND/oR there are limited conflicts between the needs of sponsoring entities.

9There is limited support from the sponsoring entities AND there are potentially significant conflicts between the needs of sponsoring entities.

Human Interaction with Technology

Evaluate the project based on the anticipated degree of human interaction with technology components in the use environment.

1Normal operations in the target environment will involve very little depth of human interaction with technology AND the number of human users that directly interact with technology will be relatively insignificant.

5 Normal operation in the target environment may involve significant depth of human interaction with technology AND/oR the number of human users that directly interact with technology may be significant.

9 Normal operation in the target environment will involve significant depth of human interaction with technology AND the number of human users that directly interact with technology will most certainly be significant.

Total Score (Sum of Scores as a Percentage)

SummaryProvide an overall summary of the project and recommendations. Threshold

(45–63) Intervention Required

(31–44) Reevaluate

(7–30) No Intervention Required

DERF 07-3567


Title AER Day 2 ST


Discretionary Project Assessment

1

1 Pseudonym.



39



Revenue Attainment2Cost Reduction2

Speed Consistent Procedures

Waste Rework/Handoffs

Elimination of Work Steps

Defect-Reduction Products/Services

Customer-Valued Products/Services

Process Effectiveness

qBO opportunity: Measure and increase customer value.

Process Efficiency

qBO opportunity: Measure and decrease operating costs.

Business Process Process Output

Quantifiable Business Objectives (QBO)

A Measure of Net Business Value

Critical Attributes of Cost Critical Attributes of Quality

DERF 07-3567


Title AER Day 2 ST


Efficiency and Effectiveness of Business Process Performance

1

1 Pseudonym.2 Representative list.



40


Fenton, Inc.’s Functionality ROI Maximization (Continued)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.

DERF 07-3567


Title AER Day 2 ST


1

1 Pseudonym.



41


Fenton, Inc.’s Functionality ROI Maximization (Continued)4. Track ROI at the Portfolio Level

A Heat Map Representation Clarifies the Distribution of Portfolio ROI

Key Advantages

■■ High-impact communication tool■■ Portfolio pattern recognition■■ RoI trend monitoring

Business Revenue

Customer Value—Base

Customer Value—Competitive

Customer Value—Differentiated

Cost-Efficiency/Compliance

High

Low

HighLow

Project Cost

Bus

ines

s V

alue

The size of the bubble depicts the project return.

DERF 07-3567


Title AER Day 2 ST


1

1 Pseudonym.



42

Business Value Category Definition QBO Requirements

Customer Value—Differentiated Establishes a unique capability for the external customer over one’s peers/competitors based on cost, quality, speed, and/or functionality

■■ VoC illustrates industry gap to meet order of magnitude customer needs.

■■ Ethnography to survey techniques

■■ Predictive market analytics

Customer Value—Competitive Provides where there are optional features for the external customer and/or failing to match the equivalent capability of peers/competitors will erode ones competitive standing over time

■■ VoC illustrates company’s gap to competitors to meet customer needs.

■■ Focus group to survey techniques

■■ Responsive market analytics

Customer Value—Base Provides where properties are defined as a enabling minimum capabilities for the external customer—a commodity in nature

■■ N/A—May be combined with other business outcomes

Business Revenue Limited received value gain for the external customer but enabling revenue gain to the company

■■ Present historical, data-based customer behavior patterns to support proposed change.

■■ Existing or competitors’ customers

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 capabilities with limited external customer value or internal efficiency gains

■■ Demonstrate no linkage to customer value or operating efficiency, or cost reduction/avoidance.

■■ Baseline current state; demonstrate future state achievement to baseline

Enterprise Capability Provides broad underlying capabilities supporting multiple LoBs, projects, or future corporate/strategic initiatives

■■ Must support “x” number of future capabilities

■■ Measurable expectation of capability achievement

■■ Demonstrate scalability, cost effectiveness, supportability, etc.

operating Efficiency Provides ongoing internal cost reductions or other supporting internal operational factors (e.g., time to deliver, internal consolidations)

■■ Demonstration of activities that will result in a reduction of ongoing costs (per unit or total business process)

Regulatory/Compliance As required by government, internal audits or other regulations with limited external customer value or internal efficiency gains

■■ Demonstrate ability to maintain current operating efficiency.

■■ Demonstrate effectiveness of compliance solution.

■■ Demonstrate potential financial impact to corporation.

■■ Explain impact to internal or external customers.


Fenton, Inc.’s Functionality ROI Maximization (Continued)4. Track ROI at the Portfolio Level (Continued)

Business Value Categories

DERF 07-3567


Title AER Day 2 ST


1

1 Pseudonym.



43

Business Outcome

Project Count

Percentage of Projects

Total Investments

Percentage of Investment

Average Cost per Project

Cost Relationship to Average

QBO $ QBO %Average QBO per Project

QBO $ per Investments

Business Revenue

5 11% $8,052,504 11% $1,610,501 85.5% $25,341,001 7% $5,068,200 $3.15

Customer Value—Base

10 5% $1,520,317 2% $152,031 8.07% $4,000,430 1% $400,043 $2.63

Customer Value— Competitive

13 12% $10,314,678 14% $793,436 42.1% $86,531,408 23% $6,656,262 $8.39

Customer Value— Differentiated

5 7% $32,533,255 45% $6,506,651 345.4% $168,121,704 45% $33,624,341 $5.12

Cost-Efficiency/Compliance

58 65% $20,600,152 28% $355,175 18.9% $91,196,549 24% $1,572,354 $4.43

grand Total 91 100% $73,020,906 100% $1,883,559 100% $375,191,092 100% $47,321,200 $5.14


Fenton, Inc.’s Functionality ROI Maximization (Continued)4. Track ROI at the Portfolio Level (Continued)

DERF 07-3567


Title AER Day 2 ST

Business Value Categories (Continued)Business Benefit Scorecard


1

1 Pseudonym.



44


McDonald’s Business Case AbstractIllustrative Example

Real Estate and Construction Cost Project

Objective

Provide timely and accurate real estate and construction capital expenditure information; this will enhance McDonald’s ability to optimize investment decisions, drive down costs, and speed the administration of the closeout of construction projects.

Solution Summary

Improve investment decisions and strengthen McDonald’s leverage with suppliers during construction project negotiation by:

■■ Providing timely and accurate reporting of real estate and construction capital expenditure plans, actuals, and projections;

■■ Driving supplier optimization and savings through comparison of project component costs (i.e., asphalt, concrete, framing); this will strengthen cost controls by enabling reporting on baseline commodity prices; and

■■ Driving general contractor savings through comparisons of construction costs and “time to complete” across multiple projects, phases, building types, geography, and square footage.

Improve accounting administration efficiencies of existing restaurant remodels and new site construction by:

■■ Automating creation of capital expenditure reports;■■ Reducing financial reconciliation effort through improved system integration;

■■ Reducing project closeout time by improved system integration;■■ Enabling access to the new application by all key stakeholders, which includes 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.

Real Estate and Construction Cost Project

Benefits

■■ Direct/Hard Savings—None■■ Indirect/Soft Benefits

– Construction supplier optimization and cost avoidance – General contractor optimization and cost avoidance – Improved accounting administration efficiencies

■■ TIB Screens■■ Business Alignment—MODERATE

– Be the most productive provider by achieving G&A and capital expenditure targets

■■ Leverage—MODERATE—US/Corp. solution■■ Financial Strength—WEAK—Benefits are indirect/soft

Risks

■■ Software vendors able to meet McDonald’s business requirements without extensive custom programming

DERF 07-0715

Catalog # AEC17FJDPH

Title Business quant ST




45


Omega Corporation’s Standard Business Case Criteria

Standard IT Project Business Case

Financial Analysis Architecture Review opportunity Analysis

Project Valuation

■■ Payback period■■ NPV■■ IRR■■ RoI

Five-Year Cost–Benefit Analysis

■■ Benefit Analysis■■ Software capitalization■■ R&D tax credit analysis■■ Detailed cash flow and P&L impact including:

– Benefits (e.g., increased revenue, revenue protection, expense reductions, cost avoidance)

– Project costs – Capital (hardware, software, and other) – Expenses

– operating expenses – Support staff – ongoing maintenance (hardware, software) – Training – Communications, etc.

■■ Project category – Strategic development – Mandated initiatives – Discretionary enhancements

■■ Consistency with IT architecture and data standards

■■ opportunities to use existing functionality■■ Critical timing issues

■■ Project description, rationale, intended functionality

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

Sourcing Review operations Review

■■ Project vendor selection process■■ opportunities to reuse existing contracts■■ offshore development opportunities■■ Lease-versus-buy analysis

■■ Impact on existing infrastructure, software, and service contracts

■■ ongoing maintenance requirements■■ Savings and costs associated with decommissioning assets

■■ Contingency and recovery costs■■ Security and privacy compliance■■ Expected service quality

1

1 Pseudonym.




46CREATING COMPELLING

BUSINESS CASES

DERF 07-0058

Catalog # CIO17C4BX9

Title Portfolio Management


Cirtrix’s Business Case Summary

The IT organization compiles the summary from existing business case documentation.

Project objectives are linked to a predefined list of enterprise strategic, business-focused, and IT-centric goals.

Business Intellgence

Project Financials Comments Quantification

Total Benefits $200,000

100%

Total Capital $100,000

Total Expense $20,000 75%

Total Costs $120,000

IT Headcount (FTE) 0.50 Feed of enhanced BI inputs into SAP

High-Level Project Business Case

Jan.Project Close July

This project will accomplish the following:

1. Compare existing software to competitors to determine if we wish to continue with them or select another vendor.

2. Select vendor and complete contract negotiations.

3. Configure software.4. Train users.5. Deploy to production.

Project StartProject Go-Live

Will need 2 FTEs for 3 months

Percentage migration of data capture to new platform

Expected Impact

20% support costs

Metric Description

Use of enhanced functionality for data capture

Sept.

Data entry time reduced: 30 mins/week = .5hrs * 50 * 40 = 1,000 hrs p.a.Improved decision making: median project cost $100,000 * 100 p.a. * 2% improvement = $200 K

Business Intelligence PlatformFinance

George Deaver

Sponsoring Organization:

Sponsor:

Project Description

8/4/xx

Need to actively manage enterprise data flow using standard data architecture

Duplicate data entry between business unit interfaces reduces data quality, leading to ine�ciencies and missed opportunities

Actuals need to be tracked against forecasts to measure performance

Business Rationale

Submission Date:

IT Team:

Milestones

Risk Mitigation Establish pilot test platform with engineering group and apply lessons learned.

Use internal resources for build and maintenance to build and retain tool competence.

Run in parallel with current platform for two weeks.

Break delivery into phases with initial release not overlapping with break points in strategic planning cycle.

Enterprise Strategic goals Business Objectives IT Objectives

Value and Visibility Controls Align IT with Business

Multiple Products Cost Reduction Support Shared Admin and ops

Customer Leverage Customer Impact Be First and Best Citrix Customer

Next-Generation Partnership Employee Impact ops Excellence Through Consistent FrameworkSustainable Growth Continuous Improvement

Competitive Excellence Productivity Gains Provide Best Customer ExperiencePeople Development Revenue Generating



47

Section 4: Providing Accurate Project Effort Estimates

PROvIDING ACCURATE PROJECT EFFORT

ESTIMATES



48

PROVIDINg ACCURATE PROJECT EFFORT ESTIMATESEstimate Resource Requirements

Use a resource calculator to estimate resource needs based on elements of project complexity.

Marriott’s Staff Resource Estimation Calculator • 50Marriott disaggregates projects into common tasks and uses a calculator to determine resource needs. Categories are weighted based on relative complexity to generate an overall score. using the overall score, the calculator categorizes projects as requiring low to high labor to complete. For each task, labor categories directly convert to resource requirements in hours.

When to Use■■ To estimate project requirements at each task■■ To determine resource needs


Estimate Costs and Risks for Agile Projects

Allocate project funds and establish project schedule based on an analysis of best-, expected-, and worst-case cost scenarios.

TransCanada’s Risk-Based Estimation for Agile Projects • 51BAs lead the project, breaking down high-level requirements into detailed user stories, which delineates business rules and their corresponding validation messages enabling developers to easily connect requirements to unit tests. To establish a baseline project cost, the time and effort required to develop each user story is estimated. Project funding is allocated based on the coverage of cost scenarios: low-risk projects receive expected funding, high-risk projects receive worst-case scenario funding. overall, the Monte Carlo simulation allows for more informed decisions about project funding.

When to Use■■ To translate high-level requirements into user stories for Agile projects■■ To help developers connect requirements to unit tests


Manage Time and Budget on Agile Projects

Continually prioritize the product catalog and build contingency buffers into the plan to set realistic expectations for total cost and duration.

Raytheon’s Earned value Metrics for Agile Projects • 53Raytheon focuses scarce sponsor time and attention on critical risks and opportunities. Raytheon’s earned value metrics for Agile projects help teams to estimate cost and schedule despite the iterative and more ambiguous direction of Agile projects.

When to Use■■ To define requirements in a way that helps with project plan and estimate■■ To make story point estimates for all features■■ To inform business about potential risks and opportunities


Estimate Benefits for Agile Projects

Estimate the value of benefits using an options approach.

British Airways’ and Emergen’s Initial value Estimate for Agile Projects • 58British Airways estimates the value of major benefits streams and uses these estimates to prioritize work by Agile teams. As the team releases the solution on an iterative basis, actual value realization can be used to refine initial estimates and reprioritize. understanding that benefits’ value are not static, British Airways uses an options approach to control delivery risks.

When to Use■■ To elicit goals and testable metrics of project realization from business sponsors■■ To Identify and prioritize benefits for release



ESTIMATES

https://aec.executiveboard.com/Members/Popup/Download.aspx?cid=100117972&s=TC_ProjectManage






49

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



ESTIMATES





50

Complexity Drivers: Capacity Planning/Performance Engineering1. Application Technology 7. User Base

CoTS 2 HQ 1

Custom 4 International 4

other (New to Marriott) 5 Properties 4

Report/Batch Component 3 Res Centers 3

Weight 2 Score 8 Weight 3 Score 12

2. Number of Tiers 8. Client Type

one 1 WEB 1

Two 1 Fat/Thick 3

Three 2 Metaframe 4

Four 3 Terminal Services 5

> Four 4


3. Number of Unique OS/Platforms 9. Extranet

one 1 TAM Plugin 2

Two 1 AMS Junction 3

Three 2

Four 3

> Four 4


4. Number of Interfaces 10. Number of Business Functions

1–5 1 < 5 2

6–10 2 6–10 3

11–15 3 11–20 4

> 15 4 > 20 5


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

Replacing Existing Application 1

New Application to Marriott 3


6. Customization Level 12. User Volumes (Total Named Users)

High 4 < 100 1

Medium 2 100–500 2

Low 1 > 500 3

Weight 4 Score 8 Weight 3 Score 6Total Complexity Score 93

ESTIMATE RESOURCE REQUIREMENTS

Marriott’s Staff Resource Estimation CalculatorIllustrative

Web-Based Access Control Engineering

Project oversight

Task Areas

Database Architecture

Web Engineering

Desktop Certification

user and Device Security

Thin Client Devices and Software

Deployment Services

Server Builds

Middleware (Application Integration Solutions)

Capacity Planning/Performance Engineering

ID Admin and user Provisioning

Security Architecture

WAN Engineering

LAN Engineering

Configuration Management

Infrastructure Application

Access Control Implementation

Functional Support

Hours and Assessment Areas

Development Test ProductionEstimate Requirements and Performance

Script and Load Test

Troubleshoot Performance Issues

36 72 12

Total Complexity Score Labor Category

190–210 High148–189 Medium High64–147 Medium22–63 Medium Low0–21 Low

DERF xx-xxxx

Catalog # PMOEC6131810SYN

Title

Total score is correlated with estimates of up-front and ongoing resource needs.

questions are designed to determine the complexity of the project and the operational environment of the end product to generate reliable work estimates.


ESTIMATES

Categories and answer choices are weighted for relative complexity.



51

DERF 06-4858

Catalog #

Title

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 Biddable offer

Secure Winning Bid

Set Shipping Route

Award a Non-Prearranged Biddable Offer

1.1 Assumptions

1.2 Definitions

1.3 Process Flows

1.4 Screen Descriptions

1.5 Business Rules

1.6 Developer Comments

1.5 Business Rules: Award a Non-Prearranged Biddable Offer

Name Type Validations

Award Quantity

Integer 1. This field is editable if the corresponding checkbox is True (i.e., checked).

2. The amount awarded to a bid cannot be more than the max bid quantity for that bid.

System Message: Award quantity must not be greater than max bid quantity.

Checkbox Boolean Validation x

Bid Rate Decimal Validation Y

Developers write business rule validation logic…

…and then write Pass/Fail unit tests.

…based on the defined validation

message…

System Message X

Award quantity must not be greater than max bid quantity.

Pass

Tests when business rules are followed

Fail

Tests that error handling works as expected when the rules are broken


ESTIMATES



52

ESTIMATE COSTS AND RISKS FOR AgILE PROJECTS (CONTINUED)

TransCanada’s Risk-Based Estimation for Agile Projects (Continued)

DERF 06-4858

Catalog # AEC16TNJ4P

Title Agile Dev ST

Monte Carlo Simulation Results

0%

100%

WorstBestProject Cost in US Dollars

Pro

bab

ility

of

Co

st S

cena

rio

(P

erce

ntag

e)

Low-risk projects receive expected funding (covering 50% of cost scenarios).

High-risk projects receive worst-case funding (covering 90% of cost scenarios).

The largest ranges are reserved for the highly variable cost of development time.

Effort estimates include time for rework and code review.

Set Shipping Route

Estimated Effort (Hours) Best Expected Worst

Schemes/Services 15.00 27.00 52.00

Integration Migration 27.00 52.00 109.00

Architect Assistance 5.00 11.00 17.50

Define Validation Rules 5.00 10.00 15.00

Backend 77.50 141.00 250.00

uI 49.50 96.50 163.00

Total Development Time 179.00 337.50 606.50

Bug Fix 44.75 84.38 151.63

Code Review 57.00 57.00 57.00

Tech Lead Assistance 60.90 113.75 208.35

Total user Story Time (Effort) 520.65 930.13 1,629.98

Secure Winning Bid






Backend 77.50 141.00 250.00

uI 49.50 96.50 163.00


Bug Fix 44.75 84.38 151.63

Code Review 57.00 57.00 57.00



Award a Non-Prearranged Biddable Offer






Backend 77.50 141.00 250.00

uI 49.50 96.50 163.00


Bug Fix 44.75 84.38 151.63

Code Review 57.00 57.00 57.00



Range estimates allow for best- and worst-case scenarios.


ESTIMATES



53

MANAgE TIME AND BUDgET ON AgILE PROJECTS

Raytheon’s Earned Value Metrics for Agile Projects A Comparison of Agile and Waterfall Lifecycles

Waterfall

Agile

Sprints■■ Detailed Requirements■■ Develop■■ Test■■ 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.

Detailed requirements definition specifies all of the technical functionality that must be built.

Concept Definition and Business Case

Approval

Requirements Definition Design Development and

QA/Testing Deployment

Deployment

quality and value of functionality is typically verified only on release.

■■ No iterations; build to the specifications identified earlier.

■■ Submit change requests if needed.■■ End-to-end functionality is

delivered late in the cycle.

Concept Definition and Business Case

Approval

High-Level Requirements

Definition

Release Scope Planning

DERF 10-5038


Title ST: PMO AER Study


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.

DERF 10-5038




ESTIMATES



55


Raytheon’s Earned Value Metrics for Agile Projects (Continued)

What the Business Sponsor Cares About How Agile Delivers

A. Will we deliver the requirements to fulfill the business case?

1. Avoid building fallow functionality by incorporating frequent feedback loops ensuring relevance of requirements that have not been built yet.

2. Avoid scope creep by forcing a prioritization of scope based on expected value and available capacity.

B. Will we meet time-to-market requirements?3. Sequence high-value features to be delivered first and be able to cancel at

any time and be left with a working functionality.

C. Are we going to stay within budget?

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 tested and valuable functionality.

6. Build discrete components early to provide valid estimates for cost to complete.

D. Will we maximize value from the system?7. Provide end users opportunities early in the project to influence the

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

DERF 10-5038




ESTIMATES



56

DERF 10-5038



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?

1. Each team member is given a deck of cards with the same set of Fibonacci numbers (1, 2, 3, 5, 8, 13, 21...).

2. A user story is presented to the team.

3. Each team member selects a card from his or her deck, representing the number of story points he or she thinks the feature will require (relative to past features).

4. Everyone reveals their chosen number at once, and outliers discuss how they arrived at their estimates.

5. Teams can go through multiple rounds of poker for each story until they achieve relative consensus.

Step 2: Team Poker Estimation

Step 1: The User Stories

Step 3: Determine Worst-Case, Most Likely, and Best-Case Scenario Ranges for the Estimates

1 2 3 5 8 13 21Increasing Complexity

User StoryIdeal: 3 Points

Expected: 5 PointsWorst: 8 Points

Estimated Range


Raytheon’s Earned Value Metrics for Agile Projects (Continued)Total Project Cost Estimation

DERF 10-5038

Catalog #

Title


ESTIMATES



57

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.

Expected Percent Complete = 25%; Since only one of Four Iterations Completed

Planned Value = Expected Percent Complete; Total Budget = 25% × $175,000 = $43,750

Actual Percent Complete = Total Number of Story Points Completed ÷ Total Number of Story Points Planned = 40 ÷ 200 = 20% Complete

Earned Value = Actual Percent Complete; Total Budget = 20% of $175,000 = $35,000

Cost Performance Index (CPI) = Earned Value ÷ Actual Cost = $35,000 ÷ $65,000 = 0.53

Conclusion: Estimate Cost at Completion Is $175,000 ÷ 0.53 = $330,188, and We Are 47% Over Budget.

FeatureEstimate

(Story Points)

Completed (Story Points)

Actual Cost (Thousands of Dollars)

Welcome Screen 10 10 15

Advert—Splash Screen 20 20 30

Login Screen 10 10 20

Personalized Google Ads

20

Catalog Browser 20

Catalog Editor 10

Shopping Basket Browser

5

Shopping Card Editor 25

Check-out Process 20

Invoice Calculation 10

Credit Card Verification 10

PayPal Payment Handling

20

order Confirmation E-Mail

20

Totals 200 40 65


Raytheon’s Earned Value Metrics for Agile ProjectsFeature Backlog Status After Completing One of Four Iterations, Illustrative

DERF 10-5038




ESTIMATES



58

ESTIMATE BENEFITS FOR AgILE PROJECTS

British Airways’ and Emergen’s Initial Value Estimate for Agile Projects

Come up with better solutions by using

innovation techniques.

11

Track progress and value delivered

across the whole value stream.

13

Integrate the customer and

the analyst in the value stream.

12

Discover the goals of the client

and customer through interviews.

1

Discover the stakeholders and

their goals using a context diagram.

2Define the business

value model and the business value

drivers that will drive the project.

3Choose between

competing and conflicting

stakeholder goals by ranking goals against business

value drivers.

4Discover the highest-value

business process and its supporting

processes.

5

Elaborate business processes and the

domain model.

6Explore the process, define acceptance

criteria, and discover missing user stories

with “what if?” scenarios.

8

Define user stories to implement the

steps in the process.

7

Capture nonfunctional

requirements with acceptance criteria and service levels.

9

Improve your process with the

theory of constraints.1

10

1 Based on Eliyahu Goldratt’s 1984 text, The Goal.

DERF 10-5038




ESTIMATES

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



59

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

Project Paid Seating Project, Business Case: 100%

Value Propositions (Discrete Measurable Objectives Derived from the Business Case)

New Revenue Stream-Seating Sales

Improve Customer Experience

Call Center Efficiencies

Revenue Increase Revenue Retention Cost Reduction Initial Estimate of Contribution to Business Case

Benefits Streams50%

30%

20%

Tracking Metrics goals

Revenue Increase 10%

Revenue Retained 5%

Cost Reduction 3%

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.

offline Sales

Exit and other Seat Sales

These are initial values only that will be revisited as benefits tracking provides more information about customer behavior.

These benefits are the minimally marketable feature set that can provide functionality to end users and will move the business case metrics.

Basic online and Change and upgrade Sales

Basic online and Change and upgrade Sales

DERF 10-5038




ESTIMATES



60


British Airways’ and Emergen’s Initial Value Estimate for Agile Projects (Continued)An Agile Option: XYZ Benefits Stream

Illustrative

1. Initial Value Estimate of Option 2. Cost to Hold 3. Exercising Cost 4. Expiry Date and Conditions

$300 K $50 K $100 K 15 March unless market competition changes

Legend

1. Initial Value

■■ Monetary value estimate is based on assessed contribution to business benefit.

2. Cost to Hold (Options Buying Price)

■■ Effort to define/document■■ Effort to determine acceptance tests■■ Effort to elaborate for the developers to estimate

3. Exercising Cost

■■ Based on the effort estimate■■ Exercising cost may include switching costs that accrue when an option is deferred. Switching costs result from the need for a team to ramp up domain and project knowledge to pick up a deferred release.

4. Expiry Date and Conditions

■■ The date by which the decision must be taken to deliver the release by a desired date; the expiry date has embedded the lead time necessary to build the solution for a target release date.

DERF xx-xxxx


Title

use the initial value estimate of an option to tentatively prioritize it on a value proposition roadmap. Revise this value after each release in a benefits stream.

Calculate the cost to hold to ensure that the initial value estimate exceeds the cost of formulating the option.

Exercising costs will differ based on teams’ domain knowledge. For example, if an option is deferred, it may have a higher exercising cost when picked up by another team.

use the expiry date and conditions to understand the timebox for decision making and any changes that will impact that expiry date.

DERF 10-5038




ESTIMATES



61


British Airways’ and Emergen’s Initial Value Estimate for Agile Projects (Continued)Continuous Reprioritization Across Releases

Illustrative

Basic online Seating Sales

Exit Row Seat Sales

online

Final Value Proposition Roadmapllustrative

Release 1 october

Release 2 December

Release 3 January

Release 4 April

offline Seating Sales

Change and upgrade Seat

Initial Value Proposition Roadmapllustrative

Release 1 october

Release 2 December

Release 3 March

offline Seating Sales

Basic online Seating SalesChange and

upgrade Seat

Exit and other Seat

Sales online

Develop and Deploy

Initiate Benefits Tracking

Obtain Benefits Realization Information

from Previous Releases

Reevaluate Estimated

Benefits on Future Options

Reprioritize Benefits

54321

Using benefits realization information, this step validates and revises the previous estimates of value of the benefit to the business case.

DERF 10-5038




ESTIMATES



62


British Airways’ and Emergen’s Initial Value Estimate for Agile Projects (Continued)Initial Portfolio of Benefits

Voucher Project Paid Seating Project

Benefit A

Options Value: 50% of business case

Benefit B


Benefit C


Benefit D


Benefit A


Benefit B


Benefit C


Reprioritized Portfolio of Benefits

Voucher Benefit A

Realized Value: 90% of business case

Voucher Benefit B

Realized Value: 5% of business case

Paid Seating Benefit A


Paid Seating Benefit B


Paid Seating Benefit C


Voucher Benefit C

Updated Options Value: 5% of business case

Voucher Benefit D

Updated Options Value: 0% of business case

Options Revaluation Based on Benefits

Tracking

DERF 10-5038




ESTIMATES



63

Note: Maximum score equals 30.

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%

ESTIMATE TESTINg RESOURCES

Hartford’s Managing Time and Budget Trade-Offs in TestingProject Risk Scorecard

DERF xx-xxxx


Title


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

DERF xx-xxxx


Title


ESTIMATES



65

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

Scoring Criteria

∑ PR X ∑ IR

Test Case DescriptionProbability Risk Factor (PR) Impact Risk Factor (IR) Risk Score

∑ IR * ∑ PR Usage

FrequencyDefect

Prone AreasChange in

RequirementsComplexity Business Criticality

1 Sample Test Scenario 1 2 2 3 2 16

2

3

4

5


Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued)Risk-Based Prioritization Tool

DERF xx-xxxx


Title


ESTIMATES



66

1.0 INTRODUCTION

1.1 Background/Summary

1.2 Documentation and References

2.0 TEST OBJECTIVES

3.0 TESTINg SCOPE

3.1 Applications/Functions/Features to Be Tested

3.2 Applications/Functions/Features Not to Be Tested

4.0 DECISIONS, ISSUES, AND CONSTRAINTS

4.1 Decisions

4.2 Issues and Constraints

5.0 ASSUMPTIONS, RISKS, AND CONTINgENCIES

5.1 Assumptions

5.2 Exceptions

5.3 Risks/Contingencies

6.0 TESTINg LEVELS AND TYPES

6.1 unit Testing

6.2 Assembly Testing

6.3 System Integration Testing

6.4 Business Acceptance Testing

6.5 Types of Tests

7.0 TEST MANAgEMENT APPROACH

7.1 Test Environment

7.2 Test Tools

7.3 Test Data

7.4 Test Script/Case Database

7.5 Change Management

7.6 Version Control

7.7 Release Management Process/System

7.8 Test Metric Approach

7.9 Defect Tracking

8.0 PASS/FAIL CRITERIA—DEFECT TOLERANCE

9.0 ROLES AND RESPONSIBILITIES

10.0 ENTRY AND EXIT CRITERIA

11.0 TEST SCHEDULE

12.0 gLOSSARY

13.0 SIgN-OFF AND APPROVAL


Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued)Testing Strategy Documentation

DERF xx-xxxx


Title


ESTIMATES



67

Test Strategy Review Checklist


Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued)Testing Strategy Documentation (Continued)

Section Section Title Checklist Items Yes No NA Comments

1

Introduction

Has the project/application overview been documented?

2 Has the intended audience been identified appropriately?

3Have all the required documents been identified and referred to for preparing the test strategy?

4

Scope

Have in-scope and out-of-scope application modules/functions to be tested been identified clearly?

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 and Type

Have all the test levels and types been defined?

8 Have the entry and exit criteria for the applicable types of testing been determined?

9

Test Methodology

Has the requirements analysis process been identified?

10 Has the test process to be followed been defined?

11Has any exception to the QA framework been documented clearly along with its rationale?

12 Has the QA automation framework to be followed been defined? (If applicable)

13 Has the list of tools and its purpose for various QA activities been identified?

14 Have the different test environments for different types of testing been identified?

15Has the test design approach manual and automation been identified for various types of testing?

16 Has the high-level test data approach been determined?

17Has the test execution approach that details the testing cycles planned for been determined?

DERF xx-xxxx


Title


ESTIMATES



68

Test Strategy Review Checklist (Continued)



DERF xx-xxxx


Title


ESTIMATES

Section Section Title Checklist Items Yes No NA Comments

18

Test Management

Have test planning activities been outlined clearly?

19Has the process for change management on how changes are identified, communicated, and tracked to closure been outlined?

20Has the process on version control from development to testing environment been outlined?

21 Has the process for defect management been identified?

22Roles and

ResponsibilitiesHave all the required roles and responsibilities been clearly stated?

23Assumptions,

Risks, and Dependencies

Have the assumptions and dependencies that underlie the test strategy been identified?

24 Have the risks based on assumptions, dependencies and past data been identified?

25Are risks being assessed based on their likelihood, and are appropriate mitigations being determined to avoid the risks?

26Test Schedule

Does the test schedule contain appropriate timelines, and is it in synch with project plan?

27 Has the reference to project plan been provided?

28 ReferencesHave all the required documents been identified and referred to for preparing the test plan?



69

Test Requirements Traceability Matrix



Item No. Requirement ID Requirement Description Test Condition Name Test Case Name Defect ID

DERF xx-xxxx


Title


ESTIMATES



70


Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued)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

DERF xx-xxxx


Title


ESTIMATES



71

Project Resource MappingIllustrative

Business Unit 1 Jan. Feb.

Demand for Core

Billable Core

overage on Core $

Demand for Flex

Billable Flex $

Total Business unit 1 $


Demand for Core

Billable Core

over/under on Core $

Demand for Flex

Billable Flex $

Total Business unit 2 $


Business Unit Resource Cost EstimationIllustrative

Business Unit Project Manager Name

Assigned Project Name

January 2010

Business unit 1 John Yes Project 1 10

Business unit 1 Kathy No 0

Business unit 2 Christina Yes Project 7 10

Business unit 2 Karthik Yes Project 7 10

Business unit 3 Penny No 0

Business unit 3 Vikram No 0

Business unit 4 Penny No 0

Business unit 4 Vikram No 0

Business unit 4 Jennifer Yes Project 1 20

Total Testing Demand 50


Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued)Testing Demand Management Tools

DERF xx-xxxx


Title


ESTIMATES



72

ESTIMATE SERVICE COST

SKF’s Reusable Services for Large-Scale IntegrationsStep-by-Step Implementation Toolkit to Sustain Service Reuse

DERF 11-3302



1 Develop Data-Oriented Service DefinitionIdentify service components using a handful of data attributes.

2 Build a Price List for Services■■ Adopt pricing scheme per service component.

■■ Identify cost per service based on pricing scheme.

3 Measure Service Consumptionuse service inbound queue to count unique message IDs.

5 Identify Patterns of Service Usage

■■ Identify which components are widely used, moderately used, or not used across services.

■■ Assess the prevalence of service components across the portfolio.

6 Identify Opportunities for Service Consolidation, Modification, and Eliminationuse volume and rate of component and service consumption to identify reuse potential.

4 Use Existing Billing Structure to Track Service Consumptionuse existing cost center structure for applications to allocate costs to business users on a monthly basis.


ESTIMATES



73

ESTIMATE SERVICE COST (CONTINUED)

SKF’s Reusable Services for Large-Scale Integrations (Continued)Implementation Cost Model

Implementation and Support Costs per Year

Create a Service Price List

Maintain Catalog of Services

Make Decisions About ongoing

Reuse, Consolidation, or Elimination

one-Time Costs

ongoing Costs

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.

DERF xx-xxxx

Catalog # AEC0852611SY

Title

$150 $150

$20

$150

$20

$75


ESTIMATES


ESTIMATES

$20 K

$75 K

$150 K



74

ESTIMATE SERVICE COST (CONTINUED)

SKF’s Reusable Services for Large-Scale Integrations (Continued)Payback on Reusable Services

Service Reusability Model Service Reusability Assumptions

1 Service is consumed by business sponsor, and potentially, other business units.

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 the cost to create the initial service. Cost avoidance is not 100% due to the cost of modifying an existing service for a “custom fit” and developer time spent finding and learning about the service.

4 Typical payback period for a reusable service is 10 minutes; on average it takes three reuses to break even.

Six Months

Cost to Create

one-of-a-Kind Service

Service Consumption Chargeback

Benefits

Cost to Generalize

and Improve Service

Performance

Cost Avoidance Due to Reuse

Three Months One Month

40

40

4050

25100

4

32

1Data

Transformations

External Connections

Internal Connections

Conversion to Common

Message Format

DERF xx-xxxx


Title


ESTIMATES



75

Costs

A. Capital Cost of Building a Service

1. Service development cost per hour (fully loaded labor cost) $100

2. Estimated number of hours required for one data transformation 100

3. Estimated number of hours required for one internal data connection 50

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

5. Estimated number of hours required for one enterprise service bus 50

B. Service Fortification

6. Cost of fortification as a percentage of initial service development cost 50%

7. Number of months between initial service creation and service fortification 3

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

Benefits

A. Service Consumption During Its Lifecycle

12. Total number of requests for a single-use service per year 1,200,000

13. Change in scale of usage due to fortification of service into a reusable service (total number of requests for a fortified service divided by total number of requests for the same service before fortification on an annual basis)

2

14. Consumption charge per request per service $0.10

B. Reuse Cost Avoidance

15. Probability that a new user of the service would have asked for creation of the service, if it had not been fortified for reuse 0.000001

ESTIMATE SERVICE COST (CONTINUED)SKF’s Reusable Services for Large-Scale Integrations (Continued)Service Cost, Payback, and Consumption Calculator

DERF xx-xxxx


Title


ESTIMATES



76


ESTIMATES



77

Section 5: Architecture Management

ARCHITECTURE MANAGEMENT



78

ARCHITECTURE MANAgEMENT

Support Business-Led Technology Purchases

Guide business leaders to ask vendors the right questions to unearth the most likely technology selection pitfalls.

CareFusion’s Technology Buyer’s Guide • 79The Technology Buyer’s Guide, a tool developed by CareFusion, contains guidelines for business leaders in procuring technology solutions directly from vendors. It guides them to the right due diligence conversations to unearth common technology selection and implementation pitfalls.

The Buyer’s Guide equips business leaders with questions for vendors in four key categories:

1. Fit with identified business need

2. Implementation effort

3. Quality of the vendor partnership

4. Financial cost

When to Use■■ To manage interactions with technology vendors■■ To guide and coach business sponsors to make informed technology choices


Balance Process Maturity and Automation

Allow flexibility between automation and processes. Use Business Process Mapping (BPM) to create a roadmap for automation of processes.

Alpha’s1 Balancing Process Maturity and Automation • 83Alpha determines which processes to automate and at what level, while helping

to optimize process maturity. As Alpha’s BAs develop deep understanding of processes, they learn to tie requirements to appropriate levels of process maturity through a three-step process:

1. Define processes before automation.

2. Automate processes for which a strong business case can be made.

3. Continue automation to improve efficiency as process matures while avoiding process rigidity.

When to Use■■ To tie requirements to appropriate levels of process maturity■■ To use process analytics to make informed technology roadmaps■■ To prioritize process improvements


Support Service Reuse

Increase ROI from existing services by reengineering them based on service usage patterns and data patterns.

DirectTv’s Deriving Maximum value from Existing Technical Services • 86

DIRECTV identifies critical standard data definitions to reengineer and orchestrate existing services into higher-RoI service offerings based on current patterns in data and service usage.

When to Use■■ To understand data standardization opportunities for services■■ To identify solution interdependencies■■ To have informed conversations with architects on service usage patterns



1 Pseudonym.






79

Part 1: Questions for Self-Reflection

1. Have we defined metrics for assessing the success of this implementation? 2. Do we understand how end users will use this solution? 3. Have we spoken with the likely end users to understand how this would fit

into their existing way of working? 4. How likely is it that the way we use this solution changes over time?

Why Ask These Questions?■■ It is hard to assess the success of any project that lacks measurable outcomes from the onset.■■ Business sponsor’s perceptions of how a solution will be used often diverge from the ways in which they

are incorporated into end users’ workflows.■■ Failing to anticipate business change may result in costly adjustments to the solutions later.

Part 2: Differentiating Questions for the Vendor

1. We have identified 2–3 core problems this solution must resolve for us. Can you provide specific examples of how you have addressed these problems for other clients?

2. What type of preparation (data access, security, special configuration, etc.) was required to successfully resolve those clients’ problems?

3. Could we obtain a reference from a customer with the same or a highly similar problem?

Why Ask These Questions?■■ It is very hard to spot the main weaknesses of software solutions during the buying process—they

generally surface during implementation. Therefore, it is common for inexperienced buyers to feel that they don’t understand the potential pitfalls of a solution.

■■ Make customer references truly comparable by ensuring they align to a highly similar problem, rather than to the product the vendor is offering.

Part 3: Standard Questions for the Vendor■■ Fit with Identified Business Need 1. How many other organizations use this product?2. How are your other clients similar and different from us?3. Can you provide documented case-in-point examples of how other organizations use your product? 4. Can you provide a tailored demo to show how your product will resolve the specific need of our organization?

■■ Functionality1. 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 Fit1. 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?)

SUPPORT BUSINESS-LED TECHNOLOgY PURCHASES

CareFusion’s Technology Buyer’s guide1. Buyer’s Guide: Fit with Identified Needs

DERF 11-2898


Title MC: Issues Impacting Applications




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 where that data currently resides? How certain are we that we know?

2. Have we tested end users’ willingness to change their workflows to fit the tool “as is” with little or no customization?

3. How many of our best people are we willing to dedicate fulltime to serve as subject matter experts during solution implementation? Part-time?

4. Will we need to project manage the implementation of this solution? If so, what experience will be needed by the person in that role?

Why Ask These Questions?■■ out of all the requirements of a vendor solution implementation, data is the most complicated. It is also

the most likely to undermine the potential benefits as a result of the unforeseen amount of integration required for the solution to work as planned.

■■ Significant modifications to existing workflow frequently result in resistance and requests for customization, which cannot be achieved without an increase in the implementation effort.

■■ Subject matter expert (SME) involvement during solution implementation is the most commonly unanticipated bottleneck in project delivery. The time commitment required from SMEs is typically two to three times higher than originally estimated.


Differentiating Questions1. How many third-party service providers have you certified in implementing

your product? Would you be comfortable if we talk to some of them independently?

2. What percentage of your revenue comes from services rather than licensing?3. If we need to customize, how do you license for development and test

environments?4. What is the average implementation cost at your different licensing tiers?

Why Ask These Questions? ■■ Third-party service providers with experience implementing the solution can provide a more honest,

impartial assessment of its strengths and weaknesses, since they typically work with multiple vendors.■■ If the vendor’s business model relies heavily on services revenues, it could indicate that the configuration

and integration of the solution is highly complex. It also gives the vendor an incentive to prolong the implementation by offering customizations.

■■ Many vendors have very strict licensing terms that lead to exploding costs anytime that a client needs to do customization.

Part 3: Standard Questions for the Vendor■■ Integration1. Based on your clients’ experience, what other standard enterprise systems

does your product need to connect to perform as designed?2. Which standard enterprise systems need to draw from the data processed

through by your solution?3. What are the most commonly missed areas of integration for customers who

want to use it like us? For the kinds of uses we are thinking of in the future?■■ Customization1. How much customization have your other clients with uses like ours had to

do?2. Which types of IT SMEs will we need to commit to implementation?3. How many business SMEs will we need to commit to implementation?

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

continuity plans?6. Would you be willing to make adjustments to your current disaster recovery and business continuity plans

based on our IT department’s recommendations?


DERF 11-2898






81


CareFusion’s Technology Buyer’s guide (Continued)3. Buyer’s Guide: Quality of Vendor Partnership


1. What specific skills and expertise does this vendor provide that we lack within our Corporate IT organization?

2. How essential is the business problem that this vendor is helping us solve to the core operations of our business?

3. What is the minimal level of vendor relationship quality that we are willing to accept?

4. How do we define a partnership “deal breaker”?

Why Ask These Questions? ■■ The probability of a vendor lock-in—a situation in which our business becomes dependent on a vendor—is

higher if vendor skills and expertise are hard to find inside (or hire into) the internal IT department.■■ In their efforts to grow their own margins, vendors sometimes lower the quality of service they provide

if their product is key to a client’s core business operations.■■ Inexperienced technology buyers often buy third-party solutions without thinking through what would

cause them to want to terminate an agreement. Defining the “deal breakers” in advance helps establish consensus for when to shop for another vendor. It also helps communicate with the vendor what aspects of the service are most important.


Differentiating Questions1. How do you measure compliance with your own protocols for notifying your

customers about extraordinary events? (e.g., security events or business disruptions)2. How do you measure customer satisfaction? Who is the customer?

(End-users, the purchaser, IT?)3. Are these metrics included in the performance evaluation of your staff? 4. Have you defined standards for issue resolution? Can you share those

standards and your performance against them?

Why Ask These Questions?■■ Most vendor products require at least a minimal amount of support. unavailability of that support at a

critical time (e.g., security events, major disruptions) may significantly impact our business.■■ Including customer satisfaction metrics in staff performance evaluations ensures that vendor employees

are more likely to provide the desired level of support regardless of their level in the organization.■■ It is hard to anticipate potential problems with using the vendor solution, but reviewing standard issue

resolution procedures can serve as a proxy for understanding: a) Potential areas of concern, b) Expected level of service if those concerns materialize.

Part 3: Standard Questions for the Vendor■■ Service=Level Agreements (SLA)1. Are your SLAs calculated based on averages over a period of time or on a

single unit of services?2. Are there exclusions from meeting the defined SLA levels?

Note: SLAs define the availability of the vendor’s product and the response time you can expect from the vendor if something goes wrong with the product or if you have a question.

3. Would you be open to a trail period during which our IT department can assess your ability to meet SLAs?

■■ Professional and Cooperative Behavior1. 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?

■■ Effective Communication1. What is the standard communication process between your company and clients regarding important

issues?2. What is your internal standard for notifying clients about extraordinary events (e.g., security breaches)?■■ Proactive Support and Responsiveness1. What time zones does your staff reside in?2. Do you monitor over or underutilization of your services to identify and diagnose potential problems?■■ End-User Support1. What type of post-implementation training will you provide?2. Will you provide ongoing support?


DERF 11-2898






82


CareFusion’s Technology Buyer’s guide (Continued)4. Buyer’s Guide: Financial Cost


1. Have we figured out an internal break-even RoI point or a set of assumptions under which this investment is no longer a good idea? Have we explored how likely are those assumptions to come true?

2. What would be the non-financial impact of vendor insolvency on our business? Do we have a contingency plan in case this happens?

3. How comfortable are we with a long-term partnership with this vendor in which the terms of our agreement cannot be changed?

4. Is this vendor also selling products to our IT organization, which may be able to provide us with discounts or references?

Why Ask These Questions? ■■ Many business leaders report that in hindsight, they would have made more explicit assumptions about

the expected RoI from a vendor solution and that they would have altered some of their financial cost decisions if the assumptions were fully fleshed out.

■■ Like any business, SaaS vendors—both big and small—could run into financial trouble. Regardless of whether the turmoil experienced is temporary or permanent, it will have an impact on its clients.

■■ Vendor lock-in—a situation in which our business becomes critically dependent on a vendor—may not be favorable if the partnership is considered a short-term fix to a long-term problem.


Differentiating Questions1. Based on our current level of need, are we considered a “growth” account

or a “maintain” account?2. How have your prices changed in the last two years? What is likely to happen

to your prices in the next two years?3. Do you actively scan for areas of under or overutilization to propose contract

modifications based on individual client usage?

Why Ask These Questions?■■ Frequently, vendors provide only a partial view into the anticipated future costs of doing business with

them. To avoid surprises, contract negotiation should focus on fully understanding initial costs of entering into agreement with the vendor, as well as projected costs, their drivers, and their likely direction.

Part 3: Standard Questions for the Vendor■■ Price Competitiveness1. What is your unit of measure for the product and service? (e.g., per employee,

per device, per user account, per transaction, enterprise-wide license?2. What is the billing frequency? E.g., per month, per quarter, per year)?3. on average, by how much does a customer’s total spend with you rise

as he or she moves from lower tiers to higher tiers?4. Are there additional charges for exceeding various parameters, such as storage?■■ Cost Flexibility1. 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?)

■■ Source of Vendor Profits1. What is your margin on goods sold versus services sold?2. How much does an average client spend on professional services with your company?3. Based on our need and environment, how much custom implementation requiring paid support would

you recommend?■■ Vendor Stability1. How long have you been in business?2. At a high level, what is your company’s strategy for the next 12 to 18 months?


DERF 11-2898






83

Define requirements for automation of process component.

BALANCE PROCESS MATURITY AND AUTOMATION

Alpha’s Balancing Process Maturity and Automation

DERF xx-xxxx


Title

1

1 Pseudonym.

Investigate Process

Analyze Process Components

Decide Whether or Not to Automate

Yes No

■■ Review workflows.■■ Interview end users and SMEs.■■ Identify process components.

Determine current maturity of each process component by assessing:■■ Current level of automation; ■■ Number of different workflows across the organization; ■■ Lack of clarity about best workflow; and■■ Amount of change management required to automate.

Exclude from technology solution.

Select only those components that have significant process maturity, manual intensity, and lengthy cycle times (e.g., for automation).

Continue Monitoring Process■■ Consider automating as part of future capabilities consulting with the business. Any future considerations of automation must be measured in terms of their RoI in comparison with other enhancement and new development requests.

Key Question■■ Will automating this process deliver the best RoI to the business for the time it will require?

Optional■■ Create best practice guide for workflow as part of change management efforts.




84

DERF xx-xxxx


Title

BALANCE PROCESS MATURITY AND AUTOMATION (CONTINUED)

Alpha’s Balancing Process Maturity and Automation (Continued)Using Process Analytics to Inform Technology Roadmaps

Steps Key Activities and 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. Create an IT Business Process Mapping (BPM) team. ■■ Identify business process experts within IT.

■■ Adopt a BPM methodology.

■■ Select BPM tools.

1

1 Pseudonym.




85

BALANCE PROCESS MATURITY AND AUTOMATION (CONTINUED)

Alpha’s Balancing Process Maturity and Automation (Continued)Using Process Analytics to Inform Technology Roadmaps (Continued)

1

DERF xx-xxxx


Title


4. Expand scope of BPM.■■ Select initial projects with similar criteria to pilot projects.

■■ Tackle increasingly complex projects as maturity deepens.

■■ Automate mature processes.

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.

1 Pseudonym.




86

SUPPORT SERVICE REUSE

DirectTV’s Deriving Maximum Value from Existing Technical ServicesPartial Root-Cause Analysis of SOA Challenges

Objective Challenges Subchallenges Solutions

Narrow down the scope of data standardization efforts to only the data elements used by services.

Create standard data definitions in the middle layer (the canonical data model), rather than resolving standardization decisions across databases.

In addition to identifying commonalities in service usage, analyze patterns in input and output data used by services to simplify rationalization decisions.

Introduce composite services based on reoccurring data and service usage patterns.

Minimize disruptions in knowledge transfer about service usage among design teams through modular service training.

1

2

3

4

5

Improve the value of existing technical services (SoA).

Lack of consistent data standards and definitions

Too many redundant, low RoI services

It’s hard to know which data to standardize.

It’s hard to gain consensus on standard data formats and definitions.

It’s hard to identify service consolidation opportunities.

It’s hard to ensure service reusability.

It’s hard to set the right level of service abstraction (granularity).

DERF 11-4449


Title CS: DIRECTv Data Standardization




87

SUPPORT SERVICE REUSE (CONTINUED)

DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued)1. Identify Data Standardization Opportunities for Services

All dataCustomer, product, account, etc.

Filter 1: Is this data used by integration services?

Filter 2: Does the data exist in more than one database?

Yes

go

No

go

Formulate an enterprise standard in the canonical data model and

allow provider databases to retain local variations in definition.

Integrate data into the canonical data model.

Yes No

DERF 11-4449






88


DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued)2. Resolve Key Data Inconsistencies

Type of Data Inconsistency

Example—Customer Data Action

1. Format: Inconsistent way of recording identical data elements

Database A

John Smith

Database B

Mr. Smith, John

Define master data standards in the canonical data model and resolve inconsistencies between provider systems through the middleware.

2. Value: Inconsistent data inputs due to poor data quality

Database A

John Smith

Database B

John Smit

Identify quick-wins in data quality improvement through an analysis of data elements most frequently evoked by services.

3. Definition: Inconsistent definitions of what a data element means

Database A

John Smith

Database B

Alpha Company Inc.

Map consumer systems data definitions to master data standards in the canonical data model.

DERF 11-4449






89

Service Name (Old Services)

Service Description Service Input and Output Data Elements1

Name Address Phone Customer

IDPayments

Account Status

1. Look_up_customer

Provides customer information.I I I O O

2. Access Account

Retrieves customer account.I I O O

3. customer3.2 Modifies customer or account information.

I I I O I

4. Activation Activates access to new products or services

I O I O O I

5. vz3_billing Submits customer order for billing

I I O O I

Service Name (Old Services)

Service Description Service Input and Output Data Elements1


DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued)3. Maximize the Value from Existing Services

1 Illustration only; a data element can be both an input and an output from a service.

1. Standardization opportunityAn area where a consolidated service can be created (e.g., Customer Information)

2. Flexibility needsAreas where the use case of a service differs from the use case of the consolidated service

I Input data

o output data

Phone Customer

ID

1. Look_up_customer

Provides customer informationI I I o o

2. Access Account

Retrieves customer accountI I o o

3. customer3.2 Modifies customer or account information

I I I o I

Filter 2: Data input and output patterns—Identify commonalities in data inputs and outputs passed between consumer and provider systems.

Filter 1: Service usage commonalities— Identify a group of services that perform the same action (e.g., look up customer profile).

DERF 11-4449






90

Service Name (New Services)

Service Description Data Elements in the Canonical Data Model

Customer Account Product Service Orders Subscriptions

1. Customer Information

Provides customer information

2. Verify Product/Service Eligibility

Retrieves the products and/or services a customer is eligible to purchase

3. update Account

Modifies customer account information

4. Verify Address Confirms customer address information

5. Process order Submits customer order for billing

6. Activate Account

Activates access to new products or services

Elements of a Composite Integration Service

Data Called by a Consumer System

Composite Service Example: A customer calls the DIRECTv customer service line to add additional channels to her subscription.

Reengineered Service Orchestration AnalysisIllustrative

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


DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued) 4. Identify High-Value Composite Services

DERF 11-4449






91


DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued)5. Promote Continuous Service Education

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.

Key Questions in Integration Process Flow

Training Tool What Does It Provide? Benefits Key Elements

1. How do I use integration services?

Integration Services usage Guide

An introduction to the services ecosystem

Defines “rules of engagement” for using all integration services

Common elements and features and across all services

2. Which set of services are available to me?

Consumer System usage Guide

An access agreement into a suite of services exposed for a specific consumer system

Ensures alignment with workflows supported by the consumer system

■■ A mapping of business processes and services a consumer system is eligible to use

■■ Service-specific information such as default expiration time, usage pattern (synchronous, asynchronous, fire and forget, etc).

3. How do I use a specific service?

Service-Specific Interface Agreement1

A set of detailed guidelines on how to use a specific service

Minimizes ambiguity around how to use a service

Standards for input data, output data, return messages, configuration)

4. How do I know the service I used worked as intended?

Event Notification Specification Document2

A set of specifications for input data, return messages, and configuration information for asynchronous services

Enables quick asynchronous communication between consumer and provider systems on whether a particular transaction succeeded or failed

■■ Notification standards and guidelines

■■ Required versus optional message communications

DERF 11-4449






92ARCHITECTURE MANAGEMENT



93

Section 6: Designing for Usability

DESIGNING FOR USABILITY



94

DESIgNINg FOR USABILITYDesign for the End User

Identify areas to improve usability by surfacing roadblocks in knowledge workers’ workflows.

LexisNexis’s Uncovering Unarticulated Needs • 95Capture knowledge worker pain points in the form of problem statements that correlate to the impact on productivity. Tie productivity roadblocks to a knowledge worker role objectives to surface business transformation needs for translation into technology design. Prioritized productivity roadblocks undergo a rigorous solution ideation phase, which results in high-fidelity wireframes and prototypes that become primary input into subsequent design stages.

When to Use■■ To surface end-user needs and translate them into technology design■■ To create a technical solution design tied to end-user productivity improvements


Improve System Usability

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


Develop Customer Intelligence

Develop a deeper understanding of customers’ technology use, needs, and expectations to bridge business sponsors’ strategic requirements with end users’ functionality needs.

Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions • 100

Standard Chartered’s Applications function develops a deeper understanding of customers and the demands they place on applications through analysis of service tickets and by soliciting ongoing feedback from end users. Standard Chartered understands customers’ technology use, needs, and expectations to bridge business sponsors’ strategic requirements with end users’ functionality needs.

When to Use■■ To develop customer intelligence to increase end-user efficiency■■ To recommend end-user workflow and usability improvements ■■ To bridge business sponsors’ strategic requirements with end users’ functionality needs



https://aec.executiveboard.com/Members/Popup/Download.aspx?cid=101031709&s=TC_Mobile_Apps_Dev






95

DESIgN FOR THE END USER

LexisNexis’s Uncovering Unarticulated NeedsProblem Statement for a New Business Development Junior Executive

Illustrative

Impact on Knowledge

Worker Productivity

=…the number of

interruptions I have during my work day…

2. Unit of Measure

Minimize…

1. Direction

…to free up time to identify new opportunities

to find new clients.

3. Outcome

Role Objective

Problem-to-Objective MappingIllustrative

1 Anthony ullwick, What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services, New York: McGraw Hill, 2005.

Satisfaction: 1–10

1—Not at All Satisfied

10—Highly Satisfied

Importance: 1–10

1—Not at All Important

10—Very Important

Difficulty: High/Medium/Low

New Business Development Junior Executive Importance Satisfaction 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.

9.5 6.5 High

a. Minimize the number of interruptions I have during my work day to free up time to identify new opportunities to find new clients.

b. Increase the number of contacts I have with clients to improve my sales pipeline.

2. Widen my network of business contacts to start marketing myself and build a book of business.

8 6.3 High

a. Minimize the time it takes to build and bring in a book of business to improve my performance against goal.

Relevant Problem Statements




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

Imp

ort

ance

of

the

Ob

ject

ive

Less Important

Very Important

High Low

Satisfaction with the Current Solution(s)

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

3. “ Widen my network of business contacts to start marketing myself and build a book of business.”

2. “ Identify an interesting market that would allow me to grow the business by 10%.”

Medium Difficulty

High Difficulty

Knowledge Worker objectives Identified as “Knowledge Worker Imperatives”

other Knowledge Worker objectives

Importance: 1–10

1—Not at All Important

10—Very Important

Satisfaction: 1–10

1—Not at All Satisfied

10—Highly Satisfied




97

DESIgN FOR THE END USER (CONTINUED)

LexisNexis’s Uncovering Hidden Productivity Improvement Opportunities (Continued)Knowledge Worker Imperative-Driven Design Process

Solution Ideation

Pre-Feature Assessment

Session

Feature Assessment

Session (FAS)

Design Roadmap Update

Project Kickoff

Input

■■ Knowledge worker imperatives

■■ Voice of the knowledge worker (e.g., interview scripts and recordings)

■■ Problem statements associated with the knowledge worker imperatives

Process Output

■■ Design documents

■■ High-fidelity wireframes

■■ High-fidelity service prototypes

■■ Initial solution concepts

Knowledge Workers

Innovation Team

■■ Customer Advocate

■■ Product Champion

Technical Teams

■■ Enterprise Architects

■■ Domain Architects

■■ user-Experience Team

■■ Prototyping Team




98

IMPROVE SYSTEM USABILITY

Kimberly-Clark’s Usability Leading IndicatorsPreemptive Performance Tracking

Is the business process itself inherently inefficient?

Is the system performing as it should?

Is performance degradation due to user inefficiency?

Does the user know how to use the application correctly?

Is the application too difficult to use correctly?

DERF 06-0359

Catalog #

Title

Potential Problems

Key Questions

User Experience Metrics

Confirming Metrics

1 Error frequency by business process

5 Average end-to-end response time

9 Number of errors per user

2 Time spent per screen 6 Number of processes executed

10 Error frequency by functionality usage

3 Ratio of number of processes completed versus aborted

7 Average process duration 11 Error frequency by error type

4 Ratio of actual completion time versus best practice

8 Cumulative user sessions by hour of day

12 Ratio of process “active” time versus “idle” time

Poorly Designed Business Process

Poor System Performance

Inefficient use




99

IMPROVE SYSTEM USABILITY (CONTINUED)

Kimberly-Clark’s Usability Leading Indicators (Continued)Usability Root-Cause Analysis

If “yes,” then proceed

If “yes,” then proceed

DERF 06-0359

Catalog #

Title

Too High

Too LowLevel One

Poorly Designed Business Processes

Is the business process efficient?

1 Error frequency by business processes

2 Time spent per screen

3 Ratio of number of processes completed versus aborted

4 Ratio of actual process completion time versus best practice

Level Two

Poor System Performance

Is the system performing as it should?

5 Average end-to-end response time

6 Number of processes executed

7 Average processes duration

8 Cumulative user sessions by hour of day

Level Three

Inefficient Use

Is the application being used efficiently?

9 Number of errors per user

10 Error frequency by functionality usage

11 Error frequency by error type

12 Ratio of process “active” time versus “idle” time

Patterns of values (signatures) indicate likely reason for performance lapse.




100

DEVELOP CUSTOMER INTELLIgENCE

Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions1. Use Multiple Channels to Understand Customer Needs

Sponsor/PM Conversation■■ Process efficiency■■ Cost, productivity, or revenue drivers

■■ Strategic changes

End-User Portal■■ Functionality■■ usability ■■ Workflow Improvements

Customer Survey■■ Relationship/ engagement quality

■■ Fit of existing solutions

■■ understanding of business issues

360˚ View of the Customer




101

DEVELOP CUSTOMER INTELLIgENCE (CONTINUED)

Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions (Continued)2. Recommend Workflow ImprovementsAnalyze Service Ticket Data to Achieve Valuable Service Outcomes

Error Type Error Impact Source User group Frequency

Application functionality

Access failure

Low (< 5% of users)

Missing patch

Call center technicians

10x/30 days

Business process

Incorrect report sequencing

High (> 25% of users)

Poorly mapped process

Business unit A line managers

21x/30 days

user Failed database query

High (> 25% of users)

Missing data field and set

Market researchers

13x/30 days

Look for Leading

Indicators

Analyze Service Ticket Data

Service Outcome

Enhance End-user Performance

Identify enhancement and/or customization opportunities as prioritized and identified by end users.

Number of errors per user group


Review business process errors to locate inefficiencies and identify solutions.

Error frequency by business process




102

1. Sponsor: Integrate country-specific requirements with current payroll system.

2. Solution Delivery Team: Deliver analysis to sponsor.

Portal

■■ Payroll data only in uS dollars■■ No foreign deduction calculations

Service Analysis

■■ Current payroll system rules and presentation interface do not align with the business’s strategic needs.

Analysis

■■ Adding data tables solves short-term need.■■ Additional data tables don’t simplify user interface.■■ Adding data tables increases current system complexity and likelihood of service failures and loss in productivity.

3. Solution Delivery Team: Provide recommendation based on sponsor and end-user analysis.

Recommendation

■■ Adopt new payroll solution that includes country-specific extensions to the core application.

4. Solution Delivery Team: Provide recommendation to sponsor.

5. Business accepts solution.


Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions (Continued)3. Bridge Sponsors’ Strategic Needs and End-Users’ Requirements




103


Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions (Continued)Process Steps


2. Develop multiple voice of the customer mechanisms to create a robust view of customer needs and priorities.

■■ Build a web-based solution portal where employees can submit questions, suggestions for new functionality, and applications enhancement requests.

■■ Make portfolio managers responsible for engaging business sponsors in a variety of discussions around pain points, strategic priorities, and market demands to build up customer knowledge.

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




104


Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions (Continued)Process Steps (Continued)


4. Build credibility by viewing every customer interaction as a service opportunity.

■■ Provide customer relationship training to all staff members.

■■ Focus initial conversations on stabilizing and improving current service levels (e.g., application availability and project tracking).

■■ With improving customer confidence, move from providing tactical and informational updates to engaging customers in strategic conversations.

3. Mine maintenance and support data to proactively identify service opportunities.

■■ Build a retrievable storage system for incident reports to increase their ability to reuse valuable information.

■■ Create common, searchable data fields for service tickets to allow for quick retrieval of information about a single customer or a particular type of service failure.

■■ Analyze service tickets to isolate applications performance issues occurring from specific user interactions or to identify trends within a single customer base.

■■ Identify customer behaviors that generate the same or similar service requests to uncover service improvement opportunities.




105

Section 7: Communications and Change Leadership

COMMUNICATIONS AND CHANGE LEADERSHIP



106

COMMUNICATIONS AND CHANgE LEADERSHIPDevelop Attributes of an Effective BA

Engage and challenge business sponsors’ assumptions.

Potential Attributes of an Effective Business-Facing IT Professional • 108Many of the attributes required in sales roles are increasingly applicable to business-facing IT professionals.

When to Use■■ To develop skills and behaviors of an effective BA


Representative Profiles • 109Like sales reps, BAs may adopt the profile of either a Challenger® or a Relationship Builder.

When to Use■■ To understand how different behaviors affect engagement outcomes


Critical Attributes of Challengers • 111Typically Relationship Builders are focused on resolving tension and creating a more collaborative, agreeable environment. on the other hand, Challengers succeed because they can teach, tailor, and create constructive tension with the sponsor. The Challenger’s success is based on the abilities to teach for differentiation, tailor for resonance, and assert control.

Typically, organizations and individuals overemphasize the risk of being aggressive. When developing attributes requiring asserting control, BAs must navigate between excessive passivity and aggression.

When to Use■■ To develop challenger attributes to create constructive tension in business engagement


Establish Effective Communication with Business Leaders

Communication strategies need to be tailored to business leaders’ temperaments and posture toward project change and their degree of influence on project outcomes.

Communication Challenges with Business Leaders • 114

Business leaders differ in their psychology, values, and assumptions about technology, placing strains on engagement with BAs. A growing percentage of business leaders are willing to lead in more aspects of applications projects.

When to Use■■ To understand behavioral temperaments of the business sponsor


Deconstruction of a Compelling Teaching Pitch • 115

A compelling teaching pitch reframes initial assumptions, showing underlying, unanticipated problems and building confidence in IT’s ability to deliver a new solution.

When to Use■■ To build confidence in your ability to deliver a new solution■■ To build effective communication skills










107

COMMUNICATIONS AND CHANgE LEADERSHIP (CONTINUED)Customer Outcomes Map • 117

BAs should tailor their communication approach based on how individual sponsors define success in their job, in terms of activities, metrics, or direction of outcome.

When to Use■■ To understand business sponsor’s definition of success■■ To tailor communication approach based on sponsor’s context and outcomes


Negotiation Roadmap • 119

The negotiation roadmap demystifies the behaviors of highly successful negotiators that can be applied for successful negotiations in a low-risk environment.

When to Use■■ To develop effective negotiation skills


Cisco’s High-Risk Stakeholder Communication Plan • 120

Cisco builds holistic stakeholder profiles capturing detailed information about stakeholder expectations and communication preferences. This information is used to identify high-risk stakeholder segments (e.g., stakeholders with high influence on project outcomes who actively resist project change).

When to Use■■ To document stakeholders’ expectations


Coca-Cola’s Building Transparency in Communications • 121

Coca-Cola fosters collaboration with business partners by communicating cost and risk information business partners need to make decisions.

When to Use■■ To improve conversation about business needs and options and cost-performance trade-offs.


Plan Change Management Activities

Target change communications based on stakeholder priorities

NetApp’s Governance Change Management Campaign • 122

NetApp identifies how stakeholders’ workflows will change and their concerns about the new governance process. They do the following:

■■ Address stakeholders’ concerns through targeted messaging of key benefits.

■■ Educate business executives about the initiative at governance forums and senior staff meetings.

■■ Create a company-level “umbrella message” about the governance process change and ensures specific messages for each stakeholder align with it.

When to Use■■ To effectively engage in change management activities■■ To develop consistent messaging for change initiatives






https://aec.executiveboard.com/Members/ResearchAndTools/Abstract.aspx?cid=100225582




108

DEVELOP ATTRIBUTES OF AN EFFECTIVE BA

Potential Attributes of an Effective Business-Facing IT Professional

Attitudes■■ Leverages Support■■ Interest in Feedback■■ outcomes Focused■■ Discretionary Effort■■ Tenacity■■ Curiosity■■ Experiments with Approach■■ Wants to Manage Company outcomes

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

Skills and Behaviors■■ Professional Image■■ Explores All options■■ Knows Value Drivers■■ offers a unique Perspective■■ Two-Way Communication Skills■■ Can Identify Economic Drivers■■ Can Pitch Strategy■■ Requests Assistance■■ Forms Good Partner Relationships■■ Has Advocates in Partners■■ Good Cross-Functional Relationships

■■ Ability to Work with the Team

■■ Respects Partner Time■■ Strategic Agility■■ Manages Expectations

Activities■■ Can Explain RoI■■ Meeting Preparation■■ Follows Formal Processes■■ Lead Generation■■ Analytical Skills

Knowledge■■ Product Knowledge ■■ Industry Knowledge

DERF 11-3914


Title MC: Targeted Business Engagement




109

DEVELOP ATTRIBUTES OF AN EFFECTIVE BA (CONTINUED)

Representative Profiles

n = 683 sales reps.

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

The Hard Worker (21% of Sample)

■■ Always willing to go the extra mile

■■ Doesn’t give up easily

■■ Self-motivated■■ Interested in feedback and development

The Challenger® (27% of Sample)

■■ Always has a different view of the world

■■ understands the customer’s business

■■ Loves to debate■■ Pushes the customer

The Relationship Builder (21% of Sample)

■■ Builds strong advocates in customer organization

■■ Generous in giving time to help others

■■ Gets along with everyone

Others (32% of Sample)

DERF 11-3914






110


Representative Profiles (Continued)

While individual differences exist, all respondents can be categorized in terms of their likelihood to exhibit one group of attributes over the others.

Challenger

■■ Knows Customer Value Drivers

■■ offers a unique Perspective

■■ Can Discuss Money

■■ Two-Way Communication Skills

■■ Can Identify Customer Economic Drivers

■■ Can Pressure Customer

■■ Can Pitch Strategy

■■ Product Knowledge

■■ Knows How Customers Differentiate

■■ Industry Knowledge

■■ Can Explain RoI of the Sale

■■ Professional Image

■■ Explores All options Before Closing

Hard Worker

■■ Motivated by Goals

■■ Discretionary Effort

■■ outcomes Focused

■■ Tenacity

■■ Project Management Skills

■■ Leverages Support

■■ Preparation Before Calls

■■ Follows Formal Sales Process

■■ Curiosity

■■ Interest in Feedback

■■ Learns Everything New

■■ Evaluates Likelihood of Purchase

■■ Experiments with Sales Approach

■■ Requests Assistance

■■ Generates Leads or Prospects

■■ Wants to Manage Company outcomes

Relationship Builder

■■ Forms Good Customer Relationships

■■ Has Advocates in Customers

■■ Attachment to the Company

■■ Can Work with Anyone

■■ Genuine

■■ Good Cross-Functional Relationships

■■ Accessible to Customer

■■ Gives Time to Help others

■■ Respects the Customer’s Time

Source: Integrated Sales Executive Council’s Rep Skills Diagnostic.

DERF 11-3914






111


Critical Attributes of Challengers

The Challenger profile focuses on building constructive tension in interactions to push customers out of their comfort zone.

■■ offers unique perspective

■■ Has two-way communication skills

■■ Knows customer value drivers

■■ Can identify economic drivers

■■ Is comfortable discussing money

■■ Can pressure the customer

The Relationship Builder profile focuses on resolving tension in interactions to make situations more amicable and positive and encourage collaboration.

■■ Forms good relationships

■■ Builds customer advocates

■■ Builds cross-functional relationships

■■ Can work with anyone

■■ Is genuine

■■ Is accessible to the customer

■■ Gives time to help others

■■ Respects the customer’s time

gets Along with Others

Teaches

Likeable

Tailors

generous with Time

Asserts Control

Implication for the Applications Function

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

Challenger Builder Profile Relationship Builder Profile

DERF 11-3914






112


Critical Attributes of Challengers (Continued)

Questions to Consider

What should my business-facing Applications staff teach?

How do I get my business-facing Applications staff to tailor?

How do I get my business-facing Applications staff to assert control?

How can I change the behavior of business-facing Applications staff?

Teach: Reframe the way business partners view their business and their needs.

Assert Control: Openly pursue goals in a direct but not aggressive way.

Tailor: Link your capabilities to business partners’ individual goals.

Teach for Differentiation

Tailor for Resonance

Assert Control

The New High Performer

Source: Integrated Sales Executive Council research.

DERF 11-3914






113


Critical Attributes of Challengers (Continued)

Passive

■■ Subverts goals to the needs of others

■■ Allows personal boundaries to be breached

■■ uses indirect, accommodating language

Assertive

■■ Directly pursues goals in constructive way

■■ Defends own personal boundaries

■■ uses direct language

Aggressive

■■ Pursues goals at the expense of professionalism

■■ Attacks others’ personal boundaries

■■ uses antagonistic language

Sales Performance Problem Common Sales Leadership Fear

Reps are often too passive with customers, seeking to resolve conflict whenever possible.

Tell sales reps to be more assertive and they may become aggressive.

DERF 11-3914






114

ESTABLISH EFFECTIVE COMMUNICATION WITH BUSINESS LEADERS

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 Technology Investments

■■ Business leaders differ in their views about how technology plays a role in their function/company role.

■■ Some view technology investments as critical to strategic outcomes, others as ancillary, and still others as irrelevant and not worth their time.

Likely Reaction to Engagement

■■ Standard engagement strategies from Applications and not received in standard ways by all business leaders.

■■ Some business leaders see engagement from Applications as a signal of poor performance and become defensive, others welcome engagement, and still others avoid it all together, adding additional barriers to Applications.

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.

DERF 11-2546


Title ST: quant Study




115

ESTABLISH EFFECTIVE COMMUNICATION WITH BUSINESS LEADERS (CONTINUED)

Deconstruction of a Compelling Teaching Pitch

“Em

oto

met

er”:

Lev

el o

f C

usto

mer

Exc

item

ent

Customer State

1. “Warmer”Building credibility by reading their mind and demonstrating empathy

2. “Reframe”First reframing of unrecognized problem, need, or assumption

3. “Rational Drowning”Gradual intensification of the problem, both in degree and closeness to the customer

4. “Emotional Impact”Description of the psychological features of the problem, or presence in the individual’s workflow, humanizing the problem

5. “Value Proposition— A New Way”Delivery of a new framework for addressing the problem; implicitly tied to the supplier value proposition

6. “Our Solution and Implementation Map”Map of supplier services or solutions linked back to key teaching points; highlighted path to implementation

Intrigued Drowning Involved Relieved

Positive

Neutral

Negative

Teaching follows boot camp theory of shocking the customer with the unknown…

…then building back the customer’s confidence in a new solution.

…breaking down the problem behind the unknown…


DERF 11-3914






116


Teaching Do’s and Don’ts


DON’T

Lead with your unique strengths.

Open with the breadth of your product portfolio and capabilities.

Focus on features and benefits.

Discuss how long your company has been in the marketplace.

Open with a focus on the customer and their issues.

DO

Lead to your unique strengths.

Make the sale personal and provide value to that individual.

Reframe customers’ understanding of their world.

DERF 11-3914






117


Customer Outcomes Map

Consumer Trade-Offs Business Leader Trade-Offs

■■ Regulatory Compliance Risk■■ Business Continuity Risk■■ Information Security Risk

■■ Hitting Cost and Scope Target■■ Speed to Market■■ Direct Benefits Realization■■ High Data Quality

■■ Total Percentage of Resources Required

■■ SME Time

Risks

Benefits

Business Effort

Required

Features

Quality

Price

Component Trade-Offs


An IT project has attributes in the areas of risk, benefits, and effort required from the business.



118


Concept Definition

Activity or responsibility in need of improvement

Metric used to measure success

Customer OutcomesWhat an individual customer

is trying to achieve—how they would define success in their job

Direction and magnitude of change necessary


DERF 11-3914






119


Negotiation Roadmap

Promise closure and seek permission to have a different conversation.

Expand potential solution components by surfacing areas of additional value.

Prioritize solution components by estimating their relative value to the customer.

Create plan and exchange value instead of giving it away.

Acknowledge and Defer

Deepen and Broaden

Explore and Compare

Concede According to Plan1

1 Concede according to plan is a principle that can be applied at any point during the negotiation conversation.

Source: Sales Executive Council research.

DERF 11-3914






120

ESTABLISH EFFECTIVE COMMUNICATION WITH BUSINESS LEADERS (CONTINUED)Cisco’s High-Risk Stakeholder Communication PlanIllustrative

DERF 09-3572

Catalog # PMOEC47894676

Title ST: Stakeholder Management

Stakeholder Segment Communications Details Key Message: What’s in It for Me?

High Influence, Resistant Posture

Target AudienceSenior Consultants, operations; operations Back office Personnel

Communication goalClosely manage expectations; improve change posture.

Level of DetailHigh-level budget and schedule communication; detailed functionality communication

Threats (Real or Perceived)Delayed rollout

Preferred ModeTrigger-based e-mail

“ We recognize the current process for submitting expense reports is time-intensive, and turnaround time is slow. The new system for submitting expenses will require less time for report submission, is more accurate, and will expedite your reimbursement turnaround time.”

High Influence, Supportive Posture

Target AudienceExecutive Sponsor; Project Sponsor

Communication goalClosely manage expectations; maintain change posture

Level of DetailHigh-level budget and schedule communication; medium-level vendor performance communication

Threats (Real or Perceived)Inadequate user training

Preferred ModeWeekly status updates; trigger-based phone call

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

Type of stakeholder drives the nature of communication plan and the degree of customization required.

Similarly themed messages are tailored for audience seniority, level of detail required, and degree of change resistance.

Customized project messages are developed and cataloged in advance. Key messages include the following:

■■ Elevator Speech■■ What’s in It for Me? ■■ Change Posture Pitch

Supportive

Neutral

Resistant

Low Medium High

Imp

acte

d

Infl

uen

tial

Mak

e o

r B

reak

Degree of Influence

Cha

nge

Po

stur

e

Supportive

Neutral

Resistant

Low Medium High

Imp

acte

d

Infl

uen

tial

Mak

e o

r B

reak

Degree of Influence

Cha

nge

Po

stur

e




121


Coca-Cola’s Building Transparency in Communications

A Transparency DeficitInformation Clarifying the Facts

■■ IT plans system changes based on its own time schedule, without full visibility of the impact on business processes.

System Change Management

■■ Ideal timing for systems changes is coordinated with business and determined by capacity to absorb change.

■■ IT makes assumptions about the business’s cost tolerance and narrows options accordingly.

Cost–Benefit Analysis

■■ IT presents solution options and lifecycle costs so that business can make the appropriate trade-offs between cost and performance.

■■ IT responds to all breakdowns according to SLAs.

Capability Investment Prioritization

■■ IT prioritizes its response to service disruptions according to business context and criticality.

IT often underappreciates or is unaware of the decision-making relevance to business partners of critical pieces of information.

IT is proactive in sharing the inputs that business partners require to make decisions affecting business performance with full knowledge of cost, risk, and available options.

■■ IT acts as an intake for business demand, managing dependency risk as an internal IT matter.

Interdependency Risk

■■ IT factors dependency risks into the business case for investment, giving business partners visibility on downstream and upstream impact.




122

PLAN CHANgE MANAgEMENT ACTIVITIES

NetApp’s governance Change Management Campaign

Stakeholder group

Change in Stakeholder Workflow Potential Stakeholder Concerns

Key Benefits Messaging

Senior Management

■■ For the first time, the right information will be visible up to the CEo level.

■■ Processes may not mature fast enough and stunt the company’s growth.

■■ IT may not adequately support the business.

■■ Better visibility on investments and returns

■■ Highest priority projects get the most attention

Business Executives

■■ Need to be more collaborative with IT and Finance in planning

■■ Need to align with the new governance models

■■ only approved projects will get done

■■ May create more red tape and reduce responsiveness

■■ Increased alignment of investments to functional strategies

■■ Higher thresholds of investments at the cross-functional council level approved by business units

IT Executives ■■ Share accountability for ensuring rigorous portfolio prioritization.

■■ Resistance to adoption ■■ Transformation of PMo from a policing to an enabling organization

■■ Investments better grouped and easier to manage

Account Managers

■■ Need to own the planning process and the transition to project delivery

■■ More bureaucracy that slows down work

■■ Fewer fire drills regarding portfolio and annual planning

Project Managers

■■ update cost–benefit analysis template at every project stage gate.

■■ More process steps to comply with

■■ Easier to communicate with business partners about projects due to consistent processes

Process Owners

■■ Process owner approval no longer required in project selection due to streamlined oversight

■■ Lower involvement in decision making

■■ Visibility into project pipeline and notification of changes when they occur

Anticipate potential pushback against the new process by considering each stakeholder’s concerns and tailors change management messaging accordingly.

DERF 11-4078


Title ST: Portfolio Management




123

PLAN CHANgE MANAgEMENT ACTIVITIES (CONTINUED)

NetApp’s Change Management Campaign Plan (Continued)

DERF 11-4078


Title ST: Portfolio Management

Communication Type

Content Audience Audience Time Commitment

Weekly E-Mails ■■ Provide context for changes, updates, and action items.

■■ Provide visibility on upcoming events.

End users and Business Leaders

10 minutes

Capability Training

■■ Provide training on using new governance and cost tracking/cost–benefit analysis capabilities.

Early Adopters and Trainers

2–5 hours

Webinar ■■ Provide an overview and set context for rollout capabilities.


1–2 hours

Brown Bags ■■ Provide an overview of the complete end-to-end process.

■■ Walk through the project lifecycle and finance process.

■■ Provide opportunity to ask questions and hear from others.

20+ “Phase 1” End users in 1 Location

3 hours

one-on-one Working Sessions

■■ Show how to complete the cost–benefit analysis template.

■■ Answer questions and provide any additional guidance.

20+ “Phase 1” End users in 1 Location

2–3 hours

Webinar ■■ Provide an overview of project lifecycle and change order go-live elements.


2 hours

Adoption Survey

■■ Assess end-user understanding and concerns. End users 30 minutes

Focus Groups ■■ Identify adoption risk areas. 6–8 Selected SMEs per Location

1 hour

Roadshows ■■ Provide update on status.

■■ Share results of adoption evaluation.

■■ Gain input, field questions related to Q1 rollout and future.

End users 2–3 hours




124COMMUNICATIONS AND CHANGE LEADERSHIP



125

Section 8: Business Relationship Management

BUSINESS RELATIONSHIP MANAGEMENT



126

BUSINESS RELATIONSHIP MANAgEMENT

Build an Engagement Strategy • 127

Tailor engagement to business leaders’ preferences for risk, benefit, and effort in IT projects.

Business executives fall into four temperaments based on their preferences and trade-offs for risk, return, and effort in Applications projects.

These pages outline the types of business leaders by temperament and the defining characteristics of each type.

When to Use■■ To understand business leaders preferences for project risk and return effort


Understand Business Sponsors’ Temperaments • 135

Four elements—sensitivity to benefits, aversion to risk, desire for control, and measures of success—define a unique business leader temperament.

These pages highlight a strategic guide to identifying business leader temperaments and key probing questions to identify a business leader’s profile.

When to Use■■ To tailor communication approach based on sponsor’s profile


Help Sponsors See Risk and Value Trade-Offs • 136

Clarify risk and value trade-offs.

CareFusion’s Clarifying Risk and value Trade-Offs

Apply CareFusion’s simple framework to help business leaders’ visualize risk and value trade-offs. Such a tool is part of the education/consultation for business leaders who want to take a more active leadership role in IT projects.

When to Use■■ To evaluate business leaders’ risk and value preferences


Track Changing Business Priorities • 137

Attain an enterprise wide view of changing business priorities.

CareFusion’s Business Trends Insight Mapuse CareFusion’s “insight map” approach to capture trends across business leaders that are valuable to Applications’ strategic planning and demand management.

When to Use■■ To create an enterprise-wide view of changing business priorities









127

BUILD AN ENgAgEMENT STRATEgY

Four Distinct Dimensions Where Business Executive Temperaments Think and Act Differently

DERF 11-2546




Success Measures

How a person views and measures past successes and defines success for a future project

Preferences along

these three dimensions

drive success measures.

Aversion to Risk

How willing a person is to take on increased risk in self-managing a project

Lure of Returns

The strength of the belief that one’s self-management of a project is necessary to capture returns

Desire for Control

How important self-managing IT projects is to an individual

The importance of three dimensions—desire for control, aversion to risk, and lure of returns—each defines how individuals measure success.

Each temperament displays a distinct behavior on each of these dimensions, with each having a unique profile based on these dimensions.



128

BUILD AN ENgAgEMENT STRATEgY (CONTINUED)

Archetypes of Business Leaders by Temperament

Willingness to Self-Manage SolutionHighLow

The Opportunists

51%

The Entrepreneurs

23%

The Cowboys

15%

The Abdicators

11%

Source: AEC 2011 Survey of Business Executives, May 2011.

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

Business leaders with rational risk/reward approaches to self-managed solutions who want to work with Applications in a new way

DERF 11-3914






129


Business Executives Fall into Four Temperaments Based on Their Preferences and Trade-Offs for Risk, Return, and Effort in Applications Projects

DERF 11-3914



Low HighOpenness to Persuasion

Low

High

Desire for Control

The Abdicators (11% of Sample) They want to do what they do and think IT should do IT.

Psychographics

■■ Avoiding management of IT projects at all costs■■ unswayed by the lure of high project returns

Top Concern

■■ Want to protect their time above all else

Demographics

■■ Typically have 5 to 15 years of work experience

The Opportunists (51% of Sample) Reformed Abdicators looking for opportunities to do it themselves

Psychographics

■■ Can be lured by high returns to self-manage projects■■ Avoiding risky IT projects at all costs

Top Concern

■■ Most concerned about getting the full scope of what they want

Demographics

■■ Typically have 5 to 15 years of work experience

The Cowboys (15% of Sample)See applications solutions as critical and need to control them; impatient

Psychographics

■■ Want to self-manage IT projects at all costs■■ Insensitive to risk

Top Concern

■■ Speed to market most important motivator

Demographics

■■ Typically have 16 to 25 years of experience

The Entrepreneurs (23% of Sample) Can look like Cowboys but have more rational desire to control projects; want to hit home runs and are willing to take risks to do it

Psychographics

■■ Will do it themselves for higher returns, even if taking on risk■■ Will do what it takes to attain business outcomes

Top Concern

■■ Most concerned about achieving business case/outcomes

Demographics

■■ Typically have 16 to 25 years of experience




130


Engaging the Abdicators

DERF 11-3914



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

Toughest Scenario—Traditional EngagementPractical Example: You are having difficulty in securing business leaders’ input on an IT–led project where you need active business sponsorship.

Challenger Response

Teach Tailor Assert Control■■ Tie Engagement to Regulatory or Strategic Risks: Give examples of how the Abdicator’s personal engagement will lower risks on corporate-level issues larger than the project and closer to his or her daily concerns.

■■ Tie Project Success to the Success of Their Daily Work: Abdicators want to focus on their domain only; tie engagement to project success and how that will improve their ability to work.

■■ Use Their Time Efficiently: Explain what you will do to respect their time and use it efficiently.

Driver: Abdicators only want to focus on their domain of expertise and are uninterested in IT projects.




131


Engaging the Opportunists

DERF 11-3914



The Opportunists

Sensitivity to Returns“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.”

Toughest Scenario: Bolstering Their ConfidencePractical Example—Concerned with potential risks, a business executive is in danger of missing an opportunity to obtain new capabilities because Applications resources are not available in a timely way to support the project.

Challenger Response

Teach Tailor Assert Control■■ Have Concrete Examples: Explain how risks have been managed in the past.

■■ Plan the Main Pain Points: Lay out a concrete support plan up front, demonstrating how they can count on Applications if problems arise.

■■ Provide a Coach: Access to personal support will reassure them.

■■ Explain the Impact of Their Involvement: Speak about how self-management increases the likelihood of achieving the scope or speed to market they desire.

■■ Be Specific: understand exactly what they want from a solution, and tie self-management directly to achievement of those goals.

■■ Address Alternatives: Make the alternative (Applications-managed projects) less desirable by playing up time delay and increased risk of missing business case or of not achieving scope.

Driver: opportunists overestimate the risks or underestimate the possible returns from self-management.




132


Engaging the Entrepreneurs

DERF 11-3914



Toughest Scenario: Pulling Them Back from the LedgePractical Example—A business leader is attempting to participate aggressively in a high-return project but is blind or indifferent to enterprise risk.

The Entrepreneurs

Sensitivity to Returns“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...”

Challenger Response

Teach Tailor Assert Control■■ Introduce Strategic Risks: Tie the impact of strategic risk, such as customer information loss or brand damage, directly to Entrepreneurs’ expressed business objectives.

■■ Amplify Risks: Make expected returns seem less than expected risks from self-management.

■■ Focus on Achieving the Business Case: This is Entrepreneurs’ greatest concern. Discuss how they need Applications’ help to reach that goal.

■■ Make Use of History: use concrete examples of past situations or projects where similar risks have caused project failure.

Driver: Entrepreneurs underappreciate the risks associated with self-management or overestimate the impact on returns.




133


Engaging the Cowboys

DERF 11-3914



The Cowboys

Sensitivity to Returns“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.”

Toughest Scenario: Reigning in Risk

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

Teach Tailor Assert Control■■ Correct the Past: Acknowledge any past failures, if they exist, and explain what steps have been taken to improve.

■■ Diminish Speed Expectations: Tie risks and complexities of a “go it alone” approach to schedule and speed-to-market impacts.

■■ Infiltrate the Team: Find a key lieutenant and win him or her over to help make your case.

■■ govern: If all else fails, govern by going to a higher authority and explaining what is at risk.

Driver: Cowboys distrust Applications’ ability to meet their needs.




134


DERF 11-3914



The AbdicatorsYou probably are dealing with an Abdicator if…

■■ They strongly defer to you as the experts and expect you to supply all the initiative and answers.

Toughest Scenario■■ It is difficult to engage them on a traditionally run project.

DO■■ Use their time efficiently.■■ Tie their effort to high-risk avoidance.■■ Tap into their concerns about regulatory compliance.

BEWARE OF■■ Confusing them with the Opportunists; they are not very motivated by returns

and cannot be persuaded to self-manage.

The CowboysYou probably are dealing with a Cowboy if…

■■ You do not know what they are doing. They talk evasively/vaguely about their initiatives.

Toughest Scenario■■ They are putting the enterprise at risk and simply will not listen.

DO■■ Find their key lieutenant and win him or her over. Try to win over the Cowboy’s

team.■■ If all else fails, govern. Go to a higher authority and explain what is at risk.

BEWARE OF■■ Confusing them with the Entrepreneur; their eagerness is fueled by a desire

to control, and they will not listen to Applications.

The OpportunistsYou probably are dealing with an Opportunist if…

■■ They emphasize how smoothly past successes went and show pride in meeting expectations.

Toughest Scenario■■ They are scared of risks when Applications does not have resources to pursue

their opportunity.

DO■■ Address their specific fears, offering concrete steps you or they can take.■■ Understand exactly what they expect from the solution.■■ Address how self-management raises the odds of achieving specific objectives.

BEWARE OF■■ Confusing them with the Abdicators; their reluctance comes from concerns about

risk, not unwillingness to self-manage.

The EntrepreneursYou probably are dealing with an Entrepreneur if…

■■ They measure past success mostly by the size of the outcome.

Toughest Scenario■■ They gamble with enterprise risks to chase high returns.

DO■■ Amplify their perception of risks they have expressed concern about.■■ Introduce new strategic risks to them, e.g., loss of customer information, direct

financial loss, and brand impact.■■ Connect risks concretely to not achieving the business case.

BEWARE OF■■ Confusing them with the Cowboys; Entrepreneurs actually can be reasoned with

and persuaded.




135

UNDERSTAND BUSINESS SPONSORS’ TEMPERAMENTS

Business Leader Discussion guide

DERF 11-2546



Decision Factors Framing Language Discovery Questions What to Listen For

Success Measures

“I typically ask people four things to make sure we use our resources in the way they’ll most benefit from. one is to understand the background and experiences they’re bringing to the table. It’s likely a lot.”

■■ What is the greatest success so far in your career?■■ How did that project come about for you?■■ Why was it important to the company?■■ What was the benefit to you?■■ Was there a point during the project when the risks started to seem high to you?

You are trying to understand how they measure success and what motivates them to get involved. There is an opportunity here to get them to talk about how they’ve viewed or handled trade-offs in the past, in a subject area that is comfortable for them.

Control

“Second, I need to understand your thinking about how you’d like to finish the project from here, and how you’d prefer to be working with us and with your vendors.”

■■ Where are you in the project lifecycle? ■■ In your ideal scenario, how much support would you

like from us on this?■■ Do you feel prepared for conversations with IT vendors?■■ What worries you about them? ■■ I have to check on our resources to support you right now. Would you be willing to delay this project to wait for resources to come free? (If so, for how long?)

You are seeing how impatient or passive they are, how much they worry about things they don’t know, and what their first instinct is about ceding control.

Benefits

“Third, I need to understand what your vision is for this project to help me adopt your views of the benefits and work with you to get to the outcomes you envision.”

■■ Why is this something you’ve identified as a priority? ■■ Whose idea was this and why are you working on it?■■ What does the company (or your group) expect to get out of the project?

■■ What do you hope to get out of the project?

You are looking for the amount of thought they’ve put into understanding potential benefits the degree of excitement they have about the benefits, and how attached they are to a vision for what the solution and outcome should be.

Risk

“Fourth, I need to understand in your own words what your perceptions of the risks here are. I want to know how we can best complement your skills and experiences here.”

■■ Have you done something like this before? ■■ What risks are most worrying you?■■ What’s at stake for you on this project?■■ What’s the impact on the project if one of the risks you worry about comes to pass?

■■ Do you like to figure things out as you go along or plan up front?

You are trying not only to gauge what risks they perceive, but how they perceive the magnitude of risk and how they weigh the risks against potential benefits personally and for the company.




136

HELP SPONSORS SEE RISK AND VALUE TRADE-OFFS

CareFusion’s Clarifying Risk and Value Trade-OffsIllustrative

Low

Low

High

HighHigh

High

4. Effort■■ IT and business full-time equivalent required for implementation and maintenance

■■ Business subject matter expert time commitment

■■ Estimated amount of customization

■■ Estimated amount of integration

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

1. Strategic Risk to the Company■■ Loss of sensitive company information■■ Brand or reputation damage■■ Direct financial loss

2. Business Outcome Attainment Risk■■ Likelihood that key functionality is missing or fails to work as intended

■■ Sensitivity to schedule delays■■ Sensitivity to budget overruns■■ Risk to productivity or revenue improvements

Constraints of a Sample Solution

DERF 11-3913


Title MC: Fusion Corporation




137

TRACK CHANgINg BUSINESS PRIORITIES

CareFusion’s Business Trends Insight MapIllustrative

DERF 11-3913


Title MC: Fusion Corporation

Customer Data

Management

Supply Chain Management

Customer Data

Management

Customer Data

Management

Customer Data

Management

Contract Management

Strategic Sourcing Strategic

Sourcing

Strategic Sourcing

Strategic Sourcing

Customer Data

Management


Customer Data

Management

Customer Data

Management

Customer Data

Management

Contract Management


Sourcing

Strategic Sourcing

Strategic Sourcing

Research and Development

Sales and Marketing

Medical Devices

Finance

Customer Data

Management


Customer Data

Management

Customer Data

Management

Customer Data

Management

Contract Management


Sourcing

Strategic Sourcing

Strategic Sourcing


Sales and Marketing

Medical Devices

Finance

Potential Actions for Applications Potential Actions for Applications Potential Actions for Applications

1. Surge in a Capability’s Importance 2. Major Changes Within a Business Unit 3. Experimentation with a given Capability

■■ Consider an enterprise project.

■■ Assess the business case for standardization.

■■ Revise skills forecasts.

■■ Revise SLAs for the business unit.

■■ Revisit investment levels.

■■ Reassign staff to project and re-scope job descriptions.

■■ Investigate if there is an unarticulated need not addressed by existing solutions.

■■ understand business drivers of experimentation.


Sales and Marketing

Medical Devices

Finance

Experimentation with a business capability indicates its importance is rising.

Experimentation with a business capability indicates its importance is diminishing.

The direction of importance of experimentation with a business capability is uncertain.

Legend




138BUSINESS RELATIONSHIP

MANAGEMENT



139

Section 9: Design Team Relationship Management

DESIGN TEAM RELATIONSHIP MANAGEMENT



140

DESIgN TEAM RELATIONSHIP MANAgEMENT

Drive Team Collaboration and Engagement

Periodically assess the key behaviors and perceptions that drive virtual and Agile team effectiveness to continually improve team performance.

volvo’s virtual Team Effectiveness Assessment • 141Rather 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 • 142S&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


Intergraph’s Agile Cultural Change Management • 143Intergraph uses the pulse survey to understand each team’s reaction to the new methodology.

When to Use■■ To understand teams’ perception of change









141

Strongly Disagree

1

Somewhat Agree

3

Strongly Agree

5

DRIVE TEAM COLLABORATION AND ENgAgEMENT

Volvo’s Virtual Team Effectiveness Assessment

goals: How Aligned Is This Team’s Understanding of goals, Actions, and Expected Results?

Cooperative goals ■■ Everyone has the same picture of overall purpose.■■ Team discusses, agrees, and reviews clear, simple goals.

Interdependent Tasks ■■ Everyone follows the same process for doing similar work.■■ Team looks for ways to interconnect and improve work processes.

Concrete Results ■■ Everyone understands the deliverables.■■ Team develops and reviews measures and milestones for deliverables.

Links: How Comfortable Is the Team with Communicating Internally?

Multiple Media ■■ A variety of media is available and accessible.■■ Team uses collaboration tools consistently and creatively.

Boundary-Crossing Interactions

■■ Team has collaboratively established operating agreements that are actively applied.■■ Team actively implements strategy for engagement across organization boundaries.

Trusting Relationships ■■ Team has high level of trust.■■ Team members build “social capital” through multiple connections.

Time: How Clear Are Project Timelines and Milestones?

Common Calendar ■■ Team has clear milestones and schedules of dates.■■ 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.

Teams fall into one of four maturity levels based on their score:

– Chaos(1–32)—No shared understanding of objectives or contributions of individual team members

– Operational Consensus (33–54)—Focused on methods of work and timelines

– Team Alignment (55–87)—Development of team relationships to overcome organizational boundaries

– Shared Accountability (88–120)—Shared leadership for achieving team objectives

DERF 10-5038






142

DRIVE TEAM COLLABORATION AND ENgAgEMENT (CONTINUED)

Standard & Poor’s Common Delivery Framework for Agile Development

Synchronization PlanningSynchronization Interface Specification

gOVERNANCESteering and Reporting

MANAgEMENTPlanning and Evaluation

ENgINEERINgDefine, Build, and Test

OPPORTUNITY(Assessment)

What is the business problem or opportunity?

objective■■ Get a project

funded.■■ Get a project

scheduled.

L H

■■ Business Sponsor■■ Project Proposer/Champion■■ Tech Management■■ Business Project Manager

■■ opportunity Phase Summary Meeting

■■ Rapid Response Team■■ Project Proposal■■ Funding Memo■■ Project Plan—Level 0■■ opportunity Phase

Summary/Sign-off

■■ Project Proposer■■ Business Analyst■■ Subject Matter Expert

■■ Business Problem and Needs Analysis

■■ Perform High-Level Risk Analysis

■■ Scope Analysis■■ Project Planning■■ Begin RFP Process

■■ Vision—Initial■■ Scope—High Level, Initial■■ Project Proposal■■ Risk Profile—Initial■■ Request for Proposal (RFP)

■■ Architects—Enterprise, Application, Data, Data Services

■■ High-Level Technical Feasibility Analysis

■■ Level 0 Estimate (+/-200%)

■■ Vision—Initial■■ Project Proposal

Timebox

Specifies expectations for governance and management: people, process, and documentation

Ensures the business context will be captured and cascaded to all team members

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

2

3

1

Synchronization Sprint

Defines the documentation options the team should be considering at each phase

4

DERF 10-5038






143

Intergraph’s Agile Cultural Change ManagementAgile Adoption Pulse Survey

DRIVE TEAM COLLABORATION AND ENgAgEMENT (CONTINUED)

Much Better

Better Same WorseMuch 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 Positive

Positive Neutral NegativeStrongly 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

DERF 10-5038






144


business analyst handbook.pdf

Documents

professional services

key business analysis

requirements management

professional advice

appropriate professional

copyrighted materials

prior approval

change leadership105section