© 2014 ibm corporation ibm control desk release management workshop – self facilitated designed...

© 2014 IBM Corporation

IBM Control Desk Release Management Workshop – Self Facilitated

Designed for Interconnectivity to Change & Configuration

o


Your company has recently purchased IBM Control Desk and wish to enable functions in the area of release management, with interlocking processes for change & configuration management.

Planning an implementation of a configuration, change and release solution is more than just an install of the software.

Process Workshops are conducted to design and define the processes, configuration and use of the new tool set. Workshops are simply one of the steps in the overall methodology of software implementations.

Allowing your stakeholders and users to come together to define business processes helps ensure adoption of the software.

– Ensure that you include all the stakeholders in the planned workshop.– Use the workshop to design how the tool will support the process, or improve the process.

To ensure faster agreement of new process changes for configuration management.

Establish your project focus and momentum.

Confirm ownership and mission.

2

oWhy Use this Deck?


This deck is constructed to facilitate a workshop and to be used in a group setting. – The slides should facilitate discussion and ensure design and configuration decisions.– The collaborative workshop should take hours or days to ensure complete design.

The workshop should be more than just talking about current processes, it is improving and determining configurations for IBM Control Desk (ICD) capabilities.

– Do not recreate current tool capabilities into IBM Control Desk, this will produce failure before you start.

– Always assess and ask “why?” when appraising current processes. Be cognizant of what works and what doesn’t. Build on what works in your current processes, do not be afraid to reconstruct what does not work!

Draw diagrams, write on whiteboards or present diagrams/documents to help illustrate points or relay information among the attendees.

Always ask “WHY?” If the “why?” doesn’t come quickly, skip over and return to ask Why.

The slides are not designed to ask every question for each process, they are meant to focus the group on what configuration and processes are necessary for the implementation.

3

oHow to Use This PowerPoint Deck o


Activities to complete before conducting workshop:– Have leaders/organizers or all of the attendees read the following list of pre reads (details in

note section below)– Ensure the project team has completed the base data design or ensure the focus of this

workshop to define the necessary base data during this workshop.• If the base data design is complete it should be understood by attendees (details on Base

Data in Project Configure link in notes section below)

Collect any current documentation or diagrams on current processes to reference during workshop.

Consider using the Process Content Packs, if you determine their use, understand the impact on the workshop decisions and design.

Process Content Packs - Informational

Before beginning this workshop, you should consider whether you would like to roll out release management in conjunction with change and configuration management. If so, there is a change management workshop & a configuration management workshop to use in collaboration. Alternatively, these workshops can be used separately, depending on your roll out and process decisions.

Ensure Design Document is updated as part of the workshop! See embedded doc.– Identify a documenter for the workshop and provide them this Design Document

4

oTo Be Completed Before the Workshop o

Microsoft Word Document

http://www-01.ibm.com/support/knowledgecenter/SSZRHJ_7.5.3/com.ibm.sccd-saas.doc/overview_cloud/c_proc_content_packs.html

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=e25892f0-20f7-46ff-bbe9-c7c03fb3036f




© 2014 IBM Corporation5

o

The Next Slides Should Be Used in the Actual Workshop !


Define Project Objectives, Goal, and/or Mission

Describe and document the project mission, goals – Where do you want to be?

– Understand your strategy for configuration, change and or release management processes and how it fits into the wider operational & business context.

• Does it align to the overall business goals? – This is a critical step for all attendees, to ensure all in the organization are in agreement of the

goal and objectives of the project.– Ensure this mission is agreed to at the executive level.– These goals drive the overall project, approach, and timeline.

Measure for success - How do you know you made it?

– This does not need to be endless set of metrics but you need to be able to measure the success, or milestones of the project work.

– Examples:• Reduction of the number of Outages Caused by a Release.• Increase in the percentage of Releases delivered on time for Production • Reduction in the number of Failed Changes in a Release (Percentage of Failed

Changes)• Increase number of changes being grouped into a release for strong rollout and

planning.

6

o


High Level Discussion Topics

Are there shortcomings of processes or capabilities that should be discussed & what priority should they be addressed in this project?

