The Software Deployment Mystery - Solved

(1)

The Software Deployment

Mystery - Solved

d

A Customer Guide

Sandor Hasznos

Carolyn Hungate

Calvin Lawrence

Fernando Zuliani

Reveals best practices and methods

proven to drive deployment success

Offers actual customer

experience as a guide

Helps make the most of your

relationship with IBM

Front cover

Bill Bierds

Jeremy Gibson

David Backman

Mike Ransom

Reid Byers

Charles P. Brown

(2)

(3)

The Software Deployment Mystery - Solved

A Customer Guide

August 2004

(4)

Third Edition (August 2004)

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

Note: Before using this information and the product it supports, read the information in

(5)

Notices

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

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

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive Armand, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES

THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

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

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

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

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

COPYRIGHT LICENSE:

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

(12)

Trademarks

The following terms are trademarks of the International Business Machines Corporation and the Rational Software Corporation, in the United States, other countries, or both:

® Approach® AIX® APL2® CICS/ESA® CICS® Database 2™ DB2 Universal Database™ DB2® GDDM® ImagePlus® Informix® IBM® ibm.com® IMS™ LearningSpace® Lotus® MQSeries® MVS™ OS/2® OS/390® Passport Advantage® Rational Unified Process® Rational® Redbooks (logo) ™ Redbooks™ RS/6000® RUP® S/390® SmartSuite® SP1® Tivoli® TME® VisualAge® WebSphere® zSeries® 1-2-3®

The following terms are trademarks of other companies:

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

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

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

UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

(13)

Preface

To solve any mystery, detectives rely on their experience along with proven tools and techniques to unravel the conundrum. This IBM® Redbook addresses the often illusive mystery known as

software deployment success

. The information, practices, and methods presented in this book have enabled many IBM

customers to achieve their business and Information Technology (IT) goals more quickly and efficiently. IBM has accumulated a wealth of knowledge and

experience in software deployment. The technologies we have developed, the best practices we have authored, and the employees we have cultivated are our greatest assets. Like a detective explaining how the mystery was solved, we use this redbook to pass on to you – our customers – the experience, knowledge, and wisdom we have accumulated after years of solving software deployment mysteries.

The primary audience for this redbook is the person who has ultimate ownership for software deployment performance. We refer to this person as the

Enterprise

Business Sponsor

(EBS). Secondary audiences include anyone who is engaged in software deployment activities. Both audiences benefit from the practices and procedures described.

This redbook refers to a core team known as the

Software Deployment Team

(SDT). This team consists of representatives from both your company and the software vendor. The mission of the SDT is to maintain ongoing and clear communication between you and your vendor. Chapter 2, “Roles and responsibilities” on page 15, describes in detail the SDT and the concept of partnership.

The best practices, presented in Chapter 3, “Software deployment best practices” on page 23, were developed after years of studying deployment challenges and their root causes. Where possible, we encourage you and all of our customers to follow them.

When we refer to “success” in this redbook, we are talking about “holistic success”. It is important to recognize that, while independent achievements are important, holistic success can only be recognized when software is deployed and is executing as envisioned. For that reason, we include the discussion in Chapter 4, “Value realization” on page 33. This chapter focuses on calculating value and discusses the concepts of return on investment (ROI) and rate of return (ROR). It also drills down into creative ways you can measure value such as hard ROI and soft ROI.

(14)

The premise of this book is that a proactive and disciplined deployment approach is required to get the expected business value from any purchase of software. The method described in Chapters 5 through 7 is called the

Software

Deployment Method

(SDM). The SDM is not the only process that you can use to deploy software, but it is an example of a repeatable process that has proven successful time and time again.

Chapter 8, “Managing software deployment projects” on page 67, provides hints and tips for managing large-scale deployment projects. Chapter 9, “Managing global software deployment projects” on page 73, helps you manage deployment on a global scale. And Chapter 10, “Software deployment resources: Support, education, tools” on page 83, describes tools and services that can help make software deployment more systemic and easier to manage.

Throughout this book, you see testimonials, quotes, and success stories submitted by customers who have leveraged all or part of the deployment practices described. One of our customers, a major U.S.-based retailer who we refer to often throughout the book, not only follows the methods that are described, but they also use them as a source for their own customized

deployment guidebook. For confidentiality reasons, we refer to this customer as GMR Corporation or GMR.

During the life cycle of deployment, IBM will always be there to assist you, but it is our goal that you become self-sufficient. This involves building a team of highly skilled subject matter experts who can craft solutions that drive deployments that achieve your business and IT goals. Software deployment is a two-way street between you and your software vendor. We hope that the information presented in this book helps you maximize deployment success and value realization.

The team that wrote this redbook

This redbook was produced by a team of specialists at the request of Lauren States (Vice President, Technical Sales and Deployment, IBM Software Group (SWG)) and Kim Waddell (Director ELA Deployment, SWG) to Maggie Blayney (Director of the ITSO).

