Lessons from Hertz Accenture Digital Transformation LawSuit

Dinakaran Sankaranarayanan


Lessons from Hertz Accenture Digital Transformation LawSuit

Digital Transformations are inherently hard. It is wild wild west to start with and if not planned well could become an uncontrollable monster that burns down finances of even large organization . Having first-hand experience of being part of such a program, the news of Digital Transformation gone wrong with Hertz and Accenture law suit made me reflect on how organizations can plan this better. Here are some of my high level scattered thoughts around this.

Build Core products internally

  • As much as possible, companies must always try to build the core product of the business internally. Never outsource it. Core Products need vision and long term strategy and it would do immense good if a team can be built to deliver on this mission. With Digital Transformation, this gains even more significance.

  • Even if it not possible to build teams and need to outsource, at least have a slim crack core team that can be on top of anything and everything that is delivered, reviewed, validated and improved constantly. Missing out on this can be suicidal. Quality must be the focus on everything that is delivered.

Culture eats Strategy for Breakfast

  • Hire the best possible talent and inculcate a culture of openness and transparency. Best teams deliver no matter what. Create a sense of environment for people to complain, voice concerns, ambiguity and help them navigate.It is not always a competency issue but could be a lack of clarity or direction.

  • Leaders need to be cognizant of the challenges that run through such programs. No one would have executed 100% of this before. Do not expect teams to tell leaders what they wanted to hear. And do not persuade teams in that direction where the solution to every problem reported is re-directed back to the same team who came to leadership in the first place. It means that the reported issues are not clearly understood and any future potential problems would go unreported because of the mistrust that there is no one to help and this can be catastrophic in terms of delivery.

  • Make Tech teams understand Business or Company point of view. Many times, not every team are aligned and do not understand the reality of how decisions are thought through or made. Bringing in a context on how it works in the background helps to get a sense of the bigger picture.

  • Digital Transformation is not just a shift to new technology or processes but also about a mind-shift change in terms of how technology can be leveraged to affect meaningful change to the way how business is run. Business Leaders, Analysts, Domain experts and everyone within the company need to be educated on the possibilities and how well they can help to improve the experience for customers.Learn- Unlearn-Relearn should be the focus.

Focus on well defined success outcomes

  • Go as detail-oriented as possible in terms of the indicators of successful outcomes. Drill down broad objectives into actual use cases so that the essence and bigger picture of the initiatives are reflected in the solution throughout.

  • The objective of Digital Transformation involves not necessarily moving to a shiny new tech stack on the cloud, but rather how it helps the business to better serve the customers. This means doing due diligence on existing pain points and establishing gating criteria on what can be an acceptable measurable successful outcome for the problem.

Build parts of application as POC

  • Building parts of actual application as POC helps to evaluate tech and product stack better. It can help to uncover the challenges associated with building in terms of product maturity, hiring talents, documentation , support and what not.

  • POC’s are not just building the most easiest use-cases where the underlying issues of the product stack is never realized or understood.

Don’t go Big Bang. Build small and refine iteratively

  • Going Big Bang does not work out with Digital Transformation programs. Build stuff small, refine and iterate gradually.

  • Avoid plans stretching not more than 6 - 8 months due to the uncertain nature of the program.

  • Scale teams as required to avoid cascading delays that result in project cost overruns.Once the very first iteration has yielded the expected results, scale teams accordingly. Scaling too early or too late can become challenging.

  • Whenever situation arises where a better solution exists, pause to understand alternative options , reflect and take balanced informed decisions. Even if it means changing some of the fundamental stuff which if unattended could become a major challenge in the future.

Always take claims of consultants and product vendors with a pinch of salt

  • Consultants and Product Vendors always paint a rosy picture of their product and competency. Always take it with a pinch of salt. Get ground level feedback from both outside and inside the organization and objectively validate the claims.

  • Have a decision framework to shortlist vendors through a well defined rating system to ensure their capabilities and limitations are better understood and expectations are aligned accordingly.

While these are by no means an exhaustive list, but are some of the challenges that came on top of my mind while reading the news and jogging down the memory lane.