Presenting the Case and Following Through
The page is written. The appendix is thick enough to answer anything. You have a slot on Thursday between the marketing dashboard and the car-park resurfacing, and twenty minutes to turn a document into a decision. Most of what goes wrong now goes wrong in the room. Most of what goes wrong after the room goes wrong because nobody wrote anything down once the money was approved.
This article covers both halves. First comes the meeting: what to bring, how to open, and how to answer the objections you will hear. There is an objection-and-answer sheet you can rehearse from. Then comes the follow-through: proposing a pilot the reader can say yes to. The follow-through includes reporting the results back in the same units the case was written in. It also includes keeping the funding alive. That matters when the outage that helped you is a year in the past and nobody remembers why the line exists. This is the last article in our Business Case series and assumes you have the one-page business case in hand.
The Meeting Itself
Bring three things: the page, the appendix, and one number you can say from memory. The page is the agenda. The appendix is the answer to every question, and its job is to stay closed unless asked. The number is the one that will be quoted back to you in six months. For Meridian Parts it was "five hundred and seventy-five hours a year." It was specific enough to remember and defensible enough to survive being remembered.
Open by reading the problem statement aloud, word for word, and then stop. It takes forty seconds. It names the business thing carried, gives a number the room can check, and quotes an outsider. Do not paraphrase it and do not apologize for reading. The paragraph was written to be heard. The room has not read it, whatever the calendar invitation said. Then say "the decision requested is at the bottom of the page" and let them look. The middle of the meeting is now their questions, which is what you want, because a question is a sign the reader is deciding.
Do not bring the vendor. Not to this meeting. Not "just to answer technical questions." A vendor in the room turns a conversation about a problem into a conversation about a product. The reader will, correctly, assume the case was written for the product. Bring the vendor, if at all, to the pilot, where they can be useful.
Do not bring slides either, or if the culture requires them, bring three: the problem statement, the options, the decision requested. Slides invite narration, and narration takes the whole slot. I once presented a transfer case with eleven slides and was asked, at slide four, whether we could "skip to the money part." The money part was slide eleven. We did not reach it.
Silence is not a no. A reader who has finished the page and is looking at the ceiling is doing arithmetic. The worst thing you can do is fill the silence with a feature. Wait. If the silence ends with "what happens if we do nothing?", read option A aloud. If it ends with "can we do a smaller version?", say yes, because that is the pilot and you already wrote it.
The Objections and Honest Answers
An objection, in a budget meeting, is a reasonable question asked by someone whose job is to be skeptical about spending. It is not resistance to be overcome. It is the reader testing whether the case survives contact with their experience. The right answer is the true one, even when the true one weakens your position. A case that concedes a fair point in the room gains more than it loses, because every other answer becomes believable.
The sheet below is the one I rehearse from. Rehearse means saying the answers aloud to a colleague who plays the finance director, ideally one who enjoys it. We make transfer software, so read the "why not free or open source" row with that in mind. The honest answer to it is often "yes, that is the right outcome." A case that cannot say so is not being honest about the options.
| Objection | Honest answer | Do not say |
|---|---|---|
| "Nothing has gone badly wrong. Why now?" | "Something goes wrong about sixty times a year; we absorb it, which is why you have not seen it. The worksheet is the record. The auditor's finding has a date attached, and that date is why now." | "It's only a matter of time." |
| "Can't the scripts just be fixed?" | "Partly, and that is option B on the page. It closes the medium finding and frees about two hundred hours. It cannot give each supplier its own login, so the high finding stays open. If you prefer B, I will do B well." | "The scripts are unmaintainable." |
| "Why not something free or open source?" | "It is in the shortlist, costed the same way. The difference is who maintains it and who we call; the appendix compares them. If the pilot shows the open-source pairing does the job, that is the recommendation." | "Free software isn't really free." |
| "The hours figure seems high." | "Every line came from the scheduler log, the ticket queue, or a four-week tally; the rows are in the appendix. Halve any row you doubt and see whether the case still stands. I think it does." | "If anything, it's an underestimate." |
| "We can't afford it this cycle." | "The pilot fits inside the existing support line, and the up-front cost is administrator time we are already spending on failures. If the full rollout must wait a cycle, the pilot still closes the audit finding on two suppliers and gives us the evidence for next cycle." | "We can't afford not to." |
| "Who will run it? You are already stretched." | "The two of us, using the hours the failures currently take. After the migration, running it is fewer hours than we spend today, and the after column shows where they go." | "It runs itself." |
| "What if the supplier of the tool disappears?" | "The protocols are standard, so the suppliers' side does not change; we would migrate the server and jobs again, roughly the same bump as now. That risk is on the scenario card, rated rare and moderate." | "They're not going anywhere." |
Every answer in the middle column points at something already written down and concedes whatever is true. The "do not say" column is a collection of sentences I have said myself, each of which lost a case. Each is an assertion in place of evidence, and the reader can hear the difference.
Remember: the finance director is not the obstacle. They are doing their job with the information they were given, and your job is to give them better information. Every objection answered with a page number from the appendix is a point scored for the case. Every objection answered with an adjective is a point against it.
Proposing the Pilot
A pilot is a time-boxed trial of the recommended option on a small, real part of the estate. Success is defined in advance in the same units as the case. The pilot is the ask on the page, and it is the thing most rooms will actually approve. That is because it is small, reversible, and funded from a line that already exists. Propose it even if you are confident the full rollout is right. A pilot that succeeds converts the case from an argument into a record.
Scope it so that it touches every leg of the case. Meridian's pilot moved two suppliers (one of the four sharing the password, so the audit finding is tested). It moved the daily purchasing uploads (so the manual-work hours are tested). It also moved one flow that had failed silently twice (so the alerting is tested). The pilot ran for four weeks, with the two administrators. The commercial pairing and the open-source pairing ran against the same two suppliers in the second fortnight. Success was written down before the pilot started: zero silent failures, zero purchasing cleanup hours, per-supplier logins and session logs the auditor would accept.
The mechanics of running a fair trial belong to another series. That includes how to keep the vendors honest and how to score what you saw. The article designing a server trial covers the setup and scoring and deciding the conclusion. For the business case, three rules matter more than the mechanics. Define success before you start, in the case's units. End on the date you said, whatever the result. And never let the pilot become the deployment. "We'll just add the other ten suppliers while we're at it" is how a four-week pilot becomes an unfunded program with no report.
One practical note on funding the pilot from an existing line. If a commercial candidate offers a free trial, the pilot can run without a purchase at all. The trials of Sysax Multi Server and Sysax FTP Automation, for instance, need no credit card. That keeps the pilot inside the administrator hours already budgeted. An open-source candidate has no purchase either. Either way the pilot's cost is hours, which is the unit the case is written in.
Template: The Follow-Up Report
The follow-up report is one paragraph and one small table, sent to the person who approved the pilot on the day it ends. It uses the same units as the case, the same finding numbers, and the same scenario name. So the reader can put it next to the page they approved and see the two match. Here is the skeleton, then Meridian's.
PILOT REPORT: [case title] [date] [author] To: [approver] What we said we would test: [scope: flows, partners, duration, who] What we said success was: [criteria, in the case's units] Result Case said Pilot showed ----------------------------- --------------- ---------------------------- [measure from the case] [figure] [figure, same unit] [measure from the case] [figure] [figure, same unit] [audit finding ref] [open/closed] [status, evidence attached] What did not go to plan: [honestly, in two lines] Which option ran best: [commercial / open-source / fix], because [one line] Decision requested: [full rollout scope, funding line, dates, next report]
PILOT REPORT: SUPPLIER AND DEALER FILE TRANSFERS IT (transfer services)
To: Operations Director
What we said we would test: Two suppliers, the daily purchasing uploads, and the
stock-feed flow that failed silently twice; four
weeks; the two administrators.
What we said success was: Zero silent failures; zero purchasing cleanup hours;
per-supplier logins and session logs the auditor
would accept.
Result Case said Pilot showed
----------------------------- --------------- ----------------------------
Silent failures (4 weeks) about 1 0
Failed jobs needing a person about 5 1 (partner outage; alert at 05:10)
Purchasing upload hours about 10 0 (jobs ran; one file rejected
by validation, correctly)
Administrator hours on pilot about 40 46 (migration ran long, week 1)
Finding 4.2 (high) open closed for 2 of 4 suppliers;
login list and logs attached
Finding 4.5 (medium) open closed for pilot flows; run
history export attached
What did not go to plan: One supplier needed a second week to change their
client settings. Migration estimate was low by 15%.
Which option ran best: Both pairings met the criteria. The commercial
pairing needed fewer administrator hours in week 3;
the open-source pairing needed a script for alerting.
Recommendation unchanged; comparison in appendix.
Decision requested: Approve full rollout of the remaining ten suppliers
and thirty-seven jobs over eight weeks from the
support line, with a quarterly one-paragraph report
in these units thereafter.
Notice the row that went badly. The migration ran fifteen percent over its estimate. The report says so in the table and again in the "did not go to plan" line. A report with no bad news reads as a report with no news. The reader will trust the zero silent failures more because the forty-six hours are next to it.
Reporting Back in the Same Language
The pilot report is the first of many. Once the rollout is approved, the line in the budget needs a short report every quarter, in the same units, from the same person. Use one paragraph. Record failures this quarter and how many needed a human. Include silent failures (which should be zero, and saying zero every quarter is the point). Include hours by role against the after column and the status of the findings. Ten minutes to write, if the scheduler keeps its history and alerts are logged. If it does not, that is a defect in the tool. The article transfer dashboards and reporting covers what a job scheduler should be able to produce for exactly this purpose.
The units matter more than the frequency. A quarterly report that says "the platform is performing well" is a report nobody reads. It has no number the reader can put next to the number they approved. Consider a report that says "twelve failures, all retried automatically, zero silent, purchasing logged two hours against a case estimate of thirty." That report takes fifteen seconds to read. It proves, each quarter, that the thing the money bought is still doing what the page said. That is the whole mechanism by which a budget line acquires a history. A line with a history is a line that survives.
Keeping the Funding When the Crisis Fades
The first article in this series drew the attention curve: flat, a spike at the outage, and a slide back to flat. On that slide, the money approved at the spike is quietly reclaimed. The follow-through is how you stop the slide. The diagram below is the same curve with quarterly reports added. Each report is a small bump. The bumps keep attention above the line at which a budget line gets cut without anyone quite deciding to cut it.
Kestrel Payroll's scheduler was funded the week after a missed bank cutoff, and the pilot went well. Nobody wrote the report. At the next budget round the renewal appeared as a line with no history and no owner. Next to it was a note from the previous year's meeting that said "no transfer incidents this year." The renewal was cut on that basis. From the outside, a control that works and a control that was never needed look identical. The outage returned eleven months later. The administrator re-funded the line the following year with a one-paragraph quarterly report that took ten minutes to write. The administrator has sent it every quarter since, including the quarters when the paragraph says "nothing happened, as designed."
"Nothing happened" is the evidence of success only if someone says so, in writing, with a number. That is the trap the quarterly report exists to avoid. It is the reason the report should go to the person who approved the money rather than into a folder. The budget line also needs a named owner, which after the pilot is you. A line with an owner gets asked "do we still need this?" and can answer. A line without one gets cut in silence. Give it a name in the budget, if it did not have one. That way, next year there is a row to point at rather than a conversation to restart.
Two things happen after the money that the case does not cover. Both decide whether the control keeps closing the finding or quietly stops being used. The first is settling the new service in: monitoring, backups, documentation, the runbook nobody writes until the first restore. The article after the purchase is the checklist. The second is people: the purchasing team who now have a job running for them, and the supplier contacts with a new login. If they are not shown the new path and told why it is easier, they will find the old one. Our training and adoption series is about making the secure path the one people take. Adoption is also a number for the quarterly report: "twelve of twelve suppliers migrated; zero uploads by hand this quarter."
Gotcha: the most dangerous quarter is the one after the rollout finishes. The failures have stopped, the finding is closed, and there is nothing to report except that nothing happened. Report it anyway. A control that is never mentioned is a control that will not be funded twice.
The Whole Series in One Paragraph
File transfer is invisible when it works and blamed on something else when it fails, which is why nobody funds it until it breaks. The way through is translation. Express risk as a likelihood and an impact with a range, from your own estate. Express routine cost as hours by role from your own logs. Quote audit findings in the auditor's words with their signed dates. Those three go on one page, with three options treated fairly and a cost as a shape rather than a spreadsheet. Add a decision requested that a person can answer with yes. You present the page, not the appendix. You answer objections with page numbers. You ask for a pilot. You report back, in the same units, every quarter, for as long as the line exists. That is the entire method, and it works whatever you buy, build, or decide to keep. It starts in why nobody funds file transfer. The worksheet that produces the number you will say from memory is in costing failed jobs and manual work.
Frequently Asked Questions
Should I invite the vendor to the budget meeting?
What if the answer in the meeting is "not this cycle"?
What goes in the quarterly report if nothing went wrong?
The pilot showed the open-source option works. Do I still recommend the commercial one?
From the Sysax team: we build secure file transfer software for Windows. Sysax Multi Server is an FTP, FTPS, SFTP, and HTTPS server. Sysax FTP Automation handles scheduled, scripted transfers. Free trials are on the download page.