Business Analyst Handbook.pdf

INFORMATION TECHNOLOGY PRACTICE

APPLICATIONS EXECUTIVE COUNCIL®

Business Analyst’s Handbook Templates for Key Business Analysis Activities

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

Information Technology Practice

www.executiveboard.com

|

Applications Executive Council®

Content Publishing Solutions

Executive Directors Shvetank Shah Warren Thune

Consultants John Hillery Andrea Moreland

Production Designers Todd Burnett Carolyn Lamond

Managing Directors Jaime Capella David Kingston

Senior Analyst Pallavi Goel

Contributing Designers Supriya Dhasmana Mike Jurka

Practice Manager Mark Tonsetic

Editor Nidhi Vikram Choudhury

Senior Directors Miles Gibson Bill Lee Alex Stille Directors Aron Kuehnemann Tim Macintyre Kristin Sherwood Associate Directors Christiane Groth Karolina Laskowska Alicia Mullery Candice Kenney Weck

Copies and Copyright

Legal Caveat

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

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

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

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

TABLE OF CONTENTS Overview of the Business Analyst's Handbook • iv Business Analyst Competency Model: Needs Discovery • vi Business Analyst Competency Model: Technology Management • vii Business Analyst Competency Model: Relationship Management and Communication • viii Section 1: Requirements Elicitation • 1 Section 2: Requirements Management and Analysis • 15 Section 3: Creating Compelling Business Cases • 33 Section 4: Providing Accurate Project Effort Estimates • 47 Section 5: Architecture Management • 77 Section 6: Designing for Usability • 93 Section 7: Communications and Change Leadership • 105 Section 8: Business Relationship Management • 125 Section 9: Design Team Relationship Management • 139


iv

OVERVIEW OF THE BUSINESS ANALYST’S HANDBOOK Five New Imperatives for Business Analysts

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

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

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

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

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

Applications Executive Council® IT PRACTICE www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

OVERVIEW OF THE BUSINESS ANALYST’S HANDBOOK (CONTINUED) How to Use This Handbook This handbook is organized into nine sections that correspond to the nine areas of the Council’s Business Analyst (BA) Competency Model. Each section provides an overview of the available resources and templates, and guidance on when to apply each. We have also included guidance on each resource’s applicability to the scope of a BA’s responsibilities.

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

■■

Essential

1

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

2

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

Reference

3

Specialized

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

Essential: Template or resource is applicable to core BA activities (e.g., requirements elicitation). Reference: Template or resource may be outside BAs’ direct scope of responsibility but where a BA is often an important contributor (e.g., portfolio requirements management). Specialized: Template or resource is outside BAs’ normal scope of responsibility but directly applicable in specialized role (e.g., services). Project Methodology: Recognizing that the 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. Applications Executive Council® IT PRACTICE www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

v

BUSINESS ANALYST Competency Model: Needs Discovery Section 1: Requirements Elicitation—Ability to identify a desired future state that addresses a business problem Level 1: Foundational

Level 2: Practitioner

Level 3: Leader

■■

Precisely and consistently captures business problems and nonfunctional requirements

■■

Can identify and document emerging business requirements

■■

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

■■

Prioritizes problems to surface the most critical needs

■■

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

■■

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

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


Level 3: Leader

■■

Properly prioritizes competing business demands

■■

Properly prioritizes business line and enterprise demands

■■

Understands business process complexity

■■

Can elicit high-level business requirements

■■

■■

■■

Assesses the risks of various solution options to different options

Accurately translates business requirements into functionality

Influences business partner requirements in support of enterprise objectives

■■

Manages requirements to meet performance expectations

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

Can articulate the business impact of business problems

■■

Understands the organization’s economic and revenue drivers

Level 2: Practitioner ■■

Understands industry-specific trends that impact the organization

■■

Clearly articulates benefits in business language

■■

Accurately measures the contribution of IT projects to business value

Level 3: Leader ■■

Quickly adapts to changes in business strategy

■■

Helps business partners communicate solution value to key stakeholders

Section 4: Providing Accurate Project Effort Estimates—Ability to quantify project resource requirements Level 1: Foundational ■■

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

vi

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

■■

Understands technology standards and architecture guidelines Obtains key input from enterprise architecture groups to ensure architecture compliance and exception management


Level 3: Leader

■■

Identifies solution interdependencies

■■

Stays abreast and creates awareness of technology developments related to a business problem

■■

Can identify commonalities and suggests a consistent approach across projects in the absence of standards

■■

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

■■

Can identify opportunities for creating reusable enterprise services

■■

Can guide and manages interactions with technology vendors

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

■■


Level 3: Leader

Incorporates usability and user interface techniques when designing systems

■■

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

■■

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

Understands knowledge workers’ information needs as they relate to a potential solution

■■

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

■■

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


vii

BUSINESS ANALYST Competency Model: Relationship Management and Communication Section 7: Communications and Change Leadership—Ability to communicate effectively across multiple constituencies to support project and organizational change objectives Level 1: Foundational


Presents ideas in a concise, focused manner

■■

Can guide team decision making

Can work as part of a larger team

■■

Provides business partners with an accurate view of challenges to end-user buy-in

■■ ■■ ■■

Surfaces potential impacts of the solution on all stakeholders


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

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


Level 3: Leader

Sets realistic customer expectations for project delivery (e.g, schedule, budget, outcome)

■■

Adjusts customer expectations in accordance with changes in scope

■■

Can influence business partner decision making to optimize requirements prioritization

■■

Clearly articulates the role of technology in terms easily understood by business constituencies

■■

Can effectively navigate conflict between multiple business partners

■■

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

■■

Proactively resolves customer satisfaction issues

■■

Tailors business partner engagement to business sponsor risk and value preferences

■■

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

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

viii

Section 1: Requirements Elicitation

Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

Requirements Elicitation

1


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 • 4 By including business stakeholders from the earliest stages of requirements planning, Hallmark facilitates a shared sense of ownership and maximizes the likelihood that requirements will meet customer needs. The requirements elicitation process is broken into five distinct phases. Each phase defines a clear delineation between tasks for the business team versus the IT team. When to Use To establish ownership and shared responsibility with business partners for each stage of requirements elicitation ■■ To validate high-level functional requirements for new systems development/legacy systems ■■

Essential

Reference

Specialized

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


Reference

Specialized

IBM’s User-Initiated Requirements Specification • 8 To improve the requirements elicitation process, IBM boosts the usability of user-provided information by supplying business users a standardized elicitation template focused on the key attributes of the end product. When to Use To capture functional and nonfunctional requirements ■■ To identify the most stable requirement ■■

Essential

Reference

Specialized

Evaluate Requirements Continually verify requirements individually and collectively against a standard set of well-known criteria throughout the project lifecycle. Capital One’s Creating High-Quality Requirements • 10 Capital One rigorously validates every functional requirement against a checklist of eight necessary attributes that each must meet. To prevent scope creep, all approved requirements must be associated with a documented business need. After making sure that each individual requirement is of high quality, the entire set of requirements is assessed as a whole against an additional set of three attributes. These attributes relate to the thoroughness of the set, the interrelationships between requirements, and the ease with which the requirements set can be changed. When to Use To prevent scope creep of requirements ■■ To define attributes of high-quality requirements ■■

Essential

Reference

Specialized

REQUIREMENTS ELICITATION (continued) Elicit Unarticulated Needs Engage in direct observation of knowledge workers to uncover unarticulated needs and transformational innovation opportunities. LexisNexis’s Uncovering Unarticulated Needs • 13 LexisNexis focuses on uncovering unarticulated needs directly from knowledge workers. BAs engage directly with employees to understand pain points or roadblocks in employees’ workflow. When to Use To assess employees’ unrecognized needs or identify barriers in their workflow

■■

Essential

Reference

Specialized



3


4

Capture High-Level Requirements Hallmark’s Shared Business: Applications Requirements Elicitation Requirements Elicitation Process

Feasibility

Goal

Business-Side Tasks

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

■■

■■

■■

ApplicationsSide Tasks

■■

■■

■■

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


Solicitation

Analysis

Prioritization

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

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

Prioritize all requirements based on business criticality of the features.

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

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

Determine criticality of features.

Validation

Integrate requirements and validate scope in collaboration with business partners.

■■

■■

■■

■■

■■

Classify wish lists according to constraints (functional, nonfunctional, environmental, design, etc.). Determine interface needs for information that is shared between business areas.

■■

■■ ■■

Estimate the impact of requirements on cost and schedule. Perform risk assessment. Examine cost of potential solutions in light of architectural and strategic fit.

■■

■■

Prioritize requirements based on cost and dependency. Identify appropriate architectural models that work with current technology roadmap.

■■

Resolve as many open issues as possible. Verify that requirements are in agreement with originally stated goals. Obtain authorization to move to Application Design. Resolve conflicts and keep consistency in check.

Capture High-Level Requirements (CONTINUED) Hallmark’s Shared Business: Applications Requirements Elicitation (Continued) High-Level Requirements Questionnaire for New Development 1. Determine Business Objectives

4. Determine Current Problems

1. What are your goals in developing this system? 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?

1. What are the problems you face without the system today? 2. What problems should this system solve? 3. Do you have to do things manually that you would like to automate? 4. Do you have performance problems that need to change? 5. Do you have functional limitations that you would like to change? 6. Are you using packages that force you to constrain your business functionality to the boundaries of the package? 7. Which reports do you currently use? What data on the report are important? How do you use the information? 8. Are there specific bottlenecks to getting at information? 9. How do you analyze the information you currently receive? What type of data are used? How do you currently get the data? How often do you get new data? 10. What type of ad hoc analysis do you typically perform? Who requests ad hoc information? What do you do with the information?

2. Determine Future Needs 1. What business requirements will this system address? 2. What information do you need from this system that you 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?

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

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

6. Determine Assumptions and Open Issues 1. List assumptions. 2. List open issues, responsible parties, and resolution date.



5


6

Capture High-Level Requirements (CONTINUED) Hallmark’s Shared Business: Applications Requirements Elicitation (Continued) High-Level Requirements Questionnaire for Legacy Systems Development 1. Determine Business Objectives

2. Determine Future Needs

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

Same as for new system development

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


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

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

Capture High-Level Requirements (continued) Sabre Holdings’ Agnostic Needs Statement Questionnaire for Business and End Users: Mobile Requirements

Business Sponsor Questionnaire

Use Case 3: End User

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

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

2. Why 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 2: End User 1. Who are you as a potential user? What is your role? A business traveler Use Case 1: End User 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.



7


8

Capture High-Level Requirements (CONTINUED) IBM’s User-Initiated Requirements Specification Business Requirements Elicitation Worksheet

1

5

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

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

Functional Requirements

Unique ID

Requirement Statement Description

Success Conditions

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

Stability Level

BFR1

High (H)—Unlikely to change

BFR2

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

BFR3 …

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

BFRn

2

BNFR1

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

Nonfunctional Requirements

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

BNFR2 BNFR3 … BNFRn

3

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


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

4

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.

Capture High-Level Requirements (CONTINUED) IBM’s User-Initiated Requirements Specification (Continued) Business Requirements Specification, Illustrative

Business Requirements Specification I. Business Scope and Objectives

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

This section defines the starting reference for a project. This section should help with the following: ■■ Provide a high-level understanding of what the enterprise is and aspires to become. It is usually depicted by a brief description on how the organization intends to achieve its goals and make the desired transition and by what means. ■■ Document events that are the initial stimuli causing the client’s business to act. ■■ Describe and quantify the benefits, costs, schedules, and assumptions required to justify the implementation (if needed).

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

II. “As Is” Business Process Flows

a. Business Functional Requirements

This section should help with the following: ■■ Contain the graphic representation of the flow of work through a business process model, narratives that describe the flow, and key process attributes. ■■ Describe a high-level business use case model; this use case model uses graphical symbols and text (business lexicon) to specify how users in specific roles will use the system. ■■ Depict the usage and interaction between resources (e.g., hardware, software, and people). III. Business Requirements Business requirements differ from systems requirements. Business requirements can be identified by the following characteristics: ■■ They support a business scope and/or objective, usually reviewed by executives. ■■ They have a business purpose/focus. ■■ They state “what” needs to be accomplished using business language. ■■ They are nontechnical.

Business Functional Requirement Id

Requirement

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

Success Criteria and Associated Metrics

BFR1 BFR2 b. Business Nonfunctional Requirements Business Functional Requirement Id

Requirement

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

Success Criteria and Associated Metrics

BFR1 BFR2 IV. Assumptions, Issues, and Constraints



9


10

Evaluate Requirements Capital One’s Creating High-Quality Requirements Individual Requirements Evaluation Criteria

The following attributes should be applied to each requirement Term

Definition

Guidelines

1. Unambiguous

The requirement has only one possible interpretation.

Avoid natural language, such as user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize. Use a requirements document glossary to capture the meaning of important terms. Uncover ambiguity by formally inspecting the requirement, writing test cases from requirements, and creating user scenarios that show the probable behavior of a specific piece of the product.

2. Correct

The requirement accurately describes the functionality to be delivered.

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

Example “For up to eight results, the detailed display format shall be used. For the remainder, the compressed display format shall be used.” Ambiguity lies in the phrase “for up to eight results.” Does it mean “for up to and including eight” or “for up to and excluding eight”?

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

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

4. Achievable

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

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

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

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


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

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

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

Term

Definition

Guidelines

Example

5. No Design Impact

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

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

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

Nonfunctional requirements such as system constraints are an exception.

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.



11


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

Definition

Guidelines

Example

I. Complete

Requirements must account for all business needs related to the project.

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

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

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

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

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

The following requirements are not consistent with each other:

II. Consistent

No two requirements must be in conflict with each other.

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

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

“The search function shall return results in the order of their relevance to the searched term.” “The search function shall display the most recently created documents first.”

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

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

Organize all requirements such that related requirements are grouped together.

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

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

