WEBVTT 00:00:08.000 --> 00:00:12.355 Hey everybody, and welcome back to the Operational ITAM Podcast. I'm 00:00:12.380 --> 00:00:16.145 Bill Van Nort, and today we're going back to a project that was finished. 00:00:16.670 --> 00:00:21.290 The change went through. The invoice came down. Finance checked the result, 00:00:21.590 --> 00:00:24.685 the project manager closed the work, and everybody moved on 00:00:24.710 --> 00:00:25.615 to something else. 00:00:26.370 --> 00:00:29.055 Six weeks later, someone asks for more licenses. 00:00:29.890 --> 00:00:33.965 That might be perfectly reasonable. The business could be hiring. A new 00:00:33.990 --> 00:00:38.285 customer could need support. A service you deliberately kept small could have 00:00:38.310 --> 00:00:39.255 become more useful. 00:00:39.870 --> 00:00:43.585 Or the old onboarding process could still be handing out the licenses you 00:00:43.610 --> 00:00:45.455 just spent a month trying to recover. 00:00:46.170 --> 00:00:50.705 The invoice won't necessarily tell you which explanation is right. For a 00:00:50.730 --> 00:00:52.955 while, the invoice might not change at all. 00:00:53.610 --> 00:00:56.775 Today, at The Decision Table: Keep the Result. 00:01:15.490 --> 00:01:18.865 Good morning, good afternoon, or good evening, wherever you're listening 00:01:18.890 --> 00:01:23.205 from. This is the show where we take the unglamorous machinery of enterprise 00:01:23.230 --> 00:01:26.655 technology and make it make sense. Grab your coffee. 00:01:27.190 --> 00:01:31.290 In episode fifteen, we worked through who owns a decision when procurement, 00:01:31.650 --> 00:01:36.185 finance, technology teams and the business have different answers. We gave 00:01:36.210 --> 00:01:39.175 the decision an owner, conditions and follow-through. 00:01:39.830 --> 00:01:44.225 Today starts after the initial result has been checked. We're asking what has 00:01:44.250 --> 00:01:47.905 to remain true for that result to last, and what should happen when 00:01:47.930 --> 00:01:49.055 those conditions change. 00:01:49.770 --> 00:01:54.225 My opinion, clearly labeled: the work that preserves a result should be 00:01:54.250 --> 00:01:58.685 designed before the project team leaves. A successful change deserves a 00:01:58.710 --> 00:02:02.345 usable handover, including the evidence that would tell its new owner 00:02:02.370 --> 00:02:03.275 to pay attention. 00:02:03.930 --> 00:02:08.625 The counterargument is reasonable. Teams already have enough reporting. Every 00:02:08.650 --> 00:02:13.485 completed project cannot become another permanent meeting. I agree. The 00:02:13.510 --> 00:02:17.590 answer has to fit the decision's exposure and the time available to respond. 00:02:18.570 --> 00:02:21.835 Sometimes that means a short exception review in a meeting you already have. 00:02:22.410 --> 00:02:26.645 Let's work through a fictional software service. The company, quantities and 00:02:26.670 --> 00:02:31.665 prices are invented. This isn't a client case or a vendor offer. All amounts 00:02:31.690 --> 00:02:32.715 are U.S. dollars. 00:02:33.310 --> 00:02:37.485 Our company previously bought five hundred fifty seats at twenty dollars per 00:02:37.510 --> 00:02:41.665 seat per month. It completed an approved reduction to four hundred fifty 00:02:41.690 --> 00:02:46.465 seats, at the same price. Assume its agreement permitted that change, and the 00:02:46.490 --> 00:02:49.255 effective date and first full invoice were verified. 00:02:49.870 --> 00:02:53.645 The monthly subscription charge went from eleven thousand dollars to nine 00:02:53.670 --> 00:02:58.465 thousand. That first month's two thousand dollar reduction is documented. We 00:02:58.490 --> 00:03:01.775 aren't extending it across a year and calling the future collected. 00:03:02.310 --> 00:03:07.045 On the handover date, four hundred seats were assigned. Fifty purchased seats 00:03:07.070 --> 00:03:11.585 remained available. The service owner deliberately retained that capacity for 00:03:11.610 --> 00:03:15.625 expected demand. Whether fifty was the right allowance was part of 00:03:15.650 --> 00:03:16.575 the approved decision. 00:03:17.290 --> 00:03:21.825 Write those facts down separately. Four hundred fifty purchased. Four hundred 00:03:21.850 --> 00:03:26.705 assigned. Fifty available. One dated position, with a reason 00:03:26.730 --> 00:03:27.475 for the difference. 00:03:28.050 --> 00:03:31.345 Now move forward six weeks. Assigned seats have reached four hundred 00:03:31.370 --> 00:03:36.385 forty-six. The subscription still includes four hundred fifty. The 00:03:36.410 --> 00:03:38.435 invoice remains nine thousand dollars. 00:03:38.990 --> 00:03:43.765 From the bill alone, everything looks fine. From the capacity position, four 00:03:43.790 --> 00:03:48.195 seats remain. Someone preparing the next intake requests another fifty. 00:03:48.710 --> 00:03:52.935 Before buying or removing anything, the service owner asks what changed. 00:03:53.970 --> 00:03:56.845 Eighteen of the additional assignments support an approved business 00:03:56.870 --> 00:04:02.085 expansion. The employees need the service, the demand is documented, and the 00:04:02.110 --> 00:04:05.195 people approving the expansion understood the operating cost. 00:04:05.970 --> 00:04:09.985 The other twenty-eight came through an old onboarding template. The new role 00:04:10.010 --> 00:04:14.270 design did not require this application, but the template still assigned it. 00:04:14.690 --> 00:04:18.885 The recovery project changed existing accounts and missed the path used to 00:04:18.910 --> 00:04:19.735 create new ones. 00:04:20.290 --> 00:04:24.945 There's also a separate issue. Twelve temporary assignments, already included 00:04:24.970 --> 00:04:29.305 in the original four hundred, have passed their review date. The associated 00:04:29.330 --> 00:04:32.825 project has ended, but nobody has confirmed whether those people 00:04:32.850 --> 00:04:33.875 still need access. 00:04:34.690 --> 00:04:38.805 Those twelve did not cause the increase of forty-six. They are a different 00:04:38.830 --> 00:04:42.945 question inside the current total. Keep that distinction clear or your 00:04:42.970 --> 00:04:46.735 reconciliation will create more confusion than the report that started it. 00:04:47.190 --> 00:04:51.505 We now have legitimate growth, an outdated assignment rule and an overdue 00:04:51.530 --> 00:04:56.225 review. A single instruction to cut licenses would treat all three as 00:04:56.250 --> 00:04:57.180 the same problem. 00:04:57.190 --> 00:04:59.445 They need different responses. 00:05:00.140 --> 00:05:04.220 For the eighteen approved assignments, record the demand and its authority. 00:05:04.880 --> 00:05:08.395 Update the forecast if the expansion changes the expected pace of 00:05:08.420 --> 00:05:12.575 consumption. There is no reason to make those employees defend a business 00:05:12.600 --> 00:05:15.345 decision that has already been properly authorized. 00:05:15.920 --> 00:05:19.695 For the twenty-eight template assignments, confirm the role requirements with 00:05:19.720 --> 00:05:23.675 the service owner. If the assignments are unnecessary, correct the 00:05:23.700 --> 00:05:27.995 provisioning rule and plan safe removal from the affected accounts. Check 00:05:28.020 --> 00:05:30.405 dependencies and required access first. 00:05:31.140 --> 00:05:35.000 For the twelve temporary assignments, return to the owner of the exception. 00:05:35.740 --> 00:05:39.975 Has the need ended, or has the work changed? Settle that question before 00:05:40.000 --> 00:05:45.295 changing access. An expired review date tells you a decision is overdue. It 00:05:45.320 --> 00:05:47.965 does not establish that removing a service is safe. 00:05:48.580 --> 00:05:51.935 This is why I would preserve a little more than the saving in the project 00:05:51.960 --> 00:05:56.735 handover. Keep the approved scope, the relevant quantities, the reason for 00:05:56.760 --> 00:06:00.545 spare capacity and the conditions that might require a new decision. 00:06:01.180 --> 00:06:04.925 Then connect each condition to evidence somebody can actually retrieve. 00:06:05.580 --> 00:06:10.075 For assignment growth, that might be a dated export, the approved intake and 00:06:10.100 --> 00:06:14.515 the provisioning record. For temporary access, it's the exception record and 00:06:14.540 --> 00:06:18.835 the review date. For service quality, it may be support incidents or an 00:06:18.860 --> 00:06:20.065 agreed acceptance measure. 00:06:20.480 --> 00:06:24.955 Make sure those records cover the same service and period. A current invoice 00:06:24.980 --> 00:06:29.215 and last month's assignment export don't describe one current position just 00:06:29.240 --> 00:06:31.325 because they are next to each other in a workbook. 00:06:32.020 --> 00:06:36.155 Be careful with the meaning of usage too. An account that hasn't signed in 00:06:36.180 --> 00:06:40.595 recently may belong to someone on leave, an occasional specialist or a 00:06:40.620 --> 00:06:44.655 recovery arrangement. Low activity is a reason to investigate the 00:06:44.680 --> 00:06:49.160 requirement. It isn't, by itself, authorization to withdraw access. 00:06:49.920 --> 00:06:52.695 Ask the service owner what evidence would establish that the 00:06:52.720 --> 00:06:53.905 assignment is unnecessary. 00:06:54.720 --> 00:06:58.735 You also need to know whether the evidence arrived. If the weekly export 00:06:58.760 --> 00:07:03.915 stops updating, the last good count can remain reassuringly visible. Record 00:07:03.940 --> 00:07:07.215 when the data was refreshed and what happens when the expected 00:07:07.240 --> 00:07:08.345 refresh is missing. 00:07:09.000 --> 00:07:12.555 For our fictional service, I would review the assignment changes weekly 00:07:12.580 --> 00:07:17.415 during the initial handover period, using the existing service review. That 00:07:17.440 --> 00:07:20.935 frequency is a case-specific recommendation, not a benchmark 00:07:20.960 --> 00:07:22.125 for every application. 00:07:22.880 --> 00:07:27.060 The review should look ahead to approved demand. With four seats available, 00:07:27.500 --> 00:07:30.940 how many people need access before the next purchase could take effect? 00:07:31.620 --> 00:07:36.215 Procurement lead time matters. Waiting until capacity reaches zero leaves 00:07:36.240 --> 00:07:40.245 very little room to distinguish a real shortage from a bad assignment rule. 00:07:40.720 --> 00:07:45.195 The trigger therefore needs a response deadline. If expected demand will 00:07:45.220 --> 00:07:49.655 exceed available capacity before procurement can respond, the service owner 00:07:49.680 --> 00:07:54.480 investigates now. If an exception reaches its review date without a decision, 00:07:54.820 --> 00:07:59.095 it goes to its accountable owner. If service quality deteriorates after 00:07:59.120 --> 00:08:02.565 recovery, the change owner checks whether the reduction contributed. 00:08:03.080 --> 00:08:07.285 That is more useful than making every number turn red at the same percentage. 00:08:07.960 --> 00:08:12.015 The FinOps Foundation's Usage Optimization guidance makes room for this 00:08:12.040 --> 00:08:16.955 judgment. It considers performance, availability and business value alongside 00:08:16.980 --> 00:08:22.155 cost, and calls for attention to usage over time. It doesn't make the lowest 00:08:22.180 --> 00:08:24.685 possible consumption the universal objective. 00:08:25.360 --> 00:08:29.715 For this case, my practical translation is straightforward: preserve the 00:08:29.740 --> 00:08:33.555 service the business intended to buy, and keep testing the assumptions that 00:08:33.580 --> 00:08:35.305 determine how much of it you need. 00:08:41.900 --> 00:08:45.995 Let's take a quick break. If you're working out who owns these checks and 00:08:46.020 --> 00:08:49.615 where they belong in the working week, my Roles and Operating Cadence 00:08:49.640 --> 00:08:53.895 resource in the Operational ITAM Store is relevant. It includes role 00:08:53.920 --> 00:08:57.900 charters, authority boundaries, and a workbook covering service catalog, 00:08:58.320 --> 00:09:00.325 assignments, cadence and workload. 00:09:00.980 --> 00:09:04.975 Use it to make the responsibilities explicit and fit the work to the people 00:09:05.000 --> 00:09:09.235 who will actually do it. Today's exercise also works with the records you 00:09:09.260 --> 00:09:12.265 already have. You don't need to buy anything to start. 00:09:12.800 --> 00:09:17.615 Visit operationalitam.com for the podcast, transcripts and practical 00:09:17.640 --> 00:09:21.875 resources. If this episode would help someone who inherits the work after 00:09:21.900 --> 00:09:24.005 projects close, send it their way. 00:09:30.560 --> 00:09:34.305 Alright. Back to our service owner and the request for fifty more seats. 00:09:35.060 --> 00:09:39.175 There are two places to look: the current assignments and the process that 00:09:39.200 --> 00:09:43.575 creates them. Correcting only the current list leaves the same problem 00:09:43.600 --> 00:09:44.930 waiting for the next intake. 00:09:44.940 --> 00:09:50.295 Microsoft provides a useful real-world mechanism here. Its documentation 00:09:50.320 --> 00:09:55.455 describes assigning licenses through groups. It also warns that moving users 00:09:55.480 --> 00:09:59.515 between licensed groups in the wrong order can interrupt service while the 00:09:59.540 --> 00:10:03.875 new assignment processes. The recommended sequence includes confirming the 00:10:03.900 --> 00:10:06.825 new license before removing the old group membership. 00:10:07.170 --> 00:10:11.385 The lesson I draw is to inspect the assignment path and verify the resulting 00:10:11.410 --> 00:10:15.550 service, rather than judging the change by the administrative action alone. 00:10:16.270 --> 00:10:20.485 That applies to our fictional template too. Test what the next eligible user 00:10:20.510 --> 00:10:23.475 receives, and check that required access still works. 00:10:24.070 --> 00:10:28.285 This is not a claim that Microsoft licenses automatically cost less when you 00:10:28.310 --> 00:10:32.165 remove an assignment. The purchased subscription and the assignment are 00:10:32.190 --> 00:10:36.605 different records. Your agreement determines the commercial options, and the 00:10:36.630 --> 00:10:39.575 service owner needs to understand the operational consequences. 00:10:40.270 --> 00:10:43.905 In our case, suppose the reviews establish that the twenty-eight template 00:10:43.930 --> 00:10:48.505 assignments and the twelve temporary assignments are unnecessary. Authorized 00:10:48.530 --> 00:10:52.035 changes remove them safely, and the team verifies the result. 00:10:52.930 --> 00:10:57.030 Four hundred forty-six minus forty leaves four hundred six assigned seats. 00:10:57.670 --> 00:11:01.645 The eighteen legitimate additions stay. The purchased quantity remains four 00:11:01.670 --> 00:11:04.595 hundred fifty, leaving forty-four seats available. 00:11:05.230 --> 00:11:10.085 There is no new invoice reduction. There is restored capacity inside the 00:11:10.110 --> 00:11:14.525 existing purchase. We also haven't proved that the requested additional fifty 00:11:14.550 --> 00:11:18.545 seats would otherwise have been bought. Don't turn that unapproved request 00:11:18.570 --> 00:11:20.175 into a fresh savings claim. 00:11:20.650 --> 00:11:25.165 Keep the original verified result on its original record. Describe this 00:11:25.190 --> 00:11:29.905 follow-up as correcting assignments and restoring capacity. If a later 00:11:29.930 --> 00:11:33.945 purchasing decision produces a financial change, document that separately 00:11:33.970 --> 00:11:35.080 with its own evidence. 00:11:35.090 --> 00:11:39.910 Now close the issue properly. The removal ticket is part of the evidence. 00:11:40.590 --> 00:11:44.485 So is the corrected template. So is a check of subsequent provisioning and 00:11:44.510 --> 00:11:48.715 service access. The owner records the outcome and the next review date. 00:11:49.370 --> 00:11:53.525 There is still a question about the control itself. Why did the change miss 00:11:53.550 --> 00:11:57.245 the template? Perhaps the project handover covered the application 00:11:57.270 --> 00:12:01.985 administrator but not the onboarding owner. Fix that handoff while the cause 00:12:02.010 --> 00:12:05.865 is visible. Otherwise the next recovery project will have the same 00:12:05.890 --> 00:12:07.875 conversation with a newer spreadsheet. 00:12:08.570 --> 00:12:13.465 The review also needs to allow for a less tidy ending. Suppose the temporary 00:12:13.490 --> 00:12:17.705 project continues, or the twenty-eight people now require the application 00:12:17.730 --> 00:12:21.855 because their jobs changed. In that case, the assignments may stay. 00:12:22.570 --> 00:12:26.185 Bring the new evidence to the person authorized to accept the changed scope 00:12:26.210 --> 00:12:31.505 and cost. Preserve the old baseline, then record the revised expectation and 00:12:31.530 --> 00:12:36.085 effective date. You should be able to explain both the original decision and 00:12:36.110 --> 00:12:37.995 why today's requirement is different. 00:12:38.670 --> 00:12:43.245 Changing a forecast after an authorized business change is sensible. Quietly 00:12:43.270 --> 00:12:47.365 changing it to make unexplained growth disappear removes the comparison you 00:12:47.390 --> 00:12:48.475 needed to investigate. 00:12:48.930 --> 00:12:52.445 The FinOps Foundation's Anomaly Management guidance supports that 00:12:52.470 --> 00:12:57.005 distinction. An anomaly is an unexpected departure from a spending pattern. 00:12:57.030 --> 00:13:01.385 Investigation can lead to a change in the environment, a revised cost 00:13:01.410 --> 00:13:06.625 expectation, or a documented explanation. An anticipated business launch can 00:13:06.650 --> 00:13:08.935 trigger an alert without representing waste. 00:13:09.490 --> 00:13:13.885 So give the reviewer permission to conclude that the demand is legitimate. If 00:13:13.910 --> 00:13:17.985 every alert must produce a reduction, you're rewarding the wrong answer 00:13:18.010 --> 00:13:20.415 whenever the business has a sound reason to grow. 00:13:20.970 --> 00:13:25.435 You also need to understand what an alert can see, and when it sees it. 00:13:26.030 --> 00:13:30.105 Amazon Web Services documents that its Cost Anomaly Detection service relies 00:13:30.130 --> 00:13:34.985 on Cost Explorer data with a delay of up to twenty-four hours. That is a 00:13:35.010 --> 00:13:38.645 useful cost signal, but it is not an immediate observation of 00:13:38.670 --> 00:13:39.975 every resource change. 00:13:40.570 --> 00:13:45.225 My recommendation is to match the control to the time available to act. A 00:13:45.250 --> 00:13:49.985 billing alert may support investigation. A rapidly growing workload may also 00:13:50.010 --> 00:13:54.150 need operational monitoring and an approved response closer to the activity. 00:13:54.850 --> 00:13:58.675 Don't describe a delayed billing signal as a guaranteed spending stop. 00:13:59.270 --> 00:14:03.645 Nor should every unexpected change trigger an automatic shutdown. Some 00:14:03.670 --> 00:14:08.445 services support customers, payroll or recovery arrangements. The response 00:14:08.470 --> 00:14:12.185 should reflect the service's purpose and the authority of the person or 00:14:12.210 --> 00:14:13.395 system taking action. 00:14:13.950 --> 00:14:17.825 In practical terms, the alert needs a destination that survives staff 00:14:17.850 --> 00:14:22.990 changes. Name the responsible role, the current person and the backup route. 00:14:23.550 --> 00:14:26.845 Someone being on leave should not suspend the business's ability to 00:14:26.870 --> 00:14:27.575 make a decision. 00:14:28.090 --> 00:14:32.005 The person investigating doesn't need authority to approve every possible 00:14:32.030 --> 00:14:36.245 outcome. They need to know what they may correct within an existing approval, 00:14:36.270 --> 00:14:40.905 and what must return to the decision owner. That is episode fifteen's 00:14:40.930 --> 00:14:44.115 authority boundary doing useful work after the meeting. 00:14:44.540 --> 00:14:48.865 For our service, fixing an assignment template within an approved role design 00:14:48.890 --> 00:14:53.685 may be an operational change. Accepting higher recurring demand or purchasing 00:14:53.710 --> 00:14:58.005 more capacity may require a different approval. Keep those routes clear 00:14:58.030 --> 00:15:00.395 enough that people can use them under time pressure. 00:15:00.970 --> 00:15:03.915 Then watch whether the review process is worth its effort. 00:15:04.410 --> 00:15:08.765 If the team spends the entire meeting dismissing predictable alerts, examine 00:15:08.790 --> 00:15:13.765 the thresholds, scope and expected business events. If a supposed exception 00:15:13.790 --> 00:15:18.665 needs the same approval every month, ask whether it is still temporary. If 00:15:18.690 --> 00:15:21.945 every issue gets escalated, check whether the reviewer has 00:15:21.970 --> 00:15:23.295 any usable authority. 00:15:23.850 --> 00:15:27.985 My preference is to record the disposition of the meaningful issues: what 00:15:28.010 --> 00:15:32.465 changed, who decided, what happened and whether the check found it early 00:15:32.490 --> 00:15:36.505 enough. That gives you evidence for simplifying the process as well 00:15:36.530 --> 00:15:37.440 as strengthening it. 00:15:37.450 --> 00:15:41.905 After a stable period, the service owner may move the review to a less 00:15:41.930 --> 00:15:46.645 frequent cycle, provided it still leaves time to respond. A material change 00:15:46.670 --> 00:15:51.405 in demand, a new provisioning path or an approaching commitment deadline can 00:15:51.430 --> 00:15:53.195 justify closer attention again. 00:15:53.690 --> 00:15:58.925 The balance matters. Constant review has a cost. So does discovering, just 00:15:58.950 --> 00:16:02.775 before renewal, that the operating assumptions have been wrong for months. 00:16:03.490 --> 00:16:08.225 This approach also travels beyond software. Imagine a hardware team that has 00:16:08.250 --> 00:16:12.805 improved its pool of spare laptops. A low spare count could mean successful 00:16:12.830 --> 00:16:18.145 redeployment, delayed returns or devices waiting for repair. Buying more 00:16:18.170 --> 00:16:21.785 addresses one possible consequence, but it doesn't tell you which 00:16:21.810 --> 00:16:23.135 process needs attention. 00:16:23.710 --> 00:16:27.185 My recommendation would be to connect the stock position to expected 00:16:27.210 --> 00:16:31.805 arrivals, confirmed returns and the time needed to make a device ready for 00:16:31.830 --> 00:16:36.625 use. Keep the service requirement visible. The point of recovering equipment 00:16:36.650 --> 00:16:40.985 is to support the next person who needs it, with an appropriate device, when 00:16:41.010 --> 00:16:41.635 they need it. 00:16:41.990 --> 00:16:45.350 The same discipline applies when responsibility crosses departments. 00:16:46.130 --> 00:16:49.945 Suppose one team reduces its subscription spend by moving the work to a 00:16:49.970 --> 00:16:54.325 service paid for elsewhere. That may be a sound business choice. But the 00:16:54.350 --> 00:16:58.525 original cost center's lower bill is not enough to establish the continuing 00:16:58.550 --> 00:17:03.465 organization-wide outcome. Ask the receiving owner what demand arrived and 00:17:03.490 --> 00:17:04.815 what changed as a result. 00:17:05.410 --> 00:17:09.745 You don't need to reconstruct the entire enterprise every week. Define the 00:17:09.770 --> 00:17:14.485 boundary of the decision at hand and include the material dependencies. If 00:17:14.510 --> 00:17:18.745 the result relies on another team absorbing work, that team belongs in the 00:17:18.770 --> 00:17:20.175 evidence and the handover. 00:17:20.770 --> 00:17:25.205 At the next management review, make that visible in a short update. State 00:17:25.230 --> 00:17:29.425 whether the intended outcome still holds, which condition changed and what 00:17:29.450 --> 00:17:33.445 decision is needed. If the evidence is missing, say the position is 00:17:33.470 --> 00:17:38.425 unconfirmed and give the recovery action. An empty field should not quietly 00:17:38.450 --> 00:17:40.375 inherit last month's green status. 00:17:40.970 --> 00:17:44.765 That kind of update lets leadership distinguish a working service that needs 00:17:44.790 --> 00:17:50.005 more capacity from a process that is recreating unnecessary demand. It 00:17:50.030 --> 00:17:53.055 also makes the owner's request much easier to evaluate. 00:17:53.710 --> 00:17:56.965 And occasionally, the original improvement will no longer be worth 00:17:56.990 --> 00:18:01.285 preserving. The business may need a different service, a larger capacity 00:18:01.310 --> 00:18:05.605 buffer or a higher level of support. The owner should bring forward that 00:18:05.630 --> 00:18:07.995 evidence and change the decision when appropriate. 00:18:08.750 --> 00:18:12.185 Keeping the result means preserving its intended value while conditions 00:18:12.210 --> 00:18:16.155 change. It doesn't mean defending an old quantity indefinitely. 00:18:17.090 --> 00:18:20.015 Which brings us to today's principle: stewardship. 00:18:20.510 --> 00:18:24.965 Someone has to carry the decision into ordinary operations, notice when its 00:18:24.990 --> 00:18:29.685 assumptions weaken, and arrange the next action. That work deserves a place 00:18:29.710 --> 00:18:32.835 in the workload and a clear transfer when the owner changes. 00:18:33.550 --> 00:18:38.045 In our fictional case, the first saving was real. The later demand contained 00:18:38.070 --> 00:18:42.790 both valid growth and avoidable assignments. The review protected service, 00:18:43.050 --> 00:18:47.525 corrected the assignment path and clarified the capacity position. Those are 00:18:47.550 --> 00:18:50.575 useful outcomes even though the invoice didn't fall again. 00:18:51.190 --> 00:18:55.465 Class dismissed. Here's your homework. Set aside about an hour and use 00:18:55.490 --> 00:18:57.795 records you're already authorized to access. 00:18:58.490 --> 00:19:02.265 Choose one completed technology change with an outcome that has already been 00:19:02.290 --> 00:19:06.805 checked. Write down that outcome and the date of the evidence. Keep the 00:19:06.830 --> 00:19:10.645 purchased quantity, assigned quantity and business requirement separate 00:19:10.670 --> 00:19:11.755 wherever they apply. 00:19:12.410 --> 00:19:16.845 Identify a condition that could undo the improvement. Find the record that 00:19:16.870 --> 00:19:21.105 would reveal the change, note how current it is, and name the person who can 00:19:21.130 --> 00:19:26.125 explain it. Then write the trigger for review, the response deadline and the 00:19:26.150 --> 00:19:28.135 route to someone authorized to decide. 00:19:28.710 --> 00:19:32.965 Check the last issue that followed that route. Was the cause corrected, the 00:19:32.990 --> 00:19:37.905 result verified and the decision recorded? If you can't find an example, mark 00:19:37.930 --> 00:19:41.565 the control untested. Don't mark it effective just because 00:19:41.590 --> 00:19:42.735 the procedure exists. 00:19:43.470 --> 00:19:47.565 Finally, put the check into an existing operating rhythm and confirm who 00:19:47.590 --> 00:19:49.715 inherits it when the current owner moves on. 00:19:50.410 --> 00:19:54.845 You'll find Roles and Operating Cadence in the Operational ITAM Store at 00:19:54.870 --> 00:19:59.545 operationalitam.com. The show notes include the source references and 00:19:59.570 --> 00:20:00.415 the resource link. 00:20:00.910 --> 00:20:04.745 As we continue at The Decision Table, keep asking where an apparently 00:20:04.770 --> 00:20:08.750 finished decision still depends on somebody doing the next piece of work. 00:20:09.390 --> 00:20:11.575 Those handoffs give us plenty to examine. 00:20:12.090 --> 00:20:17.070 The case files are open. One situation, one page. Tell me the constraint, 00:20:17.350 --> 00:20:21.745 what you did and what happened. Remove company names and sensitive details 00:20:21.770 --> 00:20:25.665 before sending it through the website. Send me one worth working, and I'll 00:20:25.690 --> 00:20:27.035 build an episode around it. 00:20:27.470 --> 00:20:32.305 I'm Bill Van Nort, this is the Operational ITAM Podcast. Check the changed 00:20:32.330 --> 00:20:37.190 conditions. Keep the review useful. Leave the next owner a clear record. 00:20:37.630 --> 00:20:39.435 I'll talk to you next week. Take care.