Planning a Change
During the risk & impact analysis phase of a change, the change manager gathers the information needed to plan the implementation of the change in such a way that it:
- minimizes the risk of an implementation failure, and that it
- minimizes the impact that the implementation has on the customers.
Risk & impact analysis tasks are used to gather this information and to finalize the implementation plan.
Questions:
How many risk & impact analysis tasks are related to the change workflow that you just registered?
There are four risk & impact tasks related to the change workflow. Risk & impact tasks can be identified in the Gantt chart by the question mark 
icon.
Why did Xurrent automatically change the status of this change workflow?
After you pressed the Start button and saved the workflow, the first task of the change workflow was assigned and the status of the workflow is set from “Registered” to “In Progress”.
Continue
Change managers normally know enough about their services to be able to complete most of the risk & impact analysis tasks. In fact, Barney Turban can handle all of the risk & impact tasks that are related to the change workflow you just registered.
In Barney’s inbox, you will find the first risk & impact task of this change workflow:
Will the change implementation cause the service to become degraded or unavailable?
Answer it as follows and set its status to “Completed”:
We should first upgrade 1 of the 2 server blades and put it back into production before we pull the other and upgrade that one. This ensures that the service will remain available, even though during the upgrade of a server the service will be degraded because its redundancy will no longer be available.
Questions:
How many successors does this task have?
When you open the ‘Relations’ section, you will see that it has two successors (and no predecessors).
How did the completion of this task affect its successors?
It caused the status of the two successors to be updated from “Registered” to “Assigned”.
Continue
You should now be able to find two more risk & impact tasks in Barney’s inbox:
1). When would be the best time to implement the change?
2). Will events be generated when the change is implemented?
Answer these tasks as follows:
1). The servers should not be upgraded from Monday through Saturday (Central Time). Those are the service hours (see the "Gold Windows Server for the Sales Tracking Production Instance of Widget Data Center" SLA) and we should not degrade the service during these hours if it can be avoided.
2). Yes, the CMP00007 and CMP00069 are monitored, so as soon as we pull one of them, the operators will start to receive NNM events. We must plan to inform the operations team.
Complete each task after you have answered it.
Question:
Why is it important that Barney documents the answers to the risk & impact analysis questions even though he already knew the answers?
To ensure that the approvers of the change (and possibly auditors) understand why he decided to plan the change the way he did.
Continue
The fourth and final risk & impact task was assigned to Barney after these last two tasks were completed. That happened because those two tasks are the predecessors of this fourth task.
Pick up this fourth task from Barney’s inbox (be sure to open the one for the correct change workflow)
Question:
In the inbox Rodney Wilson is visible as the Requester of the task. Why?
Rodney Wilson is the Requester of the first request that is related to the change workflow. When the change workflow would not be related to any requests or problems the inbox would show the workflow manager as the requester.
Be sure to specify in the “Put change into production” task that it should not be started before Sunday 6am and check the Work hours are 24×7 box. Specify in the Planned duration field and in the Planned effort field that it will take roughly 5 hours to complete this task. Be sure to relate this task to the appropriate service instance and CIs, and do not forget to adjust its impact level (the impact level is High – Service Degraded : during the change implementation the service will still be available. But the service is no longer redundant so the service is considered as being degraded. If the service would become unavailable during the change implementation the impact should be set to TOP – Service Down).
We recommend to automate these manual steps by using custom fields in the risk & impact tasks and automation rules to update the "Put change into production" task. An example of an automated change workflow template can be found in the GigaTera Managed Services account of your demo environment. As an optional exercise log in to the GigaTera Managed Services account as sandra.store@gigatera.com and create a change based on the change template "Non standard infrastructure change". Next go to the inbox and check how custom fields are used in the risk & impact task.
Once you have finalized the implementation plan, set the status of the fourth task to “Completed”.
Questions:
Which task dictates the impact level of the change workflow?
The impact field of the change workflow is automatically set to the highest impact level of the change workflow’s tasks. In this particular case, it is only the “Put change into production” task that is going to impact the service. Since its impact level should now be “High – Service Degraded for Several Users”, this should also be the impact level of the change workflow.
Which task dictates the completion target of the change workflow?
The completion target of a workflow is automatically set to the completion target of the last task that is related to the workflow. In this workflow the “Update configuration management information” task is the last task. Its completion target is used as the completion target of the change workflow.
The work hours of the assignment team, along with the value in the Planned duration field and the value in the Anticipated assignment field or the Assigned at field, are used to calculate a task's completion target. However, it is possible to use the 24-hour clock to calculate a task's completion target by checking the Work hours are 24x7 box. This allows tasks to be scheduled for implementation during a maintenance window that falls outside the normal work hours of the assignment team. So when the Start no earlier than field of a task is set to, for example, 9am on Sunday and that task's planned duration is 2 hours and the work hours are set on 24x7, then the completion target will be 11am on that same Sunday, regardless of the assignment team's work hours.