The redundant steps in these two requirements increase readability but decrease the modifiability. A single change of step may impact multiple requirements due to the redundancy of steps.


Elicit Unarticulated Needs LexisNexis’s Uncovering Unarticulated Needs The Customer Advocate Profile

1. Experience ■■

Recent experience with the workflow performed by the knowledge worker— Was recently employed in the role or participated in the business process performed by the role

2. Scientific Disposition ■■

Intellectual curiosity—Exhibits a passion for learning

■■

Observational skills—Can identify patterns in large data and information sets

■■

Problem solving—Is driven to understand the core of an issue

3. Journalistic Aptitude ■■

Interviewing skills—Is able to facilitate and guide discussions with others

■■

Interpersonal skills—Thrives in interactions with others

■■

Recognized as a Challenger® of the status quo—Is able to intelligently question knowledge worker preferences to identify unique value drivers associated with the objectives of the role, in a nonaggressive yet an assertive, authoritative way

Customer Advocate Objectives

■■

■■

Engage with knowledge workers in their normal day-today environment. Uncover and document existing pain points and needs that knowledge workers would not be able to articulate on their own.

Good but Insufficient Indicators of Success for a Customer Advocate ■■

Experience in identifying and evaluating new technologies

■■

Experience in gathering and defining business requirements

■■

Survey and data analysis skills

■■

User-experience skills



13


14

Elicit Unarticulated Needs (CONTINUED) LexisNexis’s Uncovering Unarticulated Needs (Continued) Interview Guide Objectives 1. Collect background information on the knowledge worker. 2. Understand a day in the life of the knowledge worker. 3. Observe the knowledge worker in his or her natural work environment. I. Background

II. Day in the Life

1. Job Position/Title

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

2. Business Unit ■■ Name of business unit ■■ 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?

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. How is success typically measured in your job? How do you tie that success back to the work you did?

10. What resources do you wish you could have?

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

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

12. When you look back at this job 5 or 10 years from now, how will you decide if you were successful at it? Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

Section 2: Requirements Management and Analysis


Requirements Management and Analysis

15


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 • 18 Sabre 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 Essential

Reference

Specialized

Discover’s Sample Requirements Tracking Document • 19 Discover’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 ■■

Essential

Reference

Specialized

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

Pseudonym.


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

Essential

Reference

Specialized

BCBS-MA’s Pairwise Feature Prioritization • 21 For functionally complex projects, BCBS-MA makes pairwise comparisons among features to enable the business sponsor effectively prioritize requests for functionality. When to Use To compare and rank order business preferences ■■ To compare and prioritize features ■■

Essential

Reference

Specialized

Fenton, Inc.’s1 Functionality ROI Maximization • 22 Fenton, 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 Essential

Reference

Specialized

REQUIREMENTS MANAGEMENT AND ANALYSIS (continued) Manage Requirements Across Business Process Change

Improve Portfolio-Level Requirements Visibility

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

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

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

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

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

Essential

Reference

Specialized

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

Drake Corporation’s1 Voice of the Customer Tool • 26 Drake Corporation uses a Voice of the Customer planning worksheet to understand user acceptance issues early and adapt requirements management accordingly. When to Use ■■ To assess key stakeholder attitudes ■■ To plan engagement with stakeholders Essential

1

Reference

Essential

Reference

Specialized

Specialized

Pseudonym.



17


18

Prioritize and Track Requirements Sabre Holding’s Feature Needs-Testing for Mobile Apps Illustrative, Corporate Booking Apps Candidate Features ■■ Obtains Travel Agency Contact Information ■■ Updates Traveler Profile Information

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

■■

■■

Shops and Books for Corporate Approved Hotel Rooms Displays Corporate-Specific Messaging

■■

Holds a Trip for Future Booking

Needs Test 1: Business Need Discard Features

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

Needs Test 2: End-User Workflow Need Discard Features

Usability Criteria Could use of this feature be severely impacted by any of the following? ■■ Noise/distractions ■■ Poor lighting ■■ Time pressure ■■ Slow link control protocol connectivity ■■ Complex visuals ■■ Specific mobile device (e.g., phone versus tablet) Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

Updates Traveler Profile Information

Displays Corporate-Specific Messaging Obtains Travel Agency Contact Information

Usability Criteria

Discard Features

Shops and Books for Corporate Approved Hotel Rooms

Holds a Trip for Future Booking

Prioritize and Track Requirements (CONTINUED) Discover’s Sample Requirements Tracking Document 1

4

Document requirements captured prior to the war room.

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

Requirements Tracking Document Project Name: Excelsior

Business Sponsor: Jim C

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

Project Manager: John G

Req. ID

Description

Requirement Adjustment Notes

Design Test Document Case ID

Changes Implemented

RS0001

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

Select multiple items from the list.

DD0001

Design

TC0001

UAT Done

Development Test Cases

RS0002

RS0003

2

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

Also group the products by their market.

DD0005

TC0003

Design

TC0004

Development

TC0005

Test Cases

--------------------------------

-----------------

-----------

---------

-----------------

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

-----------------

-----------

---------

-----------------

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

3

Traceability ensures that changes are implemented in all affected areas.



19


20

Prioritize and Track Requirements (CONTINUED) Paccar’s Business Objectives–Driven Functionality Prioritization Prioritizing the Impact of Applications Functionality on Fulfilling Business Objectives, Illustrative

1

6

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

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

Strong Impact = 9 Points Medium Impact = 3 Points Low Impact = 1 Point

Business Objectives Reduce Costs

2

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

Business Priority Rank

Functional Capabilities

3

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

H

M

M

H

H

L

Impact Score

Change Order Event Notification

6.6

Automate Material Requirements Ordering

4.9

Add Search Capability

5.2

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


4

Assessment of impact of functionality on the business objective

5

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.

Prioritize and Track Requirements (CONTINUED) BCBS-MA’s Pairwise Feature Prioritization Pairwise Comparison of Features A. Change Address

1

1 A

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

2

B A A

B. Change Name 2 B

C

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

A

C B

C

D D A A

D D B B

Functionality Ranking

No. of Times Circled

Business Staff

4 D. Change Status D D D

C

E

Feature

C. Reinstate

E E

E

E

E. Transfer

A

B

C

D

E

3

2

0

4

1

3

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

Complexity Ranking Applications Staff

Prioritized Feature List Project Sponsor

Business Project Manager Which feature is more important to you: ■■

Change Address or Change Name?

■■

Change Name or Reinstate?

Rank Value-Based Prioritization

Business Liaison

Cost-Based Prioritization

Which feature is more complex to create:

1

D Change Status

E Transfer

■■

2

A Change Address

C Reinstate

Change Address or Change Name?

■■

3

B Change Name

D Change Status

Change Name or Reinstate?

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.



21


22

Prioritize and Track Requirements (CONTINUED)

1

Fenton, Inc.’s Functionality ROI Maximization

Strong Impact = 9 Points

Computer Telephony Integration Project, Illustrative

Medium Impact = 5 Points Low Impact = 1 Point

1

2

Vertical views indicate potential feature gaps and redundancies.

High-Level Requirements

Need for Associates to Talk with Previously Inaccessible Customer Segments

Need to Provide Associates with Critical Customer Relationship Information

1

3

Business Value Components

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

Efficiency Goals

Value Weight

Effectiveness Goals

a

b

c

d

e

f

g

Increased Use of Call Automation

Timely Handling of Call

Efficient Call Transfer to Sales

Reduced Calls to Help Desk

Reduced Call Escalation

Increased Customer Retention

Intelligent Call Routing

$500 K

$275 K

$25 K

$100 K

$200 K

$1 M

$5 M

2

2

1

2

2

3

3

Scores can be aggregated to prioritize requirements.

Feature Score (Sum of Weight x Impact)

System Features System shall identify which customers to be harvested.

67

System shall have the flexibility to easily change harvesting instructions.

63

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

43

System shall only harvest the best customer segments.

51

System shall display customer and call information to associate.

71

System shall display key customer data to associate.

83

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

23

Pseudonym.


Manage Requirements Across Business Process Change Swiss Re’s Methodology Decision Map Customer Request Decision Tree Yes

Small (< $250 K)

Is this a one-time improvement? No

Improving Existing

What is the size of the change?

Significant ($250 K–$2 M)

Changes a Leverage Point Within the Existing Paradigm

Order of Magnitude (> $ 2 M)

Improving Existing

What are you doing to the process? Replacing Existing

Continuous Process Improvement

Business Process Improvement

What are you doing to the process? Replacing Existing

Information Systems Planning

What is the impact? Changes the Business Paradigm Yes

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

No

Business Process Improvement Radical Process Improvement Radical Process Improvement Business Process Improvement Radical Process Improvement



23


24

Manage Requirements Across Business Process Change (CONTINUED) Swiss Re’s Methodology Decision Map (Continued) Approach Descriptions Information Systems Planning ■■

■■

Improving the automation of, or information support to, an existing process Restructuring information systems for technical efficiency, functional flexibility, and maintainability

■■

Moving automated support from one platform to another

■■

Improving the integration among information systems

Continuous Process Improvement ■■

■■

■■

■■

Business Process Improvement ■■

■■

■■

■■

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


Installing a quality-oriented culture and set of procedures to encourage and exploit improvement ideas from workers Applying left-to-right thinking to evaluate how the parts of the process contribute to the required outputs and performance Achieving a series of improvements of smaller magnitude in such areas as cost, time, and quality that, over the course of time and the scope of the entire process, amount to significant improvement

Radical Process Improvement ■■

■■

■■ ■■

■■

Applications Executive Council® IT Practice www.aec.executiveboard.com

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

Replacing an existing process with a completely new or a substantially redesigned one, generally accompanied and enabled by radical changes 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

Manage Requirements Across Business Process Change (CONTINUED) Swiss Re’s Methodology Decision Map (Continued) Requirements Process, Three Stages Architectural Analysis Architecture Planning

Architecture Design

Business Process Analysis and Design Architecture Review

Initiate Analysis

Deliverables ■■ ■■ ■■ ■■

Gather Process Requirements

Model Process Design

Review Process Design

Business Solution Analysis and Design Approve Process Design

Deliverables

Application Landscape Business Information Model Context Diagram Draft Application Context Diagram

■■ ■■ ■■ ■■ ■■ ■■

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

Initiate Analysis

■■ ■■ ■■ ■■ ■■ ■■

■■ ■■

Typical Activities

■■

■■

■■

■■

Discuss project with local architecture team, obtain any business 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.

■■ ■■ ■■ ■■ ■■

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

Model Process Design

Review Process Design

Approve Process Design

Deliverables

■■

Typical Activities

Gather Process Requirements

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

Typical Activities ■■ ■■ ■■ ■■ ■■

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



25


26

Manage Requirements Across Business Process Change (CONTINUED)

1

DRAKE

corporation

Drake Corporation’s Voice of the Customer Tool Stakeholder Group Analysis

Challenge

Opportunities

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

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

Probabilities of Success (PoS)

Possible Strategies to Improve PoS

Concern they are gaining more work, not less

Believe the opportunity.

Supportive

Strongly Supportive

90%

■■

■■

Rewarded for developing, not replicating applications

■■

■■ ■■

Not as attractive as new productivity launch Not tech savvy Don’t see tech service as a partner

Not on their dashboards

■■

■■

Lab heads asked for this.

Supportive

Strongly Supportive

70%

It’s their vision.

■■

■■

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

Neutral

This is a low-risk way to reach growth targets.

Neutral

Supportive

40%

■■

■■

Supportive

60%

■■

■■

1

Pseudonym.


Engage innovators and early adopters. Leadership set priorities for all of their work, let some drop. OU—Set TS growth objectives. US—Engage tech directors. Develop new incentives. Seek help from marketer to develop.

Group metrics on the acceleration dashboard. Promote the value to the executive conference.

Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY CIGNA’s Portfolio-Level Requirements Management Group Project According to Shared Impact on Business

1

2

3

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

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

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

Business Priority

Business Process Implications

Business Process Synergy

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

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

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

1. ERP Finance Upgrade 2. Customer Information Database 3. HIPAA Rights Repository

Customer Service

2. Customer Information Database 3. HIPAA Rights Repository 7. Benefits Management Portal

Flight One

5. Receipt Management System 6. Bill Processing System 9. E-Billing Presentation

4. Claim Submission System 5. Receipt Management System 6. Bill Processing System

Claims Processing

7. Benefits Management Portal

5. Receipt Management System 4. Claim Submission System 6. Bill Processing System

1. ERP Finance Upgrade Flight Two

8. Medicaid Reporting Repository 9. E-Billing Presentation

General Accounting

3. HIPAA Rights Repository 8. Medicaid Reporting Repository

1. ERP Finance Upgrade 8. Medicaid Reporting Repository 9. E-Billing Presentation

Flight Three

7. Benefits Management Portal 2. Customer Information Database 4. Claim Submission System

For smaller, less-strategic projects, CIGNA creates alternative paths to expedite requirements gathering. Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN


27


28

Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED) CIGNA’s Portfolio-Level Requirements Management (Continued) Alternate Path for Requirements Delivery Qualifying Criteria Approved and funded enterprise projects that meet the following criteria will qualify for the alternate path for requirements development: Goal is to improve process performance, operating efficiency, and/or cost of a current business process. Minimal changes to current business process are anticipated. The change has already been identified and defined by the business area. Process impacts are limited to 1 to 2 domains, and target specific business functions in either or both of those domains.

Nonqualifying Criteria Enterprise projects that would not qualify for the alternate path would meet the following criteria: New technology is anticipated for solution (feeds, data exchanges, etc.). New business process and/or major reengineered business process is anticipated. New operations workforce/functions is anticipated to support solution.

