1. © 2014 IBM Corporation IBM Control Desk Change Management Workshop – Self- Facilitated Designed for Interconnectivity to Configuration & Release o

2. © 2014 IBM Corporation  Your company has recently purchased IBM Control Desk and wish to enable functions in the area of change management, with interlocking processes for configuration & release management.  Planning an implementation of a change, configuration, 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 change management.  Establish your project focus and momentum.  Confirm ownership and mission. 2 o Why Use this Deck?

3. © 2014 IBM Corporation  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.  This deck was designed to be used in conjunction with the configuration management & release management workshops. Configuration, change and release management processes are tightly intertwined, and we recommend considering all when working the configuration workshop.configuration management release management workshops 3 o How to Use This PowerPoint Deck o

4. © 2014 IBM Corporation  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 change management in conjunction with configuration and release management. If so, there is a configuration management & release management workshops to use in collaboration. Alternatively, these workshops can be used separately, depending on your roll out and process decisions.configuration management release management workshops  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 o To Be Completed Before the Workshop o

5. © 2014 IBM Corporation5 The Next Slides Should Be Used in the Actual Workshop ! o

6. © 2014 IBM Corporation Define Project Objectives, Goal, and/or Mission  Describe and document the project mission, goals – Where do you want to be? –Understand your strategy for change, configuration 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: Percentage reduction in unplanned changes, on configuration items. Change tickets are routed through an automated workflow, which improves efficiency of the change resources involved in getting a change to implementation. More changes are accepted as standard changes due to improved job plans and successful changes. Change meetings have become more effective in review of changes as the records are more correctly structured and define the change better. 6 o

7. © 2014 IBM Corporation 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

8. © 2014 IBM Corporation High-level Process Flow o Create & Record Change Request Assess Schedule Accept & Categorize Change Implementation Review Change Standard Change Change Request Change Assessment Information Request Change Assessment Information Project Proposal Change Schedule Implementation Progress Date Change Implementation Communication Request Fulfillment Assessing Processes Portfolio Management Release Management Deployment Management Requestor Implementing Process Monitor & Report Change Management Authorize Change Close Change

9. © 2014 IBM Corporation 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 based on change management processes. The questions in the gray box at the bottom of each slide 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

10. © 2014 IBM Corporation As a change requester, I need to submit a pre-approved standard change, to implement an update/change to a single or multiple configuration items. As an organization there is an agreed upon list of standard changes have been defined by the business from which I am aware of. Based on this list the change if filled in correctly can move to directly to the implementation phase, though it may be noted during the Change Advisory board discussion as a listed upcoming change. 10 Does your organization have defined a set of change types? If yes do they have an agreed to flow? Is the standard (simple) change a “fast path” for those changes the business has preapproved/reviewed? Are standard changes reviewed periodically to ensure they are valid and should remain as such? How does the change requester through a standard change interact with configuration item owner? Does the change manager review randomly standard changes to ensure the “guidelines” are being adhered to? Are standard changes discussed at the Change advisory board discussion/meetings to assure cohesiveness with other changes? How is the change implementer assigned to the standard changes? How are the “steps” to standard changes applied to the change? Who manages the overall steps of each standard change to ensure validity ongoing? Are the configuration items connected to the standard change record to ensure, update and accuracy of the configuration items? Do standard changes support configuration items that are not discoverable? Does your organization have defined a set of change types? If yes do they have an agreed to flow? Is the standard (simple) change a “fast path” for those changes the business has preapproved/reviewed? Are standard changes reviewed periodically to ensure they are valid and should remain as such? How does the change requester through a standard change interact with configuration item owner? Does the change manager review randomly standard changes to ensure the “guidelines” are being adhered to? Are standard changes discussed at the Change advisory board discussion/meetings to assure cohesiveness with other changes? How is the change implementer assigned to the standard changes? How are the “steps” to standard changes applied to the change? Who manages the overall steps of each standard change to ensure validity ongoing? Are the configuration items connected to the standard change record to ensure, update and accuracy of the configuration items? Do standard changes support configuration items that are not discoverable? Create & Record Change Request – Standard Change o

