Making buying decisions based only on cost is mostly a bad idea

A new CEO came on board from one of the worthy competitors; he was hired to scale up and scale out in a market that was beginning to adopt the services offered by the company. His earlier stint was with a global mature enterprise in the same industry where he had grown the business as sales head and was now ready to take on the role of a CEO. The young industry required large teams to deliver onsite services to customers; technology did provide a differentiator where early adopters had seen the value.

The CEOs newly adopted company had grown organically beating market growth but lagging behind on profitability, partly due to continuous expansion and rest attributable to operational efficiency which required technology interventions. To the CEO it was quickly evident that inducting new solutions would bring in the requisite process compliance and reduce exceptions which mostly led to costs going out of control; reduced dependence on individual performers would lead to the desired consistency and profitability.

In the initial assessment he realized that corporate overheads were low and did not lend themselves to further reduction; he therefore focused his attention on investments required to bring in requisite technology solutions and thus tasked a small team of veterans to evaluate named solutions which largely comprised the universe of available options. The team rejuvenated with the new ideas from the newbie leader jumped into the evaluation process; industry research also pointed back to the same set of vendors.

The solution providers – local and global – offered varied functionality that allowed for extension of services to be offered to customers; at the core, all offered basic process automation and customer management. The choice thus depended on technology stack, value added features, ease of use, customer and employee self-service, mobile deployment, analytics, and ability to deploy across the cloud as well as on premise. Flexible and conventional licensing models rounded up the full stack of evaluation criteria.

Within the stipulated time, the team reverted with their evaluation and recommendation; they had done a fairly good job of mapping the existing business processes and identifying the best option for their company. They had also taken into consideration the company culture and primary decision drivers – low risk and cost; in the past the management had been hesitant to explore high capital investments instead preferring to work on low cost operating model where the plug can be pulled quickly to reduce losses.

In the next Board meeting the CEO scheduled the proposal while the evaluation team stayed in the back of the room for any clarifications. The meeting started a bit late, and dragged on with the discussion on financial numbers taking up a large part of the day; by the time the item on the agenda representing the technology solution came up, the Board members declared exhaustion and to the dismay of the team present deferred it and other remaining items to the next meeting planned after a gap of 3 months.

In the next meeting the Board did manage to discuss the project and asked the CEO to rework the risk return model as they found the outflow high. A Board member was assigned the responsibility to validate the final proposal and approve. Between the CEO and the Board member they kept at it for a while attempting to get the numbers down while increasing the scope of deliverables. In the interim business continued to grow and new customer acquisitions took away the CEO’s attention from the project.

A short economic instability and the business saw a blip in performance diverting everyone’s attention to bringing revenue numbers back on track. The company continued the growth trajectory and the project was now on the backburner with all attention on further cost cutting to deliver Board mandated margins. The CEO attempted to revive the discussion on the value proposition and market competitiveness the company stood to gain with automation and technology solutions, only to be chastised for proposing spends in a lean period.

Nimbler and technology driven competition overtook the company in market standing; the Board brought in consultants to create a business strategy that would help the company regain lost glory. Months later the Chief Consultant presented the business strategy for the next 3-5 years to full attendance from Management and the Board. The plan looked familiar and so did the steps they outlined for business efficiency and profitability; by the time the meeting ended, everyone looked at the CEO as an awkward silence prevailed.

The plan and strategy was what the CEO had outlined with his favorite project that had quietly died in the hemming and hawing over the last few years !

Chief Inaction Officer: I will do nothing until I am explicitly asked to

An audit finding raised the compliance flag which necessitated the CIO to take action; he acknowledged the limitation and was thus tasked to find a solution to be deployed before the next audit. The technical team was summoned and the task assigned between 2 of his deputies who controlled the applications and the infrastructure respectively. With healthy contempt for each other, they thrived in challenging each other, at times with detrimental effect to deliverables. Their professional strengths secured them in their positions.

