Business cases for maritime software are rarely rejected on the arithmetic. They are rejected, or approved badly, because of who was asked, in what order, and under which budget line. The research on implementation failure points the same way: insufficient sponsorship is cited as a barrier by around seventy-two percent of organisations and resistance to change by eighty-two, while Gartner attributes the causes of failed enterprise software programmes to absent executive commitment and inadequate investment in change management rather than to anything technical. None of those is a modelling problem. The most consequential decision you will make about your paper is one that has nothing to do with the numbers in it — whether the request is presented as operating expenditure or capital expenditure. Operating expenditure covers routine operational cost and typically sits inside a budget somebody in your building already controls. Capital expenditure covers major investment and asset improvement, usually requires higher-level owner approval, and lands in a queue alongside dry-docking, retrofits and tonnage. Same money, two entirely different journeys, and very different odds. This page is about that journey rather than about the calculation. Start a free trial of Marine Inspection and give yourself something to show before you ask for anything.
Before the number, two questions decide the outcome
Question one
Who can actually approve this?
In a straightforward owner-operator structure it is internal. Under third-party management the manager may request while the owner's policy decides. In a bareboat structure, authority may have shifted to the charterer or its appointed manager entirely. Establishing this first is not administrative — it determines whether the person you are persuading has the power to say yes.
Question two
Is this operating or capital expenditure?
Operating expenditure is recurring cost for running the vessel. Capital expenditure is major spending that improves, upgrades or extends the life of the asset, and owners typically play a stronger role in it. The classification sets the approval path and, more importantly, the set of things your request will be compared against.
Owners commonly define procurement rules for the fleet covering approved vendors, compliance requirements, payment terms, documentation standards and — critically — budget approval levels. Those levels are a published threshold. Knowing where they sit before you write the paper is worth more than another decimal place in the model.
The Same Request, Two Competitor Sets
Classification does not change what you are buying. It changes what you are competing with, and that comparison is what actually decides the outcome. Book a Marine Inspection demo and see which path a per-vessel subscription naturally fits.
Presented as operating expenditure
Approval levelFrequently within a technical or operations budget already held by someone in the business, subject to the owner's defined approval thresholds.
Competitor setOther recurring operational spend — service contracts, subscriptions, consumables, shore support. Your subscription is compared against things of similar size and rhythm.
Decision speedFaster, because fewer people and fewer forums are involved and the amount sits below the threshold that triggers escalation.
The riskApproved quietly and resourced accordingly. A project nobody senior sponsored is a project nobody senior will unblock when it needs a decision.
Presented as capital expenditure
Approval levelHigher-level owner approval, since capital spending improves, upgrades or extends the life of the asset and owners play a stronger role in it.
Competitor setDry-docking, retrofits, treatment systems, efficiency upgrades and tonnage. Your request is compared against steel, and a subscription looks small and abstract beside a scrubber.
Decision speedSlower, tied to a capital planning cycle rather than to your timing, and frequently deferred to the next round rather than refused.
The upsideIf it clears, it clears with visible owner sponsorship attached — which is precisely the ingredient the failure research says is missing most often.
Neither route is correct in general and the choice is not always yours. What is always yours is knowing which one you are on before you write, because the paper is different in each case. An operating expenditure request should read as a cost line with a return. A capital request has to survive comparison against physical asset investment, which means leading with avoided loss rather than with efficiency, and being explicit about why this competes with steel at all.
Four People, Four Different Objections
A maritime buying centre is genuinely cross-functional and each participant is protecting something different. A paper written for one of them will be answered by the other three. Sign up for Marine Inspection and prepare an answer for each before the meeting rather than during it.
Finance
"Where did this number come from?"
Protecting the integrity of the forecast. Will discount any figure imported from a supplier and will ask which budget line it lands in and what it displaces. Wants provenance more than magnitude.
Answer with: inputs traceable to your own accounts, and the budget line named.
Technical
"We already have a system."
Protecting a decision they may have made themselves, and reasonably wary of another implementation landing on a team already stretched. The most dangerous objection because it sounds like a fact.
Answer with: what specifically the current system cannot do, demonstrated rather than asserted.
Operations
"Who is going to do this?"
Protecting capacity. Knows that implementation lands on people who already have jobs, and has watched previous projects consume more attention than promised. Frequently the objection that kills a paper quietly.
Answer with: a named owner, a stated time commitment, and what they stop doing.
The owner or board
"Why now?"
Protecting capital allocation. Not opposed in principle, but comparing this against everything else that could be funded this cycle, and asking what changes if the decision is deferred twelve months.
Answer with: the cost of the delay, expressed in the same units as the request.
Hardest objection
"We already have a system"
It is answered by demonstration, never by argument. Run one vessel on a free trial, close a real job at the machine, retrieve a component history in front of the person who raised it, and let them see the difference rather than read about it. That conversation changes with a working example in the room and does not change without one.
Ask for the Pilot, Not the Fleet
The single most effective structural change to a maritime software business case is reducing the size of the first decision. Vendor-neutral buying guidance in this sector is consistent on the point: prove it on a live cycle before you commit. Schedule a walkthrough and design a pilot that can fail cheaply.
01
Choose the difficult vessel
Not the flagship with the best crew and the tidiest records. A pilot on your best ship proves nothing that anyone will believe, and a pilot on a hard one produces an argument that survives scepticism.
02
Define what success looks like before you start
Pick two or three measurable things — time to close a job, time to retrieve a component history, number of findings converted into tracked actions. Write them down before the pilot, because a success criterion agreed afterwards is not a criterion.
03
Include the sceptic
The person most likely to object at the approval meeting should be inside the pilot rather than reading about it. A convinced sceptic is the most valuable internal reference you will ever have, and an excluded one becomes the objection.
04
Keep the exit cheap
A free trial or a month-to-month arrangement makes stopping easy, which paradoxically makes starting easy. A pilot that requires a multi-year commitment is not a pilot; it is the decision, wearing a smaller word.
05
Then ask for the fleet
The second paper is a different document from the first. It contains observed results from your own vessel rather than projections, and the people being asked have already seen it working. That is the paper that gets signed, and the pilot exists to produce it.
What the Paper Should Contain
Structure matters more than length, and a two-page document with the right sections outperforms a twenty-page one without them. Start a free trial and generate the evidence for section four before writing sections one to three.
Table 1: The Sections a Board Actually Reads
| Section | What it answers | Length | Common failure |
|---|---|---|---|
| The ask | What you want approved, in money, over what period, from which budget line | Three sentences, at the top | Buried on page four after the background |
| The problem, in their units | What is currently costing money, expressed as money rather than as frustration | A short paragraph | Described as an operational irritation, which reads as a preference |
| The evidence | Your own historical event costs, with sources a finance function can check | A table | Supplier percentages, which invite the one question you cannot answer |
| What you have already proved | Pilot results from your own vessel, with the criteria stated in advance | Half a page | Absent, because the paper came before any demonstration |
| The cost, all in | Three-year total including implementation, uplift and internal time | A short table | Year-one licence only, which erodes trust when the rest appears |
| Who owns it | A named person, their time commitment, and what they stop doing | Two sentences | Unstated, which is the objection Operations will raise |
| What happens if we defer | The cost of twelve more months of the current position | A short paragraph | Omitted, so deferral appears free — and deferral is the usual outcome |
| How we exit | What leaving costs and in what format the data returns | Two sentences | Omitted, which makes the decision feel larger than it is |
| What we are not claiming | The limits of the case, stated by you before anyone else states them | Two sentences | Omitted, so the first person to find a limit owns the narrative |
Section four is the one that changes outcomes, and it cannot be written before the pilot exists.
State the Limits Before Anyone Else Does
The section most papers omit is the one that most improves their chances, and the reason is counter-intuitive enough to be worth explaining. Book a walkthrough and identify your own honest limits before the meeting.
What overclaiming actually costs
Everyone in the room has seen a software business case before, and most have seen one that did not deliver what it promised. A paper claiming certainty is read against that memory. The first limit an approver identifies themselves becomes the frame for the whole discussion, and they will identify one.
What stating limits buys
Control of the frame. If you write that the model addresses roughly a third of your detention exposure rather than all of it, that number becomes the discussion rather than your credibility. Bounded claims are also easier to approve, because a bounded claim can be checked later.
Limits worth naming
That software prevents nothing directly and only makes some causes visible earlier. That efficiency savings will not reduce headcount and are therefore excluded from the financial case. That adoption is the principal risk and is behavioural rather than technical. That the addressable fraction is an estimate you made.
The line that does the work
Something close to: this case excludes efficiency savings because we cannot demonstrate they convert to cash, and it assumes we address only the share of past events with a record-related root cause, which we have assessed at a stated figure. Approvers respond to that sentence, because it tells them the person who wrote it was trying to be right rather than trying to win.
Sequencing, and What to Ask for First
Most papers ask for everything at once because that is how the vendor scoped it. Breaking the request changes both the approval probability and the implementation risk. Start a free trial and start at step one this month rather than proposing step three next quarter.
Now
A trial, at no cost, on one vessel
Requires no approval in most structures because it commits nothing. Produces the observed evidence that section four of the paper needs, and converts at least one sceptic. The single highest-return action available before any formal process begins.
Next
A paid pilot on two or three vessels
Small enough to sit inside an operating budget and below most escalation thresholds. Tests the thing a trial cannot — whether it holds across different crews and vessel types, which is the objection a single-vessel trial invites.
Then
Fleet rollout, with results attached
The paper that gets signed, because it contains measured outcomes from your own ships rather than projections from somebody else's. By this point the decision is about extending something that works rather than starting something that might.
Never
A fleet-wide multi-year commitment as the first ask
It maximises the size of the decision at the moment you have the least evidence, which is exactly backwards. It also removes your exit at the point where implementation failure is most likely — and the failure research is clear that the causes are behavioural rather than technical, which means they are the causes you cannot assess in advance.
Questions to Have Answers Ready For
These come up in nearly every approval meeting in this category, and the difference between a prepared answer and an improvised one is usually the difference between approved and deferred. Schedule a demo and rehearse them with whoever is presenting.
Table 2: What You Will Be Asked, and What Answers Well
| The question | What is really being asked | A strong answer | A weak answer |
|---|---|---|---|
| Where did this number come from? | Can I defend this if I approve it | Our own event costs from the last three years, with the source for each | An industry figure, which transfers the credibility risk to the approver |
| We already have a system | Was the last decision wrong, and is this a criticism of it | A demonstrated gap, framed as what has changed rather than as what was wrong | A feature comparison, which sounds like point-scoring |
| Who is going to run this? | Is this landing on someone already overloaded | A named person, a stated commitment, and what they stop doing | "The team will absorb it", which everyone present knows is untrue |
| What if we wait a year? | Is deferral free | The cost of twelve more months at your own historical event rate | Urgency asserted without a number attached to the delay |
| What if the crews do not use it? | Have you thought about the actual failure mode | Pilot adoption evidence from your own vessel, and the exit terms | An assurance that it is easy to use, which is what every vendor says |
| Is this capex or opex? | Which of my budgets does this hit and who signs | A clear classification with the budget line and threshold identified | Uncertainty, which sends the paper back before it is discussed |
| What happens if it does not work? | What is my downside | Exit terms, data export rights and the total sunk cost, stated plainly | Deflection, which makes the downside feel unbounded |
| Have you looked at alternatives? | Is this a considered choice or a preference | Named alternatives with the reason each was set aside | One option presented as though no others exist |
| What are you not claiming? | Are you being straight with me | Stated limits, offered before being asked | "Nothing" — which is the answer that loses the room |
2026 APPROVAL REALITY
Approval structures vary enormously and this page describes patterns rather than rules. Whether a request is treated as operating or capital expenditure, who holds authority, and what the approval thresholds are depend on your ownership structure, your management arrangement and your own company's procurement policy. In bareboat arrangements procurement authority may sit with the charterer or its appointed manager rather than the owner, and under third-party management a manager may request while the owner's policy determines what can actually be bought. Establish your own position before applying anything here. The implementation failure findings referenced are cross-sector. Sponsorship, resistance to change and change-management figures come from enterprise software research rather than maritime-specific study, and the mechanism rather than the precise percentage is what transfers. This page does not cover building the number. The event-cost model, addressable fraction and three-year horizon are set out separately in our cost modelling guide, and this page assumes you have already produced a defensible figure. Nothing here is financial or accounting advice. Capital and operating expenditure classification has accounting consequences that should be confirmed with your finance function.
Frequently Asked Questions
Should a software subscription be presented as opex or capex?
The classification should follow your finance function's treatment rather than your tactical preference, but it is worth understanding what each path does. Operating expenditure covers routine operational cost and typically sits within a budget already controlled inside the business, subject to your owner's defined approval thresholds. Capital expenditure covers major spending that improves, upgrades or extends the life of the asset and usually requires higher-level owner approval, with owners playing a stronger role in it. The consequence that matters is the comparison set: an operating request competes with other recurring spend, while a capital request competes with dry-docking, retrofits and tonnage.
Who actually approves this in a managed fleet?
It depends on the structure and it is worth establishing before writing anything. Owners commonly define procurement rules for the fleet covering approved vendors, compliance requirements, documentation standards and budget approval levels, which means a third-party manager may request a purchase while the owner's policy determines whether it can proceed. In a bareboat arrangement, authority may have shifted from the owner to the charterer or its appointed manager entirely. The practical first question is not whether the case is strong but who receives it and who can approve it — routing it wrongly produces delay and duplicated effort rather than a decision.
Why do good business cases still get rejected?
Usually for reasons the paper never addresses. Research on enterprise software implementation identifies resistance to change as a barrier for around eighty-two percent of organisations and insufficient sponsorship for around seventy-two, with Gartner attributing failure causes to absent executive commitment and inadequate change-management investment rather than to anything technical. Those are pre-approval and post-approval problems that no amount of modelling touches. The practical response is to secure a sponsor before the meeting rather than hoping the paper creates one, and to name an implementation owner with a stated time commitment so that the capacity objection is answered rather than left hanging.
How do I answer "we already have a system"?
By demonstration rather than by argument, because the objection is frequently defending a decision the person raising it made. A feature comparison sounds like point-scoring and hardens the position. What works is showing the specific gap on a real vessel — closing a job at the machine, retrieving a component history in seconds, converting a finding into a tracked action with evidence — and framing it as what has changed rather than as what was wrong. Vendor-neutral buying guidance in this sector makes the same point about evaluation generally: prove it on a live cycle before committing, which is also the most persuasive thing you can bring into the room.
How big should the first ask be?
As small as possible while still proving something. A free trial on one vessel commits nothing and requires no approval in most structures, yet produces the observed evidence a paper needs and converts at least one internal sceptic. A paid pilot on two or three vessels sits within an operating budget below most escalation thresholds and tests whether results hold across different crews and vessel types. Only then does the fleet request go forward, and by that point it is a proposal to extend something demonstrably working rather than to start something that might. Asking for a fleet-wide multi-year commitment first maximises the decision at the point of least evidence.
Should I include the limitations of the case?
Yes, and it is the section most often omitted and most likely to help. Everyone in an approval meeting has seen a software case that did not deliver, and a paper claiming certainty is read against that memory. Whoever first identifies a limit controls the framing of the discussion, and somebody always does. Stating plainly that efficiency savings are excluded because they cannot be shown to convert to cash, that the model addresses only a stated share of past events, and that adoption is the principal risk, tells an approver the author was trying to be right rather than to win. Bounded claims are also easier to approve, because they can be checked afterwards.
Before the paper
Get the Evidence First. Write Second.
Establish who approves and under which budget line. Secure a sponsor rather than hoping the paper produces one. Run a trial on your most difficult vessel with the sceptic inside it and the success criteria written down in advance. Name the implementation owner and what they stop doing. State the limits before anyone else finds them. Then ask — with observed results from your own ships attached, which is the version that gets signed.
