Front cover

Optimizing Software
ftware
Deployment
ment
An Insider’s Guide

Moves deployment planning upstream to

proactively manage customer success

Presents concepts, best practices, and

work products that drive ROI

Introduces and describes the

Software Deployment Method

Bill Bierds
Mike Ransom
David Backman
Carolyn Bjerke
Charles P. Brown
Jeremy Gibson
Sandor Hasznos
Calvin Lawrence

ibm.com/redbooks
International Technical Support Organization

Optimizing Software Deployment:

An Insider’s Guide

September 2003

ZG24-6725-01
 Note: Before using this information and the product it supports, read the information in “Notices” on
page ix.

Second Edition (September 2003)

This edition applies to the IBM Software Group Software Deployment Method.

© Copyright International Business Machines Corporation 2003. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. Introducing the Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Software deployment in an Enterprise Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Why software deployment is so difficult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Why have a Software Deployment Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 The Software Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 The Software Deployment Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Phase 0: Preparing for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Phase 1: Kicking off the deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Phase 2: Executing the deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Software deployment best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.6 Readiness Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.7 Solution Assurance Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 The Signature Selling, TeAM, and Software Deployment Methods . . . . . . . . . . . . . . . 10
1.3.1 Signature Selling Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Technical e-business Architecture Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 Software deployment integration with SSM and TeAM. . . . . . . . . . . . . . . . . . . . . 12
1.3.4 Software Deployment Method interaction with GSM and RUP . . . . . . . . . . . . . . . 15
1.4 Work products overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Work products from SSM in the Software Deployment Method . . . . . . . . . . . . . . 15
1.4.2 Work products from TeAM in the Software Deployment Method . . . . . . . . . . . . . 15
1.4.3 Work products produced by the Software Deployment Method . . . . . . . . . . . . . . 16
1.5 In summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 2. Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Software Sales Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1 Software Account Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Software Sales Specialist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.3 Technical Sales Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.4 Software Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.5 Software Technical Sales Specialist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.6 Software Deployment Architect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.7 Bid Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Client Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Client Executive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Client Representative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Client IT Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.4 Managing Director. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Customer’s Enterprise Business Sponsor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Team IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

© Copyright IBM Corp. 2003. All rights reserved. iii

 Chapter 3. Software Deployment Phase 0: Preparing for deployment. . . . . . . . . . . . . 25
3.1 DM 0: Create the Software Deployment Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 DM 1: Review the deployment documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4 Document review tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 DM 2: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 DM 3: Establish a deployment partnership with the customer . . . . . . . . . . . . . . . . . . . 33
3.4.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 4. Software Deployment Phase 1: Conducting the deployment kickoff . . . . 35

4.1 DM 4: Refine the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 DM 5: Finalize the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 DM 6: Conduct the deployment kickoff meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Owner and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 5. Software Deployment Phase 2: Deploying the software. . . . . . . . . . . . . . . 43

5.1 DM 7: Begin the quick deployment win activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 DM 8: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 DM 9: Scan for new deployment and revenue opportunities . . . . . . . . . . . . . . . . . . . . 48
5.3.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4 DM 10: Amend or renew the Enterprise Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.1 Owners and participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4.2 Input, tasks, and output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 6. Managing software deployment projects . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1 Enterprise Agreement project: Application of solutions to satisfy a business need . . . 54
6.2 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

iv Optimizing Software Deployment: An Insider’s Guide

6.3 Managing the success of your first project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4 Managing at the milestone level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.5 Handling project management challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.5.1 Too much of one product and not enough of another . . . . . . . . . . . . . . . . . . . . . . 56
6.5.2 Scope creep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.5.3 The inexperienced project leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 7. Managing global software deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1 How the coverage model works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2 Global deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2.1 More about the checklist items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3 A global deployment coverage example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 8. Achieving return on investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.1 Hard (tangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2 Soft (intangible) ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3 ROI must support the business strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.4 An approach to analyzing return on investment with a customer . . . . . . . . . . . . . . . . . 67
8.5 Deployment goals and measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.6 When goals are met, IBM and the customers win. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.7 Example ROI: Current value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Chapter 9. Software deployment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

9.1 Enterprise views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.1.1 All view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.1.2 Enterprise By Name view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.1.3 Locations view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9.1.4 Projects view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.1.5 Brand Coverage view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.1.6 Health Reports view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1.7 Contacts/General Documents view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.2 Account Health Summary views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.2.1 All view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.2.2 GEO views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.2.3 Detailed health reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.3 Reports view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.3.1 Pre-defined reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.4 SWAP View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.5 Team rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Chapter 10. Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.1 Identify Enterprise Business Sponsor and stakeholders . . . . . . . . . . . . . . . . . . . . . . . 86
10.2 Centralize software fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.3 Implement a license management tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.4 Hire deployment services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.5 Determine the customer’s deployment readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.6 Commit to self-sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.7 Define a time-to-value and ROI strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.8 Communicate and market the vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Chapter 11. The Readiness Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

11.1 Business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11.2 Communications plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11.3 Education plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Contents v
 11.4 Execution environment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.5 Support plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.6 Backup and recovery plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.7 Systems management plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.8 Internal service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.9 Migration plan and schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.10 Rollout plan and schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.11 Service level agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
11.12 Plan assessment tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.13 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.14 Relationships among deployment plan, project plans, and readiness plans. . . . . . . 96

Appendix A. Work products: Usage and examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

TeAM work products used by SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Work products produced by SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
SDM phases, activities, and work products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Work product examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Example: Architecture decisions document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Example: Architecture overview diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Example: Business context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Example: Current IT environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Example: Current organization diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Example: Envisioned goals and issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Example: IT standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Example: Mapping business initiatives to projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Example: Mapping projects to proposed products and solutions . . . . . . . . . . . . . . . . . 118
Example: Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Example: Project descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Example: System context diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Example: Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Example: Viability assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Appendix B. SAM, SWA, and SDA responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

SAM role and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
SWA role and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
SDA role and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Appendix C. Software deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Software deployment activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Phase 0: Preparing for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
DM 0: Create Software Deployment Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
DM 1: Deployment documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
DM 2: Develop a high-level deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
DM 3: Establish a deployment partnership with the customer . . . . . . . . . . . . . . . . . . . 133
Phase 1: Kicking off the deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
DM 4: Refine the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
DM 5: Finalize a deployment plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
DM 6: Conduct the deployment kickoff meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Phase 2: Executing the deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
DM 7: Begin quick deployment win activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
DM 8: Execute the deployment plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
DM 9: Scan for new deployment and revenue opportunities . . . . . . . . . . . . . . . . . . . . 138
DM 10: Amend or renew Enterprise Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

vi Optimizing Software Deployment: An Insider’s Guide

Appendix D. Global deployment checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Appendix E. Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Contents vii
viii Optimizing Software Deployment: An Insider’s Guide
Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that does
not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and
distribute these sample programs in any form without payment to IBM for the purposes of developing, using,
marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2003. All rights reserved. ix

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® ibm.com® Rational Suite®
C/370™ IMS™ Rational Unified Process®
CICS/ESA® LearningSpace® Rational®
CICS® Lotus® Redbooks(logo) ™
Database 2™ MVS™ Redbooks™
DB2® MVS/ESA™ RUP®
DFSORT™ NetVista™ S/390®
™ Notes® Tivoli®
Eserver™ OS/390® VisualAge®
GDDM® Passport Advantage® VTAM®
ImagePlus® PAL® WebSphere®
IBM® QMF™ zSeries®

The following terms are trademarks of other companies:

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic
Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.

x Optimizing Software Deployment: An Insider’s Guide

Preface

This IBM Redbook was written for the IBM Software Group (SWG) Team. This team consists
of the Software Account Manager (SAM), the Software Architect (SWA), the Software
Deployment Architect (SDA), the Software Sales Specialist (SSS), and the Software
Technical Sales Specialists (ITS). The premise of this book is that a proactive, defined
deployment method is essential to selling, allocating, and deploying software. This disciplined
method provides maximum software utilization. It is critical to achieving customer success
and satisfaction while earning customer confidence and loyalty.

The SAM, SWA, and SDA have cross-brand responsibility, and an overall responsibility for
selling and customer success across the entire IBM SWG portfolio. The SSS and ITS exist
within the brand (Data Management, Lotus®, Tivoli®, WebSphere®, and Rational®). They
are responsible for selling and deploying specific brand products. It is critical that the
cross-brand team members have a close working relationship with the brand teams. This
ensures that each product receives the proper amount of skilled attention during the selling
and deployment cycle.

This redbook describes the Software Deployment Method (SDM), which when followed, helps
to ensure that customers obtain value from the software they purchased from IBM. The
context used to describe the method is the Enterprise Agreement, which represents SWG’s
largest and most complicated transaction. It also describes the role of the customer, because
it is critical that the customer takes ownership and strives to be self-sufficient when deploying
and maintaining the software in their environment.

The SDM integrates tightly with two other major IBM methods: the Signature Selling Method
(SSM) and the Technical e-business Architecture Method (TeAM). This redbook describes the
interaction and integration among SDM, SSM, and TeAM.

This book presents concepts, best practices, and work products that professionals involved in
selling and deploying software should follow. With this redbook, you can more efficiently and
effectively help customers derive the greatest possible value from their software investment
with IBM.

You should view the content of this redbook as dynamic and growing. IBM has many tools,
techniques, and procedures to maximize the success of customers. The authors of this book
will expand the contents of this book as deployment breakthroughs are uncovered. Also,
several IBM and customer-specific examples are provided in this redbook. Although the
examples are accurate as of July 2003, you should use them as guidance rather than gospel,
since the details will change over time.

Important: This redbook is intended for an internal IBM audience. It is not meant to be
distributed in its entirety outside of IBM.

© Copyright IBM Corp. 2003. All rights reserved. xi

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, SWG) to Maggie Blayney (Director of the ITSO).

Bill Bierds, WW SWG - Software Deployment Strategies

Mike Ransom, ITSO Project Leader

David Backman, Senior Certified IT Architect

Charles P. Brown, Senior Certified IT Specialist

Carolyn Bjerke, Ease-of-Use Architect/Designer

Jeremy Gibson, Program Manager, Deployment Strategies

Sandor Hasznos, Certified IT Architect

Calvin Lawrence, Certified IT Architect

Thanks to the following people for their contributions to this project:

Mohammed Ajab
Software Deployment Architect

John Barker
Software Deployment Architect

Pete Bouchard
Senior Certified IT Architect

Reid S. Byers
Software IT Architect

Tom Carr
Certified Project Manager, Software Deployment Architect

Rob Coventry
Technical Sales Manager, Central Region Architects

Paul Edwards
PMP, Certified Project Manager, Software Deployment Architect

Kathy Hofstrom
Business Unit Executive, Technical Sales, Central Region, IBM Americas

Kathleen O’Leary
Software Deployment Architect

Mac Pogue
Certified Project Manager, Software Deployment Architect

Lauren States
VP Technical Sales and Deployment

Beverly Vandahl
Program Manager - ELA Deployment

xii Optimizing Software Deployment: An Insider’s Guide

 Kim Waddell
Director ELA Deployment

William Welch
Software Deployment Architect

Fernando Zuliani
Certified Senior Consulting IT Specialist

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

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:
[email protected]
򐂰 Mail your comments to:
IBM® Corporation, International Technical Support Organization
Dept. JLU Building 107-2
3605 Highway 52N
Rochester, Minnesota 55901-7829

Preface xiii
xiv Optimizing Software Deployment: An Insider’s Guide
 1

Chapter 1. Introducing the Software

Deployment Method

Deployment is defined as put into use or action. Software deployment is defined as putting
software into use or action. Achieving deployment success requires customers to implement
a software license on each endpoint – server or workstation. It also requires them to use this
software to overcome challenges, achieve their IT goals, and gain competitive advantage.

Customers use software and software solutions to address key business requirements.
Business value is fully realized when the software is implemented on a timely basis. It is also
realized when this investment is leveraged across multiple organizations and projects within
the organizations. Putting software into action drives customer success.

IBM’s extensive experience in deploying software revealed that many customers were not
taking the steps that are necessary to achieve business value, for example:
򐂰 A deployment strategy was not mapped out. Early projects were not identified, and the
scope and schedule of software implementation were not considered.
򐂰 The transition plan from the purchasing team to the implementation team did not clearly
articulate expectations, roles, and responsibilities.
򐂰 Identified deployment projects did not occur on schedule. Software deployment is
inherently complex. It involves multiple components and organizations. Therefore, reactive
project management resulted in delayed implementation due to challenges that arose late
in the deployment process.
򐂰 Successful deployments were not leveraged across the broader customer organization.
The customer and IBM organizations were tasked with a single implementation.
Therefore, they did not focus on leveraging the lessons, experiences, and investment from
this single core need across the broader customer environment.

The lack of focus in these areas has resulted in less than optimal deployment performance. It
has also spawned situations where multiple projects are run in parallel with inadequate
infrastructure or mechanics to leverage common components, tasks, resources, lessons, and
so forth.

© Copyright IBM Corp. 2003. All rights reserved. 1

 These experiences suggest that successful software deployment, both in the actual
deployment and the identification of opportunities, doesn't just happen. It requires proactive
focus and attention from both IBM and the customer in the following areas:
򐂰 Qualifying the initial demand (projects)
򐂰 Identifying the core team, both IBM and customer, that will coordinate the overall software
deployment process
򐂰 Developing a deployment strategy
򐂰 Defining additional projects that can help the customer overcome new challenges using
purchased software

To address these needs, the Software Deployment Method, which this book describes, was
established.

Software deployment does not take place in a vacuum. It should be tightly linked to the sales
cycle. As such, it should integrate with IBM’s Signature Selling Method (SSM) and the
Technical e-business Architecture Method (TeAM).

As an example of the linkage to SSM, it is critical to properly transition the customers from the
selling cycle to the deployment cycle. The Software Deployment Method begins when the
agreement has an 80% possibility of closure (see Figure 1-1). This ensures that the activities
and conversations that occur during the selling cycle, which prove to be invaluable, are
passed to the team with a focus on deployment success. The vision and goals of the
customer’s power sponsor are extremely important to identify and execute projects that
prevent the software from becoming shelfware. Also, the method for deployment described in
this book uses SSM and TeAM work products as input at various points.

Note: This book assumes that you are familiar with SSM or TeAM. A brief overview of each
method is provided later in this chapter.

2 Optimizing Software Deployment: An Insider’s Guide

 Figure 1-1 Software deployment linkage to the sales cycle

1.1 Software deployment in an Enterprise Agreement

Software deployment occurs on a wide range of scale, from transactions of less than one
million dollars to transactions of many millions of dollars. This redbook focuses on the
software that is deployed as part of an Enterprise Agreement (EA), which represents SWG’s
largest and most complicated transactions.

An Enterprise Agreement is ordinarily a multi-platform software offering that includes IBM

Eserver zSeries® monthly license charges (MLC) and a 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.

The EA was selected because it highlights some of the areas where process improvement is
required. The content of this redbook, however, is pertinent to all agreements closed within
SWG. The process and discipline presented help to ensure greater customer success across
the brands and around the world. It is important that you remember that the small customers
of today are the big customers of tomorrow.

Chapter 1. Introducing the Software Deployment Method 3

 Enterprise Agreement: Each geography refers to the Enterprise Agreement in its own
terms. In the United States, it is referred to as an Enterprise Agreement, and in the
Americas, it is called an Enterprise License Agreement (ELA). In Europe, it is called an
Enterprise Software and Services Option Agreement (ESSO), and in Asia Pacific, it is
called a Software Special Bid (SBB). This book uses the term Enterprise Agreement.

1.1.1 Why software deployment is so difficult

The software deployment challenges posed by the EA make it a perfect learning environment
for both the selling and deploying of software. In this difficult-to-manage environment,
problems invariably occur. Such problems are explained here:
򐂰 One key area of concern is the handoff after agreement closure from the selling team to
the deployment team. Roles are not always crisply defined, assumptions are made, and
expectations are set with little documentation or communication. At times, this causes
early projects, that are critical to a fast start, to falter, with the IBM team becoming the
focus of intense pressure.
򐂰 To make deployment even more difficult, when an EA is closed, not all projects are
concretely defined to maximize software utilization. Because of this, selling and demand
generation must be executed throughout the entire life cycle of the agreement.
򐂰 Often times, the person or persons who will own software deployment from the customer
are not identified or may be out of the loop during the selling cycle. Therefore, the
customer does not know which products were purchased and which business challenges
the EA was crafted to solve.
򐂰 Some people in the customer’s organization may even be opposed to what was bought
and 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 EA. It is not uncommon that the SWG and Client Teams call on
individuals who may not be fully aware of the overall corporate IT strategy. This can create
challenges during the deployment phase. That is because to maximize deployment
performance, the entire IT organization needs to be aligned behind one mission,
regardless of how tactical the individual needs may be.
򐂰 As a final hurdle in this environment, it is not uncommon for software to sit on the shelf 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 a negative conversation when
it comes time to renew, amend, or sign a new EA.

1.1.2 Why have a Software Deployment Method

A requirement arose for a documented, proven, repeatable Software Deployment Method
that, when followed, maximizes the customer’s chances of deployment success. This redbook
documents the method.

The key to the customer deriving value from software deployed within an EA is the IBM team’s
adherence to this method (a common roadmap). This keeps the team on the same page and
helps them to look and act as a team when they interact with the customer.

4 Optimizing Software Deployment: An Insider’s Guide

1.1.3 Roles and responsibilities
The entire SWG Team is responsible for the customer’s success. Throughout the life cycle of
the agreement, role clarification and teaming are extremely important. The SWG Team
includes:
򐂰 The Software Account Manager (SAM)
򐂰 The Software Architect (SWA)
򐂰 The Software Deployment Architect (SDA)
򐂰 The Software Sales Specialist (SSS)
򐂰 The Software Technical Sales Specialists (ITS)

The SAM, SWA, and SDA have cross-brand responsibilities. Their overall responsibility is for
selling and customer success across the entire IBM SWG portfolio. The SSS and ITS exist
within a brand (Data Management, Lotus, Tivoli, WebSphere, and Rational). In general, these
roles exist at each account in the ways shown in Table 1-1.

Table 1-1 Roles in a strategic and cross brand versus roles in a tactical and single brand
Sales Technical sales and deployment

Strategic and Software Account Manager (SAM) Software Architect (SWA) and Software
Cross Brand Deployment Architect (SDA)

Tactical and Software Sales Specialist (SSS) Software Technical Sales Specialist (ITS)
Single Brand

The SSS and ITS are responsible for selling and deploying their specific products. When an
agreement is negotiated, an additional key player is inserted temporarily into the equation.
This person is referred to as the Bid Manager (or Deal Maker in the Americas). This person
plays a critical role in ensuring that all agreements follow specified guidelines before they are
closed. They handle much of the negotiation around the contract details. They are critical in
the Software Deployment Method because a key component of the method is to help ensure
that the contract is fully understood by the entire SWG Team.

SAMs are involved earliest in the process because they work with the brand Software Sales
Specialists, the Software Technical Sales Specialists, and the Software Architects to define
and qualify an opportunity. Shortly after the opportunity becomes real, the Software Technical
Sales Specialists and Software Architects focus their energy on designing the solution. As
mentioned earlier, this book and the deployment method begin by focusing on this critical
point in the selling cycle (80% closure possibility). At this important juncture, a transition plan
needs to be drafted to ensure a smooth handoff between the selling and deployment teams
within the SWG.

Although it is not part of the SWG Team, the IBM Client Team also plays a critical role. The
key players on the Client Team are:
򐂰 Managing Director (integrated accounts only)
򐂰 Client Executive
򐂰 Client Representative
򐂰 Client IT Architect (CITA)

During the life of the Enterprise Agreement, the level of involvement of each person shifts in
focus. The kinds of activities each person performs also change. For example, as deployment
begins, the SDA’s sole focus is to identify and initiate projects and build relationships that lead
to new deployment opportunities. However, as the next agreement approaches (for example,
renewal, amendment, etc.), the SDA’s responsibilities start to shift. The SDA makes sure the
customer is in the best possible position to sign a new contract and that IBM is not at any
revenue risk. This revenue risk includes any situation that impacts IBM’s strong and fully

Chapter 1. Introducing the Software Deployment Method 5

 informed negotiating position. It follows that the deployment team should do the work during
the deployment cycle to help ensure that selling is natural and welcomed.

The Enterprise Business Sponsor represents the customer and takes ownership for software
deployment throughout the enterprise. The Signature Selling Method refers to the power
sponsor as being the key customer representative. To avoid confusion with the power
sponsor, it is important to clarify that the Enterprise Business Sponsor and the power sponsor
may, in some accounts, be the same person. However in other accounts, the person who
works to close the Enterprise Agreement (power sponsor) is not responsible for deployment
milestones (Enterprise Business Sponsor). In this book (and when describing the Software
Deployment Method), we refer to the deployment owner as the Enterprise Business Sponsor.

For additional information about roles and responsibilities, refer to Chapter 2, “Roles and
responsibilities” on page 17.

1.2 The Software Deployment Method

As shown in Figure 1-2, the Software Deployment Method consists of three phases and 11
steps (DM 0 through DM 10). Although these phases and steps are discussed throughout this
book in a serial manner, in practice, they may overlap or repeat throughout the deployment
cycle. The phases are:
򐂰 Phase 0: Involves preparing for the software deployment
򐂰 Phase 1: Involves conducting a series of kickoff meetings and events
򐂰 Phase 2: Involves deploying the software and driving the renewal or amendment of the
Enterprise Agreement

Create software deployment team (DM 0) Refine deployment plan (DM 4)

Begin quick wins (DM 7)
Review documents (DM 1) Finalize deployment plan
Execute deployment plan (DM 8)
Deploy- Develop high-level plan (DM 2) with customer (DM 5)
Scan for new opportunities (DM 9)
ment Establish deployment partnership with Conduct deployment kickoff
customer (DM 3) Amend or renew EA (DM 10)
meeting (DM 6)

Phase 0: Prepare for deployment Phase 1: Kickoff deployment Phase 2: Execute deployment

Figure 1-2 Overview of the Software Deployment Method

1.2.1 The Software Deployment Team

Many IBMers and customers are involved with the sale and deployment of software in an
Enterprise Agreement. The subset of individuals responsible for deployment success is called
the Software Deployment Team (SDT). This team includes the following members:
򐂰 Software Account Manager (SAM)
򐂰 Software Deployment Architect (SDA) and/or Software Architect (SWA)
򐂰 Software Technical Sales Specialists from the brands
򐂰 Services Representative or Representatives (IBM Global Services (IGS), Brand,
Education, Support, etc.)

Others from the IBM teams and the customer account participate at various times in the
activities of the method. However, the SDT is accountable for deployment success at
accounts where they are assigned throughout the entire life cycle of the EA.

6 Optimizing Software Deployment: An Insider’s Guide

1.2.2 Phase 0: Preparing for deployment
The overall purpose of this phase is for IBM and the customer to build the groundwork
required for successful deployment. The activities in this phase are:
򐂰 DM 0: Create the Software Deployment Team: During this step, the SAM, Client
Executive, Technical Sales Manager (TSM), and/or Managing Director are responsible for
forming the team that owns deployment success for IBM SWG. This team is called the
Software Deployment Team.
򐂰 DM 1: Review the contract content and critical deployment documents (IBM internal
discussion): The purpose of this activity 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, business content diagram,
requirements, and solution concepts. This information can be used throughout the
process to identify additional sales opportunities. This is explained in step DM 9, but it
should be considered in all steps.
򐂰 DM 2: Develop a high-level deployment plan (IBM internal discussion): The purpose of
this step is to take the high-level mapping of products to customer projects and assign
ownership within the customer at a project level. The high-level deployment plan defines a
list of initial deployment projects, identifies a customer sponsor and owners for known
projects, groups deployment into logical chunks, contains a deployment timeline, and
includes a services assessment. During this step, the internal SWG Team determines the
customer’s readiness for deployment by reviewing the SW Deployment Best Practices
and the Readiness Plan content.
򐂰 DM 3: Establish a deployment partnership with the customer (IBM and Customer
meeting): The purpose of this step is to solidify the customer and IBM partnership and to
help ensure that both groups realize that deployment is a “two-way street” and that the
customer is ultimately responsible for the deployment. During this activity, the SDT
partners with the customer to identify quick deployment wins (that are technical proof
points) and define critical success milestones and criteria. They agree on roles and
responsibilities and introduce the SW Deployment Best Practices and the Readiness Plan.
The customer and IBM agree on the high-level deployment plan created in the previous
steps and discuss a deployment services strategy.

1.2.3 Phase 1: Kicking off the deployment

This phase begins (ideally) after the sale has closed and at the point when critical inputs are
reviewed again to inspect changes made during contract negotiation. Also, during this phase
a deployment plan is constructed, and the deployment kickoff meeting is held. The activities in
this phase are:
򐂰 DM 4: Refine the high-level deployment plan (IBM internal activity): The purpose of this
activity is to revise the solution architecture and deployment plans to reflect any changes
made during contract negotiation. During this activity, the SDT reviews all inputs to steps
DM 1 and DM 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
had been done. A key output from this activity is a refined deployment plan.
򐂰 DM 5: Finalize the deployment plan with the customer (IBM and customer activity):
The purpose of this activity is to obtain the customer owner’s agreement with the final
deployment plan. During this activity, the SDT and customer review all inputs to DM 3 and
they agree on project controls. Also, during this step, the customer sponsor and IBM
discuss the plans for a deployment kickoff meeting.

Chapter 1. Introducing the Software Deployment Method 7

 򐂰 DM 6: Conduct a deployment kickoff meeting (IBM and customer activity): The purpose
of this activity is to market and communicate the deployment plan (and vision) to all
current and potential users within the customer’s environment. This typically is done in the
form of a meeting or a series of meetings attended by the full IBM team and customer
stakeholders (team project leads, IT leads, and lines of business leaders). It is imperative
that all key leaders attend. The kickoff meeting should create awareness, understanding,
and enthusiasm for the deployment that is about to begin.

1.2.4 Phase 2: Executing the deployment

The purpose of this phase is to begin executing the deployment plan, starting with the
carefully selected quick deployment wins and moving on to the others. During this phase,
project management is critical. The activities in this phase are:
򐂰 DM 7: Execute quick deployment wins (IBM and customer activity): The purpose of this
step is to execute on the quick deployment wins and, in doing so, demonstrate success
and build momentum in the beginning stage of deployment. This activity is critical to
building credibility early in the relationship life cycle. Software deployment has begun!
򐂰 DM 8: Execute the deployment plan (IBM and customer activity): The purpose of this
step is to build on the success and momentum of the quick deployment wins and to begin
deploying projects that were defined during the sales cycle. During this step, project
management is critical, and customer satisfaction and progress toward deployment goals
(timeline and financial) should be monitored carefully.
򐂰 DM 9: Scan for new opportunities (IBM and customer activity): Recognizing that not all
deployment projects are identified prior to agreement closure, the purpose of this activity
is to use selling and architecture techniques to generate demand for the remaining
products in the contract inventory. The SDT leverages TeAM once again to develop work
products that justify new demand for software. Also, new opportunities for revenue should
be found during this step.
򐂰 DM 10: Amend or renew the agreement (IBM internal activity): The purpose of this
activity is to shift the SWG Team’s focus to sell new revenue opportunities and obtain
repeat business for IBM. The team should drive for amendments to (or renewal of) the
Enterprise Agreement.

1.2.5 Software deployment best practices

Deployment success and value realization are best achieved when the following best
practices are adhered to constantly throughout the life of the Enterprise Agreement and the
Software Deployment Method.

The customer-specific best practices are:

򐂰 Identify Enterprise Business Sponsor and stakeholders.
򐂰 Centralize software fulfillment.
򐂰 Implement a license management tool.
򐂰 Hire deployment services.
򐂰 Determine the customer’s deployment readiness.
򐂰 Commit to self-sufficiency.
򐂰 Define a time-to-value and return on investment (ROI) strategy. For more information
about ROI, see Chapter 8, “Achieving return on investment” on page 65.
򐂰 Communicate and market the vision.

8 Optimizing Software Deployment: An Insider’s Guide

 The SWG Team’s deployment focus areas are:
򐂰 Know the contract.
򐂰 Communicate the software deployment best practices to the customer.
򐂰 Execute the deployment Readiness Plan.
򐂰 Host a deployment kickoff meeting.
򐂰 Stay with it! Software deployment success requires sustained teamwork between the
customer and IBM.

You can find more information about the best practices in Chapter 10, “Best practices” on
page 85.

1.2.6 Readiness Plan

After a customer has committed to purchase IBM software, it is critical that they acquire the
skills and process knowledge necessary to successfully deploy the solution. The Readiness
Plan is designed to facilitate the communications and planning between IBM and the
customer at this critical juncture in the sales process – after the software purchase decision
has been made but before implementation. A well-executed readiness plan proactively
addresses implementation issues with the customer. In turn, it promotes enhanced customer
satisfaction with the IBM solution. The Readiness Plan itself is a set of process and work
products that are designed to:
򐂰 Help ensure the customer expectations are aligned
򐂰 Identify issues and risks and set a proper course of action
򐂰 Help ensure the customer 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
fashions, such as one-on-one with the Enterprise Business Sponsor or presented to a group
during a kickoff meeting. Selection of plan elements and timing of their delivery highly depend
on each individual. The IBM team should fully understand the nuances of the particular
customer situation and then craft the specific Readiness Plan accordingly. The customer
should sign off on the Readiness Plan. This signifies their acknowledgement of the scope of
IBM and their own responsibilities.

The Readiness Plan is composed and delivered by the Technical Sales Team. Depending on
the scope of the software sales opportunity, the SWA, SDA, and ITS may assume ownership
of the particular plan. Pure “brand” sales may require the involvement only of the Software
ITS team. However, as the project scope and product set expands, the responsibility for
delivery shifts to the SWA and/or the SDA.

To learn more about the Readiness Plan, see Chapter 11, “The Readiness Plan” on page 89.

1.2.7 Solution Assurance Review

The Solution Assurance Review (SAR) was created to minimize deployment risk. A SAR is
used to review solutions proposed to the customer during the selling or deployment phases of
the EA. It helps to ensure that:
򐂰 The proposed solution delivers the features that are expected.
򐂰 The solution is technically possible to implement.

A Solution Assurance Review is required when a deployment solution is designed by IBM

SWG and when the product being deployed is on the Mandatory Review List (MRL). While
execution of a SAR is required at certain times, we recommend that you incorporate it into the
daily work methods and use it proactively to minimize deployment challenges.

Chapter 1. Introducing the Software Deployment Method 9

 Note: The MRL is updated regularly and maintained on the SAR Web page at:
http://w3.IBM.com/support/assure

