Getting a web project approved by a board

A board approves a web project when the web project business case answers three questions in plain language: what changes financially if we do this, what happens if we delay, and what is the worst case if it fails. Build it as a one-page decision memo with a cost-and-risk appendix — and present options, not a single recommendation.

Key Takeaways

• Boards approve risk-adjusted options, not feature lists — show two or three credible paths with trade-offs.
• Lead with money, delay and risk; put the technical detail in an appendix.
• One page wins more rooms than a forty-page deck; reserve the long form for genuine rebuild decisions.
• Name the cost of doing nothing in the same language as the cost of building.
• Pre-brief two directors before the meeting; surprise is the fastest way to a deferral.
• Every number you cite needs an owner and a source — the finance director will check.
• A web project business case is a decision document, not a design document.

What a board actually evaluates in a web project business case

Boards evaluate a web project business case on four tests: strategic fit, financial return, delivery risk and opportunity cost. If any one of the four is vague, the proposal is deferred, however good the idea. Directors ask "why now" and "what else could this money do" before they ask "how will it work".

Technical soundness rarely decides the vote. A board delegates that judgement to a named owner — an engineering lead, an external partner, or whoever will run the system afterwards. What the directors themselves weigh is whether the problem is real enough to spend organisational attention on it, and whether the person presenting the case has already thought about what could go wrong. The more confidently you can name the failure modes, the more credible the rest of the case becomes.

Why most web project proposals die in the room

Most web project proposals fail because they ask for approval of a solution before the board has accepted the problem. A deck full of screens, stack choices and a timeline reads as a technical pitch, not a decision. The second common killer is an unstated cost of delay — if directors cannot feel the pain of waiting, they will wait.

We see the same pattern repeatedly: a sponsor presents one option, defends it against alternatives that never appear on paper, and buries the cost in an appendix nobody reads. The board then asks for "more information" — which is a polite deferral, not a request for another meeting. A delayed web project carries a compounding cost, and the case is the document that makes that cost visible before the deferral happens.

When a full business case is worth the effort — and when a one-pager wins

The depth of a web project business case should match the size and irreversibility of the decision, not the size of the document the author can produce. A small refresh needs a one-page memo with a cost range and a named owner. A rebuild, a platform change or a customer-facing portal needs a full options paper, a costed risk register and a payback view.

In practice, the dividing line is simple. If the decision can be reversed cheaply — a redesign, a content migration, a hosting change — write the short version and get it in front of the board quickly. If the decision locks the organisation into a platform, a supplier or a multi-quarter build, invest the extra week in the long form. The cost of the document should never exceed the cost of a wrong decision.

How the case hangs together

A board-ready web project business case follows one structure: the problem in two sentences, the options on one table, the recommended option with a payback timeline, the risks that could break it, and the single decision being asked for. Everything else — screens, architecture, vendor detail — belongs in an appendix the directors may skim.

The spine of the memo is this five-part outline:

1. Problem (two sentences, one cost figure)
2. Options (do nothing / improve / replace)
3. Recommendation + payback
4. Risks + owners
5. The decision being asked for

That ordering matters. If the problem section fails, nothing else gets read. If the options section is thin, the recommendation looks like advocacy rather than analysis. The risks section is where you earn trust: a case with no named risks is a case that has not been thought through.

Step-by-step: build a case that survives board scrutiny

Build the web project business case backwards from the decision: agree the question first, gather evidence second, cost the options third, and write the memo last. Each step has a clear owner and a checkpoint, so the case does not become a solo writing exercise that collapses under the first cross-examination.

1. Write the decision question. One sentence, for example: "Should we replace the membership portal this financial year?" If you cannot phrase it as a yes/no choice, the case is not ready.
2. Collect the evidence. Support tickets, manual work hours, abandoned transactions, maintenance time, compliance deadlines. Each piece needs a source and a date.
3. Price the options qualitatively. Compare effort, licences, hosting, migration and ongoing operation for each path. Do not hide a cost you dislike.
4. Build the risk register. For each risk, record likelihood, impact, the owner and the mitigation. Keep it to the ones that actually threaten the decision.
5. Draft the one-pager. Problem, options table, recommendation, risks, ask. Everything else goes in the appendix.
6. Test it with finance and one operator. Ask both to find the weakest number and the vaguest risk before the meeting, not during it.
7. Pre-brief two directors. Walk them through the memo, hear their pushback, and revise. They will carry the question in the room.

Which numbers and evidence a board trusts

Directors trust numbers that have an owner, a source and a date — and they distrust averages, industry benchmarks quoted without context, and any savings figure that cannot be traced to a process you will actually change. A single measured cost of delay, even approximate, outweighs a slide of generic market statistics.

Evidence	What it proves to a board
Support tickets per month	The current system costs staff time every week
Abandoned transactions or enquiries	Revenue is already being lost
Manual work hours per process	A repeatable, quantifiable saving
Compliance or security deadline	Delay carries a named regulatory risk

Where the numbers come from matters as much as the numbers themselves. A web development quote is built from scope, platform and skill — and a board that understands those drivers will not be surprised later when a change in scope changes the cost. Name the source next to every figure.

