My organization is struggling to define when to associate a project (time and effort costs primarily) to an application. For example: A project to extract data from Application ABC and Application XYZ to produce a BI report is only using ABC, XYZ, and the BI reporting tool. Which, if any, of these applications (ABC, XYZ, and/or the BI tool) should be associated with the project to assign the associated labor costs as part of the App TCO?

I'm hoping that others out there may have faced a similar dilemma and have defined guidelines to share. Thanks!

Hi Paul,

I would maybe look at this slightly differently. In the use case that you have given, you have listed the applications that will be used by the project, but not necessarily benefiting from the project. So it may not be correct to allocate costs to any of those applications as the Labor costs are not being consumed by those applications. In that that effort is not being consumed by the app in terms of its support or enhancement.

It might therefore be worth asking the question, what applications or business units are consuming these project Labor costs. I would therefore be tempted to allocate the project Labor costs directly to the consuming business unit.

Hope this adds something to the mix

Michael

Thank you Michael! That's good insight.

I hadn't considered allocating right past applications and directly to services or business units, mainly because our PPM system is set-up to capture associations to applications and not the service or BU. Follow-up question to consider: how does your organization define an application? We're currently debating whether to treat our Enterprise Data Warehouse as an app. While it is a significant consumer of cost, especially development costs, it does not have the traditional features of an application and in fact supports dozens of applications that access its data.  

Hoping that there may be some best practices or battle-tested guidelines we could leverage in defining our application portfolio and associated projects. Anyone else have insight to share?

Ha, we're getting into that debate as well - what's an app, what's a tool, etc.  We're still meeting/discussing.  Trying to see if we cost them differently or not.  I personally think as long as they're sitting on/consuming infrastructure and being supported by our resources, they should, but then the question becomes 'how much' and how do you decide that, etc.  Might be worth its own discussion thread to see how others handled..  

We've traditionally charged back something like an Enterprise Data Warehouse or in house custom-built technology tools to the consuming applications.  However, it was important to distinguish what was a direct cost from these types of allocated costs and clearly lay that out in our reports.  We had an issue with architects and management looking at the app cost and assuming that the entire application cost would go away with a given system decommission.  They were inputting erroneous values in their business cases since they didn't understand the context of the number.

This is exactly what we're trying to prepare for as we socialize App TCO reporting. Hoping to clearly distinguish direct application cost vs. indirect. I suppose that's a topic for another thread though.

Totally agree, Paul!  We did have a separate project set up as a 'what-if' type model to cut things by a certain percentage given particular scenarios, but it was a bear to maintain - mainly because of so many different scenarios per app.  Finance just started using an Excel model for that one.  What one VP brought up once was it's not conducive to 'speed to market' if any time you're wanting to retire an app or group of apps that they have to work with Finance one on one to interrogate each individual app and the surrounding circumstances.  True, but we have yet to wrap our heads around a better way.  If all of our apps were uniform and were on the same platforms and infrastructure - if we had that cookie cutter setup - yeah, it would be a lot faster, but we don't.  We're constantly changing things, or one area doesn't like the standard, so they go off and do something on their own, or we acquire a company and have to integrate them quickly, so standardizing comes later, etc.  Again, too many different scenarios.  In a perfect world, it would be a lot quicker to assess 'savings' when retiring/replacing something, but I digress.

YES - what you said, Nancy!  We had the exact same thing happen - they'd come to us and "assume" that retiring an app that showed a cost of say $1m would result in that much savings.  We quickly got in lockstep with our Finance partners on this.  Anytime someone wanted to get the cost of an application, we would always copy the Finance area supporting that VP as a 'heads up'.  We continually had to drive home the fact that TBM represented the FULL cost to the enterprise.  Even if they retired an app, most likely the resources or the infrastructure would be reassigned/repurposed.  So what Finance would do would drill into the costs down to the cost pool level to determine 'hard' and 'soft' savings.  Hard savings being those that reduced the bottom line (reduction in contractors, contracts, or maintenance costs) and soft savings were those items that would move, but not go away.  It takes a village to get the message across for sure.

Good thread here @Josh Koziel

@Kristi Deuser - sort of related to your earlier question - additional insights at least