Chapter 5. Software deployment Phase 0: Prepare for deployment
5.2 Step 1: Review the deployment documentation
After the SDT is formed, they should collect and review such documents as any current or pending contracts, business context diagrams, solution requirements and concepts. The purpose for the review is for the team to obtain a common understanding of the documents that will be used in the deployment process and the business needs that are driving your software purchases.
At this point, it is critical to obtain from the Enterprise Business Sponsor a preliminary view of
success
and theexpected value
to be derived from the software purchase. The SDT should keep this in mind for the entire deployment process and use it to create the deployment plans. The team may need to revisit these goals and success criteria to be reminded of the business needs and prevent getting lost in the details of deployment.The SDT should thoroughly understand the content, terms, and conditions of any software purchase contract. Typically, this contains standardized terminology. However, because each agreement may be customized to meet specific needs, it may include special terms or clauses that need to be understood. The SDT should understand these customizations and how they affect the deployment process. If there are things that they don’t understand, they should ask the team negotiating the contract.
5.2.1 Owners and participants
The owners are the EBS, SSR, and the IBM Software IT Architect (SWITA). The participants include the project managers, internal IT architects, IBM Client Executive, IBM technical representatives and IBM service representatives. All members of the SDT should participate in this step.
5.2.2 Inputs, tasks, and outputs
Table 5-2 Inputs, tasks, and outputs for SDM Step 1: Review the deployment documentation
5.2.3 Benefits
The benefits that result from this documentation review are that the SDT: Has a common understanding of the business vision and goals
Agrees that the conceptual solution is viable and concurs with the viability assessment
Confirms and agrees to the roles and responsibilities for both your company and IBM
Has an awareness that the preparation phase of deployment has begun
Inputs Tasks Outputs
Draft contract Solution concept
Requirements and use cases Business context diagram
and description
System context diagram Conceptual architecture Architectural decision
document (ADD)
Initial viability assessment Organization charts IT standards
Current IT environment Project descriptions
Discuss buying decision Ensure that the content and
terms and conditions of the contracts are thoroughly understood
Study substitution clauses Understand the status of
maintenance and support Discuss any expectations Discuss license
management tools and processes and how to track deployment
Review the requirements, solution concepts, business context, conceptual
architecture, and architecture decision document
Review and refine the initial viability assessment (which includes the results of any Solution Assurance Reviews (SARs)) and confirm the solution
Document the linkages between the planned projects and products
List of open items for contract negotiation
Updated viability assessment Draft goals and milestones
document
High-level mapping of business initiatives to projects
Draft mapping of projects to products
Initial software utilization report
5.2.4 Documentation review tips
Following are several tips for the documentation review:
Analyze the software in your inventory:
Typically, you already own some IBM Software from previous purchases. You may purchase new products that are recently released or that you didn’t purchase before. It is important to perform a crosscheck between what you already own and what you are purchasing. Where do you stand with the deployment of your previous investment? Will some licenses from past purchases be used in conjunction with some newly purchased licenses to support your projects? Perform checks and balances to compare what you have with what you are going to purchase.
Understand substitution clauses:
If you are purchasing through a large, multi-year contract or negotiated special terms and conditions, your contract may include clauses that allow product substitutions. It is imperative that the SDT understand the verbiage and reasoning behind any substitution clauses. Substitution is not always straightforward and often has limitations in either quantity or product eligible for substitution. For example, you may not be entitled to substitute products between IBM Software product brands (such as WebSphere for Tivoli or Data Management for Lotus). Understanding the substitution rules now avoids surprises and assumptions that can lead to costly delays in the projects later.
Understand the status of maintenance and support:
You may have purchased maintenance in the past either with licenses or separate from the licenses. If you are making another software purchase, you will have new maintenance explained and you may want to bring all of your maintenance together. The SDT should determine which products are supported and who is receiving that support. All members of the SDT must fully understand any changes in the maintenance and support terms. Also, look ahead since the new solutions are defined to forecast who may need to be educated on the support process as you rollout the products.
Be aware of any global support needs:
If you are a global company and the solutions you will deploy are in multiple countries or regions, ensure that all of your locations are educated in the support processes and are ready for the projects. You will work closely with your IBM team to set up these global locations for media, technical support in the local language and time zone, etc. It is best to address these needs early and avoid frustration when trying to accomplish this in a crisis. For more information about global deployments, see Chapter 9, “Managing global software deployment projects” on page 73. Be proactive:
Through all of the above activities, the SDT should look aheadand address the needs before they become critical issues. Frequent
discussions, a steady focus on the business goals, and early identification of potential issues will help you be proactive.