11. © 2014 IBM Corporation As a change requester, I need to submit a normal change record, to implement an update/change to a single or multiple configuration items. As an organization it is agreed that normal changes will follow a predefined ITIL like flow which is defined by the change board of our organization. This change will be guided through to completion with a change owner, and reviewed by the change board. 11 Are there predefined approval processes for “normal” changes? Are there defined roles for the change process? Are there distinct change of ownership tasks to the flow of normal changes? Is the change requester required to enter a set of predefined data before a “normal” change can be submitted? Are there predefined procedures for the change owner to follow for how to receive a change? Is there defined roles for who can submit changes? How today is the change management process interconnected with the other ITIL processes such as; configuration, incident, problem, release? Are the configuration items identified for the normal change?, How is the configuration owner identified that a change is being applied against their configuration item? Are there predefined “templates” flows that normal changes follow? Are the templates controlled by change resources or centrally? Or managed by areas such as network? Application support? Etc… Does the change manager have visibility to the incoming changes and volume? Are there predefined approval processes for “normal” changes? Are there defined roles for the change process? Are there distinct change of ownership tasks to the flow of normal changes? Is the change requester required to enter a set of predefined data before a “normal” change can be submitted? Are there predefined procedures for the change owner to follow for how to receive a change? Is there defined roles for who can submit changes? How today is the change management process interconnected with the other ITIL processes such as; configuration, incident, problem, release? Are the configuration items identified for the normal change?, How is the configuration owner identified that a change is being applied against their configuration item? Are there predefined “templates” flows that normal changes follow? Are the templates controlled by change resources or centrally? Or managed by areas such as network? Application support? Etc… Does the change manager have visibility to the incoming changes and volume? Create & Record Change Request – Normal Change o

12. © 2014 IBM Corporation As a change requester, or change manager it is necessary to submit an emergency change record, to implement a quick update/change to a single or multiple configuration items. Emergency changes happen from time to time and the organization recognizes this and provides a path of the urgent change to flow with the focus of understanding risk and alerting those as defined to ensure quick approval and fast implementation. 12 Are there predefined paths for emergency changes? Are there roles defined who can create an emergency change? How are approvers and reviewers of emergency changes alerted to the fast review and approval? Are members of the Change Advisory Board for emergencies the same as the regular board? Is there varying approvals for emergency changes based on a set of data parameters? Can other “groups “ or processes create emergency changes, such as problem managers? Service desk analysts? Are there predefined paths for emergency changes? Are there roles defined who can create an emergency change? How are approvers and reviewers of emergency changes alerted to the fast review and approval? Are members of the Change Advisory Board for emergencies the same as the regular board? Is there varying approvals for emergency changes based on a set of data parameters? Can other “groups “ or processes create emergency changes, such as problem managers? Service desk analysts? Create & Record Change Request – Emergency Change o

13. © 2014 IBM Corporation As a change requester or owner, I have submitted a change record (typically a normal or emergency change) which is ready for review and classification to ensure it has the necessary data to begin being managed and worked through the correct change process flow. Standard changes often move through this step as pre-accepted and categorized. 13 Are there currently change processes that drive the control of your configuration items? Are the procedures for accept and categorize of the change different based on type? If a configuration item is the target of a change, is there a repository for which the configuration item is stored? Are change owners defined across different disciplines?(say network security?) or are they role based? Are there predefined data sets that must be provided to ensure the change is accepted regardless of type? Or do they change by type? Is there a predefined time frame for the step of accept and categorize? Is the control of the change management process interlocked to other processes? Configuration item and Asset management or release? Must all changes regardless of type have an asset or configuration item? For acceptance? Are the related Configuration items understood when a CI is selected on a change? Can/will the Change owner update the record as they are accepting? Or is there a return to requester process for more/new/additional data? Are change windows identified on all configuration items? Are there currently change processes that drive the control of your configuration items? Are the procedures for accept and categorize of the change different based on type? If a configuration item is the target of a change, is there a repository for which the configuration item is stored? Are change owners defined across different disciplines?(say network security?) or are they role based? Are there predefined data sets that must be provided to ensure the change is accepted regardless of type? Or do they change by type? Is there a predefined time frame for the step of accept and categorize? Is the control of the change management process interlocked to other processes? Configuration item and Asset management or release? Must all changes regardless of type have an asset or configuration item? For acceptance? Are the related Configuration items understood when a CI is selected on a change? Can/will the Change owner update the record as they are accepting? Or is there a return to requester process for more/new/additional data? Are change windows identified on all configuration items? Accept and Categorize – All Change Types o

