Specimen deliverables — Meridian Country Club (illustrative)

Phase 1 · Discover

Seven departments, eleven sessions, one survey. Nothing is assessed until the club has said what it needs.

D1.1 Stakeholder engagement record

PurposeProve the research was real and adequately covered

AudienceThe committee, and anyone auditing rigour

Why it mattersEvery later claim rests on this coverage

sessions held across seven departments, plus one survey

staff took part in a session, from 7 of 7 departments

138

survey responses — 71% of staff who touch the ICMS daily

100%

departmental coverage — no department unrepresented

Session register

Week Department

Selecting “requirements from this session” cross-links into D1.3.
Session	Week	Format	Duration	Participants	Facilitator
All staff survey	1	Online survey	Open 8 days	138 responses	Analyst
Membership	1	Group session	90 min	Head, membership executive, report consumer	Engagement lead
Requirements originated here:
Marcom	2	Group session	60 min	Head, EDM operator	Engagement lead
Requirements originated here:
Front Office / Member Services	2	Group session	90 min	Supervisor, two counter staff	Engagement lead
Requirements originated here:
Finance	2	Group session	90 min	Finance manager, reconciliation staff	Engagement lead
Requirements originated here:
Golf Operations	2	Group session	90 min	Golf manager, starter, marshal, handicap admin	Engagement lead + architect
Requirements originated here:
F&B	3	Group session	60 min	F&B manager, POS supervisor	Engagement lead
Requirements originated here:
IT	2	Interview	90 min	IT manager, systems administrator	Solution architect
Requirements originated here:
Management / Exco	2	Interview	60 min	General Manager, two Exco members	Project director
Current ICMS vendor	3	Interview	60 min	Account and product contacts	Solution architect
Consolidation workshop 1	3	Workshop	90 min	Front-of-house departments	Engagement lead + director
Requirements originated here:
Consolidation workshop 2	3	Workshop	90 min	Finance, IT, Golf Operations	Engagement lead + director

Selection rule. Per department we want a daily user, someone who approves or supervises, and someone who consumes the reports. That triangle surfaces disagreement inside the room, which a series of one-to-one interviews never does.

What we asked, in every session

What does the system do well that we should be careful not to break?
Walk me through [your core task] as you actually do it — not as the procedure describes it.
Where do you keep information outside the system, and why?
What happens when it fails? Who finds out, and how?
What do members complain about that traces back to this system?
What have you stopped asking for because you assume the answer is no?
If you could change one thing before next season, what would it be?

Question 6 produces more than the other six combined. Staff normalise limitations they have lived with for years.

D1.2 Stakeholder findings report

PurposeWhat people actually said, before any of it was coded

AudienceEveryone

Why it mattersThis is where belief changes — the tables that follow only confirm it

138

staff responded — 71% of those who touch the ICMS daily

22 hrs

of manual re-entry a week, self-reported and cross-checked against workflow mapping

6 of 7

departments build at least one report by hand every month

renewals actioned after the member had already lapsed, FY24

What staff most want fixed

One member record across booking, F&B and billing78%

Closure and cancellation handled by the system, not the telephone71%

Reports without raising an IT request64%

Voucher redemption reflected the same day58%

Renewal reminders that arrive before lapse52%

Guest registration reachable from the member record44%

Member photograph at check-in31%

Ranked, not averaged. The order is what drives the Must-have layer in D1.3.

In their words

“When the course closes we ring round. On a bad Saturday that is forty calls.”Golf Operations · Week 2

“I keep my own spreadsheet, because I do not trust the report.”Finance · Week 2

“Two systems, same member, different spelling. I fix it by hand.”Membership · Week 1

“Members tell us their voucher balance is wrong before we know it is.”F&B · Week 3

“We stopped asking IT. It is faster to do it ourselves.”Marcom · Week 2

“I know the answer. I just cannot get it out of the system.”Front Office · Week 2

Three patterns behind the findings

The workaround became the process. Staff stopped reporting failures years ago. The manual step is now written into the departmental procedure, so the system looks like it works.