How to test your case before the meeting

Test a web project business case the same way a board will test it: hand it to the finance director and one person who runs the current system, and ask them to find the weakest number and the vaguest risk. If they both name the same gap, fix that before the meeting rather than defending it in the room.

A useful dry run is to ask one sceptical colleague: "What would make you vote no?" Write down their answer verbatim and address it in the memo. If you cannot answer the objection without adding a slide, the case was not finished. The goal is not to remove every risk — that is impossible — but to show the board you have already seen it and assigned an owner.

Failure modes in the meeting and how to recover

The common boardroom failure modes are a deferred decision for "more information", a request to see a single option repriced, and a challenge that kills the session — usually an undisclosed dependency or a cost item with no owner. Recover by agreeing the missing evidence, naming who will produce it, and setting a return date in the same meeting.

Deferral is not rejection. Often the board simply wants the case tightened, and the directors will say so if you ask directly. Do not promise to "go away and think about it" — that is how proposals disappear for six months. Instead, close the meeting with: "If we bring the missing dependency analysis to the next meeting, can we decide then?" That question turns a deferral into a scheduled decision.

What the case costs you to build — and what it costs if you skip it

Building a proper web project business case costs time, not money: a few days of the sponsor's attention, an afternoon from finance, and one honest conversation with whoever operates the current system. Skipping it costs far more — a deferred rebuild, an approved project that quietly overruns, or a board that loses trust in future asks.

The operational overhead sits in two places. First, someone must own the evidence: the ticket counts, the manual-hours estimate, the payback assumption. Second, the case must stay alive after approval as the yardstick for delivery. If the approved scope drifts, the board will remember the numbers you presented and hold you to them. A scope creep conversation is easier when the original case is on record.

Risk and security questions boards raise

Boards raise risk and security questions early because a web project often touches customer data, payments, or the public face of the organisation. Expect questions about data ownership, access to live systems, who can push changes, and what happens if the launch fails. Answer with named owners and a rollback path, not with a promise.

The ownership question is the one that most often surprises technical sponsors. A board wants to know that the accounts, code and credentials sit in the organisation's name, not in a departing contractor's inbox. If the case shows the system will be operable by someone other than its original builder, that single line reduces the perceived delivery risk more than any architecture diagram.

Common mistakes we see in web project business cases

The most damaging mistake in a web project business case is hiding a cost or a dependency because the author fears it will kill the proposal — boards always find it later, and the discovery kills trust. Other common mistakes: writing in technical language, presenting one option, and confusing activity with outcome.

A case that says "we will redesign the site" describes activity. A case that says "we will reduce abandoned checkout by a measurable amount" describes an outcome. Boards approve outcomes and fund activities. The difference sounds small, but it determines whether the follow-up question is "when will it ship" or "what will it change".

A concrete scenario: the membership portal that almost got shelved

A membership organisation wanted to replace a portal built on an old platform. The first board pack was a 30-page technical proposal and was deferred. The second attempt opened with one sentence: members spend eleven minutes renewing, support handles forty calls a month, and three staff members spend Fridays exporting data by hand.

That sentence did the work. The options table showed three paths: patch the current portal, rebuild on a configured platform, or commission a custom system. The recommendation was the middle option, with the data migration and staff training named as the two real risks. Two directors had been pre-briefed, so when the finance director asked who owned the migration, the answer was already on the slide. The board approved the rebuild with a condition: a review checkpoint after the first migrated cohort.

Alternatives compared

The alternatives a board weighs are usually four: do nothing, patch the current site, rebuild on a configured platform like WordPress, or commission a custom system. The right answer depends on the age of the current system, the volume of manual work, and whether the process itself is unique to the organisation.

Option	Best when	Main risk
Do nothing	The pain is tolerable and the system is stable	Cost of delay compounds quietly
Patch or refresh	The structure is sound but looks dated or is slow	Patching symptoms, not causes
Rebuild on WordPress or similar	Standard content, membership or commerce patterns	Over-customising a platform
Custom build	The process is unique and core to the business	Longer delivery, more to operate

The custom-versus-off-the-shelf decision turns on one question: is the process itself a source of advantage, or is it a standard activity the organisation happens to do? Most boards will approve the simpler option when the case shows the complex one buys nothing except ownership of a problem.

In short: a board does not approve a website; it approves a decision. Give it a one-page web project business case that names the problem, prices the options, owns the risks and asks for one clear thing. The shorter and more honest the memo, the faster the yes.

People also search for

• What a delayed web project actually costs
• Building the case for a customer portal
• Custom software versus off-the-shelf: how to decide
• How scope creep breaks a web project budget
• What sits inside a web development quote
• What to cover in a project handover meeting

If the board has asked for a tighter web project business case — or you want someone to pressure-test the numbers before the meeting — our team can help you shape the options, cost the risks and write the memo in plain language. We build and run web applications and portals inside your own accounts, so the case and the build stay yours. Contact us and we will review what exists before you walk into the room.