Building the Case for New Technology Have Inspiration, Will Travel ...

1 © Copyright 2012 EMC Corporation. All rights reserved.

Building the Case for New Technology Projects

… Invest … Innovate … and Inspire!!!

Phyllis Doig EMC Corporation Office of Architecture and Innovation WE12 Conference Presentation November 8th, 2012


Session Description

To build an effective business case for investing in new technology projects within IT Goal

The Solution Desk team will guide you through the business case delivery process. Process

Equip yourself with the tools to build a better business case! Tools

The benefits extend well beyond individual IT projects. Benefits


What is a Business Case?

Components of the Business Case Include: Problem Statement Business Vision Benefits and Measures of Success Summary of Solution Options, Recommendation Environment: As-Is, Target Financial Summary Resource Plan for IT Assumptions Timeline Overall Project Risks Next Steps

The EMC IT Business Case defines the benefits and costs of an IT project for the purpose of making a business investment decision


Agenda

About EMC and the Solution Desk

Our Guiding Principles

A Look Back: Pre-Solution Desk Example

A Look Ahead: Solution Desk Process & Tools

Continuous Improvement

Diversity of Experiences

Benefits


About EMC 53,500 Employees Worldwide

$20 Billion Revenue in 2011

400 Sales Offices

85 Countries

#152 within the

Fortune 500

Through innovative products and services EMC accelerates the journey to cloud computing helping IT departments to store, manage, protect and analyze their most valuable asset — information — in a more agile, trusted and cost-efficient way.


2012+ 2002 1979

About EMC

Innovation In Enterprise Storage Systems and Information Management

60+ Strategic Acquisitions

Authentica, Network Intelligence, RSA, Valyd, Tablus, Verid, Archer, Documentum, Ask Once,

Acartus, Captiva, ProActivity, Document Sciences, X-Hive, Kazeon, Vmware, Rainfinity,

Akimbi, FastScale, Dolphin, Interlink, Internosis, BusinessEdge, Geniant, Conchango, Astrum,

Smarts, nLayers, Voyence, Infra, ConfigureSoft, Legato, Avamar, Kashya, Illuminator, Indigo

Stone, WysDM, Data Domain, Pi, Dantz, Mozy, Iomega, Greenplum, Isilon, Netwitness ,

Watch4Net, Pivotal Labs, XtremIO, Syncplicity

Diversity Through Strategic

Acquisition

Mem

ory P

ro

du

cts

Sto

rag

e S

yste

ms

Sto

rag

e N

etw

orks

In

fo M

an

ag

em

en

t

In

fo S

harin

g

In

fo P

rote

cti

on

Servic

es

Partn

ersh

ips

Physical IT Infrastructure

Cloud Technology

Virtual IT Infrastructure

Solutions Provider

1 2

3


About the Solution Desk

The Solution Desk is a global team within IT whose charter is to provide to the business case delivery process:

• Speed

• Objectivity

• Consistency

• Multiple IT Technology Options

Typical Projects That We Estimate:

• Business-sponsored IT initiatives • Fast estimation cycle • Within +/- 30% • Involves multiple options to evaluate

Solution Desk Involvement By Type of Initiative:

• Mission Critical 23 Infrequent • Business Critical 346 Most Often • Business Supporting 000’s Occasional


The Importance of Guiding Principles

The Guiding Principles of IT

• Efficiency

• Total Customer Experience

• Architect for the Future

• Workforce Productivity

• EMC IT Proven – Being Our Own Best Customer

… can help to:

• guide investment decisions

• shape IT technology roadmaps

• bring groups with similar objectives to the table for discussion


A Look Back: Business Case Preparation Before Solution Desk

Example: To facilitate business reporting by introducing a new database and reporting tool and by eliminating many business-maintained systems


Experienced Team to Guide Others

New Virtual Team for Each Initiative

Standard Templates, Constantly Being Honed

Sharing Knowledge Across Business Units

Repeatable Process

Now

✗High Learning Curve

✗Resource Constraints

✗Few Standard Tools or Templates

✗Little Cross-Pollination

✗Unique Process Per Initiative

Then

A Look Back A Look Ahead


The Solution Desk Process


Key Takeaways of the Solution Desk Process

Consistent, Repeatable – Firm Criteria for Standard or Extended

– Even ―Exceptions‖ follow a consistent process: engaging vendors for demos, initiating POC’s (Proof of Concept)

Time Limited

Deliverable Focused

Involves a Cross-Functional, ―Virtual‖ Team


Common Tools Used by the Solution Desk

