top of page

How to run a successful Service Costing Project

Too many service costing implementation projects end up with less ROI and more frustration than they should. As companies think about launching these projects, there are some common themes to the nightmares that haunt the project owners: IT Finance Mangers assign a team who works for months on implementing a Service Costing model for their ITFM processes, and at the end, there are complaints, changes and dissension. You spend hundreds of thousands- or even millions- of dollars to put a modern Service Costing solution in place, and at the end of the day, the Business is still not happy, and you cannot answer their questions. Sound familiar? A service costing project is a complex undertaking that integrates data from multiple systems and creates output in a completely new (and sometimes alien to the company culture) format. It is no wonder that this triggers panic attacks in some IT Directors.


Here are the 7 Deadly Sins of Cost Transparency Implementation to avoid:


  1. No documented Use Cases for the system/solution. Why are you doing this anyway? “Because an analyst told my CIO we should” is not the answer you are looking for. At the simplest form, a use case is “WHO want to do WHAT, WHY”. You should have a list of 5–15 of these you are trying to solve before you start. Is your biggest focus internal IT management, customer communication, optimization of assets, or is this part of an overall Service Culture change in your organization? These use cases-or user stories as they are referred to in an Agile environment- will guide your model design, data selection, and report creation.

  2. Expecting your staff to deliver things well outside of their domain knowledge: IT folks overwhelmingly want to be Heroes. The nature of our field means that we are constantly learning and growing- so taking on new things is an exciting prospect. However, there are many ways you can step wrong and end up with services that do not align with business need or provide insight to business value. You will need the following kinds of skills on your team:

  • Costing Expert: If you do not have costing experts on staff, engage one short term to assist in the project- and make sure that you include training and knowledge transfer to your internal staff, unless you want to rely on third party experts forever.

  • Data Geek: You need at least one person on your team who loves to play with data and can manipulate it in their head. if you have a team member for whom pivot tables are as natural as breathing, this is the person you want to leverage.

  • Technical/Scripting skills: While the modern tools are becoming more and more “click and drag”, you will eventually need to do at least some small amount of scripting. If you are building from scratch internally, you will need real programmers who understand how to code for large, complex mixes of data. Even if you pay your vendor to implement the solution, you want someone on your team who can understand and maintain your model(s).

  • Report Designer: The best models in the world are useless without the right actionable dashboards and reports that solve your use cases. This should be someone who also gets training in your tool of choice, so they understand the capabilities and limitations of that tool before they create designs.

  • A Communication Translator: This is not a project that you do in isolation in a small room with 2 people and then release as a surprise. Depending on the breadth and depth of the services you want to model costs for, you will need someone who can talk the language of internal IT as well as the language of Finance and the language of the Business.

  • System Expert(s): If you are buying an off-the-shelf software package, this will likely be someone from the software vendor, but make sure you budget time for the right person on your internal staff to learn this. There are too many failures that happen because after the vendor engagement is over, no one really understands how the system works and how to make changes. 

  • Project Manager: This is not a project you want to put your newbie project managers on, there will be a lot of moving parts, a lot of ego and personality issues to manage and the success of this project can have a large impact on how folks continue to trust your team on financial matters.

  1. Budgeting for the initiative without a high-level plan. These are projects that are notoriously underfunded, leaving the team trying to do too much too fast (so they can hit an operational date) or with not enough knowledge. Be sure you understand the internal impacts (systems and processes, documentation and testing) of the following:

  • How many data integration points will you need?

  • What is the availability and condition of the data?

  • How many reports are needed immediately?

  • Are you leveraging an industry model (like the TBM model) or building your own?

  • How knowledgeable are your people- how much outside assistance will you need (see #2 above). Your project budget should not make your boss cry but remember that the average ROI on a project of this nature is 10% of the IT Budget.

  1. Outsourcing too much of the project: While it is important to know your staff’s limits and supplement appropriately for the course of the project, you should leverage internal knowledge and skills as much as possible. You are building a model of your IT services- the very reason you exist. No one can know that better than you. In the same way, in cases where you are scripting or programming in business logic and rules, leverage organizational systems for these rather than vendor tools when you can. Building business rules in vendor tools is the first step to vendor lock in. This is a field where the software offerings are changing and growing rapidly- don’t rule out the possibility that you might want to shift vendors in 3 years.

  2. Incomplete or no test cases: The eventual result of this will most likely be a change in how you charge the business for services. We have worked with some companies who keep it all for internal management only, but most companies will eventually be doing at least show back to the business. Make sure that what you are testing does not just validate your bottom to top numbers, but also allows you to explain how these are different than your old method.

  3. Building in Isolation: This project will impact the way many people, inside and outside of IT, will think about the things they deliver every day. If the service model is a significant change in your organization, make sure you are socializing this during the project so that people have a correct understanding of how to use the final product. This means that some of your team will need to “talk IT” and be able to understand and translate the lingo of core infrastructure into finance terminology.

  4. No Operational Staff/Training: Too often executives are sold a software solution as an “automation” solution, and they think it is going to be a onetime implementation that then runs as a dark operation. While software solutions can automate data integration and calculations, they cannot handle the decisions about what to do when source data changes, the organization change, or new report requests come in. Be certain that you have staffed for the operationalization of this new process and that those folks got adequate training.


Hopefully, these lessons learned from other organizations’ failures can keep you from getting caught in an implementation sand trap.


Are there other things that you have experienced that made your project a success or failure?

 



Commentaires


bottom of page