1.3 The Signature Selling, TeAM, and Software Deployment

Methods
The Signature Selling, TeAM, and Software Deployment Methods are overlapping
methodologies. Ideally, the beginning phase of the Software Deployment Method should
occur before the sale closes, so that important handoffs from the sales team to the
deployment team can be made. Also, this beginning phase of software deployment should
occur during the planning and execution phases of TeAM. This helps ensure that the
technical work products created during these phases are inputs to activities in the deployment
method.

This section provides overviews of SSM and TeAM and shows their integration with Software
Deployment Method. It also describes the cross-method work products.

1.3.1 Signature Selling Method

IBM’s recommended way of selling is called the Signature Selling Method. SSM has three
phases: plan, execute, and implement. The activities that make up SSM are:
1. Understand the customer. Understanding the customer's business and IT environment
is the first activity in the Signature Selling method. The sales tools and collateral provide
information that helps team members evaluate the business environment and examine the
factors that affect the buyer's competitive position. The information they find helpful at this
point in the cycle describes:
– The customer’s industry
– The competitors
– Business direction for the industry solutions
– Education on the marketplace
2. Develop the sales plan. The second activity in the process is to develop plans that are
linked to the customer’s business environment. At this time, the sales team develops
plans that are linked to the customer’s business strategy and key business initiatives. The
sales tools and collateral provide information that is designed to:
– Help stimulate customer interest
– Initiate dialog to develop business needs
– Assess the customer's pains or compelling reasons to act
– Either create an initial opportunity plan or disengage
3. Establish the buying vision. The third activity in the process is to establish the buying
vision. At this point in the cycle, the customer should realize their needs and the sales
team’s needs to paint the buying vision. The sales tools and collateral provide information
that help to:
– Clarify the customer’s needs
– Bridge from the customer’s business initiatives to a conceptual solution
– Confirm the customer’s sponsorship and ability to make the buying decision
– Negotiate access to the power sponsor

10 Optimizing Software Deployment: An Insider’s Guide

 4. Qualify the opportunity. The fourth activity in the process is to articulate IBM's
capabilities and qualifying the opportunity. The sales tools and collateral provide
information that can be used to:
– Review or influence the customer's buying criteria
– Develop a preliminary solution and value statement with the customer
– Document an evaluation plan
– Gain agreement from the power sponsor
– Evaluate IBM’s risk to determine whether to continue or disengage
5. Develop a solution. The fifth activity in the process is to develop the solution with the
customer. It occurs when the customer is selecting a solution option. The sales tools and
collateral provide information to help:
– Refine a solution and develop a value proposition with the customer
– Build a solution blueprint and recommended plan
– Validate competitive position and make strategy adjustments
– Assess mutual interest in continuing relationship
– Get Contracts & Negotiations (C&N) approval for nonstandard contract terms
6. Close the sale. The sixth activity in the process is to close the sale. The sales tools and
collateral provide information to help:
– Resolve any open concerns for final customer approvals
– Negotiate final terms and conditions with legal, if necessary
– Prepare contracts to obtain customer/IBM signatures
7. Monitor the implementation. The final activity in the process is to monitor the solution
implementation and ensure that customer expectations are met. The sales tools and
collateral provide information to help:
– Track solution benefits with the customer
– Manage implementation activities to meet or exceed customer expectations
– Checkpoint with the customer and power sponsor on overall progress
– Find additional ways to extend customer value and create new opportunities for IBM

You can find more information about SSM on the Web at:
http://w3-3.ibm.com/sales/compass/ssm_home/ssm_home.html

1.3.2 Technical e-business Architecture Method

TeAM (also called TeAMethod) is a strategic method for the technical sales community that
defines a disciplined and repeatable process for architects and specialists. TeAM enables
seamless collaboration between IBM Sales, presale architects/specialists, and IGS IT
architects. It provides guidance for technical sales activities, reinforces SSM and complex
solution development best practices, increases potential to share knowledge (intellectual
capital), and helps ensure better handoff communications to IGS.

TeAM focuses on selling solutions rather than selling products. This method was originally
created for Software Architects and client IT architects. It is now being used by many
Software Technical Sales Specialists across IBM.

TeAMethod was created to:

򐂰 Support the Signature Selling Method in a coordinated way.
򐂰 Translate selling method activities to counterpart pre-sale architect activities.
򐂰 Keep TeAMethod as a thin layer that “wraps” and reuses existing methods and assets
such as System Integration and Application Development (SI&AD).

Chapter 1. Introducing the Software Deployment Method 11

 򐂰 Focus on SIMethod, now called IBM Global Services Method (GSM), as the primary
underlying method. More information about GSM is provided in 1.3.4, “Software
Deployment Method interaction with GSM and RUP” on page 15.
򐂰 Conform to Application Description Standard (ADS) where relevant.
򐂰 Provide guidance for using appropriate aspects of multiple methods.
򐂰 Provide guidance for activities unique to the pre-sale architect role.
򐂰 Support handoff and collaboration with IGS ITAs.
򐂰 Update and evolve based on real pre-sale architect experiences.

TeAM, like SSM, has three phases: plan, execute, and implement. The activities that make up
TeAM are:
1. Evaluate the customer’s environment.
2. Develop IT solutions linked to the customer’s strategy.
3. Verify the customer’s interest in working with IBM.
4. Demonstrate the business benefits and capabilities.
5. Develop the solution with the customer.
6. Refine the solution and resolve concerns.
7. Monitor and meet expectations.

You can learn more about TeAM on the Web at:

http://w3-3.ibm.com/education/servlet/com.ibm.ls.igc.servlets.
CourseDescriptionServlet?&coursecode=WBT7989B

1.3.3 Software deployment integration with SSM and TeAM

Figure 1-3 shows the recommended overlap and integration of the activities in the SSM,
TeAM, and Software Deployment Methods.

Phase 0 of the Software Deployment Method should occur in SSM between the “sale
qualified” and “sale won” activities, and during the latter part of the execute phase of the
TeAM method. Phases 1 and 2 of the Software Deployment Method should occur after the
agreement closes in SSM and during the implementation phase of TeAM.

12 Optimizing Software Deployment: An Insider’s Guide

 SSM
SSM

Completed
Proposed
Identified

Validated
Understand

Qualified
Develop the Monitor the

Won
the Develop the Eestablish the Qualify the Close the
solution with implementation
customer sales plan buying vision opportunity sale
customer

Plan Execute Implement

TeAM
TeAM

Completed
Develop IT Verify Demonstrate

Qualified
Evaluate business Develop Refine Monitor
solutions customer's

Won
benefits and solution solution and solution and
customers' linked to interest in
capabilities with resolve meet
environment customer's working
customer concerns expectations
strategy with IBM

Plan Execute Implement

SDM
SDM DM 0
DM 7
DM 4 DM 5
Define DM 1 Execute
DM 8
Refine Finalize
Software Document quick Execute
deployment deployment
Deployment review deployment deployment
plan plan with
plan

Deployment
Team customer wins

Success &

Revenue
New
DM 2 DM 6 DM 9 DM 10
DM 3
Develop high Conduct Scan for Amend or
Establish
level deployment deployment renew
partnership
deployment kick-off demand & Enterprise
with customer
plan meeting new revenue Agreement

Prepare Kick-off Execute

Figure 1-3 Integration of the SSM, TeAM, and Software Deployment Methods

Figure 1-4 shows another, more detailed example of the overlap between the Software
Deployment Method and SSM.

The overlap of the software deployment planning phase with the activities in SSM is
recommended for practical reasons. Before a sales opportunity closes, the sales team is
extremely busy, but they are present at the customer’s site and generally available for
meetings with the deployment and customer teams. After the agreement closes, their
attention shifts, and they move to the next opportunity or perhaps the next customer. The
deployment method can begin after the agreement closes. However, experience teaches us
that the deployment team has a hard (but not impossible) time getting the attention of the
sales team in a post-sales environment. Where possible, engagement with the sales team
should occur prior to agreement closure.

The recommended place to introduce deployment discussions in the SSM is when the sales
opportunity is fully qualified and there is a 70% to 80% possibility that the agreement will
close. At this point, the technical team and the customer begin to finalize the solution design.
It is also at this point that the technical sales team begins considering Solution Assurance
Reviews.

Solutions are made up of, or apply to, multiple projects. Projects “burn” software licenses, and
they may use hardware and services, too. At this point in the sales cycle, the IBM sales team
should engage the Software Deployment Team (the SAM, SDA or SWA, ITSs, and the
services representative(s)). The deployment team needs to know that an agreement is being

Chapter 1. Introducing the Software Deployment Method 13

 negotiated and who the customer players are. Ideally the sales team can introduce the
deployment team and the deployment process to the customer team. If the process is
introduced properly, the customer is assured that IBM won’t walk away after the sale
completes. Experienced IBM personnel is there to help the customer deploy what they
purchased.

Figure 1-4 SSM and Software Deployment Method overlap

Attention: The situation around agreement closure is very tenuous. The deployment team
should be careful as they get involved before an agreement closes. They should work with
the sales team to understand what and how much information to share with the customer
while the agreement is still being resolved. They need to know what the controversial
issues are, if any. The sales team may say, “This customer wants to know everything about
deployment, including how much work is expected of them.” Or they may say, “This
customer just needs a high-level review now. Wait until the agreement closes before going
into detail.”

The advantage is that a Software Deployment Architect can be pulled into accounts
frequently to talk to customers about deployment and what to expect from IBM after
agreement closure. This discussion can reassure the customer that IBM will be with them on
their road to deployment success and value realization.

14 Optimizing Software Deployment: An Insider’s Guide

1.3.4 Software Deployment Method interaction with GSM and RUP
There are other methods and processes that can have an affect on software deployment and
should be reviewed. These are the IBM Global Services Method and the Rational Unified
Process® (RUP®).

The IBM GSM provides a single method to enable a common language among all
practitioners delivering business solutions. It is a fundamental component to accelerating
Global Services' shift to asset-based services. It provides a mechanism for practitioners to
reuse knowledge and assets using a consistent, integrated approach. For more information
on GSM, see the following Web site:
http://gcdserver1.endicott.ibm.com/methods/webapp/MethodWeb

The Rational Unified Process is a Web-enabled set of software engineering processes that
provides customers with guidance to streamline their team application development activities.
From this industry-wide process platform, customers can easily choose the set of process
components that are right for their specific project needs. They can achieve more predictable
results by unifying their teams with common processes that improve communication and
create a common understanding of all tasks, responsibilities, and artifacts. On one centralized
Web exchange, Rational, platform vendors, tool vendors, and domain experts provide the
specific guidance customers need to be successful. For more information on RUP, see
Appendix E, “Rational Unified Process” on page 141.

1.4 Work products overview

An awareness of the work products used and created by the Software Deployment Method is
helpful before you begin reading about the method in detail. For explanations of the work
products and examples, refer to Appendix A, “Work products: Usage and examples” on page
97.

1.4.1 Work products from SSM in the Software Deployment Method

The primary work product from SSM used in the Software Deployment Method is the
contract.

1.4.2 Work products from TeAM in the Software Deployment Method

TeAMethod produces several work products. The work products used in the Software
Deployment Method are:
򐂰 Architectural decisions document (ADD)
򐂰 Architecture overview diagram
򐂰 Business context diagram and description
򐂰 Component model
򐂰 Customer’s ID environment
򐂰 Customer’s organization
򐂰 Envisioned goals and issues
򐂰 IT standards
򐂰 Operational model
򐂰 Project descriptions
򐂰 System context diagram
򐂰 Use cases
򐂰 Viability assessment

Chapter 1. Introducing the Software Deployment Method 15

1.4.3 Work products produced by the Software Deployment Method
The work products and subwork products produced by the Software Deployment Method
include:
򐂰 Value Realization Model (VRM)
– Customer goals and milestones
– Gap analysis report
– Deployment milestone status report
– License utilization report
– ROI/ROR status report
򐂰 Deployment plan
– Account Planning
• High level mapping of business initiatives to deployment projects
• Documented linkages of deployment projects to SWG products
• Deployment services requirements
• Status of environment and infrastructure requirements
– Project Planning
• Deployment quick-win plan
• High level deployment plan
• Architecture plan
• Deployment plan findings
• Milestone status report
• Project controls
򐂰 Readiness Plan
– Communication plan
– Migration plan
– Education plan
– Architecture plan
– Operations plan
– Risks, dependencies, assumptions, and constraints

1.5 In summary
The result of poor deployment is that IBM misses opportunities to amend and renew too many
Enterprise Agreements. The Software Deployment Method described in this redbook was
created to add structure and discipline to software deployment and to show its recommended
relationship to the SSM and TeAM methods and work products. IBM recommends that
deployment teams follow the method as described, because it helps to ensure successful
deployments.

16 Optimizing Software Deployment: An Insider’s Guide

 2

Chapter 2. Roles and responsibilities

One of the many reasons customers do business with IBM is because we have so many
skilled professionals involved in the sale and deployment of software, hardware, and services.
The challenge when so many people are involved is to make sure that the IBM team knows
the roles (positions) and responsibilities (duties) of each other. It is also important that they
communicate this clearly and consistently to the customer team or teams.

A more common frustration expressed in deployment post mortems is that roles and
responsibilities were not clearly stated up front. Then, as deployment progressed, confusion
arose over who was supposed to perform certain tasks or when they would be done. An IBM
strength can become a liability if things are not communicated clearly or at all.

The basic foundation for deriving value from an Enterprise Agreement (EA) begins with the
basic steps of ensuring that the IBM team (shown in Table 2-1) and the customer team know
their own and each other’s roles. Who is supposed to do what? And when should they do it?
This chapter sets the stage for the remaining chapters of this redbook.

Table 2-1 Overview of IBM team roles

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

© Copyright IBM Corp. 2003. All rights reserved. 17

2.1 Software Sales Team
The Software Sales Team consists of the following members:
򐂰 Sales (non-technical)
– Software Account Manager (SAM): Cross brand selling and strategic
– Software Sales Specialist (SSS): Single brand and tactical
򐂰 Technical Sales Support (TSS)
– Technical Sales Manager (TSM)
– Software Architect (SWA): Cross brand selling and strategic
– Software Deployment Architect (SDA): Cross brand deployment
– Software Technical Sales Specialist (ITS): Single brand selling and tactical
򐂰 Bid Manager (also known as the Deal Maker in the Americas): Agreement creation and
contract negotiation

Note: Refer to Appendix B, “SAM, SWA, and SDA responsibilities” on page 125, which lists
the responsibilities of the SAM, SWA, and SDA (the three roles most actively involved in a
software deployment) in table form and provides a useful reference.

2.1.1 Software Account Manager

The Software Account Manager sells IBM software in selected large accounts or Small and
Medium Business (SMB) territories and builds customer relationships. SAMs formulate sales
strategies that apply IBM software strategies to their customers’ business strategies. SAMs
work with their customers to:
򐂰 Define a strategy for the account.
򐂰 Manage customer relationships and problems.
򐂰 Negotiate long-term software contracts.

Each SAM provides a single “sales face” to the customer across all software brands in their
assigned accounts.

The SAM’s responsibilities are to:

򐂰 Grow total software revenue at their assigned accounts.
򐂰 Increase IBM software market share at their assigned accounts by competitive winbacks.
򐂰 Build the mindshare at the account for IBM software by providing thought leadership
across all of IBM software pillars.
򐂰 Develop and present to the customer the IBM software strategy.
򐂰 Coordinate the IBM software team behind this strategy, including pillar sales and technical
specialists (Data Management, Lotus, Tivoli, WebSphere, and Rational).
򐂰 Increase customer satisfaction with IBM’s software solutions.
򐂰 Develop creative, winning tactics for large opportunities, such as pricing, packaging,
service offerings, and hardware offerings.
򐂰 Take a leadership role in all key software opportunities.
򐂰 Manage IBM’s software relationship with their customers.
򐂰 Provide consolidated forecasts for all software opportunities at their accounts.

18 Optimizing Software Deployment: An Insider’s Guide

2.1.2 Software Sales Specialist
The Software Sales Specialist sells a particular set (discipline) of IBM software and works
with SAMs, Software Technical Sales Specialists, and SWAs in doing so. They have
knowledge of IBM's 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.

Note: The primary IBM Software Group (SWG) brands are Data Management, Lotus,
Tivoli, WebSphere, and Rational.

2.1.3 Technical Sales Manager

The Technical Sales Manager directs the technical sales efforts of the technical sales
professionals (for example, a Software Architect, Software Deployment Architect, and
Software Sales Specialist) engaged in selling IBM software products in a specific discipline.
The TSM actively participates in opportunity management and is responsible for technical
coverage of sales or deployment opportunities. The TSM helps to ensure customer
satisfaction by executing the solution assurance process and participating in critical situation
management.

2.1.4 Software Architect

Using the entire IBM software portfolio as a palette, the Software Architect paints
comprehensive technical solutions that solve the customer’s current and future business and
IT challenges while maximizing IBM software revenue. These comprehensive technical
solutions demonstrate that IBM software is more than the sum of its individual brand parts,
position IBM as a technology leader, and generate additional revenue.

Software Architects are valued because they first listen to the customer and then analyze the
customer's business and IT challenges. Next they design a comprehensive solution that
integrates smoothly into the customer’s context and that leverages the best of the entire IBM
software portfolio. The Software Architect’s responsibilities are to:
򐂰 Grow total software revenue at assigned accounts.
򐂰 Work with the account team and the customer to translate the customer's business vision
into a specific technical design.
򐂰 Develop plans to prove or implement the technical design by coordinating the efforts of
other members of the software sales and services teams.
򐂰 Help generate new opportunities by building relationships with key technical decision
makers.
򐂰 Direct the technical activities necessary to design and implement a solution.
򐂰 Create strong relationships with key technical decision makers.
򐂰 Focus on a technical strategy for their customer’s company rather than on specific
products or tactical implementation issues.
򐂰 Use tools, such as IBM Framework for e-business to articulate the capabilities of IBM
software.
򐂰 Help customers develop the strategy and vision for their IT systems and shape this vision
into a specific technical design.
򐂰 Exercise a repeatable, documented, and auditable design method.

Chapter 2. Roles and responsibilities 19

 򐂰 Lead the analysis and design project phases by employing accepted design methods,
patterns, and best practices.
򐂰 Understand how each IBM software product compares and integrates with other products
from IBM and our competition.
򐂰 Exploit knowledge of the IBM software portfolio to select the best product combination for
the architectural design.
򐂰 Use knowledge of customer's abilities to systematically recommend appropriate education
and services.
򐂰 Organize and lead the balance of the IBM team around the design.
򐂰 Retain an active role in the solution assurance and implementation of the design after the
sales transaction is complete.
򐂰 Harvest and share reusable intellectual capital.
򐂰 Support the Software Deployment Architects when they discover additional
post-transaction projects that require comprehensive technical solutions.
򐂰 Use technical and business acumen to win and maintain the respect and relationship with
key customer decision makers.
򐂰 Build relationship networks with knowledge sources inside and outside of IBM, and
leverage those relationships to solve customer challenges quickly.
򐂰 Investigate new software technology and design methods to proactively educate our
customers.
򐂰 Help to ensure work products are documented and transferable to other technical
professionals.

2.1.5 Software Technical Sales Specialist

Employing a technical understanding of the capabilities of a product set, the Software
Technical Sales Specialist evangelizes and advocates IBM products to technical decision
makers. The ITS cultivates the technical sale to maximize IBM revenue. By accessing and
maintaining a clear channel to customer technical decision makers, the ITS can:
򐂰 Create new revenue opportunity.
򐂰 Champion brand image.
򐂰 Position IBM as the leader in providing software solutions that meet the customer’s
technical challenges.

Using their technical knowledge and proven experience, the ITS provides a bridge between
the customer's technical challenges and potential product solutions.

The responsibilities of the Software Technical Sales Specialist are to:

򐂰 Build and maintain a technical understanding of product capabilities.
򐂰 Understand the customer's technical infrastructure and use this knowledge to identify
potential new opportunities.
򐂰 Use relationships with technical decision makers to generate new opportunities.
򐂰 Proactively create a technical product vision in the mind of a technical decision maker.
򐂰 Understand product positioning against the competition.
򐂰 Technically qualify the customer as part of the solution sale.
򐂰 Engage additional resources to turn the technical vision into a design.
򐂰 Engage sales resources to price and close the sale.

20 Optimizing Software Deployment: An Insider’s Guide

 򐂰 Manage the Solution Assurance Review process.
򐂰 Maintain a broad knowledge of IT organization structure and IT business complexities.
򐂰 Help to ensure work products are documented and transferable to other technical
professionals.

2.1.6 Software Deployment Architect

The Software Deployment Architect accelerates deployment of software solutions and
designs additional technical solutions that leverage the entire IBM SW portfolio to resolve a
customer’s business and IT challenges. The SDA employs technical knowledge and sales
abilities to help customers successfully deploy their Enterprise Agreement software. When it
goes well, deployment typically culminates in the customer renewing the Enterprise
Agreement.

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

The responsibilities of the SDA are to:

򐂰 Lead the design and deployment of technical software solutions by leveraging design
methods, patterns, and best practices.
򐂰 Select 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 how IBM's offerings compare, contrast, and integrate with the customer's
existing software investment from IBM, business partners, and the competition.
򐂰 Maintain an active role in solution assurance before and after agreement closure to help
ensure action items are closed and risks are mitigated.
򐂰 Use technical and business acumen to build and maintain influential relationship with key
customer and IBM decision makers.
򐂰 Build relationship networks with knowledge sources inside and outside of IBM and
leverage those relationships to avoid technical inhibitors to solution deployment.
򐂰 Help to ensure that the customer understands and actively takes steps to adhere to IBM
SWG deployment best practices.
򐂰 Help to ensure work products are documented and transferable to other technical
professionals.
򐂰 Harvest and share reusable intellectual capital and deployment experiences.
򐂰 Help to ensure software does not become shelfware.

2.1.7 Bid Manager

The Bid Manager designs and coordinates Enterprise Agreement packages (pricing,
contracts, etc.) and serves as the primary interface to IBM pricing, legal, accounting, and IBM
Global Finance. The Bid Manager helps to ensure that the pricing principles offered are

Chapter 2. Roles and responsibilities 21

 consistent, profitable, and viable. They also assist the SAM with strategy and implementation.
The Bid Manager negotiates the final contract with the customer.

2.2 Client Team

The Client Team includes the following members:
򐂰 Client Executive
򐂰 Client Representative
򐂰 Client IT Architect
򐂰 Managing Director (integrated accounts only)

2.2.1 Client Executive

The Client Executive builds a long-term business relationship with the client by identifying
IBM opportunities and developing 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 SAM to drive software
sales and partners with sales and technical specialists in hardware and services to drive
respective sales.

2.2.2 Client Representative

The 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
򐂰 Helps ensure overall client satisfaction

The Representative manages IBM opportunities while guiding the development of the
solution and support strategies. They partner with the SAM to drive software sales and
partners with sales and technical specialists in hardware and services to drive respective
sales.

2.2.3 Client IT Architect

The Client IT Architect has a role that is similar to that of the SWA and SDA. The CITA has IT
responsibility for the entire IBM relationship with the customer, including hardware, software,
and services. The strong relationship between the CITA and the software technical team is
critical.

2.2.4 Managing Director

The Managing Director has overall responsibility for the global relationship within the account,
including responsibility for profitability.

22 Optimizing Software Deployment: An Insider’s Guide

2.3 Customer’s Enterprise Business Sponsor
The Enterprise Business Sponsor represents the customer and takes ownership for software
deployment throughout the enterprise. This sponsor should commit to the following
responsibilities:
򐂰 Develop the internal vision for promoting the maximum usage 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.

The Signature Selling Method refers to the “power sponsor” as the key customer
representative. To avoid confusion with the power sponsor, it is important to clarify that the
Enterprise Business Sponsor and the power sponsor may, in some accounts, be the same
person. However in other accounts, the person who works to close the Enterprise Agreement
(power sponsor) is not responsible for deployment milestones (Enterprise Business Sponsor).
In this book (and when describing the Software Deployment Method), we refer to the
deployment owner as the Enterprise Business Sponsor.

2.4 Team IBM

When leveraged properly, Team IBM can be a tremendous asset to SWG and the customer.
Their wealth of knowledge and experience is unmatched in the IT industry. Their customer
knowledge goes far beyond the scope of the software that is being deployed. Team IBM
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 Sector and Integrated Accounts. Leveraging
such a diverse team can enhance and sometimes complicate the software deployment
process.

Almost every Enterprise Agreement requires the participation of multiple organizations.

Common examples are IBM Global Services for implementation support, IBM Global
Financing for financial assistance, and the System Group for the required servers and
storage. The sales prospects are enhanced if these organizations, and IBM Software Group,
define early on a common sales strategy and approach the customer as Team IBM.
Conversely, the sales prospects are diminished if these organizations operate independently.

Software Group can also leverage Team IBM when working on an EA with a new IBM
Software customer. If another IBM organization already has active business with the
customer, it can provide IBM Software Group with appropriate leads or introductions and
advice or guidance. Also, if Software Group sees an opportunity for other IBM business, it can
solicit the appropriate IBM group to partner in addressing that opportunity.

Team IBM sales incentives are listed on the Web at:

http://w3-1.ibm.com/hr/global/salesincentives/americas/challenges.html

Chapter 2. Roles and responsibilities 23

24 Optimizing Software Deployment: An Insider’s Guide
 3

Chapter 3. Software Deployment Phase 0:

Preparing for deployment
The overall purpose of the preparing for deployment phase is for IBM and the customer to
build the groundwork required for successful deployment. As shown in Figure 3-1, the
preparing for deployment phase consists of the following activities:
򐂰 DM 0: Create the Software Deployment Team (SDT)
򐂰 DM 1: Review the deployment documentation
򐂰 DM 2: Develop a high-level deployment plan
򐂰 DM 3: Establish a deployment partnership with the customer

Create software deployment team (DM 0)

Qualified

Review documents (DM 1)

Deploy-
Won

Develop high-level plan (DM 2)

ment
Establish deployment partnerhsip with
customer (DM 3)

Phase 0 Prepare Phase 1 Kickoff Phase 2 Execute

Figure 3-1 Phase 0: Preparing for deployment

© Copyright IBM Corp. 2003. All rights reserved. 25

3.1 DM 0: Create the Software Deployment Team
The purpose of this activity is to form the team that will plan and lead the software
deployment. The team is called the Software Deployment Team. Figure 3-2 shows DM 0 in
relationship to the other steps in the Signature Selling Method (SSM) and Software
Deployment Method (SDM).

SSM & SDM Interlock:DM0

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

80% Closure 2
Possibility Engage
Software Development
Team
1

DM0 Define Software

SSM 5 Develop 0 Development Team (SWG
Solutions (60-70%) and Client Team)

Deployment Methodology SSM & Team Time

Figure 3-2 DM 0: Create the Software Deployment Team

3.1.1 Owner and participants

The responsible owners are the Software Account Manager (SAM), Managing Director, or
Client Executive, and Technical Sales Manager (TSM).

Note: There is likely to be more than one Technical Sales Manager involved. This may
include the TSM for the Software Deployment Architect, the TSM for the Software Architect
(SWA), and the TSM for the Software Technical Sales Specialists who will be selected for
the SDT.

The participants are the same as the owners.

3.1.2 Input, tasks, and output

Figure 3-3 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, refer to Appendix A, “Work products: Usage and examples” on page 97.

26 Optimizing Software Deployment: An Insider’s Guide

 Inputs Tasks Outputs
Need or requirement Create a Software Deployment Results
to form team Team that includes the Software deployment team
following representatives: established.
Software Account Manager Team members understand
Software Technical Sales their roles and are
Specialists committed to the team's
Software Architect purpose and goal or goals.
Software Deployment Architect
Services representative
Get commitment from each
member to serve.
Communicate roles and
expectations.

Figure 3-3 Inputs, tasks, and outputs for DM 0: Create the Software Deployment Team

3.1.3 Benefits
The benefits of this activity are that the SDT is established, the team members understand
their roles, and they accept ownership for the customer’s deployment success. Also, the
Client Team and software managers commit the resources that are necessary to realize the
customer’s deployment goals.

3.2 DM 1: Review the deployment documentation

Figure 3-4 shows DM 1 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM1

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM1 Review deal content and critical deployment

documents (SWG Team)
80% Closure 2
Possibility Engage Identify the customer’s Enterprise Business Sponsor (EBS)
Software Development Discuss the customer buying decision. Clarify expectations
Team
and goals
1
Determine if any Solution Assurance Reviews (SAR) are
required
SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 3-4 DM 1: Review the deployment documentation

Chapter 3. Software Deployment Phase 0: Preparing for deployment 27

 During this activity, the SDT reviews such documents as the contract, business content
diagram, requirements, and solution concepts. The purpose of this activity is to obtain a
common understanding among the SDT of the critical documents (business and software
architecture) that will be used in the deployment process. The team should have a common
understanding of why the customer purchased the EA. What was the purpose of signing a
contract of this size with these products?

At this point, it is critical to obtain a preliminary view of how the customer defines success and
what value they expect to achieve from the agreement. The SDT should keep this definition in
mind for the entire deployment process and discuss it with the customer so they don’t lose
sight of the end goals.

The deployment team should thoroughly understand the content, terms, and conditions of the
contract. Typically it contains much standard terminology. But because each agreement is
unique, the contract will have sections and language that apply only to a specific sale. The
deployment team should know the customizations and how they affect the agreement. If there
are things they don’t understand, they should ask the sales team.

3.2.1 Owner and participants

The owners are the SAM, Software Architect or Software Deployment Architect, and the Bid
Manager.

The participants include the Software Group (SWG) Team. All members of the SDT are
mandatory.

3.2.2 Input, tasks, and output

Figure 3-5 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, refer to Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

Discuss the customer's buying decision. Work products
SSM
Help ensure that the content, terms, and conditions List of open items for enterprise
Draft contract of the contract are thoroughly understood. contract
Integrated solution concept Analyze software inventory and licensing. Introduction plan
TeAM Study substitution clauses. Updated viability assessment
Customer requirements/ Understand the status of maintenance and support. Draft goals and milestones
use cases
Discuss any expectations that may have been set document
Business context diagram (primarily from the Enterprise Business Sponsor). High-level mapping of business
and description
Identify any critical relationships and establish an initiatives to projects
System context diagram introduction plan. Draft mapping of projects to
Conceptual architecture Discuss the content of deployment methodology to products
Architectural decision help ensure that each member of the account team Initial software utilization report
document (ADD) understands how the deployment phase will be
Initial viability assessment executed to maximize success.
Current organization Discuss license tracking and how the customer
IT standards should plan to track deployment progress.
Current IT environment Review the requirements, solution concept,
Project description business context, conceptual architecture, and
architecture decision document.
Review/refine the initial viability assessment (which
includes results of a Solution Assurance Review
(SAR), if one was conducted). This equates to an
SDT confirmation of the solution.
Considering the customer's business initiatives,
document the linkages between deployment
projects and products.
Identify who should be involved in the next activity,
DM 2.