Input Presentation

Requirements Sheet

Output Presentation

Solution Variants

Resource Plan

Financial Summary


Introduction to the Input Presentation

The Input Presentation is a standardized template that is used for gathering and communicating the high level business requirements for a new IT proposal.

• Problem Statement

• Business Vision

• Benefits & Measures of Success

• As-Is, Target Environments

Business Requirements – Functionality / Processes

– Integration Points

– Content / Data Required & Refresh Rates

– Geography and Scale

– User Profile

• Overall Project Risks

• Application & Security Classification

• Groups Contacted in This Initiative

• Solution Options Being Considered

• Next Steps


Challenges

Don’t know where to start

Too many / too few

Incomplete in scope; not organized in a useful way

Not described well

Favor the way things are done today

Considerations

Industry Research (Gartner, Forrester…) & Company Product

Data Sheets

Match level of detail with your level of estimate (ROM = Rough

Order of Magnitude)

Develop templates as you gain experience, by type of project

Avoid acronyms

Be open to new approaches

Preparing Business Requirements for the Input Presentation


Sample Requirements Template

Business Application Requirements

Transactional

• Create, alter, reverse the transaction • Import & export capability • Archiving

Data Entities

• Create, alter, delete master data • Maintain hierarchies, categorizations • Conversion capability

Inquiry & Reporting

• Inquiry and search • Report – ad hoc, standard, dashboard

level

User Security & Access

• User setup & classification • Access Control Levels, Security • Methods of Access (ex. Mobile Devices) • Collaboration Features • Language, Geo Considerations • Organization, Hierarchy, Approvals

… continued

Implementation Considerations

• Scalability for future growth • Integrations with existing systems; availability

for dev, test, other environments • Staging of data (dev, test, production) • Conversion of History • Exiting (if SaaS or Cloud – how to get out)

Architecture

• Specific to the Project… • Consider all levels of the technology stack • Consider localizations, language • Consider industry volatility & future needs

Product & Vendor

• Product Lifecycle (Stability, Maturity) • Pricing (Purchase, Services, Support) • Customer References, Awards • Company Relationship to Yours • Availability, Access to Development • Availability, Access to Support


Capturing Requirements of All Types Beyond functional capabilities, consider additional requirements including the following:

Requirement Type Description Comments

Functional Requirements

Describes user or system generated capabilities to perform an action.

Include priority ranking of each

Integration Points Lists to/from integrations and a one-sentence description of the information flowing between them.


Content / Data Required & Refresh Rates

What data is needed, and how often should it be refreshed? What data needs to be converted?


Geography and Scale

Note the geographical or business unit entities that will be affected by this initiative; provide some quantification / count of the transactions that they perform (for system sizing).

Include priority ranking; this will determine rollout strategy.

User Profile Note the type and number of users including count.

Include priority ranking; this will determine rollout strategy.


Key Takeaways When Preparing Requirements

Requirements should be comprehensive in scope; establish a template to ensure completeness

Reflects the needs of all involved parties – Business Users of the New System

– ―Super Users‖

– Administrators

– Support, Security, Infrastructure

– External Customers

Can be used to rate the solution options or vendors being considered (on features and cost)


Introduction to the Output Presentation

The Output Presentation is a standardized template that is used for documenting solution options, costing them out, and making a recommendation.

• Problem Statement

• Business Vision

• As-Is, Target Environments

• Approach and Options Considered

• Variants - Solution Options

• The Recommendation

• High Level Architecture

Resource Plan

Financial Summary

• Assumptions & Factors Increasing Cost, Time, Resources

• Project Risks

• Next Steps


Business Application Requirements Vendor 1 Vendor 2 Vendor 3

Transactional

•Create, alter, reverse the transaction 3 Comments… 3 Comments… 2 Comments…

•Inquiry & reporting capability 3 Comments… 3 Comments… 2 Comments…

•Import & export capability 2 Comments… 3 Comments… 2 Comments…

•Archiving 2 Comments… 3 Comments… 2 Comments…

Data Entities

•Create, alter, delete master data 3 Comments… 3 Comments… 2 Comments…

•Maintain hierarchies, categorizations 2 Comments… 2 Comments… 2 Comments…


•Conversion capability 2 Comments… 3 Comments… 1 Comments…

User Security & Access

•User setup & classification 3 Comments… 3 Comments… 3 Comments…

•Access Control Levels, Security 3 Comments… 3 Comments… 3 Comments…

•Methods of Access (ex. Mobile Devices) 1 Comments… 2 Comments… 1 Comments…

