Frequently, the last few months of a transformation project are intense to the point of being all-consuming, no matter how good your project planning, communications, and team organizing are. This is simply because digital transformation frequently impacts a very large fabric of the company—maybe even the largest impact the company has ever seen.
In many cases, digital transformation touches more technical, business, and organizational elements of the company than anything that’s gone on before.
Given that impact, it is easy for companies to flinch: reduce the scope partway through, stage the rollout to lessen the impact, increase the oversight, and thereby slow down the project. Typically, these approaches—these knee-jerk reactions—are a mistake. Digital transformation is a challenging, company-changing experience. Having the entire company behind the changes, from the top on down, will define the eventual level of success. Don’t flinch! There are steps you can take in the last mile of the project to maximize the impact and value your transformation will have on the business.
A lot of the noise that can come during the final phase of your rollout can be reduced if your mission statement and project communications have been well-managed and delivered against earlier in the project.
The last phase is the absolute wrong place to debate the value that the current project can deliver. The easiest thing to do is point those who are making noise back to the original, executive-supported mission for the project. That said, new players will frequently show up, particularly when the likely level of disruption becomes clear.
Mission statements and executive endorsement can have a massive calming effect on the new players, and sharing prior communications with them can also help them buy in and feel more a part of the process.
Project timelines come under pressure during the later stages, and you will be looking for ways to compact the schedule. You have to be very careful here.
There are four areas in a project that are often compromised, to the great detriment of its success.
User acceptance testing
Digital transformation is often managed out of IT. Testing may start out as a combination of technical and business acceptance testing, but under delivery pressure, this looms large as a target. It is typical to want to compress the testing cycles of the project. One of the first places the project team may look in project timelines is the business-user acceptance testing. This is an extremely dangerous area to cut.
Engaging business users in accepting and commenting on the software is a key part of the project, and it takes time to go through this cycle. It may not feel like the same level of rigor applied to system and unit testing, but it is at least as important. Cutting here to save a timeline can result in large rework efforts because the users rejected outright or challenge what was built. This has timeline impact but also can damage the momentum and support for the success of the project. Keep the business users engaged and drive them to timely response as best you can. Any other course that reduces user testing increases your risk by a multiple.
Deploying new software does not happen in a vacuum. There are always other systems to connect to. One of the more common mistakes in a transformation project is to assume that the integration with these legacy systems will work the same way as in the past. In almost all cases, that would be a bad assumption.
I recently worked with a customer who identified over 50 integrations that had to be delivered for the final go-live. Working with our expert services team, the team was able to go through them, one by one, identifying what was critical to the project and what could be delayed.
Since validation of your integrations can’t happen until late in the project, there is a natural tendency to accelerate the integration part. This is a pretty dangerous thing to do. We often see integration failures as a major last-minute challenge to transformation. Taking the time to identify which integrations are real-time, which are near real-time, and which can be pushed to a batch can help tame the integration challenge.
Frequently, we discover that integrations that are identified as requiring the most “expensive” real-time calls turn out to be somewhat less crucial—and can have a near-real-time strategy applied. A classic example: do you really need real-time inventory validation when someone looks at the detail on an item in the catalog? Do you even need real-time validation if it gets added to a shopping cart? In many business cases, the only real-time inventory call happens as the cart is confirmed for checkout.
The more you can document and validate integration issues before getting to the last mile, the more likely you will be surviving this test. Legacy system integrations that were built over the years typically don’t perform the same way when connected to new systems. Digging into this early can only help you in this key effort. This is an area where making assumptions without validation will come back to cause you major challenges.
Closely related to integration efforts is load testing. Too often, customers make assumptions about load based on the stock performance of the vendor’s software. This is faulty reasoning. You are fitting and customizing the solution to your specific needs. Every changed setting and every custom workflow gets you one more step further away from whatever benchmarks the vendor provided for throughput. What’s more, your integrations will have a substantial impact on the performance of your solution—and there is no way your vendor can anticipate what that impact will be.
You should have a specific vendor engagement to review your architecture, settings, integrations, and custom work as a part of performance validation. Failing to do this can result in major problems when going live. I recently had a customer reach out to me after rolling out the first four of a 40-country rollout plan. The largest of the four was Ireland. The customer was having substantial scale issues. After an emergency engagement with our performance team, it became clear that major refactoring of the solution would be needed. Additional rollout had to be delayed until the system passed the load test, resulting in an avoidable executive-team embarrassment for the CIO.
System load testing needs to be a foundational part of your project. Missing or underrepresenting this step almost always turns out badly.
When the project is under time/delivery pressure, one of the first things companies look at is the training component. Cutting here would often seem to be another easy way to reduce the impact on a project’s on-time delivery challenges. Don’t do it!
Training is often underrepresented to begin with on a digital transformation project. There is nothing worse than having a new system fail because no one can use it. This is often not a technology issue. People make systems work—or not. Those people have to know and buy into what they are going to be using.
Training falls roughly into two primary components. Don’t ignore either one.
System training: This is training for the team that will be managing the work streams and business processes you have designed for the project. This is where the bulk of the training focus goes. Making sure that people know why and how the system is rolling out, and how their job will change, is critical to the last mile of the effort. There is a fair amount of work here if you are substantially altering business processes that have been around for a long time. Make sure the teams know what they are doing and why!
This is a chance to build excitement for the new solution, and getting buy-in from these teams will smooth the inevitable bumps in the rollout. This training should comprise three aspects: vendor training in a classroom or on site, system integrator amendment for any uniqueness created for your business, and hands-on sandbox experience where the users can make mistakes in a safe environment. Please—whatever you do, don’t assume that users will simply take what you give them. This is not a great approach to building the momentum you will need to claim success in digital transformation. Build a proper training plan and don’t cut corners. Send people to training and engage them in the effort. It will pay dividends.
End-user training: This is another area that is often underdelivered in a digital transformation rollout. The best thing you can do is communicate what’s coming with a sampling of end users, see how long it takes for them to grasp, and make your training plans accordingly. Some companies like to include a set of end users as the “champions” for the solution. This can work well to “seed” the user community with a team that already understands the system.
The last mile is always where the crunch comes. But the steps above will help you take the challenges in stride.
For more on IT transformation, see Building The Symphonic Enterprise: 7 Big Trends For Tomorrow’s Business.