4 things you have to do to prepare for digital transformation

Digital transformation. Omnichannel. Behind boastful marketing messages, very rarely we hear about real-life difficulties and struggles from people in the trenches. And the harsh reality is, real digital transformation is hard. Particularly transformation in telecom or manufacturing & distribution companies is on another level of difficulty to get right – as anyone leading such program will surely agree. In this article, based on our real-life telco omnichannel sales implementation projects, I want to share some of our hard-learned lessons which every program manager – whether working for big , or smaller, regional telco player - should consider during the preparation and planning for this perilous journey.

Start small, plan big

Regardless of selected delivery approach – agile or waterfall, during the planning phase of major transformation program, it is important to set long term goals from company and customer perspective. This will be an enabler for building the roadmap which is based not on the system perspective but on the real value provided from each release or stage of the transformation. The prioritization however, should not only be defined by business goals, but also by feasibility or complexity of roadmap stages to achieve visible results early and enable verification of delivery path. Too ambitious planning and “Big Bang” approach can result in significant delays or even lead to collapse of the whole program, if the value is not shown to sponsors early enough.

The first goal should be to have something in production early – anything at all, that will enable testing the overall delivery and release process. Otherwise, after a long period of design and development, project will encounter problems when starting actual testing and running first release delivery pipeline in integrated environment. All those can delay the program, if you don’t anticipate bottlenecks early enough. In our case, we discovered several unexpected issues:

• Integration points of environments not working which blocked testing at the beginning

• Security which was slowing down access to the environments for teams

• Migration of configuration between environments not automated enough, which meant long manual process

The critical part is choosing which parts of the solution to introduce first, with full understanding that in the beginning, delivered basic foundations of applications might be underwhelming to business sponsors. At the same time, delivering “quick and dirty” solution should be done only if it brings real value later. When delivered only as a “quick-win”, but due to unprepared architecture will have to be overhauled or even scrapped later, it is better to stick with the previous approach.

Focus on the right things

In large program with many systems and modules, it’s easy to lose focus, while trying to build everything in parallel with multiple teams. After the number of systems and teams exceeds some threshold, communication becomes overwhelming. It’s hard to make decisions fast and consult the right people. In our case, late design changes to cart flow affecting all processes and channels were constantly disrupting our main delivery stream. If we had focused only on those parts of design and integration which were 100% confirmed and stable, the overall development time could be shorter. This is where proper SOA architecture together with microservices can help isolating teams from some of design changes, while monolithic omnichannel commerce platforms by their very definition aggregate many backend services into larger customer-facing process.

The longer and bigger the project, the more difficult and costly it will be to make changes to it at later stages. Regardless of a methodology used (agile, waterfall), once you try to change some basic assumptions – like introducing different approach for launch - even verifying that new assumption with each already delivered module and integrated system may require weeks or even months of work with involved costs. The solution here again would be choosing nimbler, agile approach and focusing on smaller parts that can be delivered and used earlier rather than trying to do too much.

Do not think that you can do more by working in “parallel”. There are people whose time and attention simply cannot be divided further. Putting them on most important tasks first is critical, especially at the beginning of the program. It’s easy to think that just by putting more and more teams it’s possible to deliver something faster. Yet there are countless examples of projects where software took many years to deliver properly, even by companies that had seemingly unlimited budget.

All of the above simply means that during roadmap planning, it is better to start with smaller number of focused teams and streams of work, in order to first let the organization learn delivery process and then ramp up more teams, as the learning curve includes also communication within the project.

Build the right team early

The success in a big, challenging program depends foremost on selecting the right people right at the beginning. The main reason is that costs of introducing new members to a complex and long ongoing project grows exponentially up to the point where even overloaded team will protest introduction of new people as the onboarding effort won’t be worthwhile anymore.

In our cases, we took much care to assign the most experienced people to difficult and risky areas. It pays off as more experienced team members are able to warn earlier about increasing complexity, hidden cost and technical debt. They are also more assertive when someone tries to “cut the corners” as managers under pressure will try to push for unprepared deployments or simplifications that are technically unsound. They will be able to defend their position and protest such attempts.

We also believe that well-organized teams sharing common culture of trust perform generally better than “hired guns” who might be excellent in their field, but could have less motivation to support and collaborate with others.

Flexibility of team members also turned out to be a major strength. In complex projects, it is better to have people that are able and willing to switch their roles from designers, consultants or architects into trainers, or efficient defect analysts.

What is most interesting, though, is that systems architecture also has impact on how teams operate and collaborate. Monolithic applications are much harder to divide into separate teams and vendors, as opposite to microservices-based, which by their very nature enable more flexibility in choosing and mixing teams, solutions, vendors and technologies. It is also much easier to use hired dedicated teams in parallel to internal ones.

Look out for people

The longer the project takes, the more there is a need to care for team well-being and motivation. Especially detrimental is lack of closure in terms of delivered and accepted phases. Many times our teams were forced to retest some part of solution for over a year or do another major redesign of already finished process. Team members became frustrated, and motivation was falling due to daily grind on the same endless task. Think about motivation and healthy breaks. The team that is pushed beyond limits will not be productive, and even one of the key people leaving can undermine the whole initiative. It’s also advisable to reassign people between teams as this can help both the project as well as keep the motivation high.

Successful digital sales transformation requires huge and long-term effort, with dedicated and experienced team, and must be planned with that in mind. Expectations must be sensible and well managed. In the end, expect that your transformation will become a continuous learning journey, and not a one-off project – and should be treated like this.

For this reason, before taking the next step, we encourage you to speak with an experienced consultant. Feel free to contact us directly to discuss the possibilities of Digital Transformation for your company.