The Decision Table: Keep the Result

The Decision Table: Keep the Result Operational ITAM Podcast | Episode 017 | Bill Van Nort

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.