The Change Manager’s Guide for TBM Use Case Development

Implementing a Technology Business Management (TBM) use case requires much more than technical configuration. While TBM Administrators focus on building data pipelines and allocation engines, long-term success ultimately depends on structured organizational change and continuous engagement. A flawlessly architected TBM dashboard will fail to deliver value if executives ignore the metrics, data owners hesitate to share telemetry, and insights fail to integrate into corporate planning rhythms.

Designed specifically for TBM Change Managers and Practice Leads, this playbook provides a structured approach to managing the human and organizational elements of TBM use case development. In smaller organizations, these responsibilities may be distributed across a limited number of individuals performing multiple TBM functions simultaneously. Because change is a continuous discipline rather than a discrete project phase, these strategies run in parallel with the technical build. This creates a dual-track transformation that guides the organization from the pre-development validation of strategic value all the way through to the post-launch governance of data quality.

Applying This Playbook Across Organizations

Organizations adopt TBM with vastly different levels of maturity, staffing, governance, and data readiness. While this playbook presents a comprehensive model for supporting TBM use case development, organizations should not interpret every recommendation as a prerequisite for getting started. Many successful TBM initiatives begin with limited resources, incomplete data, lightweight governance, and a single motivated stakeholder or use case.

In smaller or resource-constrained organizations, responsibilities described throughout this guide may be consolidated across a small number of individuals. The Change Manager role, for example, may be performed by a TBM Practice Lead, TBM Administrator, Executive Sponsor, Finance leader, or another operational stakeholder supporting adoption efforts alongside their primary responsibilities. Similarly, informal working agreements and recurring collaboration sessions may initially replace more mature governance structures such as formalized data contracts or enterprise governance boards.

The objective of TBM adoption is not to delay progress until every dependency is solved, but to begin delivering directional insights that build trust, establish momentum, and create a foundation for continuous improvement over time. Throughout this playbook, organizations will find both mature-state recommendations and pragmatic starting approaches intended to help teams adopt these practices incrementally based on their current maturity, operational realities, and available resources.

Overarching Change Frameworks

The TBM Council recommends using proven organizational change methodologies as the scaffolding for your TBM practice. The steps in this playbook align naturally with industry-standard approaches, including:

• Kotter’s 8-Step Process: A highly effective model for building organizational urgency, securing executive sponsorship, and ensuring the TBM vision connects to broader business goals.
• Prosci’s ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement): A framework used for shaping individual adoption, helping specific users transition smoothly to new TBM practices.

You do not need prior knowledge of these specific methodologies to execute this playbook. The phases outlined below are designed to be practical, standalone steps that inherently apply the best practices of these frameworks. By following this guide, you will be equipped to shift your organization’s emphasis beyond the initial rollout to sustaining impact through ongoing communication, regular model health reviews, continuous training, and active leadership governance. Ultimately, operationalizing this approach ensures that TBM capabilities are culturally adopted, embedded, trusted, and capable of evolving with enterprise needs.

The following five phases outline a scalable framework for orchestrating this transformation alongside your technical teams, whether your organization is beginning with a single foundational use case or expanding a mature TBM practice.

Phase 1: Validating the Strategic Value (Pre-Development)

The Objective

Before the TBM Administrator writes a single allocation rule or configures a data pipeline, the Change Manager helps to ensure the proposed use case is a targeted solution to a recognized business problem. Drawing on Kotter’s principles of change, your goal in this phase is to establish organizational urgency, build a guiding coalition, and prepare the engagement strategy. On an individual level, you are initiating the “Awareness” and “Desire” stages of the ADKAR model for both primary and secondary stakeholders.

Step 1: Identify the Primary Persona, Map Resistance, and Establish Urgency

A use case built for “everyone” will ultimately be adopted by no one. Your first action is to identify the specific executive or operational leader who will consume the resulting decision views, while proactively identifying potential roadblocks.

• Action: Conduct stakeholder interviews with the target persona (e.g., the CIO, CFO, or a Product Owner) using a “listen-first” approach to map their current blind spots, and use these conversations to identify areas of cultural resistance or data silos early.
• Outcome: A documented narrative exposing the cost of the status quo, and a stakeholder map identifying potential champions and opponents.
• Application (What you do with this): You will use the narrative as your primary tool to drive engagement. When you need to ask a reluctant data owner to clean their data in Phase 2, you will use this to explain exactly how their cooperation solves a critical enterprise problem. You will use the stakeholder map to strategically “pair opponents with allies,” building a champion network that advocates for the change before the technical build even begins.
• Tool to Leverage: Reference the whitepaper Initiating Virtuous Cycles with TBM for its practical playbook on conducting listen-first stakeholder interviews and building champion networks. Additionally, use the TBM First Steps Guide: Building Strategic Alignment Between IT and Finance to prepare for early alignment meetings and avoid common startup pitfalls.

