The Decision Table: Keep the Result

The project is finished. The invoice is lower. Six weeks later, someone asks for more licenses. What changed?

Bill Van Nort follows a fictional software service after its initial improvement has been verified. This episode separates legitimate growth, an outdated onboarding rule, and overdue temporary-access reviews, then shows how to preserve the result without blocking the service the business needs.

IN THIS EPISODE
• Keep purchased capacity, assignments and business requirements distinct.
• Check the process that creates new assignments as well as the current list.
• Set review triggers early enough to leave time for action.
• Treat missing evidence as unconfirmed.
• Reopen the decision when business needs change.
• Describe restored capacity without inventing another savings claim.

WATCH, LISTEN AND READ
https://www.operationalitam.com/pages/podcast-017-keep-the-result.html

PRACTICAL EXERCISE
Allow about an hour. Choose one completed technology change using authorized records. Record the verified outcome and date, a condition that could undermine it, the evidence that would reveal the change, its owner, the review trigger and the response deadline. Inspect a recent issue to see whether the cause was corrected and the result checked. If no example exists, mark the control untested.

CHAPTERS

• (00:00) - Keep the Result
• (00:53) - The Decision Table
• (02:22) - A fictional software service
• (02:33) - Verify the starting result
• (03:28) - Six weeks later
• (03:53) - Three causes, three responses
• (05:48) - Hand over the operating conditions
• (07:22) - Act before capacity runs out
• (08:41) - Roles and operating cadence
• (09:30) - Correct the assignment path
• (10:40) - Restored capacity, not new savings
• (12:08) - When the decision should change
• (13:20) - What an alert can see
• (14:13) - Ownership and authority
• (15:00) - Keep the review useful
• (16:03) - Beyond software: spare laptops
• (17:20) - A management update that supports action
• (18:51) - Your practical exercise
• (19:50) - Resources and closing
• (20:41) - Credits

TRANSCRIPT
SOURCES AND RESOURCES
FinOps Foundation — Usage Optimization: https://www.finops.org/framework/capabilities/usage-optimization/
FinOps Foundation — Anomaly Management: https://www.finops.org/framework/capabilities/anomaly-management/
Microsoft Learn — Manage group licenses: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-group-licenses?view=o365-worldwide
Amazon Web Services — Cost Anomaly Detection: https://docs.aws.amazon.com/cost-management/latest/userguide/manage-ad.html
Roles & Operating Cadence, Bill’s paid resource: https://www.operationalitam.com/store/index.php?page=product&sku=CP-ROLES
The exercise requires no purchase. The case quantities and prices are fictional, illustrative USD.

Operational ITAM Podcast | Bill Van Nort | An EpicB Media LLC production.
https://www.operationalitam.com

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 back
to a project that was finished.

The change went through. The invoice came
down. Finance checked the result,

the project manager closed the work, and
everybody moved on

to something else.

Six weeks later, someone asks for more
licenses.

That might be perfectly reasonable. The
business could be hiring. A new

customer could need support. A service you
deliberately kept small could have

become more useful.

Or the old onboarding process could still
be handing out the licenses you

just spent a month trying to recover.

The invoice won't necessarily tell you
which explanation is right. For a

while, the invoice might not change at
all.

Today, at The Decision Table: Keep the
Result.

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 fifteen, we worked through who
owns a decision when procurement,

finance, technology teams and the business
have different answers. We gave

the decision an owner, conditions and
follow-through.

Today starts after the initial result has
been checked. We're asking what has

to remain true for that result to last,
and what should happen when

those conditions change.

My opinion, clearly labeled: the work that
preserves a result should be

designed before the project team leaves. A
successful change deserves a

usable handover, including the evidence
that would tell its new owner

to pay attention.

The counterargument is reasonable. Teams
already have enough reporting. Every

completed project cannot become another
permanent meeting. I agree. The

answer has to fit the decision's exposure
and the time available to respond.

Sometimes that means a short exception
review in a meeting you already have.

Let's work through a fictional software
service. The company, quantities and

prices are invented. This isn't a client
case or a vendor offer. All amounts

are U.S. dollars.

Our company previously bought five hundred
fifty seats at twenty dollars per

seat per month. It completed an approved
reduction to four hundred fifty

seats, at the same price. Assume its
agreement permitted that change, and the

effective date and first full invoice were
verified.

The monthly subscription charge went from
eleven thousand dollars to nine

thousand. That first month's two thousand
dollar reduction is documented. We