•Collaboration Features 1 Comments… 2 Comments… 1 Comments…

•Language, Geo Considerations 3 Comments… 3 Comments… 1 Comments…

[... and more not shown here…]

SCORE: 29 36 25

Variants Analysis A side-by-side comparison of solution options, and how well they are expected to meet the stated requirements


Business Application Requirements Vendor 1 Vendor 2 Vendor 3 Transactional

•Create, alter, reverse the transaction 3 Comments… 3 Comments… 2 Comments…


•Import & export capability 2 Comments… 3 Comments… 2 Comments…

•Archiving 2 Comments… 3 Comments… 2 Comments…

Data Entities •Create, alter, delete master data 3 Comments… 3 Comments… 2 Comments…

•Maintain hierarchies, categorizations 2 Comments… 2 Comments… 2 Comments…


•Conversion capability 2 Comments… 3 Comments… 1 Comments…

User Security & Access •User setup & classification 3 Comments… 3 Comments… 3 Comments…

•Access Control Levels, Security 3 Comments… 3 Comments… 3 Comments…

•Methods of Access (ex. Mobile Devices) 1 Comments… 2 Comments… 1 Comments…

•Collaboration Features 1 Comments… 2 Comments… 1 Comments…

•Language, Geo Considerations 3 Comments… 3 Comments… 1 Comments…

[... and more not shown here…] SCORE: 29 36 25

(1) Start With

The Original Requirements

(2) Use Color Coding To Quickly See Where Requirements Are /

Are Not Being Met

(3) Calculate Total Scores For Objective Results

Variants Analysis A side-by-side comparison of solution options, and how well they meet the stated requirements.


Preparing Solution Variants Analysis for the Output Presentation

Considerations

Use your requirements template as a basis for variants analysis

Have a visual coding to help you see the hot spots (ex. Green-Yellow-Red

ratings)

Tabulate an objective score, but

also listen to the subjective voice

Keep it simple! Be able to state:

- top 3 good features - top 3 areas of concern


Resource Plan Onshore/ Offshore

Staff or Contractor M1 M2 M3 M4 M5 M6 Rate

Total K$

Description of Responsibilities

Management

•Project Manager On Staff 0.5 0.5 0.5 0.5 0.5 0.5 160 84 Describe…

•Functional Team Lead On Staff 1 1 1 1 1 1 100 106 Describe…

•Configuration Lead On Staff 0.5 1 1 100 44 Describe…

•Development Manager Off Contractor 0.5 1 1 1 1 15 12 Describe…

•Environment Manager On Contractor 0.5 0.5 0.5 0.5 0.5 0.5 100 53 Describe…

Business Analysts

•Senior BA On Contractor 1 1 1 1 1 1 90 95 Describe…

•BA for Functional Area 1 Off Contractor 1 1 1 1 1 1 8 8 Describe…


Development Team

•DEV Senior for Technology Area 1 On Contractor 0.5 1 1 1 1 90 71 Describe…

•DEV for Technology Area 1 Off Contractor 1 1 1 6 3 Describe…


•DEV for Technology Area 2 Off Contractor 1 1 6 2 Describe…

Testing Staff

•Test Lead On Staff 0.5 1 1 0.5 80 42 Describe…

•Testers… Off Contractor 0.5 1 1 0.5 8 4 Describe…

Architects

•Infrastructure, Security…. (Multiple) (Multiple) 0.5 0.5 0.5 (Mult) (Mult) Describe…

TOTALS: 5.5 8 11.5 12.5 12 9 $

618

Resource Plan A spreadsheet tool that lets you build out the staffing plan and easily see the impact to project timeline and costs.


Resource Plan Onshore / Offshore

Staff or Contractor M1 M2 M3 M4 M5 M6 Rate

Total K$

Description of Responsibilities

Management

•Project Manager On Staff 0.5 0.5 0.5 0.5 0.5 0.5 160 84 Describe…

•Functional Team Lead On Staff 1 1 1 1 1 1 100 106 Describe…

•Configuration Lead On Staff 0.5 1 1 100 44 Describe…

•Development Manager Off Contractor 0.5 1 1 1 1 15 12 Describe…

•Environment Manager On Contractor 0.5 0.5 0.5 0.5 0.5 0.5 100 53 Describe…

Business Analysts

•Senior BA On Contractor 1 1 1 1 1 1 90 95 Describe…



Development Team


•DEV for Technology Area 1 Off Contractor 1 1 1 6 3 Describe…


•DEV for Technology Area 2 Off Contractor 1 1 6 2 Describe…