PPR Staffing Assumptions Functional BA resources within Project Process Requirements (PPR) will be assigned to these initiatives. Functional BA resources will use current “is” process map as basis for identifying specific process-impacted areas to be worked and will define use cases to outline requirements for this portion of the process map. Functional BA will be responsible for integrating the use cases created for these projects back into the process map, so these detailed changes are not “lost” amid the larger flight plan work; process modeler (PM) will work with functional BAs to ensure accurate integration of changes. Work effort for initiatives on alternate path may need to be revisited if during working these items, the changes are found to have a greater impact on the targeted business process(es) than originally expected. To support these projects, BA resources will work these initiatives directly—with expertise spanning appropriate domains.

Proposed Timeline Timeline for initiatives being addressed in alternate path will run parallel to the PPR flight schedules; specific milestones for each initiative will be negotiated with the PM and domain lead to confirm schedule for requirements delivery for smaller initiatives following the alternate path. Use case deliverables will be the artifact to be delivered by PPR resources. Requirements Traceability Matrix deliverable will be established also by the functional BA(s) working the project, as a means to capture initial project information that summarizes the needs for the process modification as well as to establish traceable documentation for the change as it moves into design, development, and testing. Business SME validation will be conducted by the functional BA (informal basis) to confirm detailed changes are accurate and meet the project objectives.


Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED) CIGNA’s Portfolio-Level Requirements Management (Continued) Project Impact Assessment on “Should” Business Processes

1

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

H

High Impact

M

Medium Impact

L

Low Impact

Customer Service Claim Correspondence Accounting

Claim Adjudication

Payment

Check Fund Paper Claim Electronic ClaimClaim AdjudicationNon-Medical Claim Correspondence Payment Claims Processing Claim Pricing Medical Claims Generation Transfers Claims Receipt Process Receipt Process Check Fund Paper Claim Electronic ClaimClaim AdjudicationNon-Medical Claim Correspondence Payment Claim Pricing Medical Claims Generation Transfers Claims Receipt Process Receipt Process M H M Check Fund Non-Medical Paper Claim Electronic Claim Claim Pricing Medical Claims Generation TransfersM Claims Receipt Process Receipt Process MH H MM M

E-Presentation Portal E-Presentation Portal System “Flight” Projects Receipt Management E-Presentation Portal System Receipt Management Customer Information Database

MH

M M

Receipt Management System Customer Information Database Provider Management System

H

Customer Information Database Provider Management System Member Web Site Redesign

M

M

HL

MH

HL

MH

L

ML

L M

H L

LL

ML L

MH

L

Provider System Member Web SiteRights Redesign HIPAAManagement Member Repository Member Website Redesign HIPAA Member RightsSystem Repository Medicaid Reporting

H

HIPAA Member RightsSystem Repository Medicaid Reporting

LL

LL

MH

Medicaid Reporting System

L

L

H

2

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

H

MM L

M

M M

L L

3 M

L

M

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

M 4

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



29


30

Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED) CIGNA’s Portfolio-Level Requirements Management (Continued) Requirements Clarification: Roles, Responsibilities, and Escalation Process

1 “As Is” Process Modeling Owner Process Modelers 15% of Requirements Group Responsibility Model “as is” business processes to denote the flow of information and cross-connections among process segments at all levels.

2 “Should” Process/High-Level Requirements Owner Senior Business Analysts 35% of Requirements Group

Key Deliverables

Responsibility

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

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

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


Owner Functional Business Analysts 50% of Requirements Group

Key Deliverables

Responsibility

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

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

A If a new requirement interdependency is uncovered during the “detailed” phase, functional business analysts work with senior business analysts to update IS/SHOULD Process Change Summaries.

Applications Executive Council® IT Practice www.aec.executiveboard.com

3 Detailed Requirements

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

Improve PORTFOLIO-LEVEL REQUIREMENTS VISIBILITY (CONTINUED) CIGNA’s Portfolio-Level Requirements Management (Continued) Project, Process, Requirements Team Responsibilities by Phase Project Initiation/ Awareness Meeting ■■

■■

■■

■■

■■

■■

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

Planning ■■

■■

■■

■■

Requirements

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

■■ ■■

■■

■■

■■

High-Level Requirements ■■

■■

■■ ■■

■■

■■

■■

Assist with issue resolution, provide clarification, and respond to questions. Support scope change management process and update documentation as needed

■■ ■■ ■■ ■■ ■■

■■ ■■ ■■ ■■ ■■ ■■

Testing ■■

Provide input to any phasing of solutions. Assist with issue resolution, provide clarification, and respond to questions. Update business requirements traceability document with assistance from System Analysis to ensure design traces back to requirements. Support design documents and walk through to verify design meets business requirements. Support scope change management process and update documentation as needed.

Detail Requirements

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

Construction ■■

Design

Provide test support for test scenario identification and defect resolution.

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

Implementation ■■ ■■

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

Warranty ■■

Provide support for clarifying questions, etc.



31



32

Section 3: Creating Compelling Business Cases


Creating Compelling Business Cases

33


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 • 35 Fenton 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 Essential

Reference

Specialized

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

■■

Essential

Pseudonym.


Specialized

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

Reference

Specialized

Citrix’s Business Case Summary • 46 Citrix 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

■■

Essential 1

Reference

Reference

Specialized

ARTICULATE AND QUANTIFY BUSINESS BENEFITS

1

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

Business Value Cascade

Key Challenges

Business Value Realization Steps

1

Business Case

Business Value Mapping

Monolithic business case

■■

Itemizing the benefits in the business case


2 Component 1

Component 2

Business value drivers are not connected to specific business activities.

High-Level Requirements Business Activity 1

Business Activity 2

Benefit-Driven Feature Prioritization

■■

Quantifying the value of application functionality

Business Activity 3

3 System Capabilities Application Functionality 1

1

Application Functionality 2



Business activities don’t tie to specific application functionality.

Portfolio ROI Dashboard

■■

Tracking project ROI trends at the portfolio level

Pseudonym.



35


36

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED)

1

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


Computer Telephony Integration Project

Component Quantification Template

Efficiency Goals

$7.1 M Cost Reduction

Revenue Increases

$1.1 M

Goal:

a. Increased use of call automation

$500 K

b. Timely handling of call

$275 K

c. Efficient transfer to sales

$25 K

d. Reduced calls to help desk

$100 K

e. Reduced call escalation

$200 K

Target:

74 seconds

Improvement:

11 seconds

Cost Savings:

$275 K

Calculation:

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

$5 M Total = $6 M

Computer Telephony Integration Workflow

c

Illustrative

Efficient transfer to sales = $25 K

f

No Customer opts for live person.

Customer is greeted by name.

One and done?

Yes

Increased customer retention = $1 M

Sales referral Help ticket opened Escalated call

a 1

Increased use of call automation = $500 K

Pseudonym.


b

Timely handling of call = $275 K

g

Intelligent call routing = $5 M

390 hours x $13.55 x 52 = $275 K

$1 M

b. Intelligent call routing

Start

85 seconds

Effectiveness Goals a. Increased customer retention

Customer calls automated system.

Baseline:

Total = $1.1 M

$6 M

Timely handling of call

d

Reduced calls to help desk = $100 K

e

Reduced call escalation = $200 K

Call complete

End


1

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

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

Discretionary Project Assessment Categories

Scoring Options

Scoring Guidelines

Quantifiable Business Objectives (QBOs) Evaluate the 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.

9

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

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

1

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

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

9

Customer Impact

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

Business Process Reengineering (Cost Reduction) Evaluate the project for opportunities to reduce operating costs through the enhancement of business process performance.

1

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

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.

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.

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.

Three most important criteria in determining whether intervention is required 1

Pseudonym.



37


38

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED) Fenton, Inc.’s Functionality ROI Maximization (Continued) 2. Connect Business Value to Business Process (Continued) Discretionary Project Assessment 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.

9

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

1

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

5

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

9

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

1

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

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.

Sponsor Interdependency Evaluate the project based on the level of sponsorship interdependency.

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

Total Score (Sum of Scores as a Percentage) Summary Provide an overall summary of the project and recommendations.

1

Pseudonym.


Threshold (45–63)

Intervention Required

(31–44)

Reevaluate

(7–30)

No Intervention Required

1


1

Fenton, Inc.’s Functionality ROI Maximization (Continued) 2. Connect Business Value to Business Process (Continued) Efficiency and Effectiveness of Business Process Performance

Business Process

Process Output

Quantifiable Business Objectives (QBO) Process Efficiency

Speed

A Measure of Net Business Value

QBO opportunity: Measure and decrease operating costs.

QBO opportunity: Measure and increase customer value.

Cost Reduction2

Revenue Attainment2

Consistent Procedures

Waste Rework/ Elimination Handoffs of Work Steps

Defect-Reduction Products/Services

Critical Attributes of Cost

1

Pseudonym.

2

Representative list.

Process Effectiveness

Customer-Valued Products/Services

Critical Attributes of Quality



39


ARTICULATE AND QUANTIFY BUSINESS BENEFITS (Continued) 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

■■ ■■ ■■

Need

■■ ■■ ■■ ■■

Features

■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■

1

Increase revenue, customer retention, employee engagement, and customer satisfaction and improve the customer experience. Utilize skill-based call routing and BSR together. Enable associates to talk to customer base previously untouched (do not call and self-service only). Need Need Need Need

for associates to talk with customer segments previously not accessible to associates for select customer groups to have their calls specially routed to provide the associates with critical customer information pertaining to the customer’s interaction and relationship to be able to effectively report on call routing and call harvesting

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

Pseudonym.


40 1

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (Continued)

1

Fenton, Inc.’s Functionality ROI Maximization (Continued) 4. Track ROI at the Portfolio Level A Heat Map Representation Clarifies the Distribution of Portfolio ROI Business Revenue Customer Value—Base

The size of the bubble depicts the project return.

Customer Value—Competitive Customer Value—Differentiated

High

Cost-Efficiency/Compliance

Key Advantages High-impact communication tool

■■

Portfolio pattern recognition

■■

ROI trend monitoring

Business Value

■■

Low Low

High Project Cost

1

Pseudonym.



41


42

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (Continued) Fenton, Inc.’s Functionality ROI Maximization (Continued) 4. Track ROI at the Portfolio Level (Continued) Business Value Categories Business Value Category

Definition

QBO Requirements

Customer Value—Differentiated

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

■■

VOC illustrates industry gap to meet order of magnitude customer needs.

■■

Ethnography to survey techniques

■■

Predictive market analytics

■■

VOC illustrates company’s gap to competitors to meet customer needs.

■■

Focus group to survey techniques

■■

Responsive market analytics

Customer Value—Competitive

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 N/A—Self-explanatory

Consolidation/Acquisition

Acquisition or divestiture activities

■■

Cost Reduction/Avoidance

Pure cost reduction or avoidance play with limited ongoing efficiency gains

■■

Elimination or avoidance of one-time costs

Defensive/Renewal

Renewal of applications/technologies/business processes to maintain capabilities with limited external customer value or internal efficiency gains

■■

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

■■

Baseline current state; demonstrate future state achievement to baseline

■■

Must support “X” number of future capabilities

■■

Measurable expectation of capability achievement

■■

Demonstrate scalability, cost effectiveness, supportability, etc.

Enterprise Capability

1

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

Provides broad underlying capabilities supporting multiple LOBs, projects, or future corporate/strategic initiatives

Operating Efficiency

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

■■

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

Regulatory/Compliance

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

■■

Demonstrate ability to maintain current operating efficiency.

■■

Demonstrate effectiveness of compliance solution.

■■

Demonstrate potential financial impact to corporation.

■■

Explain impact to internal or external customers.

Pseudonym.


1

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (Continued)

1

Fenton, Inc.’s Functionality ROI Maximization (Continued) 4. Track ROI at the Portfolio Level (Continued) Business Value Categories (Continued) Business Benefit Scorecard

1

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%

$375,191,092

100%

$47,321,200

$5.14

$1,883,559 100%

Pseudonym.



43


ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED) McDonald’s Business Case Abstract Illustrative Example Real Estate and Construction Cost Project

Real Estate and Construction Cost Project

Objective

Benefits

Provide timely and accurate real estate and construction capital expenditure 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.


■■ ■■

■■ ■■

■■ ■■

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

44


1

Omega Corporation’s Standard Business Case Criteria Standard IT Project Business Case Financial Analysis

Architecture Review

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

Opportunity Analysis ■■

■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■

Sourcing Review ■■ ■■ ■■ ■■

Project vendor selection process Opportunities to reuse existing contracts Offshore development opportunities Lease-versus-buy analysis

Operations Review ■■

■■ ■■

■■ ■■ ■■

1

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

Impact on existing infrastructure, software, and service contracts Ongoing maintenance requirements Savings and costs associated with decommissioning assets Contingency and recovery costs Security and privacy compliance Expected service quality

Pseudonym.



45


46

ARTICULATE AND QUANTIFY BUSINESS BENEFITS (CONTINUED) Cirtrix’s Business Case Summary Enterprise Strategic Goals

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

Business Objectives

IT Objectives

Value and Visibility

Controls

Align IT with Business

High-Level Project Business Case

Multiple Products

Cost Reduction

Support Shared Admin and Ops

Business Intelligence Platform

Customer Leverage

Customer Impact

Be First and Best Citrix Customer

Sponsoring Organization:

Finance

Next-Generation Partnership

Employee Impact

Sponsor: Submission Date:

George Deaver 8/4/xx

Sustainable Growth

Continuous Improvement

Competitive Excellence

Productivity Gains

IT Team:

Business Intellgence

People Development

Revenue Generating

Ops Excellence Through Consistent Framework Provide Best Customer Experience

Risk Mitigation

Business Rationale Need to actively manage enterprise data flow using standard data architecture

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

Duplicate data entry between business unit interfaces reduces data quality, leading to inefficiencies and missed opportunities

Use internal resources for build and maintenance to build and retain tool competence. Run in parallel with current platform for two weeks.

Actuals need to be tracked against forecasts to measure performance

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

Project Description

Milestones

This project will accomplish the following:

Project Start Project Go-Live Project Close

