SW Deployment best practices

ibm.com/redbooks
The Software Deployment
Mystery - Solvedd
A Customer Guide
Sandor Hasznos
Carolyn Hungate
Calvin Lawrence
Fernando Zuliani
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
Front cover
Bill Bierds
Jeremy Gibson
David Backman
Mike Ransom
Reid Byers
Charles P. Brown

The Software Deployment Mystery - Solved
A Customer Guide
August 2004
International Technical Support Organization
SG24-6070-02

© 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.
Third Edition (August 2004)
This edition applies to the IBM Software Group Software Deployment Method.
Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.

© Copyright IBM Corp. 2003, 2004. All rights reserved. iii
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 . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Why have a Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 The Software Deployment Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 The Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Phase 0: Prepare for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Phase 1: Refine and promote the plan . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Phase 2: Deploy software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.4 Software deployment method: A continuous process. . . . . . . . . . . . . 8
1.5 Software deployment best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 The readiness plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Solution Assurance Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Software solution work products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 Software deployment: A two-way street . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 2. Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Internal team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Enterprise Business Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Stakeholders, sponsors, and project leads . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Global Project Lead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Team IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 IBM Client Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 IBM Client Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 IBM Client Representative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 IBM Client IT Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 IBM Software Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 IBM Software Sales Representative (SSR). . . . . . . . . . . . . . . . . . . . 20
2.4.2 IBM Specialty Software Sales Representative (SSSR). . . . . . . . . . . 20
2.4.3 IBM Software IT Architect (SWITA). . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.4 IBM Software IT Specialist (ITS). . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iv The Software Deployment Mystery - Solved - A Customer Guide
Chapter 3. Software deployment best practices . . . . . . . . . . . . . . . . . . . . 23
3.1 Identify an Enterprise Business Sponsor and stakeholders . . . . . . . . . . . 25
3.2 Centralize software fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Implement a license management tool and process . . . . . . . . . . . . . . . . . 27
3.4 Hire deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Determine your deployment readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6 Commit to self-sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Define a time-to-value and ROI strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8 Communicate and market the vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Software deployment workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 4. Value realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Value statement and value timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 The buying decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Return on investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1 Hard (tangible) ROI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 Soft (intangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.3 Realizing value with hard and soft ROI. . . . . . . . . . . . . . . . . . . . . . . 37
4.3.4 ROI must support the business strategy. . . . . . . . . . . . . . . . . . . . . . 37
4.3.5 An approach to analyzing ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.6 When business goals are met, everyone wins . . . . . . . . . . . . . . . . . 38
4.3.7 Example ROI: Current value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 5. Software deployment Phase 0: Prepare for deployment . . . . 41
5.1 Step 0: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . 42
5.1.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.2 Inputs, tasks, and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Step 1: Review the deployment documentation . . . . . . . . . . . . . . . . . . . . 44
5.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.4 Documentation review tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Step 2: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 47
5.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Step 3: Establish the deployment partnership. . . . . . . . . . . . . . . . . . . . . . 49
5.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Chapter 6. Software deployment Phase 1: Refine and promote plan. . . . 51
6.1 Step 4: Refine the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Contents v
6.1.2 Inputs, tasks and outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Step 5: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3 Step 6: Conduct the initial deployment kickoff meeting. . . . . . . . . . . . . . . 56
6.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 7. Software deployment Phase 2: Deploy software . . . . . . . . . . . 59
7.1 Step 7: Achieve the quick deployment wins . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2 Step 8: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2.3 Benefit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3 Step 9: Identify new business needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.4 Step 10: Update the business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 8. Managing software deployment projects . . . . . . . . . . . . . . . . . 67
8.1 Project timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.2 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.3 Managing the success of your first project . . . . . . . . . . . . . . . . . . . . . . . . 70
8.3.1 Managing at the milestone level . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.3.2 Handling project management challenges . . . . . . . . . . . . . . . . . . . . 71
Chapter 9. Managing global software deployment projects . . . . . . . . . . . 73
9.1 How the coverage model works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.2 Global deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.2.1 Global level activities (primary, full-time coverage). . . . . . . . . . . . . . 77
9.2.2 Local sites (secondary, part-time coverage) . . . . . . . . . . . . . . . . . . . 78
9.2.3 Local sites (tertiary, on-demand coverage). . . . . . . . . . . . . . . . . . . . 78
9.3 More about the global deployment activities . . . . . . . . . . . . . . . . . . . . . . . 78

vi The Software Deployment Mystery - Solved - A Customer Guide
9.3.1 Identify the Enterprise Business Sponsor . . . . . . . . . . . . . . . . . . . . . 79
9.3.2 Obtain a list of software deployment locations . . . . . . . . . . . . . . . . . 79
9.3.3 Arrange full-time and part-time coverage . . . . . . . . . . . . . . . . . . . . . 79
9.3.4 Arrange on demand (tertiary) coverage . . . . . . . . . . . . . . . . . . . . . . 79
9.3.5 Conduct bi-weekly meetings with global deployment teams. . . . . . . 79
9.3.6 Checkpoint deployment satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.3.7 Provide regular progress reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.4 A global deployment coverage example . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Chapter 10. Software deployment resources: Support, education, tools 83
10.1 License management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
10.1.1 Taking control of software licenses . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.1.2 IBM Tivoli License Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.2 Communication tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.2.1 Instant messaging, Web conferencing, and team workplaces . . . . 87
10.2.2 Easy Access Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.3 Self-help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.3.1 Problem management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.3.2 License acquisition and entitlement with Passport Advantage . . . . 89
10.3.3 Software maintenance via Passport Advantage . . . . . . . . . . . . . . . 89
10.4 Premium support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.5 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.6 Deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Appendix A. Software solution work products. . . . . . . . . . . . . . . . . . . . . . 93
Work products used by SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Work product examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Architecture decisions document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Business context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Component model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Component flow model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Current IT environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Current business organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Envisioned goals and issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Current IT standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Mapping business initiatives to projects . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Mapping projects to proposed products and solutions . . . . . . . . . . . . . . . 117
Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Project description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
System context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Systems context diagrams for an integration architecture . . . . . . . . . . . . 123

Contents vii
Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Viability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Appendix B. Software deployment checklist . . . . . . . . . . . . . . . . . . . . . . 129
Software deployment steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Phase 0: Prepare for deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Step 0: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . 130
Step 1: Review the contract content and critical deployment documents . 131
Step 2: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 132
Step 3: Establish a deployment partnership . . . . . . . . . . . . . . . . . . . . . . . 133
Phase 1: Refine and promote the plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Step 4: Refine the high-level deployment plan . . . . . . . . . . . . . . . . . . . . . 133
Step 5: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Step 6: Conduct deployment kickoff meetings . . . . . . . . . . . . . . . . . . . . . 135
Phase 2: Deploy software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Step 7: Achieve quick deployment wins . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Step 8: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Step 9: Identify new business needs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Step 10: Update the business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Appendix C. Global software deployment checklist . . . . . . . . . . . . . . . . 139
Global-level activities executed by global deployment lead . . . . . . . . . . . . . . 140
Local sites (secondary ‘part-time’ coverage) . . . . . . . . . . . . . . . . . . . . . . . . . 142
Local sites (tertiary ‘on demand’ coverage) . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

viii The Software Deployment Mystery - Solved - A Customer Guide

© Copyright IBM Corp. 2003, 2004. All rights reserved. ix
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 Armand, 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.

x The Software Deployment Mystery - Solved - A Customer Guide
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:
®
Approach®
AIX®
APL2®
CICS/ESA®
CICS®
Database 2™
DB2 Universal Database™
DB2®
GDDM®
ImagePlus®
Informix®
IBM®
ibm.com®
IMS™
LearningSpace®
Lotus®
MQSeries®
MVS™
OS/2®
OS/390®
Passport Advantage®
Rational Unified Process®
Rational®
Redbooks (logo) ™
Redbooks™
RS/6000®
RUP®
S/390®
SmartSuite®
SP1®
Tivoli®
TME®
VisualAge®
WebSphere®
zSeries®
1-2-3®
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.

© Copyright IBM Corp. 2003, 2004. All rights reserved. xi
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 15, describes in detail the SDT and the concept of
partnership.
The best practices, presented in Chapter 3, “Software deployment best
practices” on page 23, 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 33. 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.

xii The Software Deployment Mystery - Solved - A Customer Guide
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 67, provides hints
and tips for managing large-scale deployment projects. Chapter 9, “Managing
global software deployment projects” on page 73, helps you manage deployment
on a global scale. And Chapter 10, “Software deployment resources: Support,
education, tools” on page 83, 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.
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 - Program Executive, Customer Success Strategies
Jeremy Gibson, Program Manager, Customer Success Strategies
David Backman, Program Executive, Software IT Architect Community
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.

Preface xiii
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 IT 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

xiv The Software Deployment Mystery - Solved - A Customer Guide
Jess Knowles, Lotus® Services Sales Representative
Kathleen O’Leary
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
Julie Czubik
Techincal Editor, International Technical Support Organization,
Poughkeepsie Center
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

Preface xv
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

xvi The Software Deployment Mystery - Solved - A Customer Guide

© Copyright IBM Corp. 2003, 2004. All rights reserved. 1
Chapter 1. Why focus on software
deployment
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
1
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).

