Last week, one of the global IT biggies invited a bunch of CIOs to their R&D Center with the defined agenda being a discussion on future trends and movements in their technologies; the idea was to get some early traction with old and potential customers and field testing that helps fine tune a product. Apart from all this were the good old peer networking and some high spirits if you know what I mean. So I was enticed enough to join the group to give away a weekend in the name of learning and networking.
CIOs in captivity!
Like all such gatherings it was a good start with key leaders and guys oozing tech from their ears talking about new disruptive technologies are coming our way in the next 2-4 years. They held sway in the graveyard sessions post-lunch, with sleep overpowering only the infirm or the bored indifferent (which did not matter). Most cynical CIOs on the wrong side of forty acknowledged the prowess and the future opportunity. Good things don’t last and this one too didn’t.
After the first two sessions started the mundane, the irrelevant and the hard sell; data center density, cooling, and power consumption. Virtualization and private cloud are good, a higher virtualization ratio even better, but 20K VMs in a rack? Why do I need 20K virtual servers? The nail in the wall was when someone decided it’s a good idea to teach CIOs how to configure a VM and then move it across racks with no downtime. I am not sure if CIOs want to be doing that or enterprises want high cost CIOs to do that!
I mean does a CIO teach the technology architect the finer nuances of VM management? To rub salt into the wounds, they extended the session over the coffee break to cover private cloud extension to the public cloud. Now I am sure that my server admin would be kicked by this demo, none of the CIOs in the room were. They expressed their displeasure in no uncertain terms, some decided to leave the premises as soon as the break was declared closed. Patience too has its limits.
The point of culmination
The climax was waiting for the following day; a visit to the R&D facility! We all got into a bus, arrived at the big building, signed in with sobriety and were taken to the show. We entered a room with biometric authentication to be faced with rows and rows of racks with cables dangling from some. Proudly the scientist pointed to one of the racks and started talking about why it was different and the innovation that went into making the hardware inside and why we should immediately order it.
I could not remember the last time I had visited a data center (even my own); digging deep into memory it dawned that it was more than a decade back. I whispered to the CIO next to me and he too reminisced a long time back. A few others had been to their outsourced or co-located data centers when they had signed the deal. I wished my infrastructure head was present; maybe he would have appreciated the significance. To us, the CIOs, it was a lost experience, we did not share the enthusiasm.
Does or should the data center matter to the CIO? The vehement answer would be ‘yes’ from many. Then what about the cloud? Have you visited the Google or Amazon or Salesforce.com data center? Do you know when you buy SaaS where it is delivered from? I believe that we need to come out of this obsession; the vendors need to start defocussing the data center and start engaging on business outcomes. Yes, the data center makes the IT run, but to pick a line from Nicholas Carr, the data center does not matter anymore!
When I wrote about requirement gathering versus solving business problems last week, I did not anticipate the kind of comments I would get. The agreements and flurry of lateral thoughts gave me enough impetus to continue the chain and focus on some of the views. Almost everyone agrees that we need to solve real business problems; the challenge is the definition of the business problem and changing the mind-set of our customers to stop thinking about technology and really tell us about what they want.
We talk about IT folks not speaking plain English or Spanish or whatever is the lingua franca, business tries to talk IT lingo and confuses the blazes out of the Business Analysts. Every industry has its slang and acronyms that add to the confusion (domain experts know this, but keep quiet). Between the domain expertise and the attempt to straddle the gap, the real problem gets lost in the chasm or some finer nuances remain uncovered. This then leads to what we classically refer to as out of scope functionality or scope creep.
The word creep somehow makes my hair stand up, that is the way of creepy guys or gals. Scope creep however indicates that no one articulated the problem or thought that it was unimportant or irrelevant to the discussion or just simply forgot to talk about. There are also instances of assumptions where the giver assumes that the taker has the knowledge by virtue of it being public domain or so obvious that it does not merit being explicitly being specified.
Translated to a document which the developer (read coder) in some faraway place sitting in a cubicle totally disconnected from the discussion is now writing the software that will be put up to the business. S/he does not have domain expertise and depends on the document to decipher what should be. We all have faced the end results that have missing pieces and functionality since it was not captured. Even when the development is undertaken internally these gaps exist albeit to a lesser extent.
So now the IT team gets beaten up and the Business Analyst bashed up for not translating adequately the business problem. Then the dance starts on what was said, how it was interpreted, and why does not IT make efforts to understand business. Escalations get nasty with the CIO having to face the music. While I generalize the problem, I have not come across too many instances of stupidity or wilful exclusion of documented features or functionality.
The skill of the Business Analyst to ask the right questions and probe are critical to the definition of the problem and thus the document that becomes the Holy document on which the system will be based. Leave out anything and you have a system that does not meet requirements thereby giving rise to “change requests”, the bad word for any developer, business user, IT team, CIO, CFO and whosoever is a stakeholder in the success of the solution.
Is there a way out? I believe that the CIO needs to play an important role in setting expectations upfront and defining the rules of engagement. S/he should educate the business teams on the criticality of the discussion and the necessity of clearly spelling out every aspect of the business and process irrespective of how stupid it looks or its obvious nature. A system is as good as the people who define it; trainees and junior staff with shallow expertise will provide only that, an incomplete system. Creepy no?
The journey of a thousand miles begins with a small step; similarly, the development or deployment of systems and solutions begins with requirement gathering. Conventional wisdom has it that IT teams talk to business users to gather their requirements, and then go about creating or finding a solution which fulfills defined selection criteria. When an agreement is reached between the users and IT, the system is then implemented. No user requirement, no solution.
Over the years many research papers have been written on the methodology and science of gathering requirements. Consultants created templates and promised success with common and uncommon sense. It has also been the subject of ridicule with challenged implementations, many of them attributed to requirements either not being articulated adequately or changing requirements leading to scope creep and thus sliding timelines. The most famous amongst these has been the pictorial representation below.
Image courtesy: © Paragon Innovations
When I reflect back on the time I was a rookie programmer, I too went through the journey albeit with not too many such experiences. I remember instances when the disconnect was complete while in many the users loved the solution and the benefit delivered right first time. It never occurred to me at that time to analyse why I got it right sometimes while everyone was miserable in other instances. Eighty percent success was deemed good and that kept everyone happy.
Seeking some expert advice
So last weekend over dinner when I met a CIO who recently inherited a legacy of many challenged projects, I was curious to find out how he planned to overcome history and get everyone moving in unison in the right direction. When he took on the new position, the buzz in the market was that the veteran of many industries and acclaimed implementations had taken on more than he should have. Everyone wished him luck and wondered what went wrong in his previous company for him to take such a risk.
The first month was spent assessing status, understanding and cataloguing projects, getting the team to wake up from inertia, and getting the business teams to start talking. In the company with many custom solutions, there were many stories on what went wrong in the past with fingers pointing at lack of business domain, incorrect interpretation of requirements, discipline, engagement, low skills, sliding timelines with projects not delivering even with 200% escalation in time and budget. The IT team was demoralized and had given up all hope.
Many months into his new role the vendors were on fire hearing about the transformation, change and the investments that had suddenly mushroomed. Old projects rejuvenated, new initiatives being aired; there was a direction where none was thought possible. The story had believers inside as well as outside. Having heard about this I was excited to be in his company to extract some insights on how he went about solving the unsolvable problem.
The CIO smiled at the questions and said, I coached my team to ask all the right questions and did the same myself with the CXOs. He elaborated user requirements will always contain not just what they need, but also what they think they want or should have. The requirements always contain many elements that are nice to have and not necessarily aligned to current reality. That is why they are referred to as “requirements”. So what are the right questions?
Ask the right questions
“What is the business problem you are trying to solve?”, “What will change for you or your customer once you have this new capability?”, “Is the benefit measurable in money or time or efficiency?”. We all ask these questions but not too often; we are happy gathering requirements and then executing solutions which are then sub-optimally used. Requirements tend to get unwieldy with all the exception conditions being mapped; in the end it does not solve the original problem but creates new ones.
Winning teams today do not focus on requirements, they ask the questions above and create solutions that solve real business problems or capture real business opportunities. I believe that the future holds a lot of promise to those who follow the new way of thinking and discard the old requirements lead approach. What do you think?
Earlier in the month I was invited to a session by a senior well-known IT Research Associate who advises many global CIOs on tactical and strategic agenda. He is a good story teller and had the audience of 20 odd CIOs spellbound with his anecdotes, examples and occasional taunts which most took sportingly or sheepishly depending on how you interpret the expressions on their faces. His consistent grouse was that while CIOs have done a lot for enterprise productivity, they have neglected IT productivity improvements.
Internal IT under scanner
Tracing through history he illustrated the role IT has played in enterprise process re-engineering and productivity improvements driven by automation, new tools and technologies, mobile enabling the enterprise, and providing time sensitive information in the hands of the decision makers. However during this era the IT team has not demonstrated commensurate improvements; solutions still take as long if not longer than what they did many decades back. He postulated despite progress across the industry, the in-house IT team has lagged behind by a big margin with no major visible improvements.
He went on to compare internal IT teams with the work being done at start-up and tech innovation companies globally. Across comparison parameters on innovation, time, productivity, quality, or sheer volume of work done, IT departments lag behind. He blamed this on mind set, archaic beliefs focused on process compliance to whatever framework the IT team had adopted. ITIL, COBIT, PMI, CMMi were boon in the past; they are the bane now. Agile development methodologies find rare favor with IT.
A reality check
He did not offer any empirical data or prescription, but no one from the audience disagreed. They sat there silently reflecting on their own realities. Post the hour, I sat ruminating over the discourse trying to figure out if this was indeed universal truth; if it was so evident, how is it that no one has thus far talked about it because everyone loves beating up IT and if it was so evident a simplistic comparison, it would have been well searched and figuring in the Top 5 priorities of the CIO and every vendor!
How do we measure IT productivity: Lines of code per day? That no longer seems relevant with the shift from procedural to new way of creating programs. How about number of people to support per 100 compute or network assets, or servers; even that is now irrelevant with virtualization and clouds taking over. Maybe number of locations, or solutions in the IT portfolio, time to respond or time to repair; most of these activities are anyway outsourced with SLAs.
Business value of IT
The baseline has been shifting and IT has adapted well to the change. In linear motion it is easy to measure a shift; in the real world it is a little difficult to quantify. So what efficiency parameters should the CIO use to demonstrate improvements if at all? The CIO dashboard and reports have evolved from technology availability to business value. Productivity gain is not specific any more but interconnected and interdependent. People do not measure activity but outcomes.
IT-influenced results are business agility, competitive differentiators, low cost of operation (Business and IT), and growing revenue faster than market. If the CIO is indeed driving these and well accepted and recognized by the enterprise, does it really matter if the lines of code generated by the IT team is lower than the industry benchmark?
The pitch was passionate enough to keep the audience awake. The speaker and his assistant were animated in professing the virtues of their products. They kept on imploring the CIO to consider their wares instead of the market leader, even though they had only 10% market share in comparison to the leader’s 60%. The CIO who had listened patiently for more than 30 minutes thanked them for the presentation signaling an end to the meeting. The entire sales team was aghast! No questions?
It was a large deal that had every vendor wanting to show their wares with a hope of getting the business. The company had embarked on a major transformation after many years of hibernation. Thus there was a sense of expectation in the market and rightly so since whosoever bagged the order would become the standard supplier for a long time to come. The total business potential was very large commercially as well as from market visibility perspective.
For the vendor having discussed the architecture and the overall strategy with the IT team, the final stage to qualification was expected to be the meeting with the CIO. So the vendor pulled all plugs and brought together the best possible team for the presentation to the final decision maker. They knew that they had a chance of making the cut since the market leader had no presence as yet in this account. The CIO was also known to be fair in his approach and that added to the expectation.
The meeting started well with the setting of expectations and illustration of the approach, product features, open standards, and recent wins across industries. So far so good, but midway something broke and the fervent pitch turned awkward; rather than discussing merits of their product, approach and solution, the sales head started talking about the problems the CIO is likely to face if they selected the leader’s products. Now it was not about what they did but what the leader did not do.
It was not evident to them that they were no longer connected to the audience and had lost. The CIO patiently heard them out through the leader bashing; he proceeded to close the meeting with a polite remark that once the decision was finalized, it would be communicated to everyone who participated in the evaluation. As they left there was a sigh in the room; the CIO and team sat quietly trying to shrug off the negativity. Nothing needed to be said; everyone unanimously agreed that this was curtains.
Why do some people resort to negative selling? Why do they not sell on merit? Don’t they realize that it puts off the environment and has an adverse impact on the outcome? Is it the desperation of targets or month/ quarter/ year end, and the need to sell at any cost (ends justifying the means) that brings to fore such behaviors? Despite losing almost every such deal (I am sure CIOs can see through this clearly), the tendency remains to put down others to show superiority.
I believe that good is not always relative to something else where the other has to be proven not good. This maxim has to be understood for the behavior to change. A product or service can be classified superior by illustrating the benefits or features; let the recipient of the information decide in his/ her frame of reference whether it is a better fit than others. Everyone does not use the same yardstick neither does everyone compare the same products/ services every time. It would be great if our IT vendor community understands this and starts creating better services and products.
As a CIO I would love to do business with such a company, wouldn’t you?
I had an interesting discussion with an executive search professional who called to ascertain interest in a position with her client. Her company is known as one of the premier head hunters that work only on C-level placements and does a good job of that. Her client, a large diversified group, wanted a business IT professional for the position of a CIO, reporting to the Group Chairman. She believed that the position was exclusive and merited attention.
As the discussion progressed, she sought my view on current CIO compensation levels. I pointed her to research done not too long ago by an IT publishing house that provided the range in which CIOs were placed with slices for industry, experience and location. She expressed dismay on the median and the fact that most of the IT leaders titled CIO were underpaid in her opinion in comparison to other CXOs. Her data points were the placements her company had executed.
The CIO-compensations analysed
Ruminating over the discussion I saw a thread on one of the professional social sites on a similar subject. Is CIO compensation in line with other CXOs in the company? Does a company perceive similar value contribution by the CIO? Are there CIOs out there who earn more than their other CXOs? The answers validated the revelation the head hunter had a few days back. Most CIOs are ill positioned and not on par with their peers (my definition: 5% variance is on par); the exception group is miniscule.
What contributes to this situation? Is the gap due to the position being still seen as a service provider and not an equal to say the CMO or the CFO? Does the person in position influence the decision on the monetary value? The industry variance exists though the gap varies. I started scanning data from other countries and found that the story was similar. Exploring age or experience gap, the data revealed that this factor was not relevant.
What is the CIO’s worth to a company? S/he keeps the business humming 24X7 across locations with connectivity, business applications, mobile connectivity, information on demand anytime anywhere, business intelligence and analytics, sales force enablement, supply chain visibility, production planning, customer relationship and engagement management, ecommerce and m-commerce, scheduling and operations of flights, hotels, information security, business continuity, phew! Is all this of any value?
Ask anyone in a company the challenges and chaos or the disruptions when any of the above stops working. The impact varies by company and industry as the elasticity is defined by multiple factors. Antagonists will say all this can be outsourced; yes it can be, however someone has to first set it up before the operations can be given away. Even total outsourcing retains part of the IT team along with the leadership to strategically keep the technology in line with the changing market and needs.
You define your worth
I believe that the value of the CIO is defined by the CIO. The discussion, debate, and engagement of the IT team with stakeholders; articulation of change, success and the value creation with IT systems contributes to the perception of value. Contributions to business decisions add up; taking a position on issues not just limited to IT make a well-rounded business leader and earns respect at the table. How the IT team interacts and presents itself is a reflection of the CIOs leadership.
Will all this bring value commensurate to the effort and monetary reward comparable to others in the enterprise? The suggestions above are a small representation of CIO behaviours that contribute to his/her locus standing. Each person has to find their balance and align it to their reality; don’t try to change the world, change yourself for your own sake. I am saying this from personal experience.
The relationship between the CIO and the CFO has been discussed with adversarial undercurrents as the general perception about the CFO portrays a beanie counter. This is analogous to the CIO remaining the EDP Manager, but the prototype has stayed stuck; in a similar vein where the belief continues that the CIO has not evolved and is still the Chief Technician who fixes Boardroom projectors and the Boss’s email.
Recent time, with the resurgence of social media, has seen the emergence of another debate about the CMO cornering a large proportion of the IT budget. This news which could be based on some data points in a survey in a small geography for a sub-segment of a domain, the conclusions depict the CMO usurping the CIO chair; a real stretch of imagination, but which has a group of CIOs vehemently opposing this purported trend. Some discussion groups even want the CIOs to confront their respective CMOs and assert their power over the IT budget.
The CEO factor examined
So when I had an opportunity to partake in a CEO get together, I was looking forward to clarifying a few assumptions and doubts. If you are wondering what this has got to do with the CFO and the CMO, well along with the CIO, they all typically report to the CEO who is expected to mediate in case there is a conflict within his team. The above presumed conflicts will sooner or later end up for arbitration or follow the general trend where the CIO backs off.
I love interacting with CEOs (including my own CEO); they are the better barometer of IT progress and use within their company than the CIO is. As the primary leader of the enterprise, s/he sets the behavioral norms and culture of the company. Their belief system percolates down the spine of the company influencing processes, process discipline, technology deployment and use, risk behavior and finally the cohesiveness of the Executive Committee that runs the company.
Since I knew most of their CIOs it was easy to create correlations: big manufacturing CEO used social media extensively, his CIO is well known for success; mid-pharma CEO who thought of IT as a cost center had high attrition in IT; a diversified group’s young digital native CEO had the CIO soaring high from success to success. You get the trend; the CEO is the lead indicator of how the job of the CIO is likely to be in a company and where s/he will stand in case of a conflict with other CXOs.
The reporting structure
If you benchmark companies with CIO reporting to CEO versus other CXOs, the comparison set clearly demonstrates the ones with the CEO fare better even when the CEO is not necessarily IT friendly. In the control group which ranges from 30-80% (CIOs reporting to CEO) depending on the geography and industry, the next differentiating factor is the CEOs appreciation, tolerance, averseness or indifference to IT. It is evident that the CIO directly or indirectly influences the success of the CIO.
Should the CIO be insecure about the span of control, budget, or technology disruptions? Most CIOs aren’t but the hype created by various factions would make you believe that the CIO is shivering with fear uncertainty and doubt (FUD factor) on his/her future. Reality being diametrically opposite, I believe that CIOs should stop reacting to rumors and instead start proactive communication on the contributions to different parts of the enterprise in making the CMO or the CFO successful. Let them be at the receiving end for a change!
A recent edit in an IT publication discussed the pitfalls of the CIO going out on the field meeting the end customers of the company’s products or services. It highlighted the fact that most CXOs wanted the CIO to stay away from the customers and not encroach on their territory. The CIO meeting customers was seen as disruptive and a threat to their relationship and the final moment of truth with the consumer. This observation was believed to be consistent across industries as well as size of the company.
A call to the Editor resulted in her portraying the reality she had witnessed on the discussion table that included some heavy weight CIOs. They were tentative in their approach to reaching out to customers; this was not viewed kindly with heavy brick-walling. A casual interaction was fine, but not continued engagement that may result in a different reality for the sales / marketing teams. Of course, there were a few outlier CIOs who did systemically meet the customers and shared insights with their teams.
My reality being different from the majority, I decided to chat up with some CXOs to determine if reality was indeed that grim. I picked a few high-touch industries like retail, banking and airlines, and added some low touch ones like pharmaceuticals and FMCG where the end consumer is largely faceless. Then I started searching through the good old visiting card rolodex, my connections on social media and professional networking sites; finally adding some with help from industry bodies.
I had some apprehension if I will get candid responses, so I decided to use the research envelope which does normally get open answers; you know researchers are perceived as non-threatening since in a statistical model, there is no identity. The modus operandi worked well and my research was successful in capturing reality with high fidelity. The correlation to industry or size of company was not decisive, the general trend was however quite evident.
Marketing and Sales have over the last few years faced uncertainty due to the global economic uncertainty and the impact it has had on consumer sentiment. Corporate as well as individual spending has seen a general holding back. Do we really need to spend? Do I really need the latest gadget? Such decision points have resulted in pressure that has everyone looking inward more than outward. Natural reaction has been to hold on to the fragile relationships. What if the discussion turned away the customer? What do you know about customers anyway?
Mr CIO, you have no business to …!
One of them quite paranoid went on to state that IT has no business prying into relationships; he had advised his team to keep everyone at bay like the pirates; auditors, information security, anyone who asked for data was turned away. Even the BI reporting was curtailed lest it be used by someone to create different conclusions. The company in question was struggling for growth though doing better than some of their competitors. In the high growth era, they were the leaders, now that appeared to be chapters in a history textbook.
Can the CIO change this behavior? Being an optimist, I would say, probably yes! Is it worth the effort? Many would say, certainly not! And I tend to agree with the collective wisdom though with a caveat. I believe that CIOs are always at the short end of disruption; so they should not back off in the face of this push back but continue the dialogue while getting others behind the cause. Different perspectives have always created new opportunities. After all, you cannot expect different results if you continued doing the same thing over and over again. I have lived by this maxim and I am still alive.
The IT industry has many types of vendors; some focusing on niche solutions, some specializing in specific technologies or domains, some who offer a menu of products / services ranging from infrastructure to applications, and then there are large diversified companies who do everything from consulting to implementation of technology solutions or packages backed by support services in a local, offshore or multi-location model. The big guys manage all kinds of requirements and bring to the discussion table a comprehensive long-term engagement model.
Different vendors set different expectations on what they can deliver; the niche providers do not promise a breadth of services, they stay focused on their expertise. The big ones claim to have expertise across the legacy to contemporary and cutting edge; they have industry practices and business consultants who profess incremental to transformational change capabilities. You name it we can do it; even if you cannot put a name to it, we will find a way to do it!
Complexities in governance
The large one-stop-shop engagements typically begin with setting of scope and expectations on delivery, timelines, and quality of service, rewards, penalties, force majeure, arbitration, cost, escalations and a lot more. The larger the scope, or the longer the time period of the contract, the governance becomes complex. We know that Total or Strategic outsourcing can cover everything; in recent times though the number of such deals has been dwindling.
So it was an interesting debate when a few CEOs on a panel berated the one-stop-shop companies giving it a new twist. Consider you wanting to reach a far-far away destination and the only option is to go by bus. Every bus gets you there, some are slower than others, some offer many comforts through the journey; the cheaper ones just get you there. Depending on what you can afford, there are many options to choose from. Caveat is once you have bought a ticket, a change is difficult and painful.
When someone advertises ‘one-stop-shop’, the conventional understanding is that I get from where I am to the final destination with no stops with the advertised and agreed comfort. Reality as we know is not always as advertised. A CEO remarked on his journey with one of the global biggies; he signed up for a long journey wanting to focus on his business. Very quickly he was on the discussion table with the bus driver, conductor and the entire fleet management company.
Why is my journey so excruciatingly slow? Why is the transformation promised not happening? When will I see any impact to my employees, stakeholders, customers, or for that matter any efficiency to business operations? Whatever happened to the pre-sales promises made by the various function heads of your company on various domains and technologies? Pat came the answer, “we are a one-stop-shop company; we go one stop at a time. This is what we promised; we did have a driver change and a breakdown; that is part of the contract. We meet defined service levels.”
Devil lies in the detail
Both are right in their frame of reference; so where is the problem? I believe that any such engagement should have common definition of reference points with clear understanding of step-by-step process, impact and governance. Otherwise the semantics of the one-stop-shop can be painful for everyone involved, the deliverer and the recipient. The bus is still moving but not in the way that makes the journey a pleasure. CIOs will be at the receiving end if there are such gaps.
Almost a decade back I remember a company that after spending a large amount of money with consultants going through the whole nine yards and then some more recommended rechristening the IT department as Business Technology. It was a move driven out of the aspiration to stay ahead of the crowd and differentiate. The BT group was different from Corporate IT and a few other IT groups within the enterprise; they were the elite. This was in the era when IT was just beginning to gain acceptance.
This large and diversified company was written about; the bold move spawned research papers and everyone acknowledged that the future belonged to Business Technology. Slowly over a period of time the internal customers of this group started asking the question, old wine in a new bottle still tastes the same; where is the change in attitude, delivery, partnership, innovation, all the good stuff that was promised and expected. Whatever happened to the Vision and Mission? Interestingly the leader retained the title of CIO and not CBTO. Maybe she did not want to tell a story.
Twist in the tale
Then I met another IT leader of a successful company who gave me a twist in the story. He had named his function STT. With me lost trying to decipher the TLA (three-letter acronym), he proudly unveiled the mystery with the logic: we create solutions; they are a lot more than hardware, software and networks. However whatever we do has a common underlying Technology framework. Solutions are holistic and do not constrain the thinking process. So our team is aptly known as Solutions & Technology Team. Ahem! Many years later the poor chap is lost in wilderness; he stressed more on the middle T than the first S.
In recent times there have been many discussions and debates on the changing role of the IT leader; some of them concluded with recommendations that the title CIO is no longer relevant and the role as it stands today will no longer exist in the next XX years (fill in whatever number you like). So, the name should be changed to reflect the new reality. Suggestions cover the entire alphabet soup with rationale based on not the CIO but the proposer’s frame of reference.
What’s in a name?
Does it matter what the function is called? Do semantics make a difference? Will the reality be different for the involved stakeholders depending on the nomenclature? How much does the name contribute to reality and success? Can an IT department transform itself with a new name? Is a change required with every changing technology trend and business evolution (would you like to be called Chief Cloud Officer)? I am not proposing going back to the historical EDP, but IT today represents to a large extent the sum of the parts that make us.
Success is a result of great attitude and not the other way around; I believe that individuals and leaders portray themselves based on past track record and the engagement that they are able to create. The IT team collectively mimics the behavior of the leader. This paradigm is true for all functions and no different for IT. CIOs should stop getting distracted by these irrational and irrelevant thoughts and focus on what matters to them, their teams, their customers (internal), and their customer’s customers (external). After all the best measure of success is success itself.