1. Compare existing software to competitors to determine if we wish to continue with them or select another vendor. 2. Select vendor and complete contract negotiations. 3. Configure software. 4. Train users. 5. Deploy to production.

Sept. Jan. July

Expected Impact Project Financials

Comments

Total Capital

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

Total Expense

$20,000

Total Costs

$120,000

IT Headcount (FTE)

0.50

Total Benefits


Metric Description

Quantification

Use of enhanced functionality for data capture

100%

20% support costs

Percentage migration of data capture to new platform 75%

Will need 2 FTEs for 3 months

Feed of enhanced BI inputs into SAP

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

Section 4: Providing Accurate Project Effort Estimates


Providing Accurate Project Effort Estimates

47


48

PROVIDING ACCURATE PROJECT EFFORT ESTIMATES Estimate Resource Requirements

Manage Time and Budget on Agile Projects

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

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

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

Raytheon’s Earned Value Metrics for Agile Projects • 53 Raytheon 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 estimate project requirements at each task ■■ To determine resource needs Essential

Reference

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

Specialized

Essential

Reference

Estimate Costs and Risks for Agile Projects

Estimate Benefits for Agile Projects

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

Estimate the value of benefits using an options approach.

TransCanada’s Risk-Based Estimation for Agile Projects • 51 BAs lead the project, breaking down high-level requirements into detailed user stories, which delineates business rules and their corresponding validation messages enabling developers to easily connect requirements to unit tests. To establish a baseline project cost, the time and effort required to develop each user story is estimated. Project funding is allocated based on the coverage of cost scenarios: low-risk projects receive expected funding, high-risk projects receive worst-case scenario funding. Overall, the Monte Carlo simulation allows for more informed decisions about project funding. When to Use ■■ To translate high-level requirements into user stories for Agile projects ■■ To help developers connect requirements to unit tests Essential Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

Reference

Specialized

Specialized

British Airways’ and Emergen’s Initial Value Estimate for Agile Projects • 58 British Airways estimates the value of major benefits streams and uses these estimates to prioritize work by Agile teams. As the team releases the solution on an iterative basis, actual value realization can be used to refine initial estimates and reprioritize. Understanding that benefits’ value are not static, British Airways uses an options approach to control delivery risks. When to Use To elicit goals and testable metrics of project realization from business sponsors ■■ To Identify and prioritize benefits for release ■■

Essential

Reference

Specialized

PROVIDING ACCURATE PROJECT EFFORT ESTIMATES (continued) Estimate Testing Resources Estimate testing effort by using the probability of discovering an error. 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 Essential

Reference

Specialized

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 Essential

Reference

Specialized



49


50

Estimate Resource Requirements Marriott’s Staff Resource Estimation Calculator Illustrative Task Areas

Database Architecture Capacity Planning/Performance Engineering Web Engineering Desktop Certification User and Device Security Web-Based Access Control Engineering

1. Application Technology COTS Custom Other (New to Marriott) Report/Batch Component Weight 2

2 4 5 3 Score 8

2. Number of Tiers One Two Three Four > Four Weight 1

Deployment Services Server Builds Middleware (Application Integration Solutions) ID Admin and User Provisioning Security Architecture WAN Engineering LAN Engineering Configuration Management Infrastructure Application Access Control Implementation Functional Support


One Two Three Four > Four Weight 1

1 1 2 3 4 Score 1

Weight 4

Score 1

Weight 3

1 2 3 4 Score 8

Weight 4

High Medium High Medium Medium Low Low

WEB Fat/Thick Metaframe Terminal Services Weight 2

1 3 4 5 Score 2

Hours and Assessment Areas Development Estimate Requirements and Performance 36

Test Script and Load Test 72

Production Troubleshoot Performance Issues 12

TAM Plugin AMS Junction

Weight 2

2 3

Score 4

< 5 6–10 11–20 > 20 Weight 5

2 3 4 5

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

Score 15

11. Data Requirements 1 3 1 3 Score 3

6. Customization Level High Medium Low

Labor Category

Score 12

10. Number of Business Functions

5. Applications Details Upgrade to Existing App (Same Functionality) Upgrade to Existing App (New Functionality) Replacing Existing Application New Application to Marriott

Weight 3

1 4 4 3

190–210 148–189 64–147 22–63 0–21

9. Extranet 1 1 2 3 4

4. Number of Interfaces 1–5 6–10 11–15 > 15

7. User Base HQ International Properties Res Centers 8. Client Type

3. Number of Unique OS/Platforms

Thin Client Devices and Software

Total Complexity Score

Complexity Drivers: Capacity Planning/Performance Engineering

Project Oversight

Representative Data to Be Generated Test Seed Data to Be Generated

Weight 5

5 5

Score 25

12. User Volumes (Total Named Users) 4 2 1 Score 8

< 100 100–500 > 500 Weight 3 Total Complexity Score

1 2 3 Score 6 93

Categories and answer choices are weighted for relative complexity. Total score is correlated with estimates of up-front and ongoing resource needs.

Estimate Costs and Risks for Agile Projects TransCanada’s Risk-Based Estimation for Agile Projects Business Requirements Requirements

Feature Breakdown

User Cases

Award a Non-Prearranged Biddable Offer

1.5 Business Rules: Award a Non-Prearranged Biddable Offer Name

Type

1.1

Assumptions

1.2

Definitions

Award Quantity

Integer

Secure Winning Bid Set Shipping Route

1.3

Process Flows

1.4

Screen Descriptions

1.5

Business Rules

1.6

Developer Comments

Award a Non-Prearranged Biddable Offer

Developers write business rule validation logic…

1. This field is editable if the corresponding checkbox is True (i.e., checked). 2. The amount awarded to a bid cannot be more than the max bid quantity for that bid. System Message: Award quantity must not be greater than max bid quantity.

…based on the defined validation message…

System Message

Validations

Checkbox

Boolean

Validation X

Bid Rate

Decimal

Validation Y

…and then write Pass/Fail unit tests.

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



51


52

Estimate Costs and Risks for Agile Projects (continued) TransCanada’s Risk-Based Estimation for Agile Projects (Continued)

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


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

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

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

100%

Expected Worst Expected Worst 27.00 Worst 52.00 Expected 27.00 52.00 109.00 27.0052.00 52.00 52.00 109.00 11.00 109.00 17.50 52.00 11.00 17.50 11.0010.00 17.5015.00 10.00 15.00 10.00141.00 15.00250.00 141.00 250.00 96.50 250.00 163.00 141.00 96.50 163.00 337.50 163.00 606.50 96.50 337.50 606.50 84.38 606.50 151.63 337.50 84.38 151.63 57.00 151.63 57.00 84.38 57.00 57.00 57.00113.75 57.00208.35 113.75 208.35 1,629.98 113.75930.13 208.35 930.13 1,629.98 930.13 1,629.98

Probability of Cost Scenario (Percentage)

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

Monte Carlo Simulation Results

0% Best

Worst Project Cost in US Dollars

Manage Time and Budget on Agile Projects Raytheon’s Earned Value Metrics for Agile Projects A Comparison of Agile and Waterfall Lifecycles Waterfall Concept Definition and Business Case Approval

Requirements Definition

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

Development and QA/Testing

Design

■■

■■ ■■

No iterations; build to the specifications identified earlier. Submit change requests if needed. End-to-end functionality is delivered late in the cycle.

Deployment

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

Agile Concept Definition and Business Case Approval

High-Level Requirements Definition

Release Scope Planning

Sprints Detailed Requirements ■■ Develop ■■ Test ■■ Integrate ■■ Reprioritize ■■

Deployment

1. Gather detailed requirements by defining technical specifics of the features to be built. 2. Force prioritization and keep the total number of points constant: If business partners add to scope, deprioritize a comparable functionality. 3. Prioritize capabilities according to user needs and value. 4. Rescope or cancel requirements if effort to build exceeds benefits: Revisit the backlog to ensure that the business case for building the rest of the capabilities is still relevant and sound. 5. Front-load pieces of functionality that users can react to (e.g., interface, data displays, reports) to address the “I know it when I see it” nature of the client-needs articulation. Allowing users to see early on what capabilities they are getting reduces rework costs since functionality has not yet been integrated with many systems. Build buy-in and create evangelists. Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN


53


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.


54

Manage Time and Budget on Agile Projects (continued) Raytheon’s Earned Value Metrics for Agile Projects (Continued)

What the Business Sponsor Cares About

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

B. Will we meet time-to-market requirements?

How Agile Delivers

1. Avoid building fallow functionality by incorporating frequent feedback loops ensuring relevance of requirements that have not been built yet. 2. Avoid scope creep by forcing a prioritization of scope based on expected value and available capacity.

3. Sequence high-value features to be delivered first and be able to cancel at any time and be left with a working functionality.

4. Save on cost by not building functionality that is not useful and high value. C. Are we going to stay within budget?

5. Save on rework cost since Agile is based on delivering discrete “chunks” of tested and valuable functionality. 6. Build discrete components early to provide valid estimates for cost to complete.

D. Will we maximize value from the system?

7. Provide end users opportunities early in the project to influence the implementation, thereby providing a more user-oriented solution and creating evangelists when the product is released.



55


56

Manage Time and Budget on Agile Projects (continued) Raytheon’s Earned Value Metrics for Agile Projects (Continued) Total Project Cost Estimation

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

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

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

2 3

5

User Story Ideal: 3 Points Expected: 5 Points Worst: 8 Points

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


8

13

21 Increasing Complexity

Manage Time and Budget on Agile Projects (continued) Raytheon’s Earned Value Metrics for Agile Projects Feature Backlog Status After Completing One of Four Iterations, Illustrative

Estimate (Story Points)

Completed (Story Points)

Actual Cost (Thousands of Dollars)

Welcome Screen

10

10

15

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

Feature

Totals

200

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

40

65

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

Source: Sulaiman, Sulaiman, Tamara and Hubert Smits, “Measuring Integrated Progress on Agile Software Development Projects,” Methods & Tools, 20 August 2010, http://www.methodsandtools.com/archive/archive.php?id=61. Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN


57


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

2 Discover the goals of the client and customer through interviews.

6

7

11

8

Choose between competing and conflicting stakeholder goals by ranking goals against business value drivers.

9 Explore the process, define acceptance criteria, and discover missing user stories with “what if?” scenarios.

Define user stories to implement the steps in the process.

12 Come up with better solutions by using innovation techniques.

4 Define the business value model and the business value drivers that will drive the project.

Discover the stakeholders and their goals using a context diagram.

Elaborate business processes and the domain model.

1

3

5 Discover the highest-value business process and its supporting processes.

10 Capture nonfunctional requirements with acceptance criteria and service levels.

Improve your process with the theory of constraints.1

13 Integrate the customer and the analyst in the value stream.

Track progress and value delivered across the whole value stream.

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

Source: Eliyahu, M. Goldratt, Jeff Cox, “The Goal: A Process of Ongoing Improvement, (1984),” North River Press, 2nd Rev edition (1992), ISBN 0-88427-061-0, 20th Anniversary edition (2004).


58

Estimate Benefits for Agile Projects (CONTINUED) British Airways’ and Emergen’s Initial Value Estimate for Agile Projects (Continued) Project Breakdown into a Benefits Stream Illustrative

Tracking Metrics

Project

Paid Seating Project, Business Case: 100%

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

New Revenue Stream-Seating Sales

Improve Customer Experience

Call Center Efficiencies

Revenue Increase

Revenue Retention

Cost Reduction

Benefits Streams

Basic Online and Change and Upgrade Sales

Exit and Other Seat Sales

Principles

Revenue Increase

10%

Revenue Retained

5%

Cost Reduction

3%

Initial Estimate of Contribution to Business Case

50%

Offline Sales

Basic Online and Change and Upgrade Sales

Goals

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

30%

20%

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

■■

Each project must have business benefits linkable to tracking metrics.

■■

Each project has a small number (fewer than five) of associated value propositions, derivable from impacts on tracking metrics.

■■

Each value proposition is realizable by a benefits stream, defined as a series of releasable feature sets capable of delivering the value proposition.



59


Estimate Benefits for Agile Projects (continued) 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.


Use the initial value estimate of an option to tentatively prioritize it on a value proposition roadmap. Revise this value after each release in a benefits stream. Calculate the cost to hold to ensure that the initial value estimate exceeds the cost of formulating the option.

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

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

60

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

1

2

3 Initiate Benefits Tracking

Develop and Deploy

4 Obtain Benefits Realization Information from Previous Releases

5 Reevaluate Estimated Benefits on Future Options

Reprioritize Benefits

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

Initial Value Proposition Roadmap

Final Value Proposition Roadmap

llustrative

llustrative

Change and Upgrade Seat

Exit and Other Seat Sales Online

Exit Row Seat Sales Online

Basic Online Seating Sales Change and Upgrade Seat

Basic Online Seating Sales

Offline Seating Sales Release 1 October

Offline Seating Sales Release 2 December

Release 3 March

Release 1 October

Release 2 December

Release 3 January

Release 4 April



61


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

Voucher Project

Paid Seating Project

Benefit A

Benefit B

Benefit C

Benefit D

Benefit A

Benefit B

Benefit C

Options Value: 50% of business case







Options Revaluation Based on Benefits Tracking

Reprioritized Portfolio of Benefits

Voucher Benefit A

Voucher Benefit B

Paid Seating Benefit A

Paid Seating Benefit B

Paid Seating Benefit C

Voucher Benefit C

Voucher Benefit D

Realized Value: 90% of business case

Realized Value: 5% of business case




Updated Options Value: 5% of business case

Updated Options Value: 0% of business case


62

Estimate Testing Resources Hartford’s Managing Time and Budget Trade-Offs in Testing Project Risk Scorecard

Project Selection Criteria

Project 1

Project 2

1. Percentage of Test Cases with Links to Financial Transactions

2

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

2

2

18/30

23/30

60%

76.66%

10. Project Introduces New Functionality Total Score Percentage (Total Score/Maximum Score)

