We are all very aware of the fact that the world is spinning faster these days. The change rate is substantially higher and the dynamics of your IT service provider task have become a bit more complex. Traditionally we have been all about keeping things stable, maintaining the status quo and stay predictable. However, our world is changing drastically, of course, we still have to do all this, but we also have to be really quick sometimes, making sure that the business can reach their objectives in this ever-changing world.
There is no way the business can wait for our development cycle to make needed functionality available for the next release.
It gets worse. We have to create process flows that are significantly faster, but at the same time we have to maintain the “old” ones, this is usually called Bi-Modal IT, we have to adapt our processes based on two distinctively different worlds, the conservative (which we like) and the very quick on (which makes us nervous). It is not far-fetched to say that this is a huge challenge. We have been fighting for years to make our processes flow great, improving them in baby steps, trimming them based on our KPIs and a lot more. We are quite good. However, in this new light we are again facing a great challenge.
Dear readers, no need to worry, we just have to make a few adjustments to become Bi-modal.
There are a lot of buzz about the need to become agile, to abandon your “old” IT Service management processes for fresh new stuff like DevOps. I can assure you that no such thing is needed; in fact, this will only complicate things even more for you. I have a very basic idea about how to adapt current ways of working that applies to all situations. Maintain what you are doing well, improve what you are doing bad and adapt what you never ever did but should do. So throwing out the two first of these in favor of nr 3 is not clever.
Now, there are a few key areas you need to take care of to become Bi-Modal.
- You need to stay very close to the business, preferably with help of BRMs (Business Relationship Managers) on a strategic level, SLM (Service Level Management) on a tactical level and your Service Desk on the operational level. You need to know what is happening, always be open to new requirements and keep a really tight management of how these requirements are logged and send into the IT service provider organization. There are many clever ways to manage this but the most important thing to remember, you cannot count on being told what the business wants, many times you actually have to ask them proactively, this is more of a push than a pull approach.
- You absolutely have to decide where a business requirement is authorized to enter the change management process and in this case qualified for the fast track. Is this part of the actual change management process or managed some other place? We cannot wait weeks just to get an approval to manage a single requirement, this has to be fast but still we need an approval to not get a very crowded change management process. In 95% of the cases I have managed this first business approval to qualify a requirement to continue in the Change process was managed directly after the first change filter, done by a specific virtual CAB composed of senior people from IT and the business, normally the same day or in worst case, the next business day. After passing this point this requirement becomes a CR (Change request) with a specific change type.
- Now, when we enter our control and deployment processes we have to make sure we manage these in a clever way. What I have done so far to help organizations manage this is introducing a new instance type in those processes. Please note, as mentioned earlier, that there has to be clear and understood criteria for what business requirements that qualifies for our fast track. Normally I recommend using a business defined set of criteria.
- In change management, we normally use standard/normal/emergency change, and I hope you are also using change models for our services. Now, for the fast track we simply introduced a quick change, a change model specialized to be fast, not sloppy. In most cases we even pre-defined change slots in CABs to be prepared if there were any quick changes, in later stages we made a quick-CAB that only managed the quick changes. It became a parallel change track, only controlled the same way but highly optimized and prioritized by the business. At first, this caused some delays in the normal change flow but after a short period, it simply was like two projects, running at the same time but controlled by the PMO, the change manager.
- The same goes for release management, you need to create a fast track and prepare the process with pre-defined time slots, specific procedures to optimize all process passages. One item that is particularly important is the actual operational hand-over. In most cases we actually defined a weekly slot for training and hand-over of quick changes to Service Desk super users (or similar).
All these items are basically about the same thing, calibration of our efforts and being prepared. This is why I always smile when I read about new ways of becoming faster, new frameworks and such. Why in earth would we change everything when what we really need is to calibrate what we already have? This is the key of being fast, be responsive and adapt your efforts to what is most important. However to manage both worlds we need to maintain the current one and create a fast track, including doing the necessary preparations to allow our process to be a lot faster when such is needed. This can be done but you need to design this specific model to be as lean as possible, thus allowing us to be a faster when needed.
A last word, do not let this become the new model for all requirements; this will only take you back to where you started. The business needs to decide what qualifies to enter our new fast track, after all this is what the Bi-Model IT is about, differentiating our delivery.