Which came first, the system or the business value?

Since starting Transformation Squared, I often get asked, what exactly is Transformation? And I ponder this a lot myself. In fact, over a decade ago, when I was deeply involved in rolling out multiple modules of SAP globally for an international company, I dare say the word was never spoken. But now it seems that almost every project either calls itself a transformation or is part of a program that does. Why is that? Is it just the new trendy buzz word like “synergy” was to 2008? An even more curious question is: what is the difference between business transformation and digital transformation? In this blog I will share some of my thoughts on this topic with you. I do not pretend to know all the answers and would be very happy if any readers have comments or insights into this from your experience.

Why all the Transformation?

I’d like to start with a little reflection on the leaps I have observed in software development over the last decade. This is in part to frame the context for the discussion of transformation but also to explain how this history contributed to the increase in popularity of the transformation and what important lessons were learned over this time which can help set modern day transformations up for success. Looking back at the pre-ERP era, when mainframe operaing systems, exel files and lotus notes ruled the day, when a business function wanted something to be done more efficiently, they would start tackling the problem with the most clever tool they could either find inhouse or buy for their department to solve their problem. This created a world where business processes were run by using hundreds and even thousands of small tools, fit for their specific purpose, in their office, in their country. When ERPs started being rolled out, many companies tried to roll them out with the same fragmented mentality. They would have the finance people talk to the IT folks to set up the finance modules and the purchasing people talk to different IT folks in hopes that it would all come together in a convenient package of software that enabled companies to decomission hundreds of small, piecemeal systems and save some money. Things started to get really complicated when what was previously a sound theory that silo thinking wasn’t good for the end to end process became a nearly impossible to manage reality, because after an ERP implementation, silo thinking has real consequences. The roll out of ERP brought the annoyances in the processes to the surface and turned them into real issues.

The early approach to ERP roll out proved to be incredibly difficult and costly for many companies. But two key lessons came out of this freshman experience. It became clear that INTEGRATION was necessary now, way more than before, because although the genius of an ERP is its ability to link various functions into the same key data structure and share master data, the trade off is that it requires cross functional alignment around how that data is defined, created, maintained and used. It also became clear that rolling out an ERP requires a huge CHANGE MANAGEMENT approach because when working in a tool like this, users often become removed from the relevance of some required actions, so they either fail to do them or do them incorrectly which affects something seemingly unrelated to them in the process. Suddenly, business leaders found themselves having problems that they considered functional, since it was their function’s KPIs that were being affected, but the causes were in fact cross functional. Many times the problems were so complex and involved functions that they didn’t even realize were involved, so they just began enhancing and develping as fast as they could to tackle the problems as they understood them, making assumptions about causation that often times were drastically inaccurate and caused negative consequences on the affected process.

Meanwhile, somewhere in the IT department, the people who often understood how the system ties everything together tried to advise and explain to the business how to tackle the problem from the holistic point of view and what the consequences of autonomously developing could be. But in many cases, the people who were working in IT didn’t always have the rhetorical skills or political significance to be heard, and in other cases functional leaders simply chose not to care, since they were focused on their own KPIs and bonuses. CFOs overruled recommendations from IT, IT frustratingly tried to explain why certain consequences are not the system’s fault, but alas the reality in many cases that came next, was that a massive blame game ensued, between the very two groups that need to be able to rely on each other the most, IT and “the business”.

Enter: Transformation. I believe the “Age of Transformation”, if I may borrow John Mauldin’s term, has come about for two intrinsically connected reasons: softwares are becoming increasingly integrated, and business leaders are becoming increasingly aware of the need to have a holistic, cross functional view, in order to be successful in their own function. Therefore, no matter where an initiative begins, it very quickly becomes evident that to do something successfully, in the current environment, the change needs to be developed holistically; and when that happens, it often gets labelled as a transformation. A transformation is different than a project in that it often is a program and it is different than a program in that it usually involves changes to the business processes, systems and possibly the organization. The end product of a transformation should be a completely different way of working. In my experience, business transformation and digital transformation are two sides of the same coin and it is time for business leaders to put archaic political battles behind, and work collaboratively towards common goals and benefit harvesting if we do not wish to continue wasting money on “bandaid” developments to cover symptoms of problems that should be solved cross functionally at the root.

Building a robust, cross functional Roadmap

As a project manager at heart, I am all to aware of the flip side of taking a cross functional holistic view when all you need is a new system because your current one is no longer supported…….scope creep! If you are not careful, since everything is tied together, every single idea that comes out of the discussions can become part of the scope. You have to of course start somewhere, lest you never start at all. This is admittedly not simple, but it is vital to build an integrated dashboard, where all interconnected initiatives and ideas can find a home, and key stakeholders can rest at ease because they see where their wishes fit into the plan and how they are connected and dependent on things that are seemingly unrelated to them. And this is not a one time activity. It is dynamic and needs to be tangible. Most importantly, this dashboard gives you power to execute quickly by dissagregating specific pieces without losing the big picture integration perspective.

Working with an Operational Steerco

It is not news to anyone that projects need steering committees. But is your steerco operational or just a formality? What I have noticed is that steerco meetings are very serious events. The projects I have had the pleasure of running have VP and CXO level attendees and these people have very full calendars and small attention spans. They want to hear the status, be asked to make decisions, and move on. And I would too if I were them so no judgement here. But the unfortunate flip side to this is that beyond the steerco there is often not much delegation of authority to speak on behalf of the program. And if it is a transformation program, you need a forum where people with decision power, meet frequently, and have engaging dicsussions around topics that impact the future state. And most importantly, you need these operational steering committes to work collaboratively, respecting the equal importance of managing technical, business and and organizational risks and decisions. Unfortunately, this means that if you do not have delegated authority below the C-level, then the C-level need to roll up their sleeves and prioritize the time needed to see these discussions through. Of course, I am not arguing that they need to be part of a daily SCRUM meeting, but the atmosphere needs to become authentic when you do meet and the frequency of meetings needs to be appropriate to discuss things that are important. Transformations cannot apply the same modus operandi that works for operations or non-transformation projects.

Conclusion

It is very difficult to say what came first, the need for companies to work in an integrated, collaborative way or the technoloical advancements that rely on integration and collaboration to produce succesful transactions and reports. But one thing is certain, businesses spend way too much time arguing about who is initiating, owning or driving the next project instead of working crossfunctionally to transform. I realize it is a bit like suggesting we sit around a campfire and sing “kumbaya” to propose that we all work together, but if we want transformation to be successful it is the very people involved in them who need to transform their mindset and way of working. We need to be able to embrace complexity instead of avoid it, and approach meetings with a learning mindset, instead of an authoritative or functionally-centric one. Leaders must take a top down approach and start showing with words and actions that transformation is cross functional and equally depends on committment and responsibility from both IT and “the business”; AND project leaders, working from the bottom up, must find responsible stakeholders from all necessary functions and IT, along with creating cross functional roadmaps to ensure related scope tangents all get captured and given a home. We can transform the transformation and make it something that adds business value instead of creating another immature, painful and costly, ERP implementation-esce disaster which we all should have learned from by now; but in order to change the systems, organizations and processes with which we work effectively, we need to start with people.