The Online Transaction Hype Cycle has been saved
The Online Transaction Hype Cycle
How to avoid the pitfalls of technology implementation and deliver a world class transaction solution
Your customers expect to be able to transact online with your business. Therefore online transaction processing is not a nice-to-have, it’s an absolute essential for keeping your existing customers loyal, and gaining new ones. This means most organisations are discussing, planning or delivering a project to introduce or improve online capability.
As technology projects go, the benefits of being online are some of the easiest to identify, and the platforms to deliver a personalised online experience are mature. So why is it that projects which should feel like a steady jog with an occasional hurdle instead often end up feeling more like a marathon in a hail storm? Based on our experience of helping clients recover their ailing online transaction projects, this paper illustrates an all too common trap that organisations find themselves in when going online – and how they can avoid repeating the same mistakes in the future.
A typical transaction project: what usually happens
The Business Case and Project Initiation
This was likely initiated from a digital/technology/customer strategy that identified the benefits of making customer transactions available online and ensuring the user experience was designed and tested with the consumer in mind. This is a good starting point. However, often we find that any concerns that were identified around data quality, integration capability, latency and security are too often relegated to the risk or issue register to be dealt with in the future should they eventuate.
With funding approved and a team stood up, focus rightly ramps up on user experience design, prototyping and testing the design with customers. It is critical that any online transaction meets the needs and expectations of users or they will simply choose to use another channel, or another business.
There will likely be further discussion of risks and issues and a basic understanding of where the information and processing required to support the transaction are located in existing systems. Architectures are agreed, and integration methods are starting to be mapped.
As the positive customer testing feedback rolls in and the designs are finalised, the project team is on a high, as illustrated in the cycle below (look familiar?).
Are those clouds?
As design moves into build, little issues start to arise. Data quality might mean some information can’t be used as planned, or its discovered that a business process includes a manual workaround that can’t be replicated online. Each issue seems resolvable as it comes up, and to keep the project moving, designs are changed quickly to maintain momentum and accommodate any limitations found.
The solution isn’t quite what you had planned but it will still deliver most of the benefits identified.
Testing starts and now you begin to find latency and security issues, and much like a tropical storm, a series of seemingly small issues quickly escalate into a situation that requires you to take evasive action as you race towards the finish line. This often results in functionality being rapidly redesigned or dropped from scope completely, without time to consider the broader impact on customer experience.
The finish line continues to move with each new change request and your project team are pushing forward but looking tired and battered. You run past your original go live date and there is definitely a feeling akin to the trough of disillusionment.
It’s go live and everyone is happy to have finished and delivered a working product, but scratch the surface and the successful feeling doesn’t go very deep. The solution looks quite different to what was originally envisioned and the benefits case has been eroded. Your exhausted project team are all in the recovery position wondering why that was so incredibly hard.
An ideal transaction project: what should happen
Check the forecast before you head out
Much like weather forecasters who understand the elements of their system and which combination of events may result in a storm, organisations looking to deliver online capability can rapidly pressure test the key elements making up their proposed project scope to predict which direction any storm fronts are likely to appear from.
Our online transaction assessment framework is tailorable, and can accommodate:
- your risk appetite
- your existing organisational knowledge in each area
- the likely impact to benefits of under-delivering on customer expectations.
We summarise the findings of the assessment in a format that is clear and useful for business transaction owners. This information should help to support informed discussion and decision making about the risks associated with each use case.
Based on the identified capability gaps, and their complexity, you can make informed decisions to manage your delivery risk, including:
- Remove some transactions from scope prior to the commencement of user experience design to allow the project to proceed with an optimised design
- Initiate parallel projects to resolve gaps, to allowing the online project to be delivered successfully
- Revise the start date of the online project while key dependencies are addressed.
We advise completing our readiness assessment for each of your transaction types prior to confirming the scope of the project and commencing design. In this way, we can help you to greatly increase your confidence in what can and will be delivered, without comprising on the quality of your final solution for your customers or your organisation.
Published: April 2018