The Victorian Auditor General’s Office (VAGO) has just tabled a report into the ‘Operational Effectiveness of the myki Ticketing System’. For those of you who are Melburnians or who have visited Melbourne, you will know how much this ticketing system is despised. Even more than Collingwood. Myki was meant to make public transport travel so much easier in Melbourne and the State of Victoria. But it hasn’t turned out that way. The reason myki is so hated my Melburnians is that it is a big, expensive IT project that has gone horribly wrong, yet our Government in their wisdom decides we should live with it despite its many shortcomings and having the opportunity to use a cheaper alternative. Unfortunately, this is a global phenomenon: in the UK there is the NHS computer system and in the US there is healthcare.gov. Some consultants have claimed that 75% of IT projects fail. Why do so many big, expensive IT projects fail to deliver? What can the sorry, sordid tale of myki tell us about why IT projects fail? And what can we learn from it?
‘Initial Governance and Contractual Arrangements Deficient’
This could mean several things. It could mean you don’t even know what you want to achieve. In the case of myki, the Transport Ticketing Authority (TTA) knew they wanted a new smartcard ticketing system but didn’t know what that meant. So what did they do? They got a potential bidder (Keane) to write the specifications for the tender. Funnily enough, Keane’s consortium (Kamco) won the tender.
It could also mean there were no checks and balances to prevent alleged corruption. The CEO of TTA was a shareholder in companies that were part of the Kamco consortium. This is despite already being paid more than the Prime Minister of Australia (already one of the highest paid political leader in the world).
Maybe it could mean choosing the wrong vendor or technology to realise the sought for benefits. As a result of the compromised tender selection process, Kamco was chosen despite lacking experience in implementing similar projects. In fact, it faced stiff competition who have worked on the Oyster technology (used in London) and a consortium that successfully implemented the Hong Kong Octopus smartcard. The London Oyster and the Hong Kong Octopus successfully dealt with much greater volume and complexity than myki ever would. In fact, the Octopus card can also be used to purchase goods and services at participating shops.
A deficient contract could mean the vendor has built in clauses that gives it perverse incentives. Despite numerous cost overruns and timelines blowing out from two to nine years, myki was able to survive despite the Government acknowledging that it “[it’s] already cost us big time…we don’t want to throw good money after bad”. The threat of litigation by Kamco forestalled any government action to cancel myki.
The Customer is Always Right
That is, if you have any idea of what customers want in the first place. Even if you do, your technical people get lost in the detail and forget why they are building the system in the first place. A casual observer of the myki saga could be forgiven for thinking that customers were not front of mind when Keane contributed to the drafting of the tender documents. Or when the CEO of TTA accepted shares in the Kamco consortium that won the tender. Or choosing an inexperienced vendor to develop and operate the myki system when more experienced (and cheaper) vendors also submitted bids. Or why loading your myki card can take anywhere from 24 hours to three weeks to process. One would think that while there will be inevitable teething problems, if you spent $1.55 billion you would get a system that was at least as efficient as the $100 million Hong Kong Octopus or the $78 million Singaporean EZ-Link. [Fun fact: ERG is actually an Australian company that successfully implemented the EZ-Link as part of the ERG-Motorola Consortium. ERG have continually offered to replace myki with a system that would cost $100 million. Governments have declined these offers.]
What does it mean to be customer-oriented in the context of an IT project? It could mean setting up a project governance board with a person from marketing or finance to keep on asking why another drop-down menu is needed, or can transactions be processed faster or make the website more user-friendly. Sure, people from marketing and finance are annoying because they don’t have a clue about the magical world of coding and wear shiny suits, but that is the point – they know the customers better than a programmer ever would. In fact, it is their job to bring money into the organisation if it is a for-profit business, or to not aggravate voters that will in turn aggravate Ministers if it is a government organisation.
Big Isn’t Always Better
In fact, past a certain point there could be diseconomies of scale. The project becomes a mini-bureaucracy with too many layers inhibiting communication that could manage risks. One of those risks is corruption. As we know now, the myki tender process was highly compromised and the administering organisation’s CEO was, to put it mildly, non-compliant with conflict of interest guidelines. No one on the project is going to argue with the CEO – that would be career suicide. Smaller projects on the other hand can deal with risks more effectively because communication is more open and the project team is more in touch with customers.
You Can’t Manage What You Can’t Measure
An important part of ongoing project management is to track it’s project. Unfortunately, myki is unable to do this because according to VAGO:
- “Deficiencies in the initial contract compromised implementation due to:
- poorly defined functional requirements
- lack of flexibility to address underperformance”
And for myki’s operation:
- “Current metrics do not address key aspects of performance
- No framework for assessing myki’s overall effectiveness, efficiency and benefits
- PTV [Public Transport Victoria, the replacement for TTA] does not adequately assure reliability of results reported by the contract”
So, the people of Victoria basically have no idea what we have paid $1.55 billion for.
An obvious point to make here is that in order to define metrics you have to be clear on what outcomes you want to see happen. Yet, for reasons discussed above, this was not the case. But myki isn’t the only example of IT programmers gone wild. In both private and public organisations, they see the IT system as the end goal rather than as a tool so they have completely missed the point of what their customers want.
This Sounds Like My Project Management Course, Why?
Maybe because even big, expensive IT projects aren’t really about the technical aspects of coding and hardware. It is about managing the relationships within the organisation to deliver a project. If there isn’t a strong business case that all parts of the organisation buy-in to, it is likely to face obstruction or be starved of resources.
Unfortunately, organisations think the way to improve success rates is to make their project managers more technical. In addition to having a managerial role to ensure delivery and manage relationships, IT project managers are expected to be technical leads. This is two very different roles in one person. Sure, some people are extraordinarily capable in both technical and business skills but most project managers aren’t. This is just an attempt by organisations to reduce costs at the expense of project delivery; you save on having a technical lead but you increase delivery risk.
So, the good people of Melbourne will continue to live with the IT white elephant of myki a while longer. It probably wouldn’t cheer up their mood to know that it could’ve been avoided by using basic project management principles. At least they can always look forward to their team beating Collingwood.