aren't extending it across a year and
calling the future collected.

On the handover date, four hundred seats
were assigned. Fifty purchased seats

remained available. The service owner
deliberately retained that capacity for

expected demand. Whether fifty was the
right allowance was part of

the approved decision.

Write those facts down separately. Four
hundred fifty purchased. Four hundred

assigned. Fifty available. One dated
position, with a reason

for the difference.

Now move forward six weeks. Assigned seats
have reached four hundred

forty-six. The subscription still includes
four hundred fifty. The

invoice remains nine thousand dollars.

From the bill alone, everything looks
fine. From the capacity position, four

seats remain. Someone preparing the next
intake requests another fifty.

Before buying or removing anything, the
service owner asks what changed.

Eighteen of the additional assignments
support an approved business

expansion. The employees need the service,
the demand is documented, and the

people approving the expansion understood
the operating cost.

The other twenty-eight came through an old
onboarding template. The new role

design did not require this application,
but the template still assigned it.

The recovery project changed existing
accounts and missed the path used to

create new ones.

There's also a separate issue. Twelve
temporary assignments, already included

in the original four hundred, have passed
their review date. The associated

project has ended, but nobody has
confirmed whether those people

still need access.

Those twelve did not cause the increase of
forty-six. They are a different

question inside the current total. Keep
that distinction clear or your

reconciliation will create more confusion
than the report that started it.

We now have legitimate growth, an outdated
assignment rule and an overdue

review. A single instruction to cut
licenses would treat all three as

the same problem.

They need different responses.

For the eighteen approved assignments,
record the demand and its authority.

Update the forecast if the expansion
changes the expected pace of

consumption. There is no reason to make
those employees defend a business

decision that has already been properly
authorized.

For the twenty-eight template assignments,
confirm the role requirements with

the service owner. If the assignments are
unnecessary, correct the

provisioning rule and plan safe removal
from the affected accounts. Check

dependencies and required access first.

For the twelve temporary assignments,
return to the owner of the exception.

Has the need ended, or has the work
changed? Settle that question before

changing access. An expired review date
tells you a decision is overdue. It

does not establish that removing a service
is safe.

This is why I would preserve a little more
than the saving in the project

handover. Keep the approved scope, the
relevant quantities, the reason for

spare capacity and the conditions that
might require a new decision.

Then connect each condition to evidence
somebody can actually retrieve.

For assignment growth, that might be a
dated export, the approved intake and

the provisioning record. For temporary
access, it's the exception record and

the review date. For service quality, it
may be support incidents or an

agreed acceptance measure.

Make sure those records cover the same
service and period. A current invoice

and last month's assignment export don't
describe one current position just

because they are next to each other in a
workbook.

Be careful with the meaning of usage too.
An account that hasn't signed in

recently may belong to someone on leave,
an occasional specialist or a

recovery arrangement. Low activity is a
reason to investigate the

requirement. It isn't, by itself,
authorization to withdraw access.

Ask the service owner what evidence would
establish that the

assignment is unnecessary.

You also need to know whether the evidence
arrived. If the weekly export

stops updating, the last good count can
remain reassuringly visible. Record

when the data was refreshed and what
happens when the expected

refresh is missing.

For our fictional service, I would review
the assignment changes weekly

during the initial handover period, using
the existing service review. That

frequency is a case-specific
recommendation, not a benchmark

for every application.

The review should look ahead to approved
demand. With four seats available,

how many people need access before the
next purchase could take effect?

Procurement lead time matters. Waiting
until capacity reaches zero leaves

very little room to distinguish a real
shortage from a bad assignment rule.

The trigger therefore needs a response
deadline. If expected demand will

exceed available capacity before
procurement can respond, the service owner

investigates now. If an exception reaches
its review date without a decision,

it goes to its accountable owner. If
service quality deteriorates after

recovery, the change owner checks whether
the reduction contributed.

That is more useful than making every
number turn red at the same percentage.

The FinOps Foundation's Usage Optimization
guidance makes room for this

judgment. It considers performance,
availability and business value alongside

cost, and calls for attention to usage
over time. It doesn't make the lowest

possible consumption the universal
objective.

For this case, my practical translation is
straightforward: preserve the

service the business intended to buy, and
keep testing the assumptions that

determine how much of it you need.

Let's take a quick break. If you're
working out who owns these checks and

where they belong in the working week, my
Roles and Operating Cadence