Figure 3-5 Inputs, tasks, and outputs for DM 1: Review the deployment documentation

28 Optimizing Software Deployment: An Insider’s Guide

3.2.3 Benefits
The benefits that result from this activity are:
򐂰 The SDT has a common understanding of the business vision.
򐂰 The SDT agrees that the conceptual solution is viable.
򐂰 The customer owner is identified.
򐂰 The SDT confirms the roles and responsibilities of the customer and IBM.
򐂰 There is an awareness that the preparation phase of deployment has begun.
򐂰 The SDT concurs with the viability assessment.
򐂰 Participants in the next deployment activity, DM 2, are identified.

3.2.4 Document review tips

Follow these tips for reviewing the deployment documentation:
򐂰 Analyze the software in the inventory. Typically, the customer owns IBM software
already from a previous agreement. Now they are a repeat customer. There may be new
products that are purchased that were released recently or that the customer didn’t
purchase in previous agreements. It is important point do a sanity check between what
they already own and what they are purchasing. Where do we stand with what they
already own? Perform checks and balances and compare what they have with what will be
new.
򐂰 Understand substitution clauses. Enterprise Agreements substitution clauses are
generally standard. However, in some cases, the sales team customizes the verbiage to
streamline agreement closure. It is imperative that the deployment team can explain the
reasons for the customized verbiage to the customer. Substitution is not straightforward
and often many products are not eligible. For example, a customer often cannot exchange
outside a specific product family (such as WebSphere for Tivoli or Data Management for
Lotus). Understanding the substitution rules avoids turning a difficult conversation into a
customer satisfaction issue.
򐂰 Understand the status of support and maintenance. The customer may have had
maintenance explained in an old contract. Now they have new maintenance included in a
new agreement. Determine which products are supported and who in the account is
eligible to receive the support. If there are support differences from the last contract to this
one, make sure the customer is aware of them. If new employees in the account need
support eligibility, be sure that they receive it. Also, look ahead as the new solution is
defined to forecast who may need eligibility down the road.
򐂰 Be aware of any global support issues. An example of a potential global support issue
is when a contract is signed in the United States, but all or some of the software is
installed at customer sites in Europe. In this example, the sites in EMEA require IBM
support and potentially they are not eligible. It is best to help ensure that these situations
are addressed early. Otherwise this can cause a great deal of frustration later when trying
to resolve a situation reactively. For more information about global deployments, see
Chapter 7, “Managing global software deployment” on page 57.
򐂰 Identify the Enterprise Business Sponsor. Early in the deployment process, it is
important to identify the customer’s Enterprise Business Sponsor. This is the person
whose career hangs in the balance if the EA does not deliver as promised. The sponsor
should think the EA has business value and can clearly explain the reasons why the
products included are needed at this time. In SSM, this person is referred to as the “power
sponsor”. However, be sure that this sponsor is responsible for deployment and not just for
closing the financial agreement. A financial sponsor may not likely be involved after
agreement closure.

Chapter 3. Software Deployment Phase 0: Preparing for deployment 29

 The sales team has been in the account for some time and should know the Enterprise
Business Sponsor. The sales team should introduce deployment team to this person. At
this meeting, begin to introduce the deployment methodology and the software
deployment best practices. This helps ensure that the sponsor understands all that is
required after agreement closure to help ensure that the EA has the best chance of
succeeding.
򐂰 Be proactive. Through all of the above activities, the deployment team should be
proactive. The Software Sales Team and the Client Team are readily available during the
time of agreement closure. This provides the perfect opportunity to gain their attention.

3.3 DM 2: Develop a high-level deployment plan

Figure 3-6 shows DM 2 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM2

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
DM2 Develop high level deployment plan 10
(SWG and Client Team)
80% Closure Define deployment road map in “big chunks”, maximize
2
license usage over time
Possibility Engage
Software Development Develop internal understanding of customer’s deployment
Team readiness
1
Determine deployment services requirements cross brand
(for example, SmartStart)

SSM 5 Develop 0
Leverage existing plans and client team to kick off SWAP
and populate customer profile
Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 3-6 DM 2: Develop a high-level deployment plan

The purpose of this activity is to take the high-level mapping of products to projects to a lower
level of detail and assign ownership at a project level. The high-level deployment plan:
򐂰 Defines a list of initial deployment projects
򐂰 Identifies a customer sponsor and owners for known projects
򐂰 Groups deployment into logical chunks
򐂰 Contains a deployment timeline
򐂰 Includes a services assessment

This plan should also define ownership (including a customer sponsor and an IBM owner) of
core infrastructure projects that are required for the implementation and maintenance of the
specific business oriented projects. Some examples include License Management, Problem
Management, Configuration Management, Performance and Availability Management,
Security, and Storage Management.

30 Optimizing Software Deployment: An Insider’s Guide

These types of projects, whether based in software or manual procedures, must be
implemented before large scale roll-outs of the line-of-business projects can occur. Early
identification of ownership is critical because it provides the needed focus for these complex
projects. It ensures that they are implemented in a common manner across the entire
customer, minimizing the cost and effort.

Ideally, a customer buys software based on need. Unfortunately with an Enterprise

Agreement, this is not always the case. In some cases, the customer justifies the purchase of
software based on projected need. In other cases, the customer buys simply because they
received an attractive discount. Sometimes when the agreement closes, the customer does
not have a plan for when and where the software will be deployed. Hopefully the customer
has a set of goals in mind for the software they are purchasing and these goals map to
potential projects.

When the agreement closes, these projects drive deployment activity. The SDT should begin
creating the project list before the agreement closes. This is when the key players are still at
the account and knowledge is available. (See Appendix A, “Work products: Usage and
examples” on page 97, which contains an example of a spreadsheet that has been used to
track projects.) List the following items:
򐂰 All the potential projects
򐂰 The brands that 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. For example, the list may contain 60 projects with 60 owners who are
going to deploy 100 products over the next three years. The projects identified at this point in
the method may not likely burn the entire EA software inventory, but it starts things moving
and generates momentum and demand for incremental license usage.

The Software Sales Team should help the deployment team identify projects that were built
into the contract to generate the demand for it. Note that there are several major brands within
IBM (Tivoli, Lotus, Data management, WebSphere, and Rational). Each one typically has
sales and technical sales people assigned to the account. The sales team for each brand is
focused on generating demand and creating potential projects. The SDT’s challenge is to
work with these teams to determine:
򐂰 The revenue that is allocated to each brand
򐂰 The projects that are involved
򐂰 The software that is included in each project
򐂰 The owners of each project
򐂰 The start and end dates
򐂰 The numbers of licenses purchased

The sooner this information is obtained, the better.

The Software Architect helps ensure that integration, where and when it needs to occur, is
executed smoothly. Keep in mind that some projects are independent. For example, a DB2®
online analytical processing (OLAP) project typically integrates only with other database
products.

Finally, an important metric for software deployment is:

Contract inventory = deployed products + forecasted deployed products + gap

Chapter 3. Software Deployment Phase 0: Preparing for deployment 31

3.3.1 Owner and participants
The owner is the Software Architect or Software Deployment Architect. The participants are
the SWG and Client Teams. All members of the SDT are mandatory.

3.3.2 Input, tasks, and output

Figure 3-7 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, see Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

SSM Conduct introductory meetings with the customer Work products
Introduction plan per the introduction plan. Updated goals and milestones
TeAM Validate/refine the goals and milestones document document
Viability assessment with Enterprise Business Sponsor. High-level phased deployment
Architectural decision Group deployment into logical "chunks" based on plan
document (ADD) business initiatives; assign owner to each Detailed mapping of products to
initiative. projects to business initiatives
Solution architecture,
Refine the list of projects created in DM1 and Services requirements
including architecture
assign customer ownership.
overview document
Create a high-level deployment timeline, a phased
Component model Initial readiness plan findings
execution plan for building the entire solution.
Internal interface Assess services requirements needed to achieve Gap analysis report
descriptions deployment goals. Environment and infrastructure
SDM Create a first-cut readiness plan using the requirements
Goals and milestones high-level deployment plan and other information Updated license utilization
document about the customer. report
Software deployment best Assess the need for infrastructure management Customer profile document
practices projects or software not already identified (for
High-level mapping of example, problem management, storage
business initiatives to management, change control, etc).
projects Review the high-level Deployment Plan and
Draft mapping of projects Readiness Plan with the IBM extended team.
to products Check adherence to Solution Assurance Review
Initial license utilization policies.
report Review the initial license utilization report and
Readiness plan template proposed content of the enterprise contract
against the deployment plan to understand any
impact to the rate of return (ROR).
Determine the gap between products with defined
projects and products that require project
definition after agreement closure.
If not previously started, kick-off the SWAP
initiative and create a customer profile.

Figure 3-7 Inputs, tasks, and outputs for DM 2: Develop a high-level deployment plan

3.3.3 Benefits
The main benefit of this activity is that the Client Team and SWG Team come to agreement on
various aspects of deployment and deployment readiness. Other benefits include:
򐂰 A high-level deployment plan mapped to projects and products is established.
򐂰 Deployment services requirements are considered and drafted for review with the
customer.
򐂰 The customer’s deployment readiness is considered and drafted for review with the
customer.
򐂰 A software deployment gap analysis is completed.

32 Optimizing Software Deployment: An Insider’s Guide

3.4 DM 3: Establish a deployment partnership with the
customer
Figure 3-8 shows DM 3 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM3

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
DM3 Establish deployment partnership with 10
EBS (IBM and customer)
80% Closure Affirm buying decision. Record goals and
2
expectations of EBS
Possibility Engage
Software Development Identify short term quick deployment wins and
Team ROI strategy
1
Present Readiness Plan and SW Deployment Best
Practice findings

SSM 5 Develop 0
Schedule deployment kick-off meeting. Discuss
participants
Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 3-8 DM 3: Establish a deployment partnership with the customer

The purpose of this activity is to solidify the customer and IBM partnership and to help ensure
that both groups realize that the customer is ultimately responsible for the deployment. During
this activity, the SDT partners with the customer to identify quick wins (that are technically
proof points) and define critical success criteria. They agree on roles and responsibilities and
introduce SW Deployment Best Practices and the Readiness Plan. They agree on the
high-level deployment plan created in the previous activity and determine deployment
services.

The SDT should meet with the Enterprise Business Sponsor, present their roles, and
establish themselves as partners focused on the success of the Enterprise Agreement. It is
important for the sponsor to understand why the deployment team is involved, what they will
do in the account, and what the customer should expect from them.

3.4.1 Owner and participants

The owners include the Enterprise Business Sponsor and all members of the SDT.

The participants include the Enterprise Business Sponsor, SWG and Client Team members,
as well as key customer stakeholders.

Chapter 3. Software Deployment Phase 0: Preparing for deployment 33

3.4.2 Input, tasks, and output
Figure 3-9 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, refer to Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

Updated goals and Confirm customer's buying decision and vision. Work products
milestones document Identify short-term quick wins. Revisions to architecture plans
High-level phased Define milestones and metrics. if needed
deployment plan Review gap analysis and determine a strategy to Deployment quick-win plan
Detailed mapping of minimize the gaps. Updated goals and milestones
products to projects to Review and discuss political, cultural, and faction document
business initiatives roadblocks that could impact deployment. Results
Services requirements Validate critical players on the customer's team. Validated high-level phased
document Communicate and jointly agree to roles and deployment plan
Initial readiness plan responsibilities of IBM team, customer team, and Validated detailed mapping of
findings deployment services. products to projects to business
Gap analysis report Introduce software deployment best practices and initiatives
Environment and the Readiness Plan to the sponsor and discuss Validated gap analysis report
infrastructure an assurance plan.
Validated readiness plan
requirements Review outputs from activity DM 2. findings
Updated license Validate project leads within the account who will Software deployment best
utilization report assist the customer owner with deployment. practices findings and actions
Identify any challenges or risks to deployment. Validated environment and
Identify prerequisites and dependencies that must infrastructure requirements
be met prior to deployment start. Validated services
Schedule date for kickoff meeting and determine requirements document
who should participate in it. Validated license utilization
report
Kick-off meeting scheduled

Figure 3-9 Inputs, tasks, and outputs for DM 3: Establish a deployment partnership with the customer

3.4.3 Benefits
The benefits that result from this activity are:
򐂰 A partnership with the customer is established.
򐂰 An agreement is established regarding software deployment ownership.
򐂰 The customer owner agrees to the high-level deployment plan.
򐂰 There is agreement on the customer’s staffing strategy (where outsourcing will be used,
for example).
򐂰 There is agreement on the plan to address best practices and deployment readiness
concerns.
򐂰 A kickoff meeting is scheduled.

34 Optimizing Software Deployment: An Insider’s Guide

 4

Chapter 4. Software Deployment Phase 1:

Conducting the deployment
kickoff
The conducting the deployment kickoff phase begins (ideally) after the sales closes and the
contract is final. Its purpose is to help ensure that the Software Deployment Team (SDT)
understands the final contract and final versions of other input used in Phase 0, to fully
engage the customer in the deployment plans, and to conduct the deployment kickoff. As
shown in Figure 4-1, conducting the deployment kickoff consists of the following activities:
򐂰 DM 4: Refine the deployment plan
򐂰 DM 5: Finalize the deployment plan
򐂰 DM 6: Conduct the deployment kickoff meeting

Refine deployment plan (DM 4)

Qualified

Deploy- Finalize deployment plan

Won

ment with customer (DM 5)

Conduct deployment kickoff
meeting (DM 6)

Phase 0 Prepare Phase 1 Kickoff Phase 2 Execute

Figure 4-1 Phase 1: Conducting the deployment kickoff

© Copyright IBM Corp. 2003. All rights reserved. 35

4.1 DM 4: Refine the deployment plan
Figure 4-2 shows DM 4 in relationship to the other steps in the Signature Selling Method
(SSM) and Software Deployment Method (SDM).

SSM & SDM Interlock: DM4

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM4 Refine deployment plan (IBM

80% Closure 2 revisit step 1 and 2)
Possibility Engage
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 4-2 DM 4: Refine the deployment plan

The purpose of this activity is to revise the architecture and deployment plans to reflect any
changes caused by contract modification. During this activity, the SDT reviews again all input
(for example, the contract, and list of deployment projects and owners) to deployment steps
DM 1 and DM 2 to determine if anything has changed. The team also completes a thorough
review of the requirements, architecture, components, interfaces, and any performance
modeling that was done. A key output from this activity is a refined deployment plan.

In activity DM 2 of the deployment method, a list of potential projects and owners is created.
At this point in the method, after the agreement closes, the deployment team meets with the
sales team and Enterprise Business Sponsor and finalizes that list. They should check for any
last-minute additions or deletions.

Some projects may be defined in sufficient detail to perform deployment planning at this time.
For these projects, the SDT, led by the Software Deployment Architect (SDA) or Software
Architect (SWA), works with the customer to perform any necessary capacity and
performance modeling. They produce a recommended physical production architecture and
associated physical architecture and define or refine hardware and software requirements.
They also discuss environmental and infrastructure requirements for deployment and conduct
a solution assurance review, if called for.

If deployment began as recommended (when the agreement was 60% to 80% complete), at
this point in the cycle, the Enterprise Agreement should have officially closed. Now is the time
to perform a final review of the contract:
򐂰 Check for any last minute changes that may have occurred before the agreement closed.
򐂰 Resolve any outstanding questions that may have arose.

36 Optimizing Software Deployment: An Insider’s Guide

 򐂰 Identify any critical relationships.
򐂰 Establish an introduction plan.

With this step, the majority of the planning for successful deployment of the software is
completed. Good planning leads to a smooth deployment.

4.1.1 Owner and participants

The owner is the Software Architect or the Software Deployment Architect. The participants
include all members of the Software Group (SWG) Team (this is mandatory).

4.1.2 Input, tasks, and output

Figure 4-3 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, refer to Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

SSM Review the output of activities DM 2 and DM 3 Work products
Signed (final) contract with IBM members of the SDT. Be sure to Refined physical deployment
provided by the Software emphasize any areas of concern that weren't architecture, including
Account Manager (SAM) appropriate for discussion with the customer in operational model
SDM DM 3. Refined deployment and
Architectural overview Perform any performance and capacity modeling systems management plans
Component descriptions necessary. Updated environment and
Internal interface Produce a recommended physical production infrastructure requirements
descriptions architecture and associated physical Proposed (draft) project
Business initiatives architecture. controls
Revisions to architectual Refine hardware and software requirements. Updated readiness and
plans Match the software requirements to the contract quick-win plans
entitlement and determine licenses that are not
Validated high-level
allocated to projects (shelfware).
phased deployment plan
Discuss environmental and infrastructure
Validated detailed
requirements for deployment, incuding overall
mapping of products to
systems management strategy, whether based
projects to business
on software or manual processes/procedures.
initiatives
Determine whether a deployment assurance
Deployment quick-win plan
review (self, peer, or expert) is required.
Goals and milestones Execute as appropriate.
document
Create a draft of project controls (ownership
Software deployment best shared with project manager).
practices findings and
Update the readiness and quick win deployment
actions
plans.
Validated services
requirements document
Validated readiness plan
findings

Figure 4-3 Inputs, tasks, and outputs for DM 4: Refining the deployment plan

4.1.3 Benefits
The benefit of this activity is that the SDT revisits and refines the deployment strategy to
incorporate changes that occurred during final contract negotiations.

Chapter 4. Software Deployment Phase 1: Conducting the deployment kickoff 37

4.2 DM 5: Finalize the deployment plan
Figure 4-4 shows DM 5 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock:DM5

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM5 Finalize plan with customer

80% Closure 2
Possibility Engage Revisit DM3 with EBS
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 4-4 DM 5 - Finalize the deployment plan

The purpose of this activity is to obtain the customer owner's agreement with the final
deployment plan for projects where the preceding activities are completed. During this
activity, the SDT and the customer review all input to DM 3 and agree on project controls. This
activity is repeated as additional projects are developed and progress to this point in the
Software Deployment Method.

4.2.1 Owner and participants

The owners are the Enterprise Business Sponsor, Software Architect or Software
Deployment Architect.

The participants include the Enterprise Business Sponsor, critical customer stakeholders,
and all SDT members.

4.2.2 Input, tasks, and output

Figure 4-5 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, refer to Appendix A, “Work products: Usage and examples” on page 97.

38 Optimizing Software Deployment: An Insider’s Guide

 Inputs Tasks Outputs
TeAM Finalize the deployment plan with the customer. Workproducts
Refined physical Discuss the appropriate migration strategy. Final deployment architecture
deployment architecture, Final physical architecture
Discuss (and confirm the existence of) the
including operational model
appropriate conceptual data model (legacy data) if Final operational model
SDM necessary (ownership shared with data architect). Final deployment plan
Refined deployment and Finalize the physical architecture and operational Final systems management plan
systems management model.
plans Final project controls
Finalize the systems management plan Final deployment quick-win plan
Updated environment and
Agree upon project controls with the customer Final goals and milestones
infrastructure requirements owner.
Proposed (draft) project document
Complete the Readiness Plan (as appropriate). Readiness plan
controls
Update the quick-win plan. Results
Updated readiness and
quick-win plans Finalize project ownership with the customer. Customer approval of
Software deployment best Finalize software deployment milestones and workproducts
practices metrics. Best practices understood and
agreed upon

Figure 4-5 Inputs, tasks, and outputs for DM 5: Finalizing the deployment plan

4.2.3 Benefits
The benefit of this activity is that the customer agrees with deployment strategy modifications
that resulted from the final contract negotiations.

4.3 DM 6: Conduct the deployment kickoff meeting

Figure 4-6 shows DM 6 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM6

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM6 Conduct deployment kick-off

80% Closure 2 meeting (IBM and Customer
Possibility Engage Stakeholders)
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 4-6 DM 6: Conduct the deployment kickoff meeting

The purpose of this activity is to market and communicate the deployment plan (and vision) to
all current and potential users within customer environment. This typically is done in the form

Chapter 4. Software Deployment Phase 1: Conducting the deployment kickoff 39

 of a meeting attended by the IBM team and customer stakeholders (team project leads, IT
leads, and lines of business leaders). It is imperative that all key leaders attend. The kickoff
meeting should create awareness, understanding, and enthusiasm for the deployment that is
about to begin.

The peak of deployment intensity should occur here at step 6 with a kickoff meeting. This
meeting should include the Enterprise Business Sponsor or Sponsors, all customer project
leads, all of the IBM people (the Client Executive, Software Account Manager (SAM), SWA, IT
specialist, brand people), and all of the customer’s counterparts to the IBMers.

Plan and conduct a meeting (many may need to participate via teleconference) where you
discuss:
򐂰 What was purchased in the Enterprise Agreement
򐂰 Why it was purchased
򐂰 The deployment plan
򐂰 The deployment schedule

Cover hardware, software, and services where applicable. At this meeting, the Enterprise
Business Sponsor should present their success criteria. The deployment team should present
the best practices described earlier in this redbook. Discuss roles and responsibilities (see
Chapter 2, “Roles and responsibilities” on page 17) too.

Dozens of people may attend this meeting. Your goal is to inform the participants and to
create excitement and energy for the deployment. This is something that we don’t do very well
today. An example of how to generate some excitement is to contact Software Group
Marketing. They have program tools such as “architecting e-business” and “e-business live”
that you can use to communicate the right points to the customer’s team. They have the ability
to take the suite of products the customer purchased, incorporate the customer’s strategy,
and present the result in a very marketing way, customized to the customer’s situation. When
the customers see how the products can come alive and solve their needs, their enthusiasm
and buy-in increases. The Software Group Marketing home page is on the Web at:
https://w3.ibm.com/software/marketing

Kickoffs happen in various forms today. A kickoff meeting may be initiated by the hardware
team which doesn’t necessarily address the software details. There may be a kickoff meeting
that includes only the executive team or the top-level customers with the top-level IBMers.
The advice here is to conduct a kickoff that includes as wide a range of people as possible,
including the end users of the software products. They have much to do with the ultimate
success of the deployment.

The kickoff meeting is a good opportunity to further demonstrate how the Enterprise
Agreement (EA) contributes to the IBM On Demand Software Strategy. The team at this
session plays a critical role in the planning required to achieve on demand goals. This
meeting can be led by the SAM, SWA, SDA, or a Software Group Marketing guest speaker.

4.3.1 Owner and participants

The owner is the Enterprise Business Sponsor, SAM, Software Deployment Architect or
Software Architect.

The participants include the Enterprise Business Sponsor, key stakeholders from the
customer, and the SWG and Client Team members from IBM.

40 Optimizing Software Deployment: An Insider’s Guide

4.3.2 Input, tasks, and output
Figure 4-7 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, see Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

SSM Present the vision that drove the Results
Final contract purchase (Enterprise Business Sponsor). Synergy and enthusiasm for
TeAM Link IBM brands/products that were the upcoming deployment
Architecture plans and purchased to the vision. High-level understanding of
descriptions Go through the contract (high points, the contract terms and
SDM terms and conditions, product quantity, conditions
High-level deployment plan timings, and critical aspects). Communicated vision and
Communicate business value and business value
Goals and milestones document
Software deployment best benefits. Understanding of roles and
Show business context and high-level responsibilities, deployment
practices architecture plan. ownership, and software
Present high-level deployment plan (from deployment best practices
activity DM2 and refined in activity DM4). List of follow-up items from
Discuss breadth of deployment (local, the meeting
regional, national, or global).
Discuss roles and responsibilities of IBM
and customers (emphasize deployment
ownership).
Discuss the players, politics, and factions
(IBM and customer). Share the plan for
overcoming or avoiding potential
roadblocks.
Communicate quick deployment wins.
Discuss software deployment best
practices.
Provide product overviews. Granularity of
products discussed should be tailored to
the audience. Typically, the overviews
should be for the few "driver" products.
Arrange for demos of key products.

Figure 4-7 Inputs, tasks, and outputs for DM 6: Conducting the deployment kickoff meeting

4.3.3 Benefits
The benefits that result from this task include:
򐂰 A perceived tight linkage of partnership
򐂰 Customer awareness, understanding, and enthusiasm
򐂰 An understanding of the key responsibilities and their owners
򐂰 IBM team’s credibility and accountability established

Chapter 4. Software Deployment Phase 1: Conducting the deployment kickoff 41

42 Optimizing Software Deployment: An Insider’s Guide
 5

Chapter 5. Software Deployment Phase 2:

Deploying the software
This purpose of this phase is to execute the quick wins, help ensure early deployment
success, execute the deployment projects that follow the quick wins, and during deployment,
look for opportunities to amend or renew the Enterprise Agreement (EA). As shown in
Figure 5-1, the activities for deploying the software are:
򐂰 DM 7: Begin quick deployment win activities
򐂰 DM 8: Execute the deployment plan
򐂰 DM 9: Scan for new deployment and revenue opportunities
򐂰 DM 10: Amend or renew the Enterprise Agreement
Qualified

Begin quick wins (DM 7)

Deploy-
Won

Execute deployment plan (DM 8)

ment Scan for new opportunities (DM 9)
Amend or renew EA (DM 10)

Phase 0 Prepare Phase 1 Kickoff Phase 2 Execute

Figure 5-1 Phase 2: Deploying the software

© Copyright IBM Corp. 2003. All rights reserved. 43

5.1 DM 7: Begin the quick deployment win activities
Figure 5-2 shows DM 7 in relationship to the other steps in the Signature Selling Method
(SSM) and Software Deployment Method (SDM).

SSM & SDM Interlock: DM7

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM7 Execute Quick Deployment Win

80% Closure 2 Goals (IBM and Customer
Possibility Engage Stakeholders)
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 5-2 DM 7: Begin the quick deployment win activities

The purpose of this activity is to execute on the quick deployment win activities and, in doing
so, to demonstrate success and build momentum in the beginning stage of deployment. This
activity is critical and can be complicated.

During this activity, the deployment team carefully monitors the early projects that allow the
customer to recognize a fast start. In addition, the Software Deployment Team (SDT) needs
to stay focused on the “quick-win” goals that the customer provided in earlier discussions. The
ultimate goal of this step is to help ensure that customer recognizes value crisply and early.
Deployment has begun!

5.1.1 Owners and participants

The owners are the Enterprise Business Sponsor, Software Deployment Architect (SDA) or
Software Architect.

The participants include the Enterprise Business Sponsor (EBS), customers project leader,
IBM Software Sales Specialist (SSS), IBM Software Technical Sales Specialist (ITS), IBM
services representative, IBM support representative, and key customer stakeholders
assigned to quick-win projects.

44 Optimizing Software Deployment: An Insider’s Guide

5.1.2 Input, tasks, and output
Figure 5-3 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, see Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

List of projects and Identify quick-win deployment Work products
owners project managers (IBM, customer, Updated and refined
Project plans for quick or third party). readiness plan associated
deployment wins Checkpoint capabilities of IBM and with quick-win projects
Readiness plan customer teams assigned to
Software deployment quick-win deployments. Results
best practices Execute the quick-win deployment Quick-win deployment
plan. projects completed
Manage the quick-win projects.
Conduct regular meetings with
project owners.
Monitor progress of quick wins
against plan and make adustments
as needed.
Implement recommendations defined
during readiness discussions.
Address and resolve technical
issues that arise.
Maintain close contact with customer
owner and stakeholders.
Execute training plan (as part of
readiness plan).
Monitor customer satisfaction.
Track software license usage.

Figure 5-3 Inputs, tasks, and outputs for DM 7: Beginning the quick deployment win activities

5.1.3 Benefits
The benefits that result from this activity are:
򐂰 Customer confidence is built.
򐂰 Technologies are tested and understood.
򐂰 Credibility of the Enterprise Business Sponsor and IBM is reaffirmed.
򐂰 Customers are trained.
򐂰 Customer references are obtained.

Chapter 5. Software Deployment Phase 2: Deploying the software 45

5.2 DM 8: Execute the deployment plan
Figure 5-4 shows DM 8 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM8

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM8 Execute deployment plans (IBM

80% Closure 2 and Customer Stakeholders)
Possibility Engage
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 5-4 DM 8: Execute the deployment plan

The purpose of this activity is to build on the success and momentum of the quick deployment
wins and begin to deploy projects that are defined up to this point. During this activity, project
management is critical. Also customer satisfaction and progress toward deployment goals
(timeline and financial) should be monitored carefully. This is also the perfect time to repeat
the kickoff meetings conducted in step DM 6. The vision of the deployment should be
re-communicated. It may also be possible to host an open house with live demonstrations of
what was accomplished with the quick wins.

During deployment, the SDT should manage two lists:

򐂰 A list that identifies existing (underway) projects
򐂰 A list that identifies potential projects

Refer to Chapter 6, “Managing software deployment projects” on page 53, for more
information about this. The SDT’s challenge in this phase is to move projects from the
“potential” list to the “active” list at an acceptable rate that will burn the software licenses.

5.2.1 Owners and participants

The owners are the Enterprise Business Sponsor, Software Deployment Architect or
Software Architect.

The participants include the SDT, Enterprise Business Sponsor, key customer stakeholders,
IBM Software Sales Specialist, and IBM Software Technical Sales Specialist.

46 Optimizing Software Deployment: An Insider’s Guide

5.2.2 Input, tasks, and output
Figure 5-5 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, refer to Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

TeAM Advertise quick win successes with Work products
Final deployment architecture meetings or open house. Deployment milestone
Final physical architecture Identify deployment project status reports
SDM managers (IBM, customer, or third License use reports
party).
Software deployment best ROI/ROR status reports
practices Educate customer on IBM's support
process. Results
Readiness plan Deployed software that
Checkpoint capabilities of IBM and
Final environment and achieves the customer's
customer teams assigned to
infrastructure requirements execute deployment. goals
Final deployment plan Begin deploying projects per the Completed projects
Final systems management deployment plan.
plan Manage the projects.
Final project controls Monitor progress against plan and
Final deployment quick-win make adustments as needed.
plan Address and resolve technical
Final goals and milestones issues that arise.
document Maintain close contact with
customer owner and stakeholders.
Monitor customer satisfaction.
Track software license usage.

Figure 5-5 Inputs, tasks, and outputs for DM 8: Executing the deployment plan

5.2.3 Benefits
The benefit that results from this activity is a satisfied customer who perceives value from the
Enterprise Agreement and who wants to do additional business with IBM.

Chapter 5. Software Deployment Phase 2: Deploying the software 47

5.3 DM 9: Scan for new deployment and revenue opportunities
Figure 5-6 shows DM 9 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM9

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM9 Scan for new deployment

80% Closure 2 opportunities and new revenues
Possibility Engage
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 5-6 DM 9: Scan for new deployment and revenue opportunities