2 The Software Deployment Mystery - Solved - A Customer Guide
taking steps that are necessary to achieve business value. Consider these
examples:
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.

Chapter 1. Why focus on software deployment 3
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
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
Note: As of the printing of this redbook, IBM Software Group has twelve
specialty areas that span the five IBM SWG brands. The brands are Data
Management, Lotus, Rational®, Tivoli®, and WebSphere®. The specialty
areas are Automation, Business Integration, Business Intelligence, Content
Management, Development Tools, Document Management, Linux, Pervasive,
Portals/Dynamic Workplace, Security, and Storage.

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.
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 Sales Representative (SSR)
Specialist Software Sales Representative (SSSR)
Software IT Architect (SWITA)
Software IT Specialists
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 15.
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 0: Prepare for deployment.
Phase 1: Refine and promote the plan.
Phase 2: Deploy software.
Figure 1-1 Overview of the Software Deployment Method
1.4.1 Phase 0: 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 0. 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 0:
Create
Software
Deployment
Team
Step 2:
Develop
High-Level
Deployment
Plan
Step 3:
Establish
Deployment
Partnership
Step 1:
Review
Documents
Phase 1
Step 4:
Refine
Deployment
Plan
Step 6:
Conduct
Deployment
Kickoff
Step 7:
Achieve
Quick-wins
Step 9:
Identify New
Business
Needs
Step 10:
Update
Business
Plan
Phase 2Phase 0
Prepare Refine and Promote Deploy
Step 5:
Finalize
Deployment
Plan
Step 8:
Execute
Deployment
Plans

