The £20,000 Problem: How Parliament's Longitude Prize Invented Modern Outcome-Based Software Commissioning
The £20,000 Problem: How Parliament's Longitude Prize Invented Modern Outcome-Based Software Commissioning
The Longitude Act of 1714 was, by any reasonable measure, an act of institutional desperation. Britain was the pre-eminent maritime nation on earth, yet its sailors were dying in preventable shipwrecks because they could not reliably determine their east-west position at sea. Parliament, having watched 2,000 men drown off the Scilly Isles three years earlier, decided to put a price on the solution. The result was the world's first formally structured open innovation challenge — and one of the most instructive case studies in the history of technology commissioning.
The lessons embedded in the Board of Longitude's turbulent forty-year operation are not merely historical. They are directly applicable to any organisation that commissions software, manages innovation programmes, or finds itself caught between stakeholders who disagree about what a successful outcome actually looks like.
Defining the Problem Before the Solution
The Longitude Act was remarkable for its specificity. It did not prescribe a method. It did not favour astronomical approaches over mechanical ones. It defined the outcome — a method capable of determining longitude to within half a degree at sea — and offered a graduated prize structure that rewarded proximity to that outcome even when the full standard was not met. This was outcome-based procurement before the term existed.
Contemporary software commissioning frequently inverts this approach. Organisations specify solutions — particular technologies, specific architectural patterns, named platforms — rather than outcomes. The consequence is that suppliers optimise for compliance with the specification rather than achievement of the underlying objective. A system can be delivered that meets every documented requirement whilst failing to solve the problem that motivated the commission.
The Longitude Act's model suggests a more productive structure. Define the measurable outcome. Specify the acceptance criteria with enough precision that any reasonable evaluator can determine whether a submission meets them. Leave the method to the people being commissioned. This approach is uncomfortable for procurement teams accustomed to detailed technical specifications, but it is the structure that produced Harrison's chronometer — a solution that no specification committee would have thought to require.
Harrison and the Working Solution Nobody Wanted
John Harrison's H4 chronometer, tested in 1761, achieved what the Longitude Act required. It determined longitude to within eighteen miles on a transatlantic voyage — well within the Act's half-degree standard. By any objective reading of the acceptance criteria, Harrison had won. The Board of Longitude declined to pay.
The reasons were various and, in retrospect, revealing. Nevil Maskelyne, the Astronomer Royal and a Board member, had a competing solution: the Lunar Distance method, which used astronomical tables to calculate longitude. Maskelyne was not simply venal, though his treatment of Harrison was shabby. He genuinely believed that a theoretical method based on celestial mechanics was more elegant, more reproducible, and less dependent on a single craftsman's ingenuity than a mechanical device that could be lost, damaged, or prove impossible to manufacture at scale.
He was not entirely wrong. But he was asking the wrong question. The question the Act had posed was not which solution was most theoretically satisfying. It was which solution worked reliably in the hands of ordinary sailors on actual ships in actual weather. Harrison's chronometer answered that question. Maskelyne's tables, whilst accurate, required skilled astronomical observation under conditions that frequently did not obtain at sea.
This conflict — between the elegant theoretical solution and the unglamorous working one — recurs throughout the history of technology. It appears in every organisation where architects favour beautiful systems over functional ones, where procurement committees weight proposal quality over delivery track record, and where internal politics shape technical decisions that should be governed by evidence. The Board of Longitude did not invent this dynamic, but it documented it with unusual clarity.
Stakeholder Conflict as an Architectural Force
The Board of Longitude was not a unified body with a shared view of success. It contained astronomers who believed the solution must be celestial, naval officers who wanted something their crews could actually use, mathematicians who doubted any mechanical device could achieve the required precision, and politicians who were spending public money and needed to be seen to be rigorous. These constituencies had genuinely different definitions of what a successful outcome looked like.
Software projects rarely acknowledge this openly. Requirements documents present a single, apparently unified view of what the system must do. Acceptance criteria are written as though all stakeholders agree on what acceptance means. In practice, the project manager, the technical lead, the business owner, and the end user frequently have incompatible definitions of success — and those incompatibilities surface at the worst possible moment: during acceptance testing, at go-live, or during the post-implementation review.
The Board of Longitude's dysfunction offers a perverse but useful model: make the stakeholder disagreements explicit before the work begins. If the Board had been required to define, in advance, precisely how H4's trial results would be evaluated and who had final authority over the evaluation, Harrison's decade of additional delays might have been avoided. In modern project governance, this translates to a pre-defined acceptance authority — a named individual or group with documented criteria for sign-off — established before development commences, not negotiated after delivery.
Open Innovation and Its Discontents
The Longitude Prize attracted submissions from across Europe and beyond. Most were unworkable. Some were eccentric. A few were genuinely interesting but ahead of the available technology. The Board's challenge was to evaluate this heterogeneous set of proposals efficiently, distinguishing credible attempts from noise without dismissing unconventional approaches prematurely.
This is the central tension of any open innovation programme, and it has not become easier to manage in three centuries. Modern hackathons, innovation challenges, and open procurement frameworks face identical problems: how do you create evaluation criteria rigorous enough to filter noise but flexible enough to accommodate solutions you did not anticipate? How do you prevent the evaluation committee's existing assumptions from systematically disadvantaging unconventional approaches?
The Board's partial answer — graduated prizes for partial achievement — is worth adopting. Rather than binary success or failure, a graduated reward structure acknowledges that partial solutions have value, that progress towards an outcome is worth recognising even when the full standard is not met, and that the innovation process is iterative rather than instantaneous. Modern equivalents include milestone-based contracts, innovation sandbox programmes that provide resource without requiring complete solutions, and staged procurement processes that allow promising early-stage approaches to develop further before full evaluation.
The Acceptance Criteria Lesson
Harrison finally received his full prize in 1773, after a direct appeal to Parliament that bypassed the Board entirely. He was eighty years old. The entire episode, from the 1714 Act to his eventual payment, had taken fifty-nine years. The problem was solved within the first decade. The remaining five decades were consumed by governance failures, stakeholder conflict, and the absence of a clear, enforceable acceptance authority.
For any team that has watched a completed, working piece of software sit in review for months whilst stakeholders negotiate what acceptance actually means, Harrison's story is not merely historical. It is a warning. The technical problem is rarely the hardest part of a software commission. The hardest part is agreeing, in advance and in writing, what done looks like — and ensuring that the people who will make that determination are identified, aligned, and empowered before the first line of code is written.
Parliament stumbled into outcome-based commissioning in 1714. It then spent the better part of a century failing to execute it properly. The tools available to modern engineering organisations — agile contracts, defined acceptance criteria, pre-agreed evaluation authorities, staged delivery milestones — represent the accumulated learning from exactly these kinds of failures. The Board of Longitude would have benefited enormously from a well-written statement of work. So, very often, do we.