Most organisations make the shift from project-to-project commissioning to programmatic capture implicitly — three captures into a relationship, the fourth gets quoted at the same per-project rate as the first. The deliberate version, designed up front, costs less per cycle, integrates better with budget calendars and accumulates institutional value that ad-hoc capture doesn't.
If you've ever caught yourself commissioning the same operator for the third or fourth capture of the same site without ever formalising the relationship, you've met the implicit-programme problem. The work has become programmatic; the contract is still per-project. The pricing reflects fresh per-project quotes rather than programme economics; the deliverable spec gets re-litigated each cycle; the operator can't plan their capacity around your demand.
This article is the deliberate alternative — what a multi-year LiDAR programme actually looks like, how to design one, and the design mistakes worth avoiding.
It pairs with the first-capture article (which covered how to set up the foundational capture so subsequent cycles run efficiently) and the build-vs-buy article (which covered when ownership beats commissioning at all). Programmatic commissioning is the third path most organisations end up needing.
The shift from project to programme isn't just about quantity. It's about five things that change in kind:
1. Multi-year contractual structure. Master service agreement or framework contract spanning 2-5 years, with work orders or task authorisations per cycle. The procurement event happens once; the captures happen on schedule.
2. Pre-agreed scope template + pricing. Standard scope and pricing for the routine cycle, with explicit handling for the occasional variation (additional area, accelerated turnaround, format change).
3. Predictable capture cycle. Monthly / quarterly / annual captures booked into the operator's calendar in advance, allowing operator to plan capacity and you to plan budget.
4. Continuous baseline / change detection. The deliverable rhythm shifts from "fresh capture" to "delta from previous" once a baseline is established. Smaller, faster, cheaper per cycle.
5. Vendor relationship continuity. The operator accumulates site-specific knowledge — terrain quirks, classification edge cases, processing parameters, stakeholder relationships. Each capture runs more smoothly because the last one did.
A relationship that delivers all five is a programme. A relationship that delivers any individual capture well but none of the five is a sequence of one-offs.
The right frequency depends on what you're trying to detect:
Monthly (12 captures / year). Mining reconciliation (pit progress, stockpile movement, dump growth), dynamic-site captures where the deliverable feeds operational decisions on short cycles. Per-capture cost typically 40-60% of one-off rate at this frequency.
Quarterly (4 captures / year). Utility network compliance (vegetation clearance, encroachment), asset condition (pavement deformation, structural settlement), recurring environmental reporting. Per-capture cost typically 60-75% of one-off.
Annual (1 capture / year). Environmental baselines, infrastructure condition assessment, regulatory reporting, council asset inventories, post-season agricultural assessment. Per-capture cost similar to one-off but with budget predictability + operator priority.
Multi-annual (every 2-5 years). Long-term change detection, slow-changing infrastructure, rehabilitation milestone audits. Programme value is in the baseline continuity rather than per-capture economics.
Event-driven (variable timing). Post-flood damage assessment, post-fire recovery, post-incident audit. Programme value is in the standby capacity and pre-agreed mobilisation terms rather than fixed cycle.
The frequency should match the rate at which the underlying information changes meaningfully. More frequent than needed generates data your team can't consume. Less frequent than needed misses the change you're trying to detect.
Programme captures don't all need to be the same scope. A common rhythm:
Cycle 1 (baseline). Full capture, full QA pack, full deliverable suite. Establishes the reference for every subsequent capture. Typically 100-130% of one-off cost because of the setup work.
Cycles 2 through N-1 (differential). Capture against the established baseline, deliver the delta + updated current state. QA pack is lighter (delta from baseline pack rather than full re-validation). Typically 40-65% of one-off cost.
Cycle N (annual full re-baseline). Once a year (or at programme milestones), run a full capture + full QA pack to re-establish baseline currency. Same as Cycle 1 economics.
The pattern matches how the data is actually used: most cycles answer "what changed?"; the annual full pack answers "what's the current state?". Both questions matter; they need different deliverable depth.
A programme that ships the full pack every cycle is over- delivering on differential cycles and under-amortising the baseline work. A programme that ships only differentials and never re-baselines accumulates drift in the reference that eventually catches up.
Three patterns work for multi-year LiDAR programmes:
Master Service Agreement + Work Orders. A single MSA covering scope template, standard pricing, change management, IP, insurance, termination — with per-cycle work orders authorising specific captures against the agreed terms. Common for government, large enterprise, and any procurement environment with strong contract governance.
Fixed-Price Programme with Annual Review. Fixed annual fee covering N captures at agreed cadence, scope and deliverables. Cap on variations. Annual price review against defined adjustment mechanism. Common for predictable recurring work where both parties value budget certainty.
Per-Cycle Commitment with Framework Pricing. Each cycle is a discrete commitment, but pricing follows a framework schedule documented in a pre-existing relationship agreement. Lighter governance, less commitment, less price stability. Common for early-stage programmes or relationships where either party wants flexibility.
Choose based on procurement environment and risk preference. MSA + Work Orders is the most common pattern for substantive multi-year programmes; the others fit specific situations.
The shift from project to programme matters for budgeting:
Operating expenditure vs capital. Programme captures typically book as opex rather than capex, simplifying multi-year planning. One-off captures sometimes get treated as project capex, complicating cross-year amortisation.
Pre-approval cycles. Annual programme captures align naturally with annual budget cycles. Monthly captures need quarterly or annual aggregate approval (most procurement processes don't approve monthly captures individually).
Reserve for re-fly contingency. Realistic programmes include 5-10% reserve for re-fly or expanded scope on specific cycles where capture conditions justify it. Without the reserve, every variation becomes a separate procurement event.
Year 1 vs steady-state cost. As covered in the first-capture article, year 1 carries setup overhead absent from year 2 onwards. Worth structuring contracts to make this explicit rather than averaging the differential across the programme.
What an operator gives a programme client that a one-off client doesn't get:
Priority access during peak demand. When weather windows are tight or capacity is constrained, programme clients are ahead of one-off clients in the operator's queue. Material during fire-season post-event work, end-of-financial-year demand spikes, or any time when capacity matters.
Locked pricing through inflation. Multi-year fixed or indexed pricing protects against the year-on-year inflation that one-off captures absorb. Particularly valuable in high-inflation periods.
Capability development specific to your sites. The operator invests in classification parameter tuning, flight plan optimisation, processing pipeline refinement, and stakeholder relationship building specific to your programme. None of this carries to a one-off relationship.
Institutional knowledge accumulation. The operator's team knows your site, your conventions, your reporting cycle, your downstream consumers. Comms shortcuts and project shortcuts that one-off clients have to re-explain each time.
These benefits are real but invisible at the per-cycle line item. They're the reason multi-year programme rates are lower per cycle than equivalent one-off — operators value the demand certainty enough to share the value.
Programmes need explicit change management because they span multiple years and demand will shift:
Site additions / deletions. New site joining the programme; old site decommissioning. The MSA should specify how additions are priced (typically per-hectare schedule) and how deletions affect the aggregate pricing.
Accuracy spec changes. New regulatory requirement tightens the residual tolerance. The MSA should specify how this is handled — variation order against existing rates, or re-procurement.
Format / consumer system changes. Your downstream tools change; the deliverable format needs updating. Worth pre- specifying how format changes get implemented (usually a one-time configuration cost + ongoing standard delivery in the new format).
Operator capacity changes. Operator's team grows or shrinks; their ability to deliver your programme changes. The MSA should specify continuity-of-service requirements and what happens if they're not met.
Less talked-about but worth designing in from the start:
Archive handoff. At programme end, what raw archive is transferred to the client? In what format? Worth specifying because it's the deliverable that determines whether the next operator can pick up the programme.
Knowledge documentation. Capture plans, processing parameters, classification configurations, control mark register, stakeholder contacts — all the institutional knowledge accumulated. Worth requiring as a programme-end deliverable.
Re-tender thresholds. What triggers a re-procurement event? Length of relationship? Significant scope change? Performance issue? Setting these up front avoids defensive contract behaviour later.
Four patterns we see in poorly-designed programmes:
Over-frequent capture. Monthly captures generating deliverables the team only reviews quarterly. Generating data faster than it can be consumed is paying for capability that isn't used.
Under-frequent capture. Annual captures of a site changing on a monthly timescale. Missing the change you're trying to detect because the rhythm doesn't match the underlying process.
Single-vendor lock-in without exit criteria. Five-year programme with no defined performance thresholds or termination conditions. By year three the relationship has calcified; switching costs (archive handoff, knowledge loss, re-onboarding) are higher than just continuing regardless of how the operator is performing.
Not aligning capture cycle with reporting calendar. Quarterly captures landing in months that don't align with quarterly board reporting. The data exists but doesn't fit the consumption rhythm; value falls.
The fixes are mostly upfront design rather than mid-programme correction. Worth investing the procurement-stage effort.
The shift from project to programme commissioning is real and worth designing deliberately. Five things change in kind: contract structure, scope template, capture cycle, deliverable rhythm, vendor relationship continuity.
Frequency by use case: monthly (mining), quarterly (network compliance), annual (environmental + infrastructure), multi-annual (long-term baselines), event-driven (post-event audit).
Deliverable rhythm: full baseline at year 1, differentials in between, annual re-baseline for currency.
Contract patterns: MSA + Work Orders (most common), Fixed-Price
Strategic value of multi-year commitment: priority access, locked pricing, capability development, institutional knowledge. None of this appears on a per-cycle line item but it's what makes programmes economically beat one-offs.
Four design mistakes worth designing around: over-frequent capture, under-frequent capture, lock-in without exit criteria, misaligned capture/reporting calendars. All correctable upfront, expensive to correct mid-programme.
Tell us the sites, the cycle frequency you're considering, and the consumer systems the data feeds into. We'll scope an MSA + Work Order structure with steady-state pricing, baseline handling, and the change-management terms upfront — so the third and fourth captures don't re-litigate scope from scratch.
The foundational capture that establishes the baseline every subsequent programme cycle compares against.
The upstream question — for organisations whose programme demand exceeds the commissioning break-even, ownership may be the right answer rather than longer programme contracts.