Parallel records where trust ran out. Four departments keep their own spreadsheet alongside the platform. Each is a data quality problem the reports cannot see.

Knowledge sits with people, not the system. Six of seven departments named one individual who knows how to get a particular answer out. That is a continuity risk before it is a technology one.

What members feel

Renewal reminders arrive after lapse, so members are asked to rejoin rather than renew.
Voucher balances are wrong for up to a day, and members notice before staff do.
Course closure reaches members by telephone, unevenly and late.

D1.3 Requirements matrix

PurposeEvery input coded, attributed and prioritised

AudienceWorking group

Why it mattersThe spine the rest of the engagement is scored against

47 requirements in total; 12 shown here as a working sample.

Department Priority Type

6 Must3 Should2 Could1 Won’t·7 of 7 departments represented in this sample

	Ref	Dept	Requirement	Type	Priority
	R-014	Golf Operations	Course closure must automatically suspend affected tee bookings and notify members	Integration	Must
Source Golf Operations group session, Week 2 · Evidence Raised by starter and marshal; confirmed against closure log · Current state Manual — starter telephones affected members
	R-002	Membership	Single member record shared across booking, F&B and billing without re-keying	Data quality	Must
Source Membership group session, Week 1 · Evidence Duplicate records demonstrated live in session · Current state Partial — billing holds a separate record
	R-007	Finance	Point-of-sale takings post to the finance ledger daily without manual journal entry	Integration	Must
Source Finance group session, Week 2 · Evidence Month-end reconciliation file, three months sampled · Current state Manual journal, twice weekly
	R-021	Front Office	Guest registration reachable from the member record without switching systems	Functional	Must
Source Front Office group session, Week 2 · Evidence Counter workflow walkthrough · Current state Two systems, manual cross-reference
	R-009	Membership	Renewal reminders trigger automatically at defined intervals before lapse	Functional	Must
Source Membership group session, Week 1 · Evidence Lapse report; 41 renewals actioned late in FY24 · Current state Manual list pulled monthly
	R-027	IT	Integration failures raise an alert rather than failing silently	Integration	Must
Source IT interview, Week 2 · Evidence No monitoring configured on two of five boundaries · Current state None — discovered on complaint
	R-033	Golf Operations	Handicap data flows to the national body without a manual export	Integration	Should
Source Golf Operations group session, Week 2 · Evidence Export file inspected; fortnightly cadence · Current state Manual export, fortnightly
	R-018	F&B	Voucher redemption visible on the member account within the same day	Data quality	Should
Source F&B group session, Week 3 · Evidence Redemption sample; two-day lag observed · Current state Overnight batch, occasionally missed
	R-005	Marcom	Segment members by activity across golf, F&B and events in one query	Reporting	Should
Source Marcom group session, Week 2 · Evidence Three campaign briefs; segments built by hand · Current state Manual, from three exports
	R-011	Finance	Ad-hoc revenue reports self-served without an IT request	Reporting	Could
Source Finance group session, Week 2 · Evidence 14 report requests logged in six months · Current state Raised as IT tickets
	R-030	Front Office	Member photograph visible at check-in for identity confirmation	UX	Could
Source Front Office group session, Week 2 · Evidence Requested by two of three counter staff · Current state Not available
	R-042	Marcom	Replace the current mailer engine as part of this programme	Functional	Won’t
Source Consolidation workshop 1, Week 3 · Evidence Deprioritised by departments jointly · Current state Out of scope this cycle

D1.4 Workflow and process assessment

PurposeWhere the time actually goes

AudienceCommittee and Finance

Why it mattersThe 22-hour figure quoted elsewhere is built here

Workflow	Steps	Manual steps	Systems touched	Hours / month	Automation opportunity	Effort	Benefit
Monthly departmental reporting	11	9	4	24	Cross-module reporting layer	High	High
Daily POS reconciliation	7	5	3	24	Scheduled ledger connector	Medium	High
Member renewal cycle	9	4	3	18	Trigger reminders from lifecycle date	Low	High
Guest registration	6	3	2	12	Surface registration from member record	High	Medium
Course closure notification	5	5	2	9	Automated suspension and notification	High	High
Voucher issue and redemption	8	3	2	8	Event-triggered posting	Medium	Medium
Total				95 hrs / month	≈ 22 hours per week