Step 2: Form a Guiding Coalition via Strategic Value Workshops

The Change Manager serves as the bridge between the business leader’s operational problem and the TBM Analyst’s technical design.

• Action: Host a scoping workshop bringing together the Executive Sponsor, the TBM Analyst, and the target persona. This trio acts as your guiding coalition for the use case. Use this session to define the “Strategic Value” statement.
• Outcome: An agreed-upon scope that aligns the requested TBM capability to one of the enterprise’s Organizational Value Drivers (e.g., Financial Performance, Innovation, Operational Efficiency).
• Application (What you do with this): You will use this statement to govern the technical build. You will hand this directly to the TBM Administrator to act as their boundary. If an allocation rule or dashboard feature does not directly support this specific value statement, you will use this document to flag it as scope creep.
• Tool to Leverage: Use the site page Learn TBM > TBM Modeling > Developing a Use Case for a repeatable process to scope and prioritize the use case based on business need and stakeholder alignment. Also, lift the RACI matrix directly from the eBook Mastering Technology Business Management Adoption: Roles & Responsibilities to clearly define who owns business requirements versus technical design.

Step 3: Articulate “What Changes For Me” for Secondary Stakeholders

A successful TBM use case requires behavioral changes from downstream stakeholders who may not directly use the final dashboard, but who supply the necessary data or operational context.

• Action: Explicitly define “what changes for me” for every secondary role impacted by the use case (e.g., engineers who must adopt new cloud tagging standards, or HR managers who must adjust labor categories).
• Outcome: A targeted value proposition that aligns the benefits of the use case to each specific stakeholder group’s needs.
• Application (What you do with this): You will use this artifact to secure cross-functional cooperation. By answering “WIIFM” (What’s In It For Me) tailored to their roles, you build the willingness needed to secure data access in Phase 2 and enforce new operational routines in Phase 3.
• Tool to Leverage: Read Top Five Best Practices for Successful TBM Adoption: Recommendations from the TBM Council Adoption & Maturity Strategy Community. Apply its guidance on explicitly aligning TBM benefits to different stakeholder groups to build trust and momentum early.

Step 4: Define the Behavioral Shift and Tie to Corporate Scorecards (Building Desire)

Because TBM is fundamentally a change management discipline, you should define the operational shift the use case is expected to trigger once it goes live and ensure it carries executive weight.

• Action: Document the expected “From/To” state for the target audience (e.g., From funding projects based on historical baseline budgets, To funding Agile product value streams based on TCO) and formally tie these expected outcomes directly to the organization’s existing OKRs and performance scorecards.
• Outcome: A defined, scorecard-aligned adoption metric (e.g., dashboard usage in monthly operational reviews, or the percentage of funding decisions referencing TBM scenarios).
• Application (What you do with this): This becomes your primary KPI for success. The Executive Sponsor will use this OKR connection to establish clear expectations that the new TBM decision views are the expected basis for future funding and performance reviews. In Phase 4, you will track this exact metric to prove the use case successfully changed how the organization operates.
• Tool to Leverage: Read the article Executive Sponsorship-The Critical Catalyst for TBM and Enterprise Transformation. It will help you position the use case as a strategic driver of enterprise transformation and ensure the adoption metrics carry executive weight.

Step 5: Develop the Use Case Communications and Engagement Plan

Transformations stall when stakeholders are caught off guard by new requests or data requirements. The Change Manager must plan the engagement cadence before the technical work begins.

• Action: Create a targeted communication plan outlining how and when the new TBM capabilities, expected quick wins, and required process changes will be shared with the organization.
• Outcome: A documented communications and stakeholder enablement strategy.
• Application (What you do with this): You will execute this plan throughout the build and post-launch phases to keep stakeholders informed and manage expectations. For example, you will use this plan to communicate a “good enough to start” data approach, which helps prevent stakeholders from abandoning the effort if early models are imperfect.
• Tool to Leverage: Reference the Top Five Best Practices for Successful TBM Adoption whitepaper for guidance on building communication plans, establishing champion networks, and delivering quick wins to build trust.

Validating the Strategic Value

By the end of Phase 1, the Change Manager has successfully translated an abstract business problem into a governed, strategically aligned TBM use case. They have built organizational urgency, mapped out a champion network to overcome cultural resistance, and secured a guiding coalition anchored by the Executive Sponsor. Furthermore, a clear communication strategy and target adoption metrics are formalized. This groundwork ensures that the technical build will not drift into scope creep, as the established “Strategic Value” statement provides strict boundaries for the TBM Administrator. Armed with scorecard-aligned KPIs and tailored value propositions for secondary stakeholders, the Change Manager is now fully equipped to navigate political barriers and secure vital data access in the next phase.

 

