In this article we’ll look at digital transformation. These programmes have the potential to give organisations competitive advantage and provide major benefits to employees and stakeholders. However, the majority of these programmes fail to provide the expected results, and in the worst-case scenario they may put the organisation at risk. So, how do you manage these programmes successfully?

Having managed and rescued digital transformation projects over a number of years, there are common factors that you need to be aware of. This isn’t a comprehensive list of things that could go wrong but a look at some of the most common issues.

Not Managing Business Change Effectively

It is common to underestimate the impact of business change. Most people do not like change, and you may receive a considerable amount of resistance to a digital transformation programme. If professional business change management is not in place, there will be an impact. This can range from lack of engagement to actively trying to undermine the programme.

Activities to Mitigate the Risk

Great communication, workshops, proof of concept activities, support from SMEs and super users, sharing the vision of the benefits of the transformation and dress rehearsals all contribute to successful business change.

What are business scenario dress rehearsals? 

In this activity, users complete core business processes in an isolated environment to provide the highest level of assurance for cutover and BAU. The business decides on the key business scenarios with advice from the project team, if required.

What are the principles of dress rehearsals? 

• Users run their critical business processes in a dedicated environment to prove readiness for go-live.
• The mindset of the dress rehearsal participants is that this is the first day of go-live.
• The business scenarios are agreed upon, and the users run them exactly as they will in BAU.
• Test scripts are not used. 
• The dress rehearsal sequence is based on business priority and level of risk. The most critical ones are completed first.
• Superusers assist the participants, and the support team is on call in case there are any issues.
• People responsible for the role after go-live should complete the activities in the dress rehearsal.
• Run at least the first week’s BAU activities and additional weeks if possible. (One full month is recommended.)
• Dress rehearsals are not a rerun of UAT or any other test phase.
• Ideally, production data should be used for the dress rehearsals to ensure data quality and to confirm the validity of the dress rehearsals.
• Roles and permissions are validated to ensure they will support BAU processing.
• Run integrations using the production schedules and BAU volume data to prove timing.

Not Including Critical Activities in Your Plans

Many critical activities are not a core element in some methodologies and frameworks. Regardless of the methodology, the following items can make the difference between success and failure:

• Your project approach, including methodology selection and enhancement.
• Professional project initiation. (Poor project initiation is a major factor in 80 per cent of IT project failures.)
• Communications.
• Quality assurance.
• Project governance.
• Proactive risk management.
• Data management.
• Analysis.
• Infrastructure build.
• Security. (Please include phases as required to retest after recommendations from the security reports are implemented.)
• Proof of concept activities. (This activity provides assurance on the business processes and technical solution.)
• Non-functional testing.
• Business dress rehearsals – In addition to solid project initiation, this is an activity that will reduce risk the most and allow a smooth cutover. It is best practice to include dress rehearsals in every project.
• Detailed cutover planning. (The runbook activities are typically at 15-minute intervals.)
• Cutover dress rehearsals.
• Parallel runs.
• Monitoring.
• Post-go-live support.
• Decommissioning legacy systems.

Most of these activities will be required for major digital transformation programmes.

Activities to Mitigate the Risk

Every digital transformation programme is different. Take a holistic view of your programme and include all relevant activities, regardless of their inclusion or not in a given methodology.

Issues with Data Quality

Issues with data quality are common on digital transformation programmes. In almost all programmes Pathway IT has worked on, the quality of the data has been overestimated. A common theme has been that the data is being used every day, so therefore the quality must be acceptable. What managers may not see is the process and procedures developed by departments to manage poor data quality.

Data quality is critical. This rule applies to every project regardless of size or methodology.

A few thoughts on data quality:

• If data isn’t updated, cleansed and quality assured, it can cause problems with testing, dress rehearsals, cutover and BAU.
• In many scenarios, test data must match production data. If you don’t have quality data, there is a high probability that the problem will impact all test phases.

Knowing that your data is as close as possible to 100 per cent before go-live is critical for post-go-live support.

• An example from a project. After cutover, issues arose with one of the upstream applications. This application was part of BAU before go-live and was not part of the implementation.
• There were multiple upstream systems, and troubleshooting the issue was difficult.
• The data for the new application underwent rigorous data assurance and was confirmed to be accurate before the cutover.
• The level of data assurance allowed the team to pinpoint the issue in the upstream system quickly because they had detailed information on the data in the new application. Without this solid data baseline, it would have taken far longer to resolve this issue, and BAU would have been impacted.

Always consider the multiple uses the data will have.

• You may be working with the manager of one of the departments in finance, and the data he is seeing in the tests is correct. However, the finance director may have other reports that consolidate data or use a different data set. Include scenarios of this type in the test and dress rehearsal activities.

Problems with data can cause reporting issues. (Inevitably the issues will be seen in the reports the senior stakeholders use.) This situation can cause stakeholders to question whether the application is functioning correctly, despite it being a data issue.

Activities to Mitigate the Risk

