Traditionally, the IT stack was divided into two buckets; change and run. For the first ten years of my career, any further delineation was unheard of. Like all standards, things change. The organization needs more granularity. I know what you’re thinking, “we have tons of detail!” But we all know that management doesn’t need every little detail, they need granularity-lite. That’s where other high level headings start to creep in.
Looking at Change first, there are other breakdowns that are meaningful.
The first category is mandatory. Some companies consider this “Run”, but at the end of the day the systems are changing. Having a meaningful mandatory category is important to telling the story. That means you can’t cheapen it by tagging items to this bucket that are really just things you want to do. Having credibility with mandatory puts you in a position to help invest in the more interesting work down the road.
Small enhancements are the next group to tackle. All companies have their own definition of this type of change. That said, I would caution against using a purely time based metric. As deliveries get smaller due to agility, time will mean less and less. The reality is that describing small enhancements is akin to the Supreme Court’s definition of pornography. Basically, “I can’t describe it but I know it when I see it.” As much as clients disdain this category, it will never be eliminated. It’s your job to keep it small so more dollars can flow to higher value projects.
To keep it simple, the last change bucket is “Strategic” or “Transform” in many companies. There has been a trend over the last five years to break this out of your change bucket and show it separately. Ideally, this will quickly identify IT dollars that help drive revenue or other important opportunities to your companies. I don’t necessarily think you have to break it out if you’re telling the story appropriately. But that will depend on the attention span of your client. To keep the message clear, it may be worth the effort.
In terms of the “Run” or “Operate” area, it’s commonly broken down further as well.
Your support levels can help you get started. Level 1/2 support is commonly separated. This helps isolate the costs associated with problem solving your applications. This is frequently the area targeted with DevOps savings. Having a meaningful baseline before embarking on that journey will be massively important to the successful measurement.
Level 3 support generally makes up the bulk of your traditional Run costs. These longer duration fixes can trap a lot of cost in the org. Good time booking is essential to isolating these costs. Without close monitoring (at least initially), this bucket can attract a lot of small enhancements dollars. As this group gains a lot of scrutiny, you will need to be vigilant.
The final category is “Non-impactable” cost. I realize that’s not a real word but it illustrates the frustration of this category. All of you likely have a legacy data center that fits into this bucket. Maybe it’s occupancy? If you are going to make the case to place it here, it better be out of your hands or have a long enough duration that management understands the problem. Don’t cheat here. The weak way out is to place anything associated with the prior management regime here. You aren’t being paid for that. Make an honest mark to market.
You don’t need to follow all of these. Most organizations only use one or two of these further breakdowns. But realize these are all arrows in your storytelling quiver. Just be prepared to put in the work to capture them accurately.