What could be the ideal structure for those? - A summary of the different lenses and layers.
Dieser Inhalt ist derzeit nur auf Englisch verfügbar.
In a nutshell
This time, we will touch on a topic related to Service Management, a coherent part of Strategic or Project Portfolio Management. If you check my profile while reading this article, I’m working hand-in-hand with ServiceNow (#ServiceNow), which was initially famous for its IT Service Management Product. Being immersed day to day in ServiceNow, understanding the depths of its mission and initiatives, the billion-dollar question might arise: How does an IT Service Management IT product vendor come to the business of Strategic and Project Portfolio Management? What can cause it to venture away from its core domain, and what magical ingredients can make it happen successfully?
Backflash
In my previous post,
I mentioned that it goes back to my trainee years when our CIO declared IT needs to serve the business, and we need to work on the service models and SLAs. It is fortunate that I still consider my sentences right. There are better scenarios for IT to serve. However, creating the processes and culture to catalog what we can provide made a future-proof operation. So, the direction was somehow right but not the cause.
Soon enough, we worked on a project to develop a better cost-allocation model to understand the direct service costs better and determine the real effort spent on products triggered by the PMO (project management office). We discovered that only 15% of cost items could be identified as direct product costs; the remaining items were categorized under various sources and allocated flatly on each product. Obviously, a product needs to be profitable to keep it, and to determine this; we need to understand both the revenue and the cost side. I could not comprehend how a product's fate could be decided exclusively by its revenue contribution, so I asked a trusted colleague, a service owner, to shed some light on it. He posed a rhetorical question, "What would you do if you put three gold coins into the piggy bank and nine fell out at the end of the year?" The unspoken answer was that you wouldn't want to mess with it. With this, I understood that the product owners and the management were fully aware of the lack of information about the actual profitability of the products, but they chose to ignore it. I had to realize that in most cases, it is easier not to know than to have full transparency, as transparency would mean creating and maintaining a complex and expensive model, mainly by manual procedures.
I got obsessed with the topic and chose it for my university thesis, starting to work out a model and its implementation possibilities. These experiences gave me the basic mentality for my future career as a consultant, religiously believing in transparency and models and tools that can change how it is.
The miracles model
Back in the day, it was an on-premise world where each company owned its physical servers and operated hundreds of separate IT systems to cater to the IT needs of a particular business product. Because the systems were usually separated, no one could tell the entire product's overall resource need (including costs). When service management gained importance, the first step was to create a connection between IT assets and applications. The link was created by Configuration Items (CI) representing an individual software or hardware component, and by combining them, we could virtually create many standalone applications, too. Combining applications makes an IT service that can complement a business service, thus becoming a product's fundamental.
Adding the concept of cost allocation to this was an innovative way of creating the desired transparency. We started to track which CI was involved in each transaction. Therefore, we could track which product was affected at the end of the line by that specific cost item. Every CI was assigned a cost structure so we could calculate transactional and overall product costs. We could see the operational expenses (OpEx), but we also needed to factor in the capital distribution related to each project (CapEx).
Those are the project costs you typically spend on product or service development. The billion-dollar question again. How can we connect the project with IT assets, IT and business services, and products? We defined all the deliverables at the beginning of the project scoping or backlog grooming. We connected those to existing CIs or newly created CIs that needed to be built to complete the investments directly to the project in a structured hierarchical way. In this way, we got a delivery structure where we could allocate human resources to have a detailed list of deliverables. With time sheeting, we could give all the CapEx costs to the product. If another service uses a CI, we could change the allocation figures by the actual number of transactions. The circuit was closed.
Considering the complexity, it is easy to understand that recording all this manually, not to mention human errors, is nearly impossible. At the time, our focus was more on the project cost allocation, as we had to recategorize most of the resource CapEx costs into OpEx costs, proving that a particular resource belonged to a specific product. Based on this resource investment, we created a Project Portfolio Management solution. We planned to integrate the Service Management solution to have the service and asset-oriented OpEx costs from that system. We also planned operational projects to collect those efforts and the resources spent on the services or assets. Finally, we calculated the overall investment to have an integrated solution, and when the management checked the cost side, we decided to postpone the work.
Current state
In the past 10 to 15 years, companies have been trying to focus more on the customers. Therefore, the whole “project” world has changed, and nowadays, we focus more on products and value streams. The delivery model also had to shift to the product focus, so we adapted to the agile methods. The cost allocation structure needs to stand to figure out the overall picture, but we need to build the same hierarchy under the products without the projects. The other change is about IT structures. Cloud computing and microservices bring us an easier-to-understand design. This can be a more accessible model but more complex. We will discuss this in another post; most companies have a hybrid model and a hybrid infrastructure, so they cannot stand only on the agile-driven product delivery but must also take care of the original waterfall projects. The same applies to the infrastructure; we have the initial on-premise infrastructure combined with an on-demand world. So, we need to handle much more complexity.
The takeaway
With or without the above example, it is becoming more apparent that creating and maintaining a transparent cost allocation model requires a lot of resources and manual work. The more complex a company's IT service management, the more resources it needs to maintain its administration. In the short run, it is easier to avoid doing it and continue the cost allocation the old-school way, seeing just a fragment of costs. In the long run, the lack of transparency causes indescribable damage on multiple levels to the company. And this starts with the mentality and the willingness to understand how there are more sides to the same story.
I'd like you to stay tuned for the following posts to learn how the right tools can support this mentality.
Next blog post in the series:
4. How do you manage everything in one portfolio to get transparency in planning and monitoring? - How to put all those things into one bucket to understand the overall picture.
5. How to get the strategic overview? How do we connect all the relevant items to our strategy to create an overview? - If we have everything, how can we connect the dots?
6. What and how must we implement to achieve our goals? - Tooling landscape
7. Summary and Key Takeaways