The problem was not unsolved in the industry and there were standard offerings that collectively created the solution required. To the CIO thus the issue at hand appeared to be an easily resolvable one, the criticality defined by the compliance requirements within the stipulated time. The team went through the motions and presented the solution and budget to the CIO who was struck by a red herring; was it a decoy or reality ? It appeared to be a new player in the market, the solution quite elegant and better than the sum of parts that made other solutions.

So he probed further inviting the vendor to present their value proposition; his team willingly obliged sensing an opportunity to differentiate from the normal. Multiple meetings and presentations later the CIO requested a Proof of Concept which was diligently completed by the team and results submitted. In a normal scenario, vendors would push for closure post a successful PoC; the vendor did the same and was then updated on the decision making cycle; the CIO then proceeded to present the solution to the Board for approval.

Boards typically want a solution to a business problem or an opportunity; they are largely agnostic to the technology solution. True to form the board left the technology decision on the CIO’s best judgement citing that they were interested in compliance using the best possible technology at the lowest possible cost. Unwilling to take a risk with no clear technology mandate, the CIO did what he was good at; no decision while keeping the vendor at bay with meaningful and irrational questions and finally an unreasonable price.

The CIO sought to validate the solution with the Technology Advisory Committee who deferred the decision back to the CIO; referring to the Regulator, he asked for a guideline on the solution which was not forthcoming. The Regulator declined to specify the technology while impressing upon the Company to expedite the solution deployment within the timeline. The passing time had the CIO under pressure while his team stood divided on between the conventional and the innovative solutions giving no solace to the cornered CIO.

The vendor attempted to provide necessary documentation that was duly submitted to the Committee and the Regulator, both maintaining status quo. The vendor demonstration immense patience stayed engaged with the team through the imbroglio and parallel commercial negotiations as the deal appeared close but open through the elapsed time of over 6 months. The impatient CEO was counseled to provide a direction which he finally did in the interest of progress sensing that the CIO will continue to dither on the decision.

Technology teams under the CIO are expected to be the evaluators, evangelists, proponents and finally the educators of possible technology solutions to the business. Heightened awareness of possibilities from technology with business users does make them influencers and at times critics of technology, the decision finally rests with the technology teams and accountability with the CIO. The unwillingness or inability to take a decision does not reflect positively on the leadership of the CIO and adversely impacts the team’s credibility.

Observations from the industry do indicate a set of CIOs who are extremely risk averse and they rarely take decisions on new technologies satisfied with being followers. They are good operational managers and struggle in their ability to partner with the business to impact business performance indicators. In the changing business environment with technology agility a necessity and essential to stay meaningful with disruptive business models threatening the core and existence, it is imperative for CIOs to embrace the new and leave business as usual to their teams or outsourced partners.

A good decision now is worth a lot more than the best decision after delayed analysis paralysis !

Professionally correct or Politically correct decisions and alignment

The company had decided to undertake an IT led transformation journey; the Board and Management including the CIO had agreed that this would help the company move to the next level of performance. Digital upstarts were threatening their existence, creating a business environment with reducing margins. This might sound like unfamiliar situation to many businesses, reality being that all industries are facing such situations from Angel and VC funded business models that surprisingly do not appear to be financially viable.

The new competitors grew in leaps and bounds leaving them struggling to stay relevant in the digital euphoria the market embraced. The company was forced to look outside its old school of thought which had worked well for decades in a customer engaged relationship model. They did not need incremental change, a revolution was imminently required and everyone knew it though it was rarely spoken of in operational review meetings; after all the current foundation had built the business to the level where they were now.

The foundation was set by the founders when they seeded the business; they were technologically on par and business competed on even keel. With pace of innovation increasing, the company started lagging behind though the brand kept them moving ahead. Despite insufficient expertise, the founders continued to interfere in every technology decision thus widening gap. They did use technology, sketchy at best leaving many open unaddressed and manual processes rendering technology led automation ineffective.

