Process of the Month – Software Change Management Process

Best practice

Process of the Month – Software Change Management Process

Firstly, sincerest thanks to all of those who re-tweeted re-posted or even “liked” this feature on LinkedIn – the viewing stats were beyond anything I could have hoped for.

As Piaras MacDonnell (Pronounced Pierce to those of a non-Celtic tongue) of SureDatum made an early request for a change management process, this has been chosen as the topic for this month’s process. Please note, while the general principles around due diligence and communications have been built into this process, for the sake of scope I have left hardware changes out of this workflow.

Both Piaras and I will be at the Gartner ITAM event in London on 11-12th Sept; so feel free to come and say hello.

Software Change Management Process

Primary Objective:

1. To ensure that software change management follows a recognised procedure.

Secondary Objectives:

1. That due diligence is carried out to assess the business impact of any software change PRIOR to a decision being taken on whether the roll-out takes place.
2. That the scope is verified for completion and accuracy both before and after the deployment/change takes place.

Assumptions:

1. Single Install/end user changes (as might typically be handled by self-service portals/helpdesk) have NOT been included in this process
2. Hardware changes that could influence a licence position have NOT been included in thisprocess
3. This process is supported by a policy that states software change management shall not take place without appropriate management approval being given prior to any changes.

Function Step Overview

1.10	The SAM Manager conducts validation checks against the software change request, ensuring that the proposed change will not expose the company to licence risk.  He also checks to ensure that any testing requirements have been carried out prior to proceeding with the change management process.  For titles that fail the test or licensing check, then the request can be routed to the Software Test Process or the Software Request Process accordingly.
1.20	The following individuals (as a minimum) are recommended to consider a software/change management request:  The Apps Packaging Team, The SAM Manager, The Requestee(s) and perhaps even any Stakeholders/End Users.  It might even be that your company has a Change Advisory Board (CAB) to consider such changes.  This assessment is to offer any or all interested parties the opportunity to speak up if the proposed change might have knock-on consequences, around resource, training requirements, technical capability of the staff to conduct the change, or any other IT impact the change might have.
1.30	The Apps Packaging Team (subject to the approval of the team at step 1.20) is required to inform the Helpdesk team of who should be seeing the change, what devices should be changed, when the change will take place, and that a roll back plan exists if anything untoward should occur.
1.40	The Apps Packaging Team (subject to the refusal of the change request at step 1.20) is required to inform the requestee(s) the change request has been declined and why.
1.50	Having confirmed the change schedule and device scope at step 1.20, The Apps Packaging Team are then required deploy the change as per the schedule/scope agreed.
1.60	Subject to completion of step 1.50, the Apps Packaging Team will then conduct quality assurance tests to ensure that the software deployment/change has been deployed to the correct number of machines and individuals, but also to the exact devices and relevant users.  Any users/devices missed, or over-deployed to, form the basis of the delta report.
1.70	Subject to the QA checks at 1.60, it has been deemed that the deployment/change was a success and that only those individuals/devices originally in scope received the change.At this point, the process closes, handing off to any End User Acceptance Trials that might be required.
1.80	Root cause analysis takes place at step 1.80 to help determine why the change/deployment did not meet the scope demanded of the change request.  A forum of the requestee(s) Helpdesk Head, and the Apps Packaging Team need to take a considered decision as to whether the roll back plan is initiated, or whether the existing deployment/change can be repaired.
1.90	Having gone through step 1.80, the forum believes the deployment/change is not worth pursuing, and so informs the Apps Packaging Team to instigate the roll back plan.
2.00	Having instigated the roll-back plan, the Apps Packaging Team undertakes further checks to ensure that the roll back was successful, by comparing removals to former deployments/changes.  Should any remaining changes/deployments still be in place, then the Apps Packaging Team returns to step 1.90 to try once more.
2.10	Having reviewed the roll back plan’s implementation at 2.00, the Apps Packaging Team and are happy that the plan was a success and the changes/deployments have been totally removed.  This requires communicating to the Requestee(s), the Stakeholders, and the Helpdesk Team by the Apps Packaging Team
2.20	Going back to Step 1.80, the former decision was taken to repair the change/deployment, and so the Apps Packaging Team are required to create a repair plan here and execute it.
2.30	Having executed the repair plan at 2.20, the Apps Packaging Team and the SAM Manager review the success/failure of this plan.  If the repair plan has failed for any reason, then the Apps Packaging Team are required to return to 2.20 to reach the last of those devices/users that the previous attempt failed to reach.
2.40	The Repair plan has been deemed a success; the Apps Packaging Team is now in a position to pass on the good news to the Helpdesk team, the requestee(s) and any stakeholders that might be involved.  The Software Change Management Process can now hand off to the End User Acceptance Trials Process.

Clearly we have some exception/error handling loops in this template; you might wish to consider a break-out loop on pages E and F; how many times is the Apps Packaging Team expected to go round in a loop to either remove or repair software?

Also, on Page A any Software Changes were rejected out of sight based on the fact that a licence/contract didn’t exist for that change.  Clearly, there are certain exceptions to this, or perhaps you might like to build your own flag into the process to start chasing the requestee(s) for purchase evidence/a licence x number of days after a software change/install.

The process kit by Rory Canavan is available from SAMcharter.com

Can’t find what you’re looking for?