Intro
In this blog, I’ll talk about a recent challenge I experienced with IT processes, where the client had decided that they don’t always apply.
In my role, I’m regularly asked to develop process material as a means of introducing common ways of working across complex IT organisations. Now the problem with process documentation is that it is held in pretty low regard by those who work in IT. The word “process” is synonymous with “bureaucracy” and “stopping me getting my work done”. As a result, the fruits of my labours can fall upon stony ground unless they’re supported by a sound approach ensuring they’re adopted, measured and continually reviewed.
But we don’t need processes nowadays, do we?
In a world where we’re now embedding agile and DevOps into the DNA of many organisations, as well as employing millennials who are themselves challenging these ideologies with even more radical approaches, it can be argued that we don’t need processes and standardisation at all.
I’d argue that under these circumstances, we need process more than ever and here’s why:
- The act of designing the process, as a collegiate activity, is the most powerful tool in terms of ensuring buy-in, sharing best practices and gaining commitment
- The process design phase can also consider important requirements such as corporate compliance, regulatory requirements and the ability to measure the process outcome / output
- As teams become more disparate, with each aligned to different sets of service-aligned objectives, having some common ways of working is critical in maintaining quality control and governance
My client’s challenge
So, back to my client. A 500+ person IT department, with a hybrid model of traditional technology siloes and new service-aligned teams who followed DevOps principles for certain services.
Their challenge was that rather than adapting existing processes to cater for the needs of the new DevOps teams, they had buckled under the pressure from these teams, who declared the processes to be too rigorous, misaligned with their ways of working and constraining their creativity and productivity.
And guess what? They were right.
When there was a major outage, there was no audit trail or evidence of any due diligence being performed through the development of the service and no proof that releases were routinely tested and assured prior to implementation.
But the answer here wasn’t to create an exception where the team operated unilaterally, with a complete lack of commonality and standardisation. This resulted in numerous teams essentially running small development firms under the company’s brand, but with no governance, control or measurement. Regardless of what they said, even DevOps teams need these factors in their processes.
It’s not impossible to develop processes that allow flexibility, creativity and alignment with DevOps ideals, whilst ensuring appropriate compliance, standardisation and control is maintained. It’s difficult, but not impossible.
So, what did we do?
Existing processes were reviewed and refined collaboratively, involving the relevant stakeholders, including process owners, practitioners, corporate compliance teams and audit teams.
We also banned teams from requesting process exceptions. If the process is inappropriate, we don’t bypass it, we refine it until it works.
As you gathered by now, I’m an advocate of process standardisation. You can read more about this obsession in our blog on RACI charts
Useful Links
To find out how we help organisations like yours, read our ultimate guide to ITSM.