Phase 2: Unlocking Architecture & Dependencies (Data Sourcing)

The Objective

TBM modeling fundamentally depends on a reliable foundation of high-quality, cross-functional data. However, acquiring this data often requires significant political capital, as data silos and cultural resistance to transparency are frequent barriers to adoption. Your objective in this phase is to secure the necessary data prerequisites by removing obstacles and empowering broad-based action (Kotter), while equipping data stewards with the “Knowledge” and “Ability” (ADKAR) required to support the TBM model.

Step 1: Map Data Owners and Identify Silos

Before the technical build begins, you should identify who controls the systems that will feed the TBM model.

• Action: Map the required financial, operational, and organizational data sources—such as the General Ledger, cloud billing, IT asset management (CMDB), and HR systems—to their respective domain owners across the enterprise.
• Outcome: A comprehensive data dependency map identifying key stewards across Finance, IT, Procurement, and Business Operations.
• Application (What you do with this): You will use this map to direct your stakeholder engagement efforts. By identifying these owners early, you ensure the TBM Administrator has a clear path to data access and is not blocked by unexpected political or organizational silos during the pipeline construction phase.
• Tool to Leverage: Use the Learn TBM > TBM Framework > TBM Foundations > Data site page as a checklist. It details essential foundational datasets (e.g., General Ledger, Labor, Cloud/FinOps data, and Vendor Contracts), ensuring you aren’t forgetting any critical enterprise data domains during your mapping exercise.

Step 2: Define Data Quality and Readiness Criteria

A major cause of stalled TBM implementations is the endless pursuit of “perfect” data. The Change Manager will facilitate alignment on what is actually required to begin.

• Action: Facilitate a session with the data owners and the TBM Administrator to agree on the data readiness criteria, specifically defining the required completeness, consistency, timeliness, and accuracy for the use case.
• Outcome: A documented data readiness baseline and an agreed-upon threshold for acceptable data fallout (unmapped costs).
• Application (What you do with this): You will use this baseline to prevent the technical build from stalling. If a dataset does not meet these criteria, you will step in to mediate remediation with the data owner before the Administrator wastes time building faulty pipelines. Conversely, you will use this to stop the technical team from endlessly tweaking rules if the data already meets the “good enough” threshold.
• Tool to Leverage: Reference the Discover > Hot Topics > Use Cases guide to evaluate data readiness criteria, and the Learn TBM > TBM Modeling > Data Quality / Fallout page to establish acceptable thresholds for unmapped costs and exception reporting.

Step 3: Communicate the “WIIFM” and Secure Data Commitments

Data owners may be hesitant to share or clean their data if they fear it will expose inefficiencies or create additional work.

• Action: Leverage the documented narrative and stakeholder map from Phase 1 to explain the “What’s In It For Me” (WIIFM) to each data owner. Address resistance by focusing on directional, “good enough to start” insights that build trust rather than demanding perfect data on day one.
• Outcome: Documented commitments for data access and a shared understanding of the required data quality baseline.
• Application (What you do with this): You will hand these secured relationships and data access permissions over to the TBM Administrator. This enables the technical team to focus strictly on building the data pipelines and allocation engines rather than negotiating for system permissions or fighting for compliance.
• Tool to Leverage: Reference the whitepaper Initiating Virtuous Cycles with TBM. Use its specific playbooks for overcoming stakeholder resistance, partnering opponents with allies, and leveraging “good enough to start” directional insights to build trust with hesitant data owners.

Step 4: Document the TBM RACI Model for the Use Case

With data access secured, you must clarify exactly who is doing the work during the technical build to prevent dropped handoffs.

• Action: Document the exact roles and responsibilities for the data pipeline and use case execution, clearly distinguishing the Data Owner providing the feed, the TBM Administrator building the mapping, and the TBM Analyst validating the output.
• Outcome: A formally agreed-upon RACI matrix for the use case execution.
• Application (What you do with this): You will use this matrix to reduce operational ambiguity during the build phase. When a data feed breaks, requirements change, or an allocation rule needs adjustment, you will use this RACI to immediately route the issue to the accountable party, preventing delays and finger-pointing.
• Tool to Leverage: Lift the RACI matrix directly from the eBook Mastering Technology Business Management Adoption: Roles & Responsibilities. This provides a ready-made template to establish clear accountability across the TBM Office and external stakeholders.

Step 5: Establish Federated Data Governance

TBM promotes federated governance, meaning no single team can or should own all the data.

