Developing a Use Case

Step 2: Develop the Use Case in the TBM Model

With the problem and scope defined, the next step is to build the use case into the TBM Model. This is where raw financial, operational, and consumption data is translated into structured insights using the TBM Taxonomy. The goal is not to perfect the model on day one, but to create a working version that delivers directional answers to the business question.

Start with the Right Data

Use the TBM Taxonomy as your guide for which data to gather. At a minimum, you’ll need:

• Financial data from the general ledger and contracts to populate Cost Pools.
• Operational data such as application inventories or infrastructure assets to align with Towers and Solutions.
• Consumption data if available, to show who is using what services.

Data is rarely complete or pristine. Rather than waiting for “perfect” data, begin with what you have. You can always improve allocations and expand inputs over time. For guidance on handling incomplete or inconsistent data, see the Council’s fallout and data quality practices.

Build Allocations and Drivers

Once data is staged, define how costs and resources flow through the model. Allocations and drivers connect Cost Pools (e.g., software, labor, cloud services) to Towers (infrastructure, applications, workplace, etc.) and then into Solutions consumed by the business. These relationships make the model meaningful to decision-makers by showing not only what money was spent but also why and by whom.

Start simple — for example, allocate software licenses evenly across applications, or distribute infrastructure costs by headcount. Document these assumptions so they can be refined later. The point of this first iteration is to demonstrate the model’s usefulness, not to capture every nuance.

Change Management Considerations

Building the model is a technical exercise, but it is also a relationship exercise:

• Clarify responsibilities with data owners. Make sure finance, IT, and procurement understand what data they are providing and how it will be used.
• Set expectations with stakeholders who will consume the insights. Emphasize that the model reflects a “first draft” view and will evolve with their input.
• Promote transparency by sharing the logic behind allocations and drivers. Even if stakeholders disagree with the chosen method, they are more likely to accept results when the rationale is clear.

These conversations are often where trust in the TBM practice is built. A collaborative approach here makes later steps — presenting and integrating results — much easier.

Keep the End in Mind

Even as you’re deep in spreadsheets, system connectors, and taxonomy mappings, remember that the model is not an end in itself. It is a means of answering the question defined in Step 1. Keep the framing of expected outcomes visible throughout development so you can focus effort where it matters most.

Step 3: Present the Results

Once the use case has been developed in the TBM Model, the next step is to present the results in a way that drives action. A model is only as valuable as the conversations it enables. Your role as the TBM Manager is to translate technical detail into insights that stakeholders can understand, trust, and use to make decisions. Our use cases page offers suggested metrics and KPIs for each use case, while our Metrics & KPIs page provides more inspiration for presenting your results.

Choose the Right Format

Different stakeholders consume information differently. Consider how your audience will act on the insights and choose the format accordingly:

• Dashboards for self-service, ongoing monitoring, or when stakeholders need regular access to updated data.
• Reports for detailed analysis, trend comparisons, or when documenting assumptions is critical.
• Presentations for decision forums where leaders need a concise story that connects data to strategic outcomes.

The TBM Model’s taxonomy-based views can help you structure outputs for different audiences: the Finance View for CFOs and controllers, the Technology View for CIOs and IT leaders, and the Business View for executives and product owners.

Tailor the Message to the Audience

Avoid “one-size-fits-all” reporting. Practitioners may want detailed allocation logic, while executives are more interested in directional insights and options for action. When framing results, focus on decisions and trade-offs rather than just cost details. For example:

• “Application A costs twice as much per user as Application B — should we consolidate?”
• “Forecasts show we are over budget by 15% — should we reprioritize or request more funding?”

By translating outputs into questions that matter to stakeholders, you shift the conversation from reporting to decision-making.

Change Management Considerations

Presenting results is often the most visible moment in the use case lifecycle. To manage change effectively:

• Socialize drafts early. Share preliminary outputs with a small group of stakeholders before a formal presentation. This builds trust and gives you time to refine based on feedback.
• Highlight value, not just cost. Position results in terms of efficiency gained, risk avoided, or capacity unlocked. This reflects the Council’s emphasis on moving beyond costs to value conversations.
• Anticipate pushback. Be ready to explain data quality caveats, allocation choices, or why certain systems were in scope. Transparency builds credibility, even when results are imperfect.