Recognizing that not all deployment projects are identified prior to agreement closure, the
purpose of this activity is to use selling techniques to generate demand for the remaining
products in the contract inventory. Also, new opportunities for revenue should be found during
this activity.

During deployment, many projects may remain on the “potential projects” list. During this
activity, shifting these projects to an “active” status continues to be a high priority. But the
deployment team also has the responsibility of recognizing licenses that may not be matched
to a deployment project in any status. This is where the technical team needs to work with the
sales team and the customer to define opportunities and design solutions that will continue
the license burndown. As stated earlier, this work effort is continuous until the customer’s full
entitlements are achieved.

Throughout deployment, it is critical that the deployment team perform a checkpoint with
customer executives to help ensure that the Enterprise Business Sponsor is getting what they
expect from deployment. Also, the deployment team should constantly watch for additional
sales opportunity to pass on to the sales team.

There should be some level of agreement among the entire Client Team, whether it be among
the Software Group (SWG) or the full IBM team, as to how frequently the full team should
interface with the customer at a senior level. The purpose of this regular interlock with the
customer is to help ensure that value milestones are being met and exceeded. The instinct for
many on the sales team is to move on to the next opportunity, forgetting about the sale that
just closed. Although this behavior is imperative to revenue growth, it is important that these
regular meetings occur to show the commitment of IBM to the customer’s goals.

The SDA should be the day-to-day constant in the account. There should also be an EA
owner for the customer who is constant in the account. There should also be someone from

48 Optimizing Software Deployment: An Insider’s Guide

 the customer side who regularly monitors a return on the investment. If all goes well, along
the timeline of the EA, this person should see good progress toward obtaining full value.

For the first three to six months of the EA, the Software Account Manager (SAM) should
check progress with the customer once a month to help ensure that things are moving along
smoothly. Thereafter, the SAM should check progress at least every three months. During the
progress meetings, the SAM should ask these types of customer satisfaction, deployment,
and selling questions:
򐂰 How is deployment progressing?
򐂰 At this point, does the customer believe that they are getting the value they expected? Is
the pace OK?
򐂰 Are there any technical issues impeding progress or satisfaction?
򐂰 Are there any contractual issues that need to be addressed?
򐂰 Do we have the right team working with you?
򐂰 Are you at a point that you would be willing to be a reference for us?
򐂰 It looks like things are going well with Storage Management (for example), and you may
need some more software in this area. Should we think about amending your Enterprise
Agreement?

Also, the SAM should interact regularly with the deployment team to help ensure that things
are moving along well. They should confirm anything that they hear from the deployment
team directly with the customer.

The Client Executive should check the EA’s progress at least every three months. When the
executive interacts with the customer, they should ask the same types of questions as noted
previously for the SAM.

Note: As part of the SSM and Technical e-business Architect Method (TeAM), the architect
and sales team identify and develop new opportunities, developing solution architectures
and laying the groundwork for the new opportunities. When that work completes, the SDT
can update the deployment plan and manage the new projects. However, there is much
work to be done on the current deployment before that point is reached.

5.3.1 Owners and participants

The owner is the Enterprise Business Sponsor, Software Deployment Architect or Software
Architect.

The participants include the Enterprise Business Sponsor and the SWG Team.

Chapter 5. Software Deployment Phase 2: Deploying the software 49

5.3.2 Input, tasks, and output
Figure 5-7 shows the inputs, tasks, and outputs for this activity. For descriptions of the inputs
and outputs, see Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

Deployment plan Revise the deployment plan Results
Goals and milestones to include the new demand. Opportunities identified
document Look for new project/product New products deployed
Gap analysis report and opportunities. New demand generated
feedback from customer Manage these new projects Value of contract realized
business owner as done in activity DM 8.
New customer
requirements

Figure 5-7 Inputs, tasks, and outputs for DM 9: Scan for new deployment and revenue opportunities

5.3.3 Benefits
The benefit of this activity is that new projects are defined that result in maximum deployment
performance.

5.4 DM 10: Amend or renew the Enterprise Agreement

Figure 5-8 shows DM 10 in relationship to the other steps in the SSM and SDM.

SSM & SDM Interlock: DM10

SSM 5 Monitor Implementation

Intensity of IBM &
Customer SSM 5 Close 6
7
Agreement 5

8
4
9

3
10

DM10 Repeat Business or EA Renewal

80% Closure 2
Possibility Engage
Software Development
Team
1

SSM 5 Develop 0

Solutions (60-70%)

Deployment Methodology SSM & Team Time

Figure 5-8 DM 10: Amend or renew the Enterprise Agreement

The ultimate goal of the Software Deployment Method is customer loyalty. As you have
learned in this redbook, the focus of DM 0 through DM 9 is planning and driving customer
success and satisfaction. These efforts earn customer confidence and foster loyalty to IBM

50 Optimizing Software Deployment: An Insider’s Guide

 products and services. DM 10 was included as the final step of SDM to ensure the client and
the SWG team leverages deployment achievements to identify and generate repeat business.
This step of SDM takes the critical inputs and findings from DM 7 through DM 9 and generate
a qualified opportunity for new revenue.

DM 10 is also when the Software Deployment Method circles back and begins again. As you
will recall, DM 0 (Create the Software Deployment Team) kicked off when an opportunity was
at 80% possibility of closure. This occurred just after step 5 (Develop Solutions) of the
Signature Selling Method. With the help of SSM, the qualified opportunities collected during
DM 10 require a reaffirmation of IBM and customer commitments to deployment success.
Consequently, the Software Deployment Method begins again and helps establish baseline
confidence.

5.4.1 Owners and participants

The owners are the SAM, Software Architect or Software Deployment Architect.

The participants include the SWG Team.

5.4.2 Input, tasks, and output

Figure 5-9 shows the inputs, tasks, and output for this activity. For descriptions of the inputs
and outputs, see Appendix A, “Work products: Usage and examples” on page 97.

Inputs Tasks Outputs

Opportunities identified Move deployment forward and Results
during steps DM 8 and meet the customer's milestones. New demand identified by
DM 9 Help ensure that all ROI and client and account teams
Deployment milestone ROR goals are being met.
status reports
Report any new revenue
Feedback from project
owners opportunities.
Anything that substantiates Assist with any new solution
the success of the design activities.
deployment that just
completed

Figure 5-9 Inputs, tasks, and output for DM 10: Amend or renew the Enterprise Agreement

5.4.3 Benefits
The benefit that results from this activity is that of a satisfied customer.

Chapter 5. Software Deployment Phase 2: Deploying the software 51

52 Optimizing Software Deployment: An Insider’s Guide
 6

Chapter 6. Managing software deployment

projects
Customers perceive that they are obtaining value from their Enterprise Agreement (EA) when
the software licenses purchased are applied to projects that make a difference in their
business. On the surface, this seems fairly straightforward, but in reality, it is a challenge.

This chapter provides information to help the deployment team begin managing the projects
that burn (use) the software licenses and stay on top of the projects throughout the life of the
Enterprise Agreement.

© Copyright IBM Corp. 2003. All rights reserved. 53

6.1 Enterprise Agreement project: Application of solutions to
satisfy a business need
From a deployment team’s perspective, a project is any customer effort that requires the
installation and use of Enterprise Agreement software licenses. Projects can burn licenses at
the beginning, middle, or end of an Enterprise Agreement, or even throughout an Enterprise
Agreement.

A project may be as straightforward as installing the SameTime application on the computers

of a dozen users, or delivering an upgraded version of an application to all of its current users.
And a project may be as complex as installing customer-written software at locations around
the world, where hundreds of IBM WebSphere licenses are required or installed as part of the
process.

Some projects last a week, where others can last a year. The project management rigor
applied varies with the project’s priority, complexity, and duration.

6.2 Getting started

At agreement close, there is typically a vision for how the software licenses should be used.
There is a high-level algorithm developed for executing the vision. The algorithm factors in:
򐂰 The number servers and workstations the customer has
򐂰 The number of gigabytes of storage that are required to store the Enterprise Agreement
software

The deployment team’s hard work begins in the post sales environment, when the vision
needs to be mapped into deployment activities (projects).

There is no formula or standard when it comes to determining how many projects will run
during an Enterprise Agreement. Typically, on the first day of deployment, the deployment
team has a list of potential and funded projects, project owners, and what software each
project will use. This list likely doesn’t contain enough projects to deploy all the software in the
Enterprise Agreement, but it starts things moving. Hopefully it creates some successes that
generate enthusiasm and demand for the remaining products that are in the portfolio.

As an example of getting started, an Enterprise Agreement for $10 million may specify $2.5
million in software to be used from each of the four IBM brands. The deployment team works
with each brand sales person and technical sales person to determine an inventory for their
$2.5 million. Then the deployment team aligns the software with the anticipated projects,
identifies a customer owner for each project, determines the start and end dates for each
project, and sets a timeline for license use. The Software Architect assigned to the account is
responsible for ensuring that all of the software in the Enterprise Agreement (across brands)
integrates smoothly, but in some cases, the projects may not need to interlock at all. For
example, there may be a totally independent Tivoli project that may not touch a data
management project. Many times projects do need to integrate.

Here is how an experienced Software Deployment Architect describes how he begins:

“I need to think of the projects very quickly on a new Enterprise Agreement that can burn
the software. So I begin my conceptualization by going back (we as deployment architects
may not have been part of the original development of the contracts) and reading and
thoroughly understanding the contract. I then meet with the Software Account Manager
(SAM) and whoever else was involved with it and understand where and how the customer
envisioned using the licenses. It is important to write down the project list on paper.

54 Optimizing Software Deployment: An Insider’s Guide

 Memories are short, and by documenting this, we help the deployment team and the
customer stay on the same page.
Once the project list is documented, I then apply good project management principles. 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 go into management requests and 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).”

6.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 deployment team should work with the Enterprise Business
Sponsor to select the first project carefully and manage it so that it deploys on time for
satisfied customers. Early in the deployment, the customer executives should exclaim, “Look
at this! It’s so terrific that we’re seeing value already!”

Every account is different, but you have to do all you can to help ensure the first project is
successful. If a deployment team 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 aren’t working with the true Enterprise Business Sponsor. The deployment team’s
challenge is to partner with the real owners, those who care most about the success of the
projects and the Enterprise Agreement, and work with them to make things happen.

6.4 Managing at the milestone level

The most valuable piece of advice that experienced 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 deployment
team cannot let itself get bogged down into the details of managing each one.

The deployment team 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 deployment team can:
򐂰 See that each project starts well
򐂰 Check with the teams at critical points to help ensure things are (or aren’t) on schedule
򐂰 Help ensure that action items required to keep projects moving are acted upon

It is wise for the deployment team to prioritize projects, too. They should be spending more of
their time on the hottest projects, but even then, they should manage them at the milestone
level.

As one deployment team 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.”

Chapter 6. Managing software deployment projects 55

6.5 Handling project management challenges
Over a multi-year deployment period, even the best deployment teams encounter some
challenges. Situations that deployment teams should be prepared to handle are:
򐂰 The customer has too much of one product and not enough of another (software licenses)
򐂰 Scope creep
򐂰 Inexperienced project managers

Each of these challenges is further explained in the following sections.

6.5.1 Too much of one product and not enough of another

As an Enterprise Agreement’s software deploys, you may discover that the customer has a
shortage of licenses in one area (which can be good for IBM) or that they have much more
than they needed in another area (which can be bad). This is when the challenges start to
present themselves, especially if the customers don’t have any substitution ability.

6.5.2 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 contract. Scope creep can be
harmful, because it can take a project off on a tangent and cause schedules to be missed.

Scope creep can be good for IBM, because it opens up additional sales opportunities.
However, the customer may sometimes expect to get additional licenses under the original
Enterprise Agreement’s umbrella. These situations may offer opportunity to exchange
licenses (make sure you know what substitutions the Enterprise Agreement contract allows).
You need to be aware of:
򐂰 The products in the Enterprise Agreement that are not being used
򐂰 How additional products may be used
򐂰 Whether the scope of the project can be enlarged to use additional product

While all this is happening, you need to be sensitive to the committed schedules and
deadlines. It is a tightrope you have to walk.

Some of the opportunity that comes from scope creep may not be software related. For
example, it can be in the hardware arena and the customer may need more processor power
or direct access storage device (DASD). You can engage the hardware group and then bring
in the appropriate services (Lotus Professional Services or Global Services, for example) to
help with integration. Additional opportunity may be in the area of education.

6.5.3 The inexperienced project leader

Skills transfer to the customer is critical. Often the project leaders are customer personnel.
You need to help ensure that they have excellent project management skills. Project
management certification is available and can be suggested in certain situations. Also, the
examples in Appendix A, “Work products: Usage and examples” on page 97, may be helpful
to project leaders.

56 Optimizing Software Deployment: An Insider’s Guide

 7

Chapter 7. Managing global software

deployment
IBM was one of the first companies in the United States to tap into a worldwide market. Our
presence in the major geographies of the world has become an increasing source of revenue.
As such, global deployments (the installation of IBM licensed software for an account that has
deployment locations that span two or more geographies) happen frequently. They pose
challenges above and beyond those faced in deploying software for accounts that are located
within a single geography. This chapter provides a checklist and advice for managing these
situations.

Note: Although North America and South America are considered one IBM geography, if
an account deploys software in both continents, consider it global because of the many
cultural differences between the two regions.

IBM is one of the 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 littered with potential pitfalls. It
is because of these pitfalls that this chapter was included in this redbook. IBM generally
assigns a global account team to any customer that has global reach. This team generally
consists of representatives from all parts of IBM, such as Global Client Executive and Global
Software Account Manager. At some accounts, a Global Software Deployment Architect is
also assigned.

Revenue recognition is one of the first pitfalls that is often encountered. Generally speaking,
IBM follows the First Landing Principal. This means that software subscription and support
is linked to a specific site in the country or region where the products are acquired and
revenue is booked. Therefore, recording revenue proportionally in the countries or regions
where the customer will use the software enables the local IBM company to fund the
necessary resources to supply the local support. The client and Software Group (SWG)
teams need to work together to ensure the revenue recognition is handled amicably across all
geographies.

© Copyright IBM Corp. 2003. All rights reserved. 57

 For the team managing a global deployment, a constant challenge is keep IBM internal issues
internal. The most important task for the team is to focus on customer satisfaction. They need
to:
򐂰 Work through problems
򐂰 Shield any IBM infrastructure problems from the customer (or at minimum, not make
excuses to the customer for them)
򐂰 Help ensure that the customers get what they need and when they need it

This is not easy. To give this situation the proper focus and resource, IBM created a role
called the Global Deployment Architect (GDA) and recommends a coverage model to help
keep the global deployment accounts on track. If an account qualifies for this type of
coverage, the GDA is positioned in the city where the Global Account Team is located
(typically where the customer’s headquarters is located). The GDA needs this proximity to the
IBM team and the customer.

The GDA has limited ability to impact locations outside their geography. For this reason, IBM
recommends a primary, secondary, and tertiary coverage model. The size of projects and the
number of simultaneous projects determine whether a deployment site requires primary,
secondary, or tertiary coverage:
򐂰 Primary = full time: A customer site where the majority of deployment occurs warrants
primary coverage. This involves full-time, dedicated, and focused deployment personnel
who are hands on and proactive.
򐂰 Secondary = part time: A customer site where significant deployment activity occurs, but
not as much as the primary site or sites, warrants secondary coverage. A part-time person
is assigned here. This means that this account is one of several assigned to them. They
are proactive or reactive in this deployment as the situation requires.
򐂰 Tertiary = on demand: A customer site where minor deployment occurs (or
straightforward deployment) receives tertiary support. The tertiary person only goes to the
account when called. The person’s name is on the “coverage chart”, but they are not the
person checking on the customer proactively to see how things are going. When the GDA
hears that something critical is happening at the account, they request that this person
gives the situation the needed attention. The on-demand person is typically the manager
of a technical team in the city, country, or region.

7.1 How the coverage model works

IBM decides if and when to assign a GDA and the primary, secondary, or tertiary support to a
global account. To date, this coverage model is applied in nine global accounts, and a tenths
account will be added soon. Table 7-1 and Table 7-2 on page 60 show the accounts and the
individuals assigned.

The size of the agreement doesn’t necessarily trigger the application of this model. Basically
IBM management decides whether an account needs global attention. Client Teams are
aware that the role and coverage model exists. If they feel it is necessary, then they raise the
need.

When a GDA is assigned, they work with the customer sponsor (the person whose job it is to
see that the global deployment succeeds) to identify the countries (regions) and cities where
deployment will occur, how much, and when. Ideally, the customer assigns project leaders
within each of their locations that has significant deployment activity. The GDA then works
within IBM to obtain the primary, secondary, and tertiary deployment commitments. The GDA

58 Optimizing Software Deployment: An Insider’s Guide

 and sponsor align the customers assigned with the IBM personnel assigned and
communicate these partnerships.

Note that a significant amount of deployment occurring outside of the United States may not
qualify as a global deployment. For example, there have been requests for a GDA at a major
account in the United Kingdom (UK). Upon closer inspection, 98% of the deployment is
happening within the UK. The deployment may be complicated and challenging, but that in
itself it does not require the application of the model. For this example, it is not a global
challenge, but a local challenge.

Table 7-1 shows the EMEA-based global deployments as of 31 December 2002.

Table 7-1 EMEA-based global deployments example

HSBC AHOLD ABN Amro BBVA BNP Paribas

Americas John Hains

(New York) (PT-Buffalo)

Americas TBD Dawn Dischler

(Other NA) (PT-Atlanta) (PT-Chicago)

Latin America Ricardo Mansano Ricardo Mansano TBD - Brazil

(PT-Brazil) (PT-Brazil)

EMEA John Barker Niels van Eck Ted Zonderland Angel Cardeno Patrick Soltani
GDA (UK) GDA GDA (Netherland) GDA (Spain) GDA (France)
(Netherland)

Tokyo

Singpore/India Choong Peng

Chee/
Sunil Tewari (OD)

China (Hong Ellis Chow

Kong S.A.R.) (PT-Acting)

Korea Sanghoon Park

Australia Susan Putland

(OD)

PT: Part time, FT: Full Time, OD: On demand

Chapter 7. Managing global software deployment 59

 Table 7-2 shows the Americas-based global deployments as of 31 December 2002.

Table 7-2 Americas-based global deployments example

JPM Chase Merrill Lynch Citigroup Morgan AMEX Fleet
Stanley

Americas Sean Franks Tom Caruso Tom Poovakad Jim Doherty Kurt Hayes
(New York) GDA GDA GDA GDA GDA

Americas TBD Tom Szukala

(Other NA) (PT-Chicago) GDA (Arizona)

Latin America Ricardo

Mansano
(PT-Brazil)

EMEA Mohammed
Ajab
(FT - UK)

Carole Carole Carole

Brougham Brougham Brougham
(PT - UK) (PT - UK) and (PT - UK)
Javier
Rodriguez-
Liviano
(OD-Germany)

Tokyo Makoto Makoto Jin Shimizu

Matsuzaki Matsuzaki (OD)
(OD) (OD)

Singpore/India Lalit Yagnik Choong Peng

(OD) Chee/
Sunil Tewari
(OD)

China (Hong Ellis Chow

Kong S.A.R.)

ANZ Susan Susan Susan Putland

Putland (OD) Putland (OD) (OD)

PT: Part time, FT: Full Time, OD: On demand

7.2 Global deployment checklist

GDAs can become so focused on what is happening at their account that they lose track of
what is happening around the world. Therefore, GDAs need to check frequently to help
ensure that they are covering all that needs to be done.

The following checklist is provided to help the GDA track the most important items. The first
few items on the list do not need to be done repeatedly, but only for the assignment process.
Other items need to be revisited regularly to help ensure they are being handled.
򐂰 Geography management assigns a Global Deployment Architect in the city where the
global Client Team is based and where the Enterprise Agreement was closed.
򐂰 The GDA works with the global Client Team and the customer to identify the customer’s
Enterprise Agreement sponsor or owner.

60 Optimizing Software Deployment: An Insider’s Guide

 򐂰 The customer’s Enterprise Agreement sponsor provides a preliminary list of software
deployment locations around the globe. This list should clarify primary, secondary, and
tertiary deployment sites. This level of granularity helps determine the level of deployment
management attention required in each geography.
򐂰 The customer’s Enterprise Agreement sponsor provides at least one Enterprise
Agreement project lead for each geography.
򐂰 The GDA manages the primary deployment sites, and a part-time person should be
assigned to cover the secondary deployment sites.
򐂰 The GDA arranges for an on-demand contact (usually from the technical sales support
organization) for all tertiary sites.
򐂰 The GDA loads profile information into Workbench and gives the global team access and
ability to update. See Chapter 9, “Software deployment tools” on page 71, for information
about Workbench.
򐂰 The GDA establishes a bi-weekly conference call with the global deployment team. Each
member should provide a brief update on the deployment progress. This status should be
placed on the Workbench profile.
򐂰 The GDA establishes bi-weekly meetings with the Software Account Manager (SAM), the
Client Executive, and the Managing Director, if applicable, to discuss software deployment
progress.
򐂰 The GDA and the local Software Deployment Architect should interlock with the Client
Teams in each geography and checkpoint software deployment satisfaction from the
perspective of the customer. Any issues raised should be investigated, escalated to the
Software Group War Room if necessary, and resolved promptly.
򐂰 The GDA distributes a progress report to the global deployment team (and to SWG
executive management) on a bi-weekly basis. It should include feedback from the
regularly scheduled meeting with the Client Team.

7.2.1 More about the checklist items

This section offers further details about the items in the deployment checklist.

Assign a GDA
The geography manager assigns a GDA to the city where the global Client Team is based.
Assignments may require a change if someone leaves during the project or if the global team,
for whatever reason, moves to another city.

Identify the customer’s sponsors

One of the deployment best practices (see Chapter 10, “Best practices” on page 85) is that
the customer should have a global sponsor who is focused on the customer’s global
deployment success. This doesn’t have to be one person. It can even be a team of three to
four people with one person assigned to each geography, for example. It is important that the
customer align people with each important deployment location.

Obtain a list of software deployment locations

The sponsor should provide a list of global deployment locations and work with the GDA 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.

Chapter 7. Managing global software deployment 61

 Arrange full-time (primary) and part-time (secondary) coverage
Per the description of the coverage model, people should be assigned full-time and part-time
to satisfy the deployment demands.

Arrange on demand (tertiary) coverage

Typically, the on-demand contact is from the technical team in the city, country, or region. For
example, this person could be an IT specialist or a Software Architect. If a technical contact is
not available, the manager of the technical team should be assigned. When the need arises,
the manager assigns the appropriate technical person from their team.

For these types of deployment efforts, the customer usually works with one product, such as
systems management or application server, that is quite specific to their needs. In this case,
the appropriate on-demand person may be a WebSphere specialist or a Tivoli specialist.

Load information into Workbench

Workbench is a deployment management tool that contains useful information. It may include
customer profiles, key customer contacts, key IBM Client Team contacts, basic contract
details (start date and end date, for example), lists of products purchased, revenue size, and
a color coding of the “health” of the customer account (red, orange, yellow, green). The GDA
is responsible for loading customer account information into the workbench tool initially and
then keeping the information current. You can find more information about this tool and its use
in Chapter 9, “Software deployment tools” on page 71.

Conduct bi-weekly meetings with global deployment team

Every other week, most GDAs lead two or more status conference calls: one call with the
team in the primary geography and then one call each with teams in the other geographies.
The GDA roles up all the summary information into Workbench as a status report. A level of
coaching should occur in these calls. GDAs should push secondary and tertiary contacts to
drive deployment. They can’t be passive. They must be proactive.

Conduct bi-weekly meetings with the SAM, client executive, and

managing director
GDAs should have regular interaction with the Client Team to let them know what deployment
is going on around the world. There is a level of maintaining credibility that is important. Since
a relatively small percentage of client executives’ revenue comes from software, you may not
get (or need) much of their time. Thirty minutes every two weeks may be enough. But in those
regular, brief updates, the GDA can gain an immense amount of credibility by showing that
they know what is going on in the account and that they are doing what is best for the
executives’ software. The GDA, SAM, and Software Architect (SWA) should be partners in
conveying the status.

Interlock with Client Teams and checkpoint deployment satisfaction

The GDA should interlock 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 GDA’s role should be to travel every
three to six months to meet each customer and local deployment personnel and help ensure
they are on top of what is happening. If items need upper management attention, the
Software Group War Room is the primary escalation vehicle.

Provide regular progress reports

The GDA should send frequent progress reports to the primary, secondary, and tertiary
people, so they are kept informed of progress in all of the geographies. The GDA needs to
communicate the data and the stories behind the data. For example, communicate what the
data is telling, or why the person in China (Hong Kong S.A.R.) should care about what is

62 Optimizing Software Deployment: An Insider’s Guide

 happening in London. By interpreting the data, and guiding decisions, the GDA builds
credibility by demonstrating a combination of technical, project management, team building,
and business skills.

7.3 A global deployment coverage example

J. P. Morgan Chase is an IBM customer that deploys software globally. Figure 7-1 shows
assignment coverage for the deployment that follows the model described in this chapter. The
majority of the deployment occurs in New York City. The global Client Team is there, as well
as the GDM, Sean Franks. Since a significant amount of deployment is occurring in the UK,
Mohammed Ajab, a primary (full time) person, is assigned. On-demand help is provided by
Mokoto Matsuzaki, Lalit Yagnik, Ellis Chow, and Susan Putland in Tokyo, Singapore, China
(Hong Kong S.A.R.), and Sydney respectively.

S Franks -GDA M Ajab - Primary E Chow -On Demand

New York UK Hong Kong

MatsuzakiT On Demand
Tokyo

S Putland - On Demand
Sydney

L Yagnik - On Demand
Singapore

Figure 7-1 Global deployment coverage example

Chapter 7. Managing global software deployment 63

64 Optimizing Software Deployment: An Insider’s Guide
 8

Chapter 8. Achieving return on investment

Tangible results are the driving forces behind financial investments. Return on investment
(ROI) is an inevitable topic of discussion with the customer. In fact, it is the most common
concern of the client. For example, they may ask, “How and when will we start to see return?”
It is a challenging question to respond to, but the Software Group Team is frequently expected
to tell their client up front how they will benefit.

As early as possible in the selling and deployment cycles (for example, during the “develop
solution with customer” step of SSM and during DM 2: Develop high-level plan step of
deployment), the Software Group Team should determine the customer’s ROI. Their work on
defining ROI pays dividends when they meet with the customer in deployment step DM 3. It
shows that:
򐂰 The IBM team has the customer’s success in mind.
򐂰 They have been thinking of ways to quantify, measure, and help ensure that success.

ROI discussions typically lead to two types of measurements:

򐂰 Hard (tangible) ROI
򐂰 Soft (intangible) ROI

According to most experts in this area, it is good to have both tangible and intangible
measures. And it is not that hard measures are good, or that soft measures are bad.

Hard and soft ROI data can be developed at an individual product level. This should not be
discouraged, but the Software Group Team should not get lost in that detail. They need to
determine ROI and overall benefits at the enterprise level and determine how those benefits
support the business vision.

© Copyright IBM Corp. 2003. All rights reserved. 65

8.1 Hard (tangible) ROI
Hard (tangible) ROI can be quantified with dollars or numbers. It is typically associated with
the following types of reductions:
򐂰 Headcount savings: Solutions often provide automation or efficiencies that allow more
work to be done with the same number of employees (that is, employees won’t need to be
hired), or the current workload can be handled with fewer employees. Customers know the
dollar overhead per employee, so these projections map cleanly to dollars saved.
򐂰 System count reduction: Hardware has fixed costs associated with it. Therefore, savings
connected with reducing hardware inventory are tangible, because “dollars saved” can be
shown.
򐂰 Server consolidation: Hard costs are associated with each server. For solutions that
result in server consolidation, the dollar savings can be shown.
򐂰 Department closures: Solutions may eliminate the need for entire departments. These
savings are tangible.

Professional studies to quantify tangible ROI can take significant amounts of time, for
example six to twelve months. The studies involve questionnaires that contain hundreds of
questions. Since many departments in the company are asked to participate, the customer’s
time investment can be quite high. When the surveys are completed, it may take several days
or weeks for the analysis to complete and the results to be made available. When all is said
and done, the results may not be totally reliable, because some subjectivity is involved.

8.2 Soft (intangible) ROI

Soft ROI cannot be projected or have its progress measured in exact dollars or numbers. It
involves such concepts as satisfaction and perception. It may include, for example, how
employees feel about their jobs, their departments, the processes they follow, their
productivity, the tools they use, their upper management, and their company.

Sometimes these factors are what determine whether the best employees stay with their
companies. Therefore, solutions that can be shown (or are believed to) improve employees
perceptions of these topics are important. Satisfaction and perception are key for both
employees and the business’ customers.

Other soft ROI examples include items that:

򐂰 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 the many applications that 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 geographical growth: Most businesses want to grow. Showing that
the solutions support seamless worldwide expansion, for example, is usually one that
generates support for the solution.
򐂰 Streamline the way organizations work within the company: Efficiency is hard to
measure or prove, but employees usually know when it is there. Solutions that re-engineer
organizations or streamline processes may have soft ROI, but important ROI nonetheless.
򐂰 Allow resource redirection: The better managed the customer’s environment is, the
more time employees must be proactive rather than reactive. They can anticipate and plan
for future business improvements.

66 Optimizing Software Deployment: An Insider’s Guide

8.3 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 purchase are based
on proactive needs or simple reaction to something perceived as the latest trend, the desire to
track and quantify benefits is absolute. Typically, the ROI is driven by a business looking to
see an increase in productivity or some type of cost savings. Therefore, it is essential that the
customer quantifies pragmatic, tangible benefits that are tied directly to the company’s
business goals and objectives.

ROI is only as important as customer management makes it. Customers tell IBM (usually
quite directly) just how tightly or casually they want their investments tracked to tangible
benefits and over what time frame.

8.4 An approach to analyzing return on investment with a

customer
A recommended approach to helping a customer measure ROI and the success of their
deployment is outlined here:
1. Interview executives, managers, and employees. Gather business needs, current metrics,
and possible benefits.
2. Review company data including organizational, processes, metrics, customer feedback,
statistics on current state, and how knowledge is shared.
3. With the knowledge of best practices, especially by companies in related industries,
analyze and synthesize the data.
4. Create quantitative (spreadsheets) and qualitative (surveys and interview guides)
measures to gather data concerning the benefits (cost avoidance, savings, and new
revenue and profits) of implementing the solution for specific communities.
5. Determine base line data for the quantitative and qualitative measures that you define.
6. Gather 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.

These steps offer an order and approach for working with a customer to identify ongoing
measurements for success and lifetime ROI.

8.5 Deployment goals and measures

