#DPI 670M

[lgraberg-blog]

FLEXUS – The efficiency project that became a wound in the cityscape with political consequences

The way to hell is paved with the best intentions, but  if you automate a mess you get an automated mess.

<This blog is an assignment in the class DPI 670M at Harvard Kennedy School, where I am a student in the springsemester 2019>

Picture: https://www.tu.no/artikler/vil-heller-ha-app-enn-flexus/246735

This is a brief review of a digitization project that took place in Oslo, the capital of Norway, in the last decade. Due to major errors that prolonged the project for many years, they ended up spending $ 80 million on an obsolete solution.

The purpose of the project was to prevent people from taking public transport without paying a ticket.

The project goal was to replace the paper ticket with a common RFID Electronic ticketing system for all collective transporting in Oslo and its surrounding urban areas. This required common tickets and ticket validators.  At the larger metro stations in Oslo, physical barriers were set up in connection with the introduction of Flexus. It was estimated that about 80 percent of subway travel went to or from one of these stations. When a passenger reads a valid card, glass doors should open up and drop the traveler in - or out.  In this way, they should ideally ensure that everyone had a valid ticket and that registered traffic data was correct.This functionally is similar to the system Boston metro system has today.

The project was a collaboration between three parties that operated railways (NSB), the metro system and trams (Oslo sporveier), and busses and ferrys (SL), respectively. NSB ordered equipment from Swiss Ascom, SL from Australian-Belgian ERG and Oslo sporveier from Thales. This due to the situation that the various suppliers had expertise that best suited the various companies' activities.

Planned project period: 2000-2005

Estimated cost: 25 million USD (excl. Emloyee cost).

The prerequisites for the loan from the Oslo municipality were that the system should "build on known computer technology solutions" and that it was "proven with good experiences from elsewhere". In the application for the municipal guarantee, the equipment was characterized as "of-the-shelf".

In 2003 the project had spent 35 million USD (excl. emloyee cost).

In 2006, they decided to reorganize the project, and in Jun the new formal project organization was established.

Mid 2009: The project was partially implemented.

2011: The project was discontinued

 Money spent in the 2000-2011 timeframe:

71 million USD (excl. emloyee cost), which was almost three times the estimated cost.

The poor performance of the project resulted in political consequences, and it ended with a public hearing and distrust of the municipal leader in Oslo city.

So the question is – how is the even possible? How is it possible to struggle around in 11 years, spending a huge amount of the taxpayers money…… for nothing? Nobody would like this to be the end result - the way to hell is paved with the best intentions.

Picture: https://www.dinside.no/reise/oslo-har-fatt-nye-t-baneruter/60968306

Assessment of projects can be broadly divided into two main parts: the degree of product success and the degree of project management success (process). Eg. the opera house in Sindney. This was a disastrously poor project management process, but an incredible product success as a world-renowned landmark. The same cannot be said about the Flexus project. Unfortunately, the Flexus project failed on both of these axes.

Espen Eckbo is a famous Norwegian comedian. This video (only in Norwegian spoken language unfortunately) was made prior to a developer conference in Oslo in 2009. In the video he acts a developer who neither knows what the system should do, how the system is intended to be used or who his boss is. As he says in the video, "I'm not a religious person, but it's a miracle that I haven't been fired".

My main hypotheses in this blog are based on available information that I have acquired about this project. I have chosen to split these in two main areas with some sub-items:

Management

Project ownership and management

Communication

Competence

Technical issues

Dependency of legacy systems

Poor introduction testing

Lack of experience and ability to understand the complexity

Management

The various entities in projects with mutual dependence to each other need an overall joint decision-making unit. In this case, the three entities were supposed to cooperate, but did not have an overall responsible unit.

From one report, I could read that: "Because the collaboration became too difficult at first, one put the head in the sand and hoped it would pass. But it never does. It might just get worse and harder. The units wanted to protect their own systems, and no one has been able to impose the other on making changes”.

Strategic clarifications should be taken early, and overall strategic actors and stakeholders must be present in the process. In this project, the partners (the buyers) had different goals, and they had also ignored the users. One example was how they calculated the travelling cost for their customers. One unit had unit rates, the other had a zone system with 88 price zones and the last operated with distance tariffs. The lack of a capacity to make these kind of strategic choices was not built up as a part of the project structure, and therefore they used these as pre-requisites in the project. From my perspective, this led to an unnecessarily complex solution, rather than a simplification. It is important to be aware of such unused opportunities in a change project, especially in the initial phases. Dedicated resources with a mindset that questions the established system is a valuable capacity at this point. I think this was one of the core points that they failed, because it created a bad starting point which became decesive for further progress. They got a three-part, rather than a unified, approach. What if someone at an early stage had suggested another solution than the perpetual obstacles they chose? They could have been an early adopter of future solutions, and a reference for other cities.

Picture: https://www.aftenposten.no/norge/i/jdyaz/Flexus-er-doende---NSB-og-Ruter-vil-ha-egne-kort