Deliver, Then Discuss

A common misstep is to deliver outputs as if they are the end of the process. In TBM, delivery is the beginning of the conversation. When presenting results, build in time for discussion, interpretation, and next steps. Encourage stakeholders to ask “so what?” and “what now?” — these questions turn static reports into catalysts for change.

Step 4: Integrate into Processes and Documentation

A use case has little lasting impact if it remains a one-time exercise. To maximize its value, the new capability must be embedded into your organization’s recurring processes, governance cycles, and documentation. This is what turns a project into a repeatable practice and ensures the insights remain relevant as strategies, budgets, and technologies evolve.

Embed into Recurring Processes

Think about where the outputs of your use case naturally fit into existing decision cycles. Examples include:

• Budgeting and forecasting: rolling forecasts can now incorporate TBM cost drivers and allocations.
• Portfolio and product reviews: leaders can compare technology spend and value across applications or services.
• Cloud and infrastructure governance: reports can feed directly into optimization and scaling discussions.

By tying the use case to established processes, you prevent it from being seen as “extra work” and instead make it part of how the business operates.

Update Documentation and Methods

Every use case creates new rules, definitions, and practices. Capture these in your documentation so they can be consistently applied and repeated. This includes:

• Allocation rules and drivers used in the TBM Model.
• Definitions of data elements, categories, or thresholds introduced during development.
• Process maps showing how results flow into planning, reporting, or governance forums.

Updating your documentation reduces reliance on tribal knowledge and ensures continuity if roles or responsibilities shift.

Change Management Considerations

Integration is where change becomes real. To help stakeholders adopt the new capability:

• Align with process owners to make sure outputs are included in regular meetings, reviews, and decision forums.
• Clarify roles for maintaining the use case — who updates data, who refreshes dashboards, who validates assumptions. (If your practice lacks defined roles, see the Council’s Roles and Responsibilities guidance).
• Reinforce adoption through training and communications. Make it clear how the use case changes expectations for decision-making and who is accountable for acting on insights.

Position as a Repeatable Capability

Finally, treat the use case not as a finished project but as a capability that can evolve. Over time, refine data quality, expand scope, or integrate additional standards (e.g., ITSM, FinOps, or Agile). This iterative approach creates what the Council calls a virtuous cycle of improvement, where each use case increases trust, adoption, and readiness for the next one.

By embedding the use case into processes and documenting it as part of your TBM practice, you ensure that the effort pays dividends long after the initial presentation. This is how TBM becomes not just a reporting exercise but a driver of ongoing value and informed decision-making.

Putting It All Together

Developing a TBM use case is more than building a report or dashboard. It is a structured process that transforms data into a repeatable capability for better decision-making. The steps are straightforward but powerful:

1. Identify the use case by defining the problem, scoping the work, and aligning on outcomes.
2. Develop it in the TBM Model by gathering data, applying the TBM Taxonomy, and building allocations and drivers.
3. Present the results in formats that match the audience, focusing on decisions and value, not just costs.
4. Integrate the capability into recurring processes and documentation so it becomes part of how the business operates.

At every stage, change management is woven into the process — engaging stakeholders early, setting expectations, and reinforcing new behaviors as insights are embedded into the organization.

Each use case you develop builds trust in the TBM practice, improves data quality, and creates momentum for the next one. Over time, this iterative approach creates a virtuous cycle of adoption and impact, where TBM becomes a trusted part of decision-making across IT, Finance, and the business.

Most importantly, practitioners should approach use case development with the mindset of TBM By Design: embedding TBM into the very fabric of how the organization plans, governs, and operates. When use cases are designed in from the start, TBM shifts from explaining costs after the fact to shaping decisions before they are made — delivering transparency, accountability, and business value at every step.

Next Steps

While you’re here, join the TBM Council to connect with peers and stay updated on all things TBM. Explore our communities to see how others are tackling similar challenges, or check out our Knowledge Base for frameworks, case studies, and how-to guidance. Learn more about the TBM Framework and how it supports smarter decision-making across IT and Finance. You can also attend an upcoming event, pursue training or certification, or see how our partners are contributing to this area of TBM practice.