The Software Deployment Mystery - Solved! A Customer Guide by IBM

Front cover
The Software Deployment

Mystery - Solved!
d!
A Customer Guide
Reveals best practices and methods

proven to drive deployment success
Offers actual customer

experience as a guide
Helps make the most of your

relationship with IBM
Bill Bierds
Jeremy Gibson
Sandor Hasznos David Backman
Carolyn Hungate Mike Ransom
Calvin Lawrence Reid Byers
Fernando Zuliani Charles P. Brown
ibm.com/redbooks
International Technical Support Organization
The Software Deployment Mystery - Solved!

A Customer Guide
February 2004
SG24-6070-01
Note: Before using this information and the product it supports, read the information in
Notices on page ix.
Second Edition (February 2004)
This edition applies to the IBM Software Group Software Deployment Method.
Copyright International Business Machines Corporation 2003, 2004. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Chapter 1. Why focus on software deployment? . . . . . . . . . . . . . . . . . . . . . 1

1.1 What makes software deployment so difficult? . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Why have a Software Deployment Method? . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 The Software Deployment Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 The Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Phase 1: Prepare for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Phase 2: Refine and promote the plan . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Phase 3: Deploy software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.4 Software deployment method: A continuous process . . . . . . . . . . . . . 7
1.5 Software deployment best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 The readiness plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Solution Assurance Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Software solution work products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9 Software deployment: A two-way street . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2. Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Internal team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Enterprise Business Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Stakeholders, sponsors, and project leads . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Global Project Lead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Team IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 IBM Software Sales Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 IBM Software Account Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 IBM Software Sales Specialist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 IBM Software Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4 IBM Software Deployment Architect . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5 IBM Software Technical Sales Specialist . . . . . . . . . . . . . . . . . . . . . 19
2.4 IBM Client Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 IBM Client Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.2 IBM Client Representative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 IBM Client IT Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Copyright IBM Corp. 2003, 2004. All rights reserved. iii

