The Top 10 Challenges When Embarking on a DX Journey

When embarking on a Digital Transformation (DX) project, you would expect a few risk items to be on your radar, but only with actual experience of DX projects does it prepare you for the reality and true extent of the challenges you expect to experience.

With a typical project, you will be familiar with procedures, processes and the relevant supporting infrastructure whilst calling on your colleagues for support and assistance, but most DX programmes use predominately new resources specially brought in to deal with the transformation. The infrastructure and tech will be different along with the overall approach and this in itself brings challenges, below details the top 10 you are most likely to encounter:

1) Lack of Experience/Expertise
The majority of DX programmes use external test providers to independently Quality Assure their products and to ensure the infrastructure integrates as expected. When choosing a testing partner, it is essential that they have and can demonstrate that they’ve done this before. Good references and case studies are a good starting point when selecting a suitable supplier. Using a test partner that doesn’t understand the complexities of DX will lead to issues later during the project life-cycle.

2) No Over-Arching Test Strategy
Before you assemble your test team, you must create an over-arching test strategy specific for the DX programme. The strategy must include all the key elements of testing and their phases, but also contain details around dealing with suppliers and the expectation of Quality you expect from them (Entry and Exit criteria) along with how defects will be handled, turned around and the overall triage process. The overall scope of the test team should be detailed, setting out clear roles and responsibility so that any gaps can be identified early by the programme before the test team is set up.

3) Budget
The elephant in the room… Don’t underestimate the cost of testing DX, it’s a beast and System Integration Testing (SIT) plays a pivotal role in the whole process, ensuring that all data flows correctly across all applications both up and down stream from the core system. When planning the testing resource, always ensure you plan for items like knowledge transfer, defect triage, re-testing, environment downtime, additional test cycles and UAT support. All the aforementioned play a big part in the overall delivery of testing DX.

4) Access to Limited Technical Resources
Like any project, getting access to key resources is limited and the larger the DX the less time you will get, in some causes single points of failure exist and at time of sickness or holidays of key individuals progress could stop or at best slow down. To efficiently maximise the time you get with key resources, it’s best to collate your questions and queries and where possible ask your co-workers if they have any outstanding queries they need resolving so that a single session could clear up multiple questions in one go.

5) Business Pushback
People are generally reluctant to change and DX is no different, education is key to ensuring everyone is brought into the reasons for DX and the benefits it will bring. Anyone not fully convinced by the change will naturally be reluctant to support the exercise. Testing plays a big part in ensuring users that the new landscape will be of good quality, will meet their expectations and bring bigger benefits to the company and users.

6) Lack of Business Requirements and Data Mapping
It’s very common that once the green light has been given to ‘GO’ then there’s a big push to get moving quickly. This often involves the production of rushed or incomplete business requirements and Data Mapping documents. We all know that poor requirements will inevitably lead to poor development and in turn lead to a product that doesn’t meet expectations. Testing must be part of the business requirement sign-off process, only once testing has confirmed that the requirements are complete and that suitable tests can be written can sign-off be achieved. Get the requirements right and you have the best chance of success.

7) No NFR’s
One of the least thought about (or owned) pieces of work, deciding who owns Non-Functional Requirements is the starting point and from ownership you can begin to write the appropriate test plan. It is not the role of the tester to define the NFR’s, this lays firmly with the business.

8) No Infrastructure Diagrams – Before/After DX Diagrams
It’s not uncommon to see a before and after DX diagram, but it’s very rare that you have a DX project that implements everything in one go, therefore you need one for each Go-live or release. This will aid SIT along with assisting users in their understanding of what applications lay on the new infrastructure and those that still exist in legacy land.

9) Knowledge Transfer – How It Works/Should Work
It goes without saying that sharing knowledge is key. One team, one goal and if the mindset of every team member is to assist the programme to gain success, then the sharing of knowledge from each phase of the project will inevitably be an asset.

10) Defects and Defect Triage
Most DX programmes are made up of multiple teams, these teams all have an interest in the overall quality of the delivery. When issues are found, whether that be a config set-up or a functional bug, then raising a defect and assigning to a specific team is key; along with providing plenty of evidence to support the issue and to give as much insight as to why the defect was raised, all of which takes time. Once you have a set of defects, then daily triage meetings are essential to ensure bug resolution moves at pace and that fixes are supplied as per the SLA’s of each team involved. The managing of defects is a task in itself and should not be overlooked as during critical test execution phases, defect resolution and retesting are critical to test phase sign-off.

In summary, don’t underestimate the complexities and effort to deliver a DX programme. Ultimately, DX is far more than just the technology. It’s about capitalising on the experience of the team and integrating the project approach with knowledge of what’s ahead.