Hey everybody, and welcome back to the Operational ITAM Podcast. I'm Bill Van Nort, and today we're going to fix a meeting.

You know the one. Procurement has a better price. Finance wants the saving. The application owner says the replacement won't be ready. Asset management has found a licensing condition nobody put in the business case. And somebody has written, "All stakeholders aligned," at the bottom of the slide.

That's optimistic. They've all received the slide.

Here's the question. When those people disagree, who actually has the authority to decide what happens next?

Because a renewal can move through every department, collect every comment, and still reach its deadline without anyone owning the decision. The contract renews. The meeting recurs. Apparently, only one of those things required a signature.

Today begins The Decision Table. Who Owns the Renewal Decision?

Good morning, good afternoon, or good evening, wherever you're listening from. This is the show where we take the unglamorous machinery of enterprise technology and make it make sense. Grab your coffee.

In episode fourteen, we challenged the bill before negotiating the discount. We separated price, quantity, and terms. Now we're leaving the Grid and doing the operating-model work I promised. Who uses that evidence, who can commit the business, and who checks whether the result actually happened?

ITAM, or IT asset management, connects the technology estate to its ownership, rights, obligations, costs, and lifecycle. FinOps connects technology consumption and cost to business value through collaboration. That's consistent with the FinOps Foundation's current framework. They overlap. Neither becomes the other just because both have a spreadsheet open.

The Foundation's twenty twenty-six framework update puts explicit attention on executive strategy and decisions across technology categories. Its Intersecting Disciplines guidance describes coordination between FinOps and functions such as asset management, procurement, finance, security, and architecture. It allows different organizational arrangements. You don't have to merge departments to begin.

My opinion, clearly labeled: start with a decision that matters, and make the working arrangement prove itself there. You can discuss reporting lines afterward. Preferably after somebody has demonstrated that the arrangement can produce an answer.

The counterargument is fair. Some organizations need structural change because authority is genuinely fragmented. A meeting won't repair conflicting mandates. But working through one decision exposes exactly which authority is missing. That's a better basis for escalation than a general complaint that nobody collaborates.

Let's work a case. This is a fictional company, with invented prices and explicit assumptions. It isn't a client story or an industry benchmark. All amounts are U.S. dollars.

The company runs customer support on a software service with a renewal quote of six hundred thousand dollars a year. A competing service offers the required subscription scope for four hundred eighty thousand a year.

The first slide says, "Save a hundred twenty thousand dollars annually."

Then the delivery estimate arrives. A hundred twenty thousand dollars to change platforms. That estimate includes data conversion, implementation, overlapping subscriptions, training, and the internal effort assigned to the project. For now, assume the estimate is complete and the migration finishes on schedule. We'll test that assumption shortly.

In the first year, the alternative's subscription and transition total six hundred thousand dollars. The recurring price is lower. The modeled first-year total is the same.

Finance also needs to distinguish cash payments from internal capacity. A salaried employee's project time can be a real economic cost without becoming an additional payroll payment. Record it once, and say what kind of cost it is.

That's the position when our meeting starts. There may be a good reason to move. But the original slide has skipped the work required to get there.

Before inviting anyone, write the decision in plain language. For this case: should we renew the incumbent, migrate to the alternative, or pursue a shorter bridge arrangement while we resolve a specific uncertainty?

Then write the deadline that preserves those choices. The renewal date may be too late. The notice clause, procurement lead time, migration schedule, and any required approval come first. This is episode nine's renewal clock, now attached to a decision somebody has to make.

I would ask the service owner to explain the business requirement. Which customer interactions must keep working? What would acceptable performance look like? Which integrations and historical records are essential? The requirement needs to be clear enough to test against either supplier.

Asset management brings the entitlement position and lifecycle evidence. An entitlement is the documented right to use something. What have we bought? Which terms apply? What is assigned or deployed, and what would change under each option? If we retain part of the old service, identify that obligation explicitly.

FinOps brings the consumption pattern and its cost drivers. What is the service actually doing? What changes if demand grows, falls, or shifts into a more expensive feature? A forecast should describe the business behavior that produces the bill.

Procurement brings the executable commercial options. Quote validity, notice requirements, minimum commitments, renewal provisions, and the route to a signed change. Legal reviews the interpretations and obligations that need legal judgment. Security and privacy review the relevant controls and data handling. They can prepare their findings before the meeting; everyone doesn't need to sit through every discussion.

Engineering or architecture validates whether the alternative can work in our environment. The delivery lead establishes whether the migration can happen with the people and time available. The service owner accepts the operational outcome within their authority. Those may be different people.

Finance agrees how the options will be compared and how any benefit will be recognized. It should be possible to follow the numbers back to the organization's financial records.

Finally, identify the person with delegated authority to approve this decision. Their authority must cover the spend and the tradeoffs being accepted, or the decision needs escalation. A budget holder cannot simply waive a legal obligation or override a security requirement outside their authority.

That person needs a recommendation they can act on. "Everyone should review" is an assignment that can survive indefinitely without ever being completed.

