Chapter Six: Procurement Pitfalls

<< Go back to Part 5: The Role of the Payment Service Provider

Overview

For the most part, transit agencies around the world acquire their ticketing and payment systems through government regulated procurement processes. Poorly designed tender processes and evaluation criteria can lead to perverse outcomes, increased risks, and as we’ve seen far too often in public transit, massively delayed deployments with budget blowouts.

At Littlepay we’ve seen our fair share of these procurements, and have learned a few lessons. We’ll share them here in the hope that we save the next transit authority from becoming another case study.

Don’t lose sight of the bigger picture

What is the ultimate purpose of a public transit ticketing procurement? Surely it should have something to do with delivering convenience and value to commuters and passengers. Yet somehow, instead of trying to deliver this convenience quickly and efficiently, we see procurements with overly complex requirements that take many years to deliver functionality customers don’t really care about.

Around the world passengers have voted with their wallets and phones indicating that they have a strong preference for the convenience of open payments. Yet we see in Melbourne (ironically, Littlepay’s home-town), the government awarded a $1.7bn contract (that’s billion!) to fully replace the much maligned Myki ticketing solution with an account based ticketing system. This will enable open payments to the long suffering commuters of Melbourne over the next 3 years, nearly a decade after Sydney enabled bank card payments. This despite the fact that the existing system could have been initially upgraded to provide open payments to the majority of people at a fraction of the cost within 6 months.

Similarly, the New Zealand Transport Authority commenced their procurement of a complex national ticketing solution with a market sounding in 2019, then awarded the contract in 2022, and will now be delivering open loop to the public in 2026, assuming the project is delivered on time, which appears unlikely. These kinds of projects are never on time.

On the other hand, over the past 2 years, Littlepay has delivered open-loop payments to 10 cities across Finland, in simple rapid succession, with next to ZERO capex (other than validator upgrades)! In California, Littlepay worked with Cal-ITP who wished to demonstrate open loop with agencies in the state before procuring device and payment processing services for a statewide framework. Littlepay was selected as the sole payment processor for all of the initial Cal-ITP pilot deployments in Santa Barbara, Monterey-Salinas and Sacramento and has since been awarded all 8 projects which have since acquired services from the framework with many more expected to launch in 2024. 

While it’s true requirements can vary by city size, network complexity, and other factors, the stark differences in implementation outcomes and costs are not explained by these factors alone. We would suggest the varying outcomes have more to do with how these procurement processes are designed, and a number of key decisions made by transit agencies, which we’ll explore below. As we do so, it’s worth keeping in mind Conway’s Law:

Paraphrased, Conway’s law suggests that:

If the procurement project involves a large, complex, bureaucratic team, you are likely to end up with a large, monolithic, inflexible, and probably expensive transit ticketing system. 

If success is defined as the delivery of a system with a wide scope of complex requirements, you’ll end up with a complex, multi-year project with many delays.    

If you rely on consultants incentivised by daily rates to design the solution, you’ll end up more complex proposals that take longer to deliver. 

You get the gist.

So, what are the key decisions and trade-offs to consider:

Big Bang v. Agile 

Government procurements are time consuming and expensive, so there’s a preference to do fewer of them. For this reason, too many RFPs succumb to the temptation of incorporating every foreseeable requirement, depriving customers of the higher value features they could enjoy much sooner.   

This is the ‘Big Bang’ approach to delivering a specific solution detailed by ‘requirements’. In the famous analogy by agile expert Henrik Kniberg, it’s like specifying your solution as a car, and then building the components of a car in stages until you build the finished product you can then use.

Big Bang - deliver a solution

This is the approach we often find with transit ticketing procurements. Consultants will design a solution hoping to capture every foreseeable needed technology including ABT, Open loop, Journey planning, and then put these as the requirements of an RFP to be delivered over a specified timeframe of several years. These projects then inevitably run into long delays and cost overruns, as with SEPTA and Melbourne Myki.

In an alternative ‘agile’ approach, the focus would be on delivering an outcome for the customer. Instead of focusing on the solution (as a car in the analogy above), the focus would be on the outcome (which is to move someone from A to B). This approach focuses on delivering the earliest usable product for the customer (e.g. a skateboard) and then iterating your way to the full set of features.

Agile - deliver an outcome iteratively

