1 00:00:08,000 --> 00:00:12,355 Hey everybody, and welcome back to the Operational ITAM Podcast. I'm 2 00:00:12,380 --> 00:00:16,145 Bill Van Nort, and today we're going back to a project that was finished. 3 00:00:16,670 --> 00:00:21,290 The change went through. The invoice came down. Finance checked the result, 4 00:00:21,590 --> 00:00:24,685 the project manager closed the work, and everybody moved on 5 00:00:24,710 --> 00:00:25,615 to something else. 6 00:00:26,370 --> 00:00:29,055 Six weeks later, someone asks for more licenses. 7 00:00:29,890 --> 00:00:33,965 That might be perfectly reasonable. The business could be hiring. A new 8 00:00:33,990 --> 00:00:38,285 customer could need support. A service you deliberately kept small could have 9 00:00:38,310 --> 00:00:39,255 become more useful. 10 00:00:39,870 --> 00:00:43,585 Or the old onboarding process could still be handing out the licenses you 11 00:00:43,610 --> 00:00:45,455 just spent a month trying to recover. 12 00:00:46,170 --> 00:00:50,705 The invoice won't necessarily tell you which explanation is right. For a 13 00:00:50,730 --> 00:00:52,955 while, the invoice might not change at all. 14 00:00:53,610 --> 00:00:56,775 Today, at The Decision Table: Keep the Result. 15 00:01:15,490 --> 00:01:18,865 Good morning, good afternoon, or good evening, wherever you're listening 16 00:01:18,890 --> 00:01:23,205 from. This is the show where we take the unglamorous machinery of enterprise 17 00:01:23,230 --> 00:01:26,655 technology and make it make sense. Grab your coffee. 18 00:01:27,190 --> 00:01:31,290 In episode fifteen, we worked through who owns a decision when procurement, 19 00:01:31,650 --> 00:01:36,185 finance, technology teams and the business have different answers. We gave 20 00:01:36,210 --> 00:01:39,175 the decision an owner, conditions and follow-through. 21 00:01:39,830 --> 00:01:44,225 Today starts after the initial result has been checked. We're asking what has 22 00:01:44,250 --> 00:01:47,905 to remain true for that result to last, and what should happen when 23 00:01:47,930 --> 00:01:49,055 those conditions change. 24 00:01:49,770 --> 00:01:54,225 My opinion, clearly labeled: the work that preserves a result should be 25 00:01:54,250 --> 00:01:58,685 designed before the project team leaves. A successful change deserves a 26 00:01:58,710 --> 00:02:02,345 usable handover, including the evidence that would tell its new owner 27 00:02:02,370 --> 00:02:03,275 to pay attention. 28 00:02:03,930 --> 00:02:08,625 The counterargument is reasonable. Teams already have enough reporting. Every 29 00:02:08,650 --> 00:02:13,485 completed project cannot become another permanent meeting. I agree. The 30 00:02:13,510 --> 00:02:17,590 answer has to fit the decision's exposure and the time available to respond. 31 00:02:18,570 --> 00:02:21,835 Sometimes that means a short exception review in a meeting you already have. 32 00:02:22,410 --> 00:02:26,645 Let's work through a fictional software service. The company, quantities and 33 00:02:26,670 --> 00:02:31,665 prices are invented. This isn't a client case or a vendor offer. All amounts 34 00:02:31,690 --> 00:02:32,715 are U.S. dollars. 35 00:02:33,310 --> 00:02:37,485 Our company previously bought five hundred fifty seats at twenty dollars per 36 00:02:37,510 --> 00:02:41,665 seat per month. It completed an approved reduction to four hundred fifty 37 00:02:41,690 --> 00:02:46,465 seats, at the same price. Assume its agreement permitted that change, and the 38 00:02:46,490 --> 00:02:49,255 effective date and first full invoice were verified. 39 00:02:49,870 --> 00:02:53,645 The monthly subscription charge went from eleven thousand dollars to nine 40 00:02:53,670 --> 00:02:58,465 thousand. That first month's two thousand dollar reduction is documented. We 41 00:02:58,490 --> 00:03:01,775 aren't extending it across a year and calling the future collected. 42 00:03:02,310 --> 00:03:07,045 On the handover date, four hundred seats were assigned. Fifty purchased seats 43 00:03:07,070 --> 00:03:11,585 remained available. The service owner deliberately retained that capacity for 44 00:03:11,610 --> 00:03:15,625 expected demand. Whether fifty was the right allowance was part of 45 00:03:15,650 --> 00:03:16,575 the approved decision. 46 00:03:17,290 --> 00:03:21,825 Write those facts down separately. Four hundred fifty purchased. Four hundred 47 00:03:21,850 --> 00:03:26,705 assigned. Fifty available. One dated position, with a reason 48 00:03:26,730 --> 00:03:27,475 for the difference. 49 00:03:28,050 --> 00:03:31,345 Now move forward six weeks. Assigned seats have reached four hundred 50 00:03:31,370 --> 00:03:36,385 forty-six. The subscription still includes four hundred fifty. The 51 00:03:36,410 --> 00:03:38,435 invoice remains nine thousand dollars. 52 00:03:38,990 --> 00:03:43,765 From the bill alone, everything looks fine. From the capacity position, four 53 00:03:43,790 --> 00:03:48,195 seats remain. Someone preparing the next intake requests another fifty. 54 00:03:48,710 --> 00:03:52,935 Before buying or removing anything, the service owner asks what changed. 55 00:03:53,970 --> 00:03:56,845 Eighteen of the additional assignments support an approved business 56 00:03:56,870 --> 00:04:02,085 expansion. The employees need the service, the demand is documented, and the 57 00:04:02,110 --> 00:04:05,195 people approving the expansion understood the operating cost. 58 00:04:05,970 --> 00:04:09,985 The other twenty-eight came through an old onboarding template. The new role 59 00:04:10,010 --> 00:04:14,270 design did not require this application, but the template still assigned it. 60 00:04:14,690 --> 00:04:18,885 The recovery project changed existing accounts and missed the path used to 61 00:04:18,910 --> 00:04:19,735 create new ones. 62 00:04:20,290 --> 00:04:24,945 There's also a separate issue. Twelve temporary assignments, already included 63 00:04:24,970 --> 00:04:29,305 in the original four hundred, have passed their review date. The associated 64 00:04:29,330 --> 00:04:32,825 project has ended, but nobody has confirmed whether those people 65 00:04:32,850 --> 00:04:33,875 still need access. 66 00:04:34,690 --> 00:04:38,805 Those twelve did not cause the increase of forty-six. They are a different 67 00:04:38,830 --> 00:04:42,945 question inside the current total. Keep that distinction clear or your 68 00:04:42,970 --> 00:04:46,735 reconciliation will create more confusion than the report that started it. 69 00:04:47,190 --> 00:04:51,505 We now have legitimate growth, an outdated assignment rule and an overdue 70 00:04:51,530 --> 00:04:56,225 review. A single instruction to cut licenses would treat all three as 71 00:04:56,250 --> 00:04:57,180 the same problem. 72 00:04:57,190 --> 00:04:59,445 They need different responses. 73 00:05:00,140 --> 00:05:04,220 For the eighteen approved assignments, record the demand and its authority. 74 00:05:04,880 --> 00:05:08,395 Update the forecast if the expansion changes the expected pace of 75 00:05:08,420 --> 00:05:12,575 consumption. There is no reason to make those employees defend a business 76 00:05:12,600 --> 00:05:15,345 decision that has already been properly authorized. 77 00:05:15,920 --> 00:05:19,695 For the twenty-eight template assignments, confirm the role requirements with 78 00:05:19,720 --> 00:05:23,675 the service owner. If the assignments are unnecessary, correct the 79 00:05:23,700 --> 00:05:27,995 provisioning rule and plan safe removal from the affected accounts. Check 80 00:05:28,020 --> 00:05:30,405 dependencies and required access first. 81 00:05:31,140 --> 00:05:35,000 For the twelve temporary assignments, return to the owner of the exception. 82 00:05:35,740 --> 00:05:39,975 Has the need ended, or has the work changed? Settle that question before 83 00:05:40,000 --> 00:05:45,295 changing access. An expired review date tells you a decision is overdue. It 84 00:05:45,320 --> 00:05:47,965 does not establish that removing a service is safe. 85 00:05:48,580 --> 00:05:51,935 This is why I would preserve a little more than the saving in the project 86 00:05:51,960 --> 00:05:56,735 handover. Keep the approved scope, the relevant quantities, the reason for 87 00:05:56,760 --> 00:06:00,545 spare capacity and the conditions that might require a new decision. 88 00:06:01,180 --> 00:06:04,925 Then connect each condition to evidence somebody can actually retrieve. 89 00:06:05,580 --> 00:06:10,075 For assignment growth, that might be a dated export, the approved intake and 90 00:06:10,100 --> 00:06:14,515 the provisioning record. For temporary access, it's the exception record and 91 00:06:14,540 --> 00:06:18,835 the review date. For service quality, it may be support incidents or an 92 00:06:18,860 --> 00:06:20,065 agreed acceptance measure. 93 00:06:20,480 --> 00:06:24,955 Make sure those records cover the same service and period. A current invoice 94 00:06:24,980 --> 00:06:29,215 and last month's assignment export don't describe one current position just 95 00:06:29,240 --> 00:06:31,325 because they are next to each other in a workbook. 96 00:06:32,020 --> 00:06:36,155 Be careful with the meaning of usage too. An account that hasn't signed in 97 00:06:36,180 --> 00:06:40,595 recently may belong to someone on leave, an occasional specialist or a 98 00:06:40,620 --> 00:06:44,655 recovery arrangement. Low activity is a reason to investigate the 99 00:06:44,680 --> 00:06:49,160 requirement. It isn't, by itself, authorization to withdraw access. 100 00:06:49,920 --> 00:06:52,695 Ask the service owner what evidence would establish that the 101 00:06:52,720 --> 00:06:53,905 assignment is unnecessary. 102 00:06:54,720 --> 00:06:58,735 You also need to know whether the evidence arrived. If the weekly export 103 00:06:58,760 --> 00:07:03,915 stops updating, the last good count can remain reassuringly visible. Record 104 00:07:03,940 --> 00:07:07,215 when the data was refreshed and what happens when the expected 105 00:07:07,240 --> 00:07:08,345 refresh is missing. 106 00:07:09,000 --> 00:07:12,555 For our fictional service, I would review the assignment changes weekly 107 00:07:12,580 --> 00:07:17,415 during the initial handover period, using the existing service review. That 108 00:07:17,440 --> 00:07:20,935 frequency is a case-specific recommendation, not a benchmark 109 00:07:20,960 --> 00:07:22,125 for every application. 110 00:07:22,880 --> 00:07:27,060 The review should look ahead to approved demand. With four seats available, 111 00:07:27,500 --> 00:07:30,940 how many people need access before the next purchase could take effect? 112 00:07:31,620 --> 00:07:36,215 Procurement lead time matters. Waiting until capacity reaches zero leaves 113 00:07:36,240 --> 00:07:40,245 very little room to distinguish a real shortage from a bad assignment rule. 114 00:07:40,720 --> 00:07:45,195 The trigger therefore needs a response deadline. If expected demand will 115 00:07:45,220 --> 00:07:49,655 exceed available capacity before procurement can respond, the service owner 116 00:07:49,680 --> 00:07:54,480 investigates now. If an exception reaches its review date without a decision, 117 00:07:54,820 --> 00:07:59,095 it goes to its accountable owner. If service quality deteriorates after 118 00:07:59,120 --> 00:08:02,565 recovery, the change owner checks whether the reduction contributed. 119 00:08:03,080 --> 00:08:07,285 That is more useful than making every number turn red at the same percentage. 120 00:08:07,960 --> 00:08:12,015 The FinOps Foundation's Usage Optimization guidance makes room for this 121 00:08:12,040 --> 00:08:16,955 judgment. It considers performance, availability and business value alongside 122 00:08:16,980 --> 00:08:22,155 cost, and calls for attention to usage over time. It doesn't make the lowest 123 00:08:22,180 --> 00:08:24,685 possible consumption the universal objective. 124 00:08:25,360 --> 00:08:29,715 For this case, my practical translation is straightforward: preserve the 125 00:08:29,740 --> 00:08:33,555 service the business intended to buy, and keep testing the assumptions that 126 00:08:33,580 --> 00:08:35,305 determine how much of it you need. 127 00:08:41,900 --> 00:08:45,995 Let's take a quick break. If you're working out who owns these checks and 128 00:08:46,020 --> 00:08:49,615 where they belong in the working week, my Roles and Operating Cadence 129 00:08:49,640 --> 00:08:53,895 resource in the Operational ITAM Store is relevant. It includes role 130 00:08:53,920 --> 00:08:57,900 charters, authority boundaries, and a workbook covering service catalog, 131 00:08:58,320 --> 00:09:00,325 assignments, cadence and workload. 132 00:09:00,980 --> 00:09:04,975 Use it to make the responsibilities explicit and fit the work to the people 133 00:09:05,000 --> 00:09:09,235 who will actually do it. Today's exercise also works with the records you 134 00:09:09,260 --> 00:09:12,265 already have. You don't need to buy anything to start. 135 00:09:12,800 --> 00:09:17,615 Visit operationalitam.com for the podcast, transcripts and practical 136 00:09:17,640 --> 00:09:21,875 resources. If this episode would help someone who inherits the work after 137 00:09:21,900 --> 00:09:24,005 projects close, send it their way. 138 00:09:30,560 --> 00:09:34,305 Alright. Back to our service owner and the request for fifty more seats. 139 00:09:35,060 --> 00:09:39,175 There are two places to look: the current assignments and the process that 140 00:09:39,200 --> 00:09:43,575 creates them. Correcting only the current list leaves the same problem 141 00:09:43,600 --> 00:09:44,930 waiting for the next intake. 142 00:09:44,940 --> 00:09:50,295 Microsoft provides a useful real-world mechanism here. Its documentation 143 00:09:50,320 --> 00:09:55,455 describes assigning licenses through groups. It also warns that moving users 144 00:09:55,480 --> 00:09:59,515 between licensed groups in the wrong order can interrupt service while the 145 00:09:59,540 --> 00:10:03,875 new assignment processes. The recommended sequence includes confirming the 146 00:10:03,900 --> 00:10:06,825 new license before removing the old group membership. 147 00:10:07,170 --> 00:10:11,385 The lesson I draw is to inspect the assignment path and verify the resulting 148 00:10:11,410 --> 00:10:15,550 service, rather than judging the change by the administrative action alone. 149 00:10:16,270 --> 00:10:20,485 That applies to our fictional template too. Test what the next eligible user 150 00:10:20,510 --> 00:10:23,475 receives, and check that required access still works. 151 00:10:24,070 --> 00:10:28,285 This is not a claim that Microsoft licenses automatically cost less when you 152 00:10:28,310 --> 00:10:32,165 remove an assignment. The purchased subscription and the assignment are 153 00:10:32,190 --> 00:10:36,605 different records. Your agreement determines the commercial options, and the 154 00:10:36,630 --> 00:10:39,575 service owner needs to understand the operational consequences. 155 00:10:40,270 --> 00:10:43,905 In our case, suppose the reviews establish that the twenty-eight template 156 00:10:43,930 --> 00:10:48,505 assignments and the twelve temporary assignments are unnecessary. Authorized 157 00:10:48,530 --> 00:10:52,035 changes remove them safely, and the team verifies the result. 158 00:10:52,930 --> 00:10:57,030 Four hundred forty-six minus forty leaves four hundred six assigned seats. 159 00:10:57,670 --> 00:11:01,645 The eighteen legitimate additions stay. The purchased quantity remains four 160 00:11:01,670 --> 00:11:04,595 hundred fifty, leaving forty-four seats available. 161 00:11:05,230 --> 00:11:10,085 There is no new invoice reduction. There is restored capacity inside the 162 00:11:10,110 --> 00:11:14,525 existing purchase. We also haven't proved that the requested additional fifty 163 00:11:14,550 --> 00:11:18,545 seats would otherwise have been bought. Don't turn that unapproved request 164 00:11:18,570 --> 00:11:20,175 into a fresh savings claim. 165 00:11:20,650 --> 00:11:25,165 Keep the original verified result on its original record. Describe this 166 00:11:25,190 --> 00:11:29,905 follow-up as correcting assignments and restoring capacity. If a later 167 00:11:29,930 --> 00:11:33,945 purchasing decision produces a financial change, document that separately 168 00:11:33,970 --> 00:11:35,080 with its own evidence. 169 00:11:35,090 --> 00:11:39,910 Now close the issue properly. The removal ticket is part of the evidence. 170 00:11:40,590 --> 00:11:44,485 So is the corrected template. So is a check of subsequent provisioning and 171 00:11:44,510 --> 00:11:48,715 service access. The owner records the outcome and the next review date. 172 00:11:49,370 --> 00:11:53,525 There is still a question about the control itself. Why did the change miss 173 00:11:53,550 --> 00:11:57,245 the template? Perhaps the project handover covered the application 174 00:11:57,270 --> 00:12:01,985 administrator but not the onboarding owner. Fix that handoff while the cause 175 00:12:02,010 --> 00:12:05,865 is visible. Otherwise the next recovery project will have the same 176 00:12:05,890 --> 00:12:07,875 conversation with a newer spreadsheet. 177 00:12:08,570 --> 00:12:13,465 The review also needs to allow for a less tidy ending. Suppose the temporary 178 00:12:13,490 --> 00:12:17,705 project continues, or the twenty-eight people now require the application 179 00:12:17,730 --> 00:12:21,855 because their jobs changed. In that case, the assignments may stay. 180 00:12:22,570 --> 00:12:26,185 Bring the new evidence to the person authorized to accept the changed scope 181 00:12:26,210 --> 00:12:31,505 and cost. Preserve the old baseline, then record the revised expectation and 182 00:12:31,530 --> 00:12:36,085 effective date. You should be able to explain both the original decision and 183 00:12:36,110 --> 00:12:37,995 why today's requirement is different. 184 00:12:38,670 --> 00:12:43,245 Changing a forecast after an authorized business change is sensible. Quietly 185 00:12:43,270 --> 00:12:47,365 changing it to make unexplained growth disappear removes the comparison you 186 00:12:47,390 --> 00:12:48,475 needed to investigate. 187 00:12:48,930 --> 00:12:52,445 The FinOps Foundation's Anomaly Management guidance supports that 188 00:12:52,470 --> 00:12:57,005 distinction. An anomaly is an unexpected departure from a spending pattern. 189 00:12:57,030 --> 00:13:01,385 Investigation can lead to a change in the environment, a revised cost 190 00:13:01,410 --> 00:13:06,625 expectation, or a documented explanation. An anticipated business launch can 191 00:13:06,650 --> 00:13:08,935 trigger an alert without representing waste. 192 00:13:09,490 --> 00:13:13,885 So give the reviewer permission to conclude that the demand is legitimate. If 193 00:13:13,910 --> 00:13:17,985 every alert must produce a reduction, you're rewarding the wrong answer 194 00:13:18,010 --> 00:13:20,415 whenever the business has a sound reason to grow. 195 00:13:20,970 --> 00:13:25,435 You also need to understand what an alert can see, and when it sees it. 196 00:13:26,030 --> 00:13:30,105 Amazon Web Services documents that its Cost Anomaly Detection service relies 197 00:13:30,130 --> 00:13:34,985 on Cost Explorer data with a delay of up to twenty-four hours. That is a 198 00:13:35,010 --> 00:13:38,645 useful cost signal, but it is not an immediate observation of 199 00:13:38,670 --> 00:13:39,975 every resource change. 200 00:13:40,570 --> 00:13:45,225 My recommendation is to match the control to the time available to act. A 201 00:13:45,250 --> 00:13:49,985 billing alert may support investigation. A rapidly growing workload may also 202 00:13:50,010 --> 00:13:54,150 need operational monitoring and an approved response closer to the activity. 203 00:13:54,850 --> 00:13:58,675 Don't describe a delayed billing signal as a guaranteed spending stop. 204 00:13:59,270 --> 00:14:03,645 Nor should every unexpected change trigger an automatic shutdown. Some 205 00:14:03,670 --> 00:14:08,445 services support customers, payroll or recovery arrangements. The response 206 00:14:08,470 --> 00:14:12,185 should reflect the service's purpose and the authority of the person or 207 00:14:12,210 --> 00:14:13,395 system taking action. 208 00:14:13,950 --> 00:14:17,825 In practical terms, the alert needs a destination that survives staff 209 00:14:17,850 --> 00:14:22,990 changes. Name the responsible role, the current person and the backup route. 210 00:14:23,550 --> 00:14:26,845 Someone being on leave should not suspend the business's ability to 211 00:14:26,870 --> 00:14:27,575 make a decision. 212 00:14:28,090 --> 00:14:32,005 The person investigating doesn't need authority to approve every possible 213 00:14:32,030 --> 00:14:36,245 outcome. They need to know what they may correct within an existing approval, 214 00:14:36,270 --> 00:14:40,905 and what must return to the decision owner. That is episode fifteen's 215 00:14:40,930 --> 00:14:44,115 authority boundary doing useful work after the meeting. 216 00:14:44,540 --> 00:14:48,865 For our service, fixing an assignment template within an approved role design 217 00:14:48,890 --> 00:14:53,685 may be an operational change. Accepting higher recurring demand or purchasing 218 00:14:53,710 --> 00:14:58,005 more capacity may require a different approval. Keep those routes clear 219 00:14:58,030 --> 00:15:00,395 enough that people can use them under time pressure. 220 00:15:00,970 --> 00:15:03,915 Then watch whether the review process is worth its effort. 221 00:15:04,410 --> 00:15:08,765 If the team spends the entire meeting dismissing predictable alerts, examine 222 00:15:08,790 --> 00:15:13,765 the thresholds, scope and expected business events. If a supposed exception 223 00:15:13,790 --> 00:15:18,665 needs the same approval every month, ask whether it is still temporary. If 224 00:15:18,690 --> 00:15:21,945 every issue gets escalated, check whether the reviewer has 225 00:15:21,970 --> 00:15:23,295 any usable authority. 226 00:15:23,850 --> 00:15:27,985 My preference is to record the disposition of the meaningful issues: what 227 00:15:28,010 --> 00:15:32,465 changed, who decided, what happened and whether the check found it early 228 00:15:32,490 --> 00:15:36,505 enough. That gives you evidence for simplifying the process as well 229 00:15:36,530 --> 00:15:37,440 as strengthening it. 230 00:15:37,450 --> 00:15:41,905 After a stable period, the service owner may move the review to a less 231 00:15:41,930 --> 00:15:46,645 frequent cycle, provided it still leaves time to respond. A material change 232 00:15:46,670 --> 00:15:51,405 in demand, a new provisioning path or an approaching commitment deadline can 233 00:15:51,430 --> 00:15:53,195 justify closer attention again. 234 00:15:53,690 --> 00:15:58,925 The balance matters. Constant review has a cost. So does discovering, just 235 00:15:58,950 --> 00:16:02,775 before renewal, that the operating assumptions have been wrong for months. 236 00:16:03,490 --> 00:16:08,225 This approach also travels beyond software. Imagine a hardware team that has 237 00:16:08,250 --> 00:16:12,805 improved its pool of spare laptops. A low spare count could mean successful 238 00:16:12,830 --> 00:16:18,145 redeployment, delayed returns or devices waiting for repair. Buying more 239 00:16:18,170 --> 00:16:21,785 addresses one possible consequence, but it doesn't tell you which 240 00:16:21,810 --> 00:16:23,135 process needs attention. 241 00:16:23,710 --> 00:16:27,185 My recommendation would be to connect the stock position to expected 242 00:16:27,210 --> 00:16:31,805 arrivals, confirmed returns and the time needed to make a device ready for 243 00:16:31,830 --> 00:16:36,625 use. Keep the service requirement visible. The point of recovering equipment 244 00:16:36,650 --> 00:16:40,985 is to support the next person who needs it, with an appropriate device, when 245 00:16:41,010 --> 00:16:41,635 they need it. 246 00:16:41,990 --> 00:16:45,350 The same discipline applies when responsibility crosses departments. 247 00:16:46,130 --> 00:16:49,945 Suppose one team reduces its subscription spend by moving the work to a 248 00:16:49,970 --> 00:16:54,325 service paid for elsewhere. That may be a sound business choice. But the 249 00:16:54,350 --> 00:16:58,525 original cost center's lower bill is not enough to establish the continuing 250 00:16:58,550 --> 00:17:03,465 organization-wide outcome. Ask the receiving owner what demand arrived and 251 00:17:03,490 --> 00:17:04,815 what changed as a result. 252 00:17:05,410 --> 00:17:09,745 You don't need to reconstruct the entire enterprise every week. Define the 253 00:17:09,770 --> 00:17:14,485 boundary of the decision at hand and include the material dependencies. If 254 00:17:14,510 --> 00:17:18,745 the result relies on another team absorbing work, that team belongs in the 255 00:17:18,770 --> 00:17:20,175 evidence and the handover. 256 00:17:20,770 --> 00:17:25,205 At the next management review, make that visible in a short update. State 257 00:17:25,230 --> 00:17:29,425 whether the intended outcome still holds, which condition changed and what 258 00:17:29,450 --> 00:17:33,445 decision is needed. If the evidence is missing, say the position is 259 00:17:33,470 --> 00:17:38,425 unconfirmed and give the recovery action. An empty field should not quietly 260 00:17:38,450 --> 00:17:40,375 inherit last month's green status. 261 00:17:40,970 --> 00:17:44,765 That kind of update lets leadership distinguish a working service that needs 262 00:17:44,790 --> 00:17:50,005 more capacity from a process that is recreating unnecessary demand. It 263 00:17:50,030 --> 00:17:53,055 also makes the owner's request much easier to evaluate. 264 00:17:53,710 --> 00:17:56,965 And occasionally, the original improvement will no longer be worth 265 00:17:56,990 --> 00:18:01,285 preserving. The business may need a different service, a larger capacity 266 00:18:01,310 --> 00:18:05,605 buffer or a higher level of support. The owner should bring forward that 267 00:18:05,630 --> 00:18:07,995 evidence and change the decision when appropriate. 268 00:18:08,750 --> 00:18:12,185 Keeping the result means preserving its intended value while conditions 269 00:18:12,210 --> 00:18:16,155 change. It doesn't mean defending an old quantity indefinitely. 270 00:18:17,090 --> 00:18:20,015 Which brings us to today's principle: stewardship. 271 00:18:20,510 --> 00:18:24,965 Someone has to carry the decision into ordinary operations, notice when its 272 00:18:24,990 --> 00:18:29,685 assumptions weaken, and arrange the next action. That work deserves a place 273 00:18:29,710 --> 00:18:32,835 in the workload and a clear transfer when the owner changes. 274 00:18:33,550 --> 00:18:38,045 In our fictional case, the first saving was real. The later demand contained 275 00:18:38,070 --> 00:18:42,790 both valid growth and avoidable assignments. The review protected service, 276 00:18:43,050 --> 00:18:47,525 corrected the assignment path and clarified the capacity position. Those are 277 00:18:47,550 --> 00:18:50,575 useful outcomes even though the invoice didn't fall again. 278 00:18:51,190 --> 00:18:55,465 Class dismissed. Here's your homework. Set aside about an hour and use 279 00:18:55,490 --> 00:18:57,795 records you're already authorized to access. 280 00:18:58,490 --> 00:19:02,265 Choose one completed technology change with an outcome that has already been 281 00:19:02,290 --> 00:19:06,805 checked. Write down that outcome and the date of the evidence. Keep the 282 00:19:06,830 --> 00:19:10,645 purchased quantity, assigned quantity and business requirement separate 283 00:19:10,670 --> 00:19:11,755 wherever they apply. 284 00:19:12,410 --> 00:19:16,845 Identify a condition that could undo the improvement. Find the record that 285 00:19:16,870 --> 00:19:21,105 would reveal the change, note how current it is, and name the person who can 286 00:19:21,130 --> 00:19:26,125 explain it. Then write the trigger for review, the response deadline and the 287 00:19:26,150 --> 00:19:28,135 route to someone authorized to decide. 288 00:19:28,710 --> 00:19:32,965 Check the last issue that followed that route. Was the cause corrected, the 289 00:19:32,990 --> 00:19:37,905 result verified and the decision recorded? If you can't find an example, mark 290 00:19:37,930 --> 00:19:41,565 the control untested. Don't mark it effective just because 291 00:19:41,590 --> 00:19:42,735 the procedure exists. 292 00:19:43,470 --> 00:19:47,565 Finally, put the check into an existing operating rhythm and confirm who 293 00:19:47,590 --> 00:19:49,715 inherits it when the current owner moves on. 294 00:19:50,410 --> 00:19:54,845 You'll find Roles and Operating Cadence in the Operational ITAM Store at 295 00:19:54,870 --> 00:19:59,545 operationalitam.com. The show notes include the source references and 296 00:19:59,570 --> 00:20:00,415 the resource link. 297 00:20:00,910 --> 00:20:04,745 As we continue at The Decision Table, keep asking where an apparently 298 00:20:04,770 --> 00:20:08,750 finished decision still depends on somebody doing the next piece of work. 299 00:20:09,390 --> 00:20:11,575 Those handoffs give us plenty to examine. 300 00:20:12,090 --> 00:20:17,070 The case files are open. One situation, one page. Tell me the constraint, 301 00:20:17,350 --> 00:20:21,745 what you did and what happened. Remove company names and sensitive details 302 00:20:21,770 --> 00:20:25,665 before sending it through the website. Send me one worth working, and I'll 303 00:20:25,690 --> 00:20:27,035 build an episode around it. 304 00:20:27,470 --> 00:20:32,305 I'm Bill Van Nort, this is the Operational ITAM Podcast. Check the changed 305 00:20:32,330 --> 00:20:37,190 conditions. Keep the review useful. Leave the next owner a clear record. 306 00:20:37,630 --> 00:20:39,435 I'll talk to you next week. Take care.