Member renewal cycle — the step chain

System: pull list Manual: review list Manual: compile mailer System: send reminder Manual: check payment Manual: chase by phone System: record payment Manual: update lapse status System: reactivate access

Amber = manual step. Forest = system step. Four of nine steps are manual, and the two chase-by-phone steps are where the 41 late renewals in FY24 originate.

Effort vs. benefit

Low effort

Medium effort

High effort

High
benefit

Member renewal cycle

Daily POS reconciliation

Monthly departmental reporting

Course closure notification

Medium
benefit

Voucher issue and redemption

Guest registration

Low
benefit

The quick-win quadrant (low effort, high benefit) is where the Phase 4 roadmap starts.

Phase 2 · Diagnose

Now, and only now, we assess. Everything here is measured against what Phase 1 established.

We diagnose against what was asked for, not everything that could be measured. That is the difference between a consultancy engagement and an IT audit. Every dimension below exists because a Phase 1 requirement made it relevant.

D2.1 Wants vs current capability

PurposeThe subtraction, shown working — the centre of the entire set

AudienceEveryone

Why it mattersIf this arithmetic can't be seen, the D4.1 recommendation is an assertion

Already met by the current platform

Closable by configuration alone

Closable by enhancement or integration work

Need capability the platform does not have

Department Priority Closure route

	What is wanted	What happens today	Priority	Closure route
	Course closure suspends bookings and notifies members	Manual — starter telephones affected members	Must	Replace only
Closure automation is not in the vendor roadmap. No configuration path exists.
	Single member record across modules	Partial — billing holds a separate record	Must	Enhancement
Closable by an integration build between billing and the member record.
	POS posts to ledger daily	Manual journal, twice weekly	Must	Enhancement
A scheduled connector to the ledger closes this. Native support exists, unconfigured.
	Guest registration from member record	Two systems, manual cross-reference	Must	Replace only
Guest registration is a separate product in this vendor architecture. Not bridgeable.
	Renewal reminders before lapse	Manual list pulled monthly	Must	Configuration
Trigger rules exist in the platform and have never been switched on.
	Integration failure alerting	None — discovered on complaint	Must	Enhancement
Monitoring can be added at each boundary without vendor involvement.
	Handicap feed automated	Manual export, fortnightly	Should	Enhancement
Requires a connector to the national body. No native support.
	Voucher redemption same day	Overnight batch, occasionally missed	Should	Enhancement
Batch frequency is configurable, but same-day needs an event trigger built.
	Cross-module segmentation	Manual, from three exports	Should	Replace only
No shared reporting layer across modules. Architectural, not configurable.
	Self-served revenue reports	Raised as IT tickets	Could	Configuration
Report builder licences already held, never rolled out.
	Member photo at check-in	Not available	Could	Configuration
Field exists in the member record, not surfaced at check-in.
	Replace mailer engine	Out of scope this cycle	Won’t	Not pursued
Deprioritised by the departments jointly in Week 3.

34 met + 3 by configuration + 5 by enhancement = 42 of 47 reachable without replacing the platform.

That is 89% of what seven departments asked for, closable on the platform the club already owns. Replacement buys the remaining 5 at roughly three times the cost, and puts the 42 that already work at migration risk.

Two of the five unreachable requirements are Must-haves — R-014 course closure and R-021 guest registration. Both are recorded as the trigger to revisit: if the vendor roadmap does not address them within eighteen months, the arithmetic changes and replacement becomes right.

D2.2 Technical health scorecard

PurposeIs this platform a sound foundation to invest further in?

Why it mattersEach dimension states its bearing on the optimise-vs-replace decision, or it is decoration