Step 1. 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 2. 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 3. 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 1: 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 4. 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 1 and 2 (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 5. 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 3 and agrees on project controls. Also,
during this step, you and IBM should discuss the plans for one or more
deployment kickoff meetings.
Step 6. 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 2: 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 7. 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 8. 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 9. Identify new business needs: Due to the dynamic nature of business,
your business needs that were not known or identified during Phases 0 and 1
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 0 and follow the
roadmap for its planning and implementation.
Step 10. 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 9. 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 0 through 3
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 6 through 10 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
10. If this software is already purchased, the process continues within the mill
back to Step 6 (kickoff and communication). This, in effect, increases the size of
the mill because more deployment activity is underway.
If the software identified in Step 9 requires an acquisition, then Step 10 jumps to
Step 1 (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
1 and 2). The assumption is that you can skip Step 0 because the Software
Deployment Team is already established. Step 3 leads to the required
acquisition, and when the new software is fed into the deployment mill, the size
of the mill increases.

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.
Software Deployment Method Software Deployment
Method Steps
Software
Deployment
Mill
Step 0: Create SW
Deployment Team
Step 1: Review Contract
Content & Critical
Deployment Documents
Step 2: Develop High
Level Deployment Plan
Step 3: Establish
Deployment
Partnership with
Vendor
Software
Acquisition
New Software
Requirement
Defined
Step 6: Kick-off
& Communication
Step 4&5:
Refine & Finalize
High Level
Deployment Plan
Step 7: Execute Quick
Deployment Wins
Step 8: Execute
Deployment
Projects
Step 9: Identify
New Business
Needs
Step 10: Purchase
Software & Update
Business Plan

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.
For assistance in understanding the best practices and applying them to your
organization, IBM can host a software deployment workshop. This workshop
includes the Enterprise Business Sponsor, the Software Deployment Team, and
Return on Investment TimelineReturn on Investment Timeline
TimeTime
ROIROI
Step 11: Purchase
Software & Update
Business Plan
Software
Deployed
Software
Deployed
Software
Deployed

key stakeholders from your organization. It is designed to both deliver the
benefits of the best practices and to discuss any gaps that need to be addressed
You can find more information about these best practices in Chapter 3, “Software
deployment best practices” on page 23. For more information about value
realization, time-to-value, and ROI, see Chapter 4, “Value realization” on
page 33.
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 IT 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 93. 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 Sales Representative, your IBM Software IT
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. GMR’s 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 SSR and SWITA.
These two groups, when combined, created the SDT (SDM Phase 0, Step 0).
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 GMR’s business objectives. The leader of GMR’s 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, GMR’s EA Deployment
Team devised an event entitled EA Land (SDM Phase 1, Step 6). 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 GMR’s deployment process. Over 1,200 GMR IT professionals
were invited to this event.
Because of GMR’s 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.

Chapter 2. Roles and responsibilities
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
“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

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 company’s 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

Chapter 2. Roles and responsibilities 17
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 GPL’s role, refer to Chapter 9, “Managing global
software deployment projects” on page 73.
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.

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.
Figure 2-1 provides an overview of the various IBM roles.
Figure 2-1 IBM client team - Software-focused view
2.3 IBM Client Team
The IBM client team consists of the following members:
IBM Client Executive
IBM Client Representative
IBM Client IT Architect
IBM Client Team – Software Focused View
Automation,
Security,
Storage
Portals,
Dynamic
Workplace
Business Intel,
Content Mgmt/
Doc. Mgmt
Business
Integration,
Pervasive
Development
Tool
Software Sales Representative (SSR)
Software IT Architect (SWITA)
Managing Director (MD)
Client Representative/Client Manager
Client IT Architect (CITA)
Specialty SSR Specialty SSR Specialty SSRSpecialty SSRSpecialty SSR
IT Specialists
Services
Support
IT SpecialistsIT SpecialistsIT Specialists IT Specialists
ServicesServicesServicesServices
SupportSupportSupportSupport
Server
Group
Global
Services
Software Group
Middleware Solution Areas*
Client Executive/Client Director
* Other solution areas that span SWG are: Linux and z-Series
DB2 Lotus Tivoli WebSphere RationalSWG Brands

2.3.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.3.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.3.3 IBM Client IT Architect
The Client IT Architect has a role similar to that of the Software IT 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.
2.4 IBM Software Team
The IBM Software Team consists of the following members:
Sales (non-technical):
– Software Sales Representative (SSR): Cross-brand strategy and sales
– Specialist Software Sales Representative (SSSR): Single brand sales and
tactical sales support
Technical Sales:
– Software IT Architect (SWITA): Cross-specialty/cross-brand strategy and
deployment
– Software IT Specialist (ITS): Single brand sales and tactical support

2.4.1 IBM Software Sales Representative (SSR)
SSRs formulate strategies that link IBM Software with your business strategies.
The SSR 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 SSR provides a single “sales face” to you across all of the IBM Software
brands.
2.4.2 IBM Specialty Software Sales Representative (SSSR)
The SSSR focuses on one or more IBM software specialties and works with the
SSRs, ITSs, and SWITAs in doing so. SSSRs have knowledge of IBM strategies
and directions for the specialties they represent. They are responsible for
positively impacting your satisfaction with the offerings within their respective
specialties.
2.4.3 IBM Software IT Architect (SWITA)
Using the entire IBM Software portfolio as a palette, the Software IT 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 SWITA designs a solution that integrates into your IT
environment and leverages the best technology available from IBM. The SWITA
has an overall responsibility for the technical solutions delivered to you and helps
ensure those solutions are successfully deployed.
The SWITA’s 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.
While the IBM Software IT 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 (SDA) 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 Sales Representative.
The SDA’s 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.4.4 IBM Software IT Specialist (ITS)
Employing a technical understanding of the capabilities of one or more specialty
areas, the Software IT 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 IT Specialist are to:
Build and maintain a technical understanding of product capabilities.
Understand your technical infrastructure and use this knowledge to identify
potential solutions.
Understand how IBM’s software compares to our competition in their
specialty area or areas.
Ensure you are technically prepared for a successful implementation.
Manage the Solution Assurance Review process.

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

Table 3-1 Summary of software deployment best practices
Software deployment
best practice
Benefit
Identify an Enterprise
Business Sponsor
Aligns business goals with Information Technology (IT) initiatives
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
fulfillment
Ensures that each person that has the desire to deploy software has the
means of getting it efficiently and effectively
Provides a control point from which software deployment progress can me
monitored
Implement a license
management tool
Allows you to verify your compliance with the terms and conditions of your
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
services
Ensures that an expert is engaged to help plan and execute the
deployment
Allows you to navigate the normal pitfalls of solution development by
leveraging experienced consultants
Dramatically increases the chances for deployment success
Determine deployment
readiness
Eliminates many of the unknowns associated with solution design and
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
self-sufficiency
Ensures that, over time, the reliance on IBM services and support is
minimized
Reduces long term cost of ownership by building skilled teams, strong
processes, and robust environments
Define a time-to-value
and ROI strategy
Provides common goals for the deployment teams to work toward
Builds confidence with the achievement of quick wins
Defines a schedule for achieving long term goals
Provides a mechanism to gain community buy in

Chapter 3. Software deployment best practices 25
3.1 Identify an Enterprise Business Sponsor and
stakeholders
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
Communicate and
Market the Vision
Increases the investment understanding by communicating the linkage
between the strategic purchase and business goals
Accelerates the rate of return and increases solution demand through
advertised successes
Software deployment
best practice
Benefit
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.

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.
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 comment: “The recommendation that one owner be defined for
the successful deployment of software has been extremely beneficial.”
– GMR Corporation’s (GMR’s) VP of Technical Services

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

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 IT Architects (SWITAs) 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 resources: Support, education, tools”
on page 83, 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.
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
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.

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 IT Architect, IBM Technical Sales Specialist, or both 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.
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.
Customer example: The Software Sales Representative 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.

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 33, for more information about
this topic.
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
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.

about the kickoff meeting, see 6.3, “Step 6: Conduct the initial deployment kickoff
meeting” on page 56.
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.
3.9 Software deployment workshop
IBM SWG has created a Software Deployment Workshop to compliment this
redbook. It has been designed to help you build the internal skills and processes
necessary to realize success from your IBM software purchases. This guided
tour is presented to you and your stakeholders, and reviews the eight best
practices that are enablers to your success. If you seek answers to any of the
following questions, you could benefit from the workshop:
What business and/or IT goals are you are hoping to accomplish through your
software purchase?
How will success and value be measured?
What are the timelines and major milestone periods on the road to success?
What deployment projects can be accomplished in the next 6 to 9 months to
produce some quick deployment wins and gain confidence?
Customer example: To facilitate this communication and marketing effort,
GMR’s EA Deployment Team devised an event entitled “EA Land” (SDM
Phase 1, Step 6). 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 GMR’s 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.

Is there a person or persons, across lines of business, responsible for
realizing full value from the purchased software?
Who will deploy software and handle knowledge transfer to your team?
What personnel skill and experience gaps do you think may impact
deployment progress?
How is education delivered today (classroom, Web, etc.)?
What internal matters (politics, factions, geographies, languages, cultures,
etc.) exist that may impact deployment mindshare, buy-in, and progress?
Across all lines of business, and within departments, how will the vision be
articulated, goals be communicated, success be advertised, and potential
challenges be averted?
At the workshop we will work with you to set the right expectations, provide
pre-workshop collateral, and offer follow-up suggestions to keep the momentum
of deployment high. The workshop will:
Introduce the Software Deployment Method.
Determine what it means to plan for success.
Identify quick deployment wins that will build confidence and momentum.
Introduce Team IBM and review our core responsibilities.
Step through deployment best practices and the readiness plan, and identify
any gaps.
Identify action plans to address gaps identified.
Define value and determine how and when it will be realized.
Sketch and discuss a high-level deployment plan that will achieve business
goals.
Schedule a follow-up meeting to checkpoint progress.
To arrange for a Software Deployment Workshop for your team, contact your
Software Sales Representative from IBM.

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

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.
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
10/15/2003
Prototype
1/15/2004
User Testing
3/22/2004
HQ Rollout
6/15/2004
US Rollout
9/13/2004
Europe
Rollout
12/15/2004
Asia
Rollout
7/15/2003

Chapter 4. Value realization 35
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 don’t 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,

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 39 and Figure 4-3 on page 40 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 6 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
Let’s 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 company’s 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
company’s 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.
Figure 4-2 Software deployment value and status by product
Software Agreement Value Statement
Product
Total #
Purchased
Licenses
Deployed
Licenses
Allocated
Software
Gap
License
Value
Deployed /
Allocated
Value
Software
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-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.
Figure 4-3 Software deployment value and status by product
Software Agreement Value Statement
Project
Total #
Proposed
Licenses
Deployed
Licenses
Remaining
License
Value
Deployed
Value
Project
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

Chapter 5. Software deployment
Phase 0: Prepare for
deployment
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 0: Create the Software Deployment Team (SDT).
Step 1: Review the deployment documentation.
Step 2: Develop a high-level deployment plan.
Step 3: Establish a deployment partnership with IBM.
5
“The will to win is nothing without the will to prepare to win.” – Vince Lombardi,
legendary football coach for the Green Bay Packers

Figure 5-1 Phase 0: Prepare for deployment
5.1 Step 0: 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 Sales Representative (SSR) 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:
Business Sponsor
Project leads
IT architects
Technical Specialists
Services representatives
Partner representatives (if involved)
Step 0:
Create
Software
Deployment
Team
Step 2:
Develop
High-Level
Deployment
Plan
Step 3:
Establish
Deployment
Partnership
Step 1:
Review
Documents
Phase 1 Phase 2Phase 0
Prepare
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.

Chapter 5. Software deployment Phase 0: Prepare for deployment 43
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 SSR, 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 0: Create the SDT
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.
Inputs Tasks Outputs
Need or requirement to form
the team
Create a Software
Deployment Team that
includes the following
representatives:
– Enterprise Business
Sponsor
– Project Managers
– Internal IT architects
– IBM Software Sales
Representative
– IBM Software Technical
Specialists
– IBM Software
Deployment Architect
– IBM Software IT Architect
– IBM Services
representative
Software Deployment Team
established.
Team members understand
their roles and
responsibilities and are
committed to the team’s
purpose and goals.

5.2 Step 1: 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 don’t understand, they should ask the team
negotiating the contract.
The owners are the EBS, SSR, and the IBM Software IT Architect (SWITA).
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 1: Review the deployment documentation
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
Draft contract
Solution concept
Requirements and use cases
Business context diagram
and description
System context diagram
Conceptual architecture
Architectural decision
document (ADD)
Initial viability assessment
Organization charts
IT standards
Current IT environment
Project descriptions
Discuss buying decision
Ensure that the content and
terms and conditions of the
contracts are thoroughly
understood
Study 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
List of open items for
contract negotiation
Updated viability assessment
Draft goals and milestones
document
High-level mapping of
business initiatives to
projects
Draft mapping of projects to
products
Initial software utilization
report

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 didn’t 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 73.
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 2: 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 IT
Architect. The participants include the EBS, SSR, 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 2: Develop a high-level plan
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
Viability assessment
Architectural decision
document
Solution architecture
Component model
Internal interface
descriptions
Goals and milestones
Software deployment best
practices
High-level mapping of
business initiatives to
projects
Draft mapping of projects to
products
Initial license utilization
report
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
Updated goals and
milestones
High-level, phased
deployment plan
Detailed mapping of
products to projects to
business initiatives
Services requirements
Environment and
infrastructure requirements
and projects
Updated license utilization
report

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 3: 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 15. 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 team’s readiness
plan or gaps from the software deployment best practices (see Chapter 3,
“Software deployment best practices” on page 23, for more information). Both the
readiness plan and best practices are designed to help you be successful with
your deployments.
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.
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 CIO’s 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.

Table 5-4 shows the inputs, tasks, and outputs for establishing the deployment
partnership.
Table 5-4 Inputs, tasks, and outputs for SDM Step 3: Establish the deployment partnership
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.
Updated goals and
milestones
High-level phased
deployment plan
Detailed mapping of products
to projects to business
initiatives
Services requirements
Skills gap analysis
Environment and
infrastructure projects
Confirm buying decision and
vision
Identify quick deployment
wins
Define deployment
milestones and
measurements
Review skills and projects
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
Finalized goals and
milestones
Quick deployment win plan
Validated high-level
deployment plan
Validated mapping of
products to projects to
business initiatives
Validated gap analysis
Validated environment or
infrastructure projects
Roadblock action plan
Scheduled kickoff meeting

Phase 1: Refine and
promote 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 4: Refine the deployment plan.
Step 5: Finalize the deployment plan.
Step 6: Conduct the initial deployment kickoff meeting.
6

Figure 6-1 Phase 1: Refine and promote the plan
6.1 Step 4: 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
Phase 0 Phase 1
Step 4:
Refine
Deployment
Plan
Step 6:
Conduct
Deployment
Kickoff
Phase 2
Refine and Promote
Step 5:
Finalize
Deployment
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 GMR’s 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.

Chapter 6. Software deployment Phase 1: Refine and promote plan 53
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 IBM Software IT Architect (SWITA).
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 4: Refine the deployment plan
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 5: 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.
Final contracts
Architectural overview
Component descriptions
Interface descriptions
Business initiatives
Revisions to architectural
plans
High-level phased
deployment plan
Detailed mapping of products
to projects to business
initiatives
Quick deployment win plan
practices
Gap analysis
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
Create a draft of project
controls
Update the deployment and
quick deployment win plans
as needed
Refined physical deployment
plan
Refined physical architecture
Refined environmental and
and systems management
plan
Proposed project controls
Refined quick deployment
win plan

The owners include the Enterprise Business Sponsor and the IBM Software IT
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 5: Finalize the deployment plan
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.
Refined physical architecture
Refined deployment plan,
deployment timeline, and
systems management plan
Proposed project controls
Refined quick deployment
win plan
practices
Review and finalize the
deployment plan
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
Final physical architecture
Final deployment plan
Final deployment timeline
Final operational model
Final systems management
plan
Final project controls
Final quick deployment win
plan
Final goals and milestones
practices understood and
agreed upon

6.3 Step 6: 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 15, and the software deployment best practices described in Chapter 3,
“Software deployment best practices” on page 23.
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 Sales Representative (SSR), and the
SDA or SWITA. 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 6: Conduct initial deployment kickoff meeting
Final contracts
Architecture plans and
descriptions
Final high-level deployment
plan and timeline
IT vision
practices
Roles and responsibilities
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” products
Arrange for demonstrations
of key products if necessary
Synergy and enthusiasm for
the upcoming deployment
High-level understanding of
the contracts
Communicated vision and
business value
Understanding of roles and
responsibilities and the
software deployment best
practices

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

Phase 2: Deploy software
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 7: Achieve quick deployment wins.
Step 8: Execute the deployment plan.
7

Step 9: Identify new business needs.
Step 10: Update the business plan.
Figure 7-1 Phase 2: Deploy software
Phase 1
Step 7:
Achieve
Quick-wins
Step 9:
Identify New
Business
Needs
Step 10:
Update
Business
Plan
Phase 2Phase 0
Deploy
Step 8:
Execute
Deployment
Plans
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.

Chapter 7. Software deployment Phase 2: Deploy software 61
7.1 Step 7: 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 IT Architect (SWITA).
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 7: Achieve quick deployment wins
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.
List of projects and owners
Project plans for quick
deployment wins
IBM readiness plan
practices
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 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
Quick deployment win
projects competed
Initial business value realized
Internal reference groups

7.2 Step 8: 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 67, 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 SWITA. 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 8: Execute the deployment plan
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 9: 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
Final deployment and
physical architectures
practices
IBM readiness plan
Final environment and
Final deployment plan
Final systems management
plan
Final project controls
Final goals and milestones
Advertise quick deployment
wins with meetings or open
house events.
Assign deployment project
managers
Educate additional users on
IBM 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
Deployment milestone status
reports
License usage reports
Value realization status
reports
Competed projects
Deployment of software and
the associated business
value achieved

which you already own. This software that needs project identification is referred
to as the “software gap.”
The owners include the EBS, the Software Sales Representative (SSR), and the
SWITA. 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 9: Identify new business needs
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 10: 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 0: Prepare for deployment” on page 41, and repeating the
cycle for successful deployments.
Deployment plan
Gap analysis
New business requirements
Revise the deployment plan
to include the new
requirements.
Seek out new demand.
Manage these new projects
as done in Step 8.
Software “gap” is reduced or
eliminated
New projects are identified
Value realized is increased

The owners include the EBS, the SSR, and the SWITA. The participants include
the extended IBM Software Technical team.
Table 7-4 Inputs, tasks, and outputs for Step 10 of SDM
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.
Projects identified in Step 9
that were not rolled into the
current deployment plan
Software gap analysis
New business requirements
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 0, Step 1.
Refreshed strategy to meet
the new business needs

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 33, 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.
8

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 15, 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.

Chapter 8. Managing software deployment projects 69
8.1 Project timing
From the SDT’s 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 project’s 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 SDT’s 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 7: Achieve the quick deployment wins” on
page 61.
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 IT 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 Sales Representative (SSR) 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.”
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! It’s terrific
that we’re 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 SDT’s
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.

Chapter 8. Managing software deployment projects 71
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 don’t need to be the ones doing it. We’re 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 93, may be helpful to
project leaders.

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 23, self-sufficiency
9

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.

Chapter 9. Managing global software deployment projects 75
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 Sales Representative, 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
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
Location Company ABC Company XYZ
Americas
(New York)
John Williams
Tertiary
Americas
(Other NA)
Dawn Dish
Tertiary
Latin America Ricardo Ferano
Secondary
Ricardo Ferano
Secondary
EMEA John Parker
Primary – lead city
Ted Fonderland
Primary – lead city
Tokyo
Singpore/India Choong Pong
Tertiary
China (Hong Kong S.A.R.) Erris Pow
Secondary
Korea Sanghoon Hark
Tertiary
Australia Susan Potville
Tertiary

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 leader’s 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 33.
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.

9.3.1 Identify the Enterprise Business Sponsor
One of the deployment best practices (see Chapter 3, “Software deployment best
practices” on page 23) 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.
9.3.2 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.
9.3.3 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.
9.3.4 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.
9.3.5 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 can’t be passive. They must be
proactive.

9.3.6 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 GPL’s 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.
9.3.7 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.

Figure 9-1 Global deployment coverage for Nestlé Corporation
GCC (primary)
Vevey, Switzerland
GC AMS (secondary)
Phoenix, Arizona
GC AOA (secondary)
Sydney, Australia
GC EUR (secondary)
Frankfurt, Germany
GC HQ, CSC (secondary)
Bussigny, Switzerland
Markets (tertiary)
any country

resources: Support,
education, tools
Chapter 3, “Software deployment best practices” on page 23, 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,
10

contact your IBM Software Sales Representative (SSR) 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 today’s 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
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 company’s 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 Premium support
All customers who pay for support and maintenance receive access to all
Web-based and telephone support 24 hours a day 7 days a week. Please refer to
your contract for specifics associated with the standard support offering from
IBM. IBM Software Group also offers a level of support that goes beyond what

most vendors offer. IBM calls the offering Premium Support. Generally speaking,
Premium Support provides you with an on-call support representative to assist
with your specific support needs. It is recommended that you speak with your
Software Sales Representative or Technical Sale Representative if you are
interested in this kind of support.
10.5 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.6 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.

Appendix A. Software solution work
products
One of the mantras at IBM is “don’t 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.
A

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 architect’s 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.

Appendix A. Software solution work products 95
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 customer’s 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).
Customer’s 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 company’s 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 Team’s (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.

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 project’s
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.
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.
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 33. 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
decision
Use a transformational hub architecture to provide more economical systems
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.

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.
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.
Subject Integration architecture

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.
Figure A-1 Example architecture overview
content
management
system
workflow
server
legacy
applications
new
packaged
applications
application
server
(new apps)
external
networks
external
networks
gateway
Citrix
apps
portal
integration
hub
EIP

Business context diagram
This e-business solution deals with several complex systems. They include
ShopCo’s 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 ShopCo’s
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.
Figure A-2 Example business context diagram
POSPOS
Multiple
Store
Support
Direct
Store
Support
HRHR
Distribution
(C&S etc)
Distribution
Systems
Financials
(Lawson etc)
Financial
Systems
AdvertisingAdvertising
Merchandizing
Price Management
Merchandizing
Price Management
Store
Management
Store
Management
Third PartyThird Party
Executive
Systems
Executive
Systems
CustomerCustomer
Reporting
Database
Reporting
Database
purchase
debit/credit, authorization
coupon control
price, promos, etc
ordering
store
activity,
orders
delivery info
labor,
benefits
personnel info
sales info
cash management

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 partner’s system at another location.
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”.
Business Partner
Browser
HTTP
Service
Servlet
Business
Object
Message
Queue
Routing/
Transform
Hub
Adaptor
Message
Queue
Queue-
Enabled
Application
Packaged
Application
Web
Service
HTTP
Service
Partner
Web
Service
Partner
Systems
HTTP
Service

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 partner’s 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.
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
API call
Queued return
passed
from routing
Queued return
data to calling
object
Return data
pointer to servletReturn JSP as
HTML
Fill in JSP with
data
API response
Queued request
to Adaptor
Queued
request passed
to routing
Request
customer info
Activate
servlet
URL request
Browser
HTTP
Server Servlet
Business
Object
R&T
Engine
Adaptor Packaged
Application

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
ShopCo’s 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.
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 user’s 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)
Store
System 390
Merchandising
Catalog
BN GT
HR
Financial
BA BT
HH FT
Returns
Distribution
GF NT
Grocery
Dry Goods
Item Management
Pharmacy
Bakery
Toys
Advertising
Advertising
Dept
POS
POS (4690)
Supermarket
Pharmacy
Toys
Store Server
(RS 6000)
Store
Management
HR, CGO, etc
RS 6000
Financial
Peterson
-
Marketz Purch
Warehouse &
Logistics
DRS
Distribution
Center
Windows
Notes – Mail,
Priceline Promotion
Access
xBase/App Dev, etc
Web
Internet structure Intranet Domino

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 user’s desktop. However, it ran sufficiently well on the Citrix server, from
which its image can be shown, page by page, on the desktop browser.
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 ShopCo’s 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.
SQL Server
Desktop
Browser
Web
Server
Nfuse
Server
Citrix Server
Browser
Brio
Plug-in
ASP
App Server
IIS
BRIO
EIP Server
IIS
WebSphere
App
Server
EIP
DB2
Image
Plus
Index
Image
Plus
Data
Visual
Basic
report
data
Citrix
Plug-in

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-don’t-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
Jane Smythe
President
Underwriting
Michael Ho
Claims
Thomas Jones
CFO
Mark Ellerby
CIO
James King
COO
Betty Plonk
Branch Ops
Jeremy Newl
Managed Care
Allen Hobbes
Bill Howard
Judy Wells
Data Mangmt
Peter McAng
Claims
Connel McFarland
Underwriting
Henry Lakey
Operations
Pi Zaharko
FNOL
Mary Martin
Changes
Web Apps
Datamart
GJS
CoA Prime
Notes/Web
Actuarial
Data Quality
End User
Client Systems
Support
Financial/Claims
Peter Vicot Ann Riley
Forms
Call Center
Quick Code
Image Team
Reporting
Workers' Comp
Comml Auto
POKI
Financial A/R
Premium Corp
Reporting
Appl. Architecture
Appl/Systems
Support
Rita Spannel Louis Jacaro Peg Henry
Lotus Notes
Admin
Networking
Services
Mail & Copy
Printing
Data Center
Prod. Control
Help Desk
Procurement
& MAC
Telecom
DBA

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 homeowner’s 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 it’s running (InsCo actually wrote a
program to check and see if it’s 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. Cenfra’s
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 don’t 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
productivity
Reduce training costs
Business initiative Customer’s name for
business initiative
Collaboration Distance Learning
Project name Customer’s name for
the project or initiative
Advanced collaboration Enterprise eLearning
Project description Brief description Enterprise-wide rollout
of collaboration tools
Training for merger,
agents, call center,
applications
Customer sponsor E = executive
P = project
(include contract
information)
E = Mary Smith P = John Doe
Project status Customer’s project
status
Plan Plan
Existing solution or
competition
None *Placeware,
*ASP Berbee
LearningSpace®
Annual cost of existing
solution or competition
Unknown ASP through Berbee
Approximately $4,000
per month + per user
access
Money in budget Yes or no and amount if
known
None Yes

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
Decision date 10/01/2002 08/09/2002
Deploy date 11/01/2002 10/01/2002
Comments Currently piloting 40
licenses of ST in the
Minneapolis location.
Looking at enterprise
rollout.
Stated corporate
evaluation in April/May
by Dave M’s team
Topic Key Goal #1 Goal #2
Topic Key Project #1 Project #2
Project name From business
initiatives sales aid
Advanced collaboration Enterprise eLearning
Proposed IBM product
or solution
Product name SameTime LearningSpace
Collaboration
IBM Software part
number
PA number D5CT2LL D5CPRLL
Function What does it do? Real time chat and
e-messages
Distance learning
Business value Value to customer Less phone tab, less
travel, faster response
training
Reduced travel and
tuition expense
Quantity 7000 7000
BAU unit price Normal PA discounted
price
$28.12 $41.64
MLC Or other non OTC if
applicable
Total revenue Will calculate qty x bau
rsvp
$201,000.00 $291,480
IBM Lead/Team
members
L = lead
M = member
(include contact info)
L = Steve W L = Tom B

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.
Comments Licenses of SameTime
in the Minneapolis
location. Looking at the
enterprise rollout.
Stated corp. evaluation
in April/May by Dave
M’s team.
Topic Key Project #1 Project #2

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.
Figure A-9 shows a simple system context diagram that indicates the position of
the new system within other existing or future 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.
Legacy
Systems
New
Packages
Intranet
& Internet
Systems
Branch
Systems
Business
Partner
Systems
New
Architecture
Datamarts

Figure A-10 Systems context diagrams example for an integration architecture
Shelf List
Distribution
Systems
Reclamation
EDI
Seasonal
Applications
Price
Check
EFT
Continuous
Replenishmt
Drop
Shipments
Direct
Delivery
End User
Computing
Direct
Store Support
Pharmacy
Store Order
Processing
Human
Resource s
Factor Toys
Store
Applications
Categories EDSCS
Category
Management
Time and
Attendance
Financial
Systems
Price
Book

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.
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).
Social
Worker
Social Work
Supervisor
Police
Dispatcher
Safe
Haven
Clerk
Judge
System
3-4, 5, 6-7
8
11
10
9
12-13

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.

