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 ITGoal
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+20021979
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
MemoryProducts
StorageSystems
StorageNetworks
InfoManagement
InfoSharing
InfoProtection
Services
Partnerships
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.
Include priority
ranking of each
Content / Data
Required & Refresh
Rates
What data is needed, and how often should it be refreshed?
What data needs to be converted?
Include priority
ranking of each
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.
• Business Vision
• As-Is, Target
Environments
• Approach and Options
Considered
• Variants - Solution
Options
• The Recommendation
• High Level Architecture
 Resource Plan
• 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 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 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
Resource Plan
A spreadsheet tool that lets you build out the staffing plan and
easily see the impact to project timeline and costs.

Preparing a Resource Plan
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
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
• Business Vision
• As-Is, Target Environments
• Approach and Options Considered
 Variants (Solution Options)
• Summary of Solutions with
Recommendation
• High Level Architecture
 Resource Plan
• 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.

Components of the
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.

Components of the
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]).
Resource Plan A spreadsheet tool that lets you build out the staffing plan and easily
see the impact to project timeline and costs.
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 ...

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

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

Similaire à Building the Case for New Technology Have Inspiration, Will Travel ... (20)

Plus de Society of Women Engineers

Plus de Society of Women Engineers (20)

Dernier

Dernier (20)

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