Categories
Customer Success Digital Transformation Insights library Payment Solutions

Are Payment Platforms in Australia on the Right Track?

by Paul Scott, Director and Board Advisor at Digital Village

Photo by Ronaldo de Oliveira on Unsplash

Payment Platforms are often referred to as the rails on which commerce transacts. It’s an interesting analogy, given the gauge of rails used today on most of the world’s train tracks were established by the Romans over 2,000 years ago, and has not changed significantly since in most parts of the world. Payments Platforms haven’t been around for the equivalent of seconds, but we have multiple incarnations, and none entirely seems to meet customer needs.

Technology can be tricky bedfellow. Take payment platforms for example. Before ‘digital’ was even a twinkle in John Vincent Atanasoff’s eye, banks were using multiple payment reconciliation methods — all paper-based of course. Records were kept in dusty ledgers scribed with ink pens by crusty men in starched shirts and voluminous morning coats.

Roll forward 90 years, and here in Australia, we have an abundance of digital payment platforms. Which is odd, because usually when technology replaces manual processes, you’d expect some degree of consolidation, streamlining and a leap forward — innovation perhaps.

Eftpos was born some ten years later and stands for electronic funds transfer at point of sale. It’s principally aimed at credit, debit and payment terminal transactions. Its also owned by the big four banks via a company called Cardlink.

BPAY was established in 1987 by the big four banks in Australia. It was the world’s first phone-based payment system. Nowadays its a full-blown digital bill payment platform.

The New Payments Platform is owned by 13 banks. It’s the new kid on the block, formed in 2013 and launched to the public in 2018. They were given an innovation mandate and launched an instant settlement process which uses phone numbers, email addresses as well as ABN’s.

Between them, each of the three principle payment platforms serves every business and consumer in Australia, but why three? Well, it’s a result of several factors, federal, industry institutions, regulators and the banks all had a hand to ensure the applecart remains upright.

Now there’s a move to seek consolidation, but just how long that will take and what the composition of the outcome could look like is anyone’s guess. There’s a bucket-load of vested interest and the glacial pace of change in banking to consider. In their wisdom, Australian Payments Council chair Robert Milliner has been appointed as the independent convener of a special industry committee examining NPP Australia’s proposed merger with BPay and Eftpos.

Robert Milliner

Not content with the existing complexity APC’s decided to have Milliner’s committee operate within a NPP-owned subsidiary, Industry Administration Committee Pty Ltd (ICA).

The purpose of ICA is to establish a governance framework for “making non-binding recommendations” on the merits of merging NPP Australia’s operations with the two domestic payments schemes.

The technology aspect of this is interesting. It’s a classic case legacy myopia. The core systems underpinning BPAY and Eftpos are 40 years old. Ask any digital solution builder what they’d recommend its likely to be ‘Reno’ versus ‘Doer-Upper’. In other words, it would be easier, quicker and better to build from scratch. Why? Because it takes 1/10 of the time to build the equivalent of 40 years ago and costs a fraction of what it takes to consolidate and build on top of existing computer code.

Speaking to people like Andrew Walker — the Impatient Futurist and you understand the logic. He’s spent a career showing retailers, banks, and insurance companies that building and consolidation on top of old systems is a waste of money and never delivers the desired outcome. Better to start with a blank screen, start solving one problem at a time and deliver outcomes users need.

Likewise, a senior executive in one of the three principal platforms explained it as follows: “Another industry insider concluded: “I feel the big four banks, in their current form, are not good for Australia, particularly over the longer term. They need to innovate, with a view to extending their business into a ‘platform’, with open support and collaboration for new entrants. An ecosystem if you will. Only this will deliver useful products and services to the Australian market and ensure the ongoing relevance of the big 4.” He concluded: “Otherwise, bring on the ‘asteroid’ for these dinosaurs.”