This section provides samples of deployment goals and questions to be asked regarding their
attainment.

Customer success
򐂰 Did the quick-win projects create positive first impressions, generate enthusiasm, and
build momentum?
򐂰 Are you achieving the milestones outlined in the deployment plan?

Chapter 8. Achieving return on investment 67

 Customer value
򐂰 Is the customer getting timely functional return from the deployed projects?

Relationship management
򐂰 How many people in the account know about your team, what they do, and the successes
they have had?
򐂰 Are you increasing your contacts over time?
򐂰 Are you working up the management chain, so that more and more senior management in
the company is aware of the deployment successes?

Customer satisfaction (three tiers)

򐂰 Tier 1: Are the customer’s technical users and implementers satisfied with the
deployment? This can be determined via a Web survey once or twice a year.
򐂰 Tier 2: Are the customer’s project leaders and middle managers satisfied? This can be
determined via a Web survey once or twice a year.
򐂰 Tier 3: Are the customer executives satisfied? This should be determined in a one-on-one
meeting with an IBM executive at least once a year.

License utilization
򐂰 Are you on target as planned with your deployment of licenses?
򐂰 Are you managing the gap effectively so there will be no shelfware at the end of the
engagement (Gap = total licenses – deployed – forecasted)?

References
References can be philosophical, for example, “I bought the solution for these reasons (list),
although the software may not yet be deployed.” Or references can be actual, for example,
“The software has been deployed in my company and I am satisfied for these reasons (list).”
򐂰 Is the customer willing to be a reference account?
– Grade 1 reference: They are willing to be quoted and referenced in a newspaper or
magazine article.
– Grade 2 reference: They are willing to appear and speak at a trade show or at a
product kickoff meeting.
– Grade 3 reference: They are willing to give a testimonial at a prospective customer’s
account.

Opportunity management
򐂰 Are you generating the new opportunities required to drive the new revenue needed year
to year?

8.6 When goals are met, IBM and the customers win
The purpose of deployment is to get the customer to buy repeatedly at increasingly greater
levels. If the customer deploys well, sees value in what was purchased, and sees value in
what was deployed, they will buy more. Ideally, the customers’ trust in IBM and loyalty to IBM
increases over the years.

68 Optimizing Software Deployment: An Insider’s Guide

8.7 Example ROI: Current value
Table 8-1 and Table 8-2 show spreadsheet data used to communicate deployment value to a
customer executive. The value is shown in dollars of deployed software licenses verses
on-the-shelf software licenses.

Table 8-1 Company A

ELA Value Statement
From 12/28/2000-9/30/2002

Total Total
Purchased on Allocated Deployed & SVP at Level SVP Deployed &
PRODUCT DESCRIPTION ELA Licenses Deployed Licenses Allocated J* Allocated Value
Host Integration Family
Host Publisher Server 10 1 0 1 $53,375.00 $53,375.00
Host On-Demand 9850 9000 0 9000 $102.50 $922,500.00
Screen Customizer 200 2 0 2 $102.50 $205.00
Lotus Family
CEO Lotus Sametime User 10000 538 0 538 $32.90 $17,700.20
WebSphere/MQ Family
MQ Series CU for UNIX & NT 596 254 0 254 $1,601.75 $406,844.50
WebSphere Advanced Edition Server 158 59 50 109 $8,441.00 $920,069.00
Data Management Family
DB2 UDB EE (qty 6 swapped out) 50 50 0 50 $17,457.00 $872,850.00
Tivoli Family
TBSM 1 1 0 1 $2,636,363.00 $2,636,363.00
Software distribution Retail 514 514 0 514 $554.00 $284,756.00
Remote Control Server Retail 93 93 0 93 $189.66 $17,638.38
Software distribution Server Back Offi 410 50 360 410 $554.00 $227,140.00
Software Distribution Clients Corpora 25000 160 24840 25000 $31.19 $779,750.00
Tivoli Software Miscellaneous 1 0 1 1 $155,167.00 $155,167.00
Tivoli Storage Manager Tier 2 6 6 0 6 $4,500.00 $27,000.00
Tivoli Storage Manager Tape Sharing 6 6 0 6 $19,875.00 $119,250.00
Tivoli Disaster Recovery 6 6 0 6 $15,750.00 $94,500.00
Deployed and Allocated Distributed Software Value $7,911,863.48

Actual Inventory Actual Savings

MLC Value (AI) MLC (AI-MLC)
Host / 390 Year 1 $5,384,028.00 $5,241,600.00 $142,428.00
Host / 390 Year 2 $4,300,500.00 $3,931,200.00 $369,300.00
Totals $9,684,528.00 $9,172,800.00 $511,728.00

Total MLC Actual Inventory Value $10,168,754.40

Additional ELA Benefits

SW Install base maintenance $476,910
IBM ELA Deployment Manager $175,000
Tivoli Business Systems Manager (TBSM) Services $870,000
Services and Education $750,000
Lotus Silver Support Contract $186,667
Lotus Services $20,000
Additional Callers $74,089
Total Additional ELA Benefits Value $2,680,299.13

Additional IBM Benefits

Tivoli Workload Scheduler Additional Discount (Compliance/New Licenses) $75,291
Informix Additional Discount (Compliance) $473,343
CPCS (Compliance) $654,780
Total Additional IBM Benefits Value $1,263,584.70

Chapter 8. Achieving return on investment 69

Table 8-2 On the shelf
ELA Value Statement
From 12/28/2000-9/30/2002

Total SVP of Undeployed and

Purchased on Licenses Allocated Total SVP at Level Undeployed & Unallocated Total
PRODUCT DESCRIPTION ELA Deployed Licenses Remaining J* Allocated Value Value
Host Integration Family $538,196
Host Publisher Server 10 1 0 10 $45,750.00 $457,500.00

Host Publisher Usage Pack 10 0 0 0 $6,219.00 $0.00

Host On-Demand 9850 9000 0 850 $77.00 $65,450.00

Screen Customizer 200 2 0 198 $77.00 $15,246.00

Lotus Family $383,497

CEO Lotus Sametime User 10000 538 0 9462 $26.89 $254,433.18

CEO Domino Workflow bundle User 1000 0 0 1000 $57.88 $57,880.00

Mobile Services for Domino Server 2 0 0 2 $4,500.00 $9,000.00

Mobile Services for Domino Client Ac 1000 0 0 1000 $60.50 $60,500.00

Domino Server 1 0 0 1 $1,616.00 $1,616.00

Notes Collaboration 1 0 0 1 $67.52 $67.52

WebSphere/MQ Family $1,818,614

MQ Series CU for UNIX & NT 596 254 0 342 $1,373.00 $469,566.00

MQ Series CU for DEC 10 0 0 10 $1,373.00 $13,730.00

VA Java Enterprise Developer 300 0 0 300 $2,098.00 $629,400.00

VisualAge C++ Developer 60 0 0 60 $1,493.00 $89,580.00

WebSphere Studio Professional User 300 0 0 300 $347.00 $104,100.00

WebSphere Advanced Edition Server 158 59 40 59 $8,682.00 $512,238.00

Data Management Family $24,314

DB2 UDB EEE 1 0 0 1 $24,314.00 $24,314.00

Undeployed and Unallocated Distributed Software Value $2,877,322

70 Optimizing Software Deployment: An Insider’s Guide

 9

Chapter 9. Software deployment tools

In January 2002, the Enterprise Agreement Workbench was introduced for use by
administrators, executives, deployment architects, and deployment teams. The Workbench
was designed for tracking Enterprise Agreement (EA) software licenses at a global,
geography, or regional level. It has become an invaluable tool used to:
򐂰 Maintain a real-time customer profile
򐂰 Keep IBM account team assignments current
򐂰 Display unique contract details such as monthly license charges (MLC) and one-time
charge (OTC) levels and contract expiration date
򐂰 Report on Enterprise Agreement customer health (red, yellow, green)
򐂰 Track individual deployment projects
򐂰 Measure progress of each deployment project
򐂰 Help ensure compliance with Solution Assurance policies in the deployment phase

Deployment architects are required to keep the Workbench current at least monthly. However,
they are encouraged to update more frequently if the account situation warrants it.

Workbench is a Lotus Notes®-based application, that is currently at Release 3.2. ELA

Workbench is continually being improved with refined processes and added features.

The starting point for Workbench is the creation of an enterprise profile, the main form of the
application. It contains vital information such as enterprise name, account type, account
status, account team information, GEOs, deployment regions, and sales regions. It also
contains the contract financial information such as total distributed revenue, MLC revenue,
and total contract value.

After the enterprise profile is created, one or more locations must be created. A location
allows the deployment architect to manage deployment at separate locations independently
and provides the access to account health report. Account health reports are monthly
snapshots that show how a location is doing.

Each location should have brands. Each brand has its own document that contains
information such as the business as usual (BAU) value of deployable software, the
percentage deployed, and the deployed BAU value.

© Copyright IBM Corp. 2003. All rights reserved. 71

 Brands may be associated with a project. The project document represents an optional plan
to deploy brands as stated in the location.

Brand deployment is tracked by recording the deployment in the form of currency or

percentages in the brand document or through the project document.

A contact document should exist for each person on the account team. It lists e-mail, address,
and phone number information.

After opening the ELA Workbench database, the display shown in Figure 9-1 is presented
with selectable views listed in the left column. Which views a user sees depends on their role.

Figure 9-1 Selectable views in the ELA Workbench database

The remainder of this section provides overviews of the information displayed for the
Enterprise, Account Health Summary, and Reports views. More information about
Workbench is available in a Workbench Training Guide that is part of the help information
within Workbench.

9.1 Enterprise views

The Enterprise views that are available are:
򐂰 All
򐂰 Enterprise by name
򐂰 Locations
򐂰 Projects
򐂰 Brand coverage
򐂰 Health reports
򐂰 Contacts/general documents

The following sections provide an example of each of these views.

72 Optimizing Software Deployment: An Insider’s Guide

9.1.1 All view
The All view displays all documents within an enterprise, sorted by enterprise name.

Figure 9-2 All view

9.1.2 Enterprise By Name view

This view sorts the documents by enterprise name.

Figure 9-3 Enterprise By Name view

9.1.3 Locations view

The Locations view displays the locations for all enterprises. This view contains the following
columns:
򐂰 Location name
򐂰 Total Contract Value (TCV) in millions of U.S. dollars
򐂰 MLC revenue in millions of U.S. dollars
򐂰 Distributed revenue in millions of U.S. dollars
򐂰 Start and end date of the contract
򐂰 Month and year of the latest account health report for the contract
򐂰 Status of the latest account health report for the contract

Chapter 9. Software deployment tools 73

 Figure 9-4 Locations view

9.1.4 Projects view

The Projects view displays the projects for all enterprises and their contracts.

Figure 9-5 Projects view

9.1.5 Brand Coverage view

The Brand Coverage view displays the brand deployment statistics for all enterprises and
their locations sorted by the brand name.

Figure 9-6 Brand Coverage view

74 Optimizing Software Deployment: An Insider’s Guide

9.1.6 Health Reports view
The Health Report document is a monthly snapshot that shows the health of a contract.

Figure 9-7 Health Reports view

Note: Product deployment is tracked by the creation and maintenance of Brand

documents. These documents contain quantities that are proposed and deployed by the
brand. They can be updated in the Brand documents or through a project with an Open
status.

9.1.7 Contacts/General Documents view

The Contacts/General Documents view lists all of the contacts associated with an enterprise
and the general documents created. These general documents are intended to store
information and attachments in one consolidated view. The types of general documents that
can be created are:
򐂰 Account milestones
򐂰 Contract addendum
򐂰 Proposal
򐂰 Deployment report
򐂰 Executive summary
򐂰 SAR information
򐂰 Escalations
򐂰 Product information
򐂰 Account plan
򐂰 Customer profile
򐂰 Assessment
򐂰 Value Proposition
򐂰 Goals and success criteria
򐂰 Communication plan
򐂰 Exit criteria
򐂰 Success story
򐂰 Monthly health report

Chapter 9. Software deployment tools 75

 Figure 9-8 Contacts/General Documents view

9.2 Account Health Summary views

The Account Health Summary views provide a look at the critical information regarding an
account. Health is updated monthly for most accounts. For assigned accounts, the Software
Deployment Architect (SDA) submits a health report. Accounts in Unassigned status are
updated by the lead Software Account Manager (SAM) via an automated survey.

Each account is assigned a color that indicates the overall account status:
򐂰 Red: High concern, high-risk account. Existing critical customer satisfaction issues are a
potential revenue risk within 90 days.
򐂰 Yellow: Low concern, low risk account. Minor customer satisfaction issues.
򐂰 Green: No known customer satisfaction or revenue risk issues.

The Account Health Summary views display the latest account health status alphabetically by
enterprises, or enterprises categorized by sales geography and region as listed here:
򐂰 All
򐂰 Americas Canada
򐂰 Americas Central
򐂰 Americas East
򐂰 Americas Federal
򐂰 Americas Latin America
򐂰 Americas West
򐂰 EMEA CEMA
򐂰 EMEA Central
򐂰 EMEA Nordic
򐂰 EMEA North
򐂰 EMEA South
򐂰 EMEA West
򐂰 Asia Pacific

The following section provides an example of each view.

76 Optimizing Software Deployment: An Insider’s Guide

9.2.1 All view
The Enterprises listed in this view are dictated by the users’ access level, which is defined by
Region, Geography or Global.

Figure 9-9 All view

9.2.2 GEO views

The GEO view summarizes health information by GEO and sales region. Enterprises are
sorted within the regions by health status and ELA renewal quarter.

Figure 9-10 GEO views

Chapter 9. Software deployment tools 77

9.2.3 Detailed health reports
From either the All, Health Report, or Account Health Summary views, you can access the
more detailed Health Report.

Figure 9-11 Detailed health reports

78 Optimizing Software Deployment: An Insider’s Guide

9.3 Reports view
The Reports view displays the report documents for all enterprises.

Figure 9-12 Reports view

9.3.1 Pre-defined reports

Currently, five predefined reports can be created in the ELA Workbench. Users can only
create reports for enterprises to which they have access. The reports are:
򐂰 Account Financial Summary
򐂰 All Accounts Status
򐂰 Brand Summary
򐂰 Location Status
򐂰 Score Card

Figure 9-13 through Figure 9-17 show an example of each of these reports.

Chapter 9. Software deployment tools 79

Figure 9-13 Account Financial Summary

Figure 9-14 All Accounts Status

Figure 9-15 Brand summary

80 Optimizing Software Deployment: An Insider’s Guide

Figure 9-16 Location status

Figure 9-17 Score card

Chapter 9. Software deployment tools 81

9.4 SWAP View
Software Architects have created a process called SWAP designed to:
򐂰 Guide the Software Architect through a repeatable process to lead in the planning of
strategic actions and investments in an account that results in increased software revenue
to IBM.
򐂰 Focus on an action plan aligned with the customer’s business initiatives, strategy, and
environment rather than IBM opportunities already in progress.
򐂰 Focus the Software Architect on the strategic technical leader role they plan in our sales
process.
򐂰 Provide IBM’s software business leaders with a valuable snapshot of data of the
customer’s investments in IBM software technology and record of a local action plan to
strategically invest IBM resources in that customer.
򐂰 Increase teaming across our sales organizations with a focus on cross-selling solutions
across our portfolio.
򐂰 Develop an industry analysis of the captured data to improve our software revenue results
by industry.

The documents created through the SWAP process are stored in the Workbench database.
Four document types are created as part of SWAP:
򐂰 Customer profile
򐂰 Sales initiatives/opportunities
򐂰 Customer environment
򐂰 Miscellaneous

The four views in which you can see the SWAP documents are:
򐂰 All
򐂰 By geography
򐂰 By industry
򐂰 By person

Figure 9-18 through Figure 9-21 show an example of each of these views.

Figure 9-18 All view

82 Optimizing Software Deployment: An Insider’s Guide

Figure 9-19 By Geography view

Figure 9-20 By Industry view

Figure 9-21 By Person view

Chapter 9. Software deployment tools 83

9.5 Team rooms
Team rooms are excellent central repositories for information. They support deployment team
collaboration. Team rooms can store technical information as well as human resource
information regarding travel, benefits, education, policies and procedures, forms, and
templates.

Many team rooms exist. To obtain access to the ones that are most helpful to you, check with
your management or operations lead for your department.

84 Optimizing Software Deployment: An Insider’s Guide

 10

Chapter 10. Best practices

Deployment success and value realization are best achieved when best practices are
adhered to constantly throughout the life of the Enterprise Agreement (EA) and the Software
Deployment Method. The customer-specific best practices are:
򐂰 Identify Enterprise Business Sponsor and stakeholders.
򐂰 Centralize software fulfillment.
򐂰 Implement a license management tool.
򐂰 Hire deployment services.
򐂰 Determine the customer’s deployment readiness.
򐂰 Commit to self-sufficiency.
򐂰 Define a time-to-value and ROI strategy. For more information about ROI, see Chapter 8,
“Achieving return on investment” on page 65.
򐂰 Communicate and market the vision.

The Software Group Team’s deployment focus areas are:

򐂰 Know the contract. Refer to 3.1, “DM 0: Create the Software Deployment Team” on
page 26, for more information about this.
򐂰 Communicate the software deployment best practices described in this chapter to the
customer.
򐂰 Develop the deployment Readiness Plan. Refer to Chapter 11, “The Readiness Plan” on
page 89, for more information.
򐂰 Host a deployment kickoff meeting. Refer to 4.3, “DM 6: Conduct the deployment kickoff
meeting” on page 39, for more information about this.
򐂰 Stay with it! Software deployment success requires teamwork between the customer and
IBM that has to be maintained through the entire relationship cycle.

The deployment team and Enterprise Business Sponsor should agree to follow deployment
best practices. These are items that have proven to ensure the highest possibility of success
in Enterprise Agreement deployments.

© Copyright IBM Corp. 2003. All rights reserved. 85

10.1 Identify Enterprise Business Sponsor and stakeholders
Ownership can be at several levels. For example, there may be a high-level Enterprise
Business Sponsor and several tiers of sponsorship beneath them. Get to know all the
sponsors and their roles. If possible, find the person in the customer account who feels that
their job is on the line if the EA does not deliver the expected value. This person will welcome
your partnership offer.

If the deployment team feels that they can’t control the projects, it is likely a sign that they
have not found, and are not working with, a true Enterprise Business Sponsor. Ensure the
business sponsor understands that you are there to support them, to partner with them. Work
with them to identify what you want to complete in the next 90 days, which can really make an
impact. Expect the wins to continue, and celebrate each one.

Work with the Enterprise Business Sponsor to identify cultural, geographical, political, skills,
or training challenges that need to be overcome. Define a strategy or plan to overcome each.
Make sure the business sponsor understands how to go about getting support for products in
each brand, and that they understand the support (level 1, level 2, and level 3 assistance) and
escalation processes. Customers should know what support numbers to call, who to call, and
who is in charge. Ideally, you should develop a support roadmap for the business sponsor so
there is no confusion in this area.

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. In Phase 1, kicking
off deployment, a COE provides an internal organization and set of personnel that can
increase the buy-in and willingness of other customer organizations to consider using IBM
software through presentations, demonstrations, and proof-of-concept activities. In Phase 2,
executing deployment, a COE facilitates the sharing of skills, experiences, and resources
across multiple projects. It accelerates and improves the quality of the deployment.

10.2 Centralize software fulfillment

Buying an EA is not like buying a car. It is not a single entity that the customer buys. Rather,
with an EA, the customer has purchased a multitude of software packages that they will start
to download from the Passport Advantage Web site. To maximize deployment activity, the
delivery of software is continuous until the contract expires.

The list of customers scheduled to receive software will likely change over time. The
Enterprise Business Sponsor should centralize the software fulfillment process as early as
possible in the deployment life cycle. That way, one party in the company is responsible for
the receipt, or downloading, of all software in the EA, logging its receipt, distributing it to those
who need it, and tracking what is delivered.

10.3 Implement a license management tool

The customer has a contractual obligation to report software usage (refer to ESSO and
Passport Advantage Agreement for details). While Software Group (SWG) has taken a soft
approach to enforce this policy, it is important that the customer think about the concept of
license tracking and management for both limited an unlimited licenses. Most of our
customers do not know, or do not want to report, which products are deployed and in use in
their environments. This makes calculating return on investment (ROI) difficult and
compliance management nearly impossible.

86 Optimizing Software Deployment: An Insider’s Guide

 License management involves identifying:
򐂰 The licenses that are installed
򐂰 The licenses that are active
򐂰 The number of licenses that are forecasted to be deployed

Since there is no automated process today, spreadsheets are presently used to identify
deployed software on every end point and to establish a baseline. Refer to Appendix A, “Work
products: Usage and examples” on page 97, which provides examples of spreadsheets that
are used to perform license management.

Tivoli has a tool called Tivoli License Manager that became available in November 2002. The
customer can leverage partners or a homegrown process or system to track license
utilization. The key point is that IBM needs to enforce more strictly the need for the customer
to report software usage. The contract specifies that this is the customer's responsibility. Not
doing so can lead to a full audit of their environment by IBM or a third-party consultant.

10.4 Hire deployment services

It is important to have IBM Services involved early in the selling cycle. The technical team
should:
򐂰 Assess the deployment projects scheduled to begin after the agreement closes.
򐂰 Match the right service representatives to analyze and size the work effort involved.

If amenable, the customer should be presented with a services proposal to execute the work.
When the customer has chosen to decline services, deployment success may be at risk.
Consider the skills and experience of the customer and make recommendations to the
Enterprise Business Sponsor to rectify any capability gaps.

10.5 Determine the customer’s deployment readiness

The transition from sales close to deployment is where significant deployment problems can
originate. Handoffs and assumptions may not be clearly communicated or documented. One
set of players is phasing out and another set is phasing in on both the customer team and the
IBM team.

The Software Account Manager (SAM), Software Deployment Architect (SDA), and Software
Architect (SWA) must take special care to work well together and to engage the appropriate
customer team members so that the momentum of a successful sales carries over to
deployment. At this point in the deployment cycle, we recommend that you document and
review the following items from the Readiness Plan with the customer. (The Readiness Plan
is described in detail in Chapter 11, “The Readiness Plan” on page 89.)
򐂰 Business goals
򐂰 Communications plan
򐂰 Education plan
򐂰 Execution environment plan
򐂰 Support plan
򐂰 Backup and recovery plan
򐂰 Systems management plan
򐂰 Migration plan and schedule
򐂰 Rollout plan and schedule
򐂰 Service level agreements
򐂰 Dependencies

Chapter 10. Best practices 87

 We realize that doing this takes time, but it is the time invested that pays excellent dividends
as you deploy. These plans help to:
򐂰 Ensure the customer has the right set of expectations to successfully implement the
proposed solution
򐂰 Ensure the IT system lies within the “art of the possible”
򐂰 Identify issues and risks to be escalated

10.6 Commit to self-sufficiency

The deployment team’s goal over time is to decrease IBM’s involvement in deployment. In
turn, this increases the self-sufficiency of the customer. A well-designed training plan is a key
part of this equation as is a plan to develop customer subject matter expertise across all
product lines. To achieve this goal, the customer should commit personnel appropriately to
match the number and complexity of key projects.

10.7 Define a time-to-value and ROI strategy

It is up to the customer’s EA owner to determine how value will be calculated. Generally the
customer has two different types of ROI:
򐂰 Soft ROI: This includes such examples as better monitoring or control capabilities, future
value, and strategic vision of a unified world and common look and feel.
򐂰 Hard ROI: This includes such examples as headcount savings, system count reduction,
server consolidation, department or process closures, and outsourcing.

The deployment team should work with the EA owner to map out a timeline with value
milestones. Revisit the milestones quarterly to help ensure the deployment is moving forward
effectively and delivering the intended results. Refer to Chapter 8, “Achieving return on
investment” on page 65, for more information about this topic.

10.8 Communicate and market the vision

Determine what the customer will do to market the EA in their company. The ability to fully
deploy software requires maximum disclosure with the customer’s IT departments and the
lines of business. This drives demand and deplete software inventory most quickly.

A key event that helps launch the deployment is to have a deployment kickoff meeting. This
kickoff meeting should occur soon after the EA closes. This event should introduce all the
customer stakeholders to the products included in the EA. Review the software deployment
best practices with the customer at this time. In addition, review expectations that were set
and the criteria for measuring value. For more information about the kickoff meeting, see 4.1,
“DM 4: Refine the deployment plan” on page 36.

Like the steady beat of a drum, communications should continue throughout the life of the EA,
marketing and surfacing deployment opportunities. The deployment team should monitor
deployment progress and recommend adjustments in the communication plan. In general,
keep those who need to know informed of EA content and progress. A communications
example can be a newsletter or Web page that keeps management and end users informed
about recent accomplishment, milestones, and improvements. It is important to promote and
validate the results of ELA deployment often to as many audiences as possible to keep up the
momentum and excitement.

88 Optimizing Software Deployment: An Insider’s Guide

 11

Chapter 11. The Readiness Plan

The 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 selling to post-sales activities
򐂰 Assure that customer’s use cases (requirements) are met
򐂰 Identify risks for mitigation and escalation

Readiness Plans are particularly important when dealing with customers who have a history
of critical situations and high-risk implementations. These customers may also have projects
that have significant scope and enterprise-wide visibility, customers who have limited skills,
first product drop installations, and service provider engagements.

The components of a Readiness Plan are:

򐂰 Business goals
򐂰 Communications plan
򐂰 Education plan
򐂰 Execution environment plan
򐂰 Support plan
򐂰 Backup and recovery plan
򐂰 Systems management plan
򐂰 Migration plan and schedule
򐂰 Rollout plan and schedule
򐂰 Service level agreements
򐂰 Dependencies

This chapter explains each of these components. For additional information about a
Readiness Plan and examples, see the following Web site and install the Xpertise Library.
From that database, select the Readiness plan shared asset.
https://w3-3.ibm.com/software/sales/salesite.nsf/salestools/
Information+and+People$XpLibInfo

© Copyright IBM Corp. 2003. All rights reserved. 89

11.1 Business goals
It is imperative that the IT community understand the business goals and benefits to be
derived from the software implementation. Sharing the business goals of the purchase
decision with them accomplishes two objectives:
򐂰 They understand better their role in the overall enterprise.
򐂰 They make dozens of daily decisions invisible to the supervisory chain. As they do so,
understanding the business value of the implementation helps them to shape their
decisions and make more informed judgments.

11.2 Communications plan

The communications plan should reflect all the direct and indirect parties involved with the
project and describe who is responsible for every aspect of the implementation. This plan
should also describe the escalation process in case of problems. This may be as simple as a
listing of names, telephone numbers, and project responsibilities. The primary objective of
this plan is to clarify customer versus IBM responsibilities during implementation. A sample
communications plan is shown in Table 11-1.

Table 11-1 Communications plan

Contact description Contact name Contact
phone

Enterprise Business Sponsor: A senior executive who is above the day-to-day Executive name
elements of the project, but who should monitor progress and can influence
organizational change, resources, and other lines of business.

Project Sponsor: You may have more than one name here especially if user Sponsor name
groups are represented by someone who needs to be informed if problems
arise.

Project Lead: This person handles project or application installation. Project Lead name

Project Development Team: List each developer. Developers

Backup and Recovery Contact: List the person responsible for developing the Availability Lead
backup and recovery plan here.

Security Contact: This person is responsible for securing the environment and Security Officer
providing authentication and authorization access to all codependent systems.

Systems Management Contact: List the lead contact for monitoring the Systems Management
environment. Contact

Internal Help Desk Contact or Contacts: List the name and number of the help Help Desk Contacts
desk as well as the name of the project lead responsible for developing
support information to the help desk.

Execution Environment (Operations) Contact: List the people who must be Operations Contact
called when the system goes down.

IBM Support Center Phone number and contract number: Make sure the IBM Support numbers
customer understands what level of support they have contracted and how to
use it.

IBM Sales Team Contact(s): When everything breaks down, the customer IBM Sales Team
must know when and how to contact the IBM sales team. It is important for the Contacts
customer to avoid communications delay and avoid over communications.

90 Optimizing Software Deployment: An Insider’s Guide

11.3 Education plan
The education plan should assess:
򐂰 The skills needed for successful implementation
򐂰 Current customer skills
򐂰 The steps to close all identified gaps

This plan should be cross-checked against the migration and rollout plan to prevent
implementation from getting ahead of customer skills. Some of the identified actions for this
plan may include attending product training, hiring skilled mentors to work onsite, or hiring
consultants to perform implementation.

This plan also starts to prepare the customer for how their resource plan should look. If they
don’t have the right in-house skills and a tight deployment schedule, they should notice
quickly that external skills are needed.

The key responsibility of the IBM sales team is to identify skill gaps and suggest approaches
for closing these gaps. It is the customer’s responsibility to close the gaps. Software technical
product specialists should be engaged to quantify and qualify the necessary skills, not as a
substitute for the skills needed.

The education plan can be a simple tabular listing of skills needed for the project, assessed
measurement, and actions for providing the skills. Identify the skill delivery date and match it
against the project schedule. Table 11-2 shows an example of an education plan.

Table 11-2 Education plan

Project skill Assessed customer Skill gap plan Target
skills (H/M/L) date

WebSphere Application Server L Attend IBM WebSphere Installation and

Installation and Configuration Configuration Training Class #999999.

DB2 Administration H Internal Skill sufficient

VisualAge® for Java™ Servlet M Attend IBM VisualAge for Java Application
Development Development Class #999999.

VisualAge for Java Enterprise L 1. Acquire IBM online education from

JavaBean (EJB) Development and Learning Services.
Design 2. Attend IBM VisualAge for Java
Application Development Class
#999999.
3. Hire an EJB Mentor from IBM Global
Services.

Chapter 11. The Readiness Plan 91

11.4 Execution environment plan
The objective of the execution environment plan is to recommend an appropriate environment
and level of discipline for development, test, and change management during implementation:
򐂰 Multiple-tiered environment: Some solutions require a four-tiered execution environment
with separated development, test, quality assurance, and production systems. Others may
only require a test and production system. It is vital to communicate the recommended
execution environment to the customer so they can plan appropriately. The execution
environment should match the topology diagram that was delivered earlier in the sell cycle.
With this deliverable, the sales team should provide detailed hardware topology
recommendations with prerequisite and co-requisite hardware and software listings.
򐂰 Development and change plan: The customer is responsible for creating the execution
environment and change plan. However, IBM can assist them to identify the development
processes and suggest a change management plan. The sales team should describe the
application development flow and method for creating and changing the application that
will run in the execution environment. Discussions related to this step may lead to the
identification of gaps in content management or change control processes.

11.5 Support plan