򐂰 Bill Bierds, WW SWG - Program Executive, Customer Success Strategies 򐂰 Jeremy Gibson, Program Manager, Customer Success Strategies

򐂰 David Backman, Program Executive, Software IT Architect Community

Note: For the purposes of this redbook, we have used IBM as the vendor. The

tools, techniques, and methods presented herein are applicable to any vendor with whom you deploy software.

(15)

򐂰 Mike Ransom, ITSO Project Leader 򐂰 Reid S. Byers, Software IT Architect

Thanks to Nestlé Corporation, Francisco Esteve (Nestlé Globe Project Leader), and Fredy Schoch (IBM Software IT Architect at Nestlé) for allowing their software deployment experiences to be included in this redbook.

We appreciate the contributions, guidance, and direction provided by the IBM SWG Technical Leadership Council. Members of that council are:

򐂰 David Backman

Senior Certified IT Architect 򐂰 Charles P. Brown

Senior Certified IT Specialist 򐂰 Sandor Hasznos Certified IT Architect 򐂰 Carolyn Hungate Ease-of-Use Architect/Designer 򐂰 Calvin Lawrence Certified IT Architect 򐂰 Fernando Zuliani

Certified Senior Consulting IT Specialist

The contributions of following individuals from IBM are also appreciated:

򐂰 Mohammed Ajab

Software Deployment Architect 򐂰 John Barker

Software Deployment Architect 򐂰 Pete Bouchard

Senior Certified IT Architect 򐂰 Tom Carr

Certified Project Manager, Software Deployment Architect 򐂰 Rob Coventry

Technical Sales Manager, Central Region Architects 򐂰 Nicki Cowley

ELA Competency Center Specialist 򐂰 Paul Edwards

PMP, Certified Project Manager, Software Deployment Architect 򐂰 Kathy Hofstrom

(16)

򐂰 Jess Knowles, Lotus® Services Sales Representative 򐂰 Kathleen O’Leary

Program Manager

򐂰 Mac Pogue

Certified Project Manager, Software Deployment Architect 򐂰 Jennifer Ramirez

Software Deployment Architect 򐂰 Lauren States

VP Technical Sales and Deployment 򐂰 Beverly Vandahl

Program Manager - ELA Deployment 򐂰 Kim Waddell

Director ELA Deployment 򐂰 William Welch

Software Deployment Architect 򐂰 Julie Czubik

Techincal Editor, International Technical Support Organization, Poughkeepsie Center

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

(17)

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

(18)

(19)

Chapter 1.

Why focus on software

deployment

Software deployment

is defined as the process of putting software and software solutions into use or action and ultimately driving business success.

The extensive experience of IBM in deploying software has revealed that many of our customers do not recognize the level of commitment that is required from them to achieve software deployment success. Also, some customers are not

1

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

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

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

(20)

taking steps that are necessary to achieve business value. Consider these examples:

򐂰 A deployment strategy is not mapped out, early projects are not identified, and the scope and schedule of software implementation are not considered. 򐂰 A transition plan from the purchasing team to the implementation team does

not clearly articulate expectations, roles, and responsibilities.

򐂰 Identified deployment projects do not finish on time. Software deployment is inherently complex and involves multiple components or organizations. Therefore, reactive project management results in delayed implementation due to challenges that arise late in the deployment process.

򐂰 Successful solutions and the deployment processes are not leveraged across the broader enterprise. The customer and IBM organizations are tasked with a single implementation. Therefore, they do not focus on leveraging the lessons, experiences, and investment from this single need across the broader environment.

The lack of focus in these areas has resulted in less than optimal return from a software purchase. It has also spawned situations where multiple projects are run in parallel with inadequate infrastructure or mechanics to leverage common components, tasks, resources, lessons, etc.

These experiences suggest that successful software deployment does not just happen. It requires proactive focus and attention from both you and IBM in the following areas:

򐂰 Understanding and qualifying the initial demand (projects)

򐂰 Identifying the core team, with individuals from IBM and your company, that will coordinate the overall software deployment process

򐂰 Developing a deployment strategy that will achieve the defined business goals

򐂰 Continually defining new projects that will help you overcome new challenges To address these needs, this redbook and the Software Deployment Method described within were established.

(21)

1.1 What makes software deployment so difficult

Regardless of the size or scale of the software deployment, you must address several challenges to its success:

򐂰 Separation of the negotiation team from the implementation team. Ideally, key members of the implementation team and key stakeholders participate in the development and negotiation of any agreement. This begins the sense of ownership and ensures that the business goals drive the product selection process. If these teams are separate, a complete transition is key. Roles and responsibilities must be crisply defined, assumptions clarified, and

expectations documented. It is too easy for early projects to falter or become delayed as teams try to collect information and direction from the negotiation process after the fact.

򐂰 When an agreement is closed, all projects may not be concretely defined to maximize software utilization. Because of this, additional projects must be identified to put the purchased software to use. In addition, new or changing business needs will arise and must be responded to throughout the

deployment cycle.