What happens next? Well, major shareholders in each of the platforms — the banks — will examine the landscape, sound out the regulators and oversight boards and decide what they can get away with. Sorry, I mean they will have an epiphany, recognise the extraordinary opportunity they have to leap forward with a new technology solution to payments people want and need. Maybe.

Categories
Agile Customer Success Digital Transformation Insights Lean Startup System Engineering

What Dev Teams Are Missing.

UX designers, check. QA designers, check. Developers, check. The list goes on… but most highly-trained dev teams are missing a vital piece of the puzzle.

Software development is an inherently technical activity but without solving a real human need a project has no purpose. So why are those with the most immediate needs, the arbiters of purpose in this instance, missing from the team?

Standard processes for software development demonstrate the issue (sometimes jovially).

@johncutlefish

Customers and end users, the foremost experts on the business and its goals, are the critical missing piece from software development.

Aren’t they included already?

Well, yes… but not enough.

Towards Customer-Centric Software Development: A Multiple-Case Study found that, even in organisations with a high level of customer focus, that customers were only present at the beginning and end of the development process.

The authors found four key challenges with this approach:

  • Indirect access to end-users led to a lack of understanding of the reasons behind customer requirements.
  • Feature prioritisation is done based on employees’ opinions and is not continuously validated with customers.
  • Testing is seen as an opportunity to identify defects but not to validate mismatches between customer needs and product offerings.
  • A lack of systematic ways to collect, analyse and incorporate customer data into the product development process.

What’s the real problem?

By omitting the customer and end-users from the delivery team you are working on hypothesis (and to some extent guess work).

Even projects undertaken with extensive and painstaking research are based on what a potential solution could look like. This hypothesis isn’t tested until the end of the development phase when complete features are presented to the users and customers.

And now for the grand reveal… The software has been built to the customer’s specifications, or has it been built to the team’s interpretation of the customer’s initial specifications? Without fully understanding the customer’s situation there is a high chance of building the wrong software.

This of course has a huge impact on budget, schedule and, worst of all, the trust between the client and team.

So how does putting the customer and users into the project team help?

Shortening feedback cycles is a central principle of Agile delivery. By embedding key stakeholders within the team, feedback cycles are reduced from weeks to days.

Developers can demonstrate early prototypes and benefit from the unique expertise and feedback that only customers and end users possess. Rather than thinking, “what would the customer want?” at key decision points they can be asked directly.

No grand reveals, no surprises. A product is developed in collaboration with the customer and ultimately the people that will be using it.

Customers and users are busy people – do they have two jobs now?

Obviously we can’t expect the customer to be turning in 40 hours a week, that would be slightly impractical (and rather unnecessary). Attending weekly team meetings and being able to respond to questions from the team is enough.

The point is to ensure the developer feels comfortable making a call to the customer or uses to clarify a requirement or gain feedback on an early version. Essentially, you remove the subjectivity and guesswork to ensure the right product is being built.

Sounds nice – does it really work?

Digital Village recently completed the first iteration of the Race Around Australia project and was rolled out for a successful pilot in NSW schools. Program manager Emily McLachlan was deeply involved in reviewing the work in progress and making critical feature decisions and prioritising application features.

Her involvement allowed the delivery team to frame technical decisions within the needs of the department, schools, teachers and students, which reduced uncertainty around the product to practically zero.

You can read about the project’s success here.

Next Steps

Convincing busy professionals to attend another meeting/ create time for the demands of a project team sounds, well, trick. In fact, the hardest part may be convincing people who feel somewhat out of their depth in a technical project to participate in delivering it.

With the right support, however, non-technical stakeholders like clients and end users can provide invaluable contributions to a project delivery team.

The first step, of course, is a conversation with project stakeholders. Luckily that conversation will be about how they can save money, reduce risk and enjoy the benefits of their new software as soon as possible. We have a suggestion…

Working closely with the customers means the team will share the customer’s disappointments and triumphs, and hopefully shifts the team’s mindset from focussing on feature delivery to customer success.