Dimension	Rating	Summary	Evidence	Bearing on the decision
Performance	Amber	Stable outside peak. Degradation at weekend tee-off windows.	Uptime log 12 months · 6 user reports · no load testing available	Tolerable. Does not on its own justify replacement.
Reliability	Green	Few severity-1 incidents. Within SLA in 11 of 12 months.	Incident register · SLA reports · escalation history	Supports enhancing rather than replacing.
Scalability	Green	Headroom adequate for five years of projected growth.	Architecture documentation · current utilisation	Removes growth as a reason to replace.
Sustainability	Red	Two core modules on a framework version out of vendor support.	Release notes · roadmap declined by vendor, limitation stated	The strongest argument for replacement, and the reason the recommendation carries an eighteen-month review trigger.
Data quality	Amber	Member record duplication at the billing boundary; 3.4% affected.	Sample profiling, 2,000 records · reconciliation exceptions	A migration cost driver, and a reason to fix data before any platform move.
Reporting	Red	No cross-module reporting. Six of seven departments combine by hand.	Report inventory · 14 IT report requests in six months	Architectural. Cannot be configured away — one of the five replace-only gaps.

RAG carries a text label always, never colour alone.

D2.3 ICMS ecosystem and integration landscape

PurposeMap every boundary and rate its portability — where migration cost and lock-in actually live

Member-facing tierMember app · booking portal · kiosk check-in

Core modulesMembership · Golf · F&B POS · Billing · Facilities

Interfaces and integrated systemsFinance ledger · HR · weather/lightning feed · mailer · national handicap body

Boundary	Method	Frequency	Connector owner	On failure	Data quality	Portability
Point of sale → core platform	Documented API	Real time	Third-party product	Retries, then alerts	Clean	Portable
Core platform → finance ledger	Scheduled file export	Twice weekly	Incumbent vendor	Fails silently	3.4% mismatch	Rebuild likely
HR system → finance ledger	Manual journal posting	Monthly	Club (manual)	Noticed at close	Clean	No dependency
Weather and lightning feed → golf	Vendor connector	Real time	Incumbent vendor	Falls back to manual	n/a	Lock-in point
Golf booking → member app	Internal module call	Real time	Incumbent vendor	Stale data shown	Clean	Lock-in point
Core platform → mailer	Nightly list export	Nightly	Club	Skips silently	Segment gaps	Portable

Connector ownership is the row most clubs have never priced. Where the incumbent built and maintains an integration, leaving them means rebuilding it — that is lock-in with a number attached.

D2.4 Membership lifecycle and Member 360 gap

PurposeCan the platform hold a complete picture of a member across their whole relationship with the club?

Lifecycle stages

Stage	System support	Manual effort	Gap
Enquiry	None — email inbox	High	No enquiry record; conversion untracked
Application	Partial — form captured, approvals offline	Medium	Approval history not held against the member
Onboarding	Partial — record created, welcome sent manually	Medium	No onboarding sequence
Active use	Good — bookings, spend, attendance captured	Low	Held in separate modules, not one view
Renewal	Weak — manual list pulled monthly	High	No trigger; 41 lapsed before contact in FY24
Lapse	None	High	No lapse reason captured
Win-back	None	High	No re-engagement path

Member 360 — field coverage

Data	Held?	Where	In one view?
Core profile	Yes	iClub	Yes
Contact and preferences	Yes	iClub + mailer	No — two places
Golf activity and handicap	Yes	iGolf	No
F&B spend	Yes	POS	No
Facility bookings	Yes	Booking module	No
Communication history	Partial	Mailer only	No
Complaints and feedback	No	Email and paper	No
Billing and arrears	Yes	Billing	No — separate record

Eight data domains, six systems, one member. A Member 360 view exists in principle and nowhere in practice.

Phase 3 · Determine

The gap is now known and sized. Only at this point does it make sense to look at the market — the shortlist is derived from the requirements, not from a vendor list.

D3.1 Market scan — longlist to shortlist

PurposeShow that the shortlist was derived, not pre-formed

candidates considered

pass operational fit

shortlisted, alongside the incumbent as baseline

Six gates, applied in order

