What if my environment is an edge case? It probably is.
Beginning with the Reality Most Organizations Live In
When practitioners begin working through the first layer of a cost model that focuses on cost pools, it’s very common to wonder whether their environment is too unusual or too complicated or too inconsistent to fit neatly into the approach described in Foundations of Cost Modeling – How to Build the First Layer. I hear this often, and I think it’s worth saying plainly that most environments are edge cases in one way or another. It may take a little more effort to model to cost pools, but it isn’t a complete nonstarter.
Segment 1 of the Foundations of Cost Modeling series is written with this in mind. It’s principle-based rather than template-based because the goal isn’t to force a specific structure onto an environment that has its own history and its own logic. The goal is to help people understand how to take what already exists in their Chart of Accounts and organize it into cost pools in a way that reflects what the organization purchases. That’s why the guidance focuses on reading the hierarchy, understanding account intent, and building a reference dataset that fits the organization rather than asking the organization to fit a predefined model.
Working With Imperfections Instead of Working Around Them
Many environments have legacy accounts that no longer match current usage, accounts that have been repurposed several times, shared usage accounts, and some even don’t utilize a full chart of accounts for technology costs, or don’t allow access to the entire book of costs or certain transaction types. None of these things prevent a cost model from taking shape. They simply mean that the work of classification requires a little more conversation, a little more validation, and a little more patience as the structure becomes clearer.
The important thing is that the cost pools reflect the nature of spend rather than the imperfections of the accounting structure. If an account description is outdated, you can look at the parent category. If an account is shared use, you can assign a weighted split to cost pools or use a conditional assignment that leverages the account and a vendor name or an account and a cost center combination. There’s even a solution for the extreme edge case of having a single account in use for all technology spend. The model doesn’t need the environment to be perfect. It only needs enough clarity to represent what the organization purchased and how those purchases support the work being done.
And while imperfections can be challenging, they aren’t complete blockers and they shouldn’t be hidden or solved with complicated workarounds or used as an opportunity to name and shame our peers and partners. Instead, they should be allowed to show up in the cost model in their operational state so they’re visible, and that visibility can be the basis of conversation about whether it’s representative of something to solve and how it may be solved to support the outcomes the organization expects. When imperfections are allowed to be seen rather than masked, they become part of the shared understanding that helps Finance and Technology work together more effectively.