Project 3

Project 4

Project 5

Note: Maximum score equals 30.



63


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

No

—

Yes

N/A

10. Project Introduces New Functionality


64

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

∑ PR

X

Probability Risk Factor (PR) Test Case Description 1

∑ IR Impact Risk Factor (IR)

Risk Score

Usage Frequency

Defect Prone Areas

Change in Requirements

Complexity

Business Criticality

∑ IR * ∑ PR

1

2

2

3

2

16

Sample Test Scenario

2 3 4 5

Scoring Criteria Probability Risk Factors (PR)

3

2

1

Defect Prone Areas

Highly Defect Prone

Medium Defect Prone

Low Defect Prone

Usage Frequency

Very Frequently Used

Frequently Used

Rarely Used

Changes in Requirements

Frequently Changed

Sometimes Changes

Never Changed

Complexity

Highly Complex

Medium Complex

Low Complex

Impact Risk Factors (IR)

3

2

1

Business Criticality

High

Medium

Low



65


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

1.0 INTRODUCTION 1.1

Background/Summary

1.2 Documentation and References

7.0 TEST MANAGEMENT APPROACH 7.1

Test Environment

7.2 Test Tools

2.0 TEST OBJECTIVES

7.3 Test Data

3.0 TESTING SCOPE

7.4 Test Script/Case Database

3.1 Applications/Functions/Features to Be Tested

7.5 Change Management

3.2 Applications/Functions/Features Not to Be Tested

7.6 Version Control

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


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

66

Estimate Testing Resources (Continued) Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued) Testing Strategy Documentation (Continued) Test Strategy Review Checklist Section

Section Title

1 2

Checklist Items

Yes

Introduction

4

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

Scope

6 8

Have in-scope and out-of-scope types of testing been identified? Has the rationale behind the scope decision been stated?

Test Levels and Type

Have all the test levels and types been defined? Have the entry and exit criteria for the applicable types of testing been determined?

9

Has the requirements analysis process been identified?

10

Has the test process to be followed been defined?

11

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

12

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

13 14

Comments

Has the intended audience been identified appropriately? Have all the required documents been identified and referred to for preparing the test strategy?

7

NA

Has the project/application overview been documented?

3

5

No

Test Methodology

Has the list of tools and its purpose for various QA activities been identified? Have the different test environments for different types of testing been identified?

15

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

16

Has the high-level test data approach been determined?

17

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



67


68

Estimate Testing Resources (Continued) Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued) Testing Strategy Documentation (Continued) Test Strategy Review Checklist (Continued) Section

Section Title

Checklist Items

18

Have test planning activities been outlined clearly?

19

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

20

Test Management

21 22 23 24 25 26 27 28

Has the process on version control from development to testing environment been outlined? Has the process for defect management been identified?

Roles and Have all the required roles and responsibilities been clearly stated? Responsibilities Have the assumptions and dependencies that underlie the test strategy been identified?

Assumptions, Have the risks based on assumptions, dependencies and past data been identified? Risks, and Dependencies Are risks being assessed based on their likelihood, and are appropriate mitigations being determined to avoid the risks? Test Schedule References


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

Yes

No

NA

Comments

Estimate Testing Resources (Continued) Hartford’s Managing Time and Budget Trade-Offs in Testing (Continued) Testing Strategy Documentation (Continued) Test Requirements Traceability Matrix

Item No.

Requirement ID

Requirement Description

Test Condition Name

Test Case Name

Defect ID



69


70

Estimate Testing Resources (Continued) 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

5

5

5

15

4

4

4

12

6

6

6

18

7

7

7

21

8

8

24

8

2

2

2

6

4

4

4

12

Total

36

36

36

108

Estimate for Total Test Case Points (Note: The Adjustment Factor in the table below is predetermined and must not be changed for every project.) Test Case Type

Complexity Weight

Adjustment Weight

Number

Result

Simple

1

1

2

72

Average

2

2

4

144

Complex

3

3

8

288

Total Test Case Points


504

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

Project Resource Mapping

Business Unit Resource Cost Estimation

Illustrative

Illustrative

Business Unit

Project Manager Name

Assigned

Project Name

January 2010

Business Unit 1

John

Yes

Project 1

10

Billable Core

Business Unit 1

Kathy

No

0

Overage on Core $

Business Unit 2

Christina

Yes

Project 7

10

Demand for Flex

Business Unit 2

Karthik

Yes

Project 7

10

Billable Flex $

Business Unit 3

Penny

No

0

Total Business Unit 1 $

Business Unit 3

Vikram

No

0

Business Unit 2

Business Unit 4

Penny

No

0

Demand for Core

Business Unit 4

Vikram

No

0

Billable Core

Business Unit 4

Jennifer

Yes

20

Over/Under on Core $

50

Demand for Flex

Total Testing Demand

Project 1

Business Unit 1

Jan.

Feb.

Jan.

Feb.

Jan.

Feb.

Demand for Core

Billable Flex $ Total Business Unit 2 $ Business Unit 3



71


72

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

1

Develop Data-Oriented Service Definition

2

■■

Identify service components using a handful of data attributes.

6

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


Build a Price List for Services

■■

5

Adopt pricing scheme per service component.

■■

Measure Service Consumption Use service inbound queue to count unique message IDs.

Identify cost per service based on pricing scheme.

Identify Patterns of Service Usage ■■

3

Identify which components are widely used, moderately used, or not used across services. Assess the prevalence of service components across the portfolio.

4

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

Estimate Service Cost (CONTINUED) SKF’s Reusable Services for Large-Scale Integrations (Continued) Implementation Cost Model Implementation and Support Costs per Year One-Time Costs Ongoing Costs

$20 $75K

$20K $75

$20

$150K $150

$150

$150

Create a Service Price List

Maintain Catalog of Services

Make Decisions About Ongoing Reuse, Consolidation, or Elimination

Note: The numbers provided in this cost model should serve as guidance to members; they are not provided by the case company. The numbers are based on the Council’s research, and we encourage members who have additional questions to contact our staff for further discussion.



73


Estimate Service Cost (CONTINUED) SKF’s Reusable Services for Large-Scale Integrations (Continued) Payback on Reusable Services

Service Reusability Model

Service Reusability Assumptions 50

100

25

Data Transformations

2

40

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.

3

1

40

External Connections

40

Internal Connections

4

Conversion to Common Message Format

Cost to Create One-ofa-Kind Service

Service Consumption Chargeback Benefits

Cost to Generalize and Improve Service Performance

Three Months Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

Cost Avoidance Due to Reuse

One Month

Six Months

74

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

Benefits

A. Capital Cost of Building a Service

A. Service Consumption During Its Lifecycle

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

$100

2. Estimated number of hours required for one data transformation

100

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

50

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

50

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

50

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

1,200,000

2

$0.10

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

B. Service Fortification 6. Cost of fortification as a percentage of initial service development cost

12. Total number of requests for a single-use service per year

0.000001

50%

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

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 10. Support cost as a percentage of total lifecycle costs

60 60%

D. Admin Costs 11. Monthly admin cost (fully loaded)

$5,000



75



76

Section 5: Architecture Management


Architecture Management

77


78

ARCHITECTURE MANAGEMENT Support Business-Led Technology Purchases Guide business leaders to ask vendors the right questions to unearth the most likely technology selection pitfalls.

to optimize process maturity. As 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.

CareFusion’s Technology Buyer’s Guide • 79 The 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. Automate processes for which a strong business case can be made. 3. Continue automation to improve efficiency as process matures while avoiding process rigidity. When to Use ■■ To tie requirements to appropriate levels of process maturity ■■ To use process analytics to make informed technology roadmaps ■■ To prioritize process improvements Essential

2. Implementation effort 3. Quality of the vendor partnership When to Use ■■ To manage interactions with technology vendors ■■ To guide and coach business sponsors to make informed technology choices Reference

Specialized

Balance Process Maturity and Automation Allow flexibility between automation and processes. Use Business Process Mapping (BPM) to create a roadmap for automation of processes. Alpha’s1 Balancing Process Maturity and Automation • 83 Alpha determines which processes to automate and at what level, while helping

1

Pseudonym.


Specialized

Support Service Reuse

4. Financial cost

Essential

Reference

Increase ROI from existing services by reengineering them based on service usage patterns and data patterns. 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 ■■

Essential

Reference

Specialized

Support Business-led Technology Purchases CareFusion’s Technology Buyer’s Guide 1. Buyer’s Guide: Fit with Identified Needs Part 1: Questions for Self-Reflection 1. Have we defined metrics for assessing the success of this implementation? 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? ■■ Functionality 1. Based on the problem we are facing, which functionality of your product will be used most in our organization? 2. Which functionality will we use least? 3. Can you provide examples of functionalities you have added based on client feedback? ■■ Ease of Use 1. How will our staff access the solution? 2. Will our staff be able to use their enterprise ID and/or single sign-on to log into your software? 3. How will our staff pull reports from the software? ■■ Short-Term Versus Long-Term Fit 1. How would our organization have to adapt in the usage of your product in a case of a major business event, (e.g., geographic expansion, M&A, significant increase in staff headcount)? 2. How would you adapt your offering if a competitor offered the same product and services bundle at a lower price point? 3. Which functionalities of your product could be enhanced to meet our specific need more efficiently in future releases? ■■

Overall Grade A–F: (How well did we understand what the vendor told us about this category?)



79


80

Support Business-led Technology Purchases (continued) CareFusion’s Technology Buyer’s Guide (Continued) 2. Buyer’s Guide: Implementation Efforts Part 1: Questions for Self-Reflection 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.

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

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



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

■■

Support Business-led Technology Purchases (continued) CareFusion’s Technology Buyer’s Guide (Continued) 3. Buyer’s Guide: Quality of Vendor Partnership Part 1: Questions for Self-Reflection 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.

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

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 Behavior 1. What incentives do you provide your staff to exhibit high levels of customer service? 2. Do you measure and analyze employee satisfaction? 3. What is your company’s standard for professional and cooperative behavior? ■■

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




81


82

Support Business-led Technology Purchases (continued) CareFusion’s Technology Buyer’s Guide (Continued) 4. Buyer’s Guide: Financial Cost Part 1: Questions for Self-Reflection 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.

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

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 Competitiveness 1. What is your unit of measure for the product and service? (e.g., per employee, per device, per user account, per transaction, enterprise-wide license? 2. What is the billing frequency? E.g., per month, per quarter, per year)? 3. On average, by how much does a 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 Flexibility 1. How much flexibility will we have to increase or decrease our level of consumption of your product and services? 2. Are there any contractual minimum payments, such as a minimum monthly or annual payments? 3. Are there any termination charges? 4. Is there a minimum length of service for a particular unit of measure (e.g., a user must be active for at least one year?) ■■

Overall Grade A–F: (How well did we understand what the vendor told us about this category?) Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

Source of Vendor Profits 1. What is your margin on goods sold versus services sold? 2. How much does an average client spend on professional services with your company? 3. Based on our need and environment, how much custom implementation requiring paid support would you recommend? ■■ Vendor Stability 1. How long have you been in business? 2. At a high level, what is your company’s strategy for the next 12 to 18 months? ■■

BALANCE PROCESS MATURITY AND AUTOMATION

1

Alpha’s Balancing Process Maturity and Automation

■■

Investigate Process

■■ ■■

Analyze Process Components

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

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

Decide Whether or Not to Automate

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

Yes

Define requirements for automation of process component.

1

No

Exclude from technology solution.

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

Pseudonym.



83

BALANCE PROCESS MATURITY AND AUTOMATION (continued) Alpha’s Balancing Process Maturity and Automation (Continued) Using Process Analytics to Inform Technology Roadmaps

Steps 1. Create an IT Business Process Mapping (BPM) team.

Key Activities and Tools ■■

Identify business process experts within IT.

■■

Adopt a BPM methodology.

■■

Select BPM tools.

■■

Work with customers to select processes to improve.

■■

Create IT–business pilot teams.

■■

Map each process.

■■

Use iterative development to execute process improvements.

2. Select pilot BPM projects.

1

Pseudonym.



84 1

BALANCE PROCESS MATURITY AND AUTOMATION (continued)

1

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

Steps

Key Activities and Tools

3. Create a BPM Center of Excellence. ■■

■■

Create BPM governance structure.

■■

Create a BPM training program to deepen talent bench.

■■

Select initial projects with similar criteria to pilot projects.

■■

Tackle increasingly complex projects as maturity deepens.

■■

Automate mature processes.

4. Expand scope of BPM.

1

Use data from pilot projects to obtain customer and management buy-in.

Pseudonym.



85


86

Support Service Reuse DirectTV’s Deriving Maximum Value from Existing Technical Services Partial Root-Cause Analysis of SOA Challenges Objective

Challenges

Subchallenges

Solutions

1 It’s hard to know which data to standardize.

Lack of consistent data standards and definitions

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

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

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

3 In addition to identifying commonalities

Improve the value of existing technical services (SOA).

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

It’s hard to identify service consolidation opportunities.

Too many redundant, low ROI services

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

4

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

5 Minimize disruptions in knowledge It’s hard to ensure service reusability.


transfer about service usage among design teams through modular service training.

Support Service Reuse (continued) DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued) 1. Identify Data Standardization Opportunities for Services All data Customer, product, account, etc.

Filter 1: Is this data used by integration services?

Yes

No

Go

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

Yes

No

Go

Formulate an enterprise standard in the canonical data model and allow provider databases to retain local variations in definition.

Integrate data into the canonical data model.



87


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

Type of Data Inconsistency 1. F ormat: Inconsistent way of recording identical data elements

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

3. D efinition: Inconsistent definitions of what a data element means


Example—Customer Data

Action

Database A

Database B

John Smith

Mr. Smith, John

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

Database A

Database B

John Smith

John Smit

Database A

Database B

John Smith

Alpha Company Inc.

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

88