14. © 2014 IBM Corporation As a change owner or manager it is necessary to ensure a change is assessed based on the type of change, the work to be performed and the configuration items that will be impacted. In most situations a standard change is already assessed as part of the overall process. Normal changes will be assessed to ensure data and values are correct based on the type of change and that it really is a normal change. The manager or change advisory board may often be the assessment team for an emergency change as it will focus on risk and less about the type of change, only that it must move quickly to resolve the current outage or degradation of service. 14 Are all configuration items statuses controlled through change, or is it dependent on change type? During the assessment process can the change owner update the predefined set of tasks to be performed? Is there a loop back process if that changes the “type” of change? Are there different assessment processes that must be followed by change owner, based on the type? For the emergency change how is the assessment approach different? Is there a level of risk associated with the assessment? Does the assessment pace alter based on the change type? Are the persons/roles involved in the assessment phase defined by only change type? Or is it by each change “template” or are they defined based on the individual change creator selecting them? Are change windows identified on all configuration items? Can incidents and problems associated to the change impact the change assessment? Is the business involved in all assessments? Or performed by a representative? During the assessment step are the configuration items verified by the configuration item owner(s) ? Are the status change procedures documented and communicated? Are the assessment guidelines defined and documented for reference? Do all standard changes pass the assessment phase? Does assessment mean both technical and business for your change process? Are all configuration items statuses controlled through change, or is it dependent on change type? During the assessment process can the change owner update the predefined set of tasks to be performed? Is there a loop back process if that changes the “type” of change? Are there different assessment processes that must be followed by change owner, based on the type? For the emergency change how is the assessment approach different? Is there a level of risk associated with the assessment? Does the assessment pace alter based on the change type? Are the persons/roles involved in the assessment phase defined by only change type? Or is it by each change “template” or are they defined based on the individual change creator selecting them? Are change windows identified on all configuration items? Can incidents and problems associated to the change impact the change assessment? Is the business involved in all assessments? Or performed by a representative? During the assessment step are the configuration items verified by the configuration item owner(s) ? Are the status change procedures documented and communicated? Are the assessment guidelines defined and documented for reference? Do all standard changes pass the assessment phase? Does assessment mean both technical and business for your change process? Assess – Normal & Emergency (Standard is Pre-assessed) o

15. © 2014 IBM Corporation As a change moves through the process steps it is necessary for the change owner and requester to schedule the change so that the change Advisory board and manager will approve the work at the time that is requested. As the change owner it is the responsibility to find the best time for the implementation. There are many factors that influence the schedule especially the type, typically emergency changes are handle quite quickly where the standard and normal will occur during normal maintenance windows for the Configuration items. 15 Are there defined and documented processes for scheduling a change based on type? Are there roles who can schedule a change? If a change must be rescheduled? How is it communicated, back to requester? Or impacted configuration item owners during the review/authorize schedule process? For Emergency changes how is the rapid scheduling handled? Are there predefine change roles and or persons? Does the change manager aid in review of the schedule before the change review board meetings? Is there a calendar of changes being scheduled viewable by change resources? Can others of the organization view the scheduling? How does the business influence the schedule? Do all configuration items have maintenance windows? Are there predefined change windows? How does a change get scheduled through a black out period if necessary? Are the procedures documented? Are there defined and documented processes for scheduling a change based on type? Are there roles who can schedule a change? If a change must be rescheduled? How is it communicated, back to requester? Or impacted configuration item owners during the review/authorize schedule process? For Emergency changes how is the rapid scheduling handled? Are there predefine change roles and or persons? Does the change manager aid in review of the schedule before the change review board meetings? Is there a calendar of changes being scheduled viewable by change resources? Can others of the organization view the scheduling? How does the business influence the schedule? Do all configuration items have maintenance windows? Are there predefined change windows? How does a change get scheduled through a black out period if necessary? Are the procedures documented? Schedule – All Change Types o