The support plan should cover both how IBM will deliver support to the customer and how the
customer will support their users during the implementation:
򐂰 IBM support processes: The customer, at all levels, needs a thorough briefing on how
the IBM support center and processes work, from Web tools to escalation procedures.
Adjust the briefing for any product-specific differences or special support purchased. Key
telephone numbers and Web addresses are important to their understanding of how to
capitalize on IBM’s capabilities. Also cover the new maintenance and subscription
elements of Passport Advantage in general.
򐂰 Customer support processes: The customer’s internal support plan should cover how
end users, development, or operations are supported during the implementation. The
customer should clearly document who will provide support to each user community and
create a plan for delivering that support. For example, if the customer has an internal help
desk, they should have an education plan to transfer skills to the help desk personnel. The
support plan should include a documentation plan for creating and delivering
documentation to all systems users. Many customers underestimate the need for
documentation. An enterprise-ready system should have documentation for end-users,
developers, operational staff, help-desk, and more.

11.6 Backup and recovery plan

The primary objective for the backup and recovery plan is to identify:
򐂰 The necessity for backup and recovery
򐂰 How backup and recovery impact the customer’s internal service level agreements
򐂰 Who is responsible for backup and recovery and document the procedures in their support
plan

The backup and recovery plan should account minimally for reinstalling software,
configuration data, and application data. Discussions surrounding this deliverable may lead to
customer interest in Tivoli Storage Manager, our premier backup and recovery solution.

92 Optimizing Software Deployment: An Insider’s Guide

 We also recommend that the customer consider implementing and exercising a full disaster
recovery plan as part of the recovery process if needed. At a minimum, they should review
their disaster recovery plan to determine feasibility.

11.7 Systems management plan

Deployment of software involves multiple end-user communities, large numbers of
heterogeneous computers, and multiple customer IT organizations. Often management of
distributed environments is perceived as needing less systems management than
mainframes environments. On the contrary, even more systems management is needed due
to the larger numbers of components.

Your deployment success is predicated on your ability to deploy, maintain, and track software
in this environment. Systems management is a key element in providing this ability. It must be
included in the base planning, not as an overlay or an afterthought.

Systems management can include:

򐂰 Configuration and operations: Distribute software, track licenses, manage the change
and control of IT assets, automate workflow, and remotely controls systems and
applications. Affiliated topics include:
– Change and release control: Processes and tools used to collect, track, approve, and
release changes into the customer environment. This topic logically precedes the
configuration and operations discipline.
– Ongoing maintenance: Ensuring the currency of software via the identification and
installation of service releases, configuration changes, stand-alone fixes, and upgrade
releases. Many deployment plans focus on a “one shot” installation, where software is
deployed and configured without consideration for how it is updated. Even during an
Enterprise Agreement deployment, software deployed early in the Enterprise
Agreement (EA) life cycle needs to be updated to inter-operate with software deployed
later in the EA life cycle.
– Problem management: Defined process or mechanism for opening, tracking, resolving,
and closing problems/issues. This can also be called a help-desk function.
򐂰 Performance and availability: Systems and applications monitoring, event correlation
and automation, business impact management. Affiliated topics include service level
agreements. They are defined metrics (availability, capacity, scalability, performance, and
security) that are used to evaluate the operational status of the overall solution. This topic
depends on basic capabilities provided by the performance and availability discipline.
򐂰 Security: Automated identity (authorization and authentication) and security event (risk
and event) management. As upgrades, migrations and implementations are
accomplished, security access for these moves must be planned as part of the process.
Authorization and access changes required for vendors or internal implementation
personnel should be determined. In addition, systems vulnerabilities should be identified.
򐂰 Storage: Incremental backup and disaster recovery, storage area network (SAN)
management.

A systems management strategy can be based on a software solution, such as the Tivoli
brand, on a manual solution based on processes or procedures, or on a combination of both.
Either way, you and your customer need to factor in the time and cost needed to define,
implement, and maintain this.

Chapter 11. The Readiness Plan 93

 Finally, the customer should consider a systems management control board. It should include
users as members to gain their buy-in, review key problem issues, and alert them to
upcoming changes.

11.8 Internal service level agreements

The systems management plan should designate who is responsible and how they intend to
account for the solution’s uptime availability during implementation.

11.9 Migration plan and schedule

Many customers don’t want to think about version 2 or 1.x, but if they don’t, migrations will
create cost and time overruns. This can create serious problems. There are two aspects of
migration planning to consider:
򐂰 Customer created code that will be promoted into production: This should be
included in the change plan noted in the Execution Environment section.
򐂰 The platform migration plan and schedule: For each version of the execution
environment, the customer faces a set of activities that can jeopardize the overall success
of the solution. Some of those activities include customer code regression testing,
execution environment tests, migration automation scripting, and back out planning. If the
execution environment does not support co-resident versions, the customer may be forced
to plan to cascade hardware as they migrate from one release to the next.

11.10 Rollout plan and schedule

So far, the customer has probably successfully executed their proof of concept, evaluation, or
perhaps pilot phase. Moving the solution into implementation requires a larger level of
commitment. The rollout plan includes all the individual plans listed in this document with a
schedule and priority attached to each activity. Laying out the activities and their schedule
helps the customer to visually see and understand the timelines and dependencies of their
project implementation.

11.11 Service level agreements

The customer’s service level agreement is a contract with their users to provide availability,
capacity, scalability, performance, and security of the system. Discussing the customer’s
expectations for these non-functional requirements helps you to understand their
expectations.

The implementation may impact the customer’s internal service level agreements. The
systems management plan should account for how the customer will monitor the system’s
uptime and respond to problems. It should also include alerts to internal customers. This plan
should discuss who is responsible and how they intend to account for the solution’s uptime
availability.

94 Optimizing Software Deployment: An Insider’s Guide

11.12 Plan assessment tool
Table 11-3 through Table 11-5, taken from IT Architecture and Design Knowledge Network,
can be useful to record the risks, assumptions, issues and dependencies (sometimes referred
to as the RAID log). It is particularly helpful if the description field (Risk description,
Assumption description, etc.) refers to the source of the requirement or issue that generated
the item. For example, a risk item that documents difficult-to-achieve response times should
refer to the non-functional requirement that stated these response times.

The IBM Sales Team should use the risk and assumption assessment tables as a summary of
the above plans. You may also want to add other active risks, assumptions, issues, or
dependencies identified during the sales process.

Table 11-3 Risks assessment tool

Risk reference Risk description Probability Impact Contingency/ Review date
(H/M/L) (H/M/L) mitigation

Table 11-4 Assumption assessment tool

Assumption Assumption Confidence Impact Review period Associated risk Closed
reference description level or date reference date

Note: Record any assumption with a low confidence and high impact as a risk.

Table 11-5 Issue assessment tool

Issue Issue Raised Date Priority Action Review period Closed or risk/
reference description by raised responsibility or date change reference

Chapter 11. The Readiness Plan 95

11.13 Dependencies
If there are prerequisite or co-requisite software, operating system, API, hardware
expectations, or any other dependencies for a successful project, document and list the
assumptions. Use the sample chart in Table 11-6 to document the dependency effects and
required dates. Relate these dependencies back to the risk assessment.

Table 11-6 Dependencies

Dependency Dependency Effect on Required by Owner Associated Completed
reference description plan date risk reference date

11.14 Relationships among deployment plan, project plans,

and readiness plans
Figure 11-1 shows the relationship of deployment plans, project plans, and readiness plans.

Deployment plan

Deployment team, roles, and

responsibilities Project plans Readiness plan
Program controls and (one per project)
governance
Deployment projects Project charter
Business goals
Quick wins Project team
Communications plan
Longer-term projects Project sponsor
Education plan
Deployment timeline WBS
Execution environment plan
High-level readiness plan Readiness plan
Support plan
Communication plan (can be integrated
Backup and recovery plan
Education plan into project plan)
Systems management plan
Licensing and tracking plan etc...
Migration plan and schedule
Deployment milestones/metrics
Rollout plan and schedule
Software demand gap analysis
Service level agreements
and strategy
Execute Dependencies
Kickoff meeting
Challenges, risks, and mitigation
plan
Prerequisites and dependencies

Execute

Execute
Figure 11-1 Deployment plans, project plans, and readiness plans

96 Optimizing Software Deployment: An Insider’s Guide

 A

Appendix A. Work products: Usage and

examples
This appendix provides information about work products used and produced by the Software
Deployment Method. Work product examples follow the descriptions. Figure A-1 provides a
mapping of the work products associated with Solution Selling Method (SSM), Technical
e-business Architect Method (TeAM), and Software Deployment Method (SDM).

Mapping Work Products

Identified Validated Qualified Proposed Won
Monitor
Understand Develop plans Establish Articulate IBM Develop Close
implementation
customer linked to buying capabilities solution the sale
SSM business & IT customer bus vision with and qualify with
and ensure
expectations
environment initiatives customer opportunity customer
are met

1-Arch. Decisions 1-Viability

1-Business 1-IT standards 1-Business 1-NFR
2-Arch. Overview
1-Operational
context context - 2-System context model assessment -
2-Current IT Diag.
2-Envisioned update Architecture 2-Viability update
infrastructure 3-Available Asset
TeAM goals and 2-Business decisions List assessment- 2-SET/MET
issues process 3-Use case update update
4-Component
3-Current roadmap 4-Viability Model 3-Project 3-Harvest
organization 3-Project assessment 5-Operational description - designs and
description- Model update architecture
update 6-Viability 4-Viability brief(s)
Assess-update assessment -
7-Project update
Descr.-update

Deployment 1-Value realization 1-VRM - update 1-VRM - update 1-VRM -update

Method model (VRM) 2-Deployment 2-Deployment 2-Deployment
2-Deployment plan - update plan - update plan - update
plan 3-Readiness 3-Readiness 3-Readiness
3-Readiness plan - update plan - update plan - update
plan

Figure A-1 SSM, TeAM, and Deployment Method: Work products mapping

© Copyright IBM Corp. 2003. All rights reserved. 97

TeAM work products used by SDM
The following information describes each of the TeAM work products used by the Software
Deployment Method.

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 IBM and the
customer.

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 the client's 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 the client as a way
to clarify which business interactions are in scope and which are out of scope of the system
being developed.

Component model
The component model documents the following information for each component:
򐂰 Responsibilities: Describes responsibilities from the view of a user of a component. The
description is later refined into specific operations that constitute the application
programming interface (API) for the component.
򐂰 Required service levels: Describes the service level for the component in regard to users
and presentation, performance/capacity and availability design rationale, reasonableness
and risk, and implementation approach.

Customer’s IT 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 their
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).

98 Optimizing Software Deployment: An Insider’s Guide

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 the client's mission
statement, vision statement, to-be business goals, and critical success factors:
򐂰 Mission statements (sometimes called value statements, credos, or principles) are the
operational, ethical, and financial guidelines of companies (or functional areas). They
articulate the goals, dreams, behavior, culture, and strategies of companies.
򐂰 Vision statements are the long-term objectives of the company. They articulate the
company's target market place, products and services. It also states the position that the
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 the 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 the Enterprise
Agreement (EA), 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 IT standards that the architecture must
accommodate.

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.

System context diagram

The system context diagram helps clarify the environment in 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