Figure A-12 Programming use case example
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
Social
Worker
System
SW completes seach screen
System returns list
SW selects case
System returns form
SW completes form
System returns authoriztion
Social worker completes search screen
System returns list
Social worker selects case
System returns form
Social worker completes form
System returns authorization
Risk
Ref.
Risk description Probability
(H/M/L)
Impact
(H/M/L)
Contingency or mitigation Initiative
1 Point-to-point
connectivity for
applications will
become increasingly
expensive and rigid.
H H Adopt integration architecture to
avoid point-to-point
connections.

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.
2 Home-grown
messaging functions
will become
undependable and
expensive to maintain.
M-H H Use standard third-party
queuing mechanism.
3 Current Internet-client
model (using Citrix) will
become expensive and
unwieldy.
H M-H Provide a more standard and
efficient browser-client model.
4 Lack of end-to-end
security architecture
will result in excessive
exposure and
maintenance cost.
M M-H Provide end-to-end security for
integration architecture.
5 Security violation of the
system running in the
demilitarized zone
(DMZ).
M H Implement screened sub-net
architecture.
6 Support cost for
desktop will continue to
rise
H M Enforce existing desktop
standards. Standardize on thin
client intranet development.
Standardize reporting tools.
Provide desktop data backup.
Standardize printing strategy.
Risk
Ref.
Risk description Probability
(H/M/L)
Impact
(H/M/L)
Contingency or mitigation Initiative

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