What will boss say ! How can we tell him we need better systems ! The world has gone mobile, we are yet to start ! He will not agree to change the existing platform even though it has outlived its usefulness. Laden with perceptions of embarrassing the promoters or rebuke from the boss, people refrained from raising the matter of obsolescence of existing solutions and resultant efficiency deficit. People accepted increasing inefficiency and worked harder to keep going; it was a losing battle which came to notice soon enough.

Business results in the face could not be ignored. Hurting from ignominy finally the management decided to wake up from self-imposed slumber. IT got the blame squarely for neglecting the business, the CIO replaced and a ray of hope for everyone with new talent wanting to create quick wins. Multiple discussions with vendors facilitated with external help, it was the beginning of renaissance. After the initial progress things started slowing down rapidly. The new CIO was confused and sought an ally to push forth the new agenda.

Every technology discussion required presence of the head honcho; his opinions were cast in stone which no one dare challenge. His legendary obstinacy had no cure, the CIO was advised to toe the party line or face irrelevance or eventual expulsion. He accepted reality and attempted to work towards making progress to the best of his ability. Technology decisions were taken were reviewed and changed frequently leaving the vendors and the CIO helpless; attempts to educate increased the uncertainty of progress.

Some of the technology choices were overturned unilaterally, the CIOs given the task of conveying the decisions to the vendor community. Internally the old hands were immune to this churn of verdicts having lived in uncertainty, accepting it as destiny. For the CIO, the professional in him had difficulty in accepting suboptimal solutions, he seethed with frustration. He faced a difficult dilemma; he knew that irrespective of the decision he took, someone will be hurt. Unfortunately that someone happened to be himself.

He turned to his mentors seeking salvation; some advised him to take the predicament head-on and not accept a compromise; after all how could he accept this dictating of technology to a technologist ? The pragmatic and realistic suggested that he set aside his pride and make the best of what he had and work towards delivery even if the solutions were conciliatory. Rest sympathized with him and promulgated survival over creating a better world; you are of no use dead to anyone, so stay alive and do what you can within the constraints.

The CIO made his choices and survived the ordeal, the organization continues to make snail like progress losing market share, vendors have ceased following up, and the world continues to evolve ! Business world has many case studies of companies unable to change that have now been relegated to history. Charles Darwin quoted “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change”, while Edward Deming quipped “It is not necessary to change, survival is not mandatory”.

Ahem !

The Business & Technology Balance

The fact that IT is about business and that IT executives should be adept in business matters has been written and talked about a gazillion times by everyone who even remotely has anything to do with IT on this planet. It has been a discussion, debate, viewpoint, opinion, experience, coaching, mentoring, part of courseware and curriculum, published by IT media, books dedicated to, researched, pushed down the CIO and IT throats, for as long as I can remember; with my weak memory indexing that would be a decade plus.

Neither CIOs nor IT disagree with this postulation, they are however fed up of repeated ranting of this party line. It is not that IT folks do not practice this every day when they are in midst of their business teams or with others. I have observed that leaving aside a handful, every IT team member has a good view of the business even if it is narrow view of the function s/he supports. As you move up the ladder the articulation gets better and the view broader; some good CIOs could give a discourse about the industry too.

It is fashionable for most vendors to start discussions with the rhetoric what are your top 3 business priorities and then barely listen to the response. Every consultant or research report continues to talk about alignment and enabling the business. The message has remained the same; the words have changed to include the latest fad or trend – cloud, big data, mobility, security, and social media – as if these are critical components of business rather than technology.

I don’t know why but a recent post by a consultant got my goat and I went into my once in a decade murderous moods wanting to challenge this underling to a duel. What did he know about the CIO and his/her role when he has never been one ? He only had advice on what a CIO should be doing to stay relevant, and that included the usual stuff that is the norm now. After a brief attacking response, I tempered down to reach the stage we reach when we see a lot of dogs barking; we ignore them.

