IT, BT, whatever, does it matter ?

Almost a decade back I remember a company that after spending a large amount of money with consultants going through the whole nine yards and then some more recommended rechristening the IT department Business Technology. It was a move driven out of the aspiration to stay ahead of the crowd and differentiate. The BT group was different from Corporate IT and a few other IT groups within the enterprise; they were the elite. This was in the era when IT was just beginning to gain acceptance.

This large and diversified company was written about; the bold move spawned research papers and everyone acknowledged that the future belonged to Business Technology. Slowly over a period of time the internal customers of this group started asking the question, old wine in a new bottle still tastes the same; where is the change in attitude, delivery, partnership, innovation, all the good stuff that was promised and expected. Whatever happened to the Vision and Mission ? Interestingly the leader retained the title of CIO and not CBTO. Maybe she did not want to tell a story.

Then I met another IT leader of a successful company who gave me a twist in the story. He had named his function STT. With me lost trying to decipher the TLA, he proudly unveiled the mystery with the logic: we create solutions; they are a lot more than hardware, software and networks. However whatever we do has a common underlying Technology framework. Solutions are holistic and do not constrain the thinking process. So our team is aptly known as Solutions & Technology Team. Ahem ! Many years later the poor chap is lost in wilderness; he stressed more on the middle T than the first S.

In recent times there have been many discussions and debates on the changing role of the IT leader; some of them concluded with recommendations that the title CIO is no longer relevant and the role as it stands today will no longer exist in the next XX years (fill in whatever number you like). So, the name should be changed to reflect the new reality. Suggestions cover the entire alphabet soup with rationale based on not the CIO but the proposer’s frame of reference.

Does it matter what the function is called ? Do semantics make a difference ? Will the reality be different for the involved stakeholders depending on the nomenclature ? How much does the name contribute to reality and success ? Can an IT department transform itself with a new name ? Is a change required with every changing technology trend and business evolution (would you like to be called Chief Cloud Officer) ? I am not proposing going back to the historical EDP, but IT today represents to a large extent the sum of the parts that make us.

Success is a result of great attitude and not the other way around; I believe that individuals and leaders portray themselves based on past track record and the engagement that they are able to create. The IT team collectively mimics the behaviour of the leader. This paradigm is true for all functions and no different for IT. CIOs should stop getting distracted by these irrational and irrelevant thoughts and focus on what matters to them, their teams, their customers (internal), and their customer’s customers (external).  

After all the best measure of success is success itself.

Legally Illegal

Last year was a very difficult year for most software companies with slowdown in new licence sales that brought in a negative trend in new business revenue. This happened very quickly after the globally experienced slowdown a few years back compounding the issue. This had all software vendors almost like acting in unison deciding to engage their existing customers in licence audits. If you cannot get new revenues, let’s squeeze some juice out of existing lemons.

So these engagements began to look all over the place; the data centres, servers hidden under tables, desktops converted to servers for a simple test or proof of concept, users created though inactive, resigned employees not deactivated, it did not matter what the event was, if there was an user identity or a database, or an instance of the application, it needed to be licenced. Office automation and other fringe app vendors joined the fray and added to the already harried CIOs blood pressure.

No debate that licence compliance is non-negotiable; licences for software or product or package used for the enterprise that in any way impacts a business process. Most vendors allow disaster recovery to be setup at nominal or no extra investment as long as it is not used conjointly with the production environment. That looks like a good principle though some complicate matters based on number of days used even when the primary was down and not operational.

Some also allow test and development instances to be setup; interestingly most do have a licencing policy that charges the customer, however most sales teams shy away from highlighting this fact during the pre-sales discussions or even when the purchase order is received. Instead they give the CIO a fine printed legal document to sign without pointing out to the salient points that the customer needs to be aware of. I don’t know of CIOs who read those wonderful documents; it’s like pressing “I accept” when we enrol to a new website or app.

So far still so good as each instance expects the customer to get into an engagement with eyes and ears open; the principle being we gave you the full documents, you read and sign or you don’t read and sign, that is a choice. The discussion gets interesting when new or additional licences are required even if a line of code is changed or added to any screen, form or report or an add-on deployed. This now attracts additional investment, sometimes a lot more than bargained for. Now that is hitting below the belt !

If I may add, the same vendors participate during the pre-sales gap analysis and bid and quote for customizations through their consulting arms vying for implementation business. But no mention that if the customer did end up customizing, then … This aspect of licencing is rarely discussed if at all and mostly comes up during licence audits leaving the CIO gasping for life. The management demands that the CIO know all this as it is his/her job to know and manage the vendor.

Page number XX, clause YY, sub-clause ZZ in the sales agreement is cited as the reference for the new demand. Read it and if you can figure it out differently let us know; else here is the bill of material and the timeline in which you need to buy. Consequences you know are not something you want to talk about. Sheepish acceptance and wows to be more careful and read all the fine print is normal behaviour; the management takes a not-so-kind view but goes ahead with the devils choice.

Why does this charade repeat itself globally with many vendors, some more than others ? It does not matter which industry, which country or geography, size of the customer (in fact the bigger the better as they are averse to the publicity it draws), this is becoming one of the relationship breakers between the impacted CIO and the vendor. Stories of these are rarely published by publicity shy individuals and enterprises. Is there a way out ?

I believe there isn’t an easy way out; negotiating from a compromised position does not get any great deals; neither does it do wonders to CIOs careers. Whether they like it or not, CIOs have to get more diligent in their approach to legalese and contracting. As the markets saturate and mature, read changes to changing end user contracts and/or licensing terms. You never know what impact it has on your company.