򐂰 Often times, the person or persons who will own software deployment from your organization are not identified or may be out of the loop during project identification and product selection. Therefore, there may be members of your team who are integral to the deployment process and are unaware of the products that were purchased and what business challenges the agreement was crafted to solve.

򐂰 Some organizations or individuals may be opposed to the vendor or the products purchased. This can potentially undermine the success of one or more projects.

򐂰 The deployment of software sold can cross a wide range of departments, lines of businesses, and multiple contacts that may or may not have been included in the selling or negotiation phases of the agreement. Therefore, it is not uncommon for the IBM team to call on individuals who may not be fully aware of your overall corporate Information Technology (IT) strategy. This can create challenges during the deployment phase. That is to maximize

Note: As of the printing of this redbook, IBM Software Group has twelve

specialty areas that span the five IBM SWG brands. The brands are Data Management, Lotus, Rational®, Tivoli®, and WebSphere®. The specialty areas are Automation, Business Integration, Business Intelligence, Content Management, Development Tools, Document Management, Linux, Pervasive, Portals/Dynamic Workplace, Security, and Storage.

(22)

deployment performance, the entire IT organization must be aligned behind one mission, regardless of how tactical the individual needs may be. 򐂰 It is not uncommon for software to remain unused for long periods of time

during the term of the agreement. Recognizing this situation early and putting actions in place to rectify it are critical steps to avoid surprises.

1.2 Why have a Software Deployment Method

We believe that the key to deriving value from your software depends on the adherence to a common roadmap or method that solves your business

problems. Following this roadmap helps the individuals assigned to deployment, within your organization and IBM, to act as one team that is focused on a common goal. This redbook describes the Software Deployment Method that, when followed, should maximize your chance of deployment success.

1.3 The Software Deployment Team

Many individuals from your company, IBM, and partners must work together smoothly to ensure the successful deployment of your software. In this book, we refer to this team as the Software Deployment Team.

Your representatives on the SDT are: 򐂰 Enterprise Business Sponsor (EBS) 򐂰 Stakeholders and sponsors

򐂰 Project managers

The IBM representatives on the SDT are: 򐂰 Software Sales Representative (SSR)

򐂰 Specialist Software Sales Representative (SSSR) 򐂰 Software IT Architect (SWITA)

򐂰 Software IT Specialists

򐂰 Services representatives (IBM Global Services, Brand, Education, Support, etc.)

The partner representatives on the SDT are: 򐂰 Third-party project managers

򐂰 IBM Business Partners assisting in administrative or deployment functions 򐂰 Third-party implementation consultants

(23)

The SDT should meet as required to develop software deployment strategies and review software deployment progress. For further information about the roles and responsibilities of the SDT, refer to Chapter 2, “Roles and responsibilities” on page 15.

1.4 The Software Deployment Method

As shown in Figure 1-1, the Software Deployment Method consists of three phases and 11 steps. Although these phases and steps are discussed

throughout this book in a serial manner, in practice they often overlap and repeat throughout the life cycle of deployment. The phases are:

򐂰 Phase 0: Prepare for deployment. 򐂰 Phase 1: Refine and promote the plan. 򐂰 Phase 2: Deploy software.

Figure 1-1 Overview of the Software Deployment Method

1.4.1 Phase 0: Prepare for deployment

The overall purpose of this phase is for you and IBM to build the groundwork required for successful deployment. The steps in this phase are:

򐂰

Step 0. Create the Software Deployment Team (SDT):

During this step, you, IBM, and any partners who may be involved work together to determine the team that will be focused on the overall success of the software deployment. This team is called the Software Deployment Team.

Step 0: Create Software Deployment Team Step 2: Develop High-Level Deployment Plan Step 3: Establish Deployment Partnership Step 1: Review Documents

Phase 1

Step 4: Refine Deployment Plan Step 6: Conduct Deployment Kickoff Step 7: Achieve Quick-wins Step 9: Identify New Business Needs Step 10: Update Business Plan

Phase 2

Phase 0

Prepare

Refine and Promote

Deploy

Step 5: Finalize Deployment Plan Step 8: Execute Deployment Plans

(24)

򐂰

Step 1. Review the critical deployment documents:

The purpose of this step is to obtain a common understanding among the SDT of the critical documents that will be used in the deployment process. During this step, the SDT reviews documents such as the contract, roles, and responsibilities, business context diagram, requirements, solution concepts, etc.

򐂰

Step 2. Develop a high-level deployment plan:

The purpose of this step is to create a high-level mapping of products to your projects and assign

ownership at a project level. The high-level deployment plan defines a list of initial deployment projects, identifies sponsors and owners from within your business for known projects, groups deployment into logical chunks, contains a deployment timeline, and includes a services assessment. During this step, you should also consider your readiness for deployment by reviewing the software deployment best practices and the readiness plan content, which are both described later in this redbook.

򐂰

Step 3. Establish a deployment partnership:

This step involves holding a formal meeting between your deployment owners, participants, or both and IBM to come to closure on major issues that must be addressed. Such issues include deployment best practices, identification of the sponsor, or