16. © 2014 IBM Corporation As the Change Manager and the Change Advisory Board it is necessary when the change is fully specified for the change to be reviewed and approved in order to move on to the implementation phase. The Change Manager will conduct a change management review call/meeting and change members will review and approve the changes to be implemented, or returned to owners for additional information before scheduling. Standard changes are typically preapproved, as long as they fall within the maintenance window. 16 Are there predefined change Advisory board members? Is there a set schedule to the change meeting of the advisory board? How does the change board come together to authorize an emergency change? Can a change manager approve changes without review of the board approval? Do all changes need to have both a business and technical approval? Are all standard changes preapproved? If the change is not authorized for varying reasons, is the change requester alerted for rework? How will the change be resubmitted for work, after it is not approved? If a change is rejected by the approval team, is a new change record required? How are the approvals recognized by the different members? Are changes required to be approved by many in a single “group” or only 1 of the many of the group? Is there a time frame required by the change approval process to ensure all changes are submitted in time for “approval”? Are there predefined change Advisory board members? Is there a set schedule to the change meeting of the advisory board? How does the change board come together to authorize an emergency change? Can a change manager approve changes without review of the board approval? Do all changes need to have both a business and technical approval? Are all standard changes preapproved? If the change is not authorized for varying reasons, is the change requester alerted for rework? How will the change be resubmitted for work, after it is not approved? If a change is rejected by the approval team, is a new change record required? How are the approvals recognized by the different members? Are changes required to be approved by many in a single “group” or only 1 of the many of the group? Is there a time frame required by the change approval process to ensure all changes are submitted in time for “approval”? Authorize – Approval to implement change o

17. © 2014 IBM Corporation As a change implementer I will execute the updates, changes, edits or removal of service that are defined in the change. The implementation of the change/updates are applied to the resources in the IT infrastructure at the time the change is scheduled. 17 Are the change implementers engaged early in the change cycle to ensure they have what they need for a successful implementation? Does the implementer update the change status when they start? Through-out implementation? What statuses are necessary for this step of change? Or the overall process of change? Can the change implementer update any part of the change record? Or only work log and status? Does the change implementer manually update the configuration items or will the updates come through discovery? Is the change state as complete when the work is complete? Or when the configuration items have been reconciled to a discovery source? If the change must be backed out? Is there a formal process for the implementer to follow to communicate the back out? If the change is partially implemented? Can the change be reworked for next change opportunity? How is progress of the change during the change window communicated? Is it necessary? Are changes being made communicated across the infrastructure teams in advance? Such as with the service desk manager and team? Are all changes implemented by a set of resources regardless of type? Are the configuration item owners identified at time of change implementation when a configuration item is taken out of service? How are configuration item owners identified for new configuration items created during a change? Does the change implementer create the configuration item? Does the change owner get notified when the change is complete? If the implementer is aware of known issues, does he/she create knowledge items for support to the service desk if the change is released as is? Are the change implementers engaged early in the change cycle to ensure they have what they need for a successful implementation? Does the implementer update the change status when they start? Through-out implementation? What statuses are necessary for this step of change? Or the overall process of change? Can the change implementer update any part of the change record? Or only work log and status? Does the change implementer manually update the configuration items or will the updates come through discovery? Is the change state as complete when the work is complete? Or when the configuration items have been reconciled to a discovery source? If the change must be backed out? Is there a formal process for the implementer to follow to communicate the back out? If the change is partially implemented? Can the change be reworked for next change opportunity? How is progress of the change during the change window communicated? Is it necessary? Are changes being made communicated across the infrastructure teams in advance? Such as with the service desk manager and team? Are all changes implemented by a set of resources regardless of type? Are the configuration item owners identified at time of change implementation when a configuration item is taken out of service? How are configuration item owners identified for new configuration items created during a change? Does the change implementer create the configuration item? Does the change owner get notified when the change is complete? If the implementer is aware of known issues, does he/she create knowledge items for support to the service desk if the change is released as is? Implementation – All Change Types o