• Action: Establish a federated data governance structure that distributes ongoing data responsibility to the appropriate domain experts, such as assigning IT Operations to own utilization data, Finance to own the ledger, and the PMO to own project and labor data.
• Outcome: Documented data ownership agreements that outline exactly who owns the definitions, quality monitoring, and refresh cadences for each data source post-launch.
• Application (What you do with this): This governance structure becomes your operational safety net. In the later phases of the use case, when new unmapped costs or data exceptions inevitably occur, you will use these contracts to hold the specific domain experts accountable for remediation, reinforcing that data quality is a shared enterprise responsibility rather than just an IT problem.
• Tool to Leverage: Reference the Learn TBM > TBM Framework > TBM Foundations > Data site page for guidance on establishing data ownership, reporting, and relationships with stakeholders across Finance, IT, Procurement, and Business Operations to sustain the model over time.

Unlocking Architecture & Dependencies

Upon completing Phase 2, the Change Manager has dismantled the organizational silos that typically restrict access to foundational systems like the General Ledger, cloud billing, and the CMDB. By defining practical data readiness criteria and formalizing a federated data governance structure, they have secured active commitments from domain experts across IT, Finance, and Business Operations. A formal RACI matrix is now in place, establishing clear accountability for data provisioning and model execution. With data pipelines politically unlocked and governance contracts signed, the TBM Administrator can now focus strictly on building the model without fighting for permissions or debating data perfection. This frees the Change Manager to advance to Phase 3, where they will focus on training stakeholders and integrating these new TBM insights into the organization’s daily operating rhythms.

Phase 3: Supporting the Step-by-Step Execution (Process Integration)

The Objective

As the TBM Administrator builds the allocation engine and configures the TBM Model, the operational reality of the business should shift to support it. Drawing on Kotter’s principle of empowering broad-based action, your objective is to identify and implement the upstream process changes required to feed the model. On an individual level, you are driving the “Knowledge” and “Ability” stages of ADKAR by equipping stakeholders to adopt new operational routines, such as updated tagging standards or time-tracking adjustments. Because change is a continuous discipline rather than a discrete project phase, this step-by-step execution runs in parallel to the technical build to embed TBM into how the business makes decisions.

Step 1: Identify Required Process and Method Changes

If a new use case requires operational data to map correctly, the upstream processes generating that data will likely need adjusting.

• Action: Work with the TBM Administrator to identify any new operational signals, Connected Standards (like FinOps or ITSM), or TBM Methods (such as delivery methodology, deployment environment, or lifecycle management) required to make the use case’s cost allocations work.
• Outcome: A documented list of upstream process changes required from secondary stakeholders.
• Application (What you do with this): You will use this list to design targeted training. If a use case requires cloud costs to be mapped to products, you know you must train engineers on a new cloud tagging policy before the model goes live.
• Tool to Leverage: Use the Learn TBM > TBM Framework > TBM Foundations > Methods site page to understand how operational attributes like Agile delivery, cloud environments, or lifecycle stages need to be tagged and captured to enable precise cost allocation.

Step 2: Design and Execute Role-Specific Training

Process changes fail when stakeholders don’t understand the mechanics of the new expectation.

• Action: Design and execute communication and training rollouts with role-specific curricula (e.g., service owner vs. product manager vs. finance analyst), providing sandbox exercises on real data.
• Outcome: Stakeholders equipped with the “Knowledge” and “Ability” (ADKAR) to execute their new operational routines.
• Application (What you do with this): By ensuring engineers know how to apply new cloud tags or product owners know how to log Agile team capacity, you prevent the data pipeline from failing on day one, ensuring the TBM Administrator has the necessary high-quality data to fuel the model.
• Tool to Leverage: Reference the Top Five Best Practices for Successful TBM Adoption whitepaper for guidance on educating stakeholders and explicitly aligning TBM benefits to specific stakeholder needs. Additionally, you can model your role-specific enablement on the structure of the Learn TBM > Education > Practitioner Course, which emphasizes hands-on, scenario-based training to build practical skills.

Step 3: Establish Formal Feedback Loops

As users attempt to adopt new routines, friction is inevitable. You should capture and address this friction before it turns into active resistance.

• Action: Set up structured mechanisms such as office hours, release notes, and backlog grooming sessions to capture stakeholder input during the rollout.
• Outcome: A formalized channel for capturing user friction and managing resistance.
• Application (What you do with this): You will use this feedback to continuously improve Data, Methods, and Tools. If users struggle with a new tagging standard, you can immediately identify the friction and adjust the training or the technical requirement before stakeholders abandon the process entirely.
• Tool to Leverage: Reference the Top Five Best Practices for Successful TBM Adoption to understand how to educate stakeholders and mitigate barriers—like cultural resistance or data quality concerns—using quick wins, communication plans, and champion networks.