Please don’t make any assumptions on data quality. Review and update data as early in the project life cycle as possible. Underestimating the time required for data extract, transformation and load is very common. It is not unusual for this to take at least four times the estimated effort and duration.

Not Managing or Communicating Deliverables

Regardless of methodology, agreeing on and tracking deliverables is key to managing a successful programme. Whether it is the deliverable from a sprint in Agile or a milestone in a Waterfall project plan, stakeholders will require updates on progress.

Activities to Mitigate the Risk

Understanding, tracking and managing dependencies between deliverables is essential. Please embed the deliverables in your plan and include updates in your regular reporting.

Underestimating Effort and Duration

Studies have indicated that most activities take over twice as long as the estimates. (This is across a range of industries, but it definitely applies to IT programmes.) 

Please factor in potential long lead times for critical activities. Examples include integration builds, security testing and completion of remedial security activities.

Additional information on estimating:

• Peers with relevant experience are usually better at estimating than the individual who will actually perform the work.
• People on projects may overlook blockers that could result in the tasks taking longer than anticipated.
• Allow extra time if the team needs to use any new tools or processes. (Doubling the estimate is not unreasonable.)
• Don’t schedule people for more than 80 per cent of working time to account for holidays, illness, etc.
• Integrations can be difficult, and completion may take far longer than anticipated. Always try to finish integration builds and associated test activities as early in the project life cycle as possible.
• Security configuration and testing can be difficult and time-consuming. Third-party security testing companies usually have a backlog of work, so it’s good practice to agree on tentative dates as early as possible. Furthermore, remedial work identified during the security test(s) may take a considerable amount of time to complete, especially if the work requires updates to major infrastructure components.

Activities to Mitigate the Risk

Have a peer estimate tasks; they are usually more accurate. 

Use historic data to assist with estimating. 

Consider using work packages to assist with estimating. They are very useful for estimating effort and for managing progress on a project. A work package will contain the following information:

• Work package title/name.
• Code.
• Status.
• Total budget. (Based on days of effort.)
• Start date.
• Completion date.
• Personnel/resource.
• Project code. 
• Comment.
• Purpose of the work package.
• Key objectives.
• Success measure.
• Tangible deliverables.
• Type of deliverable.
• Key dependencies.

The use of work packages was a core element of a major programme for a prestige car manufacturer. The three-year programme was delivered £10K under the original budget. On average, similar programmes had to go back to their boards four times for additional funding.

Please remember that studies have indicated that most activities take over twice as long as the estimates. Ensure you have the required level of contingency in your plans.

Problems with estimating have a direct correlation with budget issues. The majority of stakeholders have concerns that the programmes will not be delivered to the agreed budget. Please include the appropriate level of contingency in your plans.

Issues with Project Initiation 

This is a critical activity. Studies have shown that problems with project initiation are a major contributing factor to project failures.

What are some of the common issues with project initiation?

• Insufficient focus on dependencies and constraints.
• Underestimating effort.
• Overestimating resource availability.
• Not allowing extra time for the first use of development tools or implementation of new technology. 
• Incorrect assumptions relating to the availability of third-party resources. 
• Insufficient focus on training, non-functional tests, data quality, and security.
• Not including business and cutover dress rehearsals.
• Inaccurate budgets.
• Issues with ROI frameworks leading to wasted investment.
• Not agreeing critical success factors with stakeholders. (Or vague statements that can’t be measured.)

These are just examples; there are many more potential issues with project initiation.

Activities to Mitigate the Risk

This is a critical activity. Issues with project initiation are a major factor in eighty per cent of failed projects.

The level of documentation depends on the size and complexity of the project. The following items need to be considered:

• The project’s size. Do you have a development team of five and one stakeholder or ten project teams, 200 IT staff, 50 business people and 20 key stakeholders?
• Does the project have a hard deadline that is not negotiable? For example, is there a critical business requirement that includes supporting a product launch or delivery of a statutory or regulatory project?
• Is additional infrastructure required?
• Are new non-functional requirements included in the project scope? 

Please include all relevant sections in the project initiation phase, regardless of the methodology used.

The following are some key project initiation activities. 

The PID should contain the following sections:

• Background.
• Project definition.
• Project objectives, including critical success factors.
• Project methodology.
• Project scope.
• In scope.
• Out of scope.
• Deliverables.
• The project resource responsible for the deliverables.
• Constraints.
• Dependencies.
• Assumptions.
• Quality assurance.
• Risk management.
• Test approach.
• Dress rehearsals.
• Cutover planning. 
• Post-go-live support. 

Other items may need to be added depending on the type and complexity of the project. Allocate the appropriate amount of time to prepare the PID or project brief. This is a critical document.

Infrastructure Build Challenges

This work is critical and doesn’t receive the level of attention it requires in most methodologies. There may be references to dependencies, but this topic needs considerably more focus. 

Building new infrastructure is difficult and time-consuming, and it may have long lead times. Other teams may not appreciate the amount of effort required to design, build, and test infrastructure. It is wise to add contingencies to all infrastructure builds, analyse the impact on the critical path, and monitor this work throughout the project.