Appendix A. Work products: Usage and examples 99

 (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/volumes,
scalability, availability, portability, maintainability, and usability. It also specifies requirements
in systems management, security, infrastructure constraints, technology standards
constraints, and geographic/configuration constraints.

Viability assessment
This work product describes architectural risks, prioritizes (high, medium, and low) the
probability and impact of each, and identifies contingency plans for each risk item.

Work products produced by SDM

The Software Deployment Method produces three work products that are critical to
deployment success:
򐂰 The Value Realization Model (VRM)
򐂰 The Deployment Plan
򐂰 The Readiness Plan

The Value Realization Model defines value to the customer and IBM. The Deployment Plan
ensures IBM has a plan for deploying the software. The Readiness Plan ensures that the
customer is ready to deploy the software. This section contains descriptions of each of these
work products and their subwork products.

Value Realization Model (VRM)

The purpose of this work product is to ensure that IBM and the customer fully understand how
the customer plans to measure deployment success. It includes work products and reports
that will baseline and monitor performance during the entire customer life cycle. The Value
Realization Model is developed and updated continuously. It contains the following subwork
products:
򐂰 Customer Goals and Milestones: It is vital to work with the customer Executive Business
Sponsor at the beginning of the process to agree on and document the customers’ 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 and rate of return (ROI/ROR). For more information on ROI/ROR,
see Chapter 8, “Achieving return on investment” on page 65. Finally, develop a plan with
the customer to achieve a quick deployment win. This should be a visible project that can
be successfully deployed in three to six months and will act as a catalyst for future
success.
򐂰 Gap Analysis Report: The gap analysis report list products that will be 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.
򐂰 Deployment Milestone Status Report: Deployment milestones and metrics are the
critical checkpoints and measures that the Software Deployment Team defines with the
customer. The team then follows them closely to ensure that deployment progress is on
track.

100 Optimizing Software Deployment: An Insider’s Guide

򐂰 License Utilization Report: This report supports proper license management. It may be
the output of a license management tool such as 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 customer goals and milestones and present an updated view of the
progress.

Deployment Plan
This work product is included to ensure the architect has considered key requirements for
deployment success in the selling cycle of the customer relationship. The Deployment Plan
ultimately includes a full mapping of projects to products purchased. It is not meant to
duplicate planning around a single engagement being executed by implementation services.
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, the
customer has 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 sale.
򐂰 Documented linkages of deployment projects to Software Group (SWG) products:
Like the previous mapping of projects to business initiatives, this subwork product
documents the SWG brands and products included in each project. This provides a direct
tie to the products just purchased. This tie can help re-justify the software purchase to new
customer management, identify gaps in projected deployment, and align the deployment
timeline with the customer business initiative timeline.
򐂰 Deployment services requirements: This subwork product 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.
򐂰 Status of environment and infrastructure requirements: Any ancillary prerequisites or
co-requisites 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 by the customer 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 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.
򐂰 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

Appendix A. Work products: Usage and examples 101

 projects, groups deployment into logical chunks, contains a deployment timeline, and
includes a services assessment.
򐂰 Architecture plan: Deployment architecture is the blueprint of what will be deployed in the
customer account. It combines the work products of TeAM 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 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. Present this information to the customer to prevent
unwelcome surprises later in the deployment cycle.
򐂰 Milestone status report: There should be ongoing communication with the customer
Executive 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 customer
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 in a section of the Project
Control Book. The Project Control Book is available for review by IBM and customer
management and serves as the overall assessment of the project.

Readiness Plan
This new work product was created to ensure that the technical sales team evaluates the
customer’s readiness for deployment. In regard to the following subwork products, the
technical sales representative should consider where extra planning may be necessary to
minimize deployment risk. Decisions made in the Readiness Plan should be based on an
historical perspective of the customer. The subwork products are:
򐂰 Communication Plan: Consider who the stakeholders are and who the sponsor or owner
is for all internal and external communications.
򐂰 Migration Plan: This should include the implementation environment, change control
processes, code promotion/versioning, and a test plan.
򐂰 Education Plan: Document the skills assessment, roles, and any justification needed for
education expenditures.
򐂰 Architecture Plan: This plan documents security requirements, systems and data
integration points, and functional requirements.
򐂰 Operations Plan: Identify backup and recovery processes and owners, disaster recovery
plans, help desk environment, systems management disciplines, availability management,
logging, monitoring, etc.
򐂰 Risks, Dependencies, Assumptions & Constraints: This 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.

102 Optimizing Software Deployment: An Insider’s Guide

 For additional Readiness Plan information and examples, go to the following Web site and
install the Xpertise Library. From that database, select the Readiness Plan shared asset.
https://w3-3.ibm.com/software/sales/salesite.nsf/salestools/
Information+and+People$XpLibInfo

SDM phases, activities, and work products

Table A-1 shows the inputs and outputs for each activity in Phase 0 of the Software
Deployment Method.

Table A-1 Inputs and outputs for the activities in Phase 0 of the Software Deployment Method
Inputs Activities Outputs

򐂰 Need or requirement to form a team DM 0: Create a SDT Results

򐂰 SDT established
򐂰 Team members understand their
roles and are committed to the
team's purpose and goal or goals

SSM DM 1: Review documents Work products

򐂰 Draft contract 򐂰 List of open items for enterprise
򐂰 Integrated solution concept contract
򐂰 Introduction plan
TeAM 򐂰 Updated viability assessment
򐂰 Customer requirements or use 򐂰 Draft goals and milestones
cases document
򐂰 Business context diagram and 򐂰 High-level mapping of business
description initiatives to projects
򐂰 System context diagram 򐂰 Draft mapping of projects to products
򐂰 Conceptual architecture 򐂰 Initial software utilization report
򐂰 Architectural decision document
򐂰 Initial viability assessment
򐂰 Current organization
򐂰 IT standards
򐂰 Current IT environment
򐂰 Project description

SSM DM 2: Develop high-level plan Work products

򐂰 Introduction plan 򐂰 Updated goals and milestones
document
TeAM 򐂰 High-level phased deployment plan
򐂰 Viability assessment 򐂰 Detailed mapping of products to
򐂰 Architectural decision document projects to business initiatives
򐂰 Solution architecture, including 򐂰 Services requirements document
architecture overview 򐂰 Initial Readiness Plan findings
򐂰 Component model 򐂰 Gap analysis report
򐂰 Internal interface descriptions 򐂰 Environment and infrastructure
requirements
SDM 򐂰 Updated license utilization report
򐂰 Goals and milestones document 򐂰 Customer profile document
򐂰 Software deployment best practices
򐂰 High-level mapping of business
initiatives to projects
򐂰 Draft mapping of projects to products
򐂰 Initial license utilization report
򐂰 Readiness Plan template

Appendix A. Work products: Usage and examples 103

 Inputs Activities Outputs

򐂰 Updated goals and milestones DM 3: Establish deployment Work products

document partnership with customer 򐂰 Revisions to architecture plans if
򐂰 High-level phased deployment plan needed
򐂰 Detailed mapping of products to 򐂰 Deployment quick-win plan
projects to business initiatives 򐂰 Updated goals and milestones
򐂰 Services requirements document document
򐂰 Initial Readiness Plan findings Results
򐂰 Gap analysis report 򐂰 Validated high-level phased
򐂰 Environment and infrastructure deployment plan
requirements 򐂰 Validated detailed mapping of
򐂰 Updated license utilization report products to projects to business
initiatives
򐂰 Validated gap analysis report
򐂰 Validated Readiness Plan findings
򐂰 Software deployment best practices
findings and actions
򐂰 Validated environment and
infrastructure requirements
򐂰 Validated services requirements
document
򐂰 Validated license utilization report
򐂰 Kickoff meeting scheduled

104 Optimizing Software Deployment: An Insider’s Guide

 Table A-2 shows the inputs and outputs for each activity in Phase 1 of the Software
Deployment Method.

Table A-2 Inputs and outputs for the activities in Phase 1 of the Software Deployment Method
Inputs Activities Outputs

SSM DM 4: Refine deployment plan Work products

򐂰 Signed (final) contract provided by 򐂰 Refined physical deployment
the Software Account Manager architecture, including operational
(SAM) model
򐂰 Refined deployment and systems
SDM management plans
򐂰 Architectural overview 򐂰 Updated environment and
򐂰 Component descriptions infrastructure requirements
򐂰 Internal interface descriptions 򐂰 Proposed (draft) project controls
򐂰 Business initiatives 򐂰 Updated readiness and quick-win
򐂰 Revisions to architecture plans plans
򐂰 Validated high-level phased
deployment plan
򐂰 Validated detailed mapping of
products to projects to business
initiatives
򐂰 Deployment quick-win plan
򐂰 Goals and milestones document
򐂰 Software deployment best practices
findings and actions
򐂰 Validated services requirements
document
򐂰 Validated Readiness Plan findings

TeAM DM 5: Finalize deployment plan Work products

򐂰 Refined physical deployment with customer 򐂰 Final deployment architecture
architecture, including operational 򐂰 Final physical architecture
model 򐂰 Final operational model
򐂰 Final deployment plan
SDM 򐂰 Final systems management plan
򐂰 Refined deployment and systems 򐂰 Final project controls
management plans 򐂰 Final deployment quick-win plan
򐂰 Updated environment and 򐂰 Final goals and milestones
infrastructure requirements document
򐂰 Proposed (draft) project controls 򐂰 Readiness Plan
򐂰 Updated readiness and quick-win
plans Results
򐂰 Software deployment best practices 򐂰 Customer approval of work products
򐂰 Best practices understood and
agreed upon

SSM DM 6: Conduct deployment Results

򐂰 Final contract kickoff meeting 򐂰 Synergy and enthusiasm for the
򐂰 TeAM upcoming deployment
򐂰 Architecture plans and descriptions 򐂰 High-level understanding of the
contract terms and conditions
SDM 򐂰 Communicated vision and business
򐂰 High-level deployment plan value
򐂰 Goals and milestones document 򐂰 Understanding of roles and
򐂰 Software deployment best practices responsibilities, deployment
ownership, and software deployment
best practices
򐂰 List of follow-up items from the
meeting

Appendix A. Work products: Usage and examples 105

 Table A-3 shows the inputs and outputs for each activity in Phase 2 of the Software
Deployment Method.

Table A-3 Inputs and outputs for the activities in Phase 2 of the Software Deployment Method
Inputs Activities Outputs

򐂰 List of projects and owners DM 7: Begin quick wins Work products

򐂰 Project plans for quick deployment 򐂰 Updated and refined Readiness Plan
wins associated with quick-win projects
򐂰 Readiness Plan
򐂰 Software deployment best practices Results
򐂰 Quick-win deployment projects
completed

TeAM DM 8: Execute the deployment Work products

򐂰 Final deployment architecture plan 򐂰 Deployment milestone status reports
򐂰 Final physical architecture 򐂰 License use reports
򐂰 ROI/ROR status reports
SDM
򐂰 Software deployment best practices Results
򐂰 Readiness Plan 򐂰 Deployed software that achieves the
򐂰 Final environment and infrastructure customer's goals
requirements 򐂰 Completed projects
򐂰 Final deployment plan
򐂰 Final systems management plan
򐂰 Final project controls
򐂰 Final deployment quick- win plan
򐂰 Final goals and milestones
document

򐂰 Deployment plan DM 9: Scan account for new Results

򐂰 Goals and milestones document opportunities 򐂰 Opportunities identified
򐂰 Gap analysis report and feedback 򐂰 New products deployed
from customer business owner 򐂰 New demand generated
򐂰 New customer requirements 򐂰 Value of contract realized

򐂰 Opportunities identified during steps DM 10: Amend or renew the Results

DM 8 and DM 9 enterprise agreement 򐂰 New demand identified by client and
򐂰 Deployment milestone status reports account teams
򐂰 Feedback from project owners
򐂰 Anything that substantiates the
success of the deployment that just
completed

Work product examples

There are several examples of work products produced by TeAM and SDM. They are listed
alphabetically in this section for easy reference. Throughout the examples, COMPANY A
represents our example customer.

Example: Architecture decisions document

A summary of this document is presented here:
1. Integration architecture
Use a transformational hub to provide more economical systems maintenance and to
make the legacy systems more flexible.

106 Optimizing Software Deployment: An Insider’s Guide

 2. Legacy application access
Use component/services architecture to provide economy of reuse for legacy applications
and to enable a transformational hub.
3. Application runtime architecture
Use browser-client architecture instead of client/server or host-based development to
lower support costs and to provide business function over the Internet.
4. Application development architecture
Use an object-oriented paradigm for new development. Separate the model, view, and
controller cleanly.
5. Application development platform
Use Java as an object-oriented language for browser-client development. Use the
servlet-JSP-bean model to separate the 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 a messaging
system. Provide single sign-on 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 the flow between
applications and third-party packages.
9. Dependability of distributed systems
Provide availability/fault tolerance for reduced instruction set computer (RISC)-based
systems (and any Windows® systems running production applications).
10.Disaster recovery for Internet and intranet
Provide disaster recovery for all production systems, including browser-client applications.
11.Portal
Use a portal-based Web interface to provide a coherent and personalized user console.
12.B2B application integration
Use Web services as the standard interface to implement remote application invocation.
13.Level of integration
Use a process integration style of integration for connecting applications together.

Example: Architecture overview diagram

The integration design is in three parts:
򐂰 Integration hub: This 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 a data Extraction,
Transformation and Loading (ETL) tool.
򐂰 Gateway: This provides Internet and network access for machines. It consists of such
technologies as electronic data interchange (EDI), messaging, and Web services.

Appendix A. Work products: Usage and examples 107

 򐂰 Portal: This provides Internet and intranet access for humans. It consists of the Internet
infrastructure and associated devices.

Figure A-2 shows these three parts.

legacy
applications
gateway
external
external
networks workflow new
networks server integration
packaged
hub
applications
portal
application
server
(new apps)
content
management
system
Citrix EIP
apps

Figure A-2 Architecture overview diagram

Example: Business context diagram

This e-business solution deals with several complex systems. They include COMPANY A’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.

The new packages that were not selected were necessarily 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-3 shows an example of a business context diagram.

108 Optimizing Software Deployment: An Insider’s Guide

 Business
Business Agencies
Agencies
Regulatory
Regulatory Partners
Agencies
Agencies Partners

Brokers
Brokers

Claims
Claims

System
System Billing
Billing

Regional
Regional
Offices
Offices agency/producer
information

Underwriting
Underwriting
District
District Policy
Policy
Offices Issuance MIS
MIS
Offices Issuance

Figure A-3 Business context diagram

Example: Current IT environment

This section provides an example of a description of a company’s existing IT environment.
The company’s departments include:
򐂰 Actuarial
򐂰 Claims
򐂰 Financial
򐂰 Underwriting
򐂰 Risk Management
򐂰 Human Resources
򐂰 Operations

The IT environment is further broken down as outlined here:

򐂰 Insurance Applications
– Workers' Compensation
• Underwriting: Insurity - vendor- uses Citrix, Intel®
PRC - (from Insurity - rating engine - Citrix)
• Claims: New Claims - host app - COBOL, DB2, IMS™, CICS®
• FNOL: C/S - VB, SQL, ASP (browser based)
– Property and Casualty (PAL®)
• Underwriting: PCIS (PowerBuilder, Sybase, SQL - confirm)
• Claims: PCCS (PowerBuilder, Sybase, SQL)
• FNOL: Currently PCCS, will go to FNOL

Appendix A. Work products: Usage and examples 109

 – Disability
• Underwriting: IMACS (COMPANY A1)
• Claims: IMACS (VSAM)
• FNOL: Currently IMACS? will go to FNOL
򐂰 Risk Management
Cinch - VB, Citrix
򐂰 Billing
AMP
򐂰 Human Resources
PeopleSoft
򐂰 Financial
Oracle, VB, Excel, Access (must be kept in sync with other systems)
򐂰 Operations
Boole and Babbage
򐂰 Actuarial
Spreadsheets
Desktop
IBM NetVista™ 6792-24U
256 MB RAM
20 GB hard drive
17-inch monitor

System Software
OS/390® 2.10.0
CICS/ESA® 1.3.0
ISPF 2.10.0
MVS/ESA™ SP JES2 2.10.0
ICKDSF 2.10.0
EREP 2.10.0
System Dispatcher and Search Facility 2.10.0
GDDM/MVS™ 2.10.0
SMP/E for OS/390 2.10.0
VS COBOL II Compiler/Library/Debugger 1.4
ISM/ESA Database Manager 6.1.0
TSO/E 2.10.0
NETVIEW OS/390 1.3.0
Database 2™ (DB2) 6.1.0
C/370™ Library 2.10.0
Language Environment/MVS 2.10.0
Object Distribution Manager 3.1.0
CICSPLEX SM/ESA 1.3.0
MVS/DITTO Utility 1.3.0
MVS/EPDM
ACF/VTAM® Communications Server 2.10.0
IBM GDDM® – PGF 2.10.0
MVS/DFSMS 2.10.0
Assembler High Level 2.10.0
QMF™ 6.1.0
OS/VS COBOL Compiler and Library 2.4

110 Optimizing Software Deployment: An Insider’s Guide

DFSORT™ 2.10.0
DB2 Administration Tools 3.10.0
COBOL 2.1.0
Third-party software
Allen Systems Group JCLPREP 4.1.1
Allen Systems Group Beta42 2.1.2
BenData Heat 6.01
Boole & Babbage Auto Operator for CICS 6.1.0
Boole & Babbage Auto Operator for MVS 6.1.0
Boole & Babbage MQ Automation S/390® 6.1.0
Boole & Babbage CMF Monitor OS/390 5.3.02
Boole & Babbage MV for CICS 5.4.0
Boole & Babbage MAINVIEW for DB2 6.1.0
Boole & Babbage MV Focal Point 1.2.0
Boole & Babbage MV for OS/390 2.5.02
Boole & Babbage MQ for S/390 4.0.0
Boole & Babbage MV VISTAPOINT 1.1.3
Boole & Babbage Resolve Plus 3.2.0
Boole & Babbage RXD2 Link 2.1.0
Boole & Babbage RxD2 Flex Tools 2.1.0
Computer Associates ACF2 6.3
Computer Associates CA90s 1.0
Computer Associates CA1 5.2 SP3
Computer Associates CA11 2.2
Computer Associates Librarian 4.3
Computer Associates DADS Plus 3.5
Computer Associates CICS Sort 2.1
Chicago Software QuickReference 5.7
Compuware Xpediter CICS 7.2
Compuware Xpediter TSO 6.3
Data21 CICSHELP 4.6B
Datura
Document Systems Silver Plume 2.4
EMC Catalog Solutions 8.3
EMC INFOMOVER 3.1.9
EMC Solutions Enabler 4.2
Group1 Group1 1.3
GT Software GTB BMS 6.4
Innovation FDR 5.3.44
Innovation FDR/COMPACTOR 5.3.44
Innovation FDR/SOS 5.3.44
Innovation FDR/UPSTREAM 3.1.5
Innovation FDR/UPSTREAM PC 3.1.5
ISI
KPI
Macro-4 DumpMaster 4.7
Macro-4 Insync 3.3.2.0
McKinney Systems CICS Message 5.0
McKinney Systems CICS News 3.0
McKinney Systems Listcat Plus 6.9
Princeton Softech Move for DB2 5.0
PROGINET IND$FILE 3.2B
SEA TRMS 5.1.A#5
SERENA Comparex 8.3.0

Appendix A. Work products: Usage and examples 111

 SYBASE Direct Connect 11.7
TSI Keymaster 6.1

Current application deployment

While most of COMPANY A’s systems were originally mainframe applications, some
client/server applications were developed. There is an increasing awareness of the benefits of
development under Internet-based technologies. At the moment, the important platforms are
System 390 and Windows Client/Server.

Although current consideration is being given to remove the UNIX® systems, the available
UNIX hardware and expertise should be retained. They constitute the most likely platform for
the deployment of the Internet, intranet, workflow tool, and the integration hub.
Windows-based systems are likely to continue to be unreliable and to have security problems
(see Meta Group or Gartner for perspectives on this platform).

It is likely that COMPANY A will also find that as new business packages are implemented,
the UNIX platform becomes increasingly important both as the systems platform for those
packages and probably as servers for browser-based applications. It is certainly the case that
COMPANY A will retain both the Windows and host platforms for a long time. However, for
distributed programs, and for middleware systems, the UNIX platform is more dependable
than Windows and easier to implement than the host-based equivalents.

Figure A-4 shows an example of the current application deployment.

Claims
Partner New Claims
Premium
Policy

Insurity System 390

Citrix
IE 6.0

AMPS
Windows Notes – Mail
PCCS
Insurity
Branch Office PCIS
Spreadsheets, Access
Actuarial
xBase/App Dev
Triangle
Citrix Apps
Pipeline

Broker/Agency
RS 6000 Windows

Internet Intranet
District
Office
Web

Figure A-4 Current application deployment

The current architecture

Because the architecture represents the current default method of building net-based
applications, it is important to understand both the architecture and the implications of its use.

112 Optimizing Software Deployment: An Insider’s Guide

 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 IIS server
using an Active Server Page (ASP). The IIS server runs a Visual Basic program that connects
to a second IIS server on an EIP machine. This IIS server then connects through WebSphere
to EIP and then to the ImagePlus® system.

This somewhat unlikely 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-5 shows an example of the current architecture.

Nfuse
Server App Server EIP Server DB2

Citrix Server IIS IIS Image

Desktop Plus
Browser Visual Index
Web Basic
Browser WebSphere
Server
Citrix ASP App Image
Plug-in Server Plus
Data

Brio EIP
Plug-in BRIO SQL Server

report
data

Figure A-5 Current architecture

Appendix A. Work products: Usage and examples 113

Example: Current organization diagram
Figure A-6 shows a sample of a current organization diagram.

Vince D
President

Frank Altera
Underwriting Claims CIO CFO COO Branch Ops Managed Care
Steve W
Henry S open (Vince) Jim K Bill H Ray P John S Monica O

Data Mangmt Claims FNOL Underwriting Operations

Joe F Stephanie U Kathy Y Susan H Charles E

Cinch Reporting
Web Apps Workers' Comp
Datamart Comml Auto
CIS PCIS
One Brian W David M Financial A/R Quan N S. V S. M DBA
Notes/Web Premium Corp
Actuarial Reporting
Client Systems Forms Lotus Notes Mail & Copy Help Desk
Data Quality Appl. Architecture
Support Call Center Admin Printing Procurement
End User Appl/Systems
Financial/Claims Med. Only Networking & Dist. & MAC
Support
Image Team Services Prod. Control Telecom
Appl. Interfaces
Management CICS & RICS Storage Admin PC Support
Corp. S/390 Security
Data Center

Figure A-6 Current organization diagram

Example: Envisioned goals and issues

COMPANY A 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
COMPANY A’s 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 Chief Information Officer (CIO) made a carefully
reasoned buy-don’t-build decision and intends to move toward a standard of buying
application packages. The intent is 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.

Note: When the Insurity package was installed, 30 different systems had to be modified.
Even after that integration, it is still tightly coupled.

Two other efforts are to be combined with this move. First, the integration of a new workflow
with the imaging system should be considered in the context of the move to application
packages. Second more productive business use from the Internet and intranet should also
be planned within the context of an overall integration architecture.

114 Optimizing Software Deployment: An Insider’s Guide

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
Insurity (rating)
• A new auto package (issue - integration interface)
• A package for PCIS
• Policy issuance system
• Premium
• Financial
– Implement integration architecture
Replace homegrown messaging and polling mechanisms
– Use and reuse
Develop once and use as needed
– Centralize information
• Client profile
• Agency/Broker information
• Consolidation of small datastores (see Claim example)
򐂰 Replace aging imaging system
Provide 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 a gateway for external applications and Web services
Enable COMPANY A to broker on-line applications between agent and carrier
– Provide a 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
򐂰 Provide a single face to system users and personalized portal
– Provide portal and personalization function
– Use a browser and hub to provide a front end for an array of different applications

Appendix A. Work products: Usage and examples 115

 򐂰 Provide an architecture to accommodate heterogeneous technologies
– Need to integrate; no more islands of process
– Provide for multiple technologies on multiple platforms

The company needs two main systems (Figure A-7).

Claim
Client Agent/
Profile Broker
Policy
System System
Billing

Figure A-7 Sample required systems

Example: IT standards
The following items are de facto standards, since they appear to be adhered to by default.

Host platform
OS390 v 2.10
COBOL
VSAM
IMS
Image Plus
CICS v. 1.2
DB2 v. 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

116 Optimizing Software Deployment: An Insider’s Guide

 Browser client
Citrix plugin
IP
IE 6.0

Development
Visual Basic
Power Builder
COBOL

Example: Mapping business initiatives to projects

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

Table A-4 Mapping business initiatives to projects

Topic Key Goal #1 Goal #2

Business goal Strategic business goal Improve employee Reduce training costs
productivity

Business initiative Customer’s name for Collaboration Distance Learning

business initiative

Project name Customer’s name for the Advanced collaboration Enterprise eLearning
project or initiative

Project description Brief description Enterprise-wide rollout of Training for merger, agents,
collaboration tools call center, applications

Customer sponsor E = executive E = Mary Smith P = John Doe

P = project
(include contract info)

Project status Customer’s project status Plan Plan

Existing solution or None *Placeware,

competition *ASP Berbee
LearningSpace®

Annual cost of existing Unknown ASP through Berbee

solution or competition Approx. $4,000 per month
+ per user access

Money in budget Yes/No and amount if None Yes

known

Decision date 10/01/2002 08/09/2002

Deploy date 11/01/2002 10/01/2002

Comments Currently piloting 40 Stated corp. evaluation in

licenses of ST in the April/May by Dave M’s team
Minneapolis location.
Looking at enterprise
rollout.

Appendix A. Work products: Usage and examples 117

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

Table A-5 Mapping projects to proposed products and solutions

Topic Key Project #1 Project #2

Project name From business initiatives Advanced collaboration Enterprise eLearning

sales aid

Proposed IBM product or Product name SameTime LearningSpace

solution Collaboration

IBM software part number PA number D5CT2LL D5CPRLL

Function What does it do? Real time chat and Distance learning
e-messages

Business value Value to customer Less phone tab, less travel, Reduced travel and tuition
faster response training expense

Quantity 7000 7000

BAU unit price Normal PA discounted $28.12 $41.64

price

MLC Or other non OTC if

applicable

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

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

M = member
(include contact info)

Comments Licenses of SameTime in Stated corp. evaluation in

the Minneapolis location. April/May by Dave M’s
Looking at the enterprise team.
rollout.

118 Optimizing Software Deployment: An Insider’s Guide

Example: Operational model
Figure A-8 shows an example of an operational model diagram.

CA
Production Environment (e.g.
VeriSign)

Internet
LDAP Directory Server NM Shared Services
IBM Directory or Sun ONE Directory WMQ Cluster
(Primary + Backup)

Firewall Firewall
Application Servers
Load Balancing Web Servers Security Mgmt
WAS, WMQ
and Failover IBM HTTP Server ITAMBI
(# based on load)
WebSphere Edge Server or other
or other (# based on load) Messaging/Integration Hub Mgmt Console
(Primary + Backup) WMQIB ITMBI, ITAMBI
CrossWorlds ICS + WBC
4-way Unix or better

Development Environment (Adapters for

Siebel et.al. are
Database Server(s) BPM / Workflow
DB2 UDB not shown) MQSeries Workflow
(Primary + Backup) (Primary + Backup)

Test/stage
Test/Stageenvironment,
Environment similar to production
- similar environment
to Production except: except:
򐂰 Backup servers are not needed unless failover is to be tested in
Development Workstations
Ÿ the test/stage environment.
Development Development
Development Serverserver
Windows 2000
workstations Windows 2000
Windows or Unix
2000 or UNIX Backup servers are not needed unless failover is to be tested in the
򐂰 test/stage
Serversenvironment.
WBI Tools HTTP Server
Windows 2000
Holosofx HTTP
WAS, WMQ Server can be sized smaller than for production, and the
WSAD-IE
WBI Tools WAS,
LDAP WMQ
Server Ÿ Servers can be sized smaller than for production, and the number of
WMQ WMQI Server
LDAP
number of replicated servers can be reduced, unless an identical
replicated servers can be reduced, unless an identical envrionment is
Holosofx
CrossWorlds ICS + WBC
WSAD-IE MQSeriesWMQI
Workflow
environment
desired is desired for load testing.
for load testing.
WMQ DB2 UDB ICS + WBC
CrossWorlds
MQSeries Workflow
DB2 UDB

Figure A-8 Operational model diagram

Example: Project descriptions

The project description includes the items outlined in the following sections.

Web site
򐂰 General purpose suite:
– Audience: General Public
– Suggested content: There must be mass advertising, a regular home page, message
for the president, navigation to other suites, staffing, and recruiting. The site must
include contact us, phone directory (Call Center, offices), and office locator information.
򐂰 Client Suite:
– Audience: Clients
– Suggested content: There must be access to Cinch (includes FNOL), risk control
bulletins (possibly customized by class of business), provider referral, panel and
directory access, targeted advertising, online policy and certificates, proof of coverage,
e-billing for direct bill, e-pay, and to contact the call center.

Appendix A. Work products: Usage and examples 119

 򐂰 Agent Suite:
– Audience: Agents and Brokers
– Suggested content: There must be access to Cinch for agents, e-billing, targeted
advertising, access to online quoting, on-line policy and certificates, e-pay.
On the two sites, we present a custom view of services reflective of who is coming to
the site. Simply loading the company logo on the site at presentation is a small
example.
The service sections of the sites will eventually present different services and products
based on the logged party, for example, risk control information that is relevant to the
industry of the client.
򐂰 Employee Suite:
– Audience: Employees
– Suggested content: There must be access to FOCUS, self-administered benefits
(address changes on line), online computer-based training, e-mail, and the employee
handbook.
This suite will be accessible internally (intranet) and externally (Internet).
Procedure manuals, such as the CIC, etc., are accessed through applications but can
be part of the employee suite. The employee suite as described is focused on the
employee, for the employee.

Underwriting
򐂰 Replace premium
򐂰 New billing application
򐂰 Customer profile
򐂰 Broker/agency profile
򐂰 Replacing issuance systems

Claims
򐂰 Replace three claims systems to make one: Claims reconstruction
򐂰 Replace reporting systems
򐂰 Bottom Line, PayBase: Pay claims electronically
򐂰 Replace billing system
򐂰 Replace Image Plus

FNOL
򐂰 Modifications to new FNOL (for disability): Messaging and polling

Data
򐂰 Combine actuarial ODSs into one datamart
򐂰 Redesign of functional ODSs: Claims, policy, billing, employee
򐂰 Balance and reconciliation
򐂰 Some Notes development

Operations
򐂰 Token-ring migration to Ethernet
򐂰 Novell migration to Windows 2000

120 Optimizing Software Deployment: An Insider’s Guide

Example: System context diagram
Figure A-9 shows an example of a system context diagram.

External Entities
(Business Partners,
Vendors, ASPs)
Pervasive
Customized
Computing requests for
Devices information made XML documents returned
over wireless from partner
protocols site/application over HTTP
XML documents or HTTPS *
Customized delivered to
presentation external systems
delivered to client over HTTP or
using wireless HTTPS
protocols
Asynchronous or
Synchronous request
Request for informational for data or transactions
and business data issued over TCP/IP
over HTTP or HTTPS Web Services
Browser-based
Internet Client e-business Directories
HTML and XML documents, Application
audio, video and image files
delivered over HTTP or
HTTPS

Requests for
information made
over HTTP and Asynchronous or
HTTPS Synchronous request
for data or transactions
over TCP/IP
Asynchronous
Information or Synchronous
Browser-based delivered to a full responses over
function client TCP/IP
Intranet Client desktop over HTTP Legacy Systems
& HTTPS and
Databases

Figure A-9 System context diagram

Example: Use cases

This section presents examples of several use cases.

General
Because the projected changes to the system involve several black-boxed applications
(systems that have not yet been selected), it is not possible to obtain accurate non-functional
requirements. Although gross approximations can be used, the system must be sufficiently
scalable to accommodate substantial differences in the actual build out.

Performance
For Internet-based applications, the target of a seven-second response time is assumed. For
processes that appear to take longer than this limit, a wait screen and time estimate are
required.

Intranet applications are assumed to be required to perform in roughly the same manner as
the existing client/server programs, but there is no specified requirement for this.

Appendix A. Work products: Usage and examples 121

 The performance expected from the new generation of application programs is partly
contingent on the nature of the application package selection.

Capacity/volumes
򐂰 UW workstation: 100 heavy users, 300 users
򐂰 Standard desktop: 1000 users

Scalability
Because we do not know the identity of the third-party packaged systems that will be
installed, the integration scheme must be easily scalable.

The possibility of mergers and takeovers also requires this capability.

Availability/fault tolerance
A modern insurance company, under any circumstances, cannot operate for long without its
computer systems. When business functionality is pushed out to the customer, broker, agent,
or carrier, the ability of the system to tolerate faults becomes increasingly critical.

Although brief system downtime may acceptable for some applications, in general,
fault-tolerant failover should be provided to all customer- and partner-facing systems. There
does not appear to be an absolute need for 24x7 availability, since no international market is
involved.

Portability
An initial requirement of this architecture is the platform independence of the enterprise
backbone. The architecture is to accommodate heterogeneous technologies. In the CIO’s
expression, COMPANY A requires “engineering for agility”.

Maintainability
While there are no specific goals for maintainability, the cost of maintaining the company’s
desktops is extremely high. Gartner Group estimates the cost of client/server-based desktops
to be about $12,000 per year. Calculated over 1000 desktops, this number approaches $12
million per year.

This number is substantially higher than necessary and can be reduced.

Usability
Currently most systems are host-based or client/server. The client/server applications do not
appear to use particularly complex GUI widgets or drag-and-drop. Since a substantial portion
of the general workforce is now acquainted with using browser-based applications, new
development (and package selection) may be reasonably expected to take advantage of a
browser platform. It appears unlikely that COMPANY A will develop new application using a
3270 interface.

Security
End-to-end security should be specified before application package selection. There are
serious issues in moving exposed client information over the Internet, in personal identity
security, and in credit cards. In general, security functions should not be performed within
applications, but should be abstracted with a reliable external security system.

Overall, the system should have few entry points, should use hardened gateways, and should
authenticate users at entry points, not within applications. The system should have security

122 Optimizing Software Deployment: An Insider’s Guide

 code distributed to only a few points, should extend end-to-end, and should be based on
modularity rather than an interdependence between security and applications.

Single sign-on is desired.

Infrastructure constraints
There is a limited bandwidth to the branches. COMPANY A does not always have control over
its partner organizations, nor over their standards.

Some business applications that are host legacy systems need to be run long after their
replacements are implemented.

Geographic and configuration constraints

There are no constraints on technology usage or architecture.

Example: Viability assessment

Table A-6 presents a sample table for assessing viability. This includes determining the
probability and impact of the viability:
򐂰 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 it won’t 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. The decisions are 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.

Table A-6 Viability assessment tool

Risk Risk description Probability Impact Contingency/mitigation Initiative
ref. (H/M/L) (H/M/L)

1 Point-to-point connectivity for H H Adopt integration architecture to avoid

COMPANY A applications will point-to-point connections.
continue to become
increasingly expensive and
rigid.

2 Homegrown messaging M-H M Use standard third-party queuing

functions are likely to be mechanism.
unreliable and expensive to
maintain.

3 Current browser-client model H M-H Provide a more standard and efficient

(using Citrix) will become browser-client model.
expensive and unwieldy.

4 Lack of end-to-end security M M-H Provide end-to-end security for

architecture will result in integration architecture.
excessive exposure and
maintenance cost.

Appendix A. Work products: Usage and examples 123

 Risk Risk description Probability Impact Contingency/mitigation Initiative
ref. (H/M/L) (H/M/L)

5 Increasing need for partner H M Implement B2B architecture with

communication will expand integration architecture.
expensive use of
point-to-point connectivity.

6 Support cost for desktop will H M Enforce existing desktop standards.

continue to rise. Standardize on thin client intranet
development. Standardize reporting
tools. Provide desktop data backup.
Standardize printing strategy.

7 Lack of system monitoring M ? Provide system and performance

will create unpredicted monitoring tool.
outages.

124 Optimizing Software Deployment: An Insider’s Guide

 B

Appendix B. SAM, SWA, and SDA

responsibilities
This appendix contains descriptions of the Software Account Manager (SAM), Software
Architect (SWA), and Software Deployment Architect (SDA) roles that most actively involved
in a software deployment. Many of the following individuals are involved in the successful
sales and deployment of software, hardware, and services.
򐂰 The Software Sales Team consists of the following members:
– Sales (non-technical)
• Software Account Manager (SAM)
• Software Sales Specialist (SSS)
– Technical Sales Support (TSS)
• Technical Sales Manager (TSM)
• Software Architect (SWA)
• Software Deployment Architect (SDA)
• Software Technical Sales Specialist (ITS)
• Bid Manager (also known as the Deal Maker in the Americas)
򐂰 The Client Team includes the following members:
– Client Executive
– Client Representative
– Client IT Architect
– Managing Director
򐂰 The customer’s Enterprise Business Sponsor

For a description of all of the roles previously listed, see Chapter 2, “Roles and
responsibilities” on page 17.

© Copyright IBM Corp. 2003. All rights reserved. 125

SAM role and responsibilities

Mission The Software Account Manager sells IBM Software in selected large accounts or Small and
Medium Business (SMB) territories and builds customer relationships.

Value to IBM They formulate sales strategies that apply IBM Software strategies to their customers’
business strategies. They sell software that generates revenue for IBM.

Value to customer Each SAM provides a single “sales face” to the customer across all the software brands in their
assigned accounts. They work with their customers to define a strategy for the account,
manage customer relationships and problems, and negotiate long-term software contracts.

Responsibilities 򐂰 Grow total software revenue at their assigned accounts.

򐂰 Increase IBM Software market share at their assigned accounts by competitive winbacks.
򐂰 Build the mindshare at the account for IBM Software by providing leadership across all of
IBM Software pillars.
򐂰 Develop and present to the customer the IBM Software strategy.
򐂰 Coordinate the IBM Software team behind this strategy, including pillar sales and
technical specialists (WebSphere, Data Management, Tivoli, Lotus, and Rational).
򐂰 Increase customer satisfaction with IBM's software solutions.
򐂰 Develop creative, winning tactics for large opportunities, such as pricing, packaging,
service offerings and hardware offerings.
򐂰 Take a leadership role in all key software opportunities.
򐂰 Manage IBM's software relationship with their customers.
򐂰 Provide consolidated forecasts for all software opportunities at their account.

126 Optimizing Software Deployment: An Insider’s Guide

SWA role and responsibilities

Mission Software Architects satisfy our customers' business and IT challenges by designing cohesive
solutions that leverage the capabilities of the entire IBM Software portfolio.

Value to IBM The Software Architect drives additional revenue by creating technical designs that apply the
complete IBM Software portfolio to customer needs.

Value to customer Software Architects are valued because they analyze a customer's business and IT
challenges. They then design a comprehensive solution that integrates smoothly into the
customer's environment and leverages the best of the entire IBM Software portfolio.

Responsibilities 򐂰 Understand how each individual IBM Software product compares and integrates with
other products from IBM, our partners, and our competition.
򐂰 Lead the development of architectural designs that integrate with existing customer
environments by employing accepted design methods, patterns, and best practices.
򐂰 Use knowledge of the IBM Software portfolio to develop the best software product
solution to match the architectural design.
򐂰 Lead the IBM Software team in transitioning the customer from the design to the
deployment phase.
򐂰 Use knowledge of customer’s abilities to systematically recommend appropriate
education and services.
򐂰 Use technical and business acumen to win and maintain influential relationships with key
customer and IBM decision makers.
򐂰 Provide technical leadership in the definition and expansion of the software technical
sales strategy for the assigned account or accounts.
򐂰 Build relationship networks with knowledge sources inside and outside of IBM and
leverage those relationships to solve customer challenges quickly.
򐂰 Investigate technology and industry trends and directions to proactively educate our
customers.
򐂰 Help to ensure work products are documented and transferable to other technical
professionals.
򐂰 Harvest and share reusable intellectual capital.

Appendix B. SAM, SWA, and SDA responsibilities 127

SDA role and responsibilities

Mission The Deployment Architect accelerates deployment of software solutions and designs
additional technical solutions that leverage the entire IBM Software portfolio to resolve
customer business and IT challenges.

Value to IBM Successful design and deployment of software solutions increases customer satisfaction,
minimizes risk, and positions IBM for future software revenue.

Value to Customer Successful design and deployment of technical software solutions assures customer
readiness, minimizes risk, increases customer satisfaction, and maximizes return on software
investment.

Responsibilities 򐂰 Lead the design and deployment of technical software solutions by leveraging design
methods, patterns, and best practices.
򐂰 Select 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 team to identify and deploy new and existing solutions.
򐂰 Understand how IBM’s offerings compare, contrast and integrate with the customer’s
existing software investment from IBM, business partners, and the competition.
򐂰 Lead Solution Assurance Reviews to help ensure action items are closed and risks are
mitigated.
򐂰 Use technical and business acumen to build and maintain influential relationship with key
customer and IBM decision makers.
򐂰 Build relationship networks with knowledge sources inside and outside of IBM and
leverage those relationships to avoid technical inhibitors to software deployment.
򐂰 Help ensure that the customer understands and actively takes steps to adhere to IBM
Software Group (SWG) Deployment Best Practices and the Readiness Plan.
򐂰 Help ensure work products are documented and transferable to other technical
professionals.
򐂰 Harvest and share reusable intellectual capital and deployment experiences.
򐂰 Help ensure software does not become shelfware.

128 Optimizing Software Deployment: An Insider’s Guide

 C

Appendix C. Software deployment checklist

This appendix contains a checklist of the activities and tasks for the Software Deployment
Method. You can print it and use it as a reminder of the items in each phase and to check
progress as you complete the items.

© Copyright IBM Corp. 2003. All rights reserved. 129

Software deployment activities

Activities Owner(s) Date completed Notes

DM 0: Create the Software

Development Team (SDT)

DM 1: Review the deployment

documentation

DM 2: Develop a high-level deployment

plan

DM 3: Establish a deployment
partnership with the customer

DM 4: Refine the deployment plan

DM 5: Finalize the deployment

DM 6: Conduct the deployment kickoff

meeting

DM 7: Begin the quick deployment win

activities

DM 8: Execute the deployment plan

DM 9: Scan for new deployment and

revenue opportunities

DM 10: Amend or renew the Enterprise

Agreement

Phase 0: Preparing for deployment

DM 0: Create Software Deployment Team

Tasks Owner(s) Date completed Notes

Create a Software Deployment Team.

Get commitment from each member.

Communicate roles and expectations.

130 Optimizing Software Deployment: An Insider’s Guide

DM 1: Deployment documentation

Tasks Owner(s) Date completed Notes

Discuss the customer buying decision.

Help ensure that the content, terms, and

conditions of the contract are thoroughly
understood.

Analyze software inventory and licensing.

Study substitution clauses.

Understand the status of maintenance

and support.

Discuss any expectations that may have

been set (primarily from the Enterprise
Business Sponsor).

Identify any critical relationships and

establish an introduction plan.

Discuss the content of deployment

methodology to help ensure that each
member of the account team understands
how the deployment phase will be
executed to maximize success.

Discuss license tracking and how the

customer should plan to track deployment
progress.

Review the requirements, solution

concept, business context, conceptual
architecture, and architecture decision
document.

Review/refine initial viability assessment

(includes results of a Solution Assurance
Review (SAR), if one was conducted).
This equates to an SDT confirmation on
the solution.

Considering the customer’s business

initiatives, document the linkages
between deployment projects and
products.

Identify who should be involved in the next

activity, DM 2.

Appendix C. Software deployment checklist 131

DM 2: Develop a high-level deployment plan

Tasks Owner(s) Date completed Notes

Conduct introductory meetings with the

customer per the introduction plan.

Validate/refine goals and milestones

document with Enterprise Business
Sponsor (EBS).

Refine the list of projects created in DM 1

and assign customer ownership.

Group deployment into logical “chunks” of

projects and assign owner to each chunk.

Create a deployment timeline, which is a

phased execution plan for building the
entire solution (fairly high level).

Assess services requirements required to

achieve deployment goals.

Create a first-cut Readiness Plan using

the high-level deployment plan and other
information about the customer.

Assess need for infrastructure

management projects or software not
already identified, such as problem
management, storage management, and
change control.

Review high-level deployment plan and

Readiness Plan with IBM extended team.

Check adherence to SAR policies.

Review initial license use report and

proposed content of the enterprise
contract against deployment plan to
understand any impact to rate of return
(ROR).

Determine the gap between products with

defined projects and products that will
require project definition after agreement
closure.

If not previously started, kick off the SWAP

initiative and create a customer profile.

132 Optimizing Software Deployment: An Insider’s Guide

DM 3: Establish a deployment partnership with the customer

Tasks Owner(s) Date completed Notes

Confirm the customer’s buying decision

and vision.

Identify short-term quick wins.

Define milestones and metrics.

Review gap analysis and determine a

strategy to minimize the gaps.

Review and discuss political, cultural, and

faction roadblocks that could impact
deployment.

Validate critical players on the customer’s

team.

Communicate and jointly agree to roles

and responsibilities of IBM team,
customer team, and deployment services.

Introduce SW Deployment Best Practices

and the Readiness Plan to the sponsor
and discuss an assurance plan.

Review outputs from activity DM2.

Validate project leads within the account

who will assist the customer owner with
deployment.

Identify any challenges or risks to

deployment.

Identify prerequisites and dependencies

that must be met prior to deployment start.

Schedule a date for the kickoff meeting

and determine who should participate.

Appendix C. Software deployment checklist 133

Phase 1: Kicking off the deployment
DM 4: Refine the deployment plan

Tasks Owner(s) Date completed Notes

Review the output of activities DM 2 and

DM 3 with IBM members of the SDT. Be
sure to emphasize any areas of concern
that weren’t appropriate for discussion
with the customer in DM 3.

Perform any performance and capacity

modeling necessary.

Produce a recommended physical

production architecture and associated
physical architecture.

Refine hardware and software

requirements. Match the software
requirements to the contract entitlement
and determine licenses that are not
allocated to projects (shelfware).

Discuss environmental and infrastructure

requirements for deployment, including
overall systems management strategy,
whether based on software or manual
processes or procedures.

Determine whether a deployment

assurance review (self, peer, or expert) is
required. Execute as appropriate.

Create a draft of project controls

(ownership shared with project manager).

Update the readiness and quick-win

deployment plans.

134 Optimizing Software Deployment: An Insider’s Guide

DM 5: Finalize a deployment plan

Tasks Owner(s) Date completed Notes

Finalize the deployment plan with the

customer.

Discuss the appropriate migration

strategy.

Discuss (and confirm the existence of) the

appropriate conceptual data model
(legacy data) if necessary (ownership
shared with data architect).

Finalize the final physical architecture and

operational model.

Finalize the systems management plan.

Agree upon project controls with the

customer owner.

Complete the Readiness Plan (as

appropriate).

Update the quick-win plan.

Finalize project ownership with the

customer.

Finalize software deployment milestones

and metrics.

Appendix C. Software deployment checklist 135

DM 6: Conduct the deployment kickoff meeting

Tasks Owner(s) Date completed Notes

Present the vision that drove the purchase

(Enterprise Business Sponsor).

Link IBM brands or products that were

purchased to the vision.

Go through the contract (high points,

terms and conditions, product quantity,
timings, and critical aspects).

Communicate business value and

benefits.

Show the business context and high level

architecture plan.

Present the high-level deployment plan

(from activity DM 2 and refined in activity
DM 4).

Discuss breadth of deployment (local,

regional, national, or global).

Discuss roles and responsibilities of IBM

and the customer (emphasize deployment
ownership).

Discuss the players, politics, and factions

(IBM and customer). Share a plan for
overcoming or avoiding potential
roadblocks.

Communicate quick deployment wins.

Discuss software deployment best

practices.

Provide product overviews. The

granularity of products discussed should
be tailored to the audience.

Arrange for demos of key products in the

Enterprise Agreement.

136 Optimizing Software Deployment: An Insider’s Guide

Phase 2: Executing the deployment
DM 7: Begin quick deployment win activities

Tasks Owner(s) Date Completed Notes

Identify quick-win deployment project

managers.

Check the capabilities of IBM and

customer teams assigned to the quick-win
deployment plan.

Execute a quick-wins deployment plan.

Manage the quick-win projects.

Conduct regular meetings with project

owners.

Monitor progress of quick wins against

plan and make adjustments as needed.

Implement recommendations defined

during the readiness discussions.

Address and resolve technical issues that

arise.

Maintain close contact with the customer

owner and stakeholders.

Execute a training plan as part of the

Readiness Plan.

Monitor customer satisfaction.

Track software license usage.

DM 8: Execute the deployment plan

Tasks Owner(s) Date completed Notes

Advertise quick-win successes with

meetings or open house.

Identify deployment project managers

(could be IBM, customer, or third party).

Educate the customer on IBM’s support

process.

Check capabilities of IBM and customer

teams assigned to execute deployment.

Begin deploying projects per the

deployment plan.

Manage the projects.

Appendix C. Software deployment checklist 137

 Tasks Owner(s) Date completed Notes

Monitor progress against plan and make

adjustments as needed.

Address and resolve technical issues.

Maintain close contact with the customer

owner and stakeholders.

Monitor the customer’s satisfaction.

Track software license usage.

DM 9: Scan for new deployment and revenue opportunities

Tasks Owner(s) Date completed Notes

Revise the deployment plan to include

new demands.

Look for new project and product

opportunities.

Manage these new projects as done in

activity DM 8.

DM 10: Amend or renew Enterprise Agreement

Tasks Owner(s) Date completed Notes

Move deployment forward and meet the

customer’s milestones.

Help ensure that all return on investment

(ROI) and ROR goals are being met.

Report new revenue opportunities.

Assist with any new solution designs.

138 Optimizing Software Deployment: An Insider’s Guide

 D

Appendix D. Global deployment checklist

Global deployment activities

Geography management assigns a Global Deployment Architect (GDA) in the city where the
global Client Team is based and where the Enterprise Agreement was closed.

The GDA works with the global Client Team and the customer to identify the customer’s
Enterprise Agreement sponsor or owner.

The customer’s Enterprise Agreement sponsor provides a preliminary list of software

deployment locations around the globe. This list should clarify primary, secondary, and
tertiary deployment sites. This level of granularity helps to determine the level of deployment
management attention required in each geography.

The customer’s Enterprise Agreement sponsor provides at least one Enterprise Agreement
project lead for each geography.

The GDA manages the primary deployment sites, and a part-time person should be assigned
to cover the secondary deployment sites.

The GDA arranges for an on-demand contact (usually from the technical sales support
organization) for all tertiary sites.

The GDA loads profile information into Workbench and gives the global team access and
ability to update. (See Chapter 9, “Software deployment tools” on page 71, for information
about Workbench.)

The GDA establishes bi-weekly conference call with the global deployment team. Each
member should provide a brief update on deployment progress. This status should be placed
on the Workbench profile.

The GDA establishes bi-weekly meetings with the SAM, the Client Executive and the
Managing Director, if applicable, to discuss software deployment progress.

The GDA and the local Software Deployment Architect should interlock with the Client Teams
in each geography and checkpoint software deployment satisfaction from the perspective of
the customer. Any issues raised should be investigated, escalated to the Software Group
War Room if necessary, and resolved promptly.

© Copyright IBM Corp. 2003. All rights reserved. 139

 Global deployment activities

The GDA distributes a progress report to the global deployment team (and to SWG executive
management) on a bi-weekly basis. It should include feedback from the regularly scheduled
meeting with the Client Team.

140 Optimizing Software Deployment: An Insider’s Guide

 E

Appendix E. Rational Unified Process

The Rational Unified Process (RUP) is a Web-enabled set of software engineering processes
that provide guidance to streamline your team’s development activities. As an industry-wide
process platform, you can easily choose the set of process components that are right for your
specific project needs. You achieve more predictable results by unifying your team with
common processes that improve communication and create a common understanding of all
tasks, responsibilities, and artifacts. On one centralized Web exchange, Rational, platform
vendors, tool vendors, and domain experts provide the specific guidance you need to be
successful.

Ideal prospects are:

򐂰 Managers
򐂰 Project managers
򐂰 Architects
򐂰 Quality professionals
򐂰 Developers
򐂰 Process engineers
򐂰 Analysts

Key “pains” that the above audiences face are:

򐂰 Success depends upon heroic programmers to save late projects.
򐂰 Projects are often cancelled or significantly late to market and do not deliver necessary
capability.
򐂰 Team members do not know how to work together in an organized, directed manner.
򐂰 Software poorly fits user needs.
򐂰 Projects are unable to deal with changing requirements.
򐂰 Teams have difficulty integrating their work.
򐂰 The build-and-release process is chaotic.
򐂰 Testing procedures are tedious and expensive.
򐂰 Serious architectural flaws are discovered too late in the project to be remedied.
򐂰 The software’s performance is unacceptable.
򐂰 The software is hard to maintain and extend.

© Copyright IBM Corp. 2003. All rights reserved. 141

 RUP has the following top five features:
򐂰 Full life cycle, configurable process platform for different sizes and types of
projects: Use the RUP platform for small projects or large. Customers can configure their
process for RUP iterative development, for Extreme Programming, for achieving CMM
levels, or for specific technologies such as Java 2 Platform, Enterprise Edition (J2EE) or
Microsoft .NET.
򐂰 RUP embodies software best practices with several levels of detail: In working with
thousands of customers and partners over 20 years, Rational has developed and
identified many industry-proven best practices for developing software. These best
practices form the basis of the RUP content.
򐂰 Two-way integration between the RUP and the Rational Suite tools: The RUP
customer has access to detailed information about how to use the Rational software tools
in recommended ways to accomplish tasks specified in the process. The integration is
done through tool mentors in the RUP and extended help in the Rational tools.
򐂰 RUP Builder makes process configuration easy: A new tool, the RUP Builder,
configures a process instance from the RUP base framework and any number of process
content plug-ins.
򐂰 RUP Exchange and Process Plug-ins: RUP is an industry-wide process platform that
offers Rational customers the opportunity to get practical process content from industry
leaders that is appropriate to their specific projects. The RUP Exchange on the Rational
Developer Network provides the common distribution channel for the process plug-ins.

System requirements for RUP are:

򐂰 Operating environment
– Microsoft Windows 95, 98, 2000, NT4
– Any UNIX platform
– Linux
򐂰 Microsoft Internet Explorer 4.x
򐂰 Netscape Navigator 4.x (6.1 is not supported)
򐂰 150 MB disk space
򐂰 64 MB minimum memory
򐂰 Any Windows or UNIX supported network

For a Selling Summary for the Rational Unified Process, visit the following Web site:
https://w3-3.ibm.com/software/sales/salesite.nsf/bc3a6cca560ccb55852567d900529764/
c4c5104d33862b0e87256cd700709e48/$FILE/Rational_Unified_Process_SS.pdf

142 Optimizing Software Deployment: An Insider’s Guide

Glossary

ADD See architectural decisions document. Client Executive Builds a long-term business
relationship with the client. Identifies IBM opportunities
architectural decisions document (ADD) Lists critical and develops solution strategies that meet the client’s
architecture decisions or choices made in the design business needs. They maintain customer business
phase. It also describes the rationale for making them. relationships at the senior level with key decision makers
and influencers. The Client Executive is accountable for
architecture overview diagram Illustrates the basic total client satisfaction, IBM market share, revenue, and
ideas of the proposed architecture. It is the equivalent of profit earned from the client. They partner with the SAM to
the architect’s sketch. Depending on the context, the drive software sales and partners with sales and technical
diagram may range from basic to more detailed. Related specialists in hardware and services to drive respective
work products are the system context diagram, sales.
component model, and operations model, where
additional detail is conveyed. Typically, the diagram Client IT Architect (CITA) A role similar to that of the
evolves with greater level of detail as the architecture is Software Architect (SWA) and Software Deployment
better understood. The diagram serves as a means of Architect (SDA). The CITA has IT responsibility for the
confirming architectural understanding between IBM and entire IBM relationship with the customer, including
the customer. hardware, software, and services. The relationship among
the CITA and the software technical team is critical.
backup and recovery plan Identifies the necessity for
backup and recovery and how backup and recovery Client Representative Builds a long-term business
impacts the customer’s internal service level agreements. relationship with the client by providing total solutions to a
Customers should identify who is responsible for backup client’s business needs. The Client Representative
and recovery and document the procedures in their identifies and qualifies IBM opportunities, engages the
support plan. appropriate IBM resources, gains client commitment to
solutions when appropriate, and ensures overall client
best practices Actions recommended by experienced satisfaction. The representative manages IBM
software deployment personnel. When followed through opportunities while guiding the development of the
the life of the Enterprise Agreement (EA) and the Software solution and support strategies. They partner with the
Deployment Method, best practices help to ensure SAM to drive software sales and partners with sales and
deployment success. technical specialists in hardware and services to drive
respective sales.
Bid Manager (also called “Deal Maker” in the
Americas) Designs and coordinates Enterprise communications plan Reflects all the direct and
Agreement packages (pricing, contracts, etc.). Serves as indirect parties involved with the deployment project.
the primary interface to IBM pricing, legal, accounting, Describes who is responsible for every aspect of the
and IBM Global Finance. The Bid Manager ensures that implementation. This plan should also describe the
pricing principles offered are consistent, profitable, and escalation process in case of problems.
viable and assists the Software Account Manager (SAM)
with strategy and implementation. The Bid Manager component models Documents that include
negotiates the final contract with the customer. responsibilities and required service levels for each
component. The responsibilities are described from the
business context diagram and description Used to view of a user of the component and later refined into
document the identity of the business area being served specific operations. The service level for the component is
by the development effort and its interactions with other described in regard to users and presentation,
business entities in its environment. These entities and performance/capacity, and availability design rationale,
interactions are the sources and channels for flows of reasonableness and risk, and implementation approach.
information into and out of the business. This is key to
developing a system that is properly situated in the client's critical success factor (CSF) The limited number of
business. areas where satisfactory results ensure the achievement
of the business goals. Business issues can be used to
business goals Brief objectives of the company that identify the CSFs.
must be achieved to enable the fulfillment of the vision.
CSF See critical success factor.
CITA See Client IT Architect.

© Copyright IBM Corp. 2003. All rights reserved. 143

customer’s IT environment A work product that Enterprise Agreement (EA) A multi-platform software
documents the customer’s existing logical and physical offering that includes zSeries monthly license charges
design, existing databases design, existing Web (MLC) and one-time charge (OTC). It is a special offering
environments (servers, firewalls, for example), security that contractually leverages the Enterprise Software and
requirements, operational parameters (24x7 for example), Services Option agreement. In most cases, this
end-to-end performance requirements, and existing agreement replaces or amends other IBM agreements
standards (naming and protocols for example). (for example, Passport Advantage) that are referenced
under the offering. The average life of an EA is three
customer’s organization A work product description years, but the term can be as short as one year.
that includes an inventory of organizational elements
(structures, behaviors and enablers) for the in-scope Enterprise Business Sponsor Represents the
organizational units (for example, corporate organization, customer and takes ownership for the software
strategic business unit (SBU), functions, teams, and deployment throughout the enterprise. This sponsor
individuals). The influencers and owners may be key to commits to:
defining who to call on for a given solution. An 򐂰 Develop the internal vision for promoting the
organization chart may be color-coded, for example, to maximum utilization of purchased licenses, based on
indicate who is directly involved in the decision process. the benefit derived.
Deal Maker See Bid Manager. 򐂰 Work with lines-of-business and IT leads to delegate
responsibility for deployment success and return on
deployment architecture The blueprint of what will be investment (ROI).
deployed in the customer account. It combines the work 򐂰 Represent the business globally, if applicable.
products of TeAM that depict the architecture to be
deployed (architecture overview, operational model, and 򐂰 Define deployment milestones for the entire term of
project descriptions for example) with the deployment the Enterprise Agreement.
plans, metrics, and milestones of how it will be 򐂰 Assist with marketing and demand generation of the
accomplished. software portfolio within the organization.
򐂰 Establish deployment quick-win initiatives to establish
deployment kickoff meeting Markets and
project credibility as early as possible.
communicates the deployment plan (and vision) to all
current and potential users within the customer’s envisioned goals and issues (project ideas that
environment. All key leaders must attend (the full IBM emerged early in the sales process) A work product that
team and the customer team project leads, IT leads, and documents the client's mission statement, vision
lines of business leaders). The kickoff meeting should statement, to-be business goals, and critical success
create awareness, understanding, and enthusiasm for the factors.
deployment that is about to begin.
execution environment plan Recommends an
deployment plan (high-level and detailed) A high-level appropriate environment and level of discipline for
version is developed early in the deployment method and development, test, and change management during
defines a list of initial deployment projects, identifies deployment.
customer sponsors and owners for known projects,
groups deployment into logical chunks, contains a gap analysis A listing of products that is burned by
deployment timeline, and includes a services defined projects and products that have yet to be linked to
assessment. A more detailed version is developed later in planned projects (the latter is called potential shelfware).
the method as more projects and information are known. The unlinked products constitute the gap. Gap analysis is
Considered the “deployment bible”. also referred to as software demand gap analysis.
EA See Enterprise Agreement. global software deployment The deployment of IBM
licensed software for an account that has deployment
education plan Assesses the skills needed for locations that span two or more geographies.
successful deployment, current customer skills, and the
steps to close all identified gaps. ITS See Software Technical Sales Specialist.

IT standards A work product that documents all known

IT standards that the architecture must accommodate.

144 Optimizing Software Deployment: An Insider’s Guide

license management Involves identifying which quick wins Projects selected for their high-probability of
licenses are installed, which ones are active, and how success, their importance to the customer, and their ability
many licenses are forecasted to be deployed. To assist in to complete in a relatively short period of time. The
this area, Tivoli has a tool called Tivoli License Manager Software Deployment Team (SDT) wants the customer to
that became available in November 2002. complete these as early as possible in deployment
because they generate momentum, enthusiasm, support,
list of projects and owners A work product that lists all and positive first impressions.
the potential projects, what brands are involved, the
deployment sites, the customer owners, and their contact Rational Unified Process (RUP) A Web-enabled set of
information. This helps to ensure that when deployment software engineering processes that provide you with
begins, information is available to help drive deployment guidance to streamline your team’s development
activity. activities.

Managing Director Has overall responsibility for the Readiness Plan Fosters proactive communications
global relationship within the account, including between IBM and the customer and promotes smooth
responsibility for profitability. deployment. It is a set of processes and work products
designed to:
mapping business initiatives to deployment projects 򐂰 Level set customer’s expectations.
to products A work product acts as a map that connects 򐂰 Assign responsibilities and ownership.
products with projects and links each project to the 򐂰 Determine the customer’s implementation readiness.
business goals or initiatives that drove the original sale. 򐂰 Plan transition from pre-sales to post-sales activities.
򐂰 Assure that customer’s use cases (requirements)
migration plan The act of customers moving their have been met.
current versions of software or hardware to newer 򐂰 Identify risks for mitigation and escalation.
versions (or to new platforms). Migrations can be
complicated and may create cost and time overruns that return on investment (ROI) The value that a customer
can cause serious problems. Migration plans describe the receives on their investment in software, hardware, and
activities and timetables for doing the migration. Some of services. Hard ROI can be quantified with dollars or
those activities include customer code regression testing, numbers and is associated with headcount savings,
execution environment tests, migration automation system count reduction, server consolidation, and
scripting, and back out planning. department closures. Soft ROI is more difficult to project
and quantify, and involves perceptions and satisfaction.
mission statements The operational, ethical, and
financial guidelines of companies (or functional areas). ROI See return on investment.
They articulate the goals, dreams, behavior, culture and
strategies of companies. This should be information that rollout plan and schedule Includes all the individual
is already created by the client. Sometimes called value plans listed in the Readiness Plan, with a schedule and
statements, credos, or principles. priority attached to each activity.

operational model A work product that specifies the RUP See Rational Unified Process.
hardware that the desired architecture requires.
SAM See Software Account Manager.
project descriptions Communicates the project goals
to everyone who needs to know. Provides answers to the SAR See Solution Assurance Review.
question, “What are we doing on this project and why?”
The document provides brief descriptions of the business scope creep Projects that gradually extend beyond their
problems that the deployed projects will solve. original charters and add functions that require software
that was not in the original contract.
quick deployment wins plan Identifies projects
selected for their high-probability of success, their SDA See Software Deployment Architect.
importance to the customer, and their ability to complete
in a relatively short period of time. The plan also contains SDM See Software Deployment Method.
the milestones and metrics associated with the projects.
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.

Glossary 145
services requirements document A work product that Software Deployment Architect (SDA) Accelerates
lists the services that the Software Deployment Team deployment of software solutions and designs additional
believes the customer will need during deployment technical solutions that leverage the entire IBM Software
because they are critical to deployment success. The portfolio to resolve a customer’s business and IT
deployment team identifies these requirements during the challenges. The SDA should assume the role of “trusted
preparation phase of deployment, reviews them with the advisor to the customer”. They should leverage this
customer, and hopefully convinces the customer to relationship to identify and design solutions that satisfy
purchase them. software purchased inside and outside the Enterprise
Agreement. The SDA is key to customer satisfaction
Signature Selling Method (SSM) IBM’s recommended because they ensure that the customer realizes value
selling methodology. The steps within it are to understand from the EA. Since a multitude of projects and activities
the customer, develop a sales plan, establish a buying surround an EA, the SDA provides a single point of
vision, qualify the opportunity, develop the solution, close contact for EA-related questions and issues.
the sale, and monitor implementation.
Software Deployment Method (SDM) A recommended
Software Account Manager (SAM) Sells IBM software 3-phase, 11-activity process that a Software Deployment
in selected large accounts or Small and Medium Business Team should follow when deploying software in an
(SMB) territories and builds customer relationships. The Enterprise Agreement environment. This method uses
SAM, along with the SWA and SDA, have cross-brand work product from IBM’s Signature Selling and TeAM
responsibility, so they have overall responsibility for selling methods and integrates with these processes as well.
and customer success across the entire IBM Software Ideally, the first phase and activity of SDM should begin
Group (SWG) portfolio. SAMs are involved early because when the possibility of the EA contract being signed is at
they work with the brand Software Sales Specialists, the approximately 80%.
Software Technical Sales Specialists, and the Software
Architects to define and qualify an opportunity. Each SAM software deployment milestones and metrics The
provides a single “sales face” to the customer across all critical checkpoints and measures that the Software
the software brands in their assigned accounts. Deployment Team defines with the customer and then
follows closely to help ensure that deployment progress is
Software Architect (SWA) Designs comprehensive on track.
technical solutions that solve the customer’s business and
IT challenges while maximizing IBM software revenue. Software Deployment Team (SDT) The individuals
Software Architects are valued because they first listen to responsible for deployment success. This team should
the customer and then analyze the customer's business consist of a:
and IT challenges. They then design a comprehensive 򐂰 SAM
solution that integrates smoothly into the customer's 򐂰 SDA and/or SWA
context, and that leverages the best of the entire IBM 򐂰 IT Specialists from the brands
software portfolio. 򐂰 Services representative(s) (IGS, Brand, Education,
Support, etc.)
software demand gap analysis A listing of products
that is burned by defined projects and products that have Software Group Team (SWG Team) Consists of the
yet to be linked to planned projects (the latter is called Software Account Manager, the Software Architect, the
potential shelfware). The unlinked products constitute the Software Deployment Architect, the Software Sales
gap. Specialist (SSS), and the Software Technical Sales
Specialists.
software deployment Putting software into use or
action. Achieving deployment success requires that the Software Sales Specialist (SSS) Sells a particular set
customers implement the software license on each of IBM software and work with SAMs, Software Technical
endpoint and that they use this software to overcome Sales Specialists, and Software Architects in doing so.
challenges, achieve their IT goals, and gain a competitive They have knowledge of IBM's strategies and directions
advantage. for the products they represent. They are responsible for
closing the sale and positively impacting the customer's
satisfaction with the engagement and offerings.

Software Technical Sales 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.

146 Optimizing Software Deployment: An Insider’s Guide

Solution Assurance Review (SAR) Minimizes Technical Sales Manager (TSM) Directs the technical
deployment risk. Used to review solutions proposed to the sales efforts of pre-sales technical professionals engaged
customer during the selling or deployment phases of the in selling IBM software products in a specific discipline.
EA. Ensures that the proposed solution delivers the The TSM actively participates in opportunity management
features expected and that the solution is technically and is responsible for technical coverage of sales or
possible to implement. deployment opportunities. The TSM ensures customer
satisfaction by executing the solution assurance process
SSM See Signature Selling Method. and participating in critical situation management.

SSS See Software Sales Specialist. TSM See Technical Sales Manager.

support plan Addresses how IBM will deliver support to use cases A TeAM-generated work product that
the customer and how the customer will support their specifies customer requirements in the areas of
users during deployment. performance, capacity/volumes, scalability, availability,
portability, maintainability, usability, systems
SWA See Software Architect. management, security, infrastructure constraints,
technology standards constraints, and
SWAP A repeatable process that guides the Software geographic/configuration constraints.
Architect through planning of strategic actions and
investments in an account that results in increased Value Realization Model (VRM) A software deployment
software revenue to IBM. work product that ensures IBM and the customer fully
understand how the customer plans to measure
SWG Team See Software Group Team. deployment success
system context diagram Helps to clarify the viability assessment This work product describes
environment in which the solution will operate. This architectural risks, prioritizes (high, medium, and low) the
diagram documents all connections between the probability and impact of each, and identifies contingency
proposed system and external systems/components. plans for each risk item.
Associated with each connection are various attributes
such as data description, protocol, formats, frequency, vision statements The long-term objectives of the
volume, model of interaction (synchronous, company. They articulate the company’s target market
asynchronous), etc. This context constrains the proposed place, products and services and the position the
system with regard to the interfaces that must be company wants their products and services to have in the
implemented. The system context diagram may provide a targeted marketplace, as well as the financial position
rationale for a make or break decision on whether to go (revenue, profit, etc.).
forward.
VRM See Value Realization Model.
systems management plan A comprehensive plan that
documents the customer’s change and configuration Workbench An IBM database tool used by
management plan, security management plan, problem administrators, executives, deployment managers, and
management plan, and who is responsible for solution deployment teams for tracking Enterprise Agreement
uptime during deployment. deployment status at a global, geography, or regional
level.
TeAM See Technical e-business Architect Method.

TeAM methodology A strategic methodology for the

Pre-Sales technical community. It was designed to create
a disciplined and repeatable process for Software
Architects and Specialist. TeAM enables seamless
collaboration between IBM Sales, presale
architects/specialist, and IGS Software Architects. It
provides guidance for technical sales activities, reinforces
SSM and complex solution development best practices,
increase potential to share knowledge (IC) and help
ensure better handoff communication to IBM Global
Services (IGS).

Technical e-business Architect Method (TeAM) See

TeAM methodology.

Glossary 147
148 Optimizing Software Deployment: An Insider’s Guide
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 are also relevant as further information sources:
򐂰 IBM Software home page
http://w3.IBM.com/software
򐂰 Education and skills
http://w3-3.ibm.com/software/sales/salesite.nsf/home/area14
򐂰 Technical sales
http://w3-3.ibm.com/software/sales/salesite.nsf/home/area7

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

Note that this redbook, since it is intended for an internal IBM audience, can be found on the
following internal IBM Web site:
http://w3.itso.ibm.com

Help from IBM

IBM Support and downloads
ibm.com/support

IBM Global Services

ibm.com/services

© Copyright IBM Corp. 2003. All rights reserved. 149

150 Optimizing Software Deployment: An Insider’s Guide
Index
success 67
A support process 92
Account Financial Summary 80 value 68
account health report 71 Customer Goals & Milestones 100
Account Health Summary views 76
ADD (architecture decisions document) 98
ADS (Application Description Standard) 12 D
All Accounts Status 80 Deal Maker 5, 18, 125
All view 73, 77 department closures 66
application deployment 112 dependencies 96
Application Description Standard (ADS) 12 deployment documentation 131
architecture decisions document (ADD) 98, 106 review 27
architecture overview diagram 98, 107 review tips 29
availability/fault tolerance 107, 122 deployment goals and measures 67
deployment kickoff 7, 35
deployment kickoff meeting 39, 88, 136
B Deployment Milestone Status Report 100
backup and recovery plan 92 deployment opportunities 48, 138
best practices 8, 85 deployment owner 23
Bid Manager 5, 21 deployment partnership 133
browser-client architecture 107 with the customer 33
business context diagram 108 deployment phase 130
description 98 deployment plan 137
business goals 90, 99, 114 executing 46
business initiatives, mapping to projects 117 finalizing 38, 135
business strategy 67 high-level 30
refining 36, 134
C Deployment Plan by Product 81
capacity/volumes 122 Deployment Plan by Project 81
Cinch architecture 112 deployment preparation 7, 25
CITA (Client IT Architect) 22 deployment readiness 87
Client Executive 22 deployment satisfaction 62
Client IT Architect (CITA) 22 deployment services 87
Client Representative 22 Deployment view 74
Client Team 22, 125 detailed health reports 78
communicate 88 development and change plan 92
communications plan 90 disaster recovery 107
component model 98 plan 93
component/services architecture 107 DM 0 26, 130
contact document 72 DM 1 27, 131
contract 15 DM 10 50, 138
Contract Status 80 DM 2 30, 132
Contracts view 73 DM 3 33, 133
coverage model 58 DM 4 36, 134
critical success factors 99 DM 5 38, 135
current application deployment 112 DM 6 39, 136
current Cinch architecture 112 DM 7 44, 137
current IT environment 109 DM 8 46, 137
current organization diagram 114 DM 9 48, 138
customer
business goals 99 E
created code 94 education plan 91
IT environment 98 Enterprise Agreement 3, 50, 138
organization 98 project 54
satisfaction 68 sponsors 86

© Copyright IBM Corp. 2003. All rights reserved. 151

 substitution clauses 29 maintenance status 29
Enterprise Agreement Workbench 71 managing at the milestone level 55
Enterprise Business Sponsor 6, 23 Managing Director 22
identifying 29 Mandatory Review List (MRL) 9
Enterprise By Name view 73 market 88
Enterprise License Agreement 4 migration plan and schedule 94
enterprise profile 71 milestone level 55
Enterprise Software and Services Option Agreement 4 mission statement 99
Enterprise view 72 MRL (Mandatory Review List) 9
enterprise-level security 107 multiple-tiered environment 92
execute deployment phase 8, 137
execution environment plan 92
external workflow system 107 O
object-oriented paradigm 107
operational model 99
G opportunity management 68
Gap Analysis Report 100 organization 98
gateway 107 organization diagram 114
GDA (Global Deployment Architect) 58
GEO views 77
geographic and configuration constraints 123 P
Global Deployment Architect (GDA) 58 Passport Advantage 92
global deployment checklist 60, 139, 141 performance 121
global deployment coverage 63 Phase 0 7, 25
global deployments 57 Phase 1 7, 35
global software development 57 Phase 2 8, 43
global support issues 29 plan assessment tool 95
goals and issues 114 portability 122
portal 108
portal-based Web interface 107
H potential shelfware 100
hard ROI 66, 88 power sponsor 6
headcount savings 66 pre-defined reports 79
Health Report view 75 prepare for deployment phase 130
high-level deployment plan 132 primary coverage 58
high-priority work products 100 process integration 107
product deployment 72
progress report 62
I project 54, 72
IBM support process 92 Project Control Book 102
inexperienced project leader 56 project descriptions 99, 119
infrastructure constraints 123 project leader 56
intangible ROI 66 project management challenges 56
integration hub 107 project success 55
internal service level agreement 94 Projects view 74
IT environment 98, 109
IT standards 99, 116
ITS (Software Technical Sales Specialist) 20 Q
quick deployment win activities 44, 137

K
kickoff deployment phase 134 R
RAID log 95
Rational Unified Process 141
L Readiness Plan 9, 89
license management tool 86 Redbooks Web site 149
license utilization 68 Contact us xiii
License Utilization Report 101 references 68
refining the deployment plan 36
M relationship management 68
maintainability 122 Reports view 79
responsibilities 17, 125

152 Optimizing Software Deployment: An Insider’s Guide

return on investment 65 SWAP 82
analyzing with a customer 67 SWITA (Software IT Architect) 19
current value example 69 system context diagram 99, 121
soft versus hard 66 system count reduction 66
support of the business strategy 67
return on investment (ROI) 8
revenue opportunities 48, 138 T
ROI (return on investment) 8 tangible ROI 66
ROI/ROR Status Report 101 TeAM (Technical e-business Architecture Method) 11
roles 17 team room 84
rollout plan and schedule 94 TeAM work products 15
TeAMethod 11
Technical e-business Architecture Method (TeAM) 11
S Technical Sales Manager (TSM) 19
SAM (Software Account Manager) 18 tertiary coverage 58
SAR (Solution Assurance Review) 9 time-to-value strategy 88
scalability 122 Tivoli License Management 87, 145
scanning for new deployment, revenue opportunities 48 transformational hub 106
scope creep 56 TSM (Technical Sales Manager) 19
SDA (Software Deployment Architect) 21
SDT (Software Deployment Team) 6, 130
secondary coverage 58 U
security 122 usability 122
self-sufficiency 88 use cases 100, 121
server consolidation 66
service level agreement 93–94 V
Signature Selling Method (SSM) 10 viability assessment 100, 123
soft ROI 66, 88 vision statement 99
Software Account Manager (SAM) 18
role and responsibilities 126
software deployment 43 W
activities 130 Web services 107
best practices 8 work product 15
checklist 129 architecture decisions document 98
Enterprise Agreement 3 architecture overview diagram 98
integration 12 business context diagram and description 98
problems 4 component model 98
Software Deployment Architect (SDA) 21 customer’s IT environment 98
role and responsibilities 128 customer’s organization 98
Software Deployment Method 1, 6 goals and issues 99
checklist 129 IT standards 99
roles and responsibilities 5 operational model 99
software deployment projects 53 project descriptions 99
Software Deployment Team (SDT) 6, 130 SSM 15
creating 26 system context diagram 99
software deployment tools 71 TeAM 15
software fulfillment 86 usage and examples 97
software inventory analysis 29 use cases 100
Software IT Architect (SWITA) 19 viability assessment 100
role and responsibilities 127 Workbench 62
Software Sales Specialist (SSS) 19
Software Special Bid 4
Software Technical Sales Specialist (ITS) 20
Solution Assurance Review (SAR) 9
SSM (Signature Selling Method) 10
work products 15
SSS (Software Sales Specialist) 19
substitution clause 29
support plan 92
support process 92
support status 29

Index 153
154 Optimizing Software Deployment: An Insider’s Guide
Optimizing Software Deployment: An Insider’s Guide
(0.2”spine)
0.17”<->0.473”
90<->249 pages
 Back cover ®

Optimizing Software
Deployment
An Insider’s Guide

Moves deployment This IBM Redbook was written for the IBM Software Group (SWG)
Team. This team consists of the Software Account Manager (SAM), the
INTERNATIONAL
planning upstream to
Software Architect (SWA), the Software Deployment Architect (SDA), TECHNICAL
proactively manage
the Software Sales Specialist (SSS), and the Software Technical Sales SUPPORT
customer success
Specialists (ITS). The premise of this book is that a proactive, defined ORGANIZATION
Presents concepts, deployment method is essential to selling, allocating, and deploying
software. This disciplined method provides maximum software
best practices, and
utilization. It is critical to achieving customer success and satisfaction
work products that while earning customer confidence and loyalty.
drive ROI BUILDING TECHNICAL
This redbook describes the Software Deployment Method (SDM), INFORMATION BASED ON
which when followed, helps to ensure that customers obtain value PRACTICAL EXPERIENCE
Introduces and
from the software they purchased from IBM. The context used to
describes the IBM Redbooks are developed
describe the method is the Enterprise Agreement, which represents
Software Deployment SWG’s largest and most complicated transaction. It also describes the
by the IBM International
Method Technical Support
role of the customer, because it is critical that the customer takes Organization. Experts from
ownership and strives to be self-sufficient when deploying and IBM, Customers and Partners
maintaining the software in their environment. from around the world create
timely technical information
The SDM integrates tightly with two other major IBM methods: the based on realistic scenarios.
Signature Selling Method (SSM) and the Technical e-business Specific recommendations
Architecture Method (TeAM). This redbook describes the interaction are provided to help you
and integration among SDM, SSM, and TeAM. implement IT solutions more
effectively in your
This book presents concepts, best practices, and work products that environment.
professionals involved in selling and deploying software should follow.
With this redbook, you can efficiently and effectively help customers
derive the greatest value from their software investment with IBM.
For more information:
ibm.com/redbooks

ZG24-6725-01