Step 4: Embed TBM into the Operating Rhythm

To prevent the new processes from being treated as temporary projects, change must be timeboxed and measured within existing corporate schedules.

• Action: Identify key recurring meetings and formally embed TBM reviews into these cadences, such as monthly operational reviews for transparency, quarterly portfolio checkpoints for strategy, or biannual method tune-ups.
• Outcome: TBM processes woven directly into the existing corporate operating rhythm rather than acting as a standalone, disconnected chore.
• Application (What you do with this): This ensures that upstream data providers are continuously prompted to maintain their inputs, preventing data staleness. It also ensures that the Executive Sponsor and business leaders use the TBM decision views as the primary basis for future funding, prioritization, and performance reviews.
• Tool to Leverage: Leverage the Mastering Technology Business Management Adoption: Roles & Responsibilities eBook to help institutionalize these cadences across the TBM Office, utilizing its RACI matrix to clarify ongoing responsibilities and ensure accountability doesn’t fade post-launch.

Supporting the Step-by-Step Execution

By the end of Phase 3, the Change Manager has successfully shifted the organization’s operational habits to sustain the new TBM model. Through targeted, role-specific training, secondary stakeholders—such as engineers and product owners—now possess the practical knowledge and ability to execute required upstream processes, such as cloud tagging or Agile capacity logging. Furthermore, the Change Manager has instituted formal feedback loops to mitigate user friction and woven these new TBM data routines directly into the existing corporate operating rhythm. With data providers actively maintaining their inputs without treating the effort as a temporary chore, the TBM Administrator now has a far more sustainable and reliable operational data foundation to fuel the model. The Change Manager is now perfectly positioned to advance to Phase 4, where the focus will shift from the data providers to the data consumers—driving the executive adoption of the newly built KPIs and decision views.

Phase 4: Driving Adoption of KPIs & Decision Views (Post-Development)

The Objective

With the technical build complete and the data pipeline flowing, the focus shifts from the data providers to the data consumers. Drawing on Kotter’s final step of anchoring new approaches in the culture, your objective is to ensure the new TBM insights are actually used to make business decisions. On an individual level, you are driving the “Ability” and “Reinforcement” stages of ADKAR, ensuring that stakeholders can interpret the new dashboards and are recognized for utilizing them.

Step 1: Deliver Role-Specific KPIs and Decision Views

A dashboard that attempts to answer every question for every stakeholder will overwhelm users and stall adoption.

• Action: Partner with the TBM Analyst (acting as the “insight hunter”) to ensure the final dashboards and KPIs are tailored specifically to the primary persona and secondary consumers identified in Phase 1.
• Outcome: Targeted, role-specific decision views that cut through the noise and highlight relevant cost drivers and consumption patterns.
• Application (What you do with this): You will use these tailored views to prevent dashboard fatigue. By delivering the exact KPIs that matter to a specific leader (e.g., unit costs for a service owner vs. ROI for a product manager), you lower the barrier to entry and accelerate their ability to use the data.
• Tool to Leverage: Use the Learn TBM > TBM Modeling > KPIs/Metrics site page to select appropriate metrics aligned to your organization’s maturity phase (Ramping, Accelerating, or Innovating), ensuring you don’t overwhelm users with advanced ESG or AI metrics if they only need foundational cost variance tracking.

Step 2: Execute Post-Launch Communications

Stakeholders must be formally introduced to the new capability and understand that it is now the system of record.

• Action: Roll out the communications and engagement plan you developed in Phase 1, utilizing sustained mechanisms such as newsletters, town halls, and executive briefings.
• Outcome: Broad organizational awareness of the new TBM capability and clear expectations for its use.
• Application (What you do with this): You will use this communication blitz to publicly transition the organization away from legacy spreadsheets and fragmented reporting. It sets the formal expectation that the new TBM model is live and ready for consumption.
• Tool to Leverage: Reference the Discover > Hot Topics > Adoption site page, which provides a practical path for communications strategy and stakeholder enablement to help transition from your initial rollout to sustained operational maturity. You can also leverage the Top Five Best Practices for Successful TBM Adoption whitepaper for guidance on building sustained communication plans and champion networks that build trust and momentum.

Step 3: Track Adoption Telemetry

You cannot manage what you do not measure. The Change Manager must prove that the expected behavioral shifts are occurring.

