On numerous occasions I have been asked for the definition of IT Transformation. Even though I have my own opinion, I decided to investigate further to find out if there was a definitive answer that I could share.
After reading a few interesting articles on the subject and countless hours reading a lot of fluff, my efforts weren’t rewarded with any great moment of enlightenment. I found a blog post with a point worth noting, “Anyone involved with information technology suffers from buzzword fatigue, and the jargon keeps coming. “IT transformation” has become a popular piece of the techie vernacular, but what it means depends on whom you ask. Query 10 CIOs or IT executives about the basic definition of transformation, and you’re likely to get 10 different answers”. Wasn’t new, but amusing… buzzword fatigue, understatement of the century! I think that when you look at the definitions of IT transformation, there is no doubt that everyone has an opinion on this subject – they just aren’t willing to share it in detail. Even in an article by Deloitte stating “Whether a complete company overhaul or the evolution of a specific function, it seems everyone is trying to transform” and “IT transformation is no longer a once-in-a-life-time event that propels a company’s IT function to the upper echelon of the C-suite.” there are no conclusions you can draw as to the definition. While both articles provided me with plenty of reading material, I didn’t feel that either provided me with an answer. What does IT transformation really mean?
I believe, at its most basic, IT transformation can be summed up as a journey that takes the IT department from point A to point B. Not necessarily a physical transfer (granted an office/data centre move would potentially qualify) but more of a metaphysical one. The only similarity I found in my research was that the change had to be considered very significant for the particular business in question. I say for a particular business because, what is significant for one company could be a daily activity for another, perception is undoubtedly a key factor.
Regardless of the definition, the key to successfully delivering any major piece of work, which in the end is what any transformation requires to succeed, must go back to the basics and know the customer’s five W’s – Who, What, When, Where and Why.
- Who is the person that determines when the project has reached the end? – Thereby defining the true customer.
- What does the end game look like?
- When does this programme of work need to be completed by?
- Where does the business want this programme of work to take them?
- Why is this needed? In another way, what are the customers CTQ’s (critical to quality guidelines) and how is success measured?
Even with years of experience under your belt, it is only after understanding those critical factors that one can successfully map the real target of how, which is merely a navigable path from the current position to the planned destination. During my tenure in corporate functions within global businesses, prior to Willard Enterprises, I delivered dozens of “major transformations”. The detailed requirements have always been different and usually even changed mid-way through the project, and this was true even when delivering similar targets for the same company in the same division.
Because there are hundreds of answers to this question, specialising in all of them is entirely unrealistic and more a tune to Jack of all trades and master of none. On a monthly basis, I will be reviewing some details on transformation categories that I have the most experience with through my blog, including:
- Divestments
- Efficiency Plans
- IT Restructuring
- Mergers and Acquisitions
During these posts, if there is something in particular you would like to know regarding overall IT transformation or on one of the subjects I’ve listed above, please post a question in the comments section below or feel free to contact me directly.
In the end, isn’t delivering true IT transformation really just a journey? If you aren’t sure how to navigate it and then attempt to achieve it on your own, you are likely to take too many wrong turns and run out of funds which will force you to go back to whence you started, or find someone like myself with experience who can help you achieve your goal and guide you the rest of the way. I hope the articles I post through my blogs hold a few nuggets of facts that you haven’t previously considered and give you food for thought.
These are my thoughts, do you agree? I, as well as many of the other readers, would be interested to read your opinions and, as always, if there is something I can do to help your business or someone you know achieve their next challenge, please contact me for more information.
If your interested, I highly suggest reading EMC’s take on transformation, there are a few nice tidbits to take away
http://chucksblog.emc.com/chucks_blog/2011/10/leading-an-it-transformation.html
Interesting and thought-provoking post. I agree with you that IT Transformation is more a journey than a buzzword quest; more like a program / portfolio than a point A-to-B project. Though the buzzword innovators do provide many of the alternatives to evaluate.
For me the key is what are the drivers – your Why? question. Sometimes it is dictated by business requirements, other times by technology innovation, sometimes by society or government regulation. Once the reasons are known the path to faster, better and cheaper usually becomes clear.
I am curious to see what others think.
Gary,
I definitely agree it is more of a program of works versus a project (as well as a significant mind shift as well) but I was going to save the definition of project vs. program post for another day…
For me the really useful definition of IT Transformation must be focused on the business rather that IT… oddly enough! I would say it is the
introduction of, or change in execution of, IT in order to achieve a business goal.
Programmes and project are how you do that!
I guess it all depends on the prism used to view IT Transformation (or any, for that sort) — for companies that somewhat stagnate and need a jolt to move, it may feel like a quantum leap. For others, the likes of GE / Accenture, change is the way of being — where keeping still is not an option (you either move or are moved), in which case is a journey.
I think the most difficult part of the “Transformation” is making it last — do you burn bridges (or boats) to ensure it does not roll back by itself once the ‘project’ is completed?
I agree with your take, one businesses transformation is definitely a daily task in others. In the same fashion that one doesn’t require a map to go to their office on a daily basis, but people going there for the first time are likely to, the journey of transformation only really applies when used to take someone somewhere new for the first time. What is new for me, may not be new for you and vise versa.
Burning bridges to ensure people can’t go back to the old ways is one way to deliver change quickly, but I have found that this option only works while still in your presence. Unfortunately, the people that remain are more likely to rebuild those bridges once you have gone, if the process isn’t theirs. Not as malicious intent but as a pure habit or a path to least resistance. People are creatures of habit and dread wasting time unnecessarily (even perceived), if the teams living with the change are to embrace it, it needs to improve THEIR needs in some way: e.g. simplifying, saving time or cutting bureaucracy…
Rather than burning the bridge, I suggest transferring the ownership and delivery to the most vocal of your doubters, not your advocate. Sell them the dream, get them to deliver the future, and they will do all of the convincing for you. Equally, the solution will last far longer than you or the challenging members of staff who told you it couldn’t be done.
Does that help?