By design, omission or inadvertently, all of us have faced the situation where the vendor has declared the product “end-of-life”. This puts at risk legacy applications, instrumentation, automation, or in many cases plain old processes that have survived all attempts to change them. CIOs and IT realize that upgrades are expensive and in some case not as good as the earlier working versions in terms of stability and/or functionality. But then they have to do it lest there be no support when the software fails.
Many CIOs succumb to the pressure quickly, only to realize that the deadlines have shifted and they could have avoided the nasty dialogue with respective functions (normally finance). They could have saved the unbudgeted expense in the upgrade which wiped out buffers that were provided for some innovation. Sometimes this leaves a feeling that this was a ploy to move everyone along reducing the support costs for the vendor, maybe some incremental licences (new versions typically may have different breakup).
A CIO friend bought a software package that fit business requirements so well that it appeared to have been developed using the requirement specifications of the company. She loved it as it implied very little customization and a deployment timeline better than what the business wanted. Everything went like a dream, the solution went live with celebrations and everyone was happy. The vendor was acquired by one of the big IT product and services companies; the new CEO promised to keep old customers happy.
As it was time to scale up, the CIO approached the new entity for new licences. The offer for upgrade had her fall off her chair; it was twice of what she paid earlier. Reaching out to the old team she found no help forthcoming with them citing new policies of the acquirer. The big guy sales team explained the new investments into the solution justifying the increase. Left with no choice in the face of the earlier business success, the CIO felt cornered and frustrated though had to accept the new terms.
In another scenario recounted to me some time back, a packaged vendor gave a demonstration of a specialized solution to the business team who loved what they saw. They approached the CEO and the CIO with a claim of higher productivity and ROI. The CEO endorsed the purchase and the IT team got down to creating the project charter, implementation plan and timeline. Quickly they realized that the solution required significant customization to work in their environment.
The CIO got together with the Business Head to provide the reality which was quite different from the short trailer and demo. Since they shared trust, it was evident that the solution provider had only revealed the surface; they had pressed the right buttons and given the messages that created empathy. The resultant in high expectations created a feeling of being short changed; while there was no false information, limited revelations created desire and expectations that were unrealistic.
I could go on and on with many examples on how every day we face situations which leave us with a negative gut feeling and a sense of having been taken for a ride. Some of these are a result of our own naivety, inexperience, or overenthusiasm; also in many cases due to intentional concealment of facts and/or our interpretation of what is said. There are rare cases when mal intent has been the driver too; it is largely taking advantage of the gullibility of the buyer. And every time I hear of an incident, I feel restless.
I do not believe for a moment that this situation is unique to the CIO; at times all CXOs face situations that leave a feeling that we are being taken for a ride, sometimes during the journey, sometimes after we have been gypped. Is there a solution to this? I do not have a silver bullet to resolve such situations; I believe that tactically the CIO has to work on each case to address the issue at hand. Due diligence and contracts go some distance, the rest falls into risk zone and have no easy answer.
When the phenomenon called Cloud made appearance on the IT landscape, it promised to disrupt many existing paradigms. You don’t need to buy any server hardware and storage, capacity is available on demand and you pay for what you use. Applications with licensing models that can adapt to business cycles, Everything-As-A-Service (SaaS, PaaS, IaaS and many more), no capital investments, only operating expense. It was touted to be the silver bullet to solve all the budgeting challenges of the CIO including getting rid of the CIO.
Evolution brought competition and a hysterical wave that caught every Vendor, System Integrator, Research Analyst, and the CIO alike. New terms were coined to depict the key attributes that the cloud promised: agility, flexibility, resilience, scalability, and on-demand. Alliances of hardware, software and networking vendors vied for attention; everything was cloud-enabled or ready. When corporate data centers could not be classified, the term “Private Cloud” came to rescue.
It brought some comfort to the CIO that s/he was not seen as “not doing the in thing”; almost everyone now had a cloud, private or public. From there rose the challenge of making them work together. After all if some apps are on the public cloud while the transactional systems or other apps are still in the corporate data center, they need to inter-operate. Tools and technology solutions attempted to bridge the chasm; everyone had a variant that did something better than the other confusing the heck out of IT teams.
Someone christened the new reality of the coexistence as “Hybrid Cloud” and the term has stuck on. For simpler solutions, applications and processes like collaboration, sales force automation and the likes of Human Capital Management, the challenge was easily overcome by most. Pervasive challenges of security, data residue, service levels, interoperability between different clouds, or difficulty in migrating from one service provider to another, cut across every offering.
Evolution of the services and technology has not been uniform; a few still struggle to offer a consistent experience straddling between the data center and the public cloud. A CIO narrated a harrowing story of his journey towards making a hybrid cloud work to offer a consistent and uniform experience to his users. The vendor in question either due to ignorance or over-enthusiasm promised everything to be possible and the delivery team struggled to get even the basics working.
Step by step through the early stages of making things work, they did not just lose time, the arduous journey had the IT team struggling to explain to the CIO why the project was running totally off target. Most were not technology challenges but oversell to the CIO on what would work and how it would. Straddling the physical and cloud world to offer a seamless and uniform experience to users did pose a few challenges. I guess all clouds are not created equal as competing solutions did offer to expectation.
The CIO called for a review and experts from all over the world joined in to rescue the situation. It was a one-sided affair with no real solution emerging to the problem at hand. The CIO concluded with the pilot being disbanded. The resultant credibility loss alienated the vendor in no small measure undoing a lot of the good work that they had delivered in the past. It was almost like the nursery rhyme in real world “All the king’s horses and all the king’s men could not put the vendor back on track again.”
I guess when it comes to hybrid, cars work and have achieved a maturity level that brings consumer confidence; with clouds I guess there are still challenges to overcome and technology to reach stability and interoperability. Until then stay cautious and don’t bet on everything to work the way it did in a pure cloud or in-house model. The user experience with hybrids can be a dampener on the enthusiasm that vendors and system integrators want you to feel while they experiment at your cost.
P.S. it would appear that the next wave promises Autonomic Computing, anyone game?
Technology evolution has created many opportunities and challenges for IT departments. The pace of change in recent times has been going up exponentially with obsolescence setting in faster than the adoption curve maturity. Each new flavor, trend and hype creates a flurry of activity which forces the CIO to react. Despite claims of various consultants, there is shallowness of expertise to get some real stuff done. Today it may be difficult to find COBOL programmers; it is equally difficult to find UX or Big Data experts.
Every company and function wants to retain talent and leverage the years of experience and expertise rather than losing them. This is more so if the person is really good at what s/he does; which is why we have retention plans, fast-tracked development, high potential identification and many other financial and non-financial incentives. We also face the challenge of managing a few members who have failed to change with the times and are unable or unwilling to adapt to the new world.
The technology treadmill keeps some of us running to explore and evaluate how and what could be potential uses that will create a differentiation. We embrace the technologies when something works and soon you find the trend becoming main-stream with everyone following. Consultants, vendors and tech media keep the hype high with new buzzwords and technology lead disruptions. The already scarce resources end up stretching to explore the opportunities over and above their operational activities if any.
Operations are necessary and critical to ensure that business as usual continues while the new stuff keeps the excitement going. Most enterprises have teams that either built the systems a few decades back or were part of the teams that conceptualized the implementation. If you are lucky they have been able to reskill and stay current while managing the legacy. It is also possible that some have not been adept. Many organizations outsource the legacy sustenance and thereby the BAU operations.
The challenge that many face is to find productive use for the team members that failed to stay current with technology or business. These old-timers built the legacy that did well for the business contextual to the need at that time. With evolution their inability to adapt makes them deadweight in the current hyper-competitive business environment. The quandary for the CIO is to find useful work for them or find a humane way for their easing into other functions or out of the company.
One of my CEOs in the past had remarked of this phenomenon “We offer employment to qualified people on merit, we do not guarantee employment”. With profitability pressures and economic uncertainties this is true even for the better ones with work not just shifting to lower cost but also adding on to existing staff. Do more with less is here to stay and the bar keeps rising every year. Discussing this with a CIO, when she asked me “What is your ERP strategy?” I was stumped.
ERP is presumably the new term for Early Retirement Plan, effectively created and deployed with HR. Her company had moved off the legacy technologies that had survived more than two decades and through the planning process she had attempted to reskill the old workforce offering those positions that would have created a graceful exit over a period of time. Most took the opportunity clutching straws and made the grade. A few who did not had to be offered the new ERP!
In some companies old tech still stays, so do people; the pressures of current technology enabled disruptions will require them to sooner or later transition to newer and contemporary solutions. Recent times have seen many transitions from custom legacies to COTS systems to compete in the new normal. The eventual will arrive; CIOs need to hasten their people strategies to ensure that they are not left with a situation where they are pushed to a wall to take a decision.
All ERPs require planning, so why wait?
Last week when I wrote about selling projects, there was a flurry of responses on what is wrong with the overall approach proposed; according to many, I painted a picture of a CIO who is subservient to business and not proactive in his/her approach to creating change and transformation using IT. Some were of the view that if the CIO does not sell, it will lead to CXOs creating a shadow IT organization which will be available at beck and call to do their demand thereby side lining the CIO.
I met with a senior IT leader who postulated that the “order taking” CIO will not find success as s/he is waiting for the business to define what they want. Most of the time business does not know what they want and in such a situation there will be little progress and lot of dialogue and frustration. According to him the business friendly CIO will explore opportunities and propose the solution to what business may desire and then deliver a solution. He summed up with “know your customer and the industry and get deep into the business.”
I do not disagree with him on knowing the business or proposing a solution; I disagree with the statement that business does not know what they want. Often they presume that lack of technology knowledge creates a gap in how they need to define the business problem. They do need help in articulating the problem statement such that it clearly states the market, the process and the outcomes. It is imperative that the ownership stays with the business stakeholders lest it become an IT project.
A friend and CEO of a mid-sized company joined the discussion on what should be the terms of reference and engagement between IT and business. He is known to be “IT friendly” and good customer who uses IT effectively. He acknowledged his inability to provide a well-defined problem statement that can be translated into a system. So I probed further to give an example of what he implied. He warmed up and started talking about his current situation and his information needs.
The company was entering a new market and with commencement of commercial operations needed systems to enable the business. Local regulations being tough and demanding, the competition fierce, the CEO needed end to end visibility across the supply chain and customers while addressing the needs of the regulators. He defined the need, the growth, and the ecosystem going on to say that he had no clue what IT systems will solve the problem while throwing some available options from experience.
To me the problem definition was quite clear and so was his information needs. The point is that the questions you ask will determine what you get. We did not discuss any technology options; neither did we get into details of hosted, cloud, or solution options. Clarifying some of the finer nuances it was clear that he was at ease on my overall understanding of the need. I then turned to the CIO and signaled that despite the starting point where the CEO stated he did not know what he wanted, he actually did.
When you meet business leaders, what is the approach? Do you probe based on your knowledge of the situation or do you expect the business to come up with a formal requirement document? Is it a discussion or is it a template given to the business to fill and define what they want? What kind of engagement model do you practice? For any discussion to be fruitful, involved stakeholders have to have a common ground and assumptions to make sense. I don’t know what I don’t know, let’s collaborate.
The answers you get is a function of the questions you ask; if you start with “What reports you want”, that’s what you will get without the background context. If you ask only about the process, you will hear that; take a detached and a connected view simultaneously to get the information required. You will be surprised at the insights you can garner. I believe that CIOs and the IT teams need to be trained on how to ask the right questions; and that is also a function of how well you know the business.
It’s been 2 years in the role and I have been reasonably successful in changing the IT landscape modernizing the applications and infrastructure; many new applications have done well and have been acknowledged by the Management. The IT team some of which had spent decades in the company too has undergone change with skill upgrades and their alignment to the new way of working. However I have been finding it difficult to make big moves which I know will create business transformation.
I met an old teammate after a long time who had blossomed into a first time CIO. He had done well for himself and the company by taking them from what he described IT 1.0 to IT 2.0. He took the journey step by step reviewing the existing architecture and creating a roadmap that he systemically executed with ease. I remember him having an eye for detail and scrupulous in his approach. Proudly he explained his and his team’s handiwork which was achieved despite the lack of overtly enthusiastic support from the business.
As he narrated his story, I could not help drawing parallels from a decade back when he worked in my team. He and imbibed the principles well and upgraded the team to deliver; he was now struggling to move to the next level where he was unable to find support from his peers or his Management who did not share his enthusiasm for the new initiatives. The company with a strong legacy and loyal customers had grown with the founder driving the business skilfully not just locally but globally as well.
My CIO friend had many ideas based on his understanding of the business; networking with peer CIOs and taking help from vendors, he had come up with a few projects which he had been attempting to sell to the leadership team. They did not share his excitement on the change and resultant outcomes; everything is working well, business growth is better than it was in the past. Why upset the applecart? He found it incredulous that despite a clear ROI no one was willing to take up the cause.
I dug deeper to figure out the key business drivers (inorganic growth), the makeup of the people (loyalists), the culture (conservative), the connect and receptiveness (cautious), and finally the sense of shared urgency (none). The business perceived the new initiatives as unnecessary and a distraction; they saw no need to change; why fix something that isn’t broken? It was evident that he was unable to make it their priority or convince them of the merits. So I pushed back and asked him to stop selling.
The current approach appears to be desperation from your side with an automatic pushback response. It is your project, your idea and not theirs; they don’t see any value in your projects, so stop selling and start asking questions. Take a different approach and start engaging them in a conversation on new possibilities that open up to them and make their lives simpler or make them winners. You have to stimulate and connect with different stakeholders across the chain to kindle interest.
In the current scenario even if the project were to get started, the possibility of successful deployment and effective use is relatively low; because it is an IT project and not a business project. I have observed many projects floundering when key process or business owners were not aligned to project deliverables. A challenged HR project where the CFO and CIO pushed the decision on better ROI; an eCommerce portal with reluctant or indifferent business stakeholders, a CRM disconnected from field operations!
Why do CIOs sell projects? There’s the hypothesis about being proactive and partner to the business, something to do with alignment. I believe that situation belongs to the past as it ends up in a situation where the wooing is all left to IT, business playing the role of a reluctant partner. Unless there is connect on both sides and endorsement from senior management, the CIO begins to appear desperate while others wonder why. So stop selling and start collaborating; proceed only if you find reciprocal acknowledgement of need.
He was passion personified and loved what he did; on most days he would be the first to arrive and the last to leave. For him there were seven days in a week which just rolled along, rarely he took even the weekends off. Meal times whether breakfast, lunch or supper happened on the move whenever a few minutes presented themselves in between fixing issues or changing code. He was in perpetual motion and yet tireless like an ideal state machine.
Users loved him as he always smiled and never said no to any request or demand. Technically he was good and working 16 hour days he almost always delivered to promise. Not that the rest of the team complained, in fact they passed on some of their work to him which he took on with no qualms. The CIOs attempts to slow him down did not change his working style until one fine day nature took its toll and he was down with illness and out of commission for a month.
A decade and more later, in another company a similar story played itself again. I don’t remember if it was the first job for the person, she had already spent a decade in the company and had been part of the IT evolution from the first set of large investments. Having spent so much time, she knew every aspect of the business and the system; when the principal vendor had a problem which they needed to validate, they would call her and she always had an answer. If there was one, she was the subject matter expert.
The company was growing in leaps and bounds which lead to increase in workloads. Unable to retain a team of professionals due to her nature of micro-managing every aspect of the work, the pipeline started getting clogged leading to delays in the regular stuff; the urgent always got priority and was addressed. The bottlenecking required drastic steps and the CIO moved her laterally to the business and distributed the work to the team. Very quickly there was no pending work and everyone was happy.
Every company has this scenario playing out in some way or the other. There is always a set of resources that are deemed critical to the functioning of the company that they end up getting overloaded. Some get into such situations by default because they are good at what they do and some create such situations because they love being the center of attention and attraction. In either case their false sense of importance leads to the person and the company suffering as observed in the above anecdotes.
A long time back one of my Managers told me “In every company there is one individual who is indispensable, s/he should be fired”. Curious and naïve I asked “Why?”; to begin with apply the Red Bus theory, if a bus runs over the individual, what happens to the company ? And how to prevent and minimize any minor or major disruption? The second reason is to address the growth aspirations of the person. If s/he is critical to a position, task, process or function, then s/he cannot get elevated as s/he is critical.
So whenever such a situation presented itself, I have used a step by step approach to de-risking the individual as well as the enterprise.
- Discuss the situation with the individual to create awareness; ensure that s/he understands the implications to self and the company
- Explore growth aspirations and personal goals and how they may be restricted by the current reality. If this has been the situation for long, cite peer examples of growth
- Work with him/her to find a workable solution which could be lateral or upward move, changing role or addition of resources
- If none work, outplace the person
You also have the option to let the situation be and do nothing; not that anything has happened in the last so many years, so why should it happen now? That is a choice to make. Have you faced such a predicament either yourself personally or within your team? What did you do? I would love to learn from your experience.
Take any event, survey or discussion with a vendor, or pick any IT magazine or newsletter, all of them have something on mobility and integrally linked to that is BYOD. Mobility has prominently featured in the top priorities in every survey. It has become as discussed or more a subject as BITA (Business IT Alignment) was a decade back. There are views and opinions on everything going mobile from business process to commerce from company to consumer and everything in between.
With number of innovative as well as hair brained ideas vying for attention, there is little to choose from for a CIO. Every one of these comes with a theory and hypothesis to change the world or transform the way business is done and information consumed. These range from recognizing your customers to agile delivery of information to senior management or pushing alerts to the sales or distribution teams. The need for instant approvals to various requests is no more a proposition cutting ice.
When I met a consultant from one of the big and respected IT and Management companies, the dialogue soon veered towards what is happening in this space. Everyone is talking about mobility and related challenges of managing the device, security of information and the big issue of non-company owned devices that connect to the corporate network. He went on to postulate that the future holds a lot of pain for the CIO who has to manage the diversity with new devices mushrooming every day.
So I challenged him to illustrate what he has seen of the deployments across companies that he has surveyed or CIOs met. What kind of applications are becoming mainstream? Beyond sales force automation, reporting and maybe order entry by field staff, are there other use cases that have gained acceptance? He mentioned insurance agents and banking relationship managers using mobility to sell their services; but these are corporate deployed and largely laptops with limited customer information if at all.
Then, where is the need for mobility? Are CXOs demanding information on sales or other KPIs real time or by the hour? Are knowledge workers expecting to carry their work from the desktop/laptop to their tablet or phone? Is the shop floor crying for a mobile device or a transactional worker like Finance or HR executive expecting work enabled on a mobile device? What information and process needs the velocity that mobility enables? And if none need it, then why is mobility a big deal?
Most mobile devices, managed or unmanaged, are connected to the corporate network for email access and to some extent on collaboration (read messenger or chat). Most organizations stopped supplying phones a while back and very few have procured tablets beyond the sales or field staff. The information the phones carry is corporate email and almost all users have password protected their individual or corporate device. Loss of phone gets the finder mostly an inoperable device which could get unlocked only by luck, rarely by brute force.
Information contained on tablets could have some value to the finder if again access can be gained bypassing the security. MDM or Mobile Device Management solutions are an insurance cover over and above protection that we all enable on our personal devices. A disabled email id or active directory will anyway prevent email and other information sync immediately. Security vendors whipping up paranoia would like you to believe otherwise by painting a grimy picture of revenue and reputation loss.
I am not propagating that enterprises stop looking at mobility or mobile security; what I believe is that review each case on the business value that can be quantified. Do not base your decisions purely on the spread sheets that vendors want you to use for TCO/ROI. Stop following the mobile information security hype and deploy pragmatic solutions; you are not following your competitors to pick up their lost device, likewise your competitors are not following your people around. Take care!
Not too long ago there was a CIO who was involved in a cultural clash upwards and sideways in a matrix organization. He supported multiple diverse business units across multiple geographies; the business units had CIOs reporting into the respective CEOs, they had limited accountability to the CIO. The CIO reported to the Group CFO locally and the regional CIO functionally; the corporate IT function under the leadership of the CIO supported all the business units across the geographies.
The CIO had taken over a team of submissive staff who never challenged the business CIO demands for fear of conflict. While the overall matrix was a bit complex with differing size and profitability of business entities, the equilibrium was largely maintained with some give and take between the business units and corporate functions. Chargeback was based on revenue as well as headcount; there was occasional rumbling and murmuring which was subdued before it could raise an ugly head.
So when the CIO met the business units CXOs he was surprised at their aggression and attitudes; it was justified that the business team will generate the demand and the corporate will take care of the supply. Corporate IT was expected to take orders based on what the business had decided as the direction and strategy to deliver the systems and technology. It would have worked well except that the timelines were rarely reasonable even when Corporate IT tried very hard.
Corporate IT was also responsible for BAU systems, the data centre, applications and networking. The divide reached morbid peaks during budget discussions; your cost is too high, business cannot afford to pay increases every year; find efficiency was the mandate. Scraping the bottom did not reveal much and that was unacceptable to the business. If business is not growing, how can the expense grow? Fair point as any was, with business seeing a downturn, it is imperative to cut cost.
The difference was that the business IT budgets grew while the cut was imposed on CIT budgets. This led to frustration and thus the CIO sought arbitration from his boss the Group CFO. That is when things started going out of hand; Business CIOs along with their CEOs represented that we are a Profit Centre while you are a Cost Centre; we pay for your existence and thus have the right to determine how you work while you cannot challenge how we allocate resources. Ouch!
Determined not to lose his temper the CIO silently looked at the CFO who gravely looked at his phone avoiding eye contact. With no help available, the CIO took the challenge head-on and suggested open book costing to get constructive feedback on what can be optimized. This was rejected upfront that it was not for business to run operational systems. Smiling the CIO offered a handover of all BAU systems to respective business units to run and transfer resources too.
Taken aback the group looked at each other; the CFO rose from his slumber to pacify and resolve; he suggested that the groups step down from their positions and create a working model that does not create conflict. The open book model was agreed to with benchmarks with the external world. This was deemed an acceptable compromise. His words on being a team and the need to work in harmony appeared hollow to everyone, which he too realized.
This is not a normal scenario in every matrix organization but some parts play out in every company. It is difficult to align direction when measurement criteria are disjointed. The open acknowledgement of team work towards success ensures that producers and consumers do not see each other that way; rather they work to create an ecosystem that motivates progress. Having been part of a few matrix structures, I believe that finally the culture of the company (read CEO/Head) will determine success.
If you have been a part of a matrix and have stories to share, I would love to hear them.
We are conducting a survey among the top CIOs on IT trends, data centre efficiency, Cloud computing adoption, business analytics, mobility, leadership, top 5/10 priorities, technology priorities, top 5/10 IT challenges, business challenges, social media adoption, big data, security, … phew! You name it and it is there; every day I get a couple of invites to participate in surveys with varying time indicated, from 5 minutes to an hour. They are run by all kinds of IT vendors, research companies and publications.
Surveys normally have MCQs (Multiple Choice Questions) or a matrix in which you select different options; some also want descriptive answers. Most of them end up taking twice as long to what they mention and what they would like you to believe. For example if a survey indicates that it will take no more than 10 minutes of your time, in all probability it will take 30 unless you are a speed reader. If you actually read all the text in the MCQ before you check/click your answers, then it may take longer!
Why do CIOs participate in these surveys? They are busy professionals with paucity of time; I think it is to put across their views and get to know what others think (most surveys promise to send the results to participants, 50% do so too). But nowadays they come with incentives attached; take the survey and you stand a chance to win your favourite gadget/device or a shopping site voucher or …. The incentive increases participation rates, gravely said one such surveyor; from 5% to about 20%.
The first page normally gets genuine thoughtful answers; then you hit a block with questions where answers don’t reflect your context or reality; there is no way to skip the question, you end up selecting a random option. Questions are constructed in a way that support what the surveyor wants the outcome to be. Soon you hit a complex grid or matrix where you are expected to balance options in a way that you select one option per row whether it matters to you or not. The more interesting ones are when you keep track of totals in a column across multiple columns.
That is when most respondents start randomly marking answers or rush through the pages. Any online survey or questionnaire that requires more than 5 minutes or has more than 10 MCQs tends to get into indifference zone. What you get is random responses or a middle path or a horizontal row of answers if the questions use a scale of 1-5 or 1-10. Many are kind and desert the survey mid-way rather than input garbage. Why are most surveys so painfully irritating and difficult to respond to?
You can now understand why most CIOs don’t agree with the results; because the input is rarely a reflection of reality of the participants. The responses appear to be from a different planet, the analysis bewildering, and the implications or actions disconnected from what makes sense. CIOs blame the outcome when they largely respond with indifference to surveys that seek their inputs on what matters to them. The starting point is the survey itself. So how to overcome this situation?
To begin with reduce the complexity of the information required. If you want a split of percentages across routers, switches, wireless, bandwidth, network management, which is a subset of hardware, which is a part of the infrastructure, then you will only get what you deserve. CIOs do not measure these, neither do IT Managers. Ask questions that can be answered without a calculator or the IT budget spread sheet which has numbers, not percentages. If I don’t do social media, then I need an option “Not Applicable” or let me simply skip the question.
Now I rarely participate in surveys and if I do where possible put in textual answers with my views. Surprisingly no one has as yet written or called me back despite having my email id or cell number. Do people really read the answers? Do they care about what is being said if their agenda or hypothesis is met? Maybe the surveys are just to say that we conducted a survey and keep the data aside to publish what you wanted to anyway.
I am beginning to discover new benefits of drinking wine; apart from being a social icebreaker with people discussing the merits of Merlot over Shiraz or the lineage of the grapes and the geography, it also opens up their heart with the cup of woes flowing over with gushing speeds. I was party to one such conversation with a well-known CIO who had scraped through challenging times and was drowning his sorrows in the red. And thus the saga unfolded.
He had joined a diversified conglomerate as the Group CIO; most of the companies within the group had mid-level IT heads who now reported to him. He was expected to bring synergies and efficiency across the companies while taking the IT agenda forward to the next level. The group itself had aspirations to grow manifold over the next 3-5 years and believed that IT can contribute to expediting the journey. Everything looked well set for the CIO to capitalize on and forge ahead.
The group had humble beginnings and had tasted success with some of the new ventures that brought it to prominence. Expanding global presence, the founders had begun to hire professionals to run individual businesses as well as leaders like the CIO to drive the corporate agenda. Collectively the team was tasked with bringing to life the strategy and goal. The recipe thus appeared to be what would achieve the stated objectives.
The seasoned CIO got started by meeting the business and functional leaders, understanding their key drivers and opportunities, and within a span of 30 days charted the IT agenda and roadmap. It had all the components of internal efficiency that could be gained with technology standardization as well as connected some of the initiatives with the external end customers. Commendable progress noted the family who owned the business.
The next 30 days had some of the initiatives getting off the ground with participation from business and IT stakeholders. The larger investments needed discussion and debate on the selection of solutions as well as partners who would deliver them. Everyone had a view on how they wanted to make the selection and everyone had an opinion on what should be prioritized. The CIO attempted to moderate expectations without success. And that is when things started going haywire.
Over the next 30 days the power struggle continued with no one wanting to give away, each holding their ground; the CIO in his righteousness and professional pride believed that he knew how to run with the critical projects. The business leaders believed that they knew the business best and the CIO should yield to them considering they have to finally deliver the business outcomes. The owners left it to the group to take a decision not wanting to be the arbitrator.
As the status quo continued for some time, patience wore thin and the level of exasperation grew; in the next quarterly business review meeting they orchestrated a show down. Most of them updated the respective family members of their discomfort and the decisions they were hoping would prevail. The CIO did not have this connect and neither did it cross his mind that he should work with the majority owners to achieve what he believed was the best outcome.
In a stormy meeting the CIO quoted from success within and outside the industry with his proposed solutions and why his path was the best way forward for everyone. The business leaders refuted the claim and chorused the CIO’s limited knowledge about the culture and business. The Chairman had to react and he did what was obvious; he took the path that the CEOs had advised him of rebutting and chastising the CIO for not listening to his customers.
The CIO had a devils choice; he could accept the verdict and get started or he could refuse to bow to the decision and move on. His stand had created a deadlock; his abrupt manner and straight talk had alienated the business. The superior attitude ensured rejection of the proposals giving him limited options on the way forward. He believed that others did not understand technology neither did they respect his experience.
We know the CIO should have tactfully managed the relationships first selling his ideas to become the choice of solutions and vendors. The politically incorrect situation was self-created and this dawned upon him in our discussion after a few drinks had been downed. I am not sure if the self-revelation was too late to make amends or he had the opportunity to go back and change the direction. He thanked me and left. I am curious on how this unfolds, keep watching this space.