• Action: Actively monitor the scorecard-aligned adoption metrics you defined in Phase 1, such as dashboard usage by role, the percentage of services with published unit costs, or the percentage of spend covered by the new TBM views.
• Outcome: Quantifiable data on user adoption and friction points.
• Application (What you do with this): You will use this telemetry to identify where adoption is lagging. If a specific business unit is not logging into the dashboard, you can proactively intervene with targeted training or coaching before they permanently revert to their old ways of working.
• Tool to Leverage: Use The TBM Maturity Assessment whitepaper and its associated tool to formally evaluate the ongoing maturity of your TBM practice across dimensions like engagement, value, reporting, and automation. Additionally, reference the Learn TBM > TBM Modeling > KPIs/Metrics site page to select maturity-aligned indicators—such as the TBM Maturity Score or the percentage of solutions measured with TBM KPIs—to actively track your program’s adoption and impact.

Step 4: Institutionalize through Executive Governance

To prevent the use case from becoming an optional reporting exercise, it should carry mandatory weight in executive forums.

• Action: Partner with the Executive Sponsor to ensure the new TBM decision views are actively used in official governance cadences, such as quarterly business reviews (QBRs) and budget approvals.
• Outcome: The new TBM model becomes the increasingly trusted basis for enterprise decision-making and funding.
• Application (What you do with this): This is how you anchor the change in the corporate culture. When the Executive Sponsor begins rejecting funding requests or business cases that are not backed by the new TBM insights, adoption across the rest of the enterprise accelerates significantly.
• Tool to Leverage: Read the article Executive Sponsorship-The Critical Catalyst for TBM and Enterprise Transformation to help your sponsor enforce governance, standardize financial language, and use the insights to align technology spending with enterprise strategy.

Step 5: Celebrate Wins and Reinforce Behavior

Transformations stall when teams feel their efforts to adapt are ignored. The final step is to fulfill the “Reinforcement” stage of ADKAR.

• Action: Identify and publicly recognize teams or individuals who successfully utilize the new TBM insights to achieve quick wins—such as finding cloud savings, rationalizing an application, or improving Agile delivery velocity.
• Outcome: Positive reinforcement of the desired operational shift and the creation of visible success stories.
• Application (What you do with this): Celebrating these wins builds momentum, proves the value of the TBM discipline to skeptics, and encourages remaining holdouts to adopt the new practices to achieve similar success.
• Tool to Leverage: Leverage the Top Five Best Practices for Successful TBM Adoption whitepaper for guidance on utilizing champion networks and promoting quick wins to build trust, overcome lingering resistance, and sustain momentum.

Driving Adoption of KPIs & Decision Views

By the end of Phase 4, the Change Manager has successfully transitioned the organization from building a TBM model to actively consuming its insights. Through tailored, role-specific views and a structured communications rollout, the primary and secondary personas are now equipped to make data-driven decisions. The Change Manager is actively tracking adoption telemetry to catch lagging users, while the Executive Sponsor has institutionalized the use case by mandating TBM insights in official funding and governance forums. By publicly celebrating quick wins, the Change Manager has reinforced the new behaviors, proving that the TBM model is not just an IT reporting tool, but a strategic driver of enterprise value.

With the use case successfully adopted and operationalized, the Change Manager is now ready to move into the final phase of the lifecycle, where they will capture feedback to refine the model and scale these capabilities across participating operational areas.

Phase 5: Continuous Improvement & Scaling (Iteration)

The Objective

Once the initial use case is live and stakeholders are actively consuming the decision views, the Change Manager must ensure the practice does not stagnate. Your objective in this final phase is to shift the organization from a project-based implementation mindset into a state of continuous improvement. You will measure the maturity of the new capabilities, operationalize ongoing data governance to prevent model degradation, and strategically scale the TBM discipline to support advanced use cases and new business personas.

Organizations should scale these practices appropriate to their maturity and operational complexity.

Step 1: Evaluate TBM Maturity and Identify Gaps

To sustain momentum and justify further investment, you should formally measure how well the TBM practice has been adopted and where friction remains.

• Action: Facilitate a formal maturity assessment evaluating the practice across six dimensions: data, taxonomy, engagement, value, reporting, and automation.
• Outcome: A documented maturity baseline and a prioritized roadmap for continuous improvement.
• Application (What you do with this): You will use this assessment to demonstrate progress to the Executive Sponsor. By quantifying improvements in engagement and reporting, you secure the ongoing leadership support and funding needed to expand the TBM practice into new business units or advanced capabilities.
• Tool to Leverage: Use The TBM Maturity Assessment: A New Tool for Determining the Maturity of Your TBM Practice whitepaper and its associated assessment tool. It provides a structured framework for identifying strengths and weaknesses to inform your long-term evolution roadmap.

Step 2: Operationalize Fallout and Data Quality Management

