Once you have a reasonably mature TBM practice in place, you can be sure that some of the more sophisticated players will try to game the process. Why? Well less allocation means more IT work for the same dollars. If you are running an org where technology is vitally important but dollars are tight; frankly, you would play the game too. As a business manager, you should understand the game. This way you can act in one of two capacities; enforcement or facilitator.
Direct cost games are the easiest but the most dangerous. There are so many inputs to your P&L or your PPM system, that you’re unlikely to get caught. That said, if you do get caught playing any serious game that impacts the P&L, you’ll probably be fired. There are macro and micro ways that people use to achieve a certain outcome. If the overall budget or actuals are running hot and you need to bring it down as you allocate one to one to a client, capitalization is the easiest lever to pull. Change dollars are eligible to be moved to the balance sheet. This will decrease the P&L in the near term and lower an allocation. This is why budgets should be judged on a cash basis. But for actuals, you can achieve a desired result quickly. You have to direct your staff to book to capitalization eligble project and Finance will do the rest. If you are in charge of a group of business managers and you want to cut down (or monitor) this practice; a few Tableau reports that compare budgeted function (change/support) to timesheet booking, can quickly isolate this problem.
Allocated cost games come in many flavors. The good news about these games is that it means you have achieved your goal of having an organization that cares about TBM. You have a group of people that understand the cost base and the drivers; now let the games begin. While there are many ways to shift cost, I’ll focus on two of the more common examples.
In a world where clients are charged for consumption of applications, more savvy clients will try to attack their infrastructure charges. Some will try to drive charges out of the org. This is the desired behavior. But some will just try to make sure the charges hit other apps. Most organizations have a CMDB that maps their hardware costs to their applications. A snapshot is taken at regular intervals to create the application TCO. But what if hardware was “turned off” right before this snapshot and “turned on” right after. You’d have no charges but would still use the equipment most of the time. Clearly this doesn’t work for production environments, but dev/stage? The charges for this “orphaned” kit would go into the tax bucket and be spread to all HW objects. To make this work you’d have to understand the windows and be ready for a lot of admin, but it’s a game people play. How do you cut down on this? As usual, sunlight is the best disinfectant. Rather than a monthly orphaned server report, you could make this daily around the snapshot period. Sounds like a lot of work initially but once you bust a few people, this game tends to go away.
The other example has to do with allocation drivers. Many applications have fairly immature charging methodologies. If an app is charged out by user count, you can also see businesses “turn off” users at the end of the month (and turn them back on the first day of the new cycle). You’d be surprised how often this happens. This is fairly easy to combat. Ideally you switch the methodology to something more appropriate (think compute consumption). But in lieu of that, you can simply use “peak user count” during the period. This encourages the business to shut down unneeded users right away and renders gaming obsolete.
You will come across many more games throughout your career. Having a prevalence of games means that you are getting close to driving the right behaviors.