Now we put the evidence together. Same service. Same scope. Same comparison period. Dates on the source records. Someone responsible for resolving each material gap.

Suppose the usage report shows fewer active people than the license register. Don't average the counts. Find out what each one measures. A monthly active-user report and a count of assigned licenses are answering different questions. Seasonal use, service accounts, people on leave, and retention requirements can explain part of the difference. So can genuinely unused assignments.

Episode thirteen gave us FOCUS, the FinOps Open Cost and Usage Specification, as a way to make billing data more comparable. That helps this meeting. It doesn't turn a billing record into proof of entitlement or tell us whether a customer-support workflow can move safely.

Keep those evidence types linked, with their limits visible. If a report excludes a subsidiary, say so. If the contract interpretation is unresolved, give it an owner and an answer date. A green cell shouldn't conceal an unanswered question.

You also need a route for disagreement. If the service owner says migration takes six months and the proposal assumes three, that's a decision input. Ask what would make the shorter schedule credible. Additional people? Reduced scope? A different cutover? Price those options and test the consequences.

If nothing supports the shorter schedule, change the model. The spreadsheet doesn't get a vote on how long the integration takes.

What if nobody will accept the decision authority? Then your next action is escalation, with the consequence made explicit. This option expires on this date. This notice must be sent by that date. Here is what happens if nobody acts. Ask the executive who owns the relevant budget and service to name the authorized decision maker, following the organization's delegation rules.

Don't quietly assign yourself authority because everyone else is busy. And don't interpret silence as approval. Your contribution is to make the unresolved choice visible while there is still time to resolve it.

There is also a difference between someone challenging the evidence and someone withholding a decision. A licensing specialist can say a proposed use isn't supported by the agreement. The decision owner then needs a lawful alternative, different terms, or a different proposal. Calling that specialist uncommercial won't change the license.

I would rather have that disagreement in preparation than discover it after the purchase has become somebody's success story.

Let's take a quick break. If the difficult part in your organization is deciding who owns the work, I've built a resource for that in the Operational ITAM Store.

It's called Roles and Operating Cadence. The product includes role charters with authority boundaries and assessment exercises, plus a workbook for service catalog, assignments, cadence, and workload. There are Word, PDF, and offline HTML resources.

Use it to work through who is accountable, what they can decide, and how the work gets reviewed. Adapt it to your organization. A role description still needs an actual person with the authority and time to carry it out.

You can review the contents and selected preview at operational I T A M dot com slash store. This is my paid resource, and buying it supports the show. The exercise at the end of this episode is free and uses records you already have.

If this conversation would help someone who owns your next renewal, send them the episode. You can also visit operational I T A M dot com for the podcast, transcripts, and practical resources.

Alright. Back to the decision. Before we finish our fictional case, consider two real purchasing mechanisms.

Microsoft's S Q L Server licensing guidance says licenses with Software Assurance, or qualifying software subscription licenses, include Azure Hybrid Benefit. Software Assurance is Microsoft's coverage program that provides specified benefits alongside eligible licenses.

That can change a cloud comparison. But you need the applicable product terms, license eligibility, quantities, assignments, and coverage dates. You also need to establish whether rights are already supporting another deployment and which simultaneous-use conditions apply. A setting that enables a billing benefit doesn't establish that you're entitled to use it.

The asset specialist validates the rights. The cloud team validates the deployment and consumption. Finance compares the costs. Procurement checks the agreement. Same decision, different evidence.

Now Amazon Web Services. Its Compute Savings Plans exchange lower eligible usage prices for an hourly spending commitment over a one-year or three-year term, as described in the AWS Savings Plans documentation.

If engineering plans to reduce or retire workloads, buying against yesterday's consumption can leave you with a commitment the future workload doesn't use. Eligible usage elsewhere might absorb it, subject to the plan's scope and sharing configuration. That needs checking.

AWS also documents limited return provisions. Don't build a long-term exit strategy around a short purchase-return window.

The practical question is what consumption will remain after the approved architecture changes. Check that before buying the commitment. Keep technical efficiency, commitment utilization, and invoice reduction separate in the benefit report.

These are current vendor mechanisms, not assumptions about our fictional support-service contract. The common lesson is why a low rate can't settle the decision on its own.

Back to our case. We're comparing three years, using constant prices, the same required service scope, and no discounting. This is an illustrative cost comparison, not a complete investment appraisal. Finance would add the organization's treatment of timing, taxes, inflation, and other material factors.

At six hundred thousand a year, staying costs one million eight hundred thousand dollars over three years. The alternative costs one million four hundred forty thousand in subscriptions, plus the hundred twenty thousand transition. Total: one million five hundred sixty thousand.

That puts the alternative two hundred forty thousand dollars lower in our base case. It is a modeled difference, not a saving we've realized.

Then procurement returns with a revised incumbent offer. A three-year renewal at five hundred forty thousand dollars a year, fixed for that term, for the same required scope. For this illustration, assume the supplier will contract on those terms.

The incumbent's three-year total is now one million six hundred twenty thousand dollars. The alternative remains one million five hundred sixty thousand. The difference has narrowed to sixty thousand dollars over three years.