If data quality degrades over time, stakeholders will quickly abandon the new dashboards. The Change Manager must ensure data remediation becomes a routine habit rather than a massive annual cleanup.

• Action: Transition the federated data contracts established in Phase 2 into a sustained operational rhythm, deploying QA dashboards and exception reporting to monitor unmapped costs (“fallout”) continuously.
• Outcome: Sustained data integrity and enduring stakeholder trust.
• Application (What you do with this): When unmapped costs or data exceptions inevitably appear, you will use your QA dashboards and RACI matrix to immediately route the fallout to the accountable domain owner for remediation. This ongoing accountability prevents the TBM Administrator from becoming a bottleneck and helps sustain confidence in the model long after the initial launch.
• Tool to Leverage: Reference the Learn TBM > TBM Modeling > Data Quality / Fallout site page. Apply its best practices for detecting fallout across the TBM layers and institutionalizing QA dashboards to maintain data integrity over time.

Step 3: Scale to Advanced Use Cases and Personas

With foundational transparency achieved and basic use cases adopted, the Change Manager must guide the organization toward higher-value strategic domains.

• Action: Partner with the Executive Sponsor and TBM Practice Lead to target the next phase of maturity—such as moving from basic cost visibility to advanced use cases like AI ROI, Agile funding, or Sustainability tracking.
• Outcome: Expanded TBM scope and deeper integration into enterprise value drivers.
• Application (What you do with this): You will use the success of the initial rollout to bring reluctant secondary personas (such as FinOps leads or Agile Product Owners) into the TBM ecosystem. You can now show them tangible proof of TBM’s value, lowering resistance as you ask them to participate in more complex, integrated use cases.
• Tool to Leverage: Read the High Impact TBM Use-Cases whitepaper. Use its structured approach to identify and prioritize the right use cases for your organization’s current maturity stage—moving confidently from Ramping phase practices into Accelerating and Innovating capabilities.

Step 4: Cultivate and Expand the Champion Network

To truly institutionalize the change, advocacy must ultimately come from the business itself, not just from the central TBM Office.

• Action: Transition the initial project champions identified in Phase 1 into a sustained, self-sufficient community of practice, encouraging them to share wins and mentor new users.
• Outcome: Decentralized advocacy and a self-sustaining TBM culture.
• Application (What you do with this): You will leverage these embedded champions to organically train new staff, answer front-line dashboard questions, and enforce tagging standards within their respective departments. This drastically reduces the operational burden on the core TBM team and ensures the new behaviors scale across the enterprise naturally.
• Tool to Leverage: Reference the Top Five Best Practices for Successful TBM Adoption whitepaper for proven strategies on establishing champion networks, using continuous quick wins to build trust, and maintaining long-term stakeholder alignment.

Continuous Improvement & Scaling

By the end of Phase 5, the Change Manager has successfully guided the organization from a single, isolated TBM implementation into a dynamic, continuously improving enterprise capability. Through formal maturity assessments, the Change Manager has quantified progress and charted a strategic roadmap for the future. Data governance is now a decentralized, operationalized habit, ensuring the model remains accurate and trusted over time. Furthermore, by expanding champion networks and targeting advanced use cases, the Change Manager has more deeply integrated TBM into the organization’s operational culture. Ultimately, the Change Manager has ensured that the TBM model is not merely a static reporting tool, but a living, scalable discipline that continuously drives strategic value, optimization, and alignment across the enterprise.

Conclusion: From Project Execution to Sustainable Capability

What You Have Achieved

By executing the five phases outlined in this playbook, you have enabled your organization to treat Technology Business Management not as a static reporting exercise, but as a dynamic driver of enterprise value. You have successfully guided the organization through the complete lifecycle of a TBM use case.

Starting from a fragmented business problem, you established organizational urgency and secured a guiding coalition (Phase 1). You broke down cultural resistance and data silos, establishing the federated data governance required to fuel the model (Phase 2). Working in parallel with the technical build, you shifted the organization’s daily operating rhythms and equipped data providers with the necessary role-specific training (Phase 3). Upon launch, you successfully drove the consumption of tailored KPIs, institutionalizing TBM decision views into executive governance forums (Phase 4). Finally, you established a roadmap for continuous improvement, ensuring the practice does not stagnate (Phase 5).

The ultimate outcome is a culturally adopted, embedded, and trusted TBM capability that directly links technology investments to strategic business goals.

Integrating Outputs into Broader Change Operations

The artifacts and mechanisms you created during this use case development must not be discarded now that the initial project is live. To sustain success, these outputs must be formally integrated into the broader, ongoing change management operations of the TBM Office:

• The Champion Network: The allies and champions identified in Phase 1 should be formalized into a sustained community of practice that mentors new users and enforces operational standards (like cloud tagging) across their respective departments.
• Federated Data Contracts: The RACI matrices and data readiness criteria established in Phase 2 should become permanent governance fixtures, ensuring domain experts (Finance, IT Ops, PMO) remain continuously accountable for data quality.
• Feedback Loops and Adoption Telemetry: The mechanisms used to capture user friction and track dashboard usage in Phases 3 and 4 must become standard operating procedures for the TBM Office, driving the ongoing backlog grooming for future technical releases.

Ultimately, change management within TBM is a continuous discipline. By institutionalizing these outputs, you ensure the organization is perpetually equipped to absorb new use cases and adapt to shifting enterprise strategies.

Next Steps and Recommended Resources

With foundational transparency and your initial use case successfully adopted, your next step is to scale the TBM discipline to tackle more advanced business challenges and continuously measure your program’s maturity.

To support what comes next, leverage the following resources from the TBM Council Publication Library:

• For scaling to your next capability: Read the High Impact TBM Use-Cases whitepaper. Use this guide to identify and prioritize your next target, moving confidently from foundational visibility into advanced capabilities like AI ROI, Agile funding, or Sustainability tracking. Visit the associate site page for even more details and use cases.
• For ongoing measurement: Utilize The TBM Maturity Assessment: A New Tool for Determining the Maturity of Your TBM Practice. This tool will help you continuously evaluate your progress across data, taxonomy, engagement, value, reporting, and automation, providing a structured roadmap for your long-term TBM evolution.
• For institutionalizing the TBM Office: Reference the eBook Mastering Technology Business Management Adoption: Roles & Responsibilities to refine the organizational structure, update RACI matrices, and formally embed your change management practices into the permanent roles of the TBM Office.

Appendix A: Applying This Playbook in Resource-Constrained Environments

Organizations adopt Technology Business Management with widely varying levels of staffing, governance maturity, operational structure, and technical capability. While this playbook presents a comprehensive model for supporting TBM use case development, organizations should not interpret every activity described throughout the paper as a prerequisite for getting started. Many successful TBM initiatives begin with limited staffing, incomplete data, lightweight governance, and a narrowly scoped pilot use case designed to build momentum and demonstrate value incrementally.

What Is Actually Required to Begin?

Organizations do not need a fully mature TBM practice, dedicated change management office, or perfectly governed datasets before beginning their initial TBM use case. In many cases, organizations can successfully begin with:

• A clearly defined operational or financial visibility challenge
• One engaged stakeholder or Executive Sponsor
• A limited pilot use case tied to a meaningful business problem
• Available financial and operational data, even if incomplete
• Lightweight collaboration between participating teams
• A willingness to iteratively improve governance, data quality, and reporting over time

In resource-constrained environments, responsibilities described throughout this paper may also be distributed across a smaller number of individuals. The Change Manager role, for example, may be performed by a TBM Practice Lead, TBM Administrator, Finance stakeholder, or operational leader supporting adoption activities alongside their primary responsibilities.

What Commonly Evolves Over Time?

Many of the operational structures associated with mature TBM practices develop progressively as organizational trust, participation, and adoption increase. Organizations often begin with lightweight operational coordination before expanding into more formal governance and enterprise-wide capabilities over time.

Capabilities that commonly mature progressively include:

• Formal governance boards and review cadences
• Enterprise-wide Solution TCO visibility
• Automated data integrations and allocation processes
• Advanced tagging and ownership models
• Standardized reporting and KPI frameworks
• Dedicated TBM change management and operational support roles
• Formalized stewardship, accountability, and data quality processes
• Expanded telemetry, adoption tracking, and maturity assessments

The objective is not to delay progress until every capability is fully operationalized, but to establish enough visibility and organizational alignment to begin delivering directional insights that build trust and support continuous improvement.

How the Five Phases Scale

The five phases described throughout this playbook can be adapted significantly based on organizational maturity, staffing levels, and available resources. In many organizations:

• Phase 1 may begin with a small number of stakeholder discussions rather than formal workshops or steering committees.
• Phase 2 may rely on manually assembled data, recurring working sessions, and lightweight ownership agreements during early adoption.
• Phase 3 may focus enablement efforts only on the teams directly supporting the pilot use case.
• Phase 4 may initially integrate TBM insights into existing budgeting or operational meetings before establishing more formal governance structures.
• Phase 5 may focus on refining and expanding a single successful use case before scaling the approach across additional solutions or operational domains.

Over time, the practices, governance structures, communication approaches, and operational routines established during early TBM adoption can evolve into broader enterprise capabilities that support increasingly advanced use cases and strategic decision-making activities.