journey to #SLSP WAY OF WORK (2/?) - Efficient change management

The process of becoming a reliable factory was ongoing, and we saw a positive trend. The next step was to take a look outside of IT and improve cooperation with business. We proudly said: "Hey guys, we improved; here are facts and metrics. As you can see, we want to improve the whole organisation, and we need you onboard".

We were lucky enough that a group of open-minded managers on the business side understood and wanted the change (from my experience, this is not a rule). And a strong team dedicated to change on the IT side as well.

One of the issues we faced was the struggle to identify who was making decisions about the execution of change. Who has a say in what is to be done? Is it the owner of resources (a.k.a. IT manager), or is it the owner of a budget (a.k.a. business guy)? If they are not in sync, nothing good can happen.

In the past, IT was deciding what would be done simply because we wanted our people to have high utilisation. I'm not saying it was a rule, but it happened that some developers were working on some tasks purely because they were free, and we had nothing better for them to do because their skillset was not the right fit. This was one of the things we made clearly visible, and everybody understood: this is not a pattern we want to follow. (More about the alignment of skillset and planned activities in the next chapter)

Process

Well, we did catch ourselves in some traps.

During the last six years, we created three different generations of the CHM process. They were different in the point of guidance they provided and the enforcement they pushed. We moved through various mental states during definition - from an end-to-end process that covers everything and is so strict that 'no one shall pass!' to a process that covers even more but does not force you to go through every single step and allows you to work in agile and waterfall way of work. What does it mean even more? Well, it means a process that provides information about a single charge and can link all your tasks and activities to higher-level objectives and company goals.

Why we had to create three different generations? Well, we did catch ourselves in some traps - like introducing all the financials into the process, with strict limits on efforts spent based on the allocated budget. Can you imagine a developer unable to work on a task because the budget was missing a couple of hundred Euros? I surely can...

We wanted to ensure everybody impacted by the change was involved, so we were 'spamming' some of the core teams with evaluation impacts of all changes. Teams like Data were going through all the changes and trying to understand the possible impact on them... often without any sense.

Early iterations of the process were not disturbing the customer-vendor relationship. They followed the same principle as usual waterfall processes: business commits requirements, and IT delivers a product. It indeed can work, but one big issue it needs to address is ownership of the change. It was pretty common to see business guys lose interest in the change after the requirements were finished. From their perspective, their work was done. The scale of the change was still quite big, the delivery phase was taking a few months, and it was still common to deliver change according to the requirements while the situation on the market was changed. The business was not involved in the delivery phase, and any fine-tuning of the functionality was done during business tests, typically on an incident basis.

One important topic to mention is an approach to educating organisation about the new process. We are using so-called dry runs - a simulation of the process in small groups. It follows the principle of learning by doing - small groups of people go through the new process on whiteboards with simulated estimations, dependencies and limits on resources. As an advanced gamification factor with some unpredictability (as in a real-life) - you roll dice, and the simulated testing environment can be down for a couple of days. This enables people to 'experience' the new process and be ready to use it to handle the unexpected.

And what is the current process like? It is more of a guidance than a script you have to follow. We have a few must-haves incorporated, just like you need to have the deploy task ready. Otherwise, it will not be deployed anywhere. Out of that, it's up to the team how they use the tool we created. Whether the team uses agile or waterfall, the CHM process can support them.

The next part will be about The limits.

The previous part was about IT as a reliable factory.