• It may not be possible to tackle them all so priority is key• Do not try and rebuild old tool in new tool, you will carry the shortcomings with you.

What data if any will need to be migrated from existing tools (discovered data, categorizations, organization, relationships, configuration items, work groups, black out periods, change windows)?

Are there any regulatory, audit compliance or best practice (ISO19770, ISO2000, ITIL, COBIT, SOXS) requirements that must be met?

• If yes, who is the stakeholders or interested parties, that can ensure compliance?

Does the project have in scope items or exclusions? • Ensure they are documented and adhered to throughout workshop session.

What metrics, SLA, KPIs & reports are produced now, and what is required additionally going forward? How does the process perform against targets today?

• Do not recreate reports just to create them, validate they are needed as many reports exist in legacy systems that are unused or of no value with next or current processes.

How many expected users? How many self service users? Will there be 3rd party/external users?

7

o


High-level Process Flow o

Release Strategy

Plan Release Strategy

Change

Change Management

Design & Build Release

Solution Acceptance

Solution

Asset DeploymentInquiries & Requisitions

Monitor & Report Release

No

Asset Management

Test & Verify Release

Review & Close Release

Release

Release

Deployment Management

Release Acceptance Request

Change Management

Release Verified?

Deployment Reports

Release Reports

Yes

Release


Designing Through Use Cases

Slides 10 – 19 are use case slides, created to help you through the design workshop if you do not have use cases documented or they are similar to these.

If your business already has use cases defined, use them as the basis for the workshop discussions independently or in conjunction with the ones provided.

– There are common use cases on the next few slides, and same as used in Project Start– The next slides provide use cases for release management processes. The questions in the

gray box at the bottom of the slides should be discussed, in order to extrapolate as much design, process discussions and aid you to establish the configurations for the Control Desk UI.

If the business only has a list of requirements and not use cases, it is suggested to utilize said list in conjunction with the use cases provided in the following slides.

– It is not recommended to base the design solely on a requirements list. This will cause the tool/process not to flow based on user tasks and cause user dissatisfaction.

Discuss the use cases in the following slides collaboratively, as the slides help with general use questions.

– The general questions apply to all of the use cases to help facilitate a good business discussion and define the design for configuration.

9

o


As a change manager it is necessary to combine the right changes into a release such as might be necessary for a multi-resource set of changes that are complex and require coordination and time

synchronization for all the resources involved.

(Example roll out of new application)

10

• Are there persons identified for release management within the organization?

• Are processes defined to leverage release management?

• Do the software teams who support and manage applications leverage the processes of the release concept?

• Is the release owner able to plan the release (as it is like a project) to ensure the complexity of the many changes or many Configuration items which will be impacted?

• Is the “plan” (release) visible to the many resources that may be engaged to ensure momentum?

• How is the plan communicated across other disciplines such as Change Management, and the configuration item owners or the business?

• Typically releases which are several complex changes, may in fact include hardware and software, how is asset management engaged for the planning phase?

Plan – Complex Set of Changes o


Periodic releases for major updates to multiple resources can be set to only be completed at a set time. These non-critical groupings of changes can be bundled executed when a pre-authorized time frame is

identified. A change manager would help gather these changes together.

11

• Is the change manager enabled to group periodic changes into a release to allow the release process to better manage and plan the set of changes?

• How are the configuration items identified for the major updates?

• What process might be used to understand the it infrastructure when grouping these changes so as to find a time schedule for the release to be executed?

• How is the release manager able to view the resources so that he or she may work the bottlenecks that can occur?

• What procedures are used to analyze the changes that will make up periodic changes grouped for a release ?

• Are full deployment plans defined to ensure to minimize outages?

Plan – Periodic Changes o


Standard procedures for the delivery of fix packs and security patches across many like kind Configuration items are often rolled into release to allow for mass deployment of the software updates. This would be

planned and coordinated through a release to ensure repeatable processes and lower risk.

12

• Does operations schedule many changes to apply a single fix or patch to many servers and thus release management procedures are the driver behind the steps for these changes to the configuration items?

