Prediction 1: Is this the beginning of the end for design-build procurements?
As bespoke IT projects become more ambitious with larger scopes, they also become more likely to be delayed, over-budget, or unfortunately, to fail outright.
New Automated Fare Collection (AFC) projects must deal with a plethora of new channels and technology expectations. These include adding account-based ticketing with fare capping, cash digitization, retail networks, contactless EMV, mTicketing, MaaS API’s, and journey planning aggregation. Additionally, the pace of technology change is far faster than a traditional 10- to 15-year procurement cycle, so buying once as a shrink-wrap might be short sighted.
In 2020, it will become increasingly likely that if a procurement asks for something to be built or assembled from components to each agency’s exact specification, the IT projects underneath will be difficult for agencies to implement.
The high levels of skills required for the assembly, testing, and debugging of such complex systems would require the “A team” from vendors. However, this level of expertise is usually only deployed on the largest of clients. Relying on the “C teams” to deploy a complex newly assembled package of components for several mid-sized agencies is a risky tactic that might lead to poorer results. Thus, it puts the mid-size and smaller agencies at a disadvantage in deploying the latest AFC technology, if they try to buy with a complex and bespoke RFP.
Therefore I predict that, outside of the very largest agencies with large technology teams, many agencies will begin to switch away from design-build procurements.
Outcome-based procurement: Instead, agencies will turn to lighter outcome-based procurement style projects. In those cases, something more like a traditional Request for Information (RFI) with high level goals and agency/passenger outcomes as targets will be used to illicit binding quote responses.
>> If done right and avoiding bespoke features, more of the responses could be based on “off the shelf” fare payment platforms that would be ready to use after simple configuration rather than needing any development or custom assembly.
>> The procurement team’s focus will switch, spending less time creating large and complex RFP and more time comparing the various responses it would have received. Focusing on what you can get off the shelf rather than taking the risk on large RFP specifications and their resulting deployment projects will result in the simplification of the whole process.
>> Turning to Fare Payment-as-a-Service (FPaaS) platforms saves agencies from undertaking large, costly, time consuming, and bespoke IT projects, by buying into shared platforms that have already had complex features deployed and debugged.
>> They also benefit from new features being added centrally and offered to customers on the platform without them needing to re-procure a new system. Thus, I predict the rise of FPaaS and the fall of design-build procurements in 2020.
Prediction 2: Mobility-as-a-Service will not be about mega-apps from cities but about a selection of journey planning and urban mobility aggregators offering multiple transit modes.
At first glance, we might think that MaaS will be about mega-apps commissioned by big cities, but when taking a closer look, this outcome is actually highly unlikely especially if implemented using a design-build-operate-maintain approach to systems delivery. A city commissioned application will never be able to provide and keep pace with the best-of-breed functionality, leading urban mobility applications are able to deliver.
Riders needs vary significantly: Relying on a bespoke city-commissioned app to be the best mobility solution is not pragmatic as it assumes that all customers would be happy with one app experience. The reality is that riders needs vary significantly.
>> Many riders are regular commuters that don’t want to do a zip code to zip code plan before getting tickets and journeys as they already know their route — they just want the simplest way to prove they have paid and board their regular transit.
>> Tourists and visitors will want more handholding, some riders will like additional features and offers, others might hate it.
>> Also, visiting riders will often already have a favorite mapping or planning app installed, and will often not want to install a new app for each city, and in most cases won’t even think to look for it.
The constant competition between the giants in the mapping space yields new features and benefits each year, which a city-commissioned app is unlikely to be able to match the pace of innovation or investment. So instead of trying to beat them, join them.
Enable practical MaaS: This means the key to enable practical MaaS is that each transit operator should offer APIs and SDKs, including unified payment to enable global aggregators and journey planners to offer and fulfil journeys. That way travelers’ experiences will not be deteriorated by having to load multiple local transit cards or sign up to three different scooter hire companies.
>> The ideal for an agency could be to have its own simple app for local commuters, and to have a presence on more complex third-party apps as well.
>> Choosing that route will increase convenience for all, and give more choice for different rider groups to stick with their preferred journey planning experience, gaining new features as the journey planner apps continue to compete and evolve.
Integration through APIs and SDKs: The best way to possess a presence on various apps is integration through APIs and SDKs. Yet, it is difficult for each aggregator app to integrate into multiple different single-city bespoke solutions. For a small- or medium-sized agency, negotiating with big brand MaaS apps, such as journey planners to integrate their relatively small metro network can be difficult.
Put simply, they neither want nor need this hassle. Instead, we’ll see increasing numbers of agencies subscribe to a FPaaS platform with whom these agreements and third-party journey planner integrations are already in place. Platforms that can integrate the popular MaaS apps, such as Transit and Uber, which people are already using with multiple cities behind one API or SDK will be on the rise in 2020 as more agencies look to add “practical MaaS” apps into the transit experience they offer their passengers.
>> For MaaS to really be the answer to high-density urban mobility without requiring a private car, easy access to multiple transit modes will be vital. Restricting people’s choice and access to only one type of transit will come to be seen as wrong-headed.
Multi-transit and service approach: The challenge in 2020 will continue to be addressing the congestion in our towns and cities; it is clear that only by taking a multi-transit and service approach will society have a sustainable, practical, and achievable way of meeting the growth targets set by governments, authorities, and the citizens themselves without everyone living half their lives in a traffic jam.
>> The MaaS promise is not only about making transit ticket purchasing easy, it is about making the first-to-last-mile travel experience seamless to the passenger and this should be feasible for short and long-distance trips. This goal is the reason why collaboration is an important aspect of MaaS. Collaborative apps such as EZFare, which counts 13 agencies working together, is delivering on that aspect.
That is why I predict the rise of MaaS for some rider groups, but not as a closed “mega-app” but as an open ecosystem of journey planning and urban mobility aggregators offering multiple transit modes. Moreover, I am convinced that choice, competition, and preferably having these options in the global apps that riders will carry between cities is a more efficient way to raise the awareness, discoverability, and convenience of transit, and most importantly, to decongest cities.
Ben Whitaker is founder and head of innovation at Masabi
See all comments