Support Service Reuse (continued) DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued) 3. Maximize the Value from Existing Services Filter 1: Service usage commonalities— Identify a group of services that perform the same action (e.g., look up customer profile).

1

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

Service Name (Old Services)

Service Description

1. Look_up_ 1. L ook_up_ customer customer 2. A ccess 2. Access Account Account 3. customer3.2 3. customer3.2

Provides customer information Provides customer information.

Modifies customer or account Modifies customer or account information information.

I

4. A ctivation

Activates access to new products or services

I

5. vz3_billing

Submits customer order for billing

I

I

Input data

O

Output data

Name

Retrieves customer account Retrieves customer account.

I I

Service Input and Output Data Elements1 Customer Phone Customer Payments Address Phone ID ID

I

I

I

I I

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

I

O O

O O

I

O O

O O

I

O O

I

I

O

O

I

I

O

O

I

I I

I

I

O

Account Status

I

I

1. Standardization opportunity An area where a consolidated service can be created (e.g., Customer Information) 2. Flexibility needs Areas where the use case of a service differs from the use case of the consolidated service



89


Support Service Reuse (continued) DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued) 4. Identify High-Value Composite Services Data integration patterns: Patterns in data integrated together across different services Service usage patterns: Patterns in services used together to deliver a functionality Requests from design teams for new composite services

Reengineered Service Orchestration Analysis Illustrative

Elements of a Composite Integration Service

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

Service Name (New Services)

Service Description

1. C ustomer Information

Provides customer information

2. V erify Product/ Service Eligibility

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

3. Update Account

Modifies customer account information

4. Verify Address

Confirms customer address information

5. Process Order

Submits customer order for billing

6. A ctivate Account

Activates access to new products or services

Data Elements in the Canonical Data Model Customer


Data Called by a Consumer System

Account

Product

Service

Orders

Subscriptions

90

Support Service Reuse (continued) DirectTV’s Deriving Maximum Value from Existing Technical Services (Continued) 5. Promote Continuous Service Education Key Questions in Integration Process Flow

Training Tool

What Does It Provide?

Benefits

Key Elements

1. H ow do I use integration services?

Integration Services Usage Guide

An introduction to the services ecosystem

Defines “rules of engagement” for using all integration services

Common elements and features and across all services

2. Which set of services are available to me?

Consumer System Usage Guide

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

Ensures alignment with workflows supported by the consumer system

■■

■■

3. H ow do I use a specific service?

Service-Specific Interface Agreement1

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

Minimizes ambiguity around how to use a service

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

Event Notification Specification Document2

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

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

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.

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

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

■■

Notification standards and guidelines Required versus optional message communications



91



92

Section 6: Designing for Usability


Designing for Usability

93


94

Designing FOR USABILITY Design for the End User

Develop Customer Intelligence

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

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

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

Essential

Reference

Specialized

Improve System Usability

Kimberly-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

■■


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 Essential

Accurately isolate the cause of performance lapses due to system performance, user behavior, or business process health.

Essential

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

Reference

Specialized

Reference

Specialized

Design for the End User LexisNexis’s Uncovering Unarticulated Needs Problem Statement for a New Business Development Junior Executive Illustrative

1. Direction Minimize…

3. Outcome …the number of interruptions I have during my work day…

…to free up time to identify new opportunities to find new clients.

=

Impact on Knowledge Worker Productivity

2. Unit of Measure

Problem-to-Objective Mapping Illustrative New Business Development Junior Executive

Importance

Satisfaction

Difficulty

9.5

6.5

High

Role Objective

1. Improve my daily work experience by extracting the most relevant information in the shortest amount of time to work efficiently and manage time effectively.

Relevant Problem Statements

a. Minimize the number of interruptions I have during my work day to free up time to identify new opportunities to find new clients. b. Increase the number of contacts I have with clients to improve my sales pipeline. 2. Widen my network of business contacts to start marketing myself and build a book of business.

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.

1

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

Importance: 1–10

Satisfaction: 1–10

1—Not at All Important

1—Not at All Satisfied

10—Very Important

10—Highly Satisfied Difficulty: High/Medium/Low



95


96

Design for the End User (CONTINUED) LexisNexis’s Uncovering Unarticulated Needs (Continued) Knowledge Worker Objectives Map Illustrative for a New Business Development Junior Executive

Very Important High Difficulty

1. “Improve my daily work experience by extracting the most relevant information in the shortest amount of time to work efficiently and manage time effectively.”

Importance of the Objective

Medium Difficulty

Knowledge Worker Objectives Identified as “Knowledge Worker Imperatives”

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

Other Knowledge Worker Objectives

Importance: 1–10

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

1—Not at All Important 10—Very Important

Satisfaction: 1–10

High

Low Satisfaction with the Current Solution(s)


1—Not at All Satisfied 10—Highly Satisfied

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

Solution Ideation

Process

Input ■■

■■

■■

Design Roadmap Update

Feature Assessment Session (FAS)

Pre-Feature Assessment Session

Knowledge worker imperatives Voice of the knowledge worker (e.g., interview scripts and recordings) Problem statements associated with the knowledge worker imperatives

Knowledge Workers

Project Kickoff

Output Innovation Team ■■

■■

Customer Advocate Product Champion

Technical Teams ■■

■■

■■

■■

Enterprise Architects Domain Architects User-Experience Team Prototyping Team

■■

Design documents

■■

High-fidelity wireframes

■■

■■

High-fidelity service prototypes Initial solution concepts



97


98

Improve System Usability Kimberly-Clark’s Usability Leading Indicators Preemptive Performance Tracking

Potential Problems

Poorly Designed Business Process

Poor System Performance

Inefficient Use Is performance degradation due to user inefficiency?

Key Questions

Is the business process itself inherently inefficient?

Is the system performing as it should?

Does the user know how to use the application correctly?

Is the application too difficult to use correctly?

Confirming Metrics

User Experience Metrics


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

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

Error frequency by functionality usage

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

Improve System Usability (continued) Kimberly-Clark’s Usability Leading Indicators (Continued) Usability Root-Cause Analysis Too High

Level One

If “yes,” then proceed

Too Low

Poorly Designed Business Processes Is the business process efficient?

1 Error frequency by business processes

2 Time spent per screen 3 Ratio of number of processes completed versus aborted

4 Ratio of actual process completion time versus best practice

Level Two

If “yes,” then proceed

Poor System Performance Is the system performing as it should?

5 Average end-to-end response time

6 Number of processes executed

7 Average processes duration 8 Cumulative user sessions by hour of day

Level Three Inefficient Use Is the application being used efficiently?

9 Number of errors per user 10 Error frequency by functionality usage

11 Error frequency by error type 12 Ratio of process “active” time versus “idle” time

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



99


100

DEVELOP CUSTOMER INTELLIGENCE Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions 1. Use Multiple Channels to Understand Customer Needs

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

360˚ View of the Customer Customer Survey ■■ Relationship/ engagement quality ■■ Fit of existing solutions ■■ Understanding of business issues


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

DEVELOP CUSTOMER INTELLIGENCE (continued) Standard Chartered’s Leveraging End-User Data to Proactively Deliver Solutions (Continued) 2. Recommend Workflow Improvements Analyze Service Ticket Data to Achieve Valuable Service Outcomes

Analyze Service Ticket Data

Look for Leading Indicators

Service Outcome

Error Type

Error

Impact

Source

User Group Frequency

Application functionality

Access failure

Low (< 5% of users)

Missing patch

Call center technicians

10x/30 days

Business process

Incorrect report sequencing

High (> 25% of users)

Poorly mapped process

Business unit A line managers

21x/30 days

User

Failed database query

High (> 25% of users)

Missing data field and set

Market researchers

13x/30 days

Number of errors per user group

Error frequency by business process

Enhance End-User Performance

Business Process Improvement

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

Review business process errors to locate inefficiencies and identify solutions.



101


102

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

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

2. Solution Delivery Team: Deliver analysis to sponsor.

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

4. Solution Delivery Team: Provide recommendation to sponsor.

5. Business accepts solution.


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.

Recommendation ■■

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

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

Steps

Key Activities and Tools

1. Survey customers to identify performance gaps.

■■

Conduct a survey of executive leaders and business sponsors to assess customer satisfaction on critical performance criteria: –– Business engagement and customer relationship management –– Ability to enhance business unit performance –– Ability to meet revenue targets –– Overall credibility rating

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

■■

■■

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



103


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

Steps 3. M ine maintenance and support data to proactively identify service opportunities.

Key Activities and Tools ■■

■■

■■

■■

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

■■ ■■

■■


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

Provide customer relationship training to all staff members. Focus initial conversations on stabilizing and improving current service levels (e.g., application availability and project tracking). With improving customer confidence, move from providing tactical and informational updates to engaging customers in strategic conversations.

104

Section 7: Communications and Change Leadership


Communications and Change Leadership

105


106

COMMUNICATIONS AND CHANGE LEADERSHIP Develop Attributes of an Effective BA

Essential

Reference

Specialized

Engage and challenge business sponsors’ assumptions. Potential Attributes of an Effective Business-Facing IT Professional • 108 Many of the attributes required in sales roles are increasingly applicable to business-facing IT professionals. When to Use To develop skills and behaviors of an effective BA

■■

Essential

Reference

Specialized

When to Use To understand how different behaviors affect engagement outcomes

■■

Reference

Communication strategies need to be tailored to business leaders’ temperaments and posture toward project change and their degree of influence on project outcomes. Communication Challenges with Business Leaders • 114

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

Essential

Establish Effective Communication with Business Leaders

Business leaders differ in their psychology, values, and assumptions about technology, placing strains on engagement with BAs. A growing percentage of business leaders are willing to lead in more aspects of applications projects. When to Use ■■ To understand behavioral temperaments of the business sponsor Essential

Reference

Specialized

Specialized

Deconstruction of a Compelling Teaching Pitch • 115 Critical Attributes of Challengers • 111 Typically Relationship Builders are focused on resolving tension and creating a more collaborative, agreeable environment. On the other hand, Challengers succeed because they can teach, tailor, and create constructive tension with the sponsor. The 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

■■


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 Essential

Reference

Specialized

COMMUNICATIONS AND CHANGE LEADERSHIP (Continued) Customer Outcomes Map • 117

Coca-Cola’s Building Transparency in Communications • 121

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

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

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

Reference

Specialized

The negotiation roadmap demystifies the behaviors of highly successful negotiators that can be applied for successful negotiations in a low-risk environment. When to Use To develop effective negotiation skills

■■

Reference

Specialized

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 Essential

Essential

Reference

Specialized

Plan Change Management Activities Target change communications based on stakeholder priorities

Negotiation Roadmap • 119

Essential

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

Reference

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 Essential

Reference

Specialized

Specialized



107


108

Develop Attributes of an Effective BA Potential Attributes of an Effective Business-Facing IT Professional

Attitudes

Skills and Behaviors

Leverages Support

■■

Interest in Feedback

■■

■■ ■■

Activities

Professional Image

■■

Explores All Options

■■

Outcomes Focused

■■

Knows Value Drivers

■■

Follows Formal Processes

Discretionary Effort

■■

Offers a Unique Perspective

■■

Lead Generation

■■

Tenacity

■■

Two-Way Communication Skills

■■

Analytical Skills

■■

Curiosity

■■

Can Identify Economic Drivers

■■

Experiments with Approach

■■

Can Pitch Strategy

■■

Requests Assistance

■■

Forms Good Partner Relationships Has Advocates in Partners

■■ ■■

■■

Wants to Manage Company Outcomes

■■

Company Attachment

■■

■■

Can Work with Anyone

■■

■■

Genuine

■■

Accessible to Partners

■■

Passionate About Customers

■■

Flexible


■■

Good Cross-Functional Relationships Ability to Work with the Team

■■

Respects Partner Time

■■

Strategic Agility

■■

Manages Expectations

Knowledge

Can Explain ROI

■■

Product Knowledge

Meeting Preparation

■■

Industry Knowledge

Develop Attributes of an Effective BA (Continued) Representative Profiles

The Challenger® (27% of Sample) ■■

■■

■■ ■■

The Relationship Builder (21% of Sample)

Always has a different view of the world Understands the customer’s business Loves to debate Pushes the customer

■■

■■

■■

Builds strong advocates in customer organization Generous in giving time to help others Gets along with everyone

The Hard Worker (21% of Sample) ■■

■■

■■ ■■

Others (32% of Sample)

Always willing to go the extra mile Doesn’t give up easily Self-motivated Interested in feedback and development

n = 683 sales reps. Note: Numbers do not equal 100% due to rounding.



109


110

Develop Attributes of an Effective BA (Continued) Representative Profiles (Continued) While individual differences exist, all respondents can be categorized in terms of their likelihood to exhibit one group of attributes over the others.

Challenger ■■

Knows Customer Value Drivers

■■

Offers a Unique Perspective

■■ ■■ ■■

Relationship Builder ■■

Forms Good Customer Relationships

■■

Discretionary Effort

Can Discuss Money

■■

Outcomes Focused

Two-Way Communication Skills

■■

Attachment to the Company

■■

Tenacity

Can Identify Customer Economic Drivers

■■

Can Work with Anyone

■■

Project Management Skills

■■

Genuine

■■

Leverages Support

■■

Preparation Before Calls

■■

Follows Formal Sales Process

■■

Curiosity

■■

Interest in Feedback

■■

Learns Everything New

■■

Can Pitch Strategy

■■

Product Knowledge

■■

Accessible to Customer

Knows How Customers Differentiate

■■

Gives Time to Help Others

■■

Respects the Customer’s Time

■■

Good Cross-Functional Relationships

Industry Knowledge

■■

Can Explain ROI of the Sale

■■

Professional Image

■■

Motivated by Goals

Has Advocates in Customers

Can Pressure Customer

■■

■■

■■

■■

■■

Hard Worker

Explores All Options Before Closing

■■

■■

Experiments with Sales Approach

■■

Requests Assistance

■■