• Are the release and change manager able to work release plans together to optimize resource utilization?

• For mass deployment changes are the grouped into a release ?

• Are there pre-documented/predefined repeatable processes for fix packs, security patches?

• Are configuration item owners interlocked to the process ? How?

• Are there communications pre defined for standard procedures when it comes to mass deployments of fix packs and patches?

• Is there an ability to (plan) group like configuration items into released to ensure repeatable processes can be followed by any resource performing the work?

Plan – Mass Deployments o


A release owner or release specialist, is assigned a release and must design and build the necessary scripts, or package to deploy the software. This will include communication and training plans as well as any

back out procedures that must be defined.

13

• Are there standard procedures for package and script building ?• Are there skilled resources aligned to release script and package building? Or must they be

found for every release plan? • Who resolves resource issues if there are any, Is the Release manager enabled to do so?• Design and build also includes communication plans, are there resources in the organization

tasked with these activities, or are new resources used every release? • How are the release owner and specialist linked to the training resources, to build and design

the training plans? • Are there guidelines to the defining of back out procedures? • If the design includes additional or new hardware, how are the release owner or specialist

enabled to work with the asset team? • How well does the processes of release design and build collaborate with other areas such as

change implementers, or configuration item owners? • If new equipment is needed in the datacenter is this also part of the design and build step in a

collaborative approach? • Does the design and build focus on the nature of the release? (hardware, software, where?....)• Which type of resources are necessary for deployment?• Is any specialty Software needed for the deployment and is it owned?

Design and Build– Delivery of Packages and Scripts o


When a release is ready for testing and validation the release owner and/or, release specialist will test the package built to ensure it works, is free of errors and can be reviewed for success and acceptance into the

plan phase. Depending on the type of release this phase may vary in duration and resources.

Once the packages are validated the are recorded in a Definitive Media Library or data storage source

14

• Are there dedicated testing resources, besides the design and build resource?

• When testing are there standard testing procedures that are followed for all releases?

• Are all results of the testing documented and reworked as part of the testing phase with the design and build resources?

• If the testing should become accepted after testing is complete is the package and scripts recorded or stored? Such as in a definitive medial library or database of some sort?

• Are all facets of the “packaged” tested, including documentation, back out plans and a review of the communication plans as well?

• Are the scripts and packages properly documented for the resources that will deploy in production?

• Has the plan accounted for running the scripts in advance in a testing or staging environment before production as part of the testing strategy?

• Are testing strategies and tools reviewed periodically to ensure effectiveness of the build requirements as software and hardware change?

• Is the testing resource the release deployer? Or how is the deployer resource enabled?

Test and Accept– Package Testing for Acceptance o


Release owner & specialist work with the release manager and administrator to schedule the release, for particular dates, the deliverables, work to ensure any new assets or Configuration Items are part of the

overall release as well as schedule the training that has been defined or built in the build phase.

Additionally the communication plan is laid out.

15

• When planning the rollout, are the specialist and deployer creating a set of detailed plans which include the dates, tactical deliverables, impacted/affected Configuration items., change records as well as the locations or sites ?

• If the plan includes new hardware is the plan accounting for these actions and details with the Asset management resources?

• If the plan includes new hardware installed are there changes interlocked occurring in advance of the deployment?

• If so how is the release manager ensuring overall release schedule and plan.• Has the release been scheduled? If so are change resources in the know? • Has the training been set to the noted plan and scheduled? • Are all resources for who will perform the implementation identified? Are there standard skilled

resource pools to draw from? • Are the durations of each task and activity fully understood by implementation resources and

the release owner and manager? • Are all pre-requisites documented and assigned?• Has the communication plan been reviewed and final details set out? • Is the plan roll out interlocked to the change management process?

Plan Rollout– Details of Rollout, Training, Scheduling and Resources o


To ensure all stakeholders, end users, support team are aware of the upcoming release(s) the release administrator, owner, and manager, will use the defined communication plan to communicate the release

schedule, this includes any specific shutdowns, reminders or testing. This is a focus on awareness.

16

• Has there been defined standards for how to work the communication plan?