determining whether services will be used. This should solidify the

partnership between you and IBM and help ensure that both groups realize that deployment is a two-way street. Keep in mind that you are ultimately responsible for the deployment.

During this step, the SDT identifies quick deployment wins that act as both technical proof points and create momentum. It also defines critical success milestones and criteria. They agree on roles and responsibilities and introduce the software deployment best practices and the readiness plan. You and IBM should agree on the high-level deployment plan created in the previous activities and discuss a deployment services strategy.

1.4.2 Phase 1: Refine and promote the plan

This phase begins after an agreement is in place and when critical inputs are reviewed again to inspect any changes made during final negotiations. Also, during this phase, the deployment plan is refined and the deployment kickoff meeting or meetings are held. The steps in this phase are:

򐂰

Step 4. Refine the high-level deployment plan:

The purpose of this step is to revise the solution architecture and deployment plans to reflect any changes made during the final negotiations. During this step, the SDT reviews all inputs to Steps 1 and 2 (for example, the contract and list of deployment projects and owners) to determine if anything has changed. The team also completes a thorough review of the requirements, architecture, components, interfaces, and any performance modeling that has been done. A key output from this step is a refined deployment plan.

(25)

򐂰

Step 5. Finalize the deployment plan:

The purpose of this step is to obtain final agreement with the deployment plan among the SDT. During this step, the SDT reviews all inputs to Step 3 and agrees on project controls. Also, during this step, you and IBM should discuss the plans for one or more deployment kickoff meetings.

򐂰

Step 6. Conduct deployment kickoff meetings:

The purpose of this step is to market and communicate the deployment plan and overall vision to all current and potential users within your company. This is typically done in the form of a meeting or a series of meetings attended by your stakeholders (team project leads, IT leads, and lines of business leaders) and the full IBM team. It is imperative that key leaders and present or future stakeholders attend. Use these meetings as the forum to bring together the stakeholders, sponsors, and implementers and explain the business goals, IT vision, contract details and content, and the deployment plan. Explain what will be accomplished, why it is important, how this will be done over time, and when major milestones are expected to be reached. The kickoff meetings should create awareness, understanding, and enthusiasm for the deployment that is about to begin.

1.4.3 Phase 2: Deploy software

The purpose of this phase is to begin executing against the deployment plan. It starts with the carefully selected quick deployment wins and then moves on to the other projects. During this phase, project management is critical. The steps in this phase are:

򐂰

Step 7. Achieve quick deployment wins:

The purpose of this step is to implement the quick deployment wins and, in doing so, demonstrate success. This will build momentum, confidence, and credibility, which are vital in the beginning stages of deployment. This is also the time to revise any processes defined during earlier planning that have not worked as expected.

򐂰

Step 8. Execute the deployment plan:

The purpose of this step is to build on the success and momentum of the quick deployment wins. This is also when you begin deploying projects that were defined before and during the product selection. During this step, project management is critical. You should monitor carefully your stakeholders’ satisfaction and progress toward deployment goals (timeline and financial).

򐂰

Step 9. Identify new business needs:

Due to the dynamic nature of business, your business needs that were not known or identified during Phases 0 and 1 typically arise after deployment has begun. These new business needs may be satisfied with software that was part of the original agreement, or they may require the purchase of additional software that will be deployed in new projects. This is referred to as the

software gap

. To prepare for and meet the

(26)

new business needs, the SDT should return to Phase 0 and follow the roadmap for its planning and implementation.

򐂰

Step 10. Update the business plan:

The purpose of this step is to complete any purchase of software, and potentially additional services and education, that will meet the new business needs identified in Step 9. In this step, you also make the appropriate changes in the existing plans that will

accommodate its deployment.

1.4.4 Software deployment method: A continuous process

Figure 1-2 illustrates that the SDM is a continuous process. The outer circle represents the activities that should occur prior to the software acquisition. The inner circle represents the necessary steps to ensure that software is deployed properly. After a new software requirement is defined, SDM Steps 0 through 3 should occur in sequence (outer circle). After the purchase of software is completed, the life cycle enters what is called the “software deployment mill”. In the mill, SDM Steps 6 through 10 are executed (inner circle). These steps include deployment kickoff and communication cadence, quick deployment win execution, and deployment plan execution. Also, in the mill is the requirement that new demands constantly be uncovered. This can be a demand for software already purchased that burn down licenses that are not yet deployed. Or it can be a demand for new software requirements that require an acquisition to occur. After a new software requirement is defined, the business plan is updated in Step 10. If this software is already purchased, the process continues within the mill back to Step 6 (kickoff and communication). This, in effect, increases the size of the mill because more deployment activity is underway.

If the software identified in Step 9 requires an acquisition, then Step 10 jumps to Step 1 (from the inner circle to the outer circle). This is where the new software can be properly built into the contract and the high-level deployment plan (Steps 1 and 2). The assumption is that you can skip Step 0 because the Software Deployment Team is already established. Step 3 leads to the required