Gate	Test
Operational fit	Supports a private members club at this scale, with golf, F&B, facilities and events in one platform
Requirements coverage	Scored against the Phase 1 matrix — Must coverage first
Ecosystem reproducibility	Can reproduce or improve on the module structure and the interface layer, golf boundary included
Regional viability	Presence, support and reference base relevant to the region
Commercial transparency	Enough obtainable pricing structure to build an indicative TCO range
Vendor stability	Ownership, financial footing, roadmap credibility — a ten-year decision

Candidates

Candidate	Op. fit	Coverage	Ecosystem	Regional	Commercial	Stability	Outcome
Alternative A	Pass	Pass	Pass	Pass	Pass	Pass	Shortlisted
Alternative B	Pass	Pass	Pass	Pass	Pass	Pass	Shortlisted
Alternative C	Pass	Pass	Pass	Pass	Pass	Pass	Shortlisted
Alternative D	Pass	Pass	Fail	—	—	—	Cannot reproduce golf boundary
Alternative E	Pass	Fail	—	—	—	—	Must coverage below 60%
Alternative F	Fail	—	—	—	—	—	Hospitality PMS, not club management
Alternative G	Pass	Pass	Pass	Fail	—	—	No regional presence or support
Alternative H	Pass	Pass	Pass	Pass	Fail	—	No obtainable pricing structure
Alternative I	Pass	Pass	Pass	Pass	Pass	Fail	Ownership change in progress

Every exclusion carries its reason, so the shortlist itself can be challenged — not just the conclusion.

D3.2 Comparative evaluation checklist

PurposeThe ticklist — requirement by requirement, platform by platform, incumbent included

Why it mattersThis is what a committee will lean over the table to read

●Native — works out of the box ◐Configurable — supported, needs setup ○Customisation — possible, needs build ✗Not possible on this platform

Ref	Requirement	Pri
R-014	Course closure suspends bookings and notifies	Must
R-002	Single member record across modules	Must
R-007	POS posts to ledger daily	Must
R-021	Guest registration from member record	Must
R-009	Renewal reminders before lapse	Must
R-027	Integration failure alerting	Must
R-033	Handicap feed automated	Should
R-018	Voucher redemption same day	Should
R-005	Cross-module segmentation	Should
R-011	Self-served revenue reports	Could
R-030	Member photo at check-in	Could

Must-have coverage: Current 71% · Alternative A 94% · Alternative B 82% · Alternative C 66%

Select any cell in the matrix to see the reasoning behind the score, with links back to the requirement and the session it came from.

Re-score by department weighting

Default is equal weighting. Double-weight a department above and watch the ranking move — this demonstrates that the best platform depends on what the club decides matters, which is why the requirements matrix has to exist before the market scan.

Current platform0%

Alternative A0%

Alternative B0%

Alternative C0%

D3.3 Indicative total cost of ownership

PurposeRanges with a stated basis, not vendor quotations

Cost component	Included	Current (enhance)	Alt A	Alt B	Alt C
Licence / subscription, 5 yr	Per-member or per-module	S$140k	S$310k	S$240k	S$180k
Implementation	Configuration, integration, interface layer	S$95k	S$260k	S$210k	S$190k
Data migration	Records, history, transactions	—	S$120k	S$110k	S$130k
Customisation	Where native falls short of a Must	S$40k	S$20k	S$95k	S$150k
Training and change	Seven departments, weighted by disruption	S$25k	S$70k	S$65k	S$60k
Ongoing support, 5 yr	Vendor, hosting, internal effort	S$110k	S$150k	S$135k	S$125k
Transition and parallel running	Two systems during cutover	—	S$85k	S$80k	S$75k
Exit cost	Data portability, cost of leaving later	S$60k	S$45k	S$70k	S$95k
Five-year total		S$470k	S$1.06m	S$1.01m	S$1.01m

Exit cost is included deliberately. A platform decision made without pricing the exit is how lock-in is acquired in the first place.

D3.4 Current vendor benchmarking

PurposeHold the incumbent to the same standard as the alternatives

SLA compliance, twelve months

11 months green (within SLA), 1 month amber (breach). Severity-1 incidents: 4. Mean resolution 6.2 hrs against an 8 hr target.