• Are there templates and defined tools and mechanisms for ensuring all persons who need to be notified are being notified?

• Are the communications being used effective and detailed enough? Include things like Schedule, shut downs, reminders for any steps they must take?

• Has the communications been focused on the who is affected by the release?

• If there will be outages, has the outage been minimized through the design and build approach and tools?

• Has the communication included the training to ensure resources have attended?

• If Configuration items will be added or removed have the configuration owners been engaged and the preparation for managing and monitoring been communicated?

Prepare and Communicate– Final Preparations, and Awareness o


The release deployer, change owners and change implementers will distribute the release to the configuration items which are the focus of the release. This would occur during the scheduled release dates

and times that were defined in the plan. Should it be necessary the back out plans from the plan phase would be invoked.

17

• What approach is used to ensure the release deployers if there are many are synchronized in the deployment?

• How is the release deployer ensure to use the correct installation of hardware and software? • Is the deployer provided a guide and ensured it is updated with any last minute updates? • Does the deploy resource(s) update the Configuration items database? • Is any discovery tools used to rediscover Configuration items after the release? • Are the removal of any assets, or configuration items, completed with standard tools? How is the

data advised to resources who may need to update data bases or handle the retirement of assets, physically?

• Are the operations teams engaged at time of release to put the configuration items into standard operating procedures

• Is the release owner engaged throughout the implementation to ensure progress and tasks are moving as expected?

• Are communications with configuration management resources or others being over seen by the release owner to ensure modifications and updates?

• If this was a grouping of many change records are the change records being updated timely and with the standard procedures?

• If a back out plan was invoked is there a call/discussion, before invoking the back out? Are the appropriate resources engaged?

Distribute and Install – Release Deployment o


The release manager, owner, or administrator will review the release for deployment success and update the record with comments for review and closure.

18

• Are there standard operating procedures for reviewing and closing a release?

• Does this process mirror or align with the process for Change management?

• Are the right resources engaged to review and close the release.

• If the implementation failed or partially failed how is the record reviewed and re-worked? What approvals or reviews are necessary to complete the work?

• Does the release owner ensure to note the challenges or what worked very well?

• Is the review analysis harvested for upcoming releases and continuous improvement?

• Does the release manager record success rates for deployment during review and close?

• Has the release process and review procedures included the human resources as well as any technical tools and processes?

• How is any missing documentation or data /follow completed? Is the release status noted as this?

• Are lessons learned recorded and shared with all resources?

Review and Close o


Workshop - Wrap Up

Ensure you have defined the data sets for the fields and data noted in the design document?

Have all use case flows been defined and no action items?

Have you interlocked or prepared how this design impacts change or configuration management?

Is there a need for the additional process workshops on change and configuration?

Are there any necessary fields to be added to the user interface? Be sure the documentation has recorded these fields. • How to decide what is mandatory?

It is necessary to identify/discuss any required integrations for the implementation. • The required integration(s) should be noted in the design document • The overall design of the integration(s) should be a separate workshop, to allow the inclusion

of the technical resources

Verify with workshop attendees if there are any open items?

Set date for validation of the design as it may take the documenter a few hours/days to ensure completeness before distribution.

o




Design Validation

20

Once the design is complete and documentation is complete, ensure full organizational buy-in/sign off on configurations. • Have a quick working session to share and explain the design and approach with any who may

not have attended the workshop but will sign off on design.

Once configuration of the software has begun, engage with the users (all roles) to review early, often and always.

Design/configuration validation should occur in varying systems such as development and User Acceptance, or what ever the systems are called, which are pre-production.

Pre-production system(s) should be configured based on the design document to the exact letter. • If configuration and tool capabilities conflict, the issue should be addressed straight away with

the full team if possible or if necessary.

o


Next Steps

21

Once validation is complete, configuration of the software should begin.

Training: Determine any training approach that may be needed for the overall project rollout.

Consider and define a rollout strategy, for go live. .

o

© 2014 ibm corporation ibm control desk release management workshop – self facilitated designed...

Documents

processes of configuration

collaborative workshop

configuration requirements

workshop session

planned workshop

area of release management

configuration o

configuration decisions