Testing Staff

•Test Lead On Staff 0.5 1 1 0.5 80 42 Describe…

•Testers… Off Contractor 0.5 1 1 0.5 8 4 Describe…

Architects

•Infrastructure, Security…. (Multiple) (Multiple) 0.5 0.5 0.5 (Mult) (Mult) Describe…

TOTALS: 5.5 8 11.5 12.5 12 9 $

618

(1) Start With Core Dev Team;

Layer On The Rest

(2) Document Responsibilities &

Assumptions

(3) Change Sourcing

Assumptions & Note the Impact to

Total Cost



Preparing a Resource Plan for the Output Presentation

Considerations

Start with core development, and estimate the effort for Tech Design / Build / Unit Test. Have a rationale behind the determination of person-hours, but remember this is a ―ROM‖! —Rough Order of Magnitude

Build out the rest of the plan:

• Business Analysts for Functional Design, Training, and User Acceptance Testing

• Testers for Integration, End-to-End, Performance Testing

• Management and Leads, Architects, Security, Others…

Keep comments on what those resources will be expected to do.

Document assumptions as you discuss the plan with others.

Change sourcing (on/offshore, contracted) to see overall cost impact (―what if‖analysis).


Financial Template A spreadsheet tool that captures the financial details of your solution options, and identifies key budgeting metrics.


Financial Summary Be able to summarize the cost in a meaningful way, in order to identify the key cost drivers and points for negotiation.


Preparing a Financial Summary for the Output Presentation

Considerations

Have a tool or a systematic method to capture financial details for your solution options, including:

– Staffing Costs (In-House and Contracted)

– Hardware, Software / Licenses, and Maintenance

– Travel, Training, Contingency

– Capital & Expense, Depreciation, Year-over-Year Budget Breakouts

Identify ―Build‖ (Yr 0) and ―Run Support‖ (Yrs 1+) costs and resources.

Be able to translate the results into a common-sense summary


Key Takeaways from the Output

• Problem Statement • Business Vision • As-Is, Target Environments • Approach and Options Considered Variants (Solution Options) • Summary of Solutions with

Recommendation • High Level Architecture Resource Plan Financial Summary • Key Assumptions and Factors

Increasing Costs • Overall Project Risks • Next Steps

• Tool should easily show cost, timing of each resource

• Allow changes --―What If‖-ing

• Document Roles, Deliverables, and Assumptions

• Easily track elements impacting cost

• Identify both build and run costs

• Have a common sense summary

• How well are requirements being met?

• Develop scoring (numeric, visual)

• Have an ―elevator pitch‖ summary


Continuous Improvement & Innovation

The Solution Desk is

Constantly Updating Its Processes

Leading to innovative new tools and techniques including:

• Confidence Scorecard for Project Estimations

• Process Checklists to Guide Virtual Team Members

• Metrics Tracking Tools


Diversity Leading to Inspiration

The Solution Desk accepts IT projects from any department, any business unit, any region.

The diversity of experience helps us to find commonalities and drive efficiencies:

Examples include:

• Consolidation of individual projects into a single program to reduce the number of business-managed IT systems

• Using a single framework for all New Product Introductions


Benefits of the Solution Desk

Core Competency in Developing the Business Case

Faster Estimates

Consistent Format

Efficiencies Across Business Groups

Building a Case History


Thank You


Appendix


Components of the Input Presentation (1)

Problem Statement

A problem can be described in terms of a process or an output (physical or informational) that is different from the desired state; this implies that the desired state (a process or an output) can be described along with an explicit context. For the impact, include who or what is experiencing the problem, when the problem occurs, how it manifests itself, where (business units, locations, systems) it occurs, and why. Given this context, state the impact to time, cost, resources, &etc.

Business Vision Describe how the business will change in the future as a result of this project in terms of additional capabilities, performance or effectiveness.

Benefits & Measures of Success

• Strategic Benefits are associated with supporting overall corporate strategy (at CEO or CEO Staff), or achieving mandatory regulatory compliance.

• Hard Benefits are quantifiable and the business unit commits to reduce spend or increase margin in future budgets. Hard Benefits should be expressed in dollars.

Soft Benefits are qualitative (i.e. improved decision making, greater process efficiency, increased visibility, or improved morale) or they are quantifiable and the business unit cannot commit to reduce spend or increase margin in future budgets

• Metrics: For each of the above, identify metrics to determine that benefits were achieved and recognized.

As-Is, To-Be Use Process Flows or Design Diagrams to illustrate As-Is and Target (To-Be) processes, systems, people, and how they interact today vs in the future.