Infrastructure builds, in this context, include all components. (Security, interfaces, integrations, hardware, software components, networks, connectivity and operating systems.)

Activities to Mitigate the Risk

It is important to plan all infrastructure builds and identify the key dates and dependencies. For example, the key dates for building the infrastructure needed to support the test phases and dress rehearsals are essential.

Lead times can be weeks or months for infrastructure builds. Be sure to take such delays into account in the planning process. (The activity with the longest lead time on most projects is integration or interface builds.)

Methodology

It is perfectly acceptable to use Agile, Waterfall, PRINCE2 Agile or any other methodology and supplement it as required to manage risks effectively. Please don’t listen to any methodology ‘purist’ that state methodologies can’t be enhanced. Part of being an excellent project manager is knowing when you need to augment a methodology.

Be very careful if any stakeholders or anyone on your project team states that one methodology or another is the right answer for all projects. Furthermore, be wary of following steps in a methodology that do not add value for your project. The methodology is there to assist you and ensure successful project delivery. 

Activities to Mitigate Risk

Don’t be locked into a single methodology. On many projects, a hybrid methodology will be the best choice, particularly for complex projects that involve dependencies, the integration of legacy systems, software development and complex data loads.

Using the wrong methodology and resistance to using hybrid methodology can lead to failure.

Security

Many methodologies don't cover security in detail, despite its critical importance. The team must prioritise security in all its actions. Decisions on security will impact all areas of a project. It has always been essential, but the requirement for the highest level of security increases on a daily basis.

Activities to Mitigate Risk

• Involve the security team from the beginning of the project and ensure that they agree with all decisions that could have an impact on security. If there is any doubt, consult with them. Please don’t worry about asking a security team too many questions. They will appreciate them.
• Include contingency for security configuration and testing tasks. This activity can be difficult and time-consuming. The infrastructure, data, security and other teams will need advance notice of the dates they need to deliver to.
• Security testing. A third party will usually complete this, and their earliest date can be weeks or months in the future. Work with procurement, select the company and book the date as early as possible. Verify their cancellation policy and make the booking tentative if possible. Ensure you will be able to meet the date before confirming to prevent wasting thousands of pounds. Furthermore, the remedial work that may be identified during the security test(s) may take a considerable amount of time to complete, especially if the work requires updates to major infrastructure components.
• Use the go-live security settings, including users’ role-based access control (RBAC) in the dress rehearsals.
• As part of the development iterations, consider updates that will be required to ensure that the tests are valid. This includes updates to APIs, environment components, security configuration, data, data mapping and possibly many others, according to the specific requirements of your project.
• If the use of live data is allowed in test phases or dress rehearsals, the environment must be locked down.
• Implement production-level security to ensure that the only people with access to the data during tests and dress rehearsals are staff (or other authorised personnel) that will use it in BAU.

Test Preparation

Many programmes do not give preparation of test data the focus it requires, and this causes issues with testing and potential issues in BAU.

• The best practice is to create test data that mirrors production data. This process takes effort, but it pays dividends in test efficiency and in discovering bugs that may not be found with test data that does not replicate live data. The details may vary according to your project and the test phase, but as a principle, always use data that is as close to the To Be production data as possible.
• Use of live data – Using live data is essential for certain tests that cannot be completed with the necessary level of assurance otherwise. (Or test data that mirrors the live data perfectly.) Of course, you will need all the appropriate approvals to use live data. It is critical that the project ring-fences the test environment to ensure that no live data goes out of it. An example of this would be to disable all email functionality, interfaces and integrations that could send data outside of the test environment.

Non-functional Testing 

Many projects fail to give non-functional testing (NFT) the necessary thought or priority. Some projects view it as less important than other test phases. I’m sure most project managers have heard something like, ‘Of course the performance will be fine because we are using the same approach we’ve used on other development projects. We’ll complete NFT at the end of the project/during the final iteration if we have time.’

Avoid slipping into this trap. If issues are going to surface in NFT, you will need to know the reason as early as possible. Things like API performance, data transfer, issues with integrations and system performance can take a long time to resolve.  Furthermore, NFT is a phase that benefits considerably from test automation.

Activities to Mitigate Risk

Ensure that test data is fit for purpose for each test phase. Please remember that some tests must be completed with production data or data that mirrors production data. Identify these scenarios early in the project life cycle.

Please don’t hesitate to bring dress rehearsals forward in order to mitigate risks. They are very powerful in proving the readiness for go-live, and you can run them in parallel with test phases if required.

Risk Management 

Risk management is critical throughout the project and will come under sharp focus as cutover approaches.

Risk management should be based on objective criteria. Without this, opinions of the level of risk will vary widely. Pathway IT uses a simple but extremely effective risk management spreadsheet on programmes. The yes or no answers only take a few minutes to complete, and this provides a low, medium or high risk score.

Proactive risk management is critical if you want to deliver successful digital transformation projects.

This article has touched on some of the common issues with digital transformation projects and actions to mitigate the risks.

Good luck with your programmes!