My friendly Board Member who has also been my mentor for some time now always brings up very interesting points in discussions. I have always enjoyed talking to him as he challenges conventional wisdom with his way outside the box ideas. Being technology savvy, discussions with him tend to be not just at a high level but at times I have to explain why one solution scores over the other. In one such meeting he brought into the open a dimension.
Selection of a tool
We were discussing a new predictive analytics solution and its adoption in the industry not just locally but globally. With no competitor locally using such a solution, with bright eyes, he started drawing the end game that he wanted us to reach; the dimensions were simple in their representation but complex to execute, requiring multiple data sources and algorithms that would challenge most. As the big picture unfolded, it had me and the team scared and excited about the leap forward for our company.
Using a formal matrix for evaluation of the solution is normal for IT; functionality, roadmap, customer success, ease of use, scalability, investment, and industry-fit are some of the parameters. He helped us refine the list discarding most of them considering every solution scored a tick on them. It then came down to a few that focused on strategic intent and investments by the vendor. E.g. How many customers has the vendor invested in to enable them to succeed?
Thus the discussion was at a different plane working on the methodology, plan and shared success criteria that had direct linkage to business outcomes. I could sense wariness in the business, IT and vendor teams on the perceivably risky proposition. What if the solution does not work? What if the industry changes shape or direction? What if business users don’t use the end result for decision making? How do we enforce the models that the solution recommends? What if …
Playing it safe?
Success and failure rates of IT-led projects have been a statistics that scares every one; the reasons have not changed much over the years since I read about them first–more than 15 years back. So there was some hope with a project endorsed by Board Member, but then the big question was if we can sustain his interest over the 18-24 month period in which the end outcome would be measured. We decided to raise these questions to moderate expectations and ended up inviting trouble.
Why are you all so risk averse? How would innovation happen if everyone wanted a fool-proof solution that someone has used in the past? Why are you always looking for precedence? Early adopters always gain a competitive advantage even if it is short-lived; in most cases, the followers get lesser benefits. If you keep working with a view that we don’t want to get anything wrong, is there a guarantee that you will not? And not getting it wrong does not imply that you will get it right!
Doing nothing wrong would mean that status quo is the best place to be; trying something new is always fraught with risk. I am not implying that we take undue risks on new untested technology solutions. To get something right requires collective buy-in that CIOs seek for most projects; the marquee CIOs take a lot of calculated risks, and yes, they do face failed projects more often than others. However, they more than make up for them with their successes.
Inertia is not a good keyword for IT and CIOs; they should seek unexplored avenues to make a difference. I believe that we all strive for success and in the same vein we have a phobia for failure. The obsession to always succeed may result in a dull and boring existence that is disconnected from real life and business which has to compete every day in a new competitive environment with uncertainty. I tend to agree that doing nothing wrong does not mean that you are getting it right!
The front page of a business newspaper carried an interview of some of the big 5 IT services company CEOs that had me engrossed as these industry captains shape the direction for the industry, influence decision making and are consulted by global CEOs on IT strategy and direction. Thus the interest was high to gain from the collective wisdom as they talked about their experiences with global CIOs, decision making process, budgets, successes and finally their perceptions of where CIOs could and should be.
There were some clear messages:
- The global economy will continue to remain under pressure for the next couple of years
- Outsourcing deals will be smaller and of shorter duration as IT budgets will see a lot more rigor in the discussion
- Talent shortage will squeeze growth for IT companies and Cloud computing will keep the hardware industry challenged.
- The CIO-role will change again with technology evolution–the difference between the good and the challenged CIO will widen.
A vested interest?
They outlined the differences on how CIOs across geographies and industries outsourced core and non-core activities to focus on what matters, i.e. you guessed it right, the business. But then they also mention in the same breath that CIOs that did not outsource remained challenged to align the IT objectives to business. Whether it is remote infrastructure management (RIM), or application maintenance, and everything in between, the message was clear, outsource or perish, get relegated to reporting to the CFO.
Huh? Now that is simplistically stretching a facet of the CIOs role to create a perception that outsourcing can be equated with strategic intent. If you don’t outsource, then you and your team is busy with things that do not matter to the business and thus you are likely to remain alienated. Was there a vested interest in the words from these CEOs who have been struggling to grow their business? Some had taken over from ousted CEOs with a clear mandate to bring back the old days of high growth.
Time to introspect!
While I am a proponent of outsourcing and have partnered with IT service companies big and small to give away the technical or operational activities, in my experience there have also been cases of outsourcing not delivering to promise. CIOs connected with the pulse of the business draw the line on what needs to be given away and what should be retained. The company’s focus, perceptions of core, and finally the financial health determine what operating model should be adopted by the CIO.
The CEOs went on to talk about CIOs need to engage their stakeholders on what matters. People in a glasshouse do not throw stones at others. My plea to the same CEOs is to introspect a bit before preaching to their customers, the CIOs. The sales heads of the same companies want to engage with the CIO on nitty-gritties of technology that even the next level in the IT department rarely gets involved in (OMG, I saw a data center). They do not practice what they preach. A few CIOs I met the next day agree!
So what separates the good from the challenged? I do not for a moment believe that it is as simple as outsourcing operations or infrastructure or total outsourcing; a good CIO is a well-rounded leader who manages people and perceptions while ensuring that the delivery of promise is consistent with quality that is visible. S/he communicates effectively in all situations and is able to challenge business and IT partners/vendors in a discussion on the right solutions to business problems enabled by technology.
Is this the finite list? No again, there is no checklist that determines the difference; you have to find your balance.
Recent times have seen some distinguished CEOs and leaders biting the dust literally when some untruths were discovered in their resumes, a clear case of unnecessary padding. A few did not possess the qualifications they professed, some had not been to colleges they put in there. These are not run of the mill average Joe kind of people, they are in high offices and have shaped the future of many. It created news for a short while, and then everyone moved on relegating the tainted ones to oblivion.
To expand the team, I recently started hiring fresh and experienced talent and was flooded with resumes. It was a task to navigate through pages of hundreds of eager professionals looking through spell check errors, acronyms that I have no clue what they mean, grammatical goof ups, and multiple formats that challenged me to find information in a maze game. These were not freshers, unexposed to corporate culture; they included experienced professionals with decade-plus behind them.
I did not challenge the veracity of the information presented even in cases that stretched conventional wisdom, though annotating to explore further in the interview. I discovered that IT folks are largely truthful and sometimes too much; if they have been on a project that involved a leading edge technology, they will ensure it catches your attention. Only on digging deeper you realize that their role could have been just testing or documentation; or maybe peripheral and not technical or functional.
The conscientious mentioned every project, every assignment, and every new company even if they spent only a few months in each; though the interesting ones were the gaps which during the interview were explained in shy and embarrassing tones. They believed that if you join a company and realize that it was a mistake, don’t mention it; skip the experience that does not reflect well on your resume. No mal-intent here, just that not always in interest of keeping an abridged and concise representation; just to put the best foot forward.
So how to get the real person out of a few pages of history including education, experience, achievements, personality, potential, technical skills, and what have you. There are umpteen reference websites that offer to teach the art of interviewing and getting the best out of the person sitting across the table, the potential candidate. The intent though not adversarial is to assess everything possible about the person in the typical less than an hour spent, lateral thinking and what not.
I am not sure if this would make sense, but it is not just the responses to the questions that help us in the selection process, there is a lot more. The first few minutes have already decided the way the interview goes; subconscious mind or body language, you already know if you will like the person. The resume and the detailed planning are then thus pointers to the discussion. I have rarely seen a situation where the candidate was able to swing it around though many did not live up to initial expectations.
Coming back to the moot point, why do people manipulate resumes? Is it just to look better than who they are or a desperate urge to get something that is not rightfully theirs? Is it misplaced self-esteem or belief of personal value? I don’t know; everyone probably has different motivations; do they realize that in the end they are really undermining their integrity and the way people see them? Or has the value system changed in a way that we are comfortable with little lies if they go unnoticed?
In the monsoon season, clouds are a good subject to discuss. The last event I attended headlined clouds of all types; public, private, hybrid, that had everyone exchanging notes on experiences in drought and rain.
Participants from public sector and government agencies, companies–big and small, service providers, and a few academics, all found something to talk about and share. The organizers were beaming and so were the participants; networking at its best, which most events promise.
There were a few small groups that decided not to move out of the conference hall during the breaks finding comfort in each other’s company. It was evident that they were not at ease in reaching out to strangers and discussing subjects of mutual interest. Our IT teams have many such people who lack the social niceties and behaviors that are normal in, say, the marketing team. Such individuals are present on social networking sites albeit as silent observers rarely posting or sharing anything at all.
Importance of soft skills
Over so many years I have wrenched such individuals from my teams from their machines and pushed them into the big bad world of people who are unpredictable, emotional, talkative, demanding, lively, aggressive, and overall human in their demeanor. The above-mentioned IT folks cringe at the thought, but slowly and steadily open up and realize that it is not so bad after all. Most are able to transition over the boundary into the normal, the rare few who do not constitute groups like the one I saw.
In a hyper-competitive world that demands higher performance every day to stay in the same place, the balance between soft skills and domain (or technical) expertise is important. Everyone talks about the traits CIOs need to embrace; the teams are left to fend for themselves, and in most cases, at the mercy of the individual CIO to elevate the level at which the IT team operates. Successful CIOs who nurture talent and high potential performers invest in their teams giving them the platform and reason to grow.
Drawing a parallel
So what has all this got to do with MPLS networks? By definition MPLS networks were defined to create efficiency over existing networks in the mid-90s. With evolution they became the preferred option for many. Network administrators loved them for reliability and performance; they hated the opacity by virtue of the cloud architecture. It was big evolution for many and most techies adapted well. This is evident from the fact that most enterprises embrace MPLS over other network types.
In the real world of people, recent times have seen disruptive changes due to social networks. It has had the world excited, the marketing teams worried, and everyone wondering on whether there is a ROI in social network. Consultants have thrived and definitely made some money. It cannot be denied that Most People Love Social Networks. They provide freedom of expression in a level world. IT organizations clamped down with security concerns. Now, social media policies have replaced dictatorial censorship.
Taking the lead
Some mature companies have seen their CIOs take lead in this arena and drive social media strategy successfully and a few also found a way to make money. These CIOs and IT teams belonged to the MPLS network groups, did not talk about old paradigms like BITA, had higher success in customer engagement and continue to be the envy of the world at large.
I believe that MPLS is the way forward for everyone. IT has to lead from the front and not follow in the back. Where are you today? Part of the MPLS gang?
Talking to a few CIO friends on the much debated and discussed subject of “what next” for us, the CIOs, many aspired to be CEOs. Now that is a good thing given that CIOs are setting their goals high; some are also achieving it within IT companies, a few in other industries too. Making the transition was possible for them as they graduated from technology enabling to business enabling to business itself. Their leadership was acknowledged and when the opportunity arose, they were considered rightful choice.
Emerging as a leader
Trust and respect from peers is garnered step by step everyday with the word and the deed. Conviction that comes out of past experience, the ability to consistently deliver against odds, the cohesion of the team in committing to the stretch and unreasonable, the ability to engage in conflict resolution focusing on the issue and not the people involved. They are always happy to help, sometimes even with personal sacrifice. This separates chalk from cheese.
You would say that this is just a sample of everyday behaviors that make a successful leader and CIO; it is also shaken quickly with hearsay and frequent missed steps. Respect is always earned, rarely conferred if at all; it comes out of consistency in delivery, walk the talk, articulation, coaching and mentoring others selflessly. The mojo develops with practice and stays with them as long as they continue to stay grounded through the journey. Nothing new here too? Hold on a bit.
The gap between perception and reality is based on the demand supply management between IT and business. When CIOs manage this well, they remain relevant to themselves, the business and the enterprise. The progression is determined by the interventions outside of their realm and “out of comfort zone” discussions. The CXO has no boundary defining Job Description; they only have a primary allegiance to a function.
Path to becoming the CEO
So when a successful CIO asked me the path to becoming a CEO, I wondered what qualified me to give advice? While I am a CIO and have held a few P&L responsibilities in my career, I am not a CEO. Having mentored a few people and learned a few tips from the world’s best coach (Marshall Goldsmith), I decided to probe further. He was determined to get there and was willing to work hard. We discussed his winning formula, did a SWOT, and identified a few behaviors that needed attention.
Defining the road ahead was easier than I thought; crafting the evolution plan took some time and then we agreed upon a follow up plan and progress report. I felt humbled by the experience, his faith in my words, and suggestions on his actions which he ardently believed will get him to his goal. Reflecting on what my virtual guru referred to, “I don’t coach losers because they are not willing to change”, I too believed in his plan and hope as he was willing to change. I believe sooner or later he will get there.
And then last week someone asked me the question, “When will we see you as a CEO?”, I started wondering if I should be reading more into these questions and discussions! Flattery is good, but it should not be taken to heart lest the fall hurt the inflated ego!
Every enterprise has an IT function though the name it goes by may be different. Not many call it EDP or MIS anymore, IT is the most prevalent, BT is catching up and there are a few variants which I wrote about sometime back. Similarly the title of the leader has manifested itself in many ways, CTO, CIO, Head, GM, VP, SVP, EVP – IT and some not so common ones that are either legacy, futuristic, or far removed from convention.
Every person in the enterprise has a view on IT and the persona it represents; this is determined by personal experience and hearsay. Sometimes it is relative to past experience in other companies, in most cases it is based on (un)fulfilled expectations and the buzz in the company. The industry, its associates and partners add to or confuse the perception with their views. CIO and the team collectively are thus labelled based on these facts, experiences and views.
CIOs and IT organizations like all beings driven by Maslow’s hierarchy yearn for acknowledgement and recognition. They work hard to create their aura and earn respect with solutions and dialogues that demonstrate understanding beyond technology. They walk the talk, meet customers, and engage with stakeholders to stay ahead in the race. In many cases they succeed in creating a lasting brand value, in few they remain challenged despite doing everything right. Why?
The basic foundation of IT branding happens every day with desk side support on the laptop, desktop, printer, application, network access, email, and various other things that we take for granted. No one cares until something breaks and that incidence ends up being the tag by which IT gets labelled. One incident gets extrapolated to generic statements of (in)efficiency. Some IT organizations have active communication processes to manage this; most don’t leaving a wide gap on how they are seen.
How many CIOs invest in building the brand they and their team represents? Business IT Alignment (BITA) is not only about projects being executed or the discussion the CIO has with the Management teams. BITA happens every day with every interaction anyone within IT has with any other non-IT person (normally referred to as user) within the enterprise. This cannot be left to passive management; it has to be actively managed across the levels.
External branding is another aspect of visibility and credibility that requires a strategy and plan. Go to any conference, event or panel/ roundtable discussion, you will find the same old faces on the stage. It would appear that CIOs were born with stage fright; most are happy to be part of the audience, their views rarely get aired (everyone has a view). Nowadays social media and internet presence too contribute towards the identity of the CIO who represents the IT success of the enterprise.
The combined persona is finally the way s/he is portrayed to the world at large. If the CIO does not actively manage this, it will be managed by forces that s/he does not control. The CIO could then just be an entry in a database or one of the featured ones in a search. If people read about you and read what you stand for, your views on varied or specific subjects, it adds to the perception of who the person is. Some manage this well, the rest leave it to divine intervention.
I believe that CIOs should invest in building the brand not just internally, which is easily done by constant communication and discussion beyond transactions. They should also actively manage their visibility and branding across the IT industry and their chosen industry; participation in industry specific events, membership to bodies, talking to tech journalists and participation in social media make a great combination to get started. Is there more? It all depends on where you want to go!
“I don’t have time” is the first lament (please read ‘Being Busy‘), “how do I get started” is the second; ask the ones who have made it or wait until I write about it.
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?