Chapter 3. Software deployment best practices . . . . . . . . . . . . . . . . . . . . 21
3.1 Identify an Enterprise Business Sponsor and stakeholders . . . . . . . . . . . 23
3.2 Centralize software fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Implement a license management tool and process . . . . . . . . . . . . . . . . . 25
3.4 Hire deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Determine your deployment readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Commit to self-sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Define a time-to-value and ROI strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Communicate and market the vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 4. Value realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Value statement and value timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 The buying decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Return on investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Hard (tangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 Soft (intangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3 Realizing value with hard and soft ROI . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.4 ROI must support the business strategy . . . . . . . . . . . . . . . . . . . . . . 35
4.3.5 An approach to analyzing ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.6 When business goals are met, everyone wins . . . . . . . . . . . . . . . . . 36
4.3.7 Example ROI: Current value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Chapter 5. Software deployment Phase 1: Prepare for deployment . . . . 39

5.1 Step 1: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . 40
5.1.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Step 2: Review the deployment documentation . . . . . . . . . . . . . . . . . . . . 42
5.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.4 Documentation review tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Step 3: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 45
5.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Step 4: Establish the deployment partnership. . . . . . . . . . . . . . . . . . . . . . 47
5.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Chapter 6. Software deployment Phase 2: Refine and promote the plan 49

6.1 Step 5: Refine the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
iv The Software Deployment Mystery - Solved!

6.1.2 Inputs, tasks and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Step 6: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Step 7: Conduct the initial deployment kickoff meeting. . . . . . . . . . . . . . . 54
6.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Chapter 7. Software deployment Phase 3: Deploy software . . . . . . . . . . . 57

7.1 Step 8: Achieve the quick deployment wins . . . . . . . . . . . . . . . . . . . . . . . 58
7.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2 Step 9: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.3 Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3 Step 10: Identify new business needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4 Step 11: Update the business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 8. Managing software deployment projects . . . . . . . . . . . . . . . . . 65

8.1 Project timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3 Managing the success of your first project . . . . . . . . . . . . . . . . . . . . . . . . 68
8.3.1 Managing at the milestone level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.3.2 Handling project management challenges . . . . . . . . . . . . . . . . . . . . 69
Chapter 9. Managing global software deployment projects . . . . . . . . . . . 71

9.1 How the coverage model works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.2 Global deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.2.1 Global level activities (primary, full-time coverage) . . . . . . . . . . . . . . 74
9.2.2 Local sites (secondary, part-time coverage) . . . . . . . . . . . . . . . . . . . 75
9.2.3 Local sites (tertiary, on-demand coverage). . . . . . . . . . . . . . . . . . . . 76
9.3 More about the global deployment activities . . . . . . . . . . . . . . . . . . . . . . . 76
9.4 A global deployment coverage example . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Contents v
Chapter 10. Software deployment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10.1 License management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.1.1 Taking control of software licenses . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1.2 IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.2 Communication tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.2.1 Instant messaging, Web conferencing, and team workplaces . . . . 82
10.2.2 Easy Access Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.3 Self-help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.3.1 Problem management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.3.2 License acquisition and entitlement with Passport Advantage . . . . 84
10.3.3 Software maintenance via Passport Advantage . . . . . . . . . . . . . . . 84
10.4 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
10.5 Deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Appendix A. Software solution work products. . . . . . . . . . . . . . . . . . . . . . 87

Work products used by SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Work product examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Architecture decisions document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Business context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Component model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Component flow model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Current IT environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Current business organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Envisioned goals and issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Current IT standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Mapping business initiatives to projects . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Mapping projects to proposed products and solutions . . . . . . . . . . . . . . . 111
Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Project description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
System context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Systems context diagrams for an integration architecture . . . . . . . . . . . . 117
Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Viability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Appendix B. Software deployment checklist . . . . . . . . . . . . . . . . . . . . . . 123

Software deployment steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Phase 1: Prepare for deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Step 1: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . 124
Step 2: Review the contract content and critical deployment documents . 125
Step 3: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 126
Step 4: Establish a deployment partnership . . . . . . . . . . . . . . . . . . . . . . . 127
vi The Software Deployment Mystery - Solved!

Phase 2: Refine and promote the plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Step 5: Refine the high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 127
Step 6: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Step 7: Conduct deployment kickoff meetings . . . . . . . . . . . . . . . . . . . . . 129
Phase 3: Deploy software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Step 8: Achieve quick deployment wins . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Step 9: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Step 10: Identify new business needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Step 11: Update the business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Appendix C. Global software deployment checklist . . . . . . . . . . . . . . . . 133

Global-level activities executed by global deployment lead . . . . . . . . . . . . . . 134
Local sites (secondary part-time coverage) . . . . . . . . . . . . . . . . . . . . . . . . . 136
Local sites (tertiary on demand coverage) . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Contents vii
viii The Software Deployment Mystery - Solved!
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
Copyright IBM Corp. 2003, 2004. All rights reserved. ix

Trademarks
The following terms are trademarks of the International Business Machines Corporation and the Rational
Software Corporation, in the United States, other countries, or both:
ibm.com RS/6000
Approach IMS RUP
AIX LearningSpace S/390
APL2 Lotus SmartSuite
CICS/ESA MQSeries SP1
CICS MVS Tivoli
Database 2 OS/2 TME
DB2 Universal Database OS/390 VisualAge
DB2 Passport Advantage WebSphere
GDDM Rational Unified Process zSeries
ImagePlus Rational 1-2-3
Informix Redbooks (logo)
IBM Redbooks
The following terms are trademarks of other companies:
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure
Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
x The Software Deployment Mystery - Solved!

Preface
To solve any mystery, detectives rely on their experience along with proven tools
and techniques to unravel the conundrum. This IBM Redbook addresses the
often illusive mystery known as software deployment success. The information,
practices, and methods presented in this book have enabled many IBM
customers to achieve their business and Information Technology (IT) goals more
quickly and efficiently. IBM has accumulated a wealth of knowledge and
experience in software deployment. The technologies we have developed, the
best practices we have authored, and the employees we have cultivated are our
greatest assets. Like a detective explaining how the mystery was solved, we use
this redbook to pass on to you our customers the experience, knowledge, and
wisdom we have accumulated after years of solving software deployment
mysteries.
The primary audience for this redbook is the person who has ultimate ownership
for software deployment performance. We refer to this person as the Enterprise
Business Sponsor (EBS). Secondary audiences include anyone who is engaged
in software deployment activities. Both audiences benefit from the practices and
procedures described.
This redbook refers to a core team known as the Software Deployment Team
(SDT). This team consists of representatives from both your company and the
software vendor. The mission of the SDT is to maintain ongoing and clear
communication between you and your vendor. Chapter 2, Roles and
responsibilities on page 13, describes in detail the SDT and the concept of
partnership.
The best practices, presented in Chapter 3, Software deployment best

practices on page 21, were developed after years of studying deployment
challenges and their root causes. Where possible, we encourage you and all of
our customers to follow them.
When we refer to success in this redbook, we are talking about holistic

success. It is important to recognize that, while independent achievements are
important, holistic success can only be recognized when software is deployed
and is executing as envisioned. For that reason, we include the discussion in
Chapter 4, Value realization on page 31. This chapter focuses on calculating
value and discusses the concepts of return on investment (ROI) and rate of
return (ROR). It also drills down into creative ways you can measure value such
as hard ROI and soft ROI.
Copyright IBM Corp. 2003, 2004. All rights reserved. xi

The premise of this book is that a proactive and disciplined deployment approach
is required to get the expected business value from any purchase of software.
The method described in Chapters 5 through 7 is called the Software
Deployment Method (SDM). The SDM is not the only process that you can use to
deploy software, but it is an example of a repeatable process that has proven
successful time and time again.
Chapter 8, Managing software deployment projects on page 65, provides hints

and tips for managing large-scale deployment projects. Chapter 9, Managing
global software deployment projects on page 71, helps you manage deployment
on a global scale. And Chapter 10, Software deployment tools on page 79,
describes tools and services that can help make software deployment more
systemic and easier to manage.
Throughout this book, you see testimonials, quotes, and success stories
submitted by customers who have leveraged all or part of the deployment
practices described. One of our customers, a major U.S.-based retailer who we
refer to often throughout the book, not only follows the methods that are
described, but they also use them as a source for their own customized
deployment guidebook. For confidentiality reasons, we refer to this customer as
GMR Corporation or GMR.
During the life cycle of deployment, IBM will always be there to assist you, but it is
our goal that you become self-sufficient. This involves building a team of highly
skilled subject matter experts who can craft solutions that drive deployments that
achieve your business and IT goals. Software deployment is a two-way street
between you and your software vendor. We hope that the information presented
in this book helps you maximize deployment success and value realization.
Note: For the purposes of this redbook, we have used IBM as the vendor. The
tools, techniques, and methods presented herein are applicable to any vendor
with whom you deploy software.
The team that wrote this redbook

This redbook was produced by a team of specialists at the request of Lauren
States (Vice President, Technical Sales and Deployment, IBM Software Group
(SWG)) and Kim Waddell (Director ELA Deployment, SWG) to Maggie Blayney
(Director of the ITSO).
Bill Bierds, WW SWG - Software Deployment Chief Strategist
Jeremy Gibson, Program Manager, Deployment Strategies
David Backman, Senior Certified IT Architect
xii The Software Deployment Mystery - Solved!

Mike Ransom, ITSO Project Leader
Reid S. Byers, Software IT Architect
Thanks to Nestl Corporation, Francisco Esteve (Nestl Globe Project Leader),

and Fredy Schoch (IBM Software Architect at Nestl) for allowing their software
deployment experiences to be included in this redbook.
We appreciate the contributions, guidance, and direction provided by the IBM

SWG Technical Leadership Council. Members of that council are:
David Backman
Senior Certified IT Architect
Charles P. Brown
Senior Certified IT Specialist
Sandor Hasznos
Certified IT Architect
Carolyn Hungate
Ease-of-Use Architect/Designer
Calvin Lawrence
Certified IT Architect
Fernando Zuliani
Certified Senior Consulting IT Specialist
The contributions of following individuals from IBM are also appreciated:

Mohammed Ajab
Software Deployment Architect
John Barker
Pete Bouchard
Senior Certified IT Architect
Tom Carr
Certified Project Manager, Software Deployment Architect
Rob Coventry
Technical Sales Manager, Central Region Architects
Nicki Cowley
ELA Competency Center Specialist
Paul Edwards
PMP, Certified Project Manager, Software Deployment Architect
Kathy Hofstrom
Business Unit Executive, Technical Sales, Central Region, IBM Americas
Preface xiii
Kathleen OLeary
Program Manager
Mac Pogue
Certified Project Manager, Software Deployment Architect
Jennifer Ramirez
Lauren States
VP Technical Sales and Deployment
Beverly Vandahl
Program Manager - ELA Deployment
Kim Waddell
Director ELA Deployment
William Welch
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
xiv The Software Deployment Mystery - Solved!

Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Send us your comments

about this or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JLU Building 107-2
3605 Highway 52N
Rochester, Minnesota 55901-7829
Preface xv
xvi The Software Deployment Mystery - Solved!
1
Chapter 1. Why focus on software

deployment?
Customer example: GMR Corporation (GMR) is a growth company focused

on a wide range of merchandise retailing. Their operating strategy is to provide
the highest value to consumers through multiple store formats. In the most
current fiscal year, GMR Corporation reported revenue over $40 billion U.S.
In December 2002, GMR made an enterprise-wide purchase of software from

IBM. Early in the deployment, they recognized the need for a structured
method to deploy their software and they turned to IBM for assistance.
Throughout this book, we refer to GMR and other customers who leveraged
various aspects of this book (that is, the Software Deployment Method (SDM))
and as a result, achieved greater success and improved return on investment
(ROI).
Software deployment is defined as the process of putting software and software

solutions into use or action and ultimately driving business success.
The extensive experience of IBM in deploying software has revealed that many of
our customers do not recognize the level of commitment that is required from
them to achieve software deployment success. Also, some customers are not
taking steps that are necessary to achieve business value. Consider these
examples:
Copyright IBM Corp. 2003, 2004. All rights reserved. 1

A deployment strategy is not mapped out, early projects are not identified,
and the scope and schedule of software implementation are not considered.
A transition plan from the purchasing team to the implementation team does
not clearly articulate expectations, roles, and responsibilities.
Identified deployment projects do not finish on time. Software deployment is
inherently complex and involves multiple components or organizations.
Therefore, reactive project management results in delayed implementation
due to challenges that arise late in the deployment process.
Successful solutions and the deployment processes are not leveraged across
the broader enterprise. The customer and IBM organizations are tasked with
a single implementation. Therefore, they do not focus on leveraging the
lessons, experiences, and investment from this single need across the
broader environment.
The lack of focus in these areas has resulted in less than optimal return from a
software purchase. It has also spawned situations where multiple projects are
run in parallel with inadequate infrastructure or mechanics to leverage common
components, tasks, resources, lessons, etc.
These experiences suggest that successful software deployment does not just
happen. It requires proactive focus and attention from both you and IBM in the
following areas:
Understanding and qualifying the initial demand (projects)
Identifying the core team, with individuals from IBM and your company, that
will coordinate the overall software deployment process
Developing a deployment strategy that will achieve the defined business goals
Continually defining new projects that will help you overcome new challenges
To address these needs, this redbook and the Software Deployment Method
described within were established.
1.1 What makes software deployment so difficult?

Regardless of the size or scale of the software deployment, you must address
several challenges to its success:
Separation of the negotiation team from the implementation team. Ideally, key
members of the implementation team and key stakeholders participate in the
development and negotiation of any agreement. This begins the sense of
ownership and ensures that the business goals drive the product selection
process. If these teams are separate, a complete transition is key. Roles and
responsibilities must be crisply defined, assumptions clarified, and
2 The Software Deployment Mystery - Solved!

expectations documented. It is too easy for early projects to falter or become
delayed as teams try to collect information and direction from the negotiation
process after the fact.
When an agreement is closed, all projects may not be concretely defined to
maximize software utilization. Because of this, additional projects must be
identified to put the purchased software to use. In addition, new or changing
business needs will arise and must be responded to throughout the
deployment cycle.
Often times, the person or persons who will own software deployment from
your organization are not identified or may be out of the loop during project
identification and product selection. Therefore, there may be members of your
team who are integral to the deployment process and are unaware of the
products that were purchased and what business challenges the agreement
was crafted to solve.
Some organizations or individuals may be opposed to the vendor or the
products purchased. This can potentially undermine the success of one or
more projects.
The deployment of software sold can cross a wide range of departments,
lines of businesses, and multiple contacts that may or may not have been
included in the selling or negotiation phases of the agreement. Therefore, it is
not uncommon for the IBM team to call on individuals who may not be fully
aware of your overall corporate Information Technology (IT) strategy. This can
create challenges during the deployment phase. That is to maximize
deployment performance, the entire IT organization must be aligned behind
one mission, regardless of how tactical the individual needs may be.
It is not uncommon for software to remain unused for long periods of time
during the term of the agreement. Recognizing this situation early and putting
actions in place to rectify it are critical steps to avoid surprises.
1.2 Why have a Software Deployment Method?

We believe that the key to deriving value from your software depends on the
adherence to a common roadmap or method that solves your business problems.
Following this roadmap helps the individuals assigned to deployment, within your
organization and IBM, to act as one team that is focused on a common goal. This
redbook describes the Software Deployment Method that, when followed, should
maximize your chance of deployment success.
Chapter 1. Why focus on software deployment? 3

1.3 The Software Deployment Team
Many individuals from your company, IBM, and partners must work together
smoothly to ensure the successful deployment of your software. In this book, we
refer to this team as the Software Deployment Team.
Your representatives on the SDT are:

Enterprise Business Sponsor (EBS)
Stakeholders and sponsors
Project managers
The IBM representatives on the SDT are:

Software Account Manager (SAM)
Software Sales Specialist (SSS)
Software Architect (SWA), Software Deployment Architect (SDA), or both
Software Technical Sales Specialists from the brands (The primary IBM
Software Group brands are Data Management, Lotus, Rational, Tivoli,
and WebSphere.)
Services representatives (IBM Global Services, Brand, Education, Support,
etc.)
The partner representatives on the SDT are:

Third-party project managers
IBM Business Partners assisting in administrative or deployment functions
Third-party implementation consultants
The SDT should meet as required to develop software deployment strategies and
review software deployment progress. For further information about the roles and
responsibilities of the SDT, refer to Chapter 2, Roles and responsibilities on
page 13.
1.4 The Software Deployment Method

As shown in Figure 1-1, the Software Deployment Method consists of three
phases and 11 steps. Although these phases and steps are discussed
throughout this book in a serial manner, in practice they often overlap and repeat
throughout the life cycle of deployment. The phases are:
Phase 1: Prepare for deployment
Phase 2: Refine and promote the plan
Phase 3: Deploy software

Phase 1 Phase 2 Phase 3
Step 1: Step 2: Step 5: Step 6: Step 8: Step 9:
Create Review Refine Finalize Achieve Execute
Software Documents Deployment Deployment Quick-wins Deployment
Deployment Plan Plan Plans
Team
Step 3: Step 4: Step 10: Step 11:

Step 7:
Develop Establish Identify New Update
Deployment Conduct Business Business
High-Level
Partnership Deployment Needs Plan
Deployment
Kickoff
Plan
Prepare Refine and Promote Deploy

Figure 1-1 Overview of the Software Deployment Method
1.4.1 Phase 1: Prepare for deployment

The overall purpose of this phase is for you and IBM to build the groundwork
required for successful deployment. The steps in this phase are:
Step 1. Create the Software Deployment Team (SDT): During this step,
you, IBM, and any partners who may be involved work together to determine
the team that will be focused on the overall success of the software
deployment. This team is called the Software Deployment Team.
Step 2. Review the critical deployment documents: The purpose of this
step is to obtain a common understanding among the SDT of the critical
documents that will be used in the deployment process. During this step, the
SDT reviews documents such as the contract, roles, and responsibilities,
business context diagram, requirements, solution concepts, etc.
Step 3. Develop a high-level deployment plan: The purpose of this step is
to create a high-level mapping of products to your projects and assign
ownership at a project level. The high-level deployment plan defines a list of
initial deployment projects, identifies sponsors and owners from within your
business for known projects, groups deployment into logical chunks, contains
a deployment timeline, and includes a services assessment. During this step,
you should also consider your readiness for deployment by reviewing the
software deployment best practices and the readiness plan content, which are
both described later in this redbook.

Step 4. Establish a deployment partnership: This step involves holding a
formal meeting between your deployment owners, participants, or both and
IBM to come to closure on major issues that must be addressed. Such issues
include deployment best practices, identification of the sponsor, or
determining whether services will be used. This should solidify the
partnership between you and IBM and help ensure that both groups realize
that deployment is a two-way street. Keep in mind that you are ultimately
responsible for the deployment.
During this step, the SDT identifies quick deployment wins that act as both
technical proof points and create momentum. It also defines critical success
milestones and criteria. They agree on roles and responsibilities and
introduce the software deployment best practices and the readiness plan. You
and IBM should agree on the high-level deployment plan created in the
previous activities and discuss a deployment services strategy.
1.4.2 Phase 2: Refine and promote the plan

This phase begins after an agreement is in place and when critical inputs are
reviewed again to inspect any changes made during final negotiations. Also,
during this phase, the deployment plan is refined and the deployment kickoff
meeting or meetings are held. The steps in this phase are:
Step 5. Refine the high-level deployment plan: The purpose of this step is
to revise the solution architecture and deployment plans to reflect any
changes made during the final negotiations. During this step, the SDT reviews
all inputs to Steps 2 and 3 (for example, the contract and list of deployment
projects and owners) to determine if anything has changed. The team also
completes a thorough review of the requirements, architecture, components,
interfaces, and any performance modeling that has been done. A key output
from this step is a refined deployment plan.
Step 6. Finalize the deployment plan: The purpose of this step is to obtain
final agreement with the deployment plan among the SDT. During this step,
the SDT reviews all inputs to Step 4 and agrees on project controls. Also,
during this step, you and IBM should discuss the plans for one or more
deployment kickoff meetings.
Step 7. Conduct deployment kickoff meetings: The purpose of this step is
to market and communicate the deployment plan and overall vision to all
current and potential users within your company. This is typically done in the
form of a meeting or a series of meetings attended by your stakeholders
(team project leads, IT leads, and lines of business leaders) and the full IBM
team. It is imperative that key leaders and present or future stakeholders
attend. Use these meetings as the forum to bring together the stakeholders,
sponsors, and implementers and explain the business goals, IT vision,
contract details and content, and the deployment plan. Explain what will be

accomplished, why it is important, how this will be done over time, and when
major milestones are expected to be reached. The kickoff meetings should
create awareness, understanding, and enthusiasm for the deployment that is
about to begin.
1.4.3 Phase 3: Deploy software

The purpose of this phase is to begin executing against the deployment plan. It
starts with the carefully selected quick deployment wins and then moves on to
the other projects. During this phase, project management is critical. The steps in
this phase are:
Step 8. Achieve quick deployment wins: The purpose of this step is to
implement the quick deployment wins and, in doing so, demonstrate success.
This will build momentum, confidence, and credibility, which are vital in the
beginning stages of deployment. This is also the time to revise any processes
defined during earlier planning that have not worked as expected.
Step 9. Execute the deployment plan: The purpose of this step is to build
on the success and momentum of the quick deployment wins. This is also
when you begin deploying projects that were defined before and during the
product selection. During this step, project management is critical. You should
monitor carefully your stakeholders satisfaction and progress toward
deployment goals (timeline and financial).
Step 10. Identify new business needs: Due to the dynamic nature of
business, your business needs that were not known or identified during
Phases 1 and 2 typically arise after deployment has begun. These new
business needs may be satisfied with software that was part of the original
agreement, or they may require the purchase of additional software that will
be deployed in new projects. This is referred to as the software gap. To
prepare for and meet the new business needs, the SDT should return to
Phase 1 and follow the roadmap for its planning and implementation.
Step 11. Update the business plan: The purpose of this step is to complete
any purchase of software, and potentially additional services and education,
that will meet the new business needs identified in Step 10. In this step, you
also make the appropriate changes in the existing plans that will
accommodate its deployment.
1.4.4 Software deployment method: A continuous process

Figure 1-2 illustrates that the SDM is a continuous process. The outer circle
represents the activities that should occur prior to the software acquisition. The
inner circle represents the necessary steps to ensure that software is deployed
properly. After a new software requirement is defined, SDM Steps 1 through 4
should occur in sequence (outer circle). After the purchase of software is

completed, the life cycle enters what is called the software deployment mill. In
the mill, SDM Steps 7 through 11 are executed (inner circle). These steps include
deployment kickoff and communication cadence, quick deployment win
execution, and deployment plan execution. Also, in the mill is the requirement
that new demands constantly be uncovered. This can be a demand for software
already purchased that burn down licenses that are not yet deployed. Or it can be
a demand for new software requirements that require an acquisition to occur.
After a new software requirement is defined, the business plan is updated in Step
11. If this software is already purchased, the process continues within the mill
back to Step 7 (kickoff and communication). This, in effect, increases the size of
the mill because more deployment activity is underway.
If the software identified in Step 10 requires an acquisition, then Step 11 jumps to

Step 2 (from the inner circle to the outer circle). This is where the new software
can be properly built into the contract and the high level deployment plan (Steps
2 and 3). The assumption is that you can Step 1 because the Software
Deployment Team is already established. Step 4 leads to the required
acquisition, and when the new software is fed into the deployment mill, the size of
the mill increases.
Software Deployment Method Software Deployment

Method Steps
New Software
Software Requirement
Acquisition Defined
Step 5&6:
Step 11: Update
Purchase Refine & Finalize
Business &
Software Plan
Update High Level
Business Plan Deployment Plan
Step 10: Identify
New Business
Step 4: Establish Needs Step 1: Create SW
Deployment Software Deployment Team
Step 9: Execute
Partnership with Deployment Plan Deployment
Vendor Mill
Step 8: Execute Quick
Deployment Wins
Step 7: Kick-off
& Communication
Step 3: Develop High Step 2: Review Critical

Level Deployment Plan Deployment Documents
Figure 1-2 Software Deployment Method cycle

Figure 1-3 introduces the positive impact an effective deployment strategy can
have on return on investment. As the software deployment mill increases in the
number of active and completed deployment projects, the deployed license count
increases exponentially. As the mill increases in size it begins to approach the
size outer circle (purchase volume). When the inner circle grows to the size of the
outer circle, ROI has been achieved.
Return on Investment Timeline
Software
Deployed
ROI
Software
Deployed
Step 11: Purchase
Software & Update
Business Plan
Software
Deployed
Time
Figure 1-3 Software Deployment Method value timeline
1.5 Software deployment best practices

Deployment success and value realization require that you focus on the following
best practices:
Identify an Enterprise Business Sponsor and stakeholders
Centralize software fulfillment
Implement a license management tool and process
Hire deployment services
Determine your deployment readiness
Commit to self-sufficiency

Define a time-to-value and ROI strategy
Communicate and market the vision
You can find more information about these best practices in Chapter 3, Software
deployment best practices on page 21. For more information about value
realization, time-to-value, and ROI, see Chapter 4, Value realization on
page 31.
1.6 The readiness plan

After you commit to purchase IBM Software, it is critical that your employees
acquire the skills and process knowledge necessary to successfully implement
the solution. The readiness plan is designed to facilitate the communications and
planning between you and IBM at critical junctures. It is prepared by the IBM
Software Architect or Technical Specialist. The number of readiness plans that
are required depend on several factors such as the people who are involved, the
complexity of the environment, and the number and complexity of projects.
A well-executed readiness plan proactively addresses implementation issues. In

turn, it promotes enhanced satisfaction with the IBM solutions. The readiness
plan itself is a set of processes and work products that are designed to:
Help ensure your expectations are properly set and met
Identify issues and risks and set a proper course of action
Help ensure your team has the appropriate skills for implementation
Assign responsibilities and ownership of implementation tasks
The readiness plan is a compilation of subplans that can be delivered in many

different ways. The selection of plan elements is based on the needs of the
solution. The timing of the delivery is highly dependent on each individual
situation. The IBM team helps you fully understand the nuances of the readiness
plan and crafts a readiness plan that is best for your situation. You should sign off
on the readiness plan, which signifies your acknowledgement of the scope of
responsibilities from both you and IBM.
1.7 Solution Assurance Review

Solution Assurance Reviews (SARs) are used to review proposed solutions. IBM
subject matter experts perform these reviews to ensure that the solutions can
deliver the features that you expect and that they are technically possible to
implement.

We recommend that you incorporate the SAR process into your existing methods
and use it proactively to minimize deployment challenges. If you have a particular
situation where you want to consider a SAR, contact a member of your IBM
Software team.
1.8 Software solution work products

One of the mantras at IBM is don't reinvent the wheel. In the spirit of reuse, we
include examples of work products in Appendix A, Software solution work
products on page 87. We mention many times throughout this redbook that
planning and design are key attributes to any successful software deployment
endeavor. The work products contained in this appendix have been used by IBM
project managers and architects to drive successful deployment projects all over
the world. If you have any questions about how to use these work products,
contact your IBM Software Account Manager, your IBM Software Architect, or
your IBM Software Services representative.
1.9 Software deployment: A two-way street

We recommend that the SDT follow the method described in this redbook
because it has been proven to lead to successful software deployment. In turn,
successful deployment helps you overcome your business challenges and
achieve your business goals. It is important to realize that deployment is a
two-way street between you and IBM, and that your success fuels our success as
well. Let deployment begin!

Customer example: Soon after signing an Enterprise Agreement (EA) with
IBM, GMR recognized the need for a single owner for the EA. The
responsibility of the owner would be to ensure the successful deployment of
the software purchased in the EA. GMRs Vice President of Architecture for
Technical Services was placed in the role of Enterprise Business Sponsor
(software deployment best practices #1) by his manager (the Chief Information
Officer (CIO)). His first step was to identify a team of IT Managers to assist
with identifying a deployment strategy for GMR. IBM already had in place
sales and technical sales representatives, including a SAM and SWA. These
two groups, when combined, created the SDT (SDM Phase 1, Step 1). One
team - GMR and IBM - focused on ensuring the success of the EA.
The SDT quickly defined a high-level deployment plan that identified a

long-term view of deployment direction. The SDT also defined quick
deployment wins, five products from the EA to be deployed immediately.
These quick wins were to be delivered in the near term to build confidence and
generate excitement around the technology and solutions while supporting
GMRs business objectives. The leader of GMRs EA Deployment Team
identified product captains for the helm of each quick deployment win. Their
responsibilities were to define and execute a realistic plan to use the software
in at least one pilot project and to build the infrastructure to support use of the
quick win software in future projects. In addition, they had the responsibility
to communicate and market successes within GMR Technical Services.
To facilitate this communication and marketing effort, GMRs EA Deployment

Team devised an event entitled EA Land (SDM Phase 2, Step 7). EA Land
was organized to allow the product captains to highlight their teams
achievements during the first eight months of EA deployment work. Along with
product tables and two demo rooms, staffed by GMR and vendor
representatives, process tables were included, such as quality assurance,
information architecture, and solution services. This ensured that the
excitement about the EA products that was generated by EA Land did not
overwhelm GMRs deployment process. Over 1,200 GMR IT professionals
were invited to this event.
Because of GMRs focus on planning, communication, and several other

principles that are highlighted in this redbook, GMR achieved several early
successes in their EA deployment effort. Along the way they also successfully
designed and implemented a process to help ensure successful software
deployments in the future.

2
Chapter 2. Roles and responsibilities
Finding good players is easy. Getting them to act as a team is another story.
Casey Stengel, famed manager of baseball's New York Yankees
One of the many reasons you may have decided to do business with IBM is
because we have many skilled professionals involved in the sales and
deployment of our software, hardware, and services. The challenge when many
people are involved is to ensure that the roles and responsibilities are clearly
communicated to you. It is equally important that any expectations you have of
IBM, and vice versa, are defined as early in the software deployment process as
possible.
One of the more common concerns found when analyzing deployments is that
roles and responsibilities are not clearly stated up front. Then, as the deployment
progresses, confusion arises over who is supposed to perform certain tasks or
when they will be done. The foundation, therefore, for deriving value from your
purchases begins with ensuring that your team and the IBM team know their own
roles and the roles of each other. Who is supposed to do what? And when should
they do it? This chapter describes that foundation.

2.1 Internal team
Your internal team members include an Enterprise Business Sponsor (EBS),
project leads, stakeholders, sponsors, and a Global Project Lead if there is
significant deployment planned in multiple locations.
2.1.1 Enterprise Business Sponsor

The EBS is generally appointed by a senior executive in the Information
Technology (IT) organization. The EBS should represent your companys goals,
take ownership for software deployment throughout the enterprise, and commit
to the following responsibilities:
Develop and promote an internal vision for attaining the maximum usage of
purchased licenses, based on the benefit derived
Work with the lines-of-business and IT leads to delegate responsibility for
deployment success and return on investment (ROI)
Represent the business globally, if applicable
Define deployment milestones
Assist with marketing and demand generation of the software portfolio within
the organization
Establish quick deployment win initiatives to establish project credibility as
early as possible
2.1.2 Stakeholders, sponsors, and project leads

Stakeholders are those individuals who requested or will benefit from the
solutions being provided. This group needs frequent feedback on designs,
prototypes, and progress toward a final deliverable to maintain confidence in the
solution and delivery team.
Sponsors are those individuals who are funding the deployment work to provide
the solution to the stakeholders. The sponsor may also have selected or
approved the high-level architecture and products to be used in the solution.
Sometimes, the stakeholder and sponsor are the same individual or group.
Project leads are in charge of individual projects that contribute to the solution
paid for by the sponsor and to be delivered to the stakeholders. They manage the
day-to-day execution of the project vision and direct the efforts of the
development specialists.
To make the most of your software investment and exploit the value of that
investment, it is critical to have early and frequent communication with the

stakeholders and sponsors for each project. Both the marketing of successes
and the alerting of obstacles become a vital part of keeping the projects on track.
It is equally important to repeat the vision and ultimate goals for deployment
projects to the project managers and implementers. Without this cadence of
direction, projects can lose themselves in the day-to-day issues and lose site of
the business reasons for the implementation. It is the progress toward meeting
your business needs, more so than a particular technology or technique, that is
the goal of any deployment.
2.1.3 Global Project Lead

The Global Project Lead (GPL) is assigned to global software deployments and
coordinates all deployment activities going on around the world. This person
should:
Have excellent project management skills as well as experience on the global
stage working with a variety of people from differing cultural backgrounds.
Have experience managing complicated projects. This implies that they can
handle complicated products, and combinations of products, and complicated
geographical challenges.
Be a self starter, constantly looking for opportunities to increase the
deployment footprint.
For more information about the GPLs role, refer to Chapter 9, Managing global
software deployment projects on page 71.
2.2 Team IBM

Team IBM refers to the many people from IBM who are involved in making your
software, hardware, and service purchases successful. While each person has
their own unique focus and specialty, it is the goal of each individual to present a
cohesive view of the IBM Company.
When leveraged, the IBM team can be a tremendous asset to you. Their wealth
of expertise is unmatched in the IT industry. Also their knowledge of your
business goes far beyond the scope of the software that is being deployed. The
IBM team members come from such organizations as IBM Global Services, the
System Group (Server/Storage), IBM Global Finance, Personal Computing
Division, Printers, Partner Channels (Global and Small to Medium), and the IBM
Software Group. Almost every software agreement requires participation from
these organizations. Leveraging such a diverse team can greatly enhance the
deployment process.
Chapter 2. Roles and responsibilities 15

Typical examples of engaging multiple IBM organizations are IBM Global
Services for implementation support, IBM Global Financing for financial
assistance, and the System Group for the required servers and storage. The
deployment process is enhanced if these organizations, in concert with IBM
Software Group, are engaged early in the cycle of project development and
architecture definition.
Table 2-1 provides an overview of the various IBM roles.
Table 2-1 Overview of IBM roles

Hardware Services Software
Managing Director
Client Executive
Client Representative
Client IT Architect (CITA)
DM Lotus Tivoli WebSphere Rational
Software Account Manager (SAM)
Software Architect (SWA)
Software Deployment Architect (SDA)
Sales Spec Sales Spec Sales Spec Sales Spec Sales Spec
IT Spec IT Spec IT Spec IT Spec IT Spec
Services Services Services Services Services
Support Support Support Support Support
2.3 IBM Software Sales Team

The IBM Software Sales Team consists of the following members:
Sales (non-technical):
Software Account Manager: Cross-brand strategy and sales
Software Sales Specialist (SSS): Single brand sales and tactical sales
support

Technical Sales Support (technical):
Software Deployment Architect: Cross-brand strategy and deployment
Software Architect: Cross-brand strategy, sales, and deployment
Software Technical Sales Specialist (ITS): Single brand sales and tactical
support
2.3.1 IBM Software Account Manager

SAMs formulate strategies that link IBM Software with your business strategies.
The SAM should work closely with you to:
Understand your business needs and propose IBM solutions to meet those
needs
Manage customer relationships and problems
Negotiate future software agreements
Help you understand the IBM Software Strategy and how it is of value to you
Increase satisfaction with IBM Software solutions
Coordinate efforts of the IBM Software team to match your business strategy
Each SAM provides a single sales face to you across all of the IBM Software
brands.
2.3.2 IBM Software Sales Specialist

The SSS sells a particular set (brand) of IBM Software and works with the SAMs,
ITSs, and SWAs in doing so. They have knowledge of IBM strategies and
directions for the brand they represent. They are responsible for positively
impacting your satisfaction with the offerings within their respective brands.
Note: The primary IBM Software Group brands are Data Management, Lotus,
Rational, Tivoli, and WebSphere.
2.3.3 IBM Software Architect

Using the entire IBM Software portfolio as a palette, the Software Architect paints
comprehensive technical solutions that solve your business and IT challenges.
These comprehensive technical solutions translate your business vision into
specific technical designs. After listening to and analyzing your business needs,
the SWA designs a solution that integrates into your IT environment and
leverages the best technology available from IBM. The SWA has an overall
responsibility for the technical solutions delivered to you and helps ensure those
solutions are successfully deployed.

The SWAs responsibilities are to:
Work with you and the IBM team to translate your business vision and IT
challenges into a specific design
Develop plans to prove or implement the technical design
Build and maintain relationships with your key IT decision makers
Direct the IBM activities required to design and implement a solution
Focus on your technical strategy rather than on specific products or tactical
implementation issues
Use tools and established methodologies to help you develop the strategy
and vision for the IT systems and shape this vision into a specific technical
design
Employ accepted design methods, patterns, and best practices when
performing analysis and designing project phases
Understand the integration of the IBM Software products and how the
solutions compare with those offered by our competition
Recommend appropriate education and services based on knowledge of your
environment and skill levels
Investigate new software technology and design methods to provide proactive
education
Manage the Solution Assurance Review (SAR) process
Help you understand and adopt the software deployment best practices
Help you prevent software from becoming shelfware
2.3.4 IBM Software Deployment Architect

While the IBM Software Architect has an overall responsibility for the technical
solutions, there are circumstances that require a more specialized architect to
concentrate on the deployment of your software. The IBM Software Deployment
Architect assists you in the development of software solutions that use your
existing software. They also use the entire IBM Software portfolio as a palette,
but concentrate first on your existing and undeployed inventory. The assignment
of an SDA is decided case-by-case. It is based on the complexity of your
deployment, complexity of your contracts, or the geographic scope of your
deployment plans. If you feel your deployment requires an SDA, you should
discuss those needs with your Software Account Manager.
The SDAs responsibilities are to:

Lead the design and deployment of technical software solutions by leveraging
design methods, patterns, and best practices

Advise on the most architecturally sound combination of software to help
ensure the efficient deployment of technical solutions
Customize documented deployment methods to facilitate solution success
Lead the IBM technical team to drive new and existing solutions to completion
Understand the integration of the IBM Software products and how the
solutions compare with those offered by our competition
Maintain an active role in the Solution Assurance Review process to ensure
action items are closed and risks are mitigated
Help you understand the software deployment best practices
Help to ensure work products are documented and transferable to other
technical professionals
Help to ensure software does not become shelfware
2.3.5 IBM Software Technical Sales Specialist

Employing a technical understanding of the capabilities of a product set, the
Software Technical Sales Specialist advocates solutions to your key IT decision
makers. By using their technical knowledge and proven experience, the ITS
provides a bridge between your technical challenges and IBM solutions.
The responsibilities of the Software Technical Sales Specialist are to:

Build and maintain a technical understanding of product capabilities
Understand your technical infrastructure and use this knowledge to identify
potential solutions
Communicate the technical vision for the IBM Software brand for which they
are responsible
Understand how their IBM Software brand compares to our competition
Ensure you are technically prepared for a successful implementation
Manage the Solution Assurance Review process
2.4 IBM Client Team

The IBM client team consists of the following members:
IBM Client Executive
IBM Client Representative
IBM Client IT Architect

2.4.1 IBM Client Executive
The Client Executive builds a long-term business relationship with you by
identifying opportunities to improve your business and delivering solution
strategies that meet your business needs. The Client Executive maintains
business relationships at the senior management level of your organization. The
Client Executive is accountable for your overall satisfaction with IBM.
2.4.2 IBM Client Representative

The Client Representative builds long-term business relationships with you and
your team by providing solutions to your business needs. This is accomplished
by:
Communicating the IBM solutions to gain understanding and commitment
Engaging appropriate resources
Helping to ensure overall satisfaction
They partner with the software, hardware, and services representatives as

needed to ensure a complete solution is presented. However, they also
communicate your business and technical strategies back to Team IBM to
maintain focus on your business needs.
2.4.3 IBM Client IT Architect

The Client IT Architect has a role similar to that of the Software Architect. The
CITA has strategic responsibility for the entire technical IBM relationship across
hardware, software, and services. A strong partnership between the CITA and
your technical leaders is critical to guiding Team IBM and ensuring that the
proposed solutions are appropriate to your technical vision.

3
Chapter 3. Software deployment best

practices
Best practices are tried and true methods that have a history of being successful.
Deployment success and value realization are achieved when best practices are
adhered to consistently throughout the Software Deployment Method. Through
working with the many customers of IBM Software and seeing what works and
what fails, we created the following list of software deployment best practices:
Identify an Enterprise Business Sponsor (EBS) and stakeholders
Centralize software fulfillment
Implement a license management tool and processes
Hire deployment services
Determine your deployment readiness
Commit to self-sufficiency
Define a time-to-value and return on investment (ROI) strategy
Communicate and market the vision
It is important that you and the IBM team discuss and agree to follow these best
practices, since they have proven to ensure the highest possibility of success.
Table 3-1 summarizes the best practices that are described in this chapter.

Table 3-1 Summary of software deployment best practices
Software deployment Benefit
best practice
Identify an Enterprise Aligns business goals with Information Technology (IT) initiatives
Business Sponsor prescribed during software purchase decision
Establishes an owner for software value, rate of return (ROR), and ROI
Functions as a leader to track deployment progress and coordinate
resources to execute projects
Centralize software Ensures that each person that has the desire to deploy software has the
fulfillment means of getting it efficiently and effectively
Provides a control point from which software deployment progress can me
monitored
Implement a license Allows you to verify your compliance with the terms and conditions of your
management tool software contracts
Eases charge-backs between departments for requested software
Provides intelligence regarding software deployment
Allows better control of version management, patch delivery, upgrades,
and general maintenance
Gives you an opportunity to save money with accurate assessments of
your software usage
Hire deployment Ensures that an expert is engaged to help plan and execute the
services deployment
Allows you to navigate the normal pitfalls of solution development by
leveraging experienced consultants
Dramatically increases the chances for deployment success
Determine deployment Eliminates many of the unknowns associated with solution design and
readiness software deployment
Guides you through the activities needed to improve software planning
and deployment
Helps to ensure that the deployment goes as smoothly as possible with
the fewest challenges
Commit to Ensures that, over time, the reliance on IBM services and support is
self-sufficiency minimized
Reduces long term cost of ownership by building skilled teams, strong
processes, and robust environments
Define a time-to-value Provides common goals for the deployment teams to work toward
and ROI strategy Builds confidence with the achievement of quick wins
Defines a schedule for achieving long term goals
Provides a mechanism to gain community buy in

Software deployment Benefit
best practice
Communicate and Increases the investment understanding by communicating the linkage

Market the Vision between the strategic purchase and business goals
Accelerates the rate of return and increases solution demand through
advertised successes
3.1 Identify an Enterprise Business Sponsor and

stakeholders
Customer example: The Chief Information Officer (CIO) of a major insurance

company in Texas, U.S.A, has personally assumed ownership of their software
agreement to drive their deployment projects. He delegates the day-to-day
responsibilities to various project managers on his staff and maintains
involvement with monthly status updates. Any inhibitors to their success are
quickly dealt with so as not to impact their overall plan. Not only does the
involvement of the CIO avoid any surprises, but also it ensures that his vision
is continuously delivered and reinforced.
Ownership for your deployment success may be at several different levels. For
example, you may be the high-level Enterprise Business Sponsor and have
delegated additional sponsorship to your direct reports. Or an IT executive may
have delegated sub-sponsorship to separate lines of business. It is important that
there is one executive who is responsible for the successful implementation of
large or on-going transactions. If this person is you, seek out your local IBM
team. They are eager to meet you and build the partnership necessary for your
success.
If the Software Deployment Team (SDT) feels that they cannot control the
projects or implement any needed changes, it is possible they have not found or
are not working with the Enterprise Business Sponsor. It may be that the
individual given responsibility for deployment is not in the right position to drive
success. The sponsor needs to know that there is a team ready to work together
to achieve the business goals defined. It is with the Enterprise Business Sponsor
that quick deployment successes need to be set. Ongoing successes should be
expected and celebrated.
The members of the SDT should work with the Enterprise Business Sponsor to
identify any cultural, geographical, political, skills, or training challenges that
need to be overcome. Define a strategy or plan to overcome each. It should also
Chapter 3. Software deployment best practices 23

be clear to everyone, from the Enterprise Business Sponsor to the individual
developers, how to go about getting software support.
The Enterprise Business Sponsor should also consider forming a Center of

Excellence (COE), which provides a focal point for IBM Software expertise. This
type of organization can facilitate the deployment at multiple phases in the
deployment life cycle. While kicking off the deployment, a COE provides an
internal organization and set of personnel that can increase the buy-in and
willingness of other organizations to use the purchased software. This can be
done with presentations, demonstrations, and proof-of-concept activities. During
the deployment of software, a COE facilitates the sharing of skills, experiences,
and resources across multiple projects. It accelerates and improves the quality of
the entire deployment.
Customer comment: The recommendation that one owner be defined for

the successful deployment of software has been extremely beneficial.
GMR Corporations (GMRs) VP of Technical Services
3.2 Centralize software fulfillment

Purchasing software for a large company involves a multitude of software
packages, sometimes for a multitude of business projects, which need to be
received, logged, distributed, and tracked. We give you the option to receive
software on CDs or download them directly from our Passport Advantage
Online Web site. This process is usually continuous until the software
entitlements expire.
Over time, the individuals or groups who need to receive software will likely
change. It is important for you to initiate a centralized software fulfillment process
as early as possible in the deployment life cycle. The key element of this process
is having one party in your company be responsible for the receipt or
downloading of all software, logging its receipt, distributing it to those who need
it, and tracking what is delivered. If it is not feasible to initiate this process within
your company, consider contacting your IBM team to explore the option of using
an IBM Business Partner for assistance.

Customer example: A leading health care provider in California, U.S.A., has
partnered with IBM and their software partner to develop an electronic
software delivery system that ensures the software is available to their users
and tracked for accounting purposes. Not only can end users request
authorization and download software electronically, but the system also
produces a regular management report to the procurement office. This type of
innovation has removed the burden of CD management, provided the tracking
needed to demonstrate software utilization, and allowed the company to
reduce their operation costs.
3.3 Implement a license management tool and process

In this age of distributed computing, departmental projects, and company
locations that may span the globe, it is important to understand where your
investments are and how they are being used. You may have contractual
obligations to report on software usage or over usage, or you may use this
information internally to manage costs or charge backs. Implementing a
complete process with the appropriate tools allows you to fully understand your
software usage.
License management involves identifying:

The licenses that are supposed to be installed
The licenses that are actually installed
The licenses that are actively being used
The number of licenses that are forecasted to be installed
Many companies have tried to accomplish this task with paper, spreadsheets, or
e-mails. This tracking typically addresses only the first stage of license
management, what is supposed to be installed. An equally critical stage is that of
tracking what software licenses are actually installed and used, because
departments may be charged for the software distributed to their community,
whether or not it is used. Good record keeping and licence management
techniques regarding your software installation and use can ensure that software
is purchased at the required levels.
At other times, an audit either manual or with an inventory tool discovers

widespread installation of software and leads you to believe that value is derived
from that installation. In fact, software is often not removed or it is installed and
later forgotten. If such an inventory is used to budget maintenance, you may be
paying more than necessary to maintain support on unused licenses.
Performing effective license management takes a combination of tools and

processes. You should track both the software distributed that users should have

and use a tool to identify what is actually installed. Taking this a step further, the
tool should ideally be able to tell you if the installed software is or has been used.
Finally, you should factor in your projected deployment if using the data for
budgeting purposes.
To address this need, IBM Software Architects (SWAs) are experienced in

creating complete and end-to-end processes to achieve this level of license
management. We also developed a tool called IBM Tivoli License Manager
(ITLM) to perform the installation inventory and create usage reports.
Refer to Chapter 10, Software deployment tools on page 79, for further
information about software deployment and license management tools.
3.4 Hire deployment services

Our most successful customers frequently engage with deployment services to
augment their local expertise. These services personnel should be familiar with
the products and be able to start planning and implementing your solutions
immediately. They can also be helpful in transferring their experiences to your
own staff and reduce the time you need to reach self sufficiency.
Your IBM team has been involved with many services engagements and can help
you determine what is needed for your unique situation. If you decide not to use
an external services organization, then realize that your time-to-value may be
further out than desired. Your internal staff needs more education and time to
learn how to integrate the new technology into your existing environment.
Customer example: GMR discussed the concept of including implementation

services in their Enterprise Agreement. Ultimately they took them out to keep
the initial cost down. Now that they are into their deployment, they are working
on a separate services agreement that will provide help for any deployment
teams that need it. In hindsight, they wish that they included the services in
the original agreement.
3.5 Determine your deployment readiness

Anytime there is a transition in focus from product selection and negotiations to
deployment activities, there is an opportunity for assumptions, unclear
expectations, and added risk to your success. We developed a work product
known as the readiness plan to document your readiness or preparedness for
deployment and highlight any known risks. A readiness plan can be created at a
high level based on an overall vision and large purchase. However, we

recommend a more detailed plan for each large or complex project before it
begins.
The IBM Software Deployment Architect, IBM Software Architect, IBM Technical
Sales Specialist or all three will work with your team members to collect the
information needed to prepare a readiness plan. The plan may include some or
all of the following subplans:
Communications (including IBM support)
Education and skills
Architecture
Deployment (Implementation, testing, and migration)
Operations (Help desk support and systems management)
Risks and dependencies
Even if an upcoming project seems small and simple, it is to your advantage to

consider all of these areas and document what is expected. This facilitates the
identification of gaps and helps to direct corrective actions.
Customer example: The Software Account Manager working with a major

customer in Italy always thought these plans and reviews were done for
administrative purposes only. However, after experiencing several of them first
hand, he and the customer realized how valuable they are at avoiding the
pitfalls of a typical deployment engagement.
We realize that doing this takes time. However, the time you invest here pays
excellent dividends as you proceed with the deployment. These plans and
thought processes help you to:
Ensure that you have the right set of expectations and directives to
successfully implement the proposed solution
Ensure that the IT solution lies within the art of the possible
Identify any issues and risks that may need to be escalated
3.6 Commit to self-sufficiency

The goal of your IBM team is to decrease the level of involvement from IBM over
time as you progress through your deployment plan. This is accomplished
through a well-designed education plan that develops subject matter experts
within your own organization for the solutions being implemented. You can kick
start this by hiring deployment services, but you should strive to develop in-house
expertise.

3.7 Define a time-to-value and ROI strategy
It is up to you to determine and communicate how you will calculate and measure
value. This is typically stated as return objectives (ROI) and a time frame for that
return (time-to-value). There are generally two different types of ROI used:
Soft ROI: This includes such examples as better monitoring or control
capabilities, transformation of IT or business processes, implementation of a
strategic vision, and the adoption of a common look and feel.
Hard ROI: This includes such examples as headcount savings, system count
reduction, server consolidation, department or process closures, and
outsourcing.
You or the sponsoring executive should work with the Software Deployment
Team to define the return objectives and map a timeline with value milestones.
Revisit the milestones at least quarterly to help ensure that the deployment is
moving forward effectively and delivering the intended results.
Refer to Chapter 4, Value realization on page 31, for more information about
this topic.
Customer example: An insurance company based in Texas, U.S.A. has taken

the time-to-value concept and applied it to their project selection process. In
addition to the technical merits of a solution, the project managers work with
the software vendor to show the business value that the project will provide
and the expected time before that value is reached.
3.8 Communicate and market the vision

While your software partners and vendors are capable marketers of their
products, they are not in the best position to market your vision. Therefore, the
business drivers behind a software purchase are often not communicated within
a company. Sometimes it is the inventory of software purchased and not
deployed that gets forgotten. This internal marketing and communication should
be led by you, the Enterprise Business Sponsor, to create demand, interest, and
promote success.
A key event that helps launch a large deployment effort is to host a deployment
kickoff meeting. This meeting should take place soon after you close a software
agreement. This event should introduce all of your stakeholders to the products
purchased and how they fit into the vision. This is a good time to review these
software deployment best practices. In addition, review any expectations that
were set and the criteria that will be used to measure value. For more information

about the kickoff meeting, see 6.3, Step 7: Conduct the initial deployment kickoff
meeting on page 54.
Like the steady beat of a drum, communications should continue throughout the
life of the deployment, marketing and surfacing deployment opportunities, and
areas for improvement. The Software Deployment Team should monitor
deployment progress and recommend adjustments in the communication plan. In
general, keep those who need to know informed about the progress or inhibiting
factors. An example of communications can be a newsletter or intranet Web page
that keeps management and end users informed about recent accomplishments,
milestones, and improvements. It is important to promote and validate the results
of deployment often and to as many audiences as possible to keep up the
momentum and excitement.
Customer example: To facilitate this communication and marketing effort,

GMRs EA Deployment Team devised an event entitled EA Land (SDM
Phase 2, Step 7). EA Land was organized to allow the product captains to
highlight their teams achievements during the first eight months of EA
deployment work. Along with product tables and two demo rooms, staffed by
GMR and vendor representatives, the Vice President (VP) of GMR Technical
Services also asked to include process tables, such as quality assurance,
information architecture, and solution services. The VP did this to ensure that
the excitement about the EA products that was generated by EA Land did not
overwhelm GMRs deployment process. Over 1,200 GMR IT professionals
were invited to this event, and over 700 attended, an unprecedented turnout
for an event of this type at GMR.

4
Chapter 4. Value realization

The subject of how value is realized is far too often ignored. While neglecting or
avoiding this topic may seem harmless, the impact on the overall success of your
Information Technology (IT) and business goals can be dramatic. It is critical that
you set aside time to regularly revisit the buying decisions that were made. This
ensures that all parties involved in the deployment of software fully understand
their roles and their responsibilities.
This chapter reviews various ways in which value can be defined. You are given
specific examples and supporting case studies to help you select a method that
best matches your business. It is possible that you may not find a method that
matches your needs. However, we hope that this chapter will foster discussions
and work groups to develop a value realization strategy that works for you.

4.1 Value statement and value timeline
There is no right or wrong way to define value. When it comes to value the only
thing you can do wrong is disregard it. The first step is to define a value
statement. A value statement is not something you create once and set aside. It
must be a living document that you can modify dynamically. Generally speaking,
a value statement should describe the goals that were highlighted as part of the
buying decision. Consider the following example:
Our goal is to exceed 5% improvement in the availability, reliability, and
efficiency of our ATM network. We will partner with IBM to achieve these
goals and leverage their consulting, software, and hardware expertise to this
end.
To keep the value statement current, you must revisit it every time you purchase
new hardware or software.
The second step is to build a value timeline. The value timeline should also be
dynamic in nature and include an illustration of key projects and key milestones.
Figure 4-1 shows an example.
10/15/2003 1/15/2004 3/22/2004 6/15/2004 9/13/2004 12/15/2004

Europe Asia
Prototype User Testing HQ Rollout US Rollout
Rollout Rollout
7/15/2003
Figure 4-1 Sample value timeline
4.2 The buying decision

If you are not familiar with the details of the buying decision, you need to find the
person or persons and request a full debriefing. To begin, you need to know:
What lines of business (LOBs) were involved in the negotiation process
Who the key contacts are in these LOBs
What business goals are being address by the latest software purchase
What expectations were set as part of the decision making process

4.3 Return on investment
As early as possible, preferably before purchase is completed, the Enterprise
Business Sponsor should determine how to realize return on investment (ROI).
The work done up front to define ROI criteria will pay dividends throughout the
entire life cycle of software deployment. ROI discussions typically lead to two
types of measurements:
Hard (tangible) ROI
Soft (intangible) ROI
According to most experts in this area, it is important to have both tangible and
intangible ways to measure success. In many cases, the value may not be clearly
defined in financial terms. Therefore, the only alternative is to look for
non-financial benefits. A common misconception is that hard measures are good
and soft measures are bad. It makes the most sense to determine what is best
for your business and then measure and celebrate your successes.
Hard and soft ROI can be developed at an individual product level. While this is
not discouraged, it is important not to become lost in the details. It is more
important to determine the overall benefits at the enterprise level and tie those
benefits to your business vision.
4.3.1 Hard (tangible) ROI

Hard (tangible) ROI can be quantified with dollars or numbers. It is typically
associated with:
Headcount savings: Solutions often provide automation or efficiencies that
allow more work to be done with the same number of employees (that is,
additional employees dont need to be hired), or the current workload can be
handled with fewer employees. Your Finance or Human Resources
Department should know the full cost per employee, so these projections map
cleanly to dollars saved.
System count reduction: Hardware has fixed costs associated with it.
Therefore, solutions connected with reducing hardware inventory through
more efficient use of that hardware are tangible, and dollars saved can be
shown.
Server consolidation: It may be cheaper to move solutions from several
small machines to fewer larger machines, while maintaining or improving the
level of service. Again, since hardware costs are fixed, the dollars saved can
be quantified.
Department closures: Solutions may eliminate the need for entire
departments. This may include headcount savings, system count reductions,
Chapter 4. Value realization 33

and server consolidations. It may also include the elimination of telephone,
facilities, and real estate costs, all of which have associated savings.
Professional studies that quantify hard ROI require significant time commitment,
six to nine months in some cases. These studies involve questionnaires and
interviews that may contain hundreds of questions. Since many departments in
your company are asked to participate, your time investment can be quite high.
When this process is completed, it may take several days or weeks for the
analysis and results to be made available.
For an additional word of advise, even hard ROI has a bit of subjectivity to it.
Keep these points in mind before you embark on the long process of defining
ROI in these manners. See Figure 4-2 on page 37 and Figure 4-3 on page 38 for
good examples of how to calculate hard ROI based on software utilization.
4.3.2 Soft (intangible) ROI

Soft (intangible) ROI generally cannot be projected or have its progress
measured in exact financial or other numeric terms. It involves such concepts as
satisfaction, perception, usability, vision, etc.
Consider the following examples of soft ROI:

Help the company achieve its strategic vision: It may be difficult to
quantify the value of attaining the business vision, but there should be no
question as to the value of attaining it.
Enhance usability: For example, suppose that the many applications that
your employees had to work with all had the same look and feel. There can be
productivity and satisfaction gains from achieving that goal.
Support business growth: Most businesses want to grow. Solutions that
support seamless business expansion are of value.
Streamline the way organizations work within the company: Efficiency is
hard to measure or prove, but employees usually know when it is missing.
Solutions that re-engineer organizations or streamline processes may have
soft ROI, but important ROI nonetheless.
Allow resource redirection: The better managed your environment is, the
more time employees can be proactive rather that reactive. They can
anticipate and plan for future business improvements.
Improve employee satisfaction: Evaluate how your employees feel about
their jobs, their departments, the processes they follow, their productivity, the
tools they use, their upper management, and their company.
The challenge with soft ROI is that you need to determine how you will measure
and track progress and performance. Step 7 of the Software Deployment Method

is when you hold a kickoff meeting with all the stakeholders. This is a good time
to discuss how to calculate ROI. Everyone in this session must understand their
responsibilities regarding deployment and ROI.
4.3.3 Realizing value with hard and soft ROI

Lets look at an example of how you may see both hard and soft ROI and how it
may evolve over time.
You may have a business goal to expand your company and add three new
locations around the world to support customers more efficiently in their local
languages. To support this goal, you purchase hardware and software for each
location to support the business applications needed. The ROI for this project is
soft because it results primarily in increased customer satisfaction and the
attainment of a corporate goal.
A year later there are advances in the hardware and software arena. A decision
is made to consolidate the hardware onto fewer, but larger machines. This
solution reduces your fixed hardware support costs and provide hard ROI. The
original hardware may be returned (if leased) or redeployed to support other
business needs. The quantity of software needed for the new locations may now
be lower due to the lower number of machines or processors. This means that
you can redeploy the now available software to support additional business
needs and gain additional hard or soft ROI from the original, single purchase.
This cycle may repeat over time. However, since your focus was on solving
business problems and showing how each solution provided ROI, you can
maximize that ROI over several projects.
4.3.4 ROI must support the business strategy

ROI helps an organization understand the value to be gained from investing in
the deployment of software, hardware, and services. Whether the drivers for
purchases are based on proactive needs or a reaction to trends and market
direction, the desire to track and quantify benefits is usually absolute. Typically,
the ROI is driven by the business looking to see an increase in productivity or
some type of cost savings. Therefore, it is essential that you partner with your
IBM team to quantify the benefits, tangible or intangible, and tie them directly to
your companys business goals and objectives.

4.3.5 An approach to analyzing ROI
We recommend the following approach to measure ROI and the success of a
deployment project:
1. Interview executives, managers, and employees. Gather business needs,
current metrics, and possible benefits.
2. Review company data including organizations, processes, metrics, customer
feedback, statistics on current states, and how knowledge is shared.
3. With the knowledge of practices and business processes within your
companys industry, analyze and synthesize the data.
4. Create quantitative measures (spreadsheets) and qualitative measures
(surveys and interview guides) to gather data concerning the benefits of
implementing the solution for specific communities.
5. Determine the base line data for the quantitative and qualitative measures
that you define.
6. Gather the new data after solutions are used by the people and communities
for at least three months.
7. Calculate the benefits and define the value to the organization against the
defined business requirements.
8. Make subsequent measurements and determine the on-going value.
9. Determine any need for changes in the metrics developed for measuring
success or in the delivered solution.
These steps offer an order and approach for identifying on-going measurements
for success and lifetime ROI.
4.3.6 When business goals are met, everyone wins

The purpose of making investments in software, hardware, and services is to
solve business needs and show business value. When business needs are
solved, your business grows and improves. The results you get from these
successes help build confidence in the Lines of Business you support. This
makes your future deployment targets easier to plan and accomplish.

4.3.7 Example ROI: Current value
Figure 4-2 shows one way to illustrate the value of deployed software and the
software gap left to deploy. It is based on the normal price for each software
license, before any special discounting you may have. Licenses deployed or
allocated to specific projects are compared with the value of licenses that have
yet to be allocated to a project. Using this method helps you measure your
progress against a specific software agreement.
Software Agreement Value Statement
Deployed /
Total # Licenses Licenses Software License Allocated Software
Product Purchased Deployed Allocated Gap Value Value Gap Value
Data Management
IBM DB2 UDB Enterprise Edition 50 40 5 5 $17,000.00 $765,000.00 $85,000.00
IBM Content Manager 15 5 0 10 $5,000.00 $25,000.00 $50,000.00
Lotus
IBM Lotus Notes Seats 29000 29000 0 0 $25.00 $725,000.00 $0.00
IBM Lotus Domino Server 10 10 0 0 $1,500.00 $15,000.00 $0.00
IBM Lotus Sametime 29000 5000 20000 4000 $25.00 $625,000.00 $100,000.00
IBM Lotus Quickplace 29000 750 1500 26750 $35.00 $78,750.00 $936,250.00
Rational
IBM Rational ClearCase 30 15 10 5 $200.00 $5,000.00 $1,000.00
Tivoli
IBM Tivoli License Manager 500 300 200 0 $100.00 $50,000.00 $0.00
IBM Tivoli Distributed Monitoring 350 100 100 150 $1,000.00 $200,000.00 $150,000.00
IBM Tivoli Enterprise Console 5 2 2 1 $12,000.00 $48,000.00 $12,000.00
WebSphere
IBM WebSphere Application Server 25 25 0 0 $9,500.00 $237,500.00 $0.00
IBM WebSphere Application Developer 250 250 0 0 $250.00 $62,500.00 $0.00
$2,836,750.00 $1,334,250.00
Additional Software Agreement Benefits

IBM WebSphere architecture and implementation services $10,000.00
IBM Tivoli License Manager quick start $5,000.00
IBM DB2 data modeling and database consolidation services $5,000.00
$20,000.00
Total Value: $2,856,750.00
Figure 4-2 Software deployment value and status by product

Figure 4-3 builds on the information collected in Figure 4-2. It groups the
deployment by specific projects. You can use this to measure progress on a
specific project or compare the amount invested in software and services against
the expected benefit of that project.
Software Agreement Value Statement
Total # Licenses Licenses License Deployed Project

Project Proposed Deployed Remaining Value Value Investment
Document Management Intranet $346,000.00
IBM WebSphere Application Server 5 5 0 $9,500.00 $47,500.00
IBM WebSphere Application Developer 50 50 0 $250.00 $12,500.00
IBM DB2 UDB Enterprise Edition 10 7 3 $17,000.00 $119,000.00
IBM Content Manager 10 5 5 $5,000.00 $25,000.00
IBM Rational ClearCase 10 6 4 $200.00 $1,200.00
IBM Tivoli Distributed Monitoring 25 17 8 $1,000.00 $17,000.00
IBM Tivoli Enterprise Console 2 2 0 $12,000.00 $24,000.00
IBM WebSphere architecture and implementation services $10,000.00
IBM DB2 data modeling and database consolidation services $5,000.00
$261,200.00
Email & Collaboration $2,507,250.00
IBM Lotus Notes Seats 29000 29000 0 $25.00 $725,000.00
IBM Lotus Domino Server 10 10 0 $1,500.00 $15,000.00
IBM Lotus Sametime 29000 5000 24000 $25.00 $125,000.00
IBM Lotus Quickplace 29000 750 28250 $35.00 $26,250.00
IBM Rational ClearCase 10 4 6 $200.00 $800.00
$907,800.00
License Management $155,000.00
IBM Tivoli License Manager 500 300 200 $100.00 $30,000.00
IBM Tivoli License Manager quick start $5,000.00
$135,000.00
Figure 4-3 Software deployment value and status by product

5
Chapter 5. Software deployment

Phase 1: Prepare for
deployment
The will to win is nothing without the will to prepare to win. Vince Lombardi,
legendary football coach for the Green Bay Packers
The overall purpose of preparing for your software deployment is to build the
groundwork required for the successful deployment of your projects and
solutions. The steps you take early in the deployment process facilitate a better
understanding of your vision, enable successful kickoff meetings, and set the
tone for a positive partnership between you and IBM.
The following activities (shown in Figure 5-1) are discussed in this chapter:
Step 1: Create the Software Deployment Team (SDT)
Step 2: Review the deployment documentation
Step 3: Develop a high-level deployment plan
Step 4: Establish a deployment partnership with IBM

Step 1: Step 2:
Create Review
Software Documents
Deployment
Team
Step 3: Step 4:
Develop Establish
High-Level Deployment
Deployment Partnership
Plan
Prepare
Figure 5-1 Phase 1: Prepare for deployment
Customer example: GMR Corporation (GMR) defined an Enterprise

Business Sponsor (EBS), created a Software Deployment Team, defined
quick deployment wins, developed a high-level deployment plan, and
established a strong partnership with IBM.
5.1 Step 1: Create the Software Deployment Team

When you are confident that you know which products you will purchase, start
assembling the team that will deploy the products. Coordinate your efforts with
the IBM Software Account Manager (SAM) to create a team with members from
both companies that will decide on deployment plans and projects. The team will
also deal with any issues that come up in the deployment cycle.
The typical roles that make up the SDT are:

Enterprise Business Sponsor
Project leads
Information Technology (IT) architects (internal and from IBM)
IBM Technical Specialists
Services representatives
Partner representatives (if involved)

The members should understand the common purpose behind the impending
software purchase, decide on specific roles and responsibilities, and commit to
working together to meet your goals. There should also be a commitment to
known resource requirements.
5.1.1 Owners and participants

The responsible owners of this step are the EBS, the SAM, and the IBM Client
Executive. The participants are the same as the owners.
5.1.2 Inputs, tasks, and outputs

Table 5-1 shows the inputs, tasks, and outputs for the creation of the Software
Deployment Team (SDT).
Table 5-1 Inputs, tasks, and outputs for SDM Step 1: Create the SDT
Inputs Tasks Outputs
Need or requirement to form Create a Software Software Deployment Team

the team Deployment Team that established
includes the following Team members understand
representatives: their roles and
Enterprise Business responsibilities and are
Sponsor committed to the teams
Project Managers purpose and goals.
Internal IT architects
IBM Software Account
Manager
IBM Software Technical
Specialists
IBM Software
Deployment Architect
IBM Software Architect
IBM Services
representative
5.1.3 Benefits
The benefit of creating and maintaining the SDT is that the team members
understand their roles and then accept the ownership for the deployment
success.
Chapter 5. Software deployment Phase 1: Prepare for deployment 41

5.2 Step 2: Review the deployment documentation
After the SDT is formed, they should collect and review such documents as any
current or pending contracts, business context diagrams, solution requirements
and concepts. The purpose for the review is for the team to obtain a common
understanding of the documents that will be used in the deployment process and
the business needs that are driving your software purchases.
At this point, it is critical to obtain from the Enterprise Business Sponsor a

preliminary view of success and the expected value to be derived from the
software purchase. The SDT should keep this in mind for the entire deployment
process and use it to create the deployment plans. The team may need to revisit
these goals and success criteria to be reminded of the business needs and
prevent getting lost in the details of deployment.
The SDT should thoroughly understand the content, terms, and conditions of any
software purchase contract. Typically, this contains standardized terminology.
However, because each agreement may be customized to meet specific needs, it
may include special terms or clauses that need to be understood. The SDT
should understand these customizations and how they affect the deployment
process. If there are things that they dont understand, they should ask the team
negotiating the contract.

The owners are the EBS, SAM, and the IBM Software Deployment Architect or
IBM Software Architect.
The participants include the project managers, internal IT architects, IBM Client
Executive, IBM technical representatives and IBM service representatives. All
members of the SDT should participate in this step.

Table 5-2 shows the input, tasks, and outputs for this review.

Table 5-2 Inputs, tasks, and outputs for SDM Step 2: Review the deployment documentation
Draft contract Discuss buying decision List of open items for

Solution concept Ensure that the content and contract negotiation
Requirements and use cases terms and conditions of the Updated viability assessment
Business context diagram contracts are thoroughly Draft goals and milestones
and description understood document
System context diagram Study substitution clauses High-level mapping of
Conceptual architecture Understand the status of business initiatives to
Architectural decision maintenance and support projects
document (ADD) Discuss any expectations Draft mapping of projects to
Initial viability assessment Discuss license products
Organization charts management tools and Initial software utilization
IT standards processes and how to track report
Current IT environment deployment
Project descriptions Review the requirements,
solution concepts, business
context, conceptual
architecture, and architecture
decision document
Review and refine the initial
viability assessment (which
includes the results of any
Solution Assurance Reviews
(SARs)) and confirm the
solution
Document the linkages
between the planned
projects and products
5.2.3 Benefits
The benefits that result from this documentation review are that the SDT:
Has a common understanding of the business vision and goals
Agrees that the conceptual solution is viable and concurs with the viability
assessment
Confirms and agrees to the roles and responsibilities for both your company
and IBM
Has an awareness that the preparation phase of deployment has begun

5.2.4 Documentation review tips
Following are several tips for the documentation review:
Analyze the software in your inventory: Typically, you already own some
IBM Software from previous purchases. You may purchase new products that
are recently released or that you didnt purchase before. It is important to
perform a crosscheck between what you already own and what you are
purchasing. Where do you stand with the deployment of your previous
investment? Will some licenses from past purchases be used in conjunction
with some newly purchased licenses to support your projects? Perform
checks and balances to compare what you have with what you are going to
purchase.
Understand substitution clauses: If you are purchasing through a large,
multi-year contract or negotiated special terms and conditions, your contract
may include clauses that allow product substitutions. It is imperative that the
SDT understand the verbiage and reasoning behind any substitution clauses.
Substitution is not always straightforward and often has limitations in either
quantity or product eligible for substitution. For example, you may not be
entitled to substitute products between IBM Software product brands (such as
WebSphere for Tivoli or Data Management for Lotus). Understanding the
substitution rules now avoids surprises and assumptions that can lead to
costly delays in the projects later.
Understand the status of maintenance and support: You may have
purchased maintenance in the past either with licenses or separate from the
licenses. If you are making another software purchase, you will have new
maintenance explained and you may want to bring all of your maintenance
together. The SDT should determine which products are supported and who
is receiving that support. All members of the SDT must fully understand any
changes in the maintenance and support terms. Also, look ahead since the
new solutions are defined to forecast who may need to be educated on the
support process as you rollout the products.
Be aware of any global support needs: If you are a global company and the
solutions you will deploy are in multiple countries or regions, ensure that all of
your locations are educated in the support processes and are ready for the
projects. You will work closely with your IBM team to set up these global
locations for media, technical support in the local language and time zone,
etc. It is best to address these needs early and avoid frustration when trying
to accomplish this in a crisis. For more information about global deployments,
see Chapter 9, Managing global software deployment projects on page 71.
Be proactive: Through all of the above activities, the SDT should look ahead
and address the needs before they become critical issues. Frequent
discussions, a steady focus on the business goals, and early identification of
potential issues will help you be proactive.

5.3 Step 3: Develop a high-level deployment plan
The high-level deployment plan should be a general mapping of products to
projects and an assignment of ownership at the project level. The plan
accomplishes the following tasks:
Defines a list of initial deployment projects
Identifies the sponsors and owners for known projects
Groups the deployment into logical chunks
Defines a deployment timeline
This plan should also include ownership of any core infrastructure projects that
are prerequisites for the implementation and management of the specific
business oriented projects. Some examples include License Management,
Problem Management, Configuration Management, Performance and Availability
Management, Security, and Storage Management.
These types of projects, whether based in software or manual processes, should

be implemented before large-scale rollouts of the line-of-business projects to
ensure the business solutions can be supported and managed. Early
identification of ownership is critical because it provides the needed focus for
these projects. It also ensures that they are implemented in a common manner
across your entire enterprise, while minimizing redundant cost and effort.
Ideally, you buy software based on identified needs. However, you may
sometimes buy software based on projected needs or because of discount offers.
Also, you may purchase software without a set of known projects that will use the
software. Regardless of your reasons for buying the software, you should have a
set of business goals in mind that you can mold into potential projects.
These known or potential projects should drive the deployment planning and
activities of the SDT. The list of projects should be started before any final
contract negotiations conclude. The SDT should start by listing:
All of the known projects
All of the potential projects
The IBM Software brands and products (if known) that will be involved
The deployment locations
The project owners and their contact information
You may end up with a list of 60 projects and 60 separate project owners that will
deploy over one 100 IBM Software products over the course of three years. Or,
you may have three projects with one project owner and a broad identification of
IBM Software brands to be deployed in one year. The objective is to identify the
business goals, the projects that will support those goals, and the products
needed to implement the projects.

The owners of this step are the project managers and the IBM Software Architect
or IBM Software Deployment Architect. The participants include the EBS, SAM,
and all other members of the SDT.

Table 5-3 shows the inputs, tasks, and outputs for the high-level deployment
planning.
Table 5-3 Inputs, tasks, and outputs for SDM Step 3: Develop a high-level plan
Viability assessment Validate and refine the goals Updated goals and
Architectural decision and milestones milestones
document Group deployment into High-level, phased
Solution architecture logical chunks based on deployment plan
Component model business initiatives; assign Detailed mapping of
Internal interface ownership to the initiatives products to projects to
descriptions Refine the list of projects and business initiatives
Goals and milestones assign ownership Services requirements
Software deployment best Create a high-level Environment and
practices deployment timeline or infrastructure requirements
High-level mapping of phased execution plan for and projects
business initiatives to building the entire solution Updated license utilization
projects Assess gaps where services report
Draft mapping of projects to will be required
products Assess the need for
Initial license utilization infrastructure management
report projects
Review an initial license
utilization report and identify
where existing software will
be used and how new
software will be tracked
Determine any gap between
products with defined
projects and products that
require further project
definition
5.3.3 Benefits
The main benefit of creating a high-level deployment plan is that the SDT comes
to agreement and understands the various aspects of the deployment. It should

be clear how the products purchased will be implemented to meet the business
requirements and support the initiatives. Other benefits include:
A high-level deployment timeline
Identification of gaps in capabilities that may need to filled with services
expertise
Identification of gaps in identified projects that need additional attention
5.4 Step 4: Establish the deployment partnership

Successful deployments require a partnership between you and IBM, with all
members understanding their unique roles. These roles and requirements were
described in detail in Chapter 2, Roles and responsibilities on page 13. With
you as the Enterprise Business Sponsor leading and setting the vision, the rest
of the SDT helps execute on that vision. Three key activities that should occur
before or at the closure of a software agreement are:
Identify quick deployment projects
Create a strategy to measure and meet ROI expectations
Schedule deployment kickoff meetings
You should also be ready to review any findings from the IBM teams readiness
plan or gaps from the software deployment best practices (see Chapter 3,
Software deployment best practices on page 21, for more information). Both the
readiness plan and best practices are designed to help you be successful with
your deployments.
Customer example: The Chief Information Officer (CIO) of a major financial

institution in Sweden recognized that the deployment of their enterprise wide
software agreement required the focused efforts of a central team. Working
with the CIO, IBM created a customized Web site that allowed the interested
and authorized parties to go to one place to gather details about their
enterprise agreement. At the CIOs request, IBM established a central point of
contact to assist with contractual questions from the branches that were
spread across four countries (regions). This type of leadership from the CIO
greatly improved the communication and understanding of their very complex
software agreement.

The owners include the Enterprise Business Sponsor and all other members of
the SDT. The participants include key stakeholders and sponsors, the IBM Client
Executive, and the extended teams from your company and IBM.

Table 5-4 shows the inputs, tasks, and outputs for establishing the deployment
partnership.
Table 5-4 Inputs, tasks, and outputs for SDM Step 4: Establish the deployment partnership
Updated goals and Confirm buying decision and Finalized goals and
milestones vision milestones
High-level phased Identify quick deployment Quick deployment win plan
deployment plan wins Validated high-level
Detailed mapping of products Define deployment deployment plan
to projects to business milestones and Validated mapping of
initiatives measurements products to projects to
Services requirements Review skills and projects business initiatives
Skills gap analysis gaps and define a strategy to Validated gap analysis
Environment and address Validated environment or
infrastructure projects Review and discuss any infrastructure projects
roadblocks that could impact Roadblock action plan
deployment Scheduled kickoff meeting
Validate project owners
Schedule date for first kickoff
meeting
5.4.3 Benefits
You should realize the following benefits from the establishment of a deployment
partnership:
The SDT has an understanding of the goals and milestones associated with
the software purchase.
The SDT agrees to the high-level deployment plan.
There is a strategy and timeline for the software deployment.
There is a strategy to address skills and project gaps.
The first deployment kickoff meeting is scheduled.

6

Phase 2: Refine and promote
the plan
The next phase of your software deployment should, ideally, take place after any
sales are complete and contracts are finalized. This allows the Software
Deployment Team (SDT) to understand any last minute changes to the contracts
and understand the documents prepared earlier. After you finalize and agree to
the deployment plans, you are ready to start promoting the plans to the rest of
your enterprise. This promotion activity continues throughout the timeline of the
deployment plan, but starts by holding an initial kickoff meeting.
The following activities (see Figure 6-1) are discussed in this chapter:
Step 5: Refine the deployment plan
Step 6: Finalize the deployment plan
Step 7: Conduct the initial deployment kickoff meeting

Step 5: Step 6:
Refine Finalize
Deployment Deployment
Plan Plan
Step 7:
Conduct
Deployment
Kickoff
Refine and Promote

Figure 6-1 Phase 2: Refine and promote the plan
Customer example: The kickoff meeting was crucial at GMR Corporation

(GMR). They executed a kickoff with the EA team and the product captains. To
ensure that IBM was on the same page, they also met separately to help
formulate and validate GMRs plans. To ensure that this kickoff was not a
one-time event with limited impact, GMR executed EA Land as the one-year
EA anniversary approached. This event was effectively a trade show where
GMR Technical Services showcases solutions and their deployment process.
They also uncovered opportunities to extend the technology further into their
enterprise.
There were 700 confirmed GMR Information Technology (IT) people at EA

Land, 500 in the demo sessions. That is a great turnout for this type of event at
GMR, given that there are 1200 total people in IT who were aware of the
event.
Dave Backman, IBM Software IT Architect, for GMR Corporation.
6.1 Step 5: Refine the deployment plan

As you reach the final agreements on any pending software contracts, you may
have last minute changes. SDT must review these changes after they are in a
signed contract to evaluate how they may affect the deployment plan and

timeline. This should be a complete review of all documents to verify that the
expected goals, requirements, products, and projects are still valid. The team
should also review the architecture, components, interfaces, and any
performance modeling that was done. The key output from this step will be a
refined deployment plan.
If you have been following this deployment method, you should already have a
list of known and potential projects with assigned owners. After you finalize the
software agreement, the SDT should finalize that list and check for any
last-minute additions or changes. Since it is unlikely that you will start every
project right away, it is important to meet with the project owners and explain the
deployment plan and timeline. This shows the project owners that their needs are
planned for and their projects will be addressed within an agreed to time frame.
Some projects may be defined in sufficient detail and occur early enough in the
timeline to perform project level deployment planning at this time. For these
projects, the SDT works with the project owners to perform any necessary
capacity and performance modeling. They should recommend a physical
architecture and define or refine hardware and software requirements. They
should also discuss environmental and infrastructure requirements for
deployment. The IBM members may initiate a Solution Assurance Review (SAR)
for the project at this time, if necessary.
With this step completed, the majority of the planning for a successful
deployment of the software is completed. Good planning leads to a smooth
deployment.

The owners are the project managers and the IBM Software Deployment
Architect (SDA) or IBM Software Architect (SWA). The participants include all
members of the Software Deployment Team.
6.1.2 Inputs, tasks and outputs

Table 6-1 shows the inputs, tasks, and outputs for this step.

Table 6-1 Inputs, tasks, and outputs for SDM Step 5: Refine the deployment plan
Final contracts Review the past activities, Refined physical deployment

Architectural overview documents, and decisions plan
Component descriptions Perform any necessary Refined physical architecture
Interface descriptions performance and capacity Refined environmental and
Business initiatives modeling infrastructure requirements
Revisions to architectural Recommend a physical and systems management
plans architecture plan
High-level phased Refine hardware and Proposed project controls
deployment plan software requirements Refined quick deployment
Detailed mapping of products Discuss environmental and win plan
to projects to business infrastructure requirements
initiatives Create a draft of project
Quick deployment win plan controls
Goals and milestones Update the deployment and
Software deployment best quick deployment win plans
practices as needed
Gap analysis
6.1.3 Benefits
The benefit of this step is that the SDT revisits and refines the deployment plan,
project details, deployment timeline, and supporting plans and documents based
on any changes to the software contracts. It should be well understood what was
purchased, why it was purchased, and how it will be deployed to meet the
business goals and maximize the investment.
6.2 Step 6: Finalize the deployment plan

As the Enterprise Business Sponsor (EBS), you may have final approval
authority of the deployment plan, timeline, and supporting documentation. Or,
you may need to get final approval from the Chief Information Officer (CIO), Chief
Executive Officer (CEO), Board of Directors, or another governing body within
your company.
This step in the deployment method is the time to present the finalized plans to
this approval authority and promote the upcoming activities. You should highlight
the work done in planning and preparation by the SDT and get buy-in from the
project managers.

The owners include the Enterprise Business Sponsor and the IBM Software
Deployment Architect or IBM Software Architect. The participants include all
members of the SDT, as well as key stakeholders and sponsors.

Table 6-2 Inputs, tasks, and outputs for SDM Step 6: Finalize the deployment plan
Refined physical architecture Review and finalize the Final physical architecture
Refined deployment plan, deployment plan Final deployment plan
deployment timeline, and Discuss any appropriate Final deployment timeline
systems management plan migration strategies Final operational model
Proposed project controls Discuss any appropriate Final systems management
Refined quick deployment conceptual data model for plan
win plan legacy data Final project controls
Software deployment best Finalize the recommended Final quick deployment win
practices physical architecture plan
Finalize the systems Final goals and milestones
management plan Software deployment best
Gain agreement on project practices understood and
controls agreed upon
Update the quick deployment
win plan, if needed
Finalize project ownership
Finalize software deployment
milestones and metrics
6.2.3 Benefits
The benefits of going through this step are:
Executives are aware of the work done by the SDT to plan and prepare for a
successful deployment.
Final approvals are obtained on the plans and schedules.
Goals and milestones are affirmed.

6.3 Step 7: Conduct the initial deployment kickoff
meeting
Armed with the final plans, schedules, vision, and list of projects, it is time to
conduct the initial deployment kickoff meeting. This is called the initial meeting
because of the importance of repeating this type of kickoff meeting often. This
meeting is attended by the stakeholders from your company and from IBM and
should include team project leads, IT leads, and lines of business leaders. This
meeting should create awareness, understanding, and enthusiasm for the
deployment activities that are about to begin.
The meeting should be led by you, the Enterprise Business Sponsor, as the
leader within your company of the software deployment. Presentations may be
made by the members of the Software Deployment Team, IBM client team or
executive or other leaders that will be supporting the deployment effort. A
high-level agenda should include:
What software, hardware, and services were purchased
Why the purchase was made
The final deployment plan
The final deployment timeline
The overall vision and business goals should be explained to keep the
discussions in line with the desired results. The SDT should present the roles
and responsibilities described in Chapter 2, Roles and responsibilities on
page 13, and the software deployment best practices described in Chapter 3,
Software deployment best practices on page 21.
Dozens of people may attend this kickoff meeting. Your goal is to inform the
participants of what is to come and to create excitement and energy for the
deployment. This type of meeting should be conducted with as many people as
possible, perhaps at various locations. To maintain the enthusiasm, you should
also conduct regular update meetings or events to celebrate your successes and
highlight the activities to come.
The concept of presenting to as many people as possible is important. Do not

forget to invite and include the end users and final implementers in your meeting.
They have as much to do with the success of the deployment as does a top-level
executive.

The owners include the EBS, IBM Software Account Manager (SAM), and the
SDA or SWA. The participants include key stakeholders and sponsors, end users

representing key projects, project managers, the extended team from your
company and IBM, and all members of the SDT.

Table 6-3 Inputs, tasks, and outputs for SDM Step 7: Conduct initial deployment kickoff meeting
Final contracts Present the vision that drove Synergy and enthusiasm for
Architecture plans and the software purchase the upcoming deployment
descriptions Link the products purchased High-level understanding of
Final high-level deployment to the business initiatives and the contracts
plan and timeline vision Communicated vision and
Goals and milestones Discuss the high points, business value
IT vision terms and conditions, and Understanding of roles and
Software deployment best critical aspects of any responsibilities and the
practices contracts software deployment best
Roles and responsibilities Communicate the business practices
value and benefit
Show the business context
and high-level architecture
Present the high-level
deployment plan and timeline
Discuss the breadth of the
deployment (local, regional,
national, or global)
Discuss the roles and
responsibilities
Discuss any known
roadblocks and the plan to
overcome
Communicate the quick
deployment win plan
Discuss the software
deployment best practices
Present the key benefits of
the major driver products
Arrange for demonstrations
of key products if necessary

6.3.3 Benefits
The benefits from this and similar meetings are:
A reinforced partnership between you and IBM
Communication of the vision and goals
Awareness, understanding, and enthusiasm for the deployment
An understanding of key responsibilities
SDT credibility and accountability

7

To deploy software is to put it into use. Even the best software can be of no
benefit if it is not deployed. You can take this concept a step further and look at
the business value you receive from putting the software into use.
Up to this point, we discussed the planning and preparation for the software
deployment, the importance of measuring the value that you will realize, and
some of the preliminary steps necessary to market your vision and create an
environment ready for success. Now comes the time to take what was planned
and what is on paper and make it a reality through systematic execution of the
plan and the deployment of the software.
The purpose of this step is to execute the quick deployment win plans, ensure
early deployment success, and execute the deployment plans and projects that
follow the quick wins. Throughout this iterative process, you must also keep your
eyes open for changes in the business needs and be prepared to adjust the
plans as needed to ensure you can use your software investment to the fullest
potential. You should also search for ways to apply the successes enjoyed from
this deployment effort to future business plans.
The following activities (see Figure 7-1) are discussed in this chapter:
Step 8: Achieve quick deployment wins
Step 9: Execute the deployment plan

Step 10: Identify new business needs
Step 11: Update the business plan

Step 8: Step 9:
Achieve Execute
Quick-wins Deployment
Plans
Step 10: Step 11:

Identify New Update
Business Business
Needs Plan
Deploy
Figure 7-1 Phase 3: Deploy software
Customer example: GMR Corporation (GMR) executed quick wins, defined

and executed other deployment plans, and identified new opportunities to
repeat and build on the successes of the past year.
7.1 Step 8: Achieve the quick deployment wins

The purpose of this step is to demonstrate success early and build momentum
and credibility in the beginning stage of deployment. This can be compared to the
training wheels used to give a child confidence when learning to ride a bicycle. If
you start with your largest and most difficult project, there are greater risks of
delays and cost overruns, which can result in less-than-stellar deliverables. Get
your feet wet with a few small projects. Test the processes you developed while
you were planning the deployment. Make adjustments or alter timelines based on
what you learn here.
The Software Deployment Team (SDT) should carefully monitor the early
projects to ensure you can being with the expected fast start. The team should
stay focused on the early business goals to reduce scope creep and to provide
the value realization expected.

The owners include the Enterprise Business Sponsor (EBS) and the IBM
Software Deployment Architect (SDA) or the IBM Software Architect (SWA).
The participants include the project managers, IBM Software technical

representatives, IBM services representative, any IBM support representative or
contact, and key stakeholders assigned to the selected quick deployment win
projects.

Table 7-1 Inputs, tasks, and outputs for SDM Step 8: Achieve quick deployment wins
List of projects and owners Assign project managers to Quick deployment win
Project plans for quick quick deployment win projects projects competed
deployment wins (internal, IBM, or third party) Initial business value realized
IBM readiness plan Verify and augment the Internal reference groups
Software deployment best capabilities of the quick
practices deployment teams assigned
to the projects
Execute the quick deployment
win plan
Manage the projects with
project controls
Conduct regular meetings
with the project owners
Monitor progress of quick
deployment win projects
against plans and make
adjustments as needed.
Implement recommendations
defined during readiness
discussions
Address and resolve technical
issues that may arise
Maintain close contact with
project owners, stakeholders,
and sponsors
Execute early phases of the
education plan
Monitor the satisfaction of the
solution users
Track software license usage
Chapter 7. Software deployment Phase 3: Deploy software 59

7.1.3 Benefits
The benefits you should see as a result of this step are:
Confidence in the deployment plan and SDT are built.
Technologies are tested and understood.
Credibility of the EBS, SDT, and IBM are reaffirmed.
Technicians are trained.
Internal reference groups are created that help support additional projects.
7.2 Step 9: Execute the deployment plan

Now that you have some successes, it is time to start the longer process of
deployment as defined in your deployment plan. It is now time to tackle the bigger
projects. During this time, project management and controls are critical. It is also
important to maintain your awareness of the satisfaction of the user community
and of the stakeholders and sponsors.
This is an ideal time to repeat the deployment kickoff meetings held earlier and
provide a status report on the quick successes and reset the expectations for the
rest of the deployment. These meetings can now include live demonstrations of
the early projects to reinforce the success and reiterate the vision.
During this step, the SDT should maintain and manage to two lists:
A list that identifies existing (underway) projects
A list that identifies potential projects
Refer to Chapter 8, Managing software deployment projects on page 65, for

more information. The challenge for the SDT is to move projects from the
potential list to the existing list at an acceptable rate that burns the software
purchased and moves you closer to, or even beyond, the expected value.

The owners are the EBS and the SDA or SWA. The participants include the EBS,
the entire SDT, key stakeholders (for the duration of their assigned project), IBM
representatives from services and support, the IBM Client Executive, and project
teams developing and integrating the final solutions.


Table 7-2 Inputs, tasks, and outputs for SDM Step 9: Execute the deployment plan
Final deployment and Advertise quick deployment Deployment milestone status

physical architectures wins with meetings or open reports
Software deployment best house events. License usage reports
practices Assign deployment project Value realization status
IBM readiness plan managers reports
Final environment and Educate additional users on Competed projects
infrastructure requirements IBM support processes Deployment of software and
Final deployment plan Verify and augment the associated business
Final systems management capabilities of the value achieved
plan deployment teams assigned
Final project controls to the projects
Final goals and milestones Begin executing projects per
the deployment plan
Manage the projects with the
project controls
Monitor progress against the
plan and make adjustments
as needed
Address and resolve
technical issues that may
arise
Maintain close contact with
the stakeholders and
sponsors
Monitor overall satisfaction
7.2.3 Benefit
The benefit of this step is the achievement of the defined business goals. This
primary benefit is supported by the success of you, the Enterprise Business
Sponsor, the rest of the SDT, and the successful partnership with IBM.
7.3 Step 10: Identify new business needs

Often there is some growth forecast over the term of a multi-year software
agreement that may not be identified to a project at the time the purchase is
made. If the identification of projects that use this software is vital to your value
realization, then it is the responsibility of the SDT to assist you as the EBS in
discovering or creating those projects. Also realize that as new projects are
discovered, there may be a need to purchase additional software to augment that

which you already own. This software that needs project identification is referred
to as the software gap.

The owners include the EBS, the Software Account Manager (SAM), and the
SDA or SWA. The participants include the project managers or stakeholders that
drive the requirements to improve your business.

Table 7-3 Inputs, tasks, and outputs for SDM Step 10: Identify new business needs
Deployment plan Revise the deployment plan Software gap is reduced or

Goals and milestones to include the new eliminated
Gap analysis requirements New projects are identified
New business requirements Seek out new demand Value realized is increased
Manage these new projects
as done in Step 9
7.3.3 Benefits
The benefits of this step include:
Higher usage of purchased software
Increased value received from the original software purchase
Increased visibility of the business benefits provided
Satisfied stakeholders and end users who received new technology and
improved processes
7.4 Step 11: Update the business plan

The final step in the Software Deployment Method is to take the success from the
deployment, along with any challenges, and apply them to your future business
plans. This also means returning to the first few steps in Chapter 5, Software
deployment Phase 1: Prepare for deployment on page 39, and repeating the
cycle for successful deployments.

The owners include the EBS, the SAM, and the SDA or SWA. The participants
include the extended IBM Software Technical team.

Table 7-4 Inputs, tasks, and outputs for Step 11 of SDM

Projects identified in Step 10 Incorporate any lessons Refreshed strategy to meet

that were not rolled into the learned from the recent the new business needs
current deployment plan deployment into future plans
Goals and milestones Determine the technical
Software gap analysis needs of the identified
New business requirements projects
Apply current software
inventory and new software
purchases toward the future
deployment plans
Return to Phase 1, Step 2
7.4.3 Benefits
When the Software Deployment Method is incorporated into your standard
processes, the end result is a successful deployment. This takes focus on the
overall success and progress against the deployment plan. Other organizations
will notice your success and request the implementation of additional business
requirements. If you have a thorough method for deployment, then you can meet
that need.
You will also see an improved partnership with IBM by following the steps
detailed in the previous chapters. You gain the benefit of many professionals
working toward your success, and IBM has the satisfaction of knowing we
assisted you in meeting your goals.

8
Chapter 8. Managing software

deployment projects
This chapter provides helpful hints on managing software deployment projects.
Unlike other types of projects, software deployment has it own set of challenges
and opportunities. This chapter is not a substitute for a formal project plan
completed by a certified project management professional. We recommend that
if the funding is available, you should hire a professional project manager. Again,
we emphasize the importance of an Enterprise Business Sponsor (EBS). The
EBS plays a key role in overall success at all levels of deployment activity.
As described in Chapter 4, Value realization on page 31, the value statement

and the value timeline need to be defined as close to the closure of your software
agreement as possible. Neither of these documents is fixed. Instead, they are
expected to adjust as deployment projects are executed, new projects are
defined, and new software is purchased.
A key point is that you must view the deployment holistically. To maximize
success, you must allocate all software licenses to projects as early in the
deployment life cycle as possible. The preferred time for this effort is in final
stages of the negotiation. This is because all informed parties are at the table at
this time. Too often one or two projects are defined and the momentum is lost. It
is imperative that a concerted effort be taken to find homes for all licenses in your
agreement.

At the beginning of this redbook, we defined deployment as putting software into
use or action. Loading software onto a desktop or a server and never using it
adds no value. When you plan and position deployment projects, ensure that the
recipient organizations understand why this implementation is taking place and
how best they can leverage these changes.
This chapter provides information that will help you manage a successful
deployment project that maximizes the value you receive from your software
purchase. You see again the involvement of the Software Deployment Team
(SDT). Refer to Chapter 2, Roles and responsibilities on page 13, where we
introduce the IBM team with whom you will be working. We also define key
representatives from your team. You may not recognize or use the titles that we
selected, but hopefully you will recognize the responsibilities.
Customer example: GMR Corporation (GMR) was particularly interested in

developing a successful deployment game plan. To this end, they worked
closely with their IBM Information Technology (IT) Architects to blend the
Software Deployment Method (SDM) with their internal project planning
process.
8.1 Project timing

From the SDTs perspective, a project is any effort that requires the installation
and use of software licenses. Projects can use licenses at the beginning, middle,
or end of a predefined deployment life cycle. It is not necessary that every license
be in deployment motion immediately or simultaneously.
A project may be as straightforward as installing a collaboration application on

computers with a dozen users. It can also be as simple as delivering an
upgraded version of an application to all of its current users. Or a project can be
as complex as installing custom-written software at locations around the world,
where thousands of licenses are required or installed as part of the process.
Some projects last a week, while others can last a year. Clearly, project
management rigor that is applied varies with the projects priority, complexity, and
duration.
8.2 Getting started

When the software purchase is consummated, there is typically a vision for how
the software should be used. There is a high-level algorithm developed for
executing the vision. The algorithm factors in:

The number of servers and workstations involved
The number of gigabytes (GBs) of storage that are required to store the
purchased software
The SDTs hard work begins when the vision must be mapped into deployment
activities (projects).
There is no formula or standard when it comes to determining how many projects

are required. Typically, on the first day of deployment, the SDT has a list of
potential and funded projects, project owners, and what software each project
will use. This list likely does not contain enough projects to deploy all the
software purchased, but it starts things moving. Hopefully, it creates some
successes that generate enthusiasm and demand for the remaining products
that are in the portfolio. See 7.1, Step 8: Achieve the quick deployment wins on
page 58.
As an example of getting started, a purchase agreement for $10 million U.S. may
specify $2.5 million in software to be used from four of the five IBM Software
Group brands. The SDT works with each brand's sales person and technical
sales person to determine an inventory for their $2.5 million. Then the SDT aligns
the software with the anticipated projects, identifies an owner for each project,
determines the start and end dates for each project, and sets a timeline for
deployment. The IBM Software Architect assigned to the account is responsible
for ensuring that all of the software in the agreement (across brands) integrates
smoothly, but in some cases, the projects may not need to integrate at all. For
example, there may be a totally independent Tivoli project that may not touch a
data management project. However, many times projects need to integrate.
Here is how an experienced IBM Software Deployment Architect (SDA)

describes how he begins:
Very quickly after a new software purchase occurs, I need to think about projects
that can burn software licenses. I begin my conceptualization by going back to
read and thoroughly understanding the contract. I then meet with the Software
Account Manager (SAM) and whoever else was involved with the purchase and
understand where and how the customer envisioned using the licenses. It is
important to write down the project list on paper. Memories are short, and by
documenting this, we and the customer stay on the same page.
After the project list is documented, I apply good project management principles.
For example, I create a work breakdown structure for each project. I make sure
we have a project lead allocated to individual projects. I may have to request
management to identify when the people would be allocated. It is crucial to
allocate one IBM focal point for each project as it becomes active. There should
be one IBM counterpoint to each customer focal point per project.
Chapter 8. Managing software deployment projects 67

8.3 Managing the success of your first project
There is a saying, You only get one chance to make a good first impression.
This certainly applies to deployment. The SDT should work with the EBS to
select the first project carefully and manage it so that it deploys on time. This
builds confidence and momentum early in the deployment cycle. It also gives the
EBS a great deal of credibility with peers and line-of-business stakeholders.
Early in the deployment, your executives should exclaim, Look at this! Its terrific
that were seeing value already! This success should be advertised and
celebrated with all present and future stakeholders.
Every account is different, but you have to do all you can to help ensure the first
project is successful. If the SDT believes they cannot control the projects,
including which ones should be deployed first or who should be assigned to lead
them, it may be a sign that they are not working with the true EBS. The SDTs
challenge is to partner with the real owners, those who care most about the
success of the projects, and work with them to make things happen.
8.3.1 Managing at the milestone level

The most valuable advice that experienced Software Deployment Teams want to
share with others is to manage at the milestone level. Let the individual project
leaders manage the details of their projects (via detailed Gant charts produced
by Microsoft Project or other project management tools). There may be dozens
of projects underway. The SDT cannot let itself get bogged down into the details
of managing each project.
The SDT may advise project managers as they create their project plans, help
ensure that projects have clear charters, or review completed plans, because an
extra set of experienced eyes on these items can be quite helpful. The SDT can:
See that each project starts well
Check with the teams at critical points to help ensure things are on schedule
Help ensure that action items required to keep projects moving are acted
upon
It is wise for the SDT to prioritize projects, too. They should spend more of their
time on the hottest projects. Even then, they should manage them at the
milestone level. As one SDT member said, We need to know what needs to be
done to plan a project, but we dont need to be the ones doing it. Were not the
executors.

8.3.2 Handling project management challenges
Over a multi-year deployment period, even the best SDTs encounter some
challenges. Situations that SDTs should be prepared to handle are:
The products purchased are now not matching the current requirements
Scope creep
Inexperienced project managers
Products purchased are not matching current requirements

As software deploys, you may discover that you have a shortage of licenses in
one area or that you have much more than you need in another area. While this
can be challenging, we recommend that you speak with your vendor sales
representative and see if an arrangement can be made to adjust software
quantities.
Scope creep
Scope creep refers to projects that gradually extend beyond their original
charters and add functions that require software that was not in the original
agreement. Scope creep can be harmful, because it can take a project off on a
tangent and cause schedules to be missed. It is imperative that the EBS stay
focused on the major deployment goals.
The inexperienced project leader

The EBS needs to help ensure that they have project leads with excellent project
management skills. Project management certification is available and can be
suggested in certain situations. Also, the work product examples in the
Appendix A, Software solution work products on page 87, may be helpful to
project leaders.
Chapter 8. Managing software deployment projects 69

9
Chapter 9. Managing global software

deployment projects
If you are reading this chapter, chances are you have an interest in deploying
software at several locations around the world. The lessons and experiences
provided in this chapter help you effectively plan and manage a deployment that
spans two departments in one building, two buildings in one city, two cities in one
country (region), or two countries (regions) in one world.
The word global is used liberally to describe the landscape of a business. In its
simplest form, global implies that you are doing business in more than one
location. This is an unfortunate minimization of a challenge that in itself can
absorb the time of several full-time project managers and executives. Doing
business globally implies geographical, cultural, and language barriers that must
be overcome before business can be effectively executed. Deploying software is
no different. Proper planning must be done if the breadth of software utilization is
to be maximized.
IBM was one of the first companies in the United States to tap into the worldwide
market. Its presence in the major and minor geographies of the world has
become an increasing source of business growth. As such, global software
deployment happens frequently. Global deployments pose challenges above and
beyond those faced in deploying software within a single location. As discussed
in Chapter 3, Software deployment best practices on page 21, self-sufficiency

is key to the deployment success. This means that ownership must be
established for the success of the software purchased by your business.
IBM is one of few companies that actually has the capability to service global
customers effectively. That being said, doing business in over 100 countries or
regions with unique cultural, political, and business guidelines is complicated and
fraught with potential pitfalls. It is because of these pitfalls that this chapter is
included in this redbook. We are motivated to maximize global customer
success.
First, we recommend that you establish a global lead to be the project manager
and coordinator of all software deployment activities going on around the world.
This person should meet the following criteria:
Have excellent project management skills as well as experience on the global
stage working with a variety of people from differing cultural backgrounds.
Have experience managing complicated projects. This implies that they can
handle complicated products, and combinations of products, as well as
complicated geographical challenges.
Be a self starter, who is constantly looking for opportunities to increase the
deployment footprint.
We recommend that you have a team of project managers with a primary,

secondary, and tertiary responsibility for software deployment success.
Primary sites = full-time coverage: A deployment site where the majority of
deployment occurs. Full-time, dedicated, and focused deployment personnel
who are hands on and proactive should be assigned. They are normally
located in the city where most of the strategic global decisions are made.
Their responsibilities span the entire scope of deployment from demand
generation to deployment success. Their goal needs to be to maximize
deployment in the given city. You may have several primary deployment sites
depending on the configuration of your business. For instance, a major
financial institution may have headquarters in New York City for the U.S.,
China (Hong Kong S.A.R.) for Asia, and Paris, France for Europe. It is likely
that this company would have major deployment activities in all three cities.
We recommend that each of these cities has a dedicated project manager
focused on deployment.
Secondary sites = part-time coverage: A deployment site where significant
deployment activity occurs, but not as significant as the primary site or sites.
A part-time project manager should be assigned in these locations. They are
proactive or reactive in this deployment as the situation requires. This means
that they are monitoring and tracking existing projects, reacting to crisis
situations, and keeping their eyes open for opportunities to deploy more
software.

Tertiary sites = on-demand coverage: A deployment site where minor or
less complicated deployment projects occur. This situation receives tertiary
attention from a project manager. This project manager is only engaged when
they are asked. They are not normally probing for new software demand.
Your IBM team will align their coverage in each city around the world based on
your requirements. Under normal circumstances, support is maintained at a level
that is commensurate with the deployment activities that occur in any given city.
This IBM team generally consists of representatives from all parts of IBM, such
as a Global Client Executive, a Global Software Account Manager, and perhaps
a Global Software Deployment Architect.
9.1 How the coverage model works

The size of a software agreement does not necessarily trigger the application of
this type of global coverage model. When the high-level deployment plan is
drafted, the cities in which software deployment will occur should be recorded.
You and your IBM team should meet to assess the kind of coverage that will be
required.
If you decide to assign a global project manager, identify this person as quickly
as possible. This global lead needs to identify the countries or regions (see
Table 9-1) and cities where deployment will occur, how much, and when. Ideally,
you will assign project leaders within each location that has significant
deployment activity.
Table 9-1 Sample global software deployment coverage model
Location Company ABC Company XYZ
Americas John Williams

(New York) Tertiary
Americas Dawn Dish

(Other NA) Tertiary
Latin America Ricardo Ferano Ricardo Ferano

Secondary Secondary
EMEA John Parker Ted Fonderland

Primary lead city Primary lead city
Tokyo
Singpore/India Choong Pong

Tertiary
Chapter 9. Managing global software deployment projects 73

Location Company ABC Company XYZ
China (Hong Kong S.A.R.) Erris Pow

Secondary
Korea Sanghoon Hark

Tertiary
Australia Susan Potville

Tertiary
9.2 Global deployment checklist

Experience has shown that a Global Project Lead (GPL) will have a difficult time
focusing on multiple deployment sites all over the world. This is because certain
sites will demand greater levels of attention at the expense of lesser sites that are
perhaps not as problematic. A good example of this is a primary site where the
majority of the software is being deployed. This site by nature absorbs much
more of the project leaders attention. To combat this issue, a list of key global
activities is provided in the following section. Revisit this list periodically to ensure
that all important work items are being done.
9.2.1 Global level activities (primary, full-time coverage)

The following activities take place at a primary, full-time coverage site:
Your decision making team determines, prior to the software purchase, that
software will be deployed in multiple cities, countries (regions), or both around
the world.
Your executive team assigns a GPL to focus on software deployment at all
sites.
The GPL meets with the Software Deployment Team (SDT) and obtains a full
understanding of the buying decision.
Primary, secondary, and tertiary deployment sites are identified.
The GPL works with the SDT to draft a high-level plan for software
deployment with high-level milestones. All known deployments sites are
placed in the timeline. This high-level plan must be dynamic. It is adjusted as
deployment sites are discovered and milestones are achieved.
The GPL obtains guidance on business goals and how return on investment
(ROI) will be measured. See Chapter 4, Value realization on page 31.
The GPL begins aligning site leaders in each deployment location. This
alignment should be done in sequence with the deployment plan.

The GPL identifies a team within the vendor who will assist them at the
worldwide level.
A Document of Understanding (DOU) should be written between the
customer and the vendor.
The vendor should commit to assigning or aligning resources with all
deployment sites around the world.
The vendor should provide names and full contact information.
The GPL determines how software will be customized and implemented to
match requirements. For example, they may decide to build a gold disk that
can be used to ensure that all software deployment is identical on every
desktop and server around the world.
The GPL needs to monitor software deployment activity around the world to
ensure that all activity falls within standard guidelines set at a global level.
The GPL meets periodically with all site leaders to review deployment
progress and milestones. This meeting should include all sites that may not
yet have begun deployment of software.
The GPL schedules periodic meeting with your decision making team and the
site leaders to checkpoint deployment progress and raise any critical issues.
The meetings are used to review deployment milestones and value realization
milestones.
The GPL remains aware of all new software purchases around the world.
When these purchases are finalized, all software should be immediately
moved into software inventory.
The GPL circulates a status report monthly to your decision makers, business
sponsors, and the entire SDT around the world.
9.2.2 Local sites (secondary, part-time coverage)

The following activities take place at a secondary, part-time coverage site:
Site leaders meet with local vendor teams frequently to discuss deployment
plans and challenges.
Site leaders report status to the GPL on a predefined frequency. They report
deployment status, accomplishments, challenges, and escalation points.
Site leaders drive deployment activities in their locations.

9.2.3 Local sites (tertiary, on-demand coverage)
The following activities take place at a tertiary, on-demand coverage site:
Tertiary coverage is available in reactive situations only.
Each deployment site that is not primary or secondary should at least have a
named resource aligned with it to monitor and escalate challenges that may
impact the deployment progress.
Your vendor should also provide tertiary coverage at each one of these sites.
This coverage should be aligned with the products, solutions, or both that are
being deployed at each site. The right expertise should be available to help
resolve issues quickly.
9.3 More about the global deployment activities

This section offers further details about the items in the global deployment
activities list.
Identify the Enterprise Business Sponsor

One of the deployment best practices (see Chapter 3, Software deployment best
practices on page 21) is that you should have a global sponsor who is focused
on the global deployment success. This does not have to be one person. It can
even be a team of three to four people with one person assigned to each
geography. It is important that you align resources with each important
deployment location.
Obtain a list of software deployment locations

The EBS should provide a list of global deployment locations and work with the
GPL to identify the primary, secondary, and tertiary deployment sites, based on
the coverage model. One project leader should be assigned per geography. This
person should work in that geography with the deployment professional who is
assigned.
Arrange full-time and part-time coverage

Per the description of the coverage model, resources should be assigned
full-time and part-time to satisfy the deployment demands.
Arrange on demand (tertiary) coverage

Typically, the on-demand contact is from the technical team in the city, country, or
region. If a technical contact is not available, assign the manager of the technical
team. When the need arises, the manager assigns the appropriate technical
person from their team. For these types of deployment efforts, you usually work

with one product, such as systems management or application server, that is
quite specific to your needs. In this case, the appropriate on-demand person may
be a WebSphere or Tivoli specialist from IBM.
Conduct bi-weekly meetings with global deployment teams

Every other week, most GPLs hold two or more status conference calls: one call
with the team in the primary geography and one call each with teams in the other
geographies. The GPL roles up all the summary information into a status report.
A level of coaching should occur in these calls. GPLs should push secondary and
tertiary contacts to drive deployment. They cant be passive. They must be
proactive.
Checkpoint deployment satisfaction

The GPL should meet with teams in each geography. While there is a team in the
primary site, there are also teams in the local sites. Part of the GPLs role should
be to travel every three to six months to meet each local deployment team and
help ensure they are on top of what is happening.
Provide regular progress reports

The GPL should send frequent progress reports to the primary, secondary, and
tertiary people, so they are informed about the progress in all of the geographies.
The GPL needs to communicate the data and the stories behind the data. For
example, communicate what the data is telling, or why the person in Paris should
care about what is happening in China (Hong Kong S.A.R.). By interpreting the
data and guiding decisions, the GPL builds credibility by demonstrating a
combination of technical, project management, team building, and business
skills.
9.4 A global deployment coverage example

Nestl is an example of a customer who understands how to deploy software
globally. In 2001, Nestl initiated their GLOBE project, one of the largest and
most ambitious restructuring projects ever launched in the industry. GLOBE
standardizes Nestl on best practices for manufacturing, sales, marketing, and
all relevant business worldwide. It creates common data formats and a common
infrastructure for managing Information Technology (IT). The Nestl Globe
Competence Center (GCC) defines Service Management with Tivoli under the
leadership of Francisco Esteve. The GCC then distributes structures to the Globe
Centers of the four primary zones around the world (Europe, Americas, Asia
Oceania Africa, and the headquarters in Vevey, Switzerland) where local
management can use it. This is one example of how Nestl has embraced global

software deployment. Figure 9-1 shows the assignment coverage for the
deployment that follows the model described in this chapter.
GCC (primary)
Vevey, Switzerland GC EUR (secondary)
Frankfurt, Germany
GC AOA (secondary)
Sydney, Australia
GC AMS (secondary)
Phoenix, Arizona
GC HQ, CSC (secondary)

Bussigny, Switzerland
Markets (tertiary)
any country
Figure 9-1 Global deployment coverage for Nestl Corporation

10
Chapter 10. Software deployment tools

Chapter 3, Software deployment best practices on page 21, introduces the
software deployment best practices. This chapter presents the many tools
available to help systemically execute against these best practices. We
recommend that you take advantage of every tool, technique, process, and
procedure available that will accelerate software deployment. The tools in this
chapter fall into five primary categories:
License management tools
Communication tools
Self-help tools (support, software entitlement)
Education
Deployment Services
Most organizations have a customized set of that tools they leverage to manage
projects and monitor deployment performance. It is not our goal to have only IBM
products in place to fulfill your tool requirements. It is more important that you
recognize any weaknesses in your tool strategy and take immediate action to
address them. To learn more about any of the tools described in this chapter,
contact your IBM Software Account Manager (SAM) or see the following Web
site:
http://www.ibm.com

10.1 License management
An example of a tool for managing the deployment of software licenses is IBM
Tivoli License Manager (ITLM). This section presents portions of the white paper
IBM Tivoli License Manager Intelligent software license management to help
optimize business value that describes this tool. You can find this paper on the
Web at:
ftp://ftp.software.ibm.com/software/tivoli/whitepapers/
wp-license-mgr.pdf
In todays business, no company can make money without taking care of

Information Technology (IT) resources. IT is more than just a link in a production
chain. For many companies, it is the key factor that improves the overall revenue,
and even the smallest organization needs to set up an IT infrastructure to create
a business.
The larger your company is, the more complex the IT infrastructure must be to
support the business. This infrastructure requires time and money to be
managed, maintained, and extended. In a large organization scenario, a software
solution that helps you track assets from a financial, contractual, and physical
point of view is a critical business need.
By having an integrated view of the hardware and software assets you own, you
can plan for hardware and software maintenance and upgrade, and understand
exactly what resources are needed to support your business.
Typically, software assets are the key factor missing from asset management.
The main portion of the investment required to set up an IT infrastructure is
usually related to software, not to hardware. Taking care of the software products
that are installed and run on a large infrastructure, including thousands of servers
and desktops, is not a trivial task. However, there are several benefits in using an
enterprise solution to accomplish this task. Some of them are:
Legally enforce license agreements of procured products
Obtain information about the software that is actually needed
Strive for full utilization of procured products, paying support only on what is
used
Gather data for total cost of ownership analysis
Collecting information about the software products that are installed and used
within your IT infrastructure is the only way to achieve the benefits that were
previously described. To do this, the use of a system explicitly designed for asset
and license management and well-defined processes around that system are
required.

10.1.1 Taking control of software licenses
Software monitoring is the main issue in software asset management. As
described in the previous section, it is the only way to tell exactly what products
are really needed, especially for large environments. However, there is more than
just software inventory in a complete solution for asset and license management.
The real needs for asset management go far beyond a simple tool for software
tracking. You likely need to know whether any of your departments are
overbuying licenses because there is no way to tell if they are really needed, or
whether it is exposing your company to the risk of non-compliant usage of
software products.
Taking control of your software licenses is just as important as tracking the life
cycle of hardware assets. A solution that tells you if you are overspending or
taking the risk of high penalties gives you an instrument to achieve these goals:
Reduce overall cost of software license management and compliance
monitoring
Produce the licensing data necessary to plan for license upgrades and
migrations
Analyze the licensing data to determine if other options are more attractive
To attain these goals, license management comes into play. Your software
procurement information must be properly reconciled with the software usage
and inventory data. Only by doing this it is possible to tell whether you are paying
more license fees than necessary, or whether you should buy new licenses as
soon as possible to remove any compliance exposure.
10.1.2 IBM Tivoli License Manager

In the license management space is ITLM. ITLM can collect and maintain
information about procured, used, and installed products. It then stores the
information for analysis and reporting in a centralized and historical database.
The administration server is responsible for maintaining the database and the
access policies for allowing a system administrator to work with ITLM and browse
the available software reports.
The license procurement information is defined using the Web interface to the
administration server. Using only a Web browser, the administrator defines the
license procurement information that is needed to monitor the usage of a
software product and enforce a license agreement when requested.
The information about available licenses, which can be defined on a

product-by-product basis, is distributed automatically to the runtime servers. This
Chapter 10. Software deployment tools 81

provides support for the process of granting licenses to the requesting agents,
which happens on the servers in real-time fashion.
In this scenario, each agent is responsible for detecting each new application,
validating the available information to identify the starting product, and requesting
an existing license from a run-time server, so that the product usage can be
authorized. Thus, license control can be done in real time, and the data collected
on the runtime servers is used both for real-time reporting and periodic
reconciliation with the administration server.
You can use several settings to configure the behavior of the system in a more
detailed manner. For instance, if you are not interested in applying license
enforcement to the usage of licensed products, you may turn off the function that
requires a license to be granted to the agent before a product can start.
10.2 Communication tools

Communication is another software deployment best practice. IBM leverages
several tools to make communication easier and more efficient. They range from
tools as common as e-mail to as specialized and configurable as portals.
An important first step is that you move away from the perspective that
communication is something used only to report problems and submit orders.
The power of communication is felt most when it is easy, convenient, and difficult
to avoid. A good example is the fuel gauge in a car. It is certainly critical that you
know when your car is running low on gas, but it is also convenient to know when
the tank is more than half full so you know you have nothing to worry about.
10.2.1 Instant messaging, Web conferencing, and team workplaces

Communication with your software vendor, your partners, or simply within your
company is easier if you have the proper collaboration tools. Having real time and
easy collaboration with tools, such as instant messaging and Web conferencing,
creates better coordinated, better informed, and more agile organizations.
Having the ability to create a team workplace is an excellent way to keep an

entire Software Deployment Team (SDT) on the same page regarding
requirement documents, project plans, deployment status, and challenges.
For more information about IBM tools in this area, see:
http://www-3.ibm.com/software/collaboration/

10.2.2 Easy Access Portals
Easy Access Portals were created to give you a place to post helpful information
about your software agreement with IBM. Such information as what products
were purchased, what these products are designed to do, how deployment is
progressing, and how to get product updates are all examples of what Easy
Access Portal can provide.
As part of your software relationship with IBM, your company may have access to
a private, customized Easy Access portal. We organized your private Web portal
to make it even easier to find what you are looking for. My Software Center,
accessible via your companys private portal, is a central source for information
about software product, support, and services. Whether you are interested in the
latest software products and solutions for your industry, local events, or support,
you can find it here.
Working with your IBM team, you can customize My Software Center to help you
understand the software products and services that you are entitled to use under
your software agreement with IBM. It provides the ability to request media,
submit questions to your IBM team, and to find information about the products
included in your software agreement. To determine whether your company has
an Easy Access Portal, contact your dedicated IBM representative.
Easy Access Portals offer the following benefits:

Improve ease of use by providing secure, private one-stop environment for
evaluating products and services
Provide a seamless and private interface
Help you navigate IBM relevant sites, contacts, and collaboration centers
Provide 24x7 access to product, service, and support information, and can
include continuous access to a range of news and product information
Contain multiple interactive help options online, or you may receive offline
assistance from support, telesales and telecoverage contacts
Reduce the cost of doing business with IBM by using Shop Smart, Configure
to Order, Order Direct, Track online and Get Help Fast features
Provide a suite of valuable applications to support your software, Learning
Services and maintenance contracts, order status, and software delivery with
eQuickship
Are business-to-business (B2B) direct by integrating online ordering to
procurement system

10.3 Self-help
Self-sufficiency is another software deployment best practice from IBM. IBM has
focused a great deal of energy on providing you the tools needed to be
self-sufficient. Most of this work has been done in the problem management and
in the software fulfillment space.
10.3.1 Problem management

IBM provides an extensive set of self-help tools around problem reporting,
management, and tracking. Visit this site to begin:
http://www.ibm.com/support
10.3.2 License acquisition and entitlement with Passport Advantage

IBM offers two license acquisition and maintenance programs: Passport
Advantage and Passport Advantage Express. Passport Advantage is designed
for larger enterprises. Passport Advantage Express is designed to meet the
needs of small or medium-sized businesses.
Passport Advantage is the IBM comprehensive software licensing and software

maintenance program. It is a global program that is designed to save you money
at every stage of your software acquisition and use. Passport Advantage is the
most flexible and cost-effective way for you to reap the benefits of new releases
of the latest technology and technical support to keep your business up and
running, plus obtain volume pricing for significant software purchases. It can help
lower your acquisition and administrative costs, facilitate migration to new
platforms, boost productivity, and increase profits.
For more information, see:
http://www.lotus.com/services/passport.nsf/WebDocs/
Passport_Advantage_Home
10.3.3 Software maintenance via Passport Advantage

Passport Advantage includes a maintenance feature that complements your IBM
Software purchases. It includes both product upgrades and technical support. It
also fosters successful software deployments. With product upgrades, you get
complete upgrade and cross-platform migration coverage for most commercially
available IBM distributed software Data Management, Lotus, Rational, Tivoli,
and WebSphere Software. You can upgrade to new releases and new versions
as the needs of your business dictate. Technical Support helps keep your users

up and running wherever they are working in the world. This is our way of making
sure you are covered with the technical support you need. This is your way of
getting an increased return on your IBM investment of a total software solution.
Benefits
The benefits of obtaining maintenance via Passport Advantage are:
Includes a full 12 months of software maintenance with each license
Provides comprehensive and flexible upgrade coverage
Protects technology investments
Simplifies and improves software asset management
Reduces acquisition and administration costs
Streamlines budgeting for software upgrade and migration costs
Provides immediate support coverage on newly acquired products during
installation phase and for life cycle of product
Incorporates flexible, easy-to-access, responsive, cross-platform support
from IBM, worldwide
Provides access to IBM Software technical support for all of your designated
IT staff
Simplifies acquisition and renewal of cross-platform support
Enhances overall expected response time of two hours or less during normal
business hours
Provides 24x7 access to support resources for business-critical outages
Increases self help via the Internet
For more information, see:
10.4 Education
To be self-sufficient, a team must be developed that has the right blend of skills
and experience to act independently of IBM support and services teams. This
education can be obtained via knowledge transfer from deployment services or it
can be a obtained via formal education made available by IBM.
To learn more about education available to you, see:
http://www-3.ibm.com/services/learning/training_cat.html

10.5 Deployment services
Car races are won by less than a tenth of a second. What makes or breaks the
victory happens in the pit, where expert crew members swarm the car to change
four tires, refuel and adjust the car in less than 20 seconds. These pit crew
members are highly skilled in using the tools to perform this feat.
IBM has its own e-business version of the pit crew the IBM Services teams. Our
teams offer skilled experts for Lotus, DB2, Tivoli, and WebSphere software.
Worldwide, our technical consultants turn opportunities into wins, challenges into
solutions, and skeptics into loyal customers. Just as the pit crew readies the car
and driver for the win, the IBM services teams have the expertise to make you a
winner with IBM Software.
The IBM services teams are available to help design and develop application
solutions that run on IBM middleware and provide services to support the proper
installation, configuration and operation of the products. The teams have strong
relationships with the IBM Business Partner community and IBM Global Services
to provide a broad range of services to suit your needs.
IBM services teams can support and mentor your implementation teams. Or they
can help you improve the skills of your development staff through training and
hands-on experience. All of our services are structured to ensure your success.

A
Appendix A. Software solution work

products
One of the mantras at IBM is dont reinvent the wheel. In the spirit of reuse, we
present the information in this appendix. We mention many times throughout this
redbook that planning and design are key attributes to any successful software
deployment endeavor. The work products contained in this appendix have been
used by IBM project managers and architects to drive successful deployment
projects all over the world. If you have any questions about how to use these
work products, contact you software sales representative, your software
architect, or your software services representative.

Work products used by SDM
The following information describes each of the work products used by the
Software Deployment Method (SDM).
Architecture decisions document (ADD)

This document lists critical architecture decisions or choices made in the design
phase. It describes the rationale for making them.
Architecture overview diagram

An architecture overview diagram illustrates the basic ideas of the proposed
architecture. It is the equivalent of the architects sketch. Depending on the
context, the diagram may range from basic to detailed. Related work products
are the system context diagram, component model, and operations model, where
additional detail is conveyed. Typically, the architecture overview diagram evolves
with greater level of detail as the architecture is better understood. The diagram
serves as a means to confirm architectural understanding between you and IBM.
Business context diagram and description

Business context diagrams are used to document the identity of the business
area being served by the development effort and its interactions with other
business entities in its environment. These entities and interactions are the
sources and channels for flows of information into and out of the business. This
understanding is key to developing a system that is properly situated in your
business. In addition, business context diagrams:
Provide the source of business events that occur across the business
boundary
Act as a framework for determining the set of business processes
Articulate the scope of the business area being served by the new information
system
Various business context diagrams can be examined and discussed with you as
a way to clarify which business interactions are in scope and which are out of
scope of the system being developed.
Component model
The component model documents the following information for each component:
Responsibilities: Describes responsibilities from the view of a user of a
component. The description is later refined into specific operations that
constitute the application programming interface (API) for the component.

Required service levels: Describes the service level for the component in
regard to users and presentation, performance or capacity and availability
design rationale, reasonableness and risk, and implementation approach.
Information Technology environment

This work product documents the customers existing logical and physical design,
databases design, and Web environments (servers, firewalls, for example). It
also documents your security requirements, operational parameters (24x7, for
example), end-to-end performance requirements, and existing standards
(naming and protocols, for example).
Customers organization
This work product description is simply an inventory (or chart) of organizational
elements (structures, behaviors and enablers) for in-scope organizational units
(for example, corporate organization, strategic business unit (SBU), functions,
teams, and individuals). The influencers and owners may be key to defining who
to call for a given solution. An organization chart may be color-coded, for
example, to indicate who is directly involved in the decision process.
Envisioned goals and issues

Envisioned goals and issues include project ideas that emerged early in the
sales process. The envisioned goals and issues work product is documentation
about your:
Mission statements (sometimes called value statements, credos, or
principles) are the operational, ethical, and financial guidelines of your
company (or functional areas). They articulate the goals, dreams, behavior,
culture, and strategies of your company.
Vision statements are the long-term objectives of your company. They
articulate your companys target marketplace, products and services. They
also state the position that your company wants their products and services to
have in the targeted marketplace, as well as the financial position (revenue,
profit, etc.).
Business goals are the short objectives of your company that have to be
achieved to enable the fulfillment of the vision. The focus of the Software
Deployment Teams (SDT) should be on the business goals that relate to the
projects that are part of your software purchase, for example, a specific
functional area.
Critical success factors (CSFs) are the few, high-priority areas where
satisfactory results help to ensure the achievement of the business goals. The
business issues can be used to identify the CSFs.
Appendix A. Software solution work products 89

IT standards
This work product documents all known Information Technology (IT) standards
that the architecture must accommodate.
Non-functional requirements
This work product details all of the key features and characteristics that are
required in the new system. It defines the constraints imposed upon it by other
factors. These requirements form a basis for preliminary system sizing and for
the first estimates of cost. The requirements, along with the component model,
are used to produce the operational model. These requirements are often the
most important single determining factor in the entire design.
Operational model
This work product specifies the hardware that the desired architecture requires.
Project descriptions
A project description document is written to communicate the project goals to all
who need to know. It is critical for the entire team to understand the projects
goals. Writing a project description helps to verify that everyone connected with
the project agrees on its objectives.
A statement of project goals gives the development team a context within which
to work. It provides a concrete starting point for development. Project goals can
raise issues of scope and function, which are best identified as early as possible.
The project description work product is a brief answer to the question: What are
we doing on this project and why? The content depends on the nature of the
project.
For example, on an application development project, the project goals describe

the business requirements of the application to be developed. These are not
functional requirements, but rather short descriptions of the business problems
that the application should solve. For a business transformation project, the
project goals are more general statements of objectives and business
imperatives.
System context diagram

The system context diagram helps clarify the environment on which the solution
will operate. This diagram documents all connections between the proposed
system and external systems and components. Various attributes are associated
with each connection. These attributes may include data description, protocol,
formats, frequency, volume, and model of interaction (synchronous,
asynchronous). This context constrains the proposed system in regard to the

interfaces that must be implemented. The system context diagram may provide a
rationale for a make or break decision on whether to go forward.
Use cases
This work product specifies requirements in the areas of performance, capacity
or volumes, scalability, availability, portability, maintainability, and usability. It also
specifies requirements in systems management, security, infrastructure
constraints, technology standards constraints, and geographic or configuration
constraints.
Viability assessment
This work product describes architectural risks, prioritizes (high, medium, and
low) the probability and impact of each, and identifies contingency plans for each
risk item.
Value Realization Model (VRM)

The purpose of this work product is to ensure that you have a plan to measure
deployment success. It includes work products and reports that will baseline and
monitor performance during the entire deployment life cycle. The Value
Realization Model is developed and updated continuously. It contains the
following subwork products:
Goals and milestones: It is vital to work with the Enterprise Business
Sponsor (EBS) at the beginning of the process to agree on and document the
goals and milestones. This includes the overall vision, specific goals to be
achieved with the IBM solutions purchased, important milestones to be used
as checkpoints in the deployment, and the metrics used to measure success.
This should also include a strategy to measure return on investment (ROI)
and rate of return (ROR). For more information about ROI and ROR, see
Chapter 4, Value realization on page 31. Finally, you develop a plan to
achieve a quick deployment win. This should be a visible project that can be
successfully deployed in three to six months and can act as a catalyst for
future success.
Gap analysis report: The gap analysis report lists products that will be
burned by defined projects and products that have yet to be linked to planned
projects. The unlinked products constitute the gap.
Deployment milestone status report: Deployment milestones and metrics
are the critical checkpoints and measures that the Software Deployment
Team defines. The team follows them closely to ensure that deployment
progress is on track.
License utilization report: This report supports proper license management.
It may be the output of a license management tool such as IBM Tivoli License

Manager. This should identify what software licenses are installed, where
they are installed, and which ones are actively used.
ROI/ROR status report: The ROI/ROR status report should re-state the
strategy documented with goals and milestones and present an updated view
of the progress.
Deployment plan
The deployment plan includes a full mapping of projects to products purchased.
It is not meant to duplicate planning around a single project being executed. The
content falls into two primary categories, Account Planning and Project Planning,
as explained in the following sections.
Account planning
The Account Planning subwork products in the deployment plan include:
High-level mapping of business initiatives to deployment projects:
Ideally, you have a set of goals in mind for the software that they are
purchasing. Those goals map to potential projects. When the agreement
closes, these projects drive deployment activity. This subwork product is a
mapping that links each project to the business goals or initiatives that drove
the original purchase.
Documented linkages of deployment projects to products: Like the
previous mapping of projects to business initiatives, this subwork product
documents the products included in each project. This provides a direct tie to
the products just purchased. This tie can help to rejustify the software
purchase to new management, identify gaps in projected deployment, and
align the deployment timeline with the business initiative timeline.
Deployment services requirements: This subwork product lists the services
that the SDT believes is needed during deployment because they are critical
to deployment success. The deployment team identifies these requirements
during the preparation phase of deployment, reviews them with the EBS.
Status of environment and infrastructure requirements: Any ancillary
prerequisites or corequisites must be completed before or along side the
actual software deployment for a successful project. These may include
hardware acquisition and setup, third-party software, or the creation of a new
organization to handle the customization and rollout of the solution. It is
important that these are recorded and monitored to prevent the project from
stalling.
Project Planning
The Project Planning subwork products in the Deployment Plan include:
Deployment quick-win plan: It is important that success be demonstrated
as early as possible in deployment, because it will generate momentum,

enthusiasm, support, and positive first impressions. The quick-win plan
identifies projects selected for their high-probability of success, their
importance to the business, and their ability to complete in a relatively short
period of time. The plan also contains the milestones and metrics associated
with the projects.
High-level deployment plan: The deployment plan is the deployment bible.
A high-level version is developed early in the deployment method. It defines a
list of initial deployment projects, groups deployment into logical chunks,
contains a deployment timeline, and includes a services assessment.
Architecture plan: The deployment architecture is the blueprint of what will
be deployed in the environment. It combines all of the work products to
illustrate how the solution will be accomplished.
Deployment plan findings and action plan: In the process of defining and
documenting the deployment and architecture plans, important items may be
missing or not accounted for. These may include necessary hardware that
has not been budgeted for or the implementation of a new and complex
solution that is missing education and training on the new software. These
items need to be documented and an action plan must be created to address
any deficiencies.
Milestone status report: There should be ongoing communication with the
Enterprise Business Sponsor to provide updates on the progress of the
deployment projects against the business milestones. This should be a
high-level report that communicates progress or identified inhibitors to
maintain support for the deployment or overcome obstacles to success.
Project controls: Project controls provide documented processes and
deliverables in the project areas of scope, time, cost, quality, human
resources, communications, risk, procurement, and other project elements as
required by the situation. Each element is documented by the project
manager and should be made available for review by management (yours
and that of IBM) and serves as the overall assessment of the project.
Readiness plan
This work product was created to ensure that the IBM team evaluates your
readiness for deployment. In regard to the following subplans, the SDT should
consider where extra planning may be necessary to minimize deployment risk.
The subplans are:
Communication plan: Considers who the stakeholders are and who the
sponsor or owner is for all internal and external communications. This plan
also contains a support plan.
Education and skills plan: Documents the skills assessment, roles, and any
justification needed for education expenditures.

Architecture plan: Documents security requirements, systems and data
integration points, and functional requirements.
Deployment plan: Addresses implementation, testing, and migration.
Operations plan: Identifies backup and recovery processes and owners,
disaster recovery plans, help desk environment, systems management
disciplines, availability management, logging, monitoring, etc.
Risks and dependencies: Points out items that pose risks to the success of
the project or define boundaries that should be understood by all parties. This
information helps to minimize surprises by identifying areas that need special
attention.
Work product examples

There are several references to work products in this redbook. This appendix
provides examples of many of those work products. They are listed alphabetically
for easy reference. Throughout the examples, InsCo and ShopCo are used to
represent a sample company.
Architecture decisions document

This document consists of a series of architectural decisions. Each decision is
documented in a table as shown in Table A-1.
Table A-1 Example architecture decisions document

Subject Integration architecture
Architectural Use a transformational hub architecture to provide more economical systems

decision maintenance and to make the legacy systems more flexible.
Issue There is a large number of legacy systems, some of which are to be replaced. There is
a disposition to buy over build. There is a large number of interfaces, cost of
maintenance is large, and the system is rigid. Additionally, the corporation must provide
the potential to be acquired or to acquire.
A basic principle is that packages should lead infrastructure. Point-to-point connections

between existing legacy systems create a rigid application environment into which it is
difficult to install a new package. Because ShopCo is focused on cost reduction and has
specified a direction of purchasing and integrating packaged business applications
instead of building those applications, the elimination of a substantial number of the
point-to-point interfaces will go a long way toward achieving this goal.
Assumptions Systems will require maintenance modifications for the foreseeable future. Multiple
redundant interconnections are much more expensive to maintain than single
connections. Systems which have abstracted interfaces are easier to work with.

Subject Integration architecture
Motivation Economy, flexibility, reliability, time to market. Ability to add packages and make
changes in a timely way.
Alternatives Continue to support point-to-point connectivity going forward. System will become
increasingly hard to maintain as new packages are added. Addition of new packages
will itself become more difficult.
Decision Use modified integration hub architecture.
Implications Requires messaging protocol.
A typical set of architectural decisions may include such decisions as:

1. Integration architecture: Use a transformational hub to provide more
economical systems maintenance and to make the legacy systems more
flexible.
2. Legacy application access: Use component or services architecture to
provide economy of reuse for legacy applications, and to enable a
transformational hub.
3. Application runtime architecture: Use a browser-client architecture instead
of client/server or host-based development to lower support costs and to
provide business function over Internet.
4. Application development architecture: Use an object-oriented paradigm for
new development. Separate model, view, and controller cleanly.
5. Application development platform: Use Java as an object-oriented
language for Internet-client development. Use the servlet-JSP-bean model to
separate model-view-controller for object design.
6. Internet/intranet platform: Provide reliable production, test, and
development platforms for Internet- and intranet-based systems.
7. Security for new systems: Provide enterprise-level security straight through
from Web to host, including messaging system. Provide single signon for
applications.
8. Workflow system: Use an external workflow system to reduce coding
required when integrating applications with each other and with human
workers. Use a system to control flow between applications and third-party
packages.
9. Dependability of distributed systems: Provide availability or fault tolerance
for RISC-based systems (and any Microsoft Windows systems running
production applications).
10.Disaster recovery for Internet and intranet: Provide disaster recovery for
all production systems, including Internet and intranet client applications.

11.Portal: Use a portal-based Web interface to provide a coherent and
personalized user console.
12.B2B application integration: Use Web services as the standard interface for
implementing remote application invocation.
13.Level of integration: Use a process integration style of integration for
connecting applications together.
Architecture overview
The integration design is in three parts: the integration hub, the gateway, and the
portal. Figure A-1 shows these three parts.
The integration hub provides routing and transformation services between

legacy applications and new packages, as well as with the gateway and portal. It
also provides the facility for creating and maintaining the data warehouse by use
of an extract, transform, load (ETL) tool.
The gateway provides Internet and network access for machines. It consists of
technologies such as electronic data interchange (EDI), messaging, and Web
services.
The portal provides Internet and intranet access for humans, and consists of the
Internet infrastructure and associated devices.
legacy
applications
gateway
external
external
networks workflow new
networks
server integration
packaged
hub
applications
portal
application
server
(new apps)
content
management
system
Citrix EIP
apps
Figure A-1 Example architecture overview

Business context diagram
This e-business solution deals with several complex systems. They include
ShopCos legacy applications, the intranet, the Internet, the branch systems,
business partners, and a series of new packages that will gradually replace the
existing legacy systems. Specifically, this solution is intended to provide an
architecture for combining these elements into a consistent whole.
To ensure that this process begins with an accurate understanding of the existing
flow of work and information throughout the system, we examined ShopCos
current business context and illustrated it as shown in Figure A-2. Many of these
systems will be replaced by packaged application over the next two years. The
new packages that are not yet selected will necessarily be treated as black
boxes for the sake of this architecture. The integration of the new systems with
the existing structures, as well as with the projected workflow and Internet
systems, raise architectural issues that can only be roughed out in general at this
time.
debit/credit, authorization
Customer
Customer Third
ThirdParty
Party
Direct
Multiple
Store
Store
purchase
Support
Support
coupon control
price, promos, etc

Advertising
Advertising
POS
POS Distribution
Distribution store
Store
Store Systems
(C&S etc) activity,
Management
Management
orders
ordering
delivery info
personnel info
labor,
benefits
HR
HR
Financial Merchandizing
Merchandizing
Financials
Systems
(Lawson etc)
Price
PriceManagement
Management
Executive
Executive sales info
Reporting
Reporting Systems
Systems cash management
Database
Database
Figure A-2 Example business context diagram

Component model
The model shown in Figure A-3 illustrates use case #1, an intranet-based
application that accesses a legacy system, a packaged application, and a
black-box system sitting on a partners system at another location.
Routing/ Queue-
HTTP Business Message Message
Browser Servlet Transfor m Enabled
Service Object Queu e Queue
Hub Application
Packaged
W eb Adaptor
Service Application
Partner
HTTP HTTP Partner
Web
Service Service Systems
Service
Business Partner
Figure A-3 Example component model
The components in this model are:

Browser: In the best case, the system is browser-agnostic. Although it may
be possible to specify which browser is used internally, on the Web any may
be used. The intention is to use only the basic browser services.
Hypertext Transfer Protocol (HTTP) Server: The HTTP server accepts a
Uniform Resource Locator (URL) request from the Internet or from the Mobile
Connection Service. It either handles the request itself (in the case of simple
Hypertext Markup Language (HTML)), or passes it along to a servlet to be
handled.
Servlet: The servlet is the basic controller of the model-view-controller
system. It determines which objects need to be used by the request and
directs and organizes their activity. When its work is done, it returns a Java
Server Page (JSP) to the browser.
Business object: The business object contains the business logic for a
particular piece of work. It communicates with other objects as needed,
notably data objects which handle access to the data and services. In
general, these objects are built so that they can be handled with any standard
graphic programming tool, in which case they are commonly called beans.

Message queue: The queue is a messaging system that provides assured
delivery (once and only once) of a message that is posted on it. The queue
has security enabled on it so that only the appropriate recipient can open it.
Integration hub: This is really a two-fold component: a routing and
transformational hub. The routing node directs the message to the
appropriate application queue or to a transformational node. A
transformational node checks to see what kinds of conversion are to be
performed on the message, performs the actual transformation, and forwards
the message to another node or to an application.
Queue-enabled application: This is an application that has had code added
to it that can communicate with the messaging stack. The application is made
capable of receiving and generating appropriate messages through this
queue. It is also possible for an application to provide input and output to a
queue by use of a flat file or database.
Adaptor: This component represents a packaged or custom adaptor that has
been created to allow a packaged application to converse on the queuing
mechanism. Many are available from either the application vendor or third
parties.
Packaged application: This represents any application that can be
queue-enabled or that produces a file or database.
Web Service: This service provides communication across the Internet using
Simple Object Access Protocol (SOAP). It uses HTTP for its lower-level
protocol.
Partner system: This is a system running on a partners machine, whose
internals may or may not be known to the originating system.

Component flow model
Figure A-4 shows a sample component flow model. The flow of information
among the components follows the standard object and queuing conventions for
servlet, bean, and JSP. It passes through the routing engine and an adapter that
was purchased in conjunction with the packaged application. The packaged
application appears to the business object (and to the programmer) as another
bean.
HTTP Business R&T Adaptor Packaged

Browser Server Servlet Object Engine Application
URL request Activate Request

servlet customer info Queued API call
Queued request
request passed to Adaptor
to routing
API response
Queued return Queued return

Return data
passed data to calling
Return JSP as Fill in JSP with pointer to servlet
from routing object
HTML data
Figure A-4 Example component flow model
Current IT environments
Current IT environments are typically depicted by application lists followed by
diagrams. A sample list follows. Figure A-5 and Figure A-6 are sample diagrams
that illustrate the current architecture.
IBM host systems software

OS/390 2.8
TME NetView 1.03
CICS/ESA Base V4.1.0
COBOL for OS/390.21
NetView Performance Monitor 2.4
DB2PM 4.1
Basic Telecom Access Method SP
Print Management Facility 1.1.1
SDF II MVS 1.4
GDDM-IVU 1.1.3

GDDM Interactive Map Def 2.1.3
GDDM-GDS 1.1.3
VS Fortran 2.6
VS Cobol II 1.4.0
IBM Database 2 MVS 5.1.0
NetView DM for MVS 1.6.2
IMS Sys U/B Tools 5.1
NetView FTP for MVS 2.2.1
System Automation for OS/390 1.3
Escon Manager 1.3.0
MVS Bookmaster 1.4.0
OGL/370 1.1.0
Cobol for MVS 1.2
VisualAge Cobol for OS/390, APL2 2
PL/I MVS 2.3
Host applications
Bidders 6.0.0
IBIS A/P 7.1
IBIS G/L
Inforem 1.1.7
Genesys Payroll 5.5
WACS 4.1
27 legacy systems
Non-IBM host systems software

Abendaid/MVS 9.2.1
Abendaid/FX 4.2
CA-11 2.2
CA-90s 1
CA DADS Plus 3.5
CA-Filesave 1.1.0
CA-Gener/OL 7.0.b
RS/6000 in-store system software

AIX 4.3.1
AIX Connect 1.1
E-Network Comm Server for SNA 5
Tivoli TME10 for AIX 3.1.4
Retail Connectivity Option 2.3
TPS 3270 Emulation 3.1.7
TPS 3270 Emulation 3.1.0
3151 Terminal Emulation

RS/6000 in-store applications
People Planner 6.1.9125
Time and Attendance 7B00.11 SG
Comtec Suite 3.33
Electronic Label Technology 5.31
FacetTerm 3.4.3
PDX 4.0.3
Telxon 1.2
Lotus 1-2-3 for AIX 1.02
Informix 5.07
POS in-store system software

4690/OS 1
4690 Enhanced Remote Operator 1
POS in-store applications

Supermarket Application 1
Surepay C
Supermarket Electronic Marketing 1
RS/6000 server system software

AIX 4.3
E-Network Comm Server for SNA 5
Tivoli TME10 for AIX 3.1.4
Java 1.1.5
Load Leveler 1.3.0
Performance Agent 2.2.1
PSSP 3.1
RS/6000 server applications

Priceman
RWS Nitro
World Information Systems
PDX 4.0.3
Executive Support System 6.2
Cash and Sales 6.2
CIC
Applications available via server

Microsoft Access 2000
Microsoft Access 97
Microsoft Access

Microsoft Excel 2000
Microsoft Excel 97
Microsoft Office 2000
Microsoft Office 97
Corel Office 2000
Monarch 4
DBase 2.0
FoxPro 2.6
Lotus SmartSuite Millenium
Desktop software
Windows 95 B
Windows 98 SE
Windows 2000 5.00.2195 SP1
Personal Communications
SmartSuite Millenium
Global Dialer 2.5
Netscape 4.7
Acrobat Reader 3.25
Norton AntiVirus 4.1
PC Outline
Other software
Novell NetWare 4.11
OS/2 Notes 4.6
Microsoft Windows 98 98B
Microsoft Windows NT 4
MAC-OS
PSI Standard Desktop Platform 1.0
Excel 97
Example 1: Current application deployment

Figure A-5 shows the current application deployment. While most of the
ShopCos systems were originally mainframe applications, some client/server
applications were developed. Also, there is an increasing awareness of the
benefits of development under Internet-based technologies. At the moment, the
important platforms are S/390 and Windows Client/Server.
The available UNIX hardware and expertise should be retained, because they
constitute the most likely platform for the deployment of the Internet, intranet,
workflow tool, and the integration hub.
It is likely that ShopCo will also find that, as new business packages are
implemented, the UNIX platform will become increasingly important both as the

systems platform for those packages and probably as servers for browser-based,
Internet client applications.
Distribution Item Management

Advertising
GF NT Pharmacy
Dept
Grocery Bakery
Dry Goods Toys
Financial Merchandising
POS BA BT Catalog
Store Server POS (4690) HH FT BN GT
(RS 6000) Supermarket Returns
Store Pharmacy
Management Toys
HR, CGO, etc HR Advertising
System 390
Store
Warehouse &
Financial Notes Mail,
Logistics
- Priceline Promotion
Peterson
DRS Access
Marketz Purch xBase/App Dev, etc
RS 6000 Windows
Distribution
Center Internet structure Intranet Domino
Web
Figure A-5 Example diagram that illustrates the current architecture
Example 2: Subsystem needing special attention

Because the ShopCo architecture represents the current default method of
building Net-based applications, it is crucial to understand the underpinnings of
this architecture. Figure A-6 illustrates the architecture.
A browser, on the users desktop, is used to connect to the Web site. This
browser then uses a plug-in to launch a Citrix session running on a Citrix server
within the secure zone. Within this Citrix session, a second browser is launched.
This browser then connects to an Internet Information Server (IIS) using an
auxiliary storage pool (ASP). The IIS server runs a Visual Basic program which
connects to a second IIS server on an Enterprise Information Portal (EIP)

machine. This IIS server then connects through WebSphere to EIP and then to
the ImagePlus system.
This somewhat unlikely and cumbersome configuration came about because the
Brio system, used to provide reports, was unacceptably slow when the client was
on the users desktop. However, it ran sufficiently well on the Citrix server, from
which its image can be shown, page by page, on the desktop browser.
Nfuse
Server App Server EIP Server DB2
Citrix Server IIS IIS Image

Desktop Plus
Browser Visual Index
Web Basic
Browser WebSphere
Server
ASP App Image
Citrix
Plug- in Server Plus
Data
Brio EIP
Plug-in BRIO SQL Server
report
data
Figure A-6 Example current architecture diagram
Current business organization

Over a period of three months, multiple interviews were conducted with the
senior members of the ShopCos IT team highlighted in Figure A-7. In addition,
there were several meetings with the Chief Information Officer (CIO), as well as
several conferences with technical people at a lower level.

Jane Smythe
President
Underwriting Claims CIO CFO COO Branch Ops Managed Care Bill Howard
Judy Wells
Michael Ho Thomas Jones James King Mark Ellerby Betty Plonk Jeremy Newl Allen Hobbes
Data Mangmt Claims FNOL Underwriting Operations

Peter McAng Connel McFarland Mary Martin Henry Lakey Pi Zaharko
Changes Reporting
Web Apps Workers' Comp
Datamart Comml Auto
GJS POKI
CoA Prime Peter Vicot Ann Riley Financial A/R Rita Spannel Louis Jacaro Peg Henry DBA
Notes/Web Premium Corp
Actuarial Reporting
Client Systems Forms Lotus Notes Mail & Copy Help Desk
Data Quality Appl. Architecture
Support Call Center Admin Printing Procurement
End User Appl/Systems Data Center
Financial/Claims Quick Code Networking & MAC
Support
Image Team Services Prod. Control Telecom
Figure A-7 Example business organization
Envisioned goals and issues

ShopCo has a legacy background of 3270-based host applications. Over the last
few years, a concerted attempt was made to provide more advanced client
interfaces for new systems. This resulted in the development of a moderate
number of client/server applications constructed in Visual Basic and
PowerBuilder.
In the context of this mix of applications, the CIO made a carefully-reasoned

build-dont-buy decision to begin to move toward application packages. This is
intended to provide stable business functionality on a platform that can be more
easily and economically maintained. An integration architecture is needed to
facilitate the addition of new packages. (When the Cenfra package was installed,
30 different systems had to be modified, and even after that integration, it is still
tightly coupled.)
Two other efforts are to be combined with this move. The first of these, the
integration of a new workflow with the imaging system, should be considered in

the context of the move to application packages. The second effort, to get more
productive business use from the Internet and intranet infrastructure, should also
be planned within the context of an overall integration architecture.
To provide for these goals, the CIO has requested IBM to provide an integration
architecture. This architecture is to include imaging, workflow, application
integration, Web integration, and integration with business partner systems.
The specific goals are:

Reduce maintenance costs
Implement packages
Cenfra (rating)
A new homeowners package
A package for CPCS
Policy Issuance System
Premium
Financial
Implement integration architecture: Replace home-grown messaging and
polling mechanisms
Use and reuse: Develop once, and use as needed
Centralize information
Client profile
Agency/broker information
Replace aging imaging system: Provide for e-mail, graphics, voice
messages, direct fax, etc.
Reduce time to market
Implement packages
Implement workflow
Use integration architecture
Engineering for agility
Improve system reliability
Implement queuing
Improve system maintenance
Harden infrastructure
Move critical and enterprise systems to open standards
Provide Internet infrastructure
Provide gateway for external applications and Web services: Enable InsCo
to broker online applications between agent and carrier.
Provide portal for employees, customers, and business partners.

Standardize Web standards and development.
The intranet infrastructure should support the development of an
underwriters workstation.
Version control of the Web site.
The issues are:

Some system level functions are home-grown, such as the polling piece of
FNOL. It requires tending to make sure its running (InsCo actually wrote a
program to check and see if its running).
Image environment is 12 years-old, MODCA only, no voicemail, e-mail, etc.
Islands of process are hard to maintain and integrate. This makes the move to
packages much more difficult.
Tightly integrated functions will make the move to packages much more
difficult, for example, the need to decouple claims from check creation
process.
Many legacy applications need to integrate with new packages. Cenfras
installation required 30 different systems to be modified, and even after that
integration, it is still tightly coupled.
Complicated legacy systems make it more difficult to develop application
function quickly.
Large number of legacy system interactions is expensive to maintain.
Some systems are not reliable (FNOL is required to be recycled daily).
If we bring products in, we dont have the opportunity to see all the features.
There is no end-to-end security.
There is no end-to-end systems management.
Current IT standard
While some extensive standards documents have been promulgated over the
years, the most effective standards at ShopCo are de facto. This can clearly be
seen by examining the current IT environment. The use of COBOL as an
application development standard has been maintained more as a default than
an active choice. Enterprise program development has with some exceptions
been restricted to COBOL under CICS and IMS.
Within the stores, the C language is in use, as is Informix. There is a limited

amount of Visual Basic used in the client/server space, and some traces of the
beginnings of Java development.

There does not appear to be an agreed upon standard for future application
development.
There is no specific standard for the Web platform.
Database standards are DB2 Universal Database (UDB), with SQL server as a
second option. But there is some Sybase and some Access, as well as FoxPro
and Approach.
At the same time, there is a decided and verbalized proclivity toward the use of
packaged software. Although many of these package standards remain to be set,
the decision to use packages where possible should itself be treated as a
standard.
Host platform
S/390 Version 2.10
COBOL
VSAM
IMS
Image Plus
CICS Version 1.2
DB2 Version 6.2
Client/server platform
PowerBuilder
Sybase
Visual Basic
Oracle
Excel
Access
Ethernet (token ring)
Windows 2000 Desktop (Windows NT)
Windows 2000 Server (Novell)
Brio
Server platform
AIX
Sybase
Powerbuilder
MDI Gateway
SNA Comm Server
PeopleSoft
Windows 2000 Server

SQLServer 7
FDR backup
Browser client
Citrix plugin
IP
IE 6.0
Mapping business initiatives to projects

Table A-2 shows an example of a table for mapping business initiatives to
projects.
Table A-2 Mapping business initiatives to projects

Topic Key Goal #1 Goal #2
Business goal Strategic business goal Improve employee Reduce training costs
productivity
Business initiative Customers name for Collaboration Distance Learning

business initiative
Project name Customers name for Advanced collaboration Enterprise eLearning

the project or initiative
Project description Brief description Enterprise-wide rollout Training for merger,

of collaboration tools agents, call center,
applications
Customer sponsor E = executive E = Mary Smith P = John Doe

P = project
(include contract
information)
Project status Customers project Plan Plan

status
Existing solution or None *Placeware,

competition *ASP Berbee
LearningSpace
Annual cost of existing Unknown ASP through Berbee

solution or competition Approximately $4,000
per month + per user
access
Money in budget Yes or no and amount if None Yes

known

Topic Key Goal #1 Goal #2
Decision date 10/01/2002 08/09/2002
Deploy date 11/01/2002 10/01/2002
Comments Currently piloting 40 Stated corporate

licenses of ST in the evaluation in April/May
Minneapolis location. by Dave Ms team
Looking at enterprise
rollout.
Mapping projects to proposed products and solutions

Table A-3 shows an example of a table for mapping projects to proposed
products and solutions.
Table A-3 Mapping projects to proposed products and solutions

Topic Key Project #1 Project #2
Project name From business Advanced collaboration Enterprise eLearning

initiatives sales aid
Proposed IBM product Product name SameTime LearningSpace

or solution Collaboration
IBM Software part PA number D5CT2LL D5CPRLL

number
Function What does it do? Real time chat and Distance learning
e-messages
Business value Value to customer Less phone tab, less Reduced travel and
travel, faster response tuition expense
training
Quantity 7000 7000
BAU unit price Normal PA discounted $28.12 $41.64

price
MLC Or other non OTC if

applicable
Total revenue Will calculate qty x bau $201,000.00 $291,480

rsvp
IBM Lead/Team L = lead L = Steve W L = Tom B

members M = member
(include contact info)

Topic Key Project #1 Project #2
Comments Licenses of SameTime Stated corp. evaluation

in the Minneapolis in April/May by Dave
location. Looking at the Ms team.
enterprise rollout.
Non-functional requirements
The non-functional requirements are explained in the following sections.
General
Because the projected changes to the system involve a large number of
black-boxed applications (systems that are not yet selected), it is not possible to
obtain accurate non-functional requirements in some cases. Although gross
approximations can be used, the system must be sufficiently scalable to
accommodate substantial differences in the actual build-out.
Performance
Average response time for external Internet-based applications is to be less than
7 seconds. To make this reasonable, a specific use case transaction time is
assumed to be no more than 2 seconds. Exceptions to this are the ERV
application, which must be less than 5 seconds, and the CCamp application,
which must be less than 1 second.
Capacity/volumes
Store TLOG files run at an average of 15 MB per store per week over 102 stores.
This constitutes a capacity of approximately 2 GB per week, or about 100 GB per
year. This is required for the trickle system, ETL tool, and the data warehouse,
and possibly the integration hub.
The transactional systems must be able to accommodate 350 concurrent users.

The users will generate a transaction every 5 seconds, on the average.
Scalability
Because the identity of many of the future packaged systems cannot be known
with certainty, the integration scheme must be easily scalable within an order of
magnitude, that is, a factor of 10. The possibility of mergers and takeovers
requires this capability as well.
Hardware upgrades must be able to be accomplished using the same class of

server. That is they must be able to scale horizontally.

Availability/fault tolerance
The point-of-sale machines are critical to the business operation
minute-to-minute. They should be managed to reduce the possibility of failure to
a minimum. They must be available 24x7x365 for 72 stores, and 14x5x200 for the
remainder.
The current system of providing a single installable replacement for a store

server is cumbersome. However, since there is currently a flexibility of several
hours allowed in replacing an inoperative machine, it is not dangerous.
Usability
Applications must adhere to the ShopCo Common User Interface (SCUI) for all
browser-based applications.
Portability
Because of the projected consolidation and migration of production machines in
the third quarter, all applications developed for this system are required to be
portable across runtime platforms. Projected package purchases and uncertainty
as to merger possibilities also make it prudent to ensure that the new
applications can run wherever they are required.
Maintainability
No specific requirements are noted.
Security
End-to-end security should be specified before application package selection.
Single signon is a requirement, and application packages must be able confirm
to the corporate standard. Security functions should not be performed within
applications unless they are approved by the chief architect.
In general, the system should have few entry points, should use hardened
gateways, and should authenticate users at entry points, not within applications.
The system must have a security code distributed to only a few nodes, must
extend end-to-end, and must be based on modularity rather than an
interdependence between security and applications.
Infrastructure constraints
MQSeries is the required messaging mechanism. Oracle is used for all GFV
applications and DB2 is used for all others.
Most business application are host legacy systems.

Geographic and configuration constraints
Configuration cannot include single points of failure. Configuration must support
local deployment within both Western Europe and PAC RIM countries (regions).
Operational model
Figure A-8 shows an example of an operational model diagram.
Figure A-8 Operational model diagram example

Project description
This can be a highly detailed description of one specific project. This example is
from an integration architecture that touches many different projects.
Group manager workbench

Provide the group manager with the decision support tools that are need to
perform exception-based analysis. This includes the delivery of personalized
corporate data. Automate the monthly financial and inventory reconciliation.
Automate the store checklist process. Automate the back-feed data for two-way
internal flow.
The architectural implication is that this project requires a portal or

personalization intranet infrastructure and attachment to the legacy system by an
integration hub.
Implement TRN
Migrate to the TRN Market Point-of-Sale (POS) applications. Customize TRN
application to cover high priority GFN customizations. Integrate existing host item
maintenance and electronic payment systems with TRN.
The architectural implication is that the integration hub is used to couple TRN to
other systems.
Price optimization
Use a price optimization solution (DemandTec, or KhiMetrics) to facilitate more
effective margin management. Need ADM numbers to expand beyond classical,
rock, and early jazz categories.
The architectural implication is that the addition and integration of package

solutions is facilitated by use of the integration hub (and possibly the ETL tool).
new Item and Price Management

Consolidate Shopco item data into a single item master. Migration to a new item
master is the foundation step for the migration to a new set of merchandising and
decision support tools. Include data definition work to enable the transfer of item
data. Need technology integration hub.
The architectural implication is that the implementation of this application is

greatly facilitated by the use of the ETL tool and the integration hub.
Data warehouse
The data warehouse provides the foundation for cost accounting, category
management, and GYPSY replacement. The data warehouse provides a single

source of item data for all future ShopCo applications. It is dependent on the
TLOG data.
The architectural implication is that the implementation of a data warehouse is

dependent on the trickle data movement mechanism and is greatly facilitated by
the ETL tool.
Replace the DSD Receiving system

Replace the DSD Receiving system. Implement DEX to automate the store level
direct delivery vendor receiving. This will ensure data integrity, improve
productivity, and enable more detailed receipts at store level.
The architectural implication is that if this system is determined to have to

interface with legacy systems, then the presence of an integration hub (and
possibly ETL tool) will make its implementation much simpler and less expensive.
System context diagram

Figure A-9 shows a simple system context diagram that indicates the position of
the new system within other existing or future systems.
Business
Partner New
Systems Packages
New Legacy
Architecture Systems
Branch
Systems
Intranet
Datamarts
& Internet
Systems
Figure A-9 System context diagram example

The integration architecture interfaces with substantial number of existing legacy
systems and with a series of new business packages which are not yet selected.
Because these packages must be treated as black boxes, flexibility must be a
primary criterion for architectural design. At the same time, the new system must
integrate with Internet and intranet-based systems and business partner
systems. Since many of these processes are executing outside of the enterprise
center, security must also be taken as a primary issue. Finally, the addition of the
new datamarts and the movement toward a unified ODS requires the new
architecture to accommodate data integration as well as process integration.
Systems context diagrams for an integration architecture

Figure A-10 shows a systems context diagram for an integration architecture.
Category Time and Financial Drop

Shelf List Categories EDS CS
Managem ent Attendance System s Shipments
Distribution Direct
Systems Delivery
End User
Computing
Reclamation
Direct
EDI Store Support
Seasonal Pharmacy
Applications
Human
Price Resource s
Check
Continu ous Store Price Store Order

EFT Factor Toys
Replenishm t Application s Book Processing
Figure A-10 Systems context diagrams example for an integration architecture

Use cases
Use cases in these architecture documents are not programming-level use
cases, but rather high-level descriptions of how a system works. As shown in
Figure A-11, this example involves more than one actor.
8 Judge
3-4, 5, 6-7
System 9
12-13
Safe
Social Haven
Worker
10 Clerk
Police
11 Dispatcher
Social Work
Supervisor
Figure A-11 Use cases diagram example
The following information further describes Figure A-11:

Actor: Social worker.
Description: A social worker spends most of the time working in the field on
individual cases. The social worker frequently needs access to the
departmental systems in real time.
Use Case #1: It makes provision for a child in danger.
Event: A social worker is called to a household where she determines there is
a child in eminent danger. The child needs to be removed to a safe haven.
Actors: Social worker (and judge, safe haven clerk, police dispatcher,
supervisor).

Overview: The social worker uses a personal digital assistant (PDA) to
connect to system. They select the eminent danger process, and complete
the form to request court approval, safe haven, and police assistance. The
system arranges and records all transactions and messages for the social
worker to proceed.
Preconditions: These are valid cause for removal of child. They include the
availability of a safe haven and the establishment of remote communications.
Termination outcomes: The social worker receives approval and assistance
for removing child.
Use case description

The use case in this scenario follows this sequence:
1. The social worker connects the PDA to a system and logs on.
2. The social worker selects the process and receives a search screen.
3. The social worker enters the name and address information. Then they click
Search.
4. The screen returns a list. The social worker selects the correct items, clicks
OK, and receives the case information.
5. The social worker selects an option for the application to remove child and
receives form.
6. The social worker fills out the form and submits it. Then they log off the
system.
7. The form information is received at the server and passed by the workflow
system to the courts.
8. The approved request is passed to police dispatcher.
9. The approved request is routed to the safe haven desk and the custodian.
10.The approved request is forwarded to a social services supervisor.
11.When the workflow system successfully negotiates with all of these services,
the social worker is alerted via the PDA with the instruction to read the
approval message.
12.The social worker connects to system, logs on, and receives the message
with the approval document, the name and address of the safe haven (with a
map), and estimated time of arrival of police assistance.
A programming use case for this scenario looks similar to the example shown in
Figure A-12.

System
Social
Worker
SW completes
Social seachsearch
worker completes sc reen
screen
System returnslistlis t
System returns
SW
Social selects
worker case
selects case
System returns
System returnsform
form
SWworker
Social c ompletes form
completes form
System returnsauthorization
System returns authoriztion
Figure A-12 Programming use case example
Viability assessment
This example represents the initial assessment of viability for the current
architecture. It may include risks, assumptions, issues, and dependencies.
Table A-4 shows the risks section.
Table A-4 Example viability assessment

Risk Risk description Probability Impact Contingency or mitigation Initiative
Ref. (H/M/L) (H/M/L)
1 Point-to-point H H Adopt integration architecture to

connectivity for avoid point-to-point connections.
applications will
become increasingly
expensive and rigid.

Risk Risk description Probability Impact Contingency or mitigation Initiative
Ref. (H/M/L) (H/M/L)
2 Home-grown M-H H Use standard third-party

messaging functions queuing mechanism.
will become
undependable and
expensive to maintain.
3 Current Internet-client H M-H Provide a more standard and

model (using Citrix) will efficient browser-client model.
become expensive and
unwieldy.
4 Lack of end-to-end M M-H Provide end-to-end security for

security architecture integration architecture.
will result in excessive
exposure and
maintenance cost.
5 Security violation of the M H Implement screened sub-net

system running in the architecture.
demilitarized zone
(DMZ).
6 Support cost for H M Enforce existing desktop

desktop will continue to standards. Standardize on thin
rise client intranet development.
Standardize reporting tools.
Provide desktop data backup.
Standardize printing strategy.
Note the following explanations for probability and impact in Table A-4:
Probability:
High: The risk identified is probably going to occur, or is already occurring.
Medium: The risk identified is about as likely to happen as not to happen.
Low: The risk identified is unlikely but still worth considering.
Impact:
High: Resolution is likely to require difficult decisions, probably above the
level of the project manager, which is likely to affect the schedule, budget,
or functional completeness of the project.
Medium: Special management attention is required, but it should be
possible to contain the risk within the project plan.
Low: Normal management attention should be sufficient to resolve the
issue.

B
Appendix B. Software deployment

checklist
This appendix contains a series of checklists of the activities and tasks for the
Software Deployment Method (SDM). You can print it and use it as a reminder of
the items in each phase and to track your progress as you complete the items.

Software deployment steps
Activity Owner(s) Date completed Notes
Step 1: Create the Software

Deployment Team
Step 2: Review the critical deployment

documents
Step 3: Develop a high-level

deployment plan
Step 4: Establish a deployment

partnership
Step 5: Refine the high-level

deployment plan
Step 7: Conduct deployment kickoff

meetings
Step 8: Achieve quick deployment

wins
Phase 1: Prepare for deployment

Step 1: Create the Software Deployment Team
Gather the Software Deployment

Team
Get commitment from each member
Communicate roles, responsibilities,

and expectations

Step 2: Review the contract content and critical deployment
documents
Discuss the buying decision
Ensure that the content, terms and

conditions of the contract are
thoroughly understood by all SDT
members
Study and understand any

substitution clauses
Understand the status of maintenance

and support
Discuss any expectations
Discuss license management tools

and processes and how to track
deployment
Review the requirements, solution

concepts, business context,
conceptual architecture, and
architecture decision document
Review and refine the initial viability

assessment (which includes the
results of any Solution Assurance
Reviews (SARs)) and confirm the
solution
Document the linkages between the

planned projects and products
Appendix B. Software deployment checklist 125

Step 3: Develop a high-level deployment plan
Validate and refine the goals and

milestones
Group deployment into logical chunks

based on business initiatives; assign
ownership to the initiatives
Refine the list of projects and assign

ownership
Create a high-level deployment

timeline or phased execution plan for
building the entire solution
Assess gaps where services will be

required
Assess the need for infrastructure

management projects
Review an initial license utilization

report and identify where existing
software will be used and how new
software will be tracked
Determine any gap between products

with defined projects and products
that require further project definition

Step 4: Establish a deployment partnership
Confirm the buying decision and

vision
Identify quick deployment wins
Define deployment milestones and

measurements
Review skill and project gaps and

define a strategy to address
Review and discuss any roadblocks

that could impact deployment
Validate project owners
Schedule date for first kickoff meeting
Phase 2: Refine and promote the plan

Step 5: Refine the high-level deployment plan
Review the past activities, documents,

and decisions
Perform any necessary performance

and capacity modeling
Recommend a physical architecture
Refine hardware and software

requirements
Discuss environmental and

infrastructure requirements
Create a draft of project controls
Update the deployment and quick

deployment win plans as needed

Review and finalize the deployment

plans
Discuss any appropriate migration

strategies
Discuss any appropriate conceptual

data model for legacy data
Finalize the recommended physical

architecture
Finalize the systems management

plan
Gain agreement on project controls
Update the quick deployment win

plan, if needed
Finalize project ownership
Finalize software deployment

milestones and metrics

Step 7: Conduct deployment kickoff meetings
Present the vision that drove the

software purchase
Link the products purchased to the

business initiatives and vision
Discuss the high points, terms and

conditions, and critical aspects of any
contracts
Communicate the business value and

benefit
Show the business context and

high-level architecture
Present the high-level deployment

plan and timeline
Discuss the breadth of the deployment

(local, regional, national, or global)
Discuss the roles and responsibilities
Discuss any known roadblocks and

the plan to overcome
Communicate the quick deployment

win plan
Discuss the software deployment best

practices
Present the key benefits of the major

driver projects
Arrange for demonstration of key

products if necessary

Step 8: Achieve quick deployment wins
Assign project managers to quick

deployment win projects (internal,
IBM, or third party)
Verify and augment the capabilities of

the quick deployment teams assigned
to the projects
Execute the quick deployment win

plan
Manage the projects with project

controls
Conduct regular meetings with the

project owners
Monitor progress of quick deployment

projects against plans and make
adjustments as needed
Implement recommendations defined

during readiness discussions
Address and resolve technical issues

that may arise
Maintain close contact with project

owners, stakeholders, and sponsors
Execute early phases of the education

plan
Monitor the satisfaction of the solution

users

Advertise quick deployment wins

with meetings or open house
events
Assign deployment project

managers
Educate additional users on

software support processes
Verify and augment capabilities of

the deployment teams assigned
to the projects
Begin executing projects per the

deployment plan
Manage the projects with the

project controls
Monitor progress against the plan

and make adjustments as needed
Address and resolve technical

issues that may arise
Maintain close contact with the

stakeholders and sponsors
Monitor overall satisfaction
Track software license utilization
Revise the deployment plan to

include the new requirements
Seek out new demand
Manage these new projects as

done in Step 9

Incorporate any lessons learned

from the recent deployment into
future plans
Determine the technical needs of

the identified projects
Apply current software inventory

and new software purchases
toward the future deployment
plans
Return to Phase 1, Step 2

C
Appendix C. Global software deployment

checklist
Experience has shown that a Global Project Lead will have a difficult time
focusing on multiple deployment sites all over the world. This is because certain
sites will demand greater levels of attention at the expense of lesser sites that are
perhaps not as problematic. A good example of this is a primary site where the
majority of the software is being deployed. This site by natural will absorb a lot
more of the project leaders attention. To combat this issue, this appendix
provides a list of key global activities. You should revisit this list periodically to
ensure that all important work items are being done.

Global-level activities executed by global deployment
lead
Your decision making team determines,

prior to the software purchase, that
software will be deployed in multiple
cities, countries, or regions around the
world.
Your executive team assigns a Global

Project Lead (GPL) to focus on software
deployment at all sites.
The GPL obtains a full understanding of

the buying decision.
Primary, secondary, and tertiary

deployment sites are identified.
The GPL works with the Software

Deployment Team (SDT) to draft a
high-level plan for software deployment
with high level milestones. All known
deployments sites are placed in the
timeline. This high-level plan needs to
be dynamic. It is adjusted as
deployment sites are discovered and
milestones are achieved.
The GPL identifies a team within the

vendor who will assist them at the
worldwide level.
A Document of Understanding
(DOU) should be written between
the customer and the vendor.
The vendor should commit to
assigning or aligning resources with
all deployment sites around the
world.
The vendor should provide names
and full contact information.

The GPL determines how software will

be customized and implemented to
match requirements. For example, they
may build a gold disk that can be used
to ensure that all software deployment is
identical on every desktop and server
around the world.
The GPL needs to monitor software

deployment activity around the world to
ensure that all activity falls within
standard guidelines set at a global level.
The GPL meets periodically with all site

leaders to review deployment progress
and milestones. This meeting should
include all sites that may not yet have
begun deployment software.
The GPL schedules periodic meeting

with your decision making team and the
site leaders to checkpoint deployment
progress and raise any critical issues.
The meetings are used to review
deployment milestones and value
realization milestones.
The GPL remains aware of all new

software purchases around the world.
When these purchases are finalized all
software should be immediately moved
into software inventory.
The GPL circulates a status report

monthly to your decision-makers,
business sponsors, and the entire
Software Deployment Team around the
world.
Appendix C. Global software deployment checklist 135

Local sites (secondary part-time coverage)
Site leaders meet with local vendor

teams frequently to discuss
deployment plans and challenges.
Site leaders report status to the GPL

on a predefined frequency. They
report deployment status,
accomplishments, challenges, and
escalation points.
Site leaders drive deployment

activities in their location.
Local sites (tertiary on demand coverage)
Tertiary coverage is available in

reactive situations only.
Each deployment site that is not

primary or secondary should at least
have a named resource aligned with it
to monitor and escalate challenges
that may impact the deployment
progress.
Your vendor should also provide

tertiary coverage at each one of these
sites. This coverage should be aligned
with the products, solutions, or both
being deployed at each site. The right
expertise should be available to help
resolve issues quickly.

D
Appendix D. Additional material

This redbook refers to additional material that can be downloaded from the
Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246070
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the redbook form number, SG24-6070.

Using the Web material
The additional Web material that accompanies this redbook includes the
following files:
File name Description
checklists.zip A Microsoft Excel spreadsheet that contains the
templates in Appendix B, Software deployment checklist
on page 123, and Appendix C, Global software
deployment checklist on page 133.
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the
Web material zip file into this folder.

Glossary
ADD See architectural decisions document. business goals Brief objectives of the company
that must be achieved to enable the fulfillment of the
architectural decisions document (ADD) Lists vision.
critical architecture decisions or choices made in the
design phase. It also describes the rationale for CITA See Client IT Architect.
making them.
Client Executive Builds a long-term business
architecture overview diagram Illustrates the relationship with the client. Identifies IBM
basic ideas of the proposed architecture. It is the opportunities and develops solution strategies that
equivalent of the architects sketch. Depending on meet the clients business needs. They maintain
the context, the diagram may range from basic to customer business relationships at the senior level
more detailed. Related work products are the with key decision makers and influencers. The Client
system context diagram, component model, and Executive is accountable for total client satisfaction,
operations model, where additional detail is IBM market share, revenue, and profit earned from
conveyed. Typically, the diagram evolves with a the client. They partner with the Software Account
greater level of detail as the architecture is better Manager (SAM) to drive software sales and partners
understood. The diagram serves as a means of with sales and technical specialists in hardware and
confirming architectural understanding between IBM services to drive respective sales.
and the customer.
Client IT Architect (CITA) A role similar to that of
backup and recovery plan Identifies the the Software Architect (SWA) and Software
necessity for backup and recovery and how backup Deployment Architect (SDA). The CITA has IT
and recovery impacts the customers internal responsibility for the entire IBM relationship with the
service-level agreements. Customers should customer, including hardware, software, and
identify who is responsible for backup and recovery services. The relationship among the CITA and the
and document the procedures in their support plan. software technical team is critical.
best practices Actions recommended by Client Representative Builds a long-term

experienced software deployment personnel. When business relationship with the client by providing
followed through the life of the Enterprise Agreement total solutions to a clients business needs. The
(EA) and the Software Deployment Method (SDM), Client Representative identifies and qualifies IBM
best practices help to ensure deployment success. opportunities, engages the appropriate IBM
resources, gains client commitment to solutions
business context diagram and when appropriate, and ensures overall client
description Used to document the identity of the satisfaction. The representative manages IBM
business area being served by the development opportunities while guiding the development of the
effort and its interactions with other business entities solution and support strategies. They partner with
in its environment. These entities and interactions the SAM to drive software sales and partners with
are the sources and channels for flows of sales and technical specialists in hardware and
information into and out of the business. This is key services to drive respective sales.
to developing a system that is properly situated in
the clients business.

communications plan Reflects all the direct and deployment architecture The blueprint of what
indirect parties involved with the deployment project. will be deployed in the customer account. It
Describes who is responsible for every aspect of the combines the work products that depict the
implementation. This plan should also describe the architecture to be deployed (architecture overview,
escalation process in case of problems. operational model, and project descriptions for
example) with the deployment plans, metrics, and
component models Documents that include milestones of how it will be accomplished.
responsibilities and required service levels for each
component. The responsibilities are described from deployment kickoff meeting Markets and
the view of a user of the component and later refined communicates the deployment plan (and vision) to
into specific operations. The service level for the all current and potential users within the customers
component is described in regard to users and environment. All key leaders must attend (the full
presentation, performance and capacity, and IBM team and the customer team project leads, IT
availability design rationale, reasonableness and leads, and lines of business leaders). The kickoff
risk, and implementation approach. meeting should create awareness, understanding,
and enthusiasm for the deployment that is about to
critical success factor (CSF) The limited number begin.
of areas where satisfactory results ensure the
achievement of the business goals. Business issues deployment plan (high-level and detailed) A
can be used to identify the CSFs. high-level version is developed early in the
deployment method and defines a list of initial
CSF See critical success factor. deployment projects, identifies customer sponsors
and owners for known projects, groups deployment
customers IT environment A work product that into logical chunks, contains a deployment timeline,
documents the customers existing logical and and includes a services assessment. A more
physical design, existing databases design, existing detailed version is developed later in the method as
Web environments (servers, firewalls, for example), more projects and information are known. It is
security requirements, operational parameters considered the deployment bible.
(24x7 for example), end-to-end performance
requirements, and existing standards (such as EA See Enterprise Agreement.
naming and protocols).
education plan Assesses the skills needed for
customers organization A work product successful deployment, current customer skills, and
description that includes an inventory of the steps to close all identified gaps.
organizational elements (structures, behaviors and
enablers) for the in-scope organizational units (for Enterprise Agreement (EA) A multi-platform
example, corporate organization, strategic business software offering that includes IBM Eserver
unit (SBU), functions, teams, and individuals). The zSeries monthly license charges (MLC) and
influencers and owners may be key to defining who one-time charge (OTC). It is a special offering that
to call for a given solution. An organization chart may contractually leverages the Enterprise Software and
be color-coded, for example, to indicate who is Services Option agreement. In most cases, this
directly involved in the decision process. agreement replaces or amends other IBM
agreements (for example, Passport Advantage) that
are referenced under the offering. The average life of
an EA is three years, but the term can be as short as
one year.

Enterprise Business Sponsor Represents the license management Involves identifying which
customer and takes ownership for the software licenses are installed, which ones are active, and
deployment throughout the enterprise. This sponsor how many licenses are forecasted to be deployed.
commits to: To assist in this area, Tivoli has a tool called IBM
Develop the internal vision for promoting the Tivoli License Manager that became available in
maximum utilization of purchased licenses, November 2002.
based on the benefit derived.
list of projects and owners A work product that
Work with lines-of-business and IT leads to lists all the potential projects, what brands are
delegate responsibility for deployment success involved, the deployment sites, the customer
and return on investment (ROI). owners, and their contact information. This helps to
Represent the business globally, if applicable. ensure that, when deployment begins, information is
available to help drive deployment activity.
Define deployment milestones for the entire
term of the Enterprise Agreement. Managing Director Has overall responsibility for
Assist with marketing and demand generation of the global relationship within the account, including
the software portfolio within the organization. responsibility for profitability.
Establish deployment quick-win initiatives to
mapping business initiatives to deployment
establish project credibility as early as possible.
projects to products A work product that acts as
envisioned goals and issues (project ideas that a map that connects products with projects. It links
emerged early in the sales process) A work each project to the business goals or initiatives that
product that documents the clients mission drove the original sale.
statement, vision statement, to-be business goals,
migration plan The act of customers moving their
and critical success factors.
current versions of software or hardware to newer
execution environment plan Recommends an versions (or to new platforms). Migrations can be
appropriate environment and level of discipline for complicated and may create cost and time overruns
development, test, and change management during that can cause serious problems. Migration plans
deployment. describe the activities and timetables for doing the
migration. Some of those activities include customer
gap analysis A listing of products that is burned by code regression testing, execution environment
defined projects and products that have yet to be tests, migration automation scripting, and back out
linked to planned projects (the latter is called planning.
potential shelfware). The unlinked products
constitute the gap. Gap analysis is also referred to mission statements The operational, ethical, and
as software demand gap analysis. financial guidelines of companies (or functional
areas). They articulate the goals, dreams, behavior,
global software deployment The deployment of culture and strategies of companies. This should be
IBM licensed software for an account that has information that is already created by the client.
deployment locations that span two or more Sometimes called value statements, credos, or
geographies. principles.
IT standards A work product that documents all operational model A work product that specifies
known IT standards that the architecture must the hardware that the desired architecture requires.
accommodate.
ITS See Software Technical Sales Specialist.
Glossary 141
project descriptions Communicates the project return on investment (ROI) The value that a
goals to everyone who needs to know. Provides customer receives on their investment in software,
answers to the question, What are we doing on this hardware, and services. Hard ROI can be quantified
project and why? The document provides brief with dollars or numbers and is associated with
descriptions of the business problems that the headcount savings, system count reduction, server
deployed projects will solve. consolidation, and department closures. Soft ROI is
more difficult to project and quantify, and involves
quick deployment wins Projects selected for their perceptions and satisfaction.
high-probability of success, their importance to the
customer, and their ability to complete in a relatively ROI See return on investment.
short period of time. The Software Deployment
Team (SDT) wants the customer to complete these rollout plan and schedule Includes all the
as early as possible in deployment because they individual plans listed in the readiness plan, with a
generate momentum, enthusiasm, support, and schedule and priority attached to each activity.
positive first impressions.
RUP See Rational Unified Process.
quick deployment wins plan Identifies projects
selected for their high-probability of success, their SAM See Software Account Manager.
importance to the customer, and their ability to
complete in a relatively short period of time. The SAR See Solution Assurance Review.
plan also contains the milestones and metrics
associated with the projects. scope creep Projects that gradually extend
beyond their original charters and add functions that
Rational Unified Process (RUP) A require software that was not in the original contract.
Web-enabled set of software engineering processes
that provide you with guidance to streamline your SDA See Software Deployment Architect.
teams development activities.
SDM See Software Deployment Method.
readiness plan Fosters proactive communications
SDT See Software Deployment Team.
between IBM and the customer and promotes
smooth deployment. It is a set of processes and
service level agreements A contract between the
work products designed to:
customer and their users for providing availability,
Level set customers expectations.
capacity, scalability, performance, and security of
Assign responsibilities and ownership.
the system.
Determine the customers implementation
readiness. services requirements document A work
Plan transition from pre-sales to post-sales product that lists the services that the Software
activities. Deployment Team believes the customer will need
Assure that customers use cases during deployment because they are critical to
(requirements) are met. deployment success. The deployment team
Identify risks for mitigation and escalation. identifies these requirements during the preparation
phase of deployment, reviews them with the
customer, and hopefully convinces the customer to
purchase them.

Software Account Manager (SAM) Sells IBM Software Deployment Architect
Software in selected large accounts or Small and (SDA) Accelerates deployment of software
Medium Business (SMB) territories and builds solutions and designs additional technical solutions
customer relationships. The SAM, along with the that leverage the entire IBM Software portfolio to
SWA and SDA, have cross-brand responsibility, so resolve a customers business and IT challenges.
they have overall responsibility for selling and The SDA should assume the role of trusted advisor
customer success across the entire IBM Software to the customer. They should leverage this
Group (SWG) portfolio. SAMs are involved early relationship to identify and design solutions that
because they work with the brand Software Sales satisfy software purchased inside and outside the
Specialists, the Software Technical Sales Enterprise Agreement. The SDA is key to customer
Specialists, and the Software Architects to define satisfaction because they ensure that the customer
and qualify an opportunity. Each SAM provides a realizes value from the EA. Since a multitude of
single sales face to the customer across all the projects and activities surround an EA, the SDA
software brands in their assigned accounts. provides a single point of contact for EA-related
questions and issues.
Software Architect (SWA) Designs
comprehensive technical solutions that solve the Software Deployment Method (SDM) A
customers business and IT challenges while recommended 3-phase, 11-activity process that a
maximizing IBM Software revenue. Software Software Deployment Team should follow when
Architects are valued because they first listen to the deploying software in an Enterprise Agreement
customer and then analyze the customers business environment. Ideally, the first phase and activity of
and IT challenges. They then design a SDM should begin when the possibility of the
comprehensive solution that integrates smoothly contract being signed is at approximately 80%.
into the customers context, and that leverages the
best of the entire IBM Software portfolio. software deployment milestones and
metrics The critical checkpoints and measures
software demand gap analysis A listing of that the Software Deployment Team defines with the
products that is burned by defined projects and customer and then follows closely to help ensure
products that have yet to be linked to planned that deployment progress is on track.
projects (the latter is called potential shelfware). The
unlinked products constitute the gap. Software Deployment Team (SDT) The
individuals responsible for deployment success.
software deployment Putting software into use or This team should consist of:
action. Achieving deployment success requires that EBS
the customers implement the software license on SAM
each endpoint and that they use this software to SDA, SWA, or both
overcome challenges, achieve their IT goals, and IT Specialists from the brands
gain a competitive advantage. Services representative(s) (IBM Global
Services, Brand, Education, Support, etc.)
Software Group Team (SWG Team) Consists of

the Software Account Manager, the Software
Architect, the Software Deployment Architect, the
Software Sales Specialist (SSS), and the Software
Technical Sales Specialists.
Glossary 143
Software Sales Specialist (SSS) Sells a systems management plan A comprehensive
particular set of IBM Software and works with SAMs, plan that documents the customers change and
Software Technical Sales Specialists, and Software configuration management plan, security
Architects in doing so. They have knowledge of IBM management plan, problem management plan, and
strategies and directions for the products they who is responsible for solution uptime during
represent. They are responsible for closing the sale deployment.
and positively impacting the customers satisfaction
with the engagement and offerings. use cases A work product that specifies customer
requirements in the areas of performance,
Software Technical Sales Specialist capacity/volumes, scalability, availability, portability,
(ITS) Advocates IBM products to technical decision maintainability, usability, systems management,
makers. The ITS can create new revenue security, infrastructure constraints, technology
opportunity, champion brand image, and position standards constraints, and geographic/configuration
IBM as the leader in providing software solutions constraints.
that meet the customers technical challenges. The
ITS also provides a bridge between the customers Value Realization Model (VRM) A software
technical challenges and potential product solutions. deployment work product that ensures that IBM and
the customer fully understand how the customer
Solution Assurance Review (SAR) Minimizes plans to measure deployment success.
deployment risk. Used to review solutions proposed
to the customer during the selling or deployment viability assessment This work product describes
phases of the EA. Ensures that the proposed architectural risks, prioritizes (high, medium, and
solution delivers the features expected and that the low) the probability and impact of each, and
solution is technically possible to implement. identifies contingency plans for each risk item.
SSS See Software Sales Specialist. vision statements The long-term objectives of the
company. They articulate the companys target
support plan Addresses how IBM will deliver marketplace, products and services, and the
support to the customer and how the customer will position the company wants their products and
support their users during deployment. services to have in the targeted marketplace, as well
as the financial position (revenue, profit, etc.).
SWA See Software Architect.
VRM See Value Realization Model.
SWG Team See Software Group Team.
system context diagram Helps to clarify the

environment on which the solution will operate. This
diagram documents all connections between the
proposed system and external systems and
components. Associated with each connection are
various attributes such as data description, protocol,
formats, frequency, volume, model of interaction
(synchronous, asynchronous), etc. This context
constrains the proposed system with regard to the
interfaces that must be implemented. The system
context diagram may provide a rationale for a make
or break decision on whether to go forward.

Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
Online resources
These Web sites and URLs are also relevant as further information sources:
Instant messaging, Web conferencing, and team workplace tools
http://www-3.ibm.com/software/collaboration
Problem management self help and support
Passport Advantage
http://www.lotus.com/services/passport.nsf/WebDocs/
Passport_Advantage_Home
Education
http://www-3.ibm.com/services/learning/training_cat.html
IBM Tivoli License Manager Intelligent software license management to
help optimize business value
ftp://ftp.software.ibm.com/software/tivoli/whitepapers/
wp-license-mgr.pdf
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks

Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services

Index
IT environment 89
A organization 89
account planning 92
customer team 14
Achieve the quick deployment wins 58
ADD (architecture decisions document) 88
analyze the software in your inventory 44 D
analyzing ROI 36 department closure 33
architecture decisions document (ADD) 88 deploy software 57
architecture overview diagram 88 deployment kickoff meeting 28
Architecture plan 93 Deployment Milestone Status Report 91
architecture plan 94 deployment plan 92, 94
deployment quick-win plan 92
deployment services 86
B Develop a high-level deployment plan 45
best practice 9, 21
documentation review tips 44
centralize software fulfillment 24
commit to self-sufficiency 27
communicate and market the vision 28 E
define a time-to-value and ROI strategy 28 Easy Access Portal 83
determine your deployment readiness 26 education 85
hire deployment services 26 education and skills plan 93
identify an EBS and stakeholders 23 Enterprise Business Sponsor 14
implement a license management tool and pro- entitlement 84
cess 25 Establish the deployment partnership 47
business context diagram and description 88 example
business goals 89 architecture decisions document 94
buying decision 32 architecture overview 96
business context diagram 97
component flow model 100
C component model 98
centralize software fulfillment 24
current business organization 105
CITA (Client IT Architect) 20
current IT environments 100
Client Executive 20
current IT standard 108
Client IT Architect (CITA) 20
envisioned goals and issues 106
Client Representative 20
mapping business initiatives to projects 110
Client Team 19
mapping projects to proposed products and so-
communication plan 93
lutions 111
component model 88
non-functional requirements 112
Conduct the initial deployment kickoff meeting 54
operational model 114
conduct the initial deployment kickoff meeting 54
project description 115
coverage model 73
system context diagram 116
Create the SDT 40
systems context diagrams
critical success factors 89
for an integration architecture 117
customer
use cases 118
business goals 89
viability assessment 120

Execute the deployment plan 60 License Utilization Report 91
local site 75
tertiary, on-demand coverage 76
F
Finalize the deployment plan 52
full-time coverage 72 M
managing at the milestone level 68
managing global software deployment projects 71
G managing software deployment projects 65
Gap Analysis Report 91
getting started 66
global deployment
managing the success of your first project 68
activities 76
Milestone status report 93
checklist 74
mission statement 89
coverage example 77
My Software Center 83
global level activities 74
Global Project Lead (GPL) 15
global software deployment 71 N
checklist 133 non-functional requirements 90
projects 71
global support needs 44
goals and milestones 91
O
on demand coverage 73
H operations plan 94
hard (tangible) ROI 33 organization 89
hard ROI 28, 33, 35
headcount savings 33
high-level deployment plan 93
P
part-time coverage 72
Passport Advantage 84
I Phase 1, Prepare for deployment 39
IBM Client Executive 20 Phase 2, Refine and promote the plan 49
IBM Client IT Architect (CITA) 20 Phase 3, Deploy software 57
IBM Client Representative 20 potential shelfware 91
IBM Client Team 19 Prepare for deployment 39
IBM Software Account Manager (SAM) 17 primary site 72
IBM Software Architect (SWA) 17 primary, full-time coverage 74
IBM Software Deployment Architect 18 process tables 29
IBM Software Deployment Architect (SDA) 18 project controls 93
IBM Software Sales Specialist (SSS) 17 project descriptions 90
IBM Software Sales Team 16 project lead 14
IBM Software Technical Sales Specialist (ITS) 19 project management challenges 69
Identify new business needs 61 Project Planning 92
inexperienced project leader 69 project success 68
IT environment 89 project timing 66
IT standards 90
ITS (IBM Software Technical Sales Specialist) 19
R
readiness plan 26, 93
L overview 10
license acquisition 84 realizing value with hard and soft ROI 35
license management 80 Redbooks Web site 145

Contact us xv status of maintenance and support 44
Refine and promote the plan 49 Step 1
Refine the deployment plan 50 benefits 41
responsibilities 13 Create the Software Deployment Team (SDT)
return on investment (ROI) 33 40
Review the deployment documentation 42 inputs, tasks, and outputs 41
risks and dependencies 94 owners and participants 41
ROI (return on investment) 33 Step 10
current value example 37 benefits 62
ROI/ROR Status Report 92 Identify new business needs 61
roles 13 inputs, tasks, and outputs 62
owners and participants 62
Step 11
S benefits 63
SAM (IBM Software Account Manager) 17
inputs, tasks, and outputs 63
SAR (Solution Assurance Review) 10
scope creep 69
Update the business plan 62
SDA (IBM Software Deployment Architect) 18
Step 2
SDT (Software Deployment Team) 4
benefits 43
secondary site 72
secondary, part-time coverage 75
server consolidation 33
Review the deployment documentation 42
soft (intangible) ROI 34
Step 3
soft ROI 28, 33, 35
benefits 46
Software Account Manager (SAM) 17
Develop a high-level deployment plan 45
Software Architect (SWA) 17
software deployment 1
best practices 9, 21
Step 4
challenges 2
benefits 48
checklist 123
Establish the deployment partnership 47
continuous process 7
Phase 1, Preparing for deployment 39
Phase 2, Refine and promote the plan 49
Step 5
Phase 3, Deploy software 57
benefits 52
tools 79
inputs, tasks and outputs 51
Software Deployment Architect (SDA) 18
Software Deployment Method 3
Refine the deployment plan 50
Software Deployment Method (SDM) 4
Step 6
Software Deployment Team (SDT) 4
benefits 53
software gap 7
Finalize the deployment plan 52
software maintenance via Passport Advantage 84
Software Sales Specialist (SSS) 17
Software Sales Team 16
Step 7
software solution work products 87
benefits 56
Software Technical Sales Specialist (ITS) 19
Conduct the initial deployment kickoff meeting
Solution Assurance Review (SAR) 10
54
sponsor 14
SSS (IBM Software Sales Specialist) 17
stakeholder 14
Step 8
Index 149
Achieve the quick deployment wins 58 Work products used by SDM 88
benefits 60
Step 9
benefit 61
Execute the deployment plan 60
substitution clauses 44
SWA (IBM Software Architect) 17
system count reduction 33
T
Team IBM 15
tertiary site 73
Tivoli License Management 141
tools 79
U
Update the business plan 62
use cases 91
V
value realization 31
Value Realization Model (VRM) 91
value statement 32
value timeline 32
vision statement 89
W
why have a Software Deployment Method 3
work product
architecture decisions document 88
component model 88
customers IT environment 89
customers organization 89
goals and issues 89
IT standards 90
project descriptions 90
use cases 91
Work product examples 94

The Software Deployment Mystery - Solved! A Customer Guide
(0.2spine)
0.17<->0.473
90<->249 pages
Back cover
The Software Deployment

Mystery - Solved!
A Customer Guide
Reveals best To solve any mystery, detectives rely on their experience along
practices and with proven tools and techniques to unravel the conundrum. This INTERNATIONAL
methods proven to IBM Redbook addresses the often illusive mystery known as TECHNICAL
drive deployment software deployment success. The information, practices, and SUPPORT
success methods presented in this book have enabled many IBM customers ORGANIZATION
to achieve their business and IT goals more quickly and efficiently.
IBM has accumulated a wealth of knowledge and experience in
Offers actual
software deployment. The technologies we have developed, the
customer experience best practices we have authored, and the employees we have BUILDING TECHNICAL
as a guide cultivated are our greatest assets. Like a detective explaining how INFORMATION BASED ON
PRACTICAL EXPERIENCE
the mystery was solved, we use this redbook to pass on to you
Helps make the most our customers the experience, knowledge, and wisdom we have
of your relationship accumulated after years of solving software deployment mysteries. IBM Redbooks are developed by
with IBM the IBM International Technical
The primary audience for this redbook is the person who has Support Organization. Experts
ultimate ownership for software deployment performance. We from IBM, Customers and
Partners from around the world
refer to this person as the Enterprise Business Sponsor (EBS). create timely technical
Secondary audiences include anyone who is engaged in software information based on realistic
deployment activities. Both audiences benefit from the practices scenarios. Specific
and procedures described. recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks
SG24-6070-01 ISBN 0738498416

The Software Deployment Mystery - Solved! A Customer Guide by IBM

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

The Software Deployment Mystery - Solved! A Customer Guide by IBM

Hochgeladen von

Copyright:

Verfügbare Formate

Front cover

The Software Deployment

Reveals best practices and methods

Offers actual customer

Helps make the most of your

The Software Deployment Mystery - Solved!

Second Edition (February 2004)

Chapter 1. Why focus on software deployment? . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Copyright IBM Corp. 2003, 2004. All rights reserved. iii

Chapter 4. Value realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter 5. Software deployment Phase 1: Prepare for deployment . . . . 39

Chapter 6. Software deployment Phase 2: Refine and promote the plan 49

iv The Software Deployment Mystery - Solved!

Chapter 7. Software deployment Phase 3: Deploy software . . . . . . . . . . . 57

Chapter 8. Managing software deployment projects . . . . . . . . . . . . . . . . . 65

Chapter 9. Managing global software deployment projects . . . . . . . . . . . 71

Appendix A. Software solution work products. . . . . . . . . . . . . . . . . . . . . . 87

Appendix B. Software deployment checklist . . . . . . . . . . . . . . . . . . . . . . 123

vi The Software Deployment Mystery - Solved!

Appendix C. Global software deployment checklist . . . . . . . . . . . . . . . . 133

Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Copyright IBM Corp. 2003, 2004. All rights reserved. ix

The following terms are trademarks of other companies:

x The Software Deployment Mystery - Solved!

The best practices, presented in Chapter 3, Software deployment best

When we refer to success in this redbook, we are talking about holistic

Copyright IBM Corp. 2003, 2004. All rights reserved. xi

Chapter 8, Managing software deployment projects on page 65, provides hints

The team that wrote this redbook

xii The Software Deployment Mystery - Solved!

Thanks to Nestl Corporation, Francisco Esteve (Nestl Globe Project Leader),

We appreciate the contributions, guidance, and direction provided by the IBM

The contributions of following individuals from IBM are also appreciated:

Become a published author

xiv The Software Deployment Mystery - Solved!

We want our Redbooks to be as helpful as possible. Send us your comments

Chapter 1. Why focus on software

Customer example: GMR Corporation (GMR) is a growth company focused

In December 2002, GMR made an enterprise-wide purchase of software from

Software deployment is defined as the process of putting software and software

Copyright IBM Corp. 2003, 2004. All rights reserved. 1

1.1 What makes software deployment so difficult?

2 The Software Deployment Mystery - Solved!

1.2 Why have a Software Deployment Method?

Chapter 1. Why focus on software deployment? 3

Your representatives on the SDT are:

The IBM representatives on the SDT are:

The partner representatives on the SDT are:

1.4 The Software Deployment Method

4 The Software Deployment Mystery - Solved!

Step 3: Step 4: Step 10: Step 11:

Prepare Refine and Promote Deploy

1.4.1 Phase 1: Prepare for deployment

Chapter 1. Why focus on software deployment? 5

1.4.2 Phase 2: Refine and promote the plan

6 The Software Deployment Mystery - Solved!

1.4.3 Phase 3: Deploy software

1.4.4 Software deployment method: A continuous process

Chapter 1. Why focus on software deployment? 7

If the software identified in Step 10 requires an acquisition, then Step 11 jumps to

Software Deployment Method Software Deployment

Step 3: Develop High Step 2: Review Critical