Software deployment steps
Phase 0: Prepare for deployment
Step 0: Create the Software Deployment Team
Activity Owner(s) Date completed Notes
Step 0: Create the Software
Deployment Team
Step 1: Review the critical deployment
documents
Step 2: Develop a high-level
deployment plan
Step 3: Establish a deployment
partnership
Step 4: Refine the high-level
deployment plan
Step 5: Finalize the deployment plan
Step 6: Conduct deployment kickoff
meetings
Step 7: Achieve quick deployment
wins
Step 8: Execute the deployment plan
Step 9: Identify new business needs
Step 10: Update the business plan
Gather the Software Deployment
Team
Get commitment from each member
Communicate roles, responsibilities,
and expectations

Appendix B. Software deployment checklist 131
Step 1: 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

Step 2: 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 3: Establish a deployment partnership
Phase 1: Refine and promote the plan
Step 4: Refine the high-level deployment plan
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
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
Create a draft of project controls
Update the deployment and quick
deployment win plans as needed

Step 5: Finalize the deployment plan
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 6: 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

Phase 2: Deploy software
Step 7: 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

Step 8: Execute the deployment plan
Step 9: Identify new business needs
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 8

Step 10: Update the business plan
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 0, Step 1

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 leader’s 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.
C

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.

Appendix C. Global software deployment checklist 141
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.

