Last updated: Digital transformation series: 10 Digital Transformation Tips

Digital transformation series: 10 Digital Transformation Tips

10 shares

Listen to article

Download audio as MP3

This is the fifth in a series of posts created to address the crucial aspects of performing a successful digital transformation.

10 digital transformation tips – and a few things to avoid along the way

There are more ways to get digital transformation wrong than there are to get it right. It is an unfortunate truth that there are many moving pieces and any one of them can derail your efforts. Some of the following tips can help you avoid that challenge.

I am sure there are others I have missed—I’d be delighted to get your feedback on that at r.werkema@sap.com

Your Mission & Objectives: Stephen Covey effective people should ‘start with the end in mind.’ Digital transformations are certainly aligned to that. Don’t delay building your mission statement around your transformation effort, and make sure that you broadly communicate with stakeholders what the end state means and will look like.

In a customer meeting a few months back, they were obsessed with making sure that internal teams were aligned, as well as their branch offices, and even their customers and business partners. They made it a point to tell everyone what the end state would look like. The result was a huge transformation with very few bumps in the process.

Communicate your plans—repeatedly: Digital transformation has to take place while you are running your business. In many organizations, ensuring day to day activities is more than a full-time job already. Assume that you will have to repeatedly communicate your plans to a broad set of constituents both in your company and perhaps partners and customers.

And, as I have said in previous posts, if you drive this as an ‘IT’ project with little input from the business, it is likely you will have a much more difficult adoption than if you engage the business with a clear communications strategy.

Don’t forget to communicate with your partners as well. Your systems integrator and your technology partner have vested interests in your success, but assumptions are not a good idea here. I wrote recently about the partner selection process—that should be just the starting point.

Aligning all of the involved parties seems like an obvious step, but lack of communication is one of the primary reasons projects of this magnitude fail. When you are changing the business you can never say this is a IT driven event and expect success.

Build room in your budget: A few weeks ago we discussed budget issues. There are certainly ways to get this wrong. Nearly a third of the customer challenges I get involved with have budget as a major problem. Going back and asking for more money is one of the worst experiences you can ever go through professionally. I worked with a customer recently that had to ask for funding three times. Not only is the project at substantial risk when this happens, but your credibility will be damaged no matter the outcome.

I advise customers to hide at least 15% of their overall budget for things you don’t yet know about. Let’s face it—digital transformation projects are new to most people. There are going to be project events and bumps no one anticipated. Building in some cushion will allow you some breathing room. You do not have to share this with anyone except the team providing the funding. If you don’t use it, they will be very ready to slap you on the back for coming in under budget.

Leverage partnership. Get your partners to put skin in the game. Your Systems Integrator (SI) and technology partner form a trinity with you that will need to fully engaged to be successful. During your sales cycle, ask both partners how they are committed to your success. It is an answer that could be vital to the success of your project. Having your technology partner review the intended deployment mile stones with your SI can result in surprising input, and in some cases, good ‘catches’ before the project is even underway.

There are all sorts of ways those partners can support you. From monetary support (eg. ‘free resources’ for certain tasks) to bringing in specialists for certain key requirements, partners won’t often volunteer these things until asked…make sure you do!

Executive sponsorship: Find at least one – if not several – champions on your organizational leadership team who support you and who you can turn to if issues arise. Make sure you are briefing them well—per point 2 above! The executive(s) supporting the project should understand what the transformation effort is and fully embrace it.

Project kickoff: It helps build team bonds and galvanize members when you have a formal kickoff. The kickoff is another chance to make sure that the mission and expectations are well communicated. If this is a big enough transformation, get the right execs there to emphasize the importance.

I have always pushed for the CEO and the head of sales to endorse a substantial transformation project—it does two important things: lets everyone know that this is an important initiative, and having the CEO talk underscores the value it will bring, which can be very handy down the road if there are bumps to be addressed.

Milestoning: Find a regular set of checkpoints to bring all parties together. Agile development processes often make it more difficult to identify the milestones, but that is a critical part of the equation. At the very least you need to do formal reviews at the following points:

Architectural Review: Look to both your SI and technology partner(s) to review your current architecture, the integration touchpoints and external system connections. Take the time to review these in detail with your partners. Integration is often one of the most under estimated areas of a project. Don’t assume that they are all covered. If you are going to have any nasty surprises, integration is a very good candidate.

Code Validation: Make sure you budget for a formal review by your technology partner. Too often, code gets delivered with issues. You don’t want to find that out after the completion of the project that your customizations have issues that require substantial rework. Validating your custom code after a sprint or a set of sprints will leave you if much smaller rework challenges.

Go-live check: Ask both your SI and Technology partner to give you a list of things that you have to have completed before going live. Get this early on in the project, as you will have a large quantity of items to add to it that are driven from the project. Don’t lose sight of the overall objectives.

Performance review: Make sure you have budgeted the investment to do a formal performance check on the technical aspects of the project.  Don’t assume that your partners will see to this. Define the expected metrics and test to them in at least one cycle.

Throw a go live party: Easy to blow this off, but you want to do it for reasons beyond celebrating the effort of the project. This should give notice to the whole company that transformation has arrived or continues. It’s a chance to trumpet the accomplishment—and make a loud point that you have succeeded—business will no longer be the same!

Post-live punch list: Make sure you have built into your contract that all high-priority issues are resolved and secondary issues fall below a defined threshold before release final payments to your SI. This is an important lever—you will never have as much influence as you do before payment.

Maintenance and support: Define your maintenance strategy at the beginning of your project. Once the deployment is complete it is pretty unlikely you will have built the skills in your internal team to be able to manage all aspects of your new platform. The end of the project is the wrong time to figure that out—you don’t have leverage of your SI partner, and they may already be planning to move on to new customers.

You should go to your SI during the planning phase and budget in at least 6 months of support—with your team shadowing the effort to maximize the learnings. A common mistake is being optimistic about the need here—or worse, not planning for this at all. That can make the post-live transition extremely painful—and can leave an undesired mark on the whole project even if it was otherwise successful!

This is the fifth post in a series about digital transformation. You can find the other posts here:

Digital transformation: How to select the right partners to maximize success

Digital transformation: The first step is building consensus and creating a mission statement 

Digital transformation: Define scope to stay within budget

Digital transformation: Building effective digital transformation teams

Share this article

10 shares

Search by Topic beginning with