resource in the Operational ITAM Store is
relevant. It includes role

charters, authority boundaries, and a
workbook covering service catalog,

assignments, cadence and workload.

Use it to make the responsibilities
explicit and fit the work to the people

who will actually do it. Today's exercise
also works with the records you

already have. You don't need to buy
anything to start.

Visit operationalitam.com for the podcast,
transcripts and practical

resources. If this episode would help
someone who inherits the work after

projects close, send it their way.

Alright. Back to our service owner and the
request for fifty more seats.

There are two places to look: the current
assignments and the process that

creates them. Correcting only the current
list leaves the same problem

waiting for the next intake.

Microsoft provides a useful real-world
mechanism here. Its documentation

describes assigning licenses through
groups. It also warns that moving users

between licensed groups in the wrong order
can interrupt service while the

new assignment processes. The recommended
sequence includes confirming the

new license before removing the old group
membership.

The lesson I draw is to inspect the
assignment path and verify the resulting

service, rather than judging the change by
the administrative action alone.

That applies to our fictional template
too. Test what the next eligible user

receives, and check that required access
still works.

This is not a claim that Microsoft
licenses automatically cost less when you

remove an assignment. The purchased
subscription and the assignment are

different records. Your agreement
determines the commercial options, and the

service owner needs to understand the
operational consequences.

In our case, suppose the reviews establish
that the twenty-eight template

assignments and the twelve temporary
assignments are unnecessary. Authorized

changes remove them safely, and the team
verifies the result.

Four hundred forty-six minus forty leaves
four hundred six assigned seats.

The eighteen legitimate additions stay.
The purchased quantity remains four

hundred fifty, leaving forty-four seats
available.

There is no new invoice reduction. There
is restored capacity inside the

existing purchase. We also haven't proved
that the requested additional fifty

seats would otherwise have been bought.
Don't turn that unapproved request

into a fresh savings claim.

Keep the original verified result on its
original record. Describe this

follow-up as correcting assignments and
restoring capacity. If a later

purchasing decision produces a financial
change, document that separately

with its own evidence.

Now close the issue properly. The removal
ticket is part of the evidence.

So is the corrected template. So is a
check of subsequent provisioning and

service access. The owner records the
outcome and the next review date.

There is still a question about the
control itself. Why did the change miss

the template? Perhaps the project handover
covered the application

administrator but not the onboarding
owner. Fix that handoff while the cause

is visible. Otherwise the next recovery
project will have the same

conversation with a newer spreadsheet.

The review also needs to allow for a less
tidy ending. Suppose the temporary

project continues, or the twenty-eight
people now require the application

because their jobs changed. In that case,
the assignments may stay.

Bring the new evidence to the person
authorized to accept the changed scope

and cost. Preserve the old baseline, then
record the revised expectation and

effective date. You should be able to
explain both the original decision and

why today's requirement is different.

Changing a forecast after an authorized
business change is sensible. Quietly

changing it to make unexplained growth
disappear removes the comparison you

needed to investigate.

The FinOps Foundation's Anomaly Management
guidance supports that

distinction. An anomaly is an unexpected
departure from a spending pattern.

Investigation can lead to a change in the
environment, a revised cost

expectation, or a documented explanation.
An anticipated business launch can

trigger an alert without representing
waste.

So give the reviewer permission to
conclude that the demand is legitimate. If

every alert must produce a reduction,
you're rewarding the wrong answer

whenever the business has a sound reason
to grow.

You also need to understand what an alert
can see, and when it sees it.

Amazon Web Services documents that its
Cost Anomaly Detection service relies

on Cost Explorer data with a delay of up
to twenty-four hours. That is a

useful cost signal, but it is not an
immediate observation of

every resource change.

My recommendation is to match the control
to the time available to act. A

billing alert may support investigation. A
rapidly growing workload may also

need operational monitoring and an
approved response closer to the activity.

Don't describe a delayed billing signal as
a guaranteed spending stop.

Nor should every unexpected change trigger
an automatic shutdown. Some

services support customers, payroll or
recovery arrangements. The response

should reflect the service's purpose and
the authority of the person or

system taking action.

In practical terms, the alert needs a
destination that survives staff

changes. Name the responsible role, the
current person and the backup route.

Someone being on leave should not suspend
the business's ability to

make a decision.

The person investigating doesn't need
authority to approve every possible

outcome. They need to know what they may
correct within an existing approval,

and what must return to the decision
owner. That is episode fifteen's