In the context of transit ticketing, this might be the delivery of open payments, which the customers view as the highest value feature, followed by the addition of registration and account functionality, and then gradually other features based on customer feedback. This customer-centric approach delivers value sooner, and lowers risk of delivery.

This is the approach Littlepay has taken in California. Iterative deployments, with new partners being integrated into a modular solution. Delivering what the passengers want the most first (open payments), and then adding new functionality.

Modular v. Vertically Integrated

Modularity and agility go hand in hand. You could say the former is a prerequisite for the latter. You simply cannot be agile while dependent on the delivery of a fully vertically integrated solution by a single vendor.  

In the same way that you don’t need to throw out your monitor and keyboard when you upgrade your laptop, a modular ticketing system gives transit agencies the flexibility to upgrade and future proof their solutions in a lower risk way.

Government RFP documentation and selection processes were designed in an era of bespoke systems that were built from the ground up. As Conway’s law predicts, the RFP process will bias the outcome in favour of legacy vertically integrated systems.

Avoiding a monolithic system, and drive towards modularity requires upfront design decisions regarding the architecture and interfaces of the system. This in turn needs to be reflected in the tender process to attract vendors who can work in an agile and collaborative model.

Prime v. Parcel

Many government procurements continue to be structured with a ‘prime’ vendor, based on the idea that having “one throat to choke” will reduce contract and supplier management complexity, and increase accountability. This is simply a false comfort that often leads to adverse outcomes.

If you start with a premise of ‘how do we mitigate failure’ as opposed to ‘how do we achieve success’ then every subcontractor will be working to the lowest common denominator focused on avoiding penalties and break clauses instead of delivering innovation and value. ‘One throat to choke’ leads to a cascading contractual ‘pass the buck exercise’ where accountabilities are obfuscated by a ‘prime vendor’. It’s also a cheap trick by procurement teams to pass the risk down the line to those who have to deliver. 

What comfort is there in being able to charge the vendor penalties, when your project is disastrously delayed and every penalty is offset with a more expensive change request.   

Cloud services, microservice architectures, and API’s have destroyed the already questionable rationale that underpinned ‘one throat to choke’.   

At Littlepay we’ve integrated with dozens of hardware vendors, acquirers, and back-offices, and proven parcelled procurements can be delivered with much lower risk if designed well. With this architecture comes more transparency, clearer accountabilities, and better delivery. 

Consultants v. Practitioners

Consultant can play a helpful and important role in supporting a government agency through a procurement process. But every consultant brings to the table their own experiences and biases. If you hire consultants with prior experience working for large vertically integrated systems, you’re likely to get a process and solution that points you in that direction.

Consultants love complexity and transit ticketing and payments is a complex domain. Another iteration of Conway’s law might say “The complexity of your system is proportional to the number of consultants involved in the design”.

We’ve seen too many procurements and deployments fail based on the complexity of requirements by consultants who are too far removed from today’s practices. A classic example was the expensively aborted project ABBOT (which had several failed iterations).

ABBOT was an attempt to create a regional government-owned platform that could unify multiple ticketing systems to provide passengers with multi-modal ticketing. With hundreds of requirements detailed in the minutia, this project was always bound to implode on the weight of its own complexity. By focusing on requirements, vendors scramble to comply with requests, often underestimating the time and cost of delivery.

In our experience, effective and constructive engagements with consultants occur when the transit agency has a clear understanding of the outcomes it wants to achieve. This understanding is gained through early engagement with practitioners in the industry. By focusing on outcomes instead of requirements, we can understand what various systems and approaches can offer, and move with more agility.  

The good consultants will be open minded and focused on higher-level outcomes, giving practitioners the freedom to come up with different innovative solutions to address these. 

Structuring a procurement process

Now that we understand some of the trade-offs, here are some of our learning from the more successful deployments we’ve encountered.

Learn what’s possible

With the introduction of cloud based SaaS and modular services, transit ticketing has evolved greatly over the past decade. Options are increasing as new innovative vendors enter the market.

When Costa Rica’s central bank set out to bring contactless nationally across the transit network, they engaged industry ticketing vendors and the card networks over a 12 month period, to determine the approach they wished to adopt. This provided great clarity in the tender process, and allowed Littepay to deliver a national open-loop solution within a year of commencing the project.

Transport for NSW, perhaps the most technologically advanced and capable agency we’ve dealt with, are currently undertaking a 2 part process to learn what’s possible from industry practitioners, before the tender for Sydney Metro system. The first part was an ‘Industry Sounding’ where they put forward a proposed approach and asked the industry to comment on the approach. The next stage was an RFI which further refined their thinking prior to finalising the RFP documentation. 