Generates Leads or Prospects

■■

Source: Integrated Sales Executive Council’s Rep Skills Diagnostic.


Evaluates Likelihood of Purchase

Wants to Manage Company Outcomes

Develop Attributes of an Effective BA (Continued) Critical Attributes of Challengers Challenger Builder Profile

Relationship Builder Profile

The Challenger profile focuses on building constructive tension in interactions to push customers out of their comfort zone.

■■ ■■

Offers unique perspective Has two-way communication skills

■■

Knows customer value drivers

■■

Can identify economic drivers

■■

Is comfortable discussing money

■■

Can pressure the customer

Teaches

The Relationship Builder profile focuses on resolving tension in interactions to make situations more amicable and positive and encourage collaboration.

■■

Forms good relationships

■■

Builds customer advocates

■■

Tailors

Asserts Control

Builds cross-functional relationships

■■

Can work with anyone

■■

Is genuine

■■

Is accessible to the customer

■■

Gives time to help others

■■

Respects the customer’s time

Gets Along with Others

Likeable

Generous with Time

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



111


112

Develop Attributes of an Effective BA (Continued) Critical Attributes of Challengers (Continued)

Teach: Reframe the way business partners view their business and their needs.

Tailor: Link your capabilities to business partners’ individual goals.

Teach for Differentiation

Tailor for Resonance

Assert Control

Assert Control: Openly pursue goals in a direct but not aggressive way.

The New High Performer

Questions to Consider What should my business-facing Applications staff teach?

Source: Integrated Sales Executive Council research. Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

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?

Develop Attributes of an Effective BA (Continued) Critical Attributes of Challengers (Continued)

■■

■■

■■

Subverts goals to the needs of others Allows personal boundaries to be breached Uses indirect, accommodating language

Aggressive

Assertive

Passive

■■

■■

■■

Directly pursues goals in constructive way Defends own personal boundaries Uses direct language

Sales Performance Problem

■■

■■

■■

Pursues goals at the expense of professionalism Attacks others’ personal boundaries Uses antagonistic language

Common Sales Leadership Fear

Reps are often too passive with customers, seeking to resolve conflict whenever possible.

Tell sales reps to be more assertive and they may become aggressive.



113


Establish Effective Communication with Business Leaders Communication Challenges with Business Leaders

Characteristics

Differentiation

Personality

■■

Views of Technology Investments

Likely Reaction to Engagement

■■

■■

■■

■■

Values

■■

■■

Career Past

■■

■■


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

114

Establish Effective Communication with Business Leaders (Continued) Deconstruction of a Compelling Teaching Pitch

Positive

“Emotometer”: Level of Customer Excitement

…then building back the customer’s confidence in a new solution.

Teaching follows boot camp theory of shocking the customer with the unknown…

2. “Reframe” First reframing of unrecognized problem, need, or assumption

Neutral

1. “Warmer” Building credibility by reading their mind and demonstrating empathy

…breaking down the problem behind the unknown…

3. “Rational Drowning” Gradual intensification of the problem, both in degree and closeness to the customer

4. “Emotional Impact” Description of the psychological features of the problem, or presence in the 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

Negative Intrigued

Drowning

Involved

Relieved

Customer State Source: Integrated Sales Executive Council research.



115


116

Establish Effective Communication with Business Leaders (Continued) Teaching Do’s and Don’ts

DON’T

DO

Open with the breadth of your product portfolio and capabilities.

Open with a focus on the customer and their issues.

Discuss how long your company has been in the marketplace.

Reframe customers’ understanding of their world.

Focus on features and benefits.

Make the sale personal and provide value to that individual.

Lead with your unique strengths.

Source: Integrated Sales Executive Council research.


Lead to your unique strengths.

Establish Effective Communication with Business Leaders (Continued) Customer Outcomes Map An IT project has attributes in the areas of risk, benefits, and effort required from the business.

Consumer Trade-Offs

Business Leader Trade-Offs

Component Trade-Offs

■■

Features

Risks

■■ ■■

■■

Quality

Benefits

■■ ■■ ■■

Price

Business Effort Required

■■

■■

Regulatory Compliance Risk Business Continuity Risk Information Security Risk

Hitting Cost and Scope Target Speed to Market Direct Benefits Realization High Data Quality

Total Percentage of Resources Required SME Time



117


118

Establish Effective Communication with Business Leaders (Continued) Concept Definition

Customer Outcomes What an individual customer is trying to achieve—how they would define success in their job

Activity or responsibility in need of improvement

Source: Integrated Sales Executive Council research.


Metric used to measure success

Direction and magnitude of change necessary

Establish Effective Communication with Business Leaders (Continued) Negotiation Roadmap

Acknowledge and Defer

Promise closure and seek permission to have a different conversation.

1

Deepen and Broaden

Expand potential solution components by surfacing areas of additional value.

Explore and Compare

Prioritize solution components by estimating their relative value to the customer.

Concede According to Plan1

Create plan and exchange value instead of giving it away.

Concede according to plan is a principle that can be applied at any point during the negotiation conversation.

Source: Sales Executive Council research.



119


120

Establish Effective Communication with Business Leaders (Continued) Cisco’s High-Risk Stakeholder Communication Plan Illustrative Type of stakeholder drives the nature of communication plan and the degree of customization required.

Customized project messages are developed and cataloged in advance. Key messages include the following: ■■

Elevator Speech

■■

What’s in It for Me?

■■

Change Posture Pitch

Similarly themed messages are tailored for audience seniority, level of detail required, and degree of change resistance.

Stakeholder Segment

Communications Details

Key Message: What’s in It for Me?

High Influence, Resistant Posture

Target Audience Senior Consultants, Operations; Operations Back Office Personnel

“We recognize the current process for submitting expense reports is time-intensive, and turnaround time is slow. The new system for submitting expenses will require less time for report submission, is more accurate, and will expedite your reimbursement turnaround time.”

Resistant

Low

Influential

Neutral

Make or Break

Supportive Impacted

Change Posture

Communication Goal Closely manage expectations; improve change posture.

Medium

High

Degree of Influence

Level of Detail High-level budget and schedule communication; detailed functionality communication Threats (Real or Perceived) Delayed rollout Preferred Mode Trigger-based e-mail

High Influence, Supportive Posture

Target Audience Executive Sponsor; Project Sponsor

Resistant

Low

Influential

Neutral

Make or Break

Supportive Impacted

Change Posture

Communication Goal Closely manage expectations; maintain change posture

Medium

High

Degree of Influence

Level of Detail High-level budget and schedule communication; medium-level vendor performance communication Threats (Real or Perceived) Inadequate user training Preferred Mode Weekly status updates; trigger-based phone call


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

Establish Effective Communication with Business Leaders (Continued) Coca-Cola’s Building Transparency in Communications Information System Change Management

Cost–Benefit Analysis

Interdependency Risk

Capability Investment Prioritization

A Transparency Deficit ■■

■■

■■

■■

IT plans system changes based on its own time schedule, without full visibility of the impact on business processes. IT makes assumptions about the business’s cost tolerance and narrows options accordingly.

IT acts as an intake for business demand, managing dependency risk as an internal IT matter.

IT responds to all breakdowns according to SLAs.

IT often underappreciates or is unaware of the decision-making relevance to business partners of critical pieces of information.

Clarifying the Facts ■■

■■

■■

■■

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

IT is proactive in sharing the inputs that business partners require to make decisions affecting business performance with full knowledge of cost, risk, and available options.



121


122

Plan Change Management Activities NetApp’s Governance Change Management Campaign Stakeholder Group

Change in Stakeholder Workflow

Senior Management

■■

Business Executives

IT Executives

For the first time, the right information will be visible up to the CEO level.

■■

Need to be more collaborative with IT and Finance in planning

■■

Need to align with the new governance models

■■

Only approved projects will get done

■■

Share accountability for ensuring rigorous portfolio prioritization.

Potential Stakeholder Concerns ■■

Processes may not mature fast enough and stunt the company’s growth.

■■

IT may not adequately support the business.

■■

May create more red tape and reduce responsiveness

■■

Resistance to adoption

Key Benefits Messaging ■■

Better visibility on investments and returns

■■

Highest priority projects get the most attention

■■

Increased alignment of investments to functional strategies

■■

Higher thresholds of investments at the cross-functional council level approved by business units

■■

Transformation of PMO from a policing to an enabling organization

■■

Investments better grouped and easier to manage

Account Managers

■■

Need to own the planning process and the transition to project delivery

■■

More bureaucracy that slows down work

■■

Fewer fire drills regarding portfolio and annual planning

Project Managers

■■

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


Plan Change Management Activities (Continued) NetApp’s Change Management Campaign Plan (Continued) Communication Type Weekly E-Mails

Capability Training

Content

Audience

Audience Time Commitment 10 minutes

■■

Provide context for changes, updates, and action items.

■■

Provide visibility on upcoming events.

End Users and Business Leaders

Provide training on using new governance and cost tracking/cost–benefit analysis capabilities.

Early Adopters and Trainers

2–5 hours

Provide an overview and set context for rollout capabilities.


1–2 hours

20+ “Phase 1” End Users in 1 Location

3 hours

2–3 hours

■■

Webinar

■■

Brown Bags

■■

Provide an overview of the complete end-to-end process.

■■

Walk through the project lifecycle and finance process.

■■

Provide opportunity to ask questions and hear from others.

■■

Show how to complete the cost–benefit analysis template.

■■

Answer questions and provide any additional guidance.

20+ “Phase 1” End Users in 1 Location

Provide an overview of project lifecycle and change order go-live elements.


2 hours

■■

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.

End Users

2–3 hours

■■

Share results of adoption evaluation.

■■

Gain input, field questions related to Q1 rollout and future.

One-on-One Working Sessions Webinar Adoption Survey

■■



123



124

Section 8: Business Relationship Management


Business Relationship Management

125


126

BUSINESS RELATIONSHIP MANAGEMENT Build an Engagement Strategy • 127

Help Sponsors See Risk and Value Trade-Offs • 136

Tailor engagement to business leaders’ preferences for risk, benefit, and effort in IT projects.

Clarify risk and value trade-offs.

Business executives fall into four temperaments based on their preferences and trade-offs for risk, return, and effort in Applications projects.

CareFusion’s Clarifying Risk and Value Trade-Offs

These pages outline the types of business leaders by temperament and the defining characteristics of each type. When to Use To understand business leaders preferences for project risk and return effort

■■

Essential

Reference

Specialized

Apply 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

■■

Essential

Reference

Specialized

Understand Business Sponsors’ Temperaments • 135

Track Changing Business Priorities • 137

Four elements—sensitivity to benefits, aversion to risk, desire for control, and measures of success—define a unique business leader temperament.

Attain an enterprise wide view of changing business priorities.

These pages highlight a strategic guide to identifying business leader temperaments and key probing questions to identify a business leader’s profile. When to Use To tailor communication approach based on sponsor’s profile

■■

Essential


Reference

Specialized

CareFusion’s Business Trends Insight Map Use 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 Essential

Reference

Specialized

BUILD AN ENGAGEMENT STRATEGY Four Distinct Dimensions Where Business Executive Temperaments Think and Act Differently The importance of three dimensions— desire for control, aversion to risk, and lure of returns—each defines how individuals measure success.

Lure of Returns The strength of the belief that one’s self-management of a project is necessary to capture returns

Aversion to Risk How willing a person is to take on increased risk in self-managing a project

Each temperament displays a distinct behavior on each of these dimensions, with each having a unique profile based on these dimensions.

Preferences along these three dimensions drive success measures.

Success Measures How a person views and measures past successes and defines success for a future project

Desire for Control How important self-managing IT projects is to an individual



127


128

BUILD AN ENGAGEMENT STRATEGY (continued) Archetypes of Business Leaders by Temperament Business leaders with rational risk/ reward approaches to self-managed solutions who want to work with Applications in a new way

The Opportunists

The Entrepreneurs

51%

23%

The Abdicators

The Cowboys

11%

15%

Low

Willingness to Self-Manage Solution

High

n = 181 business leaders.

Business Leader (Self-)Management of Solutions Delivery: Business takes primary responsibility for performing or managing solutions delivery activities traditionally performed by Corporate IT (e.g., selecting and procuring tools, vendor selection, project management, vendor management). Source: AEC 2011 Survey of Business Executives, May 2011. Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

BUILD AN ENGAGEMENT STRATEGY (continued) Business Executives Fall into Four Temperaments Based on Their Preferences and Trade-Offs for Risk, Return, and Effort in Applications Projects

Low

Openness to Persuasion

High

The Abdicators (11% of Sample)

The Opportunists (51% of Sample)

They want to do what they do and think IT should do IT.

Reformed Abdicators looking for opportunities to do it themselves

Psychographics ■■ ■■

Avoiding management of IT projects at all costs Unswayed by the lure of high project returns

Low

■■ ■■

Top Concern ■■

Can be lured by high returns to self-manage projects Avoiding risky IT projects at all costs

Top Concern

Want to protect their time above all else

■■

Demographics ■■

Psychographics

Most concerned about getting the full scope of what they want

Demographics

Typically have 5 to 15 years of work experience

■■

Typically have 5 to 15 years of work experience

Desire for Control The Cowboys (15% of Sample)

The Entrepreneurs (23% of Sample)

See applications solutions as critical and need to control them; impatient

Can look like Cowboys but have more rational desire to control projects; want to hit home runs and are willing to take risks to do it

Psychographics ■■ ■■

Psychographics

Want to self-manage IT projects at all costs Insensitive to risk

■■ ■■

Top Concern ■■

Speed to market most important motivator

Demographics ■■

Typically have 16 to 25 years of experience

Will do it themselves for higher returns, even if taking on risk Will do what it takes to attain business outcomes

Top Concern

High

■■

Most concerned about achieving business case/outcomes

Demographics ■■

Typically have 16 to 25 years of experience



129


BUILD AN ENGAGEMENT STRATEGY (continued) Engaging the Abdicators