acquisition, and when the new software is fed into the deployment mill, the size of the mill increases.

(27)

Figure 1-2 Software Deployment Method cycle

Figure 1-3 introduces the positive impact an effective deployment strategy can have on return on investment. As the software deployment mill increases in the number of active and completed deployment projects, the deployed license count increases exponentially. As the mill increases in size it begins to approach the size outer circle (purchase volume). When the inner circle grows to the size of the outer circle, ROI has been achieved.

Software Deployment Method

Software Deployment

Method Steps Software Deployment Mill Step 0: Create SW Deployment Team

Step 1: Review Contract Content & Critical Deployment Documents Step 2: Develop High

Level Deployment Plan Step 3: Establish Deployment Partnership with Vendor Software Acquisition New Software Requirement Defined Step 6: Kick-off & Communication Step 4&5: Refine & Finalize High Level Deployment Plan

Step 7: Execute Quick Deployment Wins Step 8: Execute Deployment Projects Step 9: Identify New Business Needs Step 10: Purchase Software & Update Business Plan

(28)

Figure 1-3 Software Deployment Method value timeline

1.5 Software deployment best practices

Deployment success and value realization require that you focus on the following best practices:

򐂰 Identify an Enterprise Business Sponsor and stakeholders. 򐂰 Centralize software fulfillment.

򐂰 Implement a license management tool and process. 򐂰 Hire deployment services.

򐂰 Determine your deployment readiness. 򐂰 Commit to self-sufficiency.

򐂰 Define a time-to-value and ROI strategy. 򐂰 Communicate and market the vision.

For assistance in understanding the best practices and applying them to your organization, IBM can host a software deployment workshop. This workshop includes the Enterprise Business Sponsor, the Software Deployment Team, and

Return on Investment Timeline

Time

ROI

Step 11: Purchase Software & Update Business Plan Software Deployed Software Deployed Software Deployed

(29)

key stakeholders from your organization. It is designed to both deliver the benefits of the best practices and to discuss any gaps that need to be addressed You can find more information about these best practices in Chapter 3, “Software deployment best practices” on page 23. For more information about value realization, time-to-value, and ROI, see Chapter 4, “Value realization” on page 33.

1.6 The readiness plan

After you commit to purchase IBM Software, it is critical that your employees acquire the skills and process knowledge necessary to successfully implement the solution. The readiness plan is designed to facilitate the communications and planning between you and IBM at critical junctures. It is prepared by the IBM Software IT Architect or Technical Specialist. The number of readiness plans that are required depend on several factors such as the people who are involved, the complexity of the environment, and the number and complexity of projects. A well-executed readiness plan proactively addresses implementation issues. In turn, it promotes enhanced satisfaction with the IBM solutions. The readiness plan itself is a set of processes and work products that are designed to: 򐂰 Help ensure your expectations are properly set and met

򐂰 Identify issues and risks and set a proper course of action

򐂰 Help ensure your team has the appropriate skills for implementation 򐂰 Assign responsibilities and ownership of implementation tasks

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

1.7 Solution Assurance Review

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

(30)

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

1.8 Software solution work products

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

1.9 Software deployment: A two-way street

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

(31)

Customer example: Soon after signing an Enterprise Agreement (EA) with

IBM, GMR recognized the need for a single owner for the EA. The

responsibility of the owner would be to ensure the successful deployment of the software purchased in the EA. GMR’s Vice President of Architecture for Technical Services was placed in the role of Enterprise Business Sponsor (software deployment best practices #1) by his manager (the Chief

Information Officer (CIO)). His first step was to identify a team of IT Managers to assist with identifying a deployment strategy for GMR. IBM already had in place sales and technical sales representatives, including a SSR and SWITA. These two groups, when combined, created the SDT (SDM Phase 0, Step 0). One team—GMR and IBM—focused on ensuring the success of the EA. The SDT quickly defined a high-level deployment plan that identified a long-term view of deployment direction. The SDT also defined “quick deployment wins”, five products from the EA to be deployed immediately. These quick wins were to be delivered in the near term to build confidence and generate excitement around the technology and solutions while

supporting GMR’s business objectives. The leader of GMR’s EA Deployment Team identified product captains for the helm of each quick deployment win. Their responsibilities were to define and execute a realistic plan to use the software in at least one pilot project and to build the infrastructure to support use of the “quick win” software in future projects. In addition, they had the responsibility to communicate and market successes within GMR Technical Services.

To facilitate this communication and marketing effort, GMR’s EA Deployment Team devised an event entitled

EA Land

(SDM Phase 1, Step 6). EA Land was organized to allow the product captains to highlight their teams’

achievements during the first eight months of EA deployment work. Along with product tables and two demo rooms, staffed by GMR and vendor

representatives,

process tables

were included, such as quality assurance, information architecture, and solution services. This ensured that the excitement about the EA products that was generated by EA Land did not overwhelm GMR’s deployment process. Over 1,200 GMR IT professionals were invited to this event.

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

(32)

(33)

Chapter 2.

Roles and responsibilities