Hire the right consultants for the right job

If you’re not sure where to start, talk to us first. We’ll give you some pointers and a few options and you can then make a more informed decision.

Pilot

Modular systems give you a chance to pilot some of the components of the system in a live environment, giving you valuable data to refine your final tender requirements and outcomes. 

Littlepay has integrated and certified with a wide range of hardware vendors that can be quickly deployed at very low cost to achieve this outcome.

In Helsinki, we ran a contactless open loop initial pilot using validators from two different vendors well in advance of the final hardware procurement, uncovering a range of additional considerations that were included in the tender.

In California, Littlepay ran small scale pilots in two cities for a simple flat fare deployment prior to the broader Cal-ITP procurement, giving valuable feedback and proof points regarding the performance of various devices relative to their promise.

Build in optionality

The Cal-ITP run procurement for California’s ticketing system introduced the innovative concept of a ‘vendor panel’ or framework to their process. Instead of having a single vendor in a ‘winner takes it all’ decision, they evaluated bidder responses and pricing, and approved a number of vendor offerings. Individual city agencies could then select from this panel at their own discretion, with pre-agreed commercial terms.

That is, a transit agency in California can select one of 3 device vendors, and one of 4 different back-offices without having to go through a new tendering process. This concept could have much broader applicability in larger agency tenders, which may need a range of different hardware for different use cases. 

Again, this comes back to modularity and the initial design of the solution allowing for this ‘plug and play’ approach to building an overall system.

Parcel your tender and let vendors bid on multiple lots

Breaking up the procurement into separate lots allows for greater competition while retaining the flexibility of having both specialist best-of-breed applications, as well as fully integrated solutions. 

Separate procurement lots for hardware (front office), payments (middle office), ticketing (back office), and System Integration (consulting) are logical. This approach allows for greater competition as smaller specialist vendors can bid on individual components, while also giving ample opportunity for large integrators to propose fully vertically integrated solutions by combining lots.

Do real reference checks to quality vendors

A common pitfall we’ve seen in a number of tenders is inadequate reference checking in the qualification round. There have been many instances of vendors claiming ‘qualifications’ in having previously deployed certain solutions, being awarded the tender on this basis, and then revealing that they don’t have production ready systems, or that the deployments are not actually live yet, or that they were referring to something totally different. 

Being able to process a payment in the retail context is not the same as open payments for transit.

An example of this is in the recent tender process in Melbourne, where references cited are now being disputed.  

Reference checking should be robust, very specific and validated. This is the work consultants should be able to do.

Scoring Respondents

We’ve seen a few tenders which have been won by the barest of margins, with a few thousand dollars on price being the determining factor between two vastly different solutions. It can only be the result of a poorly designed scoring system when the results do not show clearer separation between two very different systems.

You can have more flexibility in your decision making by:

• Adding more qualitative factors to the scoring 
  • Allocating points to a demo, or a pilot is an example of a qualitative scoring round
• Not overweighting one factor over all others.  
  • We’ve seen Total Cost weighted at 80% in some tenders, which creates a likelihood that an inferior and cheap solution wins on points. 

Don’t over commit

In a fast moving world, where new technologies are emerging, and modular flexible solutions allow for flexibility, there’s no reason for a tender to be awarded for an excessively long term.   

Ten to fifteen year contracts to a single vendor puts the transit agency in a difficult position if technologies change. This is a legacy from the bespoke-build days where hugely expensive systems needed long periods to recover costs.

Contracts for more modular solutions like those in Helsinki and California are for 3-4 years. This is a good benchmark for components that don’t require heavy capex commitments for bespoke solutions.

This chapter on procurement pitfalls concludes our Fundamentals of Transit Payments series. Throughout our exploration of the basics of fare collection, we delve into Contactless Payments (cEMV) in Transit, examined the Architecture of an Open-Loop Transit System, defined Fare Systems in Contactless, identified available Types of Hardware, and clarified The Role of the PSP. As this series concludes, we hope that you are now ready to make the move to contactless payments. 

Go back to Part 1: Introduction to Contactless Payments (cEMV) in transit >>

Ask for Help?

At Littlepay our mission is “To move more people through better payment experiences”.  Reach out to our team and we’ll be more than happy to help you along the journey.