Ruminating over the state of affairs I wondered about the fact that one of the core competencies of IT is that they understand technology and are able to apply it to influence business outcomes. If IT did not understand technology, its pros and cons, the application of technology solutions would be like a game of roulette; you win some, you lose some. And if IT abdicated this responsibility, who would validate the efficacy of the solution and that it is being used to its optimal capacity or value or benefit ?

The technology team needs to engage the vendors and solution providers on equal terms getting into deep dives on every technology component as well as the integrated solution to understand how it will deliver to promise as well as coexist with the current technology framework and architecture. Things don’t work by chance when information follows with the material or process to generate goods and revenue. They have to be made to work with each other by design and that requires technology skills.

The diversity of technologies, hardware, software, applications, networking, storage, cloud, dashboards, analytics, reports and reporting tools, mobile devices, data management, security, and what have you, each requires extensive effort to understand how they impact each other and then manage them effectively. I have yet to sight a person who had expertise in all of them; a team can collectively represent a potent unbeatable combination which when married with business will always succeed.

It is a fallacy to expect the IT team to give away their foundation of technology and embrace business skills only. To me it would be like choosing either work or life. Life gives birth to work and work enables a life. Similarly technology innovation opens new opportunities for business and new opportunities give rise to new solutions. I believe that a balance has to be found such that the two sides of the coin give different views to whoever is looking at it without compromising each other.

Technology needs business as much as business needs technology today. 

Right or Wrong ?

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.

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 …

Success and failure rates of IT lead 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 !

What's in a name ?

In recent times, there have been many consultants, research entities and academia discussing the IT organization’s transformation. The proposed concept seeks to rechristen IT to BT to reflect the new nature of the expected role. The rationale is largely around the fact that business drives technology within an enterprise. So the function should be called business technology (BT). Many CIOs like the new nomenclature, and have attempted to adopt this new symbol that represents their purported evolution and alignment.

Flashback to 2002; I interviewed for a Fortune 50 company’s Indian operations. The process progressed well, and I joined the company (which had a federated IT organization). The corporate IT organization was responsible for standards, infrastructure, architecture, and many applications that were supporting the operations. Then we had Manufacturing IT, which focused on the requirements of the manufacturing plants, connecting to suppliers, managing the manufacturing process, and running the warehouses. The company also had an R&D IT function that empowered the large and globally spread research teams with enabling technology solutions that were critical towards maintaining the company’s leadership position. Each IT organization head reported to the respective function head with dotted line to the global IT head; they had the flexibility and independence to create solutions or choose vendors. Last but not the least was the function called Business Technology, into which I was inducted.

Business Technology worked with the sales organization. It existed in almost every country that the company operated in, and reported to the CEO. It was the largest group and also the most powerful, since the sales teams connected with customers, and thus also had the power to garner larger IT budgets. Thus this name signified a closer relationship with business. It provided technology initiatives that impacted life everyday on the field connecting with customers, while competing with others in the industry. Not that those other teams were not aligned to their respective business folks, but the impact of changes was slower, and largely created internal efficiencies or benefit. Thus, every introduction to an outsider required a five minute discourse on why we were called Business Technology.

Was BT any different? We still had our challenges around vendors, change management, new initiatives, budget approvals, technology adoption, political issues, everything that a normal IT organization experiences every day. As the CIO, my role was acknowledged with a seat on the management table, but like every other CXO, it required consistent performance to keep it there. The basic expectation from the CIO was to create business value, challenge status quo, and participate in all discussions around the table that influenced the company’s future direction.

So, what about the role today? The CIO is required to do all of the above, sometimes even fight to get a seat on the management table; in a few cases where the CIO does not report to the CEO, they are dependent on other CXOs to be their voice in the management team meetings. Will the change in name to business technology bring about the transformation and fast track the evolution and acceptance of the function better than when it is plain old IT? I guess not–the enterprise, the IT leader, and the culture largely contribute to its success. BT happened almost a decade back, evolution is catching up.

After all, as the bard said it a long time back, “What’s in a name; that which we call a rose, by any other name would smell as sweet”!