Requirements: (1) Functional

Typical initiatives for a single item may have 10-20 high level requirements; initiatives involving multiple applications, databases, business groups may have 20-50 high level requirements. More detailed requirements lists can be put into the appendix if they are available and may influence the solution options that will be investigated. Include priority rankings.

• High level example: the ability to create invoices. • Detailed example: the ability to create specific kinds of invoices (list them)

with particular data requirements (identify) for certain conditions (describe).

(2) Integration Points

Consider source and destination applications, databases, or infrastructure elements. Provide specific application, interface, database, or object name where possible.

(3) Content/ Data • List master data entities that will need to be created / maintained to support the initiative.

• Consider transactional data that needs to be passed from one system to another. • Identify approximate volumes for each, frequency of refresh. • Consider conversion volumes and amount of history needed.

(4) Geography • Consider countries, regions, business units, operating units which may utilize your application, reporting system or infrastructure elements.

• Business analysts may use this information to prepare a high-level rollout strategy (especially if using a phased approach), to consider geo-specific requirements (language, regulatory, localization issues for example), and to investigate pre-existing or future-planned overlapping solutions.

• Solution architects may use this information to evaluate language implications, performance-over-a-distance implications, and globalization or localization issues.



Requirements: (5) User

• Identify the types of users to ensure that the correct capabilities and constraints can be designed. Ex – standard users, ―super users‖, restricted or inquiry-only users, executives, administrators, external parties.

• Describe how this basic profile may vary by business unit or geography. • Include counts of users and priority for rollout, if you create a phased rollout strategy. • This information will provide business and security analysts with information needed to

properly configure the system for usage; it will also provide solution architects with information needed to design for performance and for security/access.

• You might consider adding a column for ―geography‖ or ―business unit‖ or other criteria if this affects your rollout strategy – i.e. a combination of user role and one of these factors.

Overall Project Risks

• For the input document, overall project risks typically impact scope, timeline, budget, resources.

• For the output document, risks may be based on more specific functionality or capabilities.

Application & Security Classification

A standardized questionnaire which drives the application support level and security treatment. For example, will the solution be mission critical and require 24x7 support? If so, this will impact run rate cost projections, to ensure that you have the staffing required to provide that level of support.

Groups Contacted Identify all business teams that need to be consulted when assessing the ―as is‖ situation and documenting requirements. Identify all technology teams that need to be consulted when determining solution options, estimates, architecture, security, infrastructure and support.

Solution Options Being Considered

• Describe each candidate solution being considered, advantages, disadvantages.

Next Steps Identify all of the working sessions that your team will need to get to output.


Components of the Output Presentation (1)

Problem Statement, Business Vision, As-Is & To-Be

(Repeated from the Input Presentation)

Approach & Options Considered

Describe the process that the team used in order to identify and assess any options that were considered for output.

Variants – Solution Options

A side-by-side comparison of solution options, showing how well they meet the stated requirements.

Summary of Solutions & Recommendation

A list of solution options which provides their description, costs and key financial metrics, and a list of their advantages and disadvantages.

High Level Architecture A diagram illustrating all components of the IT technology stack as needed for the solution. Security/access elements are addressed as well. Each environment is represented (Development, Test, Production, DR [Disaster Recovery]).


Financial Summary A spreadsheet tool that captures the financial details of your solution options, and identifies key budgeting metrics.


Components of the Output Presentation (2)

Project Risks We begin with risks identified at input (which may impact scope, timeframe, resources, cost) and add solution-specific risks that were uncovered during the output working sessions. For each risk we provide the following: (1) ―Risk Impact‖ Score (which is a measure of a potential cost increase, time increase, scope change, or quality degradation) (2) Realization Probability Score (which indicates the likelihood of realization) (3) Response (to Accept, Mitigate, Transfer, or Avoid) (4) Response Plan and Plan Owner

Next Steps Beyond output, these are the steps needed to secure approval by the architectural review board and ultimately the business sponsors.


Learning Objectives for SWE 2012

How to document requirements for technology initiatives in a consistent and comprehensive manner, making it easier to evaluate solution options.

How to prepare resource and financial plans, and express the results in a clear and understandable manner.

How continuous process improvement leads to innovation within your own team and also extends to the teams you work with.

Creating a culture of inspiration when working with diverse teams and technologies.

Building the Case for New Technology Have Inspiration, Will Travel ...

Engineering

Transcript of Building the Case for New Technology Have Inspiration, Will Travel ...