Operational ITAM Podcast

A renewal can pass through every department and still arrive at its deadline without a decision owner. Bill Van Nort works through a fictional customer-support renewal to show how ITAM, FinOps, procurement, finance, engineering, and the service owner can reach a defensible choice and verify what happens afterward.

The episode examines a lower-priced replacement, transition costs, a revised incumbent offer, and a delay scenario that reverses the cost ranking. Azure Hybrid Benefit and AWS Compute Savings Plans illustrate why licensing rights, consumption forecasts, and commercial commitments need a shared discussion.

The company, prices, and outcome in the central case are illustrative, not a client case study or savings benchmark.

Website and transcripts: https://www.operationalitam.com/ · Operational ITAM Store: https://www.operationalitam.com/store/ · Roles & Operating Cadence: https://www.operationalitam.com/store/index.php?page=product&sku=CP-ROLES

The store contains Bill's paid resources. Today's homework requires no purchase.

Your homework
Choose one renewal. Record the decision, last useful decision date, authorized owner, options, missing evidence and its owners, the condition that would change your recommendation, implementation responsibility, and the post-approval check.

Discussion
Where does your renewal process stall: evidence, authority, migration readiness, or checking the result?

Chapters
00:00 The meeting that cannot decide
01:08 From a better bill to a better decision
02:44 The fictional renewal
04:32 Who comes to the table
06:40 When the evidence disagrees
09:16 A short break
10:24 Two real reasons the disciplines need each other
12:22 The offer changes
15:05 Make the decision executable
16:35 After the signature
18:23 The takeaway and the homework

Transcript
Primary references

FinOps Framework: https://www.finops.org/framework/
Intersecting Disciplines: https://www.finops.org/framework/capabilities/intersecting-disciplines/
ITAM and FinOps: planning and procurement: https://www.finops.org/wg/finops-itam-practical-scenarios-planning-procurement/
Microsoft SQL Server licensing: https://www.microsoft.com/licensing/guidance/SQL
Azure Hybrid Benefit: https://learn.microsoft.com/en-us/azure/azure-sql/azure-hybrid-benefit?view=azuresql
AWS Savings Plans FAQ: https://aws.amazon.com/savingsplans/faqs/
AWS Savings Plans returns: https://docs.aws.amazon.com/savingsplans/latest/userguide/return-sp.html
An EpicB Media LLC production.


Creators and Guests

Host
Bill Van Nort
Founder of Operational ITAM. Thirty years leading IT asset management in banking, mortgage, and automotive.

What is Operational ITAM Podcast?

Thirty years of enterprise IT, distilled into something you can use on Monday morning.

Operational ITAM is a podcast about the unglamorous machinery of enterprise technology — hardware and software asset management, licensing, audit defense, SaaS governance, and the money quietly leaking out of all of them. Host Bill Van Nort has led IT asset management, end-user computing, and workplace technology at large organizations across banking, mortgage, and automotive, reclaimed millions in software spend, and survived audits from the biggest publishers on the planet.

No vendor pitches disguised as advice. No jargon for its own sake. When something is an opinion, he says so. When the honest answer is "it depends," he tells you what it depends on.

New episodes cover the fundamentals that never change: know what you have, know where it is, know what it costs, know when it leaves.

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.