Software Release and Deployment Management

dart aimed at bull One of the most dangerous changes a corporation can undertake is the release and deployment of software. This is a lesson that airlines and UK banks appear to have failed to learn: difficulties with upgrades and migrations were still generating problems for consumers. A UK bank was recently fined £48.65m for operational resilience failings.
Delegation to a process is an excellent technique for routine upgrades: regognising prior errors plus QMS reviews are the foundations of progress. Documenting these lessons in procedures guarantees that they are learnt rather than just identified.
Delegation to automation is better still: do the QA on the automation once, then simply check that the automation ran without generating an unacceptable error.
Automated processes, auto-QA and auto-documentation are a departmental manager's best friend when it comes to software release and deployment.

This is how it works. I had a graduate Chemical Engineer, a Furniture Design graduate, and a Forestry Management graduate running software release and deployment. I provided them with initial suggestions from my personal experience, as a Standard Operating Procedure. That terrified me because they did things differently. But, I had hired graduates; I was not paying them to be clones. Furthermore, if their alternative was superior to my original, it was approved and the procedure was revised.
What I 'brought to the party' was my initial experience (I had done the job myself for many years) and my tacit knowledge: the protocol's "what to do if it goes wrong" section usually said to refer to the person with my job title. As the years went by, less and less went wrong. When I take holidays, I no longer called the Team Leader every day: twenty years ago I used to.
send email For more information on how we can help you with improving either IT release management or IT deployment management, please write to robert@itsm-support.com.