Local sites (secondary ‘part-time’ coverage)
Local sites (tertiary ‘on demand’ 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.
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.

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

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 129, and Appendix C, “Global software
deployment checklist” on page 139.
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.
architectural decisions document (ADD) Lists
critical architecture decisions or choices made in the
design phase. It also describes the rationale for
making them.
architecture overview diagram Illustrates the
basic ideas of the proposed architecture. It is the
equivalent of the architect’s sketch. Depending on
the context, the diagram may range from basic to
more detailed. Related work products are the
system context diagram, component model, and
operations model, where additional detail is
conveyed. Typically, the diagram evolves with a
greater level of detail as the architecture is better
understood. The diagram serves as a means of
confirming architectural understanding between IBM
and the customer.
backup and recovery plan Identifies the
necessity for backup and recovery and how backup
and recovery impacts the customer’s internal
service-level agreements. Customers should
identify who is responsible for backup and recovery
and document the procedures in their support plan.
best practices Actions recommended by
experienced software deployment personnel. When
followed through the life of the Enterprise
Agreement (EA) and the Software Deployment
Method (SDM), best practices help to ensure
deployment success.
business context diagram and
description 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 is key
to developing a system that is properly situated in
the client’s business.
business goals Brief objectives of the company
that must be achieved to enable the fulfillment of the
vision.
CITA See Client IT Architect.
Client Executive Builds a long-term business
relationship with the client. Identifies IBM
opportunities and develops solution strategies that
meet the client’s business needs. They maintain
customer business relationships at the senior level
with key decision makers and influencers. The Client
Executive is accountable for total client satisfaction,
IBM market share, revenue, and profit earned from
the client. They partner with the Software Sales
Representative (SSR) to drive software sales and
partners with sales and technical specialists in
hardware and services to drive respective sales.
Client IT Architect (CITA) A role similar to that of
the Software IT Architect (SWITA) and Software
Deployment Architect (SDA). The CITA has IT
responsibility for the entire IBM relationship with the
customer, including hardware, software, and
services. The relationship among the CITA and the
software technical team is critical.
Client Representative Builds a long-term
business relationship with the client by providing
total solutions to a client’s business needs. The
Client Representative identifies and qualifies IBM
opportunities, engages the appropriate IBM
resources, gains client commitment to solutions
when appropriate, and ensures overall client
satisfaction. The representative manages IBM
opportunities while guiding the development of the
solution and support strategies. They partner with
the SSR to drive software sales and partners with
sales and technical specialists in hardware and
services to drive respective sales.

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

Glossary 147
Enterprise Business Sponsor Represents the
customer and takes ownership for the software
deployment throughout the enterprise. This sponsor
commits to:
Develop the internal vision for promoting the
maximum utilization of purchased licenses,
based on the benefit derived.
Work with 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 for the entire
term of the Enterprise Agreement.
Assist with marketing and demand generation of
the software portfolio within the organization.
Establish deployment quick-win initiatives to
establish project credibility as early as possible.
envisioned goals and issues (project ideas that
emerged early in the sales process) A work
product that documents the client’s mission
statement, vision statement, to-be business goals,
and critical success factors.
execution environment plan Recommends an
appropriate environment and level of discipline for
development, test, and change management during
deployment.
gap analysis A listing of products that is burned by
defined projects and products that have yet to be
linked to planned projects (the latter is called
potential shelfware). The unlinked products
constitute the gap. Gap analysis is also referred to
as software demand gap analysis.
global software deployment The deployment of
IBM licensed software for an account that has
deployment locations that span two or more
geographies.
IT standards A work product that documents all
known IT standards that the architecture must
accommodate.
ITS See Software IT Specialist.
license management Involves identifying which
licenses are installed, which ones are active, and
how many licenses are forecasted to be deployed.
To assist in this area, Tivoli has a tool called IBM
Tivoli License Manager that became available in
November 2002.
list of projects and owners A work product that
lists all the potential projects, what brands are
involved, the deployment sites, the customer
owners, and their contact information. This helps to
ensure that, when deployment begins, information is
available to help drive deployment activity.
Managing Director Has overall responsibility for
the global relationship within the account, including
responsibility for profitability.
mapping business initiatives to deployment
projects to products A work product that acts as
a map that connects products with projects. It links
each project to the business goals or initiatives that
drove the original sale.
migration plan The act of customers moving their
current versions of software or hardware to newer
versions (or to new platforms). Migrations can be
complicated and may create cost and time overruns
that can cause serious problems. Migration plans
describe the activities and timetables for doing the
migration. Some of those activities include customer
code regression testing, execution environment
tests, migration automation scripting, and back out
planning.
mission statements The operational, ethical, and
financial guidelines of companies (or functional
areas). They articulate the goals, dreams, behavior,
culture and strategies of companies. This should be
information that is already created by the client.
Sometimes called value statements, credos, or
principles.
operational model A work product that specifies
the hardware that the desired architecture requires.

project descriptions Communicates the project
goals to everyone who needs to know. Provides
answers to the question, “What are we doing on this
project and why?” The document provides brief
descriptions of the business problems that the
deployed projects will solve.
quick deployment wins Projects selected for their
high-probability of success, their importance to the
customer, and their ability to complete in a relatively
short period of time. The Software Deployment
Team (SDT) wants the customer to complete these
as early as possible in deployment because they
generate momentum, enthusiasm, support, and
positive first impressions.
quick deployment wins plan Identifies projects
selected for their high-probability of success, their
importance to the customer, and their ability to
complete in a relatively short period of time. The plan
also contains the milestones and metrics associated
with the projects.
Rational Unified Process® (RUP®) A
Web-enabled set of software engineering processes
that provide you with guidance to streamline your
team’s development activities.
readiness plan Fosters proactive communications
between IBM and the customer and promotes
smooth deployment. It is a set of processes and
work products designed to:
Level set customer’s expectations.
Assign responsibilities and ownership.
Determine the customer’s implementation
readiness.
Plan transition from pre-sales to post-sales
activities.
Assure that customer’s use cases
(requirements) are met.
Identify risks for mitigation and escalation.
return on investment (ROI) The value that a
customer receives on their investment in software,
hardware, and services. Hard ROI can be quantified
with dollars or numbers and is associated with
headcount savings, system count reduction, server
consolidation, and department closures. Soft ROI is
more difficult to project and quantify, and involves
perceptions and satisfaction.
ROI See return on investment.
rollout plan and schedule Includes all the
individual plans listed in the readiness plan, with a
schedule and priority attached to each activity.
RUP See Rational Unified Process.
SAR See Solution Assurance Review.
scope creep Projects that gradually extend
beyond their original charters and add functions that
require software that was not in the original contract.
SDA See Software Deployment Architect.
SDM See Software Deployment Method.
SDT See Software Deployment Team.
service level agreements A contract between the
customer and their users for providing availability,
capacity, scalability, performance, and security of
the system.
services requirements document A work
product that lists the services that the Software
Deployment Team believes the customer will need
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
customer, and hopefully convinces the customer to
purchase them.
software demand gap analysis A listing of
products that is burned by defined projects and
products that have yet to be linked to planned
projects (the latter is called potential shelfware).
The unlinked products constitute the gap.

Glossary 149
software deployment Putting software into use or
action. Achieving deployment success requires that
the customers implement the software license on
each endpoint and that they use this software to
overcome challenges, achieve their IT goals, and
gain a competitive advantage.
(SDA) Accelerates deployment of software
solutions and designs additional technical solutions
that leverage the entire IBM Software portfolio to
resolve a customer’s business and IT challenges.
The SDA should assume the role of “trusted advisor
to the customer”. They should leverage this
relationship to identify and design solutions that
satisfy software purchased inside and outside the
Enterprise Agreement. The SDA is key to customer
satisfaction because they ensure that the customer
realizes value from the EA. Since a multitude of
projects and activities surround an EA, the SDA
provides a single point of contact for EA-related
questions and issues.
Software Deployment Method (SDM) A
recommended 3-phase, 11-activity process that a
Software Deployment Team should follow when
deploying software in an Enterprise Agreement
environment. Ideally, the first phase and activity of
SDM should begin when the possibility of the
contract being signed is at approximately 80%.
software deployment milestones and
metrics The critical checkpoints and measures
that the Software Deployment Team defines with the
customer and then follows closely to help ensure
that deployment progress is on track.
Software Deployment Team (SDT) The
individuals responsible for deployment success.
This team should consist of:
EBS
SSR
SDA, SWITA, or both
IT Specialists from the brands
Services representative(s) (IBM Global
Services, Brand, Education, Support, etc.)
Software Group Team (SWG Team) Consists of
the Software Sales Representative, the Software IT
Architect, the Software Deployment Architect, the
Specialist Software Sales Representative (SSSR),
and the Software IT Specialists.
Software IT Architect (SWITA) Designs
comprehensive technical solutions that solve the
customer’s business and IT challenges while
maximizing IBM Software revenue. Software IT
Architects are valued because they first listen to the
customer and then analyze the customer’s business
and IT challenges. They then design a
comprehensive solution that integrates smoothly
into the customer’s context, and that leverages the
best of the entire IBM Software portfolio.
Software IT Specialist (ITS) Advocates IBM
products to technical decision makers. The ITS can
create new revenue opportunity, champion brand
image, and position IBM as the leader in providing
software solutions that meet the customer’s
technical challenges. The ITS also provides a bridge
between the customer’s technical challenges and
potential product solutions.
Software Sales Representative (SSR) Sells IBM
Software in selected large accounts or Small and
Medium Business (SMB) territories and builds
customer relationships. The SSR, along with the
SWITA and SDA, have cross-brand responsibility,
so they have overall responsibility for selling and
customer success across the entire IBM Software
Group (SWG) portfolio. SSRs are involved early
because they work with the brand Specialist
Software Sales Representatives, the Software IT
Specialists, and the Software IT Architects to define
and qualify an opportunity. Each SSR provides a
single “sales face” to the customer across all the
software brands in their assigned accounts.
Solution Assurance Review (SAR) Minimizes
deployment risk. Used to review solutions proposed
to the customer during the selling or deployment
phases of the EA. Ensures that the proposed
solution delivers the features expected and that the
solution is technically possible to implement.

Specialist Software Sales Representative
(SSSR) Sells a particular set of IBM Software and
works with SSRs, Software IT Specialists, and
Software IT Architects in doing so. They have
knowledge of IBM strategies and directions for the
products they represent. They are responsible for
closing the sale and positively impacting the
customer’s satisfaction with the engagement and
offerings.
SSR See Software Sales Representative.
SSSR See Specialist Software Sales
Representative.
support plan Addresses how IBM will deliver
support to the customer and how the customer will
support their users during deployment.
SWG Team See Software Group Team.
SWITA See Software IT Architect.
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.
systems management plan A comprehensive
plan that documents the customer’s change and
configuration management plan, security
management plan, problem management plan, and
who is responsible for solution uptime during
deployment.
use cases A work product that specifies customer
requirements in the areas of performance,
capacity/volumes, scalability, availability, portability,
maintainability, usability, systems management,
security, infrastructure constraints, technology
standards constraints, and geographic/configuration
constraints.
Value Realization Model (VRM) A software
deployment work product that ensures that IBM and
the customer fully understand how the customer
plans to measure deployment success.
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.
vision statements The long-term objectives of the
company. They articulate the company’s target
marketplace, products and services, and the
position the company wants their products and
services to have in the targeted marketplace, as well
as the financial position (revenue, profit, etc.).
VRM See Value Realization Model.

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
A
account planning 98
Achieve the quick deployment wins 61
ADD (architecture decisions document) 94
analyze the software in your inventory 46
analyzing ROI 38
architecture decisions document (ADD) 94
architecture overview diagram 94
Architecture plan 99
architecture plan 100
B
best practice 10, 23
centralize software fulfillment 26
commit to self-sufficiency 29
communicate and market the vision 30
define a time-to-value and ROI strategy 30
determine your deployment readiness 28
hire deployment services 28
identify an EBS and stakeholders 25
implement a license management tool and pro-
cess 27
business context diagram and description 94
business goals 95
buying decision 34
C
centralize software fulfillment 26
CITA (Client IT Architect) 19
Client Executive 19
Client IT Architect (CITA) 19
Client Representative 19
Client Team 18
communication plan 99
Communication tools 87
component model 94
Conduct the initial deployment kickoff meeting 56
conduct the initial deployment kickoff meeting 56
coverage model 76
Create the SDT 42
critical success factors 95
customer
business goals 95
IT environment 95
organization 95
D
department closure 35
deploy software 59
deployment kickoff meeting 30
Deployment Milestone Status Report 97
deployment plan 98, 100
deployment quick-win plan 98
deployment services 91
Develop a high-level deployment plan 47
documentation review tips 46
E
Easy Access Portal 88
Easy access portals 88
education 91
education and skills plan 99
Enterprise Business Sponsor 16
entitlement 89
Establish the deployment partnership 49
example
architecture decisions document 100
architecture overview 102
business context diagram 103
component flow model 106
component model 104
current business organization 111
current IT environments 106
current IT standard 114
envisioned goals and issues 112
mapping business initiatives to projects 116
mapping projects to proposed products and so-
lutions 117
non-functional requirements 118
operational model 120
project description 121
system context diagram 122
systems context diagrams
for an integration architecture 123
use cases 125

viability assessment 127
Execute the deployment plan 63
F
Finalize the deployment plan 54
full-time coverage 74
G
Gap Analysis Report 97
global deployment
activities 78
checklist 76
coverage example 80
global level activities 77
Global Project Lead (GPL) 17
global software deployment 73
checklist 139
projects 73
global support needs 46
goals and milestones 97
H
hard (tangible) ROI 35
hard ROI 30, 35, 37
headcount savings 35
high-level deployment plan 99
I
IBM Client Executive 19
IBM Client IT Architect (CITA) 19
IBM Client Representative 19
IBM Client Team 18
IBM Software IT Architect (SWITA) 20
IBM Software IT Specialist (ITS) 22
IBM Software Sales Representative (SSR) 20
IBM Software Team 19
IBM Specialty Software Sales Representative
(SSSR) 20
IBM Tivoli License Manager (ITLM) 86
Identify new business needs 64
inexperienced project leader 72
Instant messaging 87
internal team 16
IT environment 95
IT standards 96
ITS (IBM Software IT Specialist) 22
L
license acquisition 89
license management 85
License Utilization Report 97
local site 78
tertiary, on-demand coverage 78
M
managing at the milestone level 71
managing global software deployment projects 73
managing software deployment projects 67
getting started 69
managing the success of your first project 70
Milestone status report 99
mission statement 95
My Software Center 88
N
non-functional requirements 96
O
on demand coverage 75
operations plan 100
organization 95
P
part-time coverage 74
Passport Advantage 89
Phase 0, Prepare for deployment 41
Phase 1, Refine and promote the plan 51
Phase 2, Deploy software 59
potential shelfware 97
Premium support 90
Prepare for deployment 41
primary site 74
primary, full-time coverage 77
Problem management 89
process tables 31
project controls 99
project descriptions 96
project lead 16
project management challenges 71
Project Planning 98
project success 70
project timing 69

Index 155
R
readiness plan 28, 99
overview 11
realizing value with hard and soft ROI 37
Redbooks Web site 151
Contact us xv
Refine and promote the plan 51
Refine the deployment plan 52
responsibilities 15
return on investment (ROI) 35
Review the deployment documentation 44
risks and dependencies 100
ROI (return on investment) 35
current value example 39
ROI/ROR Status Report 98
roles 15
S
SAR (Solution Assurance Review) 11
scope creep 71
SDT (Software Deployment Team) 4
secondary site 74
secondary, part-time coverage 78
Self-help 89
server consolidation 35
soft (intangible) ROI 36
soft ROI 30, 35, 37
software deployment 1
best practices 10, 23
challenges 3
checklist 129
continuous process 8
Phase 0, Preparing for deployment 41
Phase 1, Refine and promote the plan 51
Phase 2, Deploy software 59
tools 83
Software Deployment Method 4
Software Deployment Method (SDM) 5
software deployment resources 83
Software Deployment Team (SDT) 4
Software deployment workshop 31
software gap 7
Software IT Architect (SWITA) 20
Software IT Specialist (ITS) 22
software maintenance via Passport Advantage 89
Software Sales Representative (SSR) 20
software solution work products 93
Software Team 19
Solution Assurance Review (SAR) 11
Specialty Software Sales Representative (SSSR)
20
sponsor 16
stakeholder 16
status of maintenance and support 46
Step 0
benefits 43
Create the Software Deployment Team (SDT)
42
inputs, tasks, and outputs 43
owners and participants 43
Step 1
benefits 45
Review the deployment documentation 44
Step 10
benefits 66
Update the business plan 65
Step 2
benefits 48
Develop a high-level deployment plan 47
Step 3
benefits 50
Establish the deployment partnership 49
Step 4
benefits 54
inputs, tasks and outputs 53
Refine the deployment plan 52
Step 5
benefits 55
Finalize the deployment plan 54
Step 6
benefits 58
Conduct the initial deployment kickoff meeting
56
Step 7

Achieve the quick deployment wins 61
benefits 62
Step 8
benefit 64
Execute the deployment plan 63
Step 9
benefits 65
Identify new business needs 64
substitution clauses 46
support, education, and tools 83
system count reduction 35
T
Team IBM 17
team workplaces 87
tertiary site 75
Tivoli License Management 147
U
Update the business plan 65
use cases 97
V
value realization 33
Value Realization Model (VRM) 97
value statement 34
value timeline 34
vision statement 95
W
Web conferencing 87
why have a Software Deployment Method 4
work product
architecture decisions document 94
component model 94
customer’s IT environment 95
customer’s organization 95
goals and issues 95
IT standards 96
project descriptions 96
use cases 97
Work product examples 100
Work products used by SDM 94

TheSoftwareDeploymentMystery-Solved-ACustomerGuide

®
SG24-6070-02 ISBN 0738491284
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooksare developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
The Software Deployment
Mystery - Solved
A Customer Guide
Reveals best
practices and
methods proven to
drive deployment
success
Offers actual
customerexperience
as a guide
Helps make the most
of your relationship
with IBM
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 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.
Back cover

SW Deployment best practices

More Related Content

What's hot (16)

Similar to SW Deployment best practices (20)

SW Deployment best practices