18. © 2014 IBM Corporation After a change is implemented, as a change manager, implementer, or owner, it is necessary to have the change verified that the updates had the desired effect on the configuration items and the overall Infrastructure and were applied correctly and without issue. 18 Who performs the change review? Is the review performed by more than one resources? Is it a group review? Are all changes reviewed? What are the parameters for which a change is reviewed? If it was an emergency is it reviewed for root cause? If not all changes are reviewed what is the documented factors for which changes are reviewed? Are post implementation documentation part of the review process by the implementation resource? If the change was partially implemented does it go through review before completion? For lessons learned? How are reviewed changes and lessons learned procedurally handled to continuously improve? What part of the record is editable for the review? Is the change requester involved in the review output? Do all changes move to closed after review? Is there any other status necessary? Are configuration items verified during the review step? Did it occur as a post implementation step before it got to review? Are actions taken to control undocumented changes? What controls and processes have been enabled to ensure configuration control and no unauthorized changes? If an unapproved change was done, is it reviewed and discussed as part of change advisory board? If an auditor does perform an audit and the configuration items prove to have been changed what actions is taken and by who? Who performs the change review? Is the review performed by more than one resources? Is it a group review? Are all changes reviewed? What are the parameters for which a change is reviewed? If it was an emergency is it reviewed for root cause? If not all changes are reviewed what is the documented factors for which changes are reviewed? Are post implementation documentation part of the review process by the implementation resource? If the change was partially implemented does it go through review before completion? For lessons learned? How are reviewed changes and lessons learned procedurally handled to continuously improve? What part of the record is editable for the review? Is the change requester involved in the review output? Do all changes move to closed after review? Is there any other status necessary? Are configuration items verified during the review step? Did it occur as a post implementation step before it got to review? Are actions taken to control undocumented changes? What controls and processes have been enabled to ensure configuration control and no unauthorized changes? If an unapproved change was done, is it reviewed and discussed as part of change advisory board? If an auditor does perform an audit and the configuration items prove to have been changed what actions is taken and by who? Review – Post Implementation (All Change Types) o

19. © 2014 IBM Corporation After all implementation tasks are complete, and the change has been verified, the Change Owner will record if the change was successful. The Change Owner makes this determination through consultation with stakeholders, such as members of the Change Advisory Board, the RFC submitter, Users, Customers, and others. The change will then be sent to completed/closed. 19 Who can set a change to closed? Are changes auto-closed after set number of days after review? Can the implementer set a change to closed after implementation if it is say a standard change type? Is the review discussed and approved before setting the status to closed ? Are there any standard operating procedures that would stop a change from being closed? How is the communication handled back to stakeholders, users and customers of a change being complete or closed? Will a final reconciliation of configuration item updates be walked through by configuration owner before the change record is set to closed? Can incidents be active on a closed change? Would it remain “review” until incidents resolved? What reporting is necessary for changes as they close? What visibility of closed changes is necessary by the change resources for other change work? (duplication, review before other changes?) Are there any regulatory items that must be completed before a change can be set to closed? Who can set a change to closed? Are changes auto-closed after set number of days after review? Can the implementer set a change to closed after implementation if it is say a standard change type? Is the review discussed and approved before setting the status to closed ? Are there any standard operating procedures that would stop a change from being closed? How is the communication handled back to stakeholders, users and customers of a change being complete or closed? Will a final reconciliation of configuration item updates be walked through by configuration owner before the change record is set to closed? Can incidents be active on a closed change? Would it remain “review” until incidents resolved? What reporting is necessary for changes as they close? What visibility of closed changes is necessary by the change resources for other change work? (duplication, review before other changes?) Are there any regulatory items that must be completed before a change can be set to closed? Close – Communicate and Closing a Change o

20. © 2014 IBM Corporation 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 configuration or release management?  Is there a need for additional process workshops with a focus on configuration management & release management?configuration management release management?  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

21. © 2014 IBM Corporation Design Validation 21  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

22. © 2014 IBM Corporation Next Steps 22  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