The Abdicators Sensitivity to Returns “I’d rather stick to my day job. I’m sure IT can make the project more successful than I can.” Aversion to Risk “Technology is your job. I break computers just by looking at them.” Success Measures “If I turn on my computer, it works and it’s easy to use—that’s a success.”

Driver: Abdicators only want to focus on their domain of expertise and are uninterested in it projects.

Toughest Scenario—Traditional Engagement Practical Example: You are having difficulty in securing business leaders’ input on an IT–led project where you need active business sponsorship.

Challenger Response Teach ■■

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.


Tailor ■■

Tie Project Success to the Success of Their Daily Work: Abdicators want to focus on their domain only; tie engagement to project success and how that will improve their ability to work.

Assert Control ■■

Use Their Time Efficiently: Explain what you will do to respect their time and use it efficiently.

130

BUILD AN ENGAGEMENT STRATEGY (continued) Engaging the Opportunists 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.”

Driver: Opportunists overestimate the risks or underestimate the possible returns from self-management.

Toughest Scenario: Bolstering Their Confidence Practical 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.


■■

Have Concrete Examples: Explain how risks have been managed in the past.

Explain the Impact of Their Involvement: Speak about how self-management increases the likelihood of achieving the scope or speed to market they desire.

Tailor ■■

■■

Assert Control

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

■■

■■

Provide a Coach: Access to personal support will reassure them.

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



131


BUILD AN ENGAGEMENT STRATEGY (continued) Engaging the Entrepreneurs 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...”

Driver: Entrepreneurs underappreciate the risks associated with self-management or overestimate the impact on returns.

Toughest Scenario: Pulling Them Back from the Ledge Practical Example—A business leader is attempting to participate aggressively in a high-return project but is blind or indifferent to enterprise risk.


■■

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


Tailor ■■

Amplify Risks: Make expected returns seem less than expected risks from self-management.

Assert Control ■■

Focus on Achieving the Business Case: This is Entrepreneurs’ greatest concern. Discuss how they need Applications’ help to reach that goal.

132

BUILD AN ENGAGEMENT STRATEGY (continued) Engaging the Cowboys 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.”

Driver: Cowboys distrust Applications’ ability to meet their needs.

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.


Correct the Past: Acknowledge any past failures, if they exist, and explain what steps have been taken to improve.

Tailor ■■

Assert Control

Diminish Speed Expectations: Tie risks and complexities of a “go it alone” approach to schedule and speed-to-market impacts.

■■

■■

Infiltrate the Team: Find a key lieutenant and win him or her over to help make your case.

Govern: If all else fails, govern by going to a higher authority and explaining what is at risk.



133


134

BUILD AN ENGAGEMENT STRATEGY (continued) The Abdicators

The Opportunists

You probably are dealing with an Abdicator if…

You probably are dealing with an Opportunist if…

■■

They strongly defer to you as the experts and expect you to supply all the initiative and answers.

Toughest Scenario ■■ It is difficult to engage them on a traditionally run project. Do ■■ Use their time efficiently. ■■ Tie their effort to high-risk avoidance. ■■ Tap into their concerns about regulatory compliance. Beware of ■■ Confusing them with the Opportunists; they are not very motivated by returns and cannot be persuaded to self-manage.

■■

They emphasize how smoothly past successes went and show pride in meeting expectations.

Toughest Scenario ■■ They are scared of risks when Applications does not have resources to pursue their opportunity. Do ■■ Address their specific fears, offering concrete steps you or they can take. ■■ Understand exactly what they expect from the solution. ■■ Address how self-management raises the odds of achieving specific objectives. Beware of ■■ Confusing them with the Abdicators; their reluctance comes from concerns about risk, not unwillingness to self-manage.

The Cowboys

The Entrepreneurs

You probably are dealing with a Cowboy if…

You probably are dealing with an Entrepreneur if…

■■

You do not know what they are doing. They talk evasively/vaguely about their initiatives.

Toughest Scenario ■■ They are putting the enterprise at risk and simply will not listen.

■■

They measure past success mostly by the size of the outcome.

Toughest Scenario ■■ They gamble with enterprise risks to chase high returns.

Do ■■ Find their key lieutenant and win him or her over. Try to win over the Cowboy’s team. ■■ If all else fails, govern. Go to a higher authority and explain what is at risk.

Do ■■ Amplify their perception of risks they have expressed concern about. ■■ Introduce new strategic risks to them, e.g., loss of customer information, direct financial loss, and brand impact. ■■ Connect risks concretely to not achieving the business case.

Beware of ■■ Confusing them with the Entrepreneur; their eagerness is fueled by a desire to control, and they will not listen to Applications.

Beware of ■■ Confusing them with the Cowboys; Entrepreneurs actually can be reasoned with and persuaded.


Understand Business Sponsors’ Temperaments Business Leader Discussion Guide

Decision Factors

Success Measures

Control

Framing Language

Discovery Questions

“I typically ask people four things to make sure we use our resources in the way they’ll most benefit from. One is to understand the background and experiences they’re bringing to the table. It’s likely a lot.”

■■

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

■■

■■ ■■ ■■ ■■

■■

■■ ■■ ■■

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

■■ ■■ ■■

■■

Risk

“Fourth, I need to understand in your own words what your perceptions of the risks here are. I want to know how we can best complement your skills and experiences here.”

■■ ■■ ■■ ■■

■■

What to Listen For

What is the greatest success so far in your career? How did that project come about for you? Why was it important to the company? What was the benefit to you? Was there a point during the project when the risks started to seem high to you?

You are trying to understand how they measure success and what motivates them to get involved. There is an opportunity here to get them to talk about how they’ve viewed or handled trade-offs in the past, in a subject area that is comfortable for them.

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.

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.

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.



135


136

Help Sponsors See Risk and Value Trade-Offs CareFusion’s Clarifying Risk and Value Trade-Offs Illustrative 1. Strategic Risk to the Company ■■ Loss of sensitive company information ■■ Brand or reputation damage ■■ Direct financial loss

Constraints of a Sample Solution

High

4. Effort ■■ IT and business fulltime equivalent required for implementation and maintenance ■■ Business subject matter expert time commitment ■■ Estimated amount of customization ■■ Estimated amount of integration

Low

High

High

Low

High

3. Risk to the Project ■■ Operational stability (e.g., downtime) ■■ Vendor financial stability ■■ Percentage of service-level agreements (SLAs) met ■■ Effectiveness of vendor disaster recovery plan Applications Executive Council® IT Practice www.aec.executiveboard.com © 2012 The Corporate Executive Board Company. All Rights Reserved. AEC2241712SYN

2. Business Outcome Attainment Risk ■■ Likelihood that key functionality is missing or fails to work as intended ■■ Sensitivity to schedule delays ■■ Sensitivity to budget overruns ■■ Risk to productivity or revenue improvements

Track Changing Business Priorities CareFusion’s Business Trends Insight Map Illustrative

Customer Data Management

Customer Data Management Supply Chain Management

Customer Data Management Strategic Sourcing

Research and Development

Customer Data Management Contract Management

Strategic Sourcing

Strategic Sourcing

Strategic Sourcing

Medical Devices

Finance


Strategic Sourcing Sales and Marketing

■■

■■

Consider an enterprise project. Assess the business case for standardization. Revise skills forecasts.

Customer Data Management Supply Chain Management


Potential Actions for Applications ■■

3. Experimentation with a Given Capability

2. Major Changes Within a Business Unit

1. Surge in a Capability’s Importance


Strategic Sourcing

Customer Data Management Customer Data Management

Contract Management

Strategic Sourcing

Strategic Sourcing

Strategic Sourcing

Medical Devices

Finance


Sales and Marketing


Revise SLAs for the business unit.

■■

Revisit investment levels.

■■

Supply Chain Management

Reassign staff to project and re-scope job descriptions.


Strategic Sourcing Sales and Marketing

Customer Data Management Customer Data Management

Contract Management

Strategic Sourcing

Strategic Sourcing

Medical Devices

Finance


■■

Investigate if there is an unarticulated need not addressed by existing solutions. Understand business drivers of experimentation.

Legend Experimentation with a business capability indicates its importance is rising.

Experimentation with a business capability indicates its importance is diminishing.

The direction of importance of experimentation with a business capability is uncertain.



137



138

Section 9: Design Team Relationship Management


Design Team Relationship Management

139


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 • 141 Rather than focus exclusively on collaboration tool offerings, Volvo applies NetAge’s framework to measure specific attributes of effective team behavior. When to Use To understand attributes of effective team behavior ■■ To effectively establish collaboration across team members ■■

Essential

Reference

Specialized

Standard & Poor’s Common Delivery Framework for Agile Development • 142 S&P’s framework standardizes governance, management, and engineering for stakeholder roles, processes, and artifacts. When to Use To synchronize dependencies between roles, processes, and artifacts on a distributed Agile team

■■

Essential


Reference

Specialized

Intergraph’s Agile Cultural Change Management • 143 Intergraph uses the pulse survey to understand each team’s reaction to the new methodology. When to Use To understand teams’ perception of change

■■

Essential

Reference

Specialized

Drive Team Collaboration and Engagement Volvo’s Virtual Team Effectiveness Assessment 1

3

5

Strongly Disagree

Somewhat Agree

Strongly Agree

Teams fall into one of four maturity levels based on their score:

Goals: How Aligned Is This Team’s Understanding of Goals, Actions, and Expected Results? Cooperative Goals

■■ ■■

Interdependent Tasks

■■ ■■

Concrete Results

■■ ■■

Everyone has the same picture of overall purpose. Team discusses, agrees, and reviews clear, simple goals.

–– Chaos (1–32)—No shared understanding of objectives or contributions of individual team members

Everyone follows the same process for doing similar work. Team looks for ways to interconnect and improve work processes. Everyone understands the deliverables. Team develops and reviews measures and milestones for deliverables.

–– Operational Consensus (33–54)—Focused on methods of work and timelines

Links: How Comfortable Is the Team with Communicating Internally? Multiple Media

■■ ■■

Boundary-Crossing Interactions

■■

Trusting Relationships

■■

■■

■■

A variety of media is available and accessible. Team uses collaboration tools consistently and creatively.

–– Team Alignment (55–87)—Development of team relationships to overcome organizational boundaries

Team has collaboratively established operating agreements that are actively applied. Team actively implements strategy for engagement across organization boundaries. Team has high level of trust. Team members build “social capital” through multiple connections.

–– Shared Accountability (88–120)—Shared leadership for achieving team objectives

Time: How Clear Are Project Timelines and Milestones? Common Calendar

■■ ■■

Interrelated Projects

■■ ■■

Awareness of Phase

■■ ■■

Team has clear milestones and schedules of dates. People are aware of ongoing key team dates and cultural calendar. Task timelines are collaboratively established. Team adapts to rapidly changing conditions. Team has clear view of its lifecycle and current phase. People discuss team processes and suggestions for improvements.

People: How Familiar Is the Team with Roles and Responsibilities? Independent Members

■■ ■■

Shared Leadership

■■ ■■

Integrated Levels

■■ ■■

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



141


DRIVE TEAM COLLABORATION AND ENGAGEMENT (CONTINUED) Standard & Poor’s Common Delivery Framework for Agile Development 1

Specifies expectations for governance and management: people, process, and documentation

GOVERNANCE Steering and Reporting OPPORTUNITY (Assessment)

■■ ■■ ■■ ■■

What is the business problem or opportunity?

Business Sponsor Project Proposer/Champion Tech Management Business Project Manager

MANAGEMENT Planning and Evaluation ■■ ■■ ■■ ■■

■■

Objective Get a project funded. ■■ Get a project scheduled.

■■ ■■

■■

■■ ■■ ■■

Opportunity Phase Summary Meeting Rapid Response Team Project Proposal Funding Memo Project Plan—Level 0 Opportunity Phase Summary/Sign-Off

■■ ■■ ■■ ■■ ■■ ■■ ■■

L

■■

H

■■

ENGINEERING Define, Build, and Test

Project Proposer Business Analyst Subject Matter Expert

■■

Architects—Enterprise, Application, Data, Data Services

Business Problem and Needs Analysis Perform High-Level Risk Analysis Scope Analysis Project Planning Begin RFP Process

■■

High-Level Technical Feasibility Analysis Level 0 Estimate (+/-200%)

■■ ■■ ■■

Vision—Initial Project Proposal

Vision—Initial Scope—High Level, Initial Project Proposal Risk Profile—Initial Request for Proposal (RFP) Timebox Synchronization Sprint

4

Defines the documentation options the team should be considering at each phase

Synchronization Planning

3


Synchronization Interface Specification

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

2

Ensures the business context will be captured and cascaded to all team members

142

DRIVE TEAM COLLABORATION AND ENGAGEMENT (CONTINUED) Intergraph’s Agile Cultural Change Management Agile Adoption Pulse Survey Much Better

Better

Same

Worse

Much Worse

Strongly Positive

Positive

Neutral

Negative

Strongly Negative

1. How would you rate how much the team accomplished in the past sprint? 2. How would you rate how well Scrum helps clarify the goals of what the team was supposed to deliver? 3. How would you rate your perception of how much business value your team produced in the past sprint? 4. How would you rate the quality and “fit for purpose” of what the team produced using the Scrum methods? 5. How would you rate the level of collaboration within the team? 6. How would you rate your perception of how much wasted/throwaway work happened in the sprint?

7. How would you rate your overall feelings about using Scrum? 8. How would you rate the training received for sprint planning? 9. How would you rate the usefulness of the sprint-planning sessions? 10. How would you rate the usefulness of the daily stand-up meetings? 11. How would you rate the usefulness of the sprint review sessions? 12. How would you rate the effectiveness of the sprint retrospective? 13. How do you feel about moving into a common room?

14. If the decision were solely up to you, would your team continue using Scrum?

Yes

No



143



144

Business Analyst Handbook.pdf

Recommend Documents