One of the many reasons you may have decided to do business with IBM is because we have many skilled professionals involved in the sales and

deployment of our software, hardware, and services. The challenge when many people are involved is to ensure that the roles and responsibilities are clearly communicated to you. It is equally important that any expectations you have of IBM, and vice versa, are defined as early in the software deployment process as possible.

One of the more common concerns found when analyzing deployments is that roles and responsibilities are not clearly stated up front. Then, as the deployment progresses, confusion arises over who is supposed to perform certain tasks or when they will be done. The foundation, therefore, for deriving value from your purchases begins with ensuring that your team and the IBM team know their own roles and the roles of each other. Who is supposed to do what? And when should they do it? This chapter describes that foundation.

2

“Finding good players is easy. Getting them to act as a team is another story.” – Casey Stengel, famed manager of baseball's New York Yankees

(34)

2.1 Internal team

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

2.1.1 Enterprise Business Sponsor

The EBS is generally appointed by a senior executive in the Information

Technology (IT) organization. The EBS should represent your company’s goals, take ownership for software deployment throughout the enterprise, and commit to the following responsibilities:

򐂰 Develop and promote an internal vision for attaining the maximum usage of purchased licenses, based on the benefit derived

򐂰 Work with the lines-of-business and IT leads to delegate responsibility for deployment success and return on investment (ROI)

򐂰 Represent the business globally, if applicable 򐂰 Define deployment milestones

򐂰 Assist with marketing and demand generation of the software portfolio within the organization

򐂰 Establish quick deployment win initiatives to establish project credibility as early as possible

2.1.2 Stakeholders, sponsors, and project leads

Stakeholders

are those individuals who requested or will benefit from the solutions being provided. This group needs frequent feedback on designs, prototypes, and progress toward a final deliverable to maintain confidence in the solution and delivery team.

Project leads

are in charge of individual projects that contribute to the solution paid for by the sponsor and to be delivered to the stakeholders. They manage the day-to-day execution of the project vision and direct the efforts of the development specialists.

To make the most of your software investment and exploit the value of that investment, it is critical to have early and frequent communication with the

(35)

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

2.1.3 Global Project Lead

The Global Project Lead (GPL) is assigned to global software deployments and coordinates all deployment activities going on around the world. This person should:

򐂰 Have excellent project management skills as well as experience on the global stage working with a variety of people from differing cultural backgrounds. 򐂰 Have experience managing complicated projects. This implies that they can

handle complicated products, and combinations of products, and complicated geographical challenges.

򐂰 Be a self starter, constantly looking for opportunities to increase the deployment footprint.

For more information about the GPL’s role, refer to Chapter 9, “Managing global software deployment projects” on page 73.

2.2 Team IBM

Team IBM refers to the many people from IBM who are involved in making your software, hardware, and service purchases successful. While each person has their own unique focus and specialty, it is the goal of each individual to present a cohesive view of the IBM Company.

When leveraged, the IBM team can be a tremendous asset to you. Their wealth of expertise is unmatched in the IT industry. Also their knowledge of your business goes far beyond the scope of the software that is being deployed. The IBM team members come from such organizations as IBM Global Services, the System Group (Server/Storage), IBM Global Finance, Personal Computing Division, Printers, Partner Channels (Global and Small to Medium), and the IBM Software Group. Almost every software agreement requires participation from these organizations. Leveraging such a diverse team can greatly enhance the deployment process.

(36)

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

Figure 2-1 provides an overview of the various IBM roles.

Figure 2-1 IBM client team - Software-focused view

2.3 IBM Client Team

The IBM client team consists of the following members: 򐂰 IBM Client Executive

򐂰 IBM Client Representative 򐂰 IBM Client IT Architect

IBM Client Team – Software Focused View

Automation, Security, Storage Portals, Dynamic Workplace Business Intel, Content Mgmt/ Doc. Mgmt Business Integration, Pervasive Development Tool Software Sales Representative (SSR)

Software IT Architect (SWITA) Managing Director (MD)

Client Representative/Client Manager Client IT Architect (CITA)

Specialty SSR Specialty SSR Specialty SSR Specialty SSR Specialty SSR IT Specialists Services Support IT Specialists IT Specialists IT Specialists IT Specialists Services Services Services Services Support Support Support Support

Server

Group

Services

Global

Software Group

Middleware Solution Areas*

Client Executive/Client Director

* Other solution areas that span SWG are: Linux and z-Series

DB2 Lotus Tivoli WebSphere Rational

(37)

2.3.1 IBM Client Executive

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

2.3.2 IBM Client Representative

The Client Representative builds long-term business relationships with you and your team by providing solutions to your business needs. This is accomplished by:

򐂰 Communicating the IBM solutions to gain understanding and commitment 򐂰 Engaging appropriate resources

򐂰 Helping to ensure overall satisfaction

They partner with the software, hardware, and services representatives as needed to ensure a complete solution is presented. However, they also communicate your business and technical strategies back to Team IBM to maintain focus on your business needs.