Nobody did anything wrong. The evidence changed. Our recommendation needs to change with it.

Now test the migration assumption. In an illustrative delay scenario, additional overlap and delivery effort add ninety thousand dollars beyond the transition cost already included. The alternative becomes one million six hundred fifty thousand dollars. That's thirty thousand more than the revised incumbent option.

We haven't proved migration is bad. We've identified what could reverse the cost ranking. The project team must tell us whether that delay scenario is credible and what could prevent it. Don't invent a probability to make the arithmetic look sophisticated.

Cost isn't the only acceptance test. Can customers still reach support during cutover? Can the team retrieve the required historical records? Does the replacement meet security and accessibility requirements? Establish how those questions will be tested and who can accept the result.

A valuable capability might justify paying more. So might a credible reduction in operational risk. Describe the benefit and its evidence without manufacturing a dollar value. The executive should know what the organization is buying with the difference.

For our support service, I would ask whether the change improves something customers or staff actually experience. Can an agent find the right case history? Does the workflow reduce a verified source of rework? Establish the baseline and an acceptance test before calling the new feature valuable. A feature demonstrated by the supplier is a candidate benefit. The service owner still has to establish whether it solves their problem.

For our worked case, assume testing hasn't yet established that the replacement can handle a required integration. The incumbent meets the present business requirement. The revised price is contractually available. The authorized owner chooses the three-year renewal, accepting that commitment, with a funded evaluation of the alternative before the next contractual decision window.

That is our fictional outcome. Another organization, with different evidence, could responsibly choose migration.

Now record the actual authorization. Which service and legal entity? Which offer and term? What spending limit? What conditions must be met before signature? Who implements the change, and when will the outcome be reviewed?

Record the rejected alternative and the reason. In this case, the unresolved integration and the narrow base-case advantage mattered. That protects the organization from having to reconstruct the decision later from a collection of meeting invitations.

A conditional approval needs a condition someone can verify. If legal clearance is required, identify the reviewer and the document. If testing is required, identify the acceptance criteria. Don't leave a phrase like "subject to satisfactory checks" floating above a purchase order.

And a bridge arrangement is only an option if the supplier actually offers it and the authorized parties agree. Price the extension, preserve necessary rights and support, and write down what the extra time will accomplish. Otherwise, you've bought another deadline with the same unanswered question attached.

The meeting isn't finished when the order is signed. In our case, procurement checks the executed order against the approved offer. The service owner confirms the expected service and configuration. Asset management updates the entitlement and renewal records. Finance verifies the billing and the agreed benefit treatment.

The revised incumbent price is sixty thousand dollars a year below the earlier six-hundred-thousand-dollar renewal option. That is not automatically sixty thousand below last year's actual spend. Those might be different baselines. Carry the comparison label into the report.

And don't let multiple teams count the same benefit independently. Procurement's negotiated reduction and the service owner's lower forecast may describe the same change. Give the change one traceable record, credit the contributors, and have finance validate the result.

Now establish the review rhythm. My recommendation is to fit it to the decision's risk and deadlines. A routine renewal inside approved limits may need a short review. A material migration or uncertain commitment needs closer attention. Set a review date and specific triggers for returning to the decision owner.

Those triggers could include a failed acceptance test, demand outside the approved forecast, a missed notice milestone, or a changed commercial offer. Give each trigger an action. An alert without an owner is just another thing people can acknowledge.

You don't need a new committee for every invoice. You need a reliable way to identify the decisions that cross boundaries, assemble the evidence, and reach someone who can act.

For a smaller organization, one person may carry several of these roles. Keep the questions separate even when the chairs aren't. Bring in specialist review where the rights, obligations, or risks exceed that person's expertise or authority.

Which brings us to today's principle. Accountability.

Shared work still needs clear decision authority. Being accountable means explaining the choice, arranging the work that makes it real, and returning to the evidence afterward. It doesn't require pretending you personally know every license term or migration detail.

Class dismissed. Here's your homework. Set aside about an hour, using information you're already authorized to access.

Choose one upcoming renewal. Write the decision and the last date that preserves your options. Name the person authorized to decide. List the available options, the evidence each one still needs, and the person responsible for supplying it. Use the same scope and comparison period for the costs.

Then write the condition most likely to change your recommendation. Don't write "more information." Write the specific missing answer. Finish with the implementation owner and the evidence you'll check after approval. Take that page to the decision owner before the meeting is booked.

If you want help making those responsibilities repeatable, you'll find my Roles and Operating Cadence resource in the Operational ITAM Store. The link is in the show notes. You can complete today's homework without buying it.

As we continue at The Decision Table, the next question is how to prove the value of a decision after the presentation is over. What changed, who benefited, and what can finance actually verify? That's the direction I want to explore next.

The case files are open. One situation, one page. The constraint, what you did, and what happened. Remove company names and sensitive details before sending it through the website. Send me one worth working, and I'll build an episode around it.

I'm Bill Van Nort, this is the Operational ITAM Podcast. Put the choice in writing. Give the owner usable evidence. Come back for the result. I'll talk to you next week. Take care.