Dimension	Rating	Assessed against	If the vendor does not cooperate
SLA compliance	Green	Historical SLA reports, incident logs, resolution records	Club-side incident records and stakeholder history
Roadmap alignment	Red	Published roadmap against the Phase 1 matrix	Release history and public product signals
Service quality	Amber	Escalation history, responsiveness, relationship health	Stakeholder-reported experience
Lock-in risk	Red	Contract terms, proprietary dependencies, data portability, connector ownership	Contract documents held by the Club

Lock-in exposure

Factor	Position
Connectors owned by vendor	3 of 6 boundaries
Data export format	Proprietary; documented export available
Contract notice period	12 months
Escrow arrangement	None
Framework support status	Two modules out of support

The vendor declined to provide roadmap material. That refusal is itself a finding and is reported as one — it is why roadmap alignment is rated red rather than left unrated.

Phase 4 · Decide

The determination, and everything that makes it defensible.

D4.1 Assessment report and recommendation

PurposeThe document Management and the General Committee read

Why it mattersEverything else exists to make this page defensible

Enhance

Of 47 requirements gathered across seven departments, 34 are already met, 8 can be closed through configuration and integration work, and 5 need capability the platform does not have and the vendor does not plan to build. Replacement would cost roughly three times as much to reproduce most of what the club already owns.

Decision flowchart

47 requirements

↓

no action

↓

42 reachable without replacing (89%)

↓

ENHANCE

↓

2 are Must-haves → 18-month review trigger

3 are Should/Could → accept, revisit at renewal

Why not the other two paths

Not optimise alone. Two of the five unmet Must-haves are integration gaps configuration cannot reach. It closes nothing that matters to members and leaves the sustainability finding unaddressed.

Not replace. Six boundaries would need rebuilding, two of them real-time. Nine months of parallel running for capability the club largely has. Replace becomes right if the vendor's framework support position does not change within eighteen months.

What changes, in plain terms

Audience	Change
For members	Renewal reminders arrive before lapse rather than after. Voucher balances correct the same day. Course closure reaches the app without a phone call.
For staff	22 hours of manual re-entry a week removed across Finance and Front Office, redeployed to member-facing work.
For the Committee	Cross-module reporting without an IT request, and a single member record that makes those reports trustworthy.

Roadmap — nine months

M1M2M3M4M5M6M7M8M9

Configuration quick wins (R-009, R-011, R-030)

Member record integration (R-002, R-018)

Finance and monitoring connectors (R-007, R-027)

Handicap feed & reporting layer (R-033, partial R-005)

Low-effort, high-benefit first — which is why the D1.4 effort/benefit plot exists.

Baseline measures established by this review

Measure	Baseline	Source
Manual re-entry across seven departments	22 hours per week
Member records duplicated at billing boundary	3.4%
Renewals actioned after lapse	41 in FY24
Boundaries without failure alerting	2 of 6
Departments building reports by hand	6 of 7
Severity-1 incidents, twelve months	4

Cost and benefit of each path

Path	Indicative cost	Duration	Closes / leaves
Optimise	S$40k – 60k	3 months	Closes 2 of 13 gaps. Sustainability unaddressed.
Enhance (recommended)	S$180k – 240k	9 months	Closes 8 of 13. Retains existing data. Five deferred pending vendor roadmap.
Replace	S$620k – 900k	18 months	Closes all 13. Migration risk across 6 boundaries, 9 months parallel running.

Risks and mitigations

Risk	Impact	Mitigation
Vendor framework support lapses inside 18 months	High	Review trigger written into the recommendation; portability work sequenced first
Data quality blocks the member record integration	Medium	Deduplication precedes integration in the roadmap
Configuration quick wins absorb the appetite for the harder work	Medium	Roadmap sequences quick wins alongside, not before, the integration workstream

The vendor declined to provide roadmap material. The sustainability rating and the two deferred Must-haves rest on release history and public product signals rather than a vendor commitment. The report says so on its face, and the recommendation is framed to be revisited if that position changes.

A specimen report that admits what it could not establish is more persuasive than one that appears to know everything.