If you are reading this post you probably are not yet in the last mile of your transformation project. 😊
Frequently, the last few months of a transformation project are intense to the point of being fully consumed—no matter how good your project planning, your communications and your 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 prior.
Given that impact it is easy for companies to flinch—reduce the scope part way 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. I have said in prior posts, digital transformation is a hard, company changing experience. Having the entire company behind the changes—from the top on down—will define the eventual level of success of the project. Don’t flinch! There are steps you can take in the last miles 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 making noise back to the original, executive supported, Mission for the project. That said, there are frequently new players that show up—particularly when it becomes clear the level of disruption the transformation is likely to have.
Mission statements and executive endorsement can have a massive calming impact to the new players, and sharing prior communications with them can also help them buy in and feel more a part of the process.
It is often the case during the later stages of a project that timelines come under pressure 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 often get compromised– to a great detriment to the success of the project.
Digital transformation project: 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 very first places the project team may look in project lime lines is the business users 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 take 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 time line 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.
The integration phase
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 to 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, they were able to go through, one by one, identifying what was critical to the project and what could be delayed.
Since validation of your integrations cant happen until late in the project, there is a natural lean to accelerate the integration part. This is a pretty dangerous thing to do—we frequently 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 often 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.
Load testing
Closely related to Integration efforts are 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 farther 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 with your go live. I recently had a customer reach out to me after rolling out their first four of a 40 country rollout plan—the largest of the four was Ireland. They were having substantial scale issues. After an emergency engagement with our performance team, it became clear that substantial 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.
I have stressed before that system load testing needs to be a foundational part of your project. Missing, or under representing this step almost always turns out badly.
Training
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 under represented to begin with on a digital transformation project. There is nothing worse than having a new system that fails 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 of them.
System training: This is training for the team that will be managing the workstreams and business processes you have designed in 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 these teams bought in will smooth the inevitable bumps you will have in the rollout. This training should comprise three aspects: Vendor training in a classroom or onsite, 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 under delivered in a digital transformation roll out. The best thing you can do is communicate with a sampling of end users what is coming, see how long it takes for them to grasp and make your training plans accordingly. Often time, 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.