The report from the municipal audit briefly concluded that the project was staffed with too few people and had too tiny expertise. According to Norway's most reputable and politically neutral newspaper, Aftenposten: “It seems that the project has sailed its own sea without central management, and that the project board did not receive information about the major delays”. With a too small staff in the project, as pointet out here, they also lack some exploring capability. Most probably they were stuck in a day-to-day focus to solve emerging problems.

Good meeting arenas and communication channels should have been created. This is always important, but especially in this case with three independent entities to interact.

Picture: https://www.vartoslo.no/etter-13-ar-fjernes-sperreportene-pa-t-banen-skandalesystemet-kostet-oslofolk-600-millioner-kroner/

Technical issues

The report from the municipal auditor makes major question marks on the project manager's and the project manager's technical expertise, and they question the realism of the project according to the limited resources that in the early phase should follow up and control the procurement. It seems like the suppliers got too much power and that the project management team never understood the extent of what was to be done. It may therefore appear that the project management has chosen to rely entirely on the suppliers. Trust is important, but at the same time one must be clear about what is the buyer’s responsibility and what is the supplier's responsibility. The buyer has money as a means, while the supplier has this as "target". And the opposite for the product itself. The buyer has the final product as the target, while the supplier has this as its means. This asymmetry is fundamental in a buyer-supplier relationship.

Out of order. Picture: https://bedrebillett.files.wordpress.com/2011/09/img_5071.jpg

Many projects that have failed, one has often oversimplified the problem and underestimated the complexity to be solved. This is reinforced by the quotation from the CEO in one of the co-operation units: “Adapting the “of-the-shelf” product was much more comprehensive than I had imagined”.

Picture: https://www.aftenposten.no/osloby/i/bKxq8B/Forventet-suksess_-men-endte-med-nedtur-Na-skal-disse-fjernes

The project also experienced emerging problems that pulled off project resources to solve adhoc issues.

As a following consequence due to the delays in the project, there were problems with the old paper-based machines, which according to the original plans had long been phased out. Some of the buses piston boxes had to be transferred to the trams, while bus drivers were referred to hand-stamp tickets and cards. It worked poorly during rush hour, and extra bad when one for a period lacked ink for the hand punches and had to let people run for free. "It is untenable and irresponsible to just see that revenue disappears by people driving for free. It is the pointless shop,” summarized the UniBuss director, who was responsible for 70 percent of bus operations in Oslo.

Cards, card readers and vending machines that have not worked have created additional problems with the introduction of the system. The annual report for 2011 states that "a customer-perceived uptime of readers of around 98%, and down to 92% on city buses, is far from acceptable."

In the autumn of 2010, they discovered that 30.000 cards, which had been in stock for too long, resulted in the inspectors not being able to read the information with their readers. By check, passengers with these cards got a fine and had to seek out the company themselves to prove their innocence before the fee was deducted.

All these events are examples that attract too much attention for the project, and need to be resolved immediately. With limited resources available, it is difficult to get sufficient progress in the project's main task.

The project also encountered adversity regarding testing the solution. Contract conditions were clarified in 2003, and the system was to be ready for trial operation in 2005. Tests were conducted, where the recipient accepted and signed the trial operation tests. The supplier Thales also assumed that the system was ready for trial operation. It was definitely not. On the contrary, it turned out that the whole project was in a critical phase. "It should never have been signed that the test of the system was successful in 2005" (CEO of Oslo sporveier).

Seen in retrospect, it is strange that they did not have a more professional test regime on a solution that should be used by the inhabitants of, and visitors to, Norway's capital. It does not appear that they conducted smaller tests to try out the solution in iterations. They have most likely chosen a traditional waterfall model. There is a high probability that the project's major challenges can be explained by this choice, where you are actually blind for much of the project period. (You actually know little about the product going to work).

In summary, we are left with the following:

Many units and different goals created barriers to the progress of the project

The tariff and zone structure remained unclear and the biggest problem

No responsible unit with overall responsibility

The users were not involved

The users' needs were not taken care of

They did not take passengers on advice and they did not take advice from the staff. It was the focus on income hedging.

If you automate a mess, you get an automated mess. Electronic payment is complex technology, but well proven. Problems with the technology were a consequence of the complex organization of public transport in the city of Oslo and the county of Akershus, including the complex tariff and the zone system

Postnote:

Five years after the access rafters were set up, they were still not used. In the autumn of 2011, both the barriers and the readers were disconnected, after passengers had been squeezed into the doors. Physical barriers can be a problem for evacuation of the stations by fire, accidents or the like!

Already in 2010 it was clear that the barriers would not be used. Only now (end of 2018, early 2019) do they start removing them, finally.

Today, the metro system is an open and trust-based system, where there is no need for barriers. The users are happy with a easy solution, and the vast majority of the traveler buy the ticket with the app via smartphone. This applies to both single trips and period cards. It is efficient and reliable. Effective random checks are conducted on a regular basis if the traveler has a valid ticket. It is still possible to buy paper tickets, but this is both more expensive and more demanding. The population of Norway is eager to use digital solutions. The solution works seamlessly between all public transport means, and the cost sharing is a software-based distribution solution. There are now two companies that cooperate. Train transport is handled by NSB (Norwegian state railways), and other public transport is handled by #Ruter.