2.3.3 IBM Client IT Architect

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

2.4 IBM Software Team

The IBM Software Team consists of the following members: 򐂰 Sales (non-technical):

– Software Sales Representative (SSR): Cross-brand strategy and sales – Specialist Software Sales Representative (SSSR): Single brand sales and

tactical sales support 򐂰 Technical Sales:

– Software IT Architect (SWITA): Cross-specialty/cross-brand strategy and deployment

(38)

2.4.1 IBM Software Sales Representative (SSR)

SSRs formulate strategies that link IBM Software with your business strategies. The SSR should work closely with you to:

򐂰 Understand your business needs and propose IBM solutions to meet those needs.

򐂰 Manage customer relationships and problems. 򐂰 Negotiate future software agreements.

򐂰 Help you understand the IBM Software Strategy and how it is of value to you. 򐂰 Increase satisfaction with IBM Software solutions.

򐂰 Coordinate efforts of the IBM Software team to match your business strategy. Each SSR provides a single “sales face” to you across all of the IBM Software brands.

2.4.2 IBM Specialty Software Sales Representative (SSSR)

The SSSR focuses on one or more IBM software specialties and works with the SSRs, ITSs, and SWITAs in doing so. SSSRs have knowledge of IBM strategies and directions for the specialties they represent. They are responsible for positively impacting your satisfaction with the offerings within their respective specialties.

2.4.3 IBM Software IT Architect (SWITA)

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

The SWITA’s responsibilities are to:

򐂰 Work with you and the IBM team to translate your business vision and IT challenges into a specific design.

򐂰 Develop plans to prove or implement the technical design.

򐂰 Build and maintain relationships with your key IT decision makers. 򐂰 Direct the IBM activities required to design and implement a solution.

(39)

򐂰 Focus on your technical strategy rather than on specific products or tactical implementation issues.

򐂰 Use tools and established methodologies to help you develop the strategy and vision for the IT systems and shape this vision into a specific technical design.

򐂰 Employ accepted design methods, patterns, and best practices when performing analysis and designing project phases.

򐂰 Understand the integration of the IBM Software products and how the solutions compare with those offered by our competition.

򐂰 Recommend appropriate education and services based on knowledge of your environment and skill levels.

򐂰 Investigate new software technology and design methods to provide proactive education.

򐂰 Manage the Solution Assurance Review (SAR) process.

򐂰 Help you understand and adopt the software deployment best practices. 򐂰 Help you prevent software from becoming shelfware.

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

The SDA’s responsibilities are to:

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

򐂰 Advise on the most architecturally sound combination of software to help ensure the efficient deployment of technical solutions.

򐂰 Customize documented deployment methods to facilitate solution success. 򐂰 Lead the IBM technical team to drive new and existing solutions to

completion.

򐂰 Understand the integration of the IBM Software products and how the solutions compare with those offered by our competition.

(40)

򐂰 Maintain an active role in the Solution Assurance Review process to ensure action items are closed and risks are mitigated.

򐂰 Help you understand the software deployment best practices.

򐂰 Help to ensure work products are documented and transferable to other technical professionals.

򐂰 Help to ensure software does not become shelfware.

2.4.4 IBM Software IT Specialist (ITS)

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

򐂰 Build and maintain a technical understanding of product capabilities. 򐂰 Understand your technical infrastructure and use this knowledge to identify

potential solutions.

򐂰 Understand how IBM’s software compares to our competition in their specialty area or areas.

򐂰 Ensure you are technically prepared for a successful implementation. 򐂰 Manage the Solution Assurance Review process.

(41)

Chapter 3.

Software deployment best

practices

Best practices are tried and true methods that have a history of being successful. Deployment success and value realization are achieved when best practices are adhered to consistently throughout the Software Deployment Method. Through working with the many customers of IBM Software and seeing what works and what fails, we created the following list of software deployment best practices: 򐂰 Identify an Enterprise Business Sponsor (EBS) and stakeholders.

򐂰 Centralize software fulfillment.

򐂰 Implement a license management tool and processes. 򐂰 Hire deployment services.

򐂰 Determine your deployment readiness. 򐂰 Commit to self-sufficiency.

򐂰 Define a time-to-value and return on investment (ROI) strategy. 򐂰 Communicate and market the vision.

It is important that you and the IBM team discuss and agree to follow these best practices, since they have proven to ensure the highest possibility of success. Table 3-1 summarizes the best practices that are described in this chapter.

(42)

Table 3-1 Summary of software deployment best practices Software deployment best practice Benefit Identify an Enterprise Business Sponsor

򐂰 Aligns business goals with Information Technology (IT) initiatives prescribed during software purchase decision

򐂰 Establishes an owner for software value, rate of return (ROR), and ROI 򐂰 Functions as a leader to track deployment progress and coordinate

resources to execute projects Centralize software

fulfillment

򐂰 Ensures that each person that has the desire to deploy software has the means of getting it efficiently and effectively

򐂰 Provides a control point from which software deployment progress can me monitored

Implement a license management tool

򐂰 Allows you to verify your compliance with the terms and conditions of your software contracts

򐂰 Eases charge-backs between departments for requested software 򐂰 Provides intelligence regarding software deployment

򐂰 Allows better control of version management, patch delivery, upgrades, and general maintenance

򐂰 Gives you an opportunity to save money with accurate assessments of your software usage

Hire deployment services

򐂰 Ensures that an expert is engaged to help plan and execute the deployment

򐂰 Allows you to navigate the normal pitfalls of solution development by leveraging experienced consultants

򐂰 Dramatically increases the chances for deployment success Determine deployment

readiness

򐂰 Eliminates many of the unknowns associated with solution design and software deployment

򐂰 Guides you through the activities needed to improve software planning and deployment

򐂰 Helps to ensure that the deployment goes as smoothly as possible with the fewest challenges

Commit to self-sufficiency

򐂰 Ensures that, over time, the reliance on IBM services and support is minimized

򐂰 Reduces long term cost of ownership by building skilled teams, strong processes, and robust environments

Define a time-to-value and ROI strategy

򐂰 Provides common goals for the deployment teams to work toward 򐂰 Builds confidence with the achievement of quick wins

򐂰 Defines a schedule for achieving long term goals 򐂰 Provides a mechanism to gain community buy in

(43)

3.1 Identify an Enterprise Business Sponsor and

stakeholders

Ownership for your deployment success may be at several different levels. For example, you may be the high-level Enterprise Business Sponsor and have delegated additional sponsorship to your direct reports. Or an IT executive may have delegated sub-sponsorship to separate lines of business. It is important that there is one executive who is responsible for the successful implementation of large or on-going transactions. If this person is you, seek out your local IBM team. They are eager to meet you and build the partnership necessary for your success.

If the Software Deployment Team (SDT) feels that they cannot control the projects or implement any needed changes, it is possible they have not found or are not working with the Enterprise Business Sponsor. It may be that the individual given responsibility for deployment is not in the right position to drive success. The sponsor needs to know that there is a team ready to work together to achieve the business goals defined. It is with the Enterprise Business Sponsor that quick deployment successes need to be set. Ongoing successes should be expected and celebrated.

The members of the SDT should work with the Enterprise Business Sponsor to identify any cultural, geographical, political, skills, or training challenges that need to be overcome. Define a strategy or plan to overcome each. It should also

Communicate and Market the Vision

򐂰 Increases the investment understanding by communicating the linkage between the strategic purchase and business goals

򐂰 Accelerates the rate of return and increases solution demand through advertised successes

Software deployment best practice

Benefit

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

company in Texas, U.S.A, has personally assumed ownership of their software agreement to drive their deployment projects. He delegates the day-to-day responsibilities to various project managers on his staff and maintains involvement with monthly status updates. Any inhibitors to their success are quickly dealt with so as not to impact their overall plan. Not only does the involvement of the CIO avoid any surprises, but also it ensures that his vision is continuously delivered and reinforced.

The Software Deployment Mystery - Solved

The Software Deployment

Mystery - Solved

d

A Customer Guide

Sandor Hasznos

Carolyn Hungate

Calvin Lawrence

Fernando Zuliani

Reveals best practices and methods

proven to drive deployment success

Offers actual customer

experience as a guide

Helps make the most of your

relationship with IBM

Front cover

Bill Bierds

Jeremy Gibson

David Backman

Mike Ransom

Reid Byers

Charles P. Brown

The Software Deployment Mystery - Solved

A Customer Guide

August 2004

Contents

Notices

Trademarks

Preface

software deployment success

Enterprise

Business Sponsor

Software Deployment Team

Software

Deployment Method

The team that wrote this redbook

Become a published author

Comments welcome

Why focus on software

deployment

Software deployment

1

1.1 What makes software deployment so difficult

1.2 Why have a Software Deployment Method

1.3 The Software Deployment Team

1.4 The Software Deployment Method

1.4.1 Phase 0: Prepare for deployment

Step 0. Create the Software Deployment Team (SDT):

Phase 1

Phase 2

Phase 0

Prepare

Refine and Promote

Deploy

Step 1. Review the critical deployment documents:

Step 2. Develop a high-level deployment plan:

Step 3. Establish a deployment partnership:

1.4.2 Phase 1: Refine and promote the plan

Step 4. Refine the high-level deployment plan:

Step 5. Finalize the deployment plan:

Step 6. Conduct deployment kickoff meetings:

1.4.3 Phase 2: Deploy software

Step 7. Achieve quick deployment wins:

Step 8. Execute the deployment plan:

Step 9. Identify new business needs:

software gap

Step 10. Update the business plan:

1.4.4 Software deployment method: A continuous process

Software Deployment Method

1.5 Software deployment best practices

Return on Investment Timeline

Return on Investment Timeline

Time

Time

ROI

ROI

1.6 The readiness plan

1.7 Solution Assurance Review

1.8 Software solution work products

1.9 Software deployment: A two-way street