authority boundary doing useful work after
the meeting.

For our service, fixing an assignment
template within an approved role design

may be an operational change. Accepting
higher recurring demand or purchasing

more capacity may require a different
approval. Keep those routes clear

enough that people can use them under time
pressure.

Then watch whether the review process is
worth its effort.

If the team spends the entire meeting
dismissing predictable alerts, examine

the thresholds, scope and expected
business events. If a supposed exception

needs the same approval every month, ask
whether it is still temporary. If

every issue gets escalated, check whether
the reviewer has

any usable authority.

My preference is to record the disposition
of the meaningful issues: what

changed, who decided, what happened and
whether the check found it early

enough. That gives you evidence for
simplifying the process as well

as strengthening it.

After a stable period, the service owner
may move the review to a less

frequent cycle, provided it still leaves
time to respond. A material change

in demand, a new provisioning path or an
approaching commitment deadline can

justify closer attention again.

The balance matters. Constant review has a
cost. So does discovering, just

before renewal, that the operating
assumptions have been wrong for months.

This approach also travels beyond
software. Imagine a hardware team that has

improved its pool of spare laptops. A low
spare count could mean successful

redeployment, delayed returns or devices
waiting for repair. Buying more

addresses one possible consequence, but it
doesn't tell you which

process needs attention.

My recommendation would be to connect the
stock position to expected

arrivals, confirmed returns and the time
needed to make a device ready for

use. Keep the service requirement visible.
The point of recovering equipment

is to support the next person who needs
it, with an appropriate device, when

they need it.

The same discipline applies when
responsibility crosses departments.

Suppose one team reduces its subscription
spend by moving the work to a

service paid for elsewhere. That may be a
sound business choice. But the

original cost center's lower bill is not
enough to establish the continuing

organization-wide outcome. Ask the
receiving owner what demand arrived and

what changed as a result.

You don't need to reconstruct the entire
enterprise every week. Define the

boundary of the decision at hand and
include the material dependencies. If

the result relies on another team
absorbing work, that team belongs in the

evidence and the handover.

At the next management review, make that
visible in a short update. State

whether the intended outcome still holds,
which condition changed and what

decision is needed. If the evidence is
missing, say the position is

unconfirmed and give the recovery action.
An empty field should not quietly

inherit last month's green status.

That kind of update lets leadership
distinguish a working service that needs

more capacity from a process that is
recreating unnecessary demand. It

also makes the owner's request much easier
to evaluate.

And occasionally, the original improvement
will no longer be worth

preserving. The business may need a
different service, a larger capacity

buffer or a higher level of support. The
owner should bring forward that

evidence and change the decision when
appropriate.

Keeping the result means preserving its
intended value while conditions

change. It doesn't mean defending an old
quantity indefinitely.

Which brings us to today's principle:
stewardship.

Someone has to carry the decision into
ordinary operations, notice when its

assumptions weaken, and arrange the next
action. That work deserves a place

in the workload and a clear transfer when
the owner changes.

In our fictional case, the first saving
was real. The later demand contained

both valid growth and avoidable
assignments. The review protected service,

corrected the assignment path and
clarified the capacity position. Those are

useful outcomes even though the invoice
didn't fall again.

Class dismissed. Here's your homework. Set
aside about an hour and use

records you're already authorized to
access.

Choose one completed technology change
with an outcome that has already been

checked. Write down that outcome and the
date of the evidence. Keep the

purchased quantity, assigned quantity and
business requirement separate

wherever they apply.

Identify a condition that could undo the
improvement. Find the record that

would reveal the change, note how current
it is, and name the person who can

explain it. Then write the trigger for
review, the response deadline and the

route to someone authorized to decide.

Check the last issue that followed that
route. Was the cause corrected, the

result verified and the decision recorded?
If you can't find an example, mark

the control untested. Don't mark it
effective just because

the procedure exists.

Finally, put the check into an existing
operating rhythm and confirm who

inherits it when the current owner moves
on.

You'll find Roles and Operating Cadence in
the Operational ITAM Store at

operationalitam.com. The show notes
include the source references and

the resource link.

As we continue at The Decision Table, keep
asking where an apparently

finished decision still depends on
somebody doing the next piece of work.

Those handoffs give us plenty to examine.

The case files are open. One situation,
one page. Tell me 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. Check the changed

conditions. Keep the review useful. Leave
the next owner a clear record.

I'll talk to you next week. Take care.