Information Technology Management with a Purpose

Much of what I know about technology has been learnt from technology vendors. While it’s true that I have read about various technologies and also used them, at times the real understanding has come from vendor interactions.

Vendors know best about the technology that they deal with. Vendor representatives possess considerable literature, are trained internally by experts, and carry demo packs with them. They also have substantial amounts of experience when it comes to dealing with various customers, answering their queries, and also by being a part of their implementation — whether it’s a success or failure.

Many years ago, I realized about the fallacy of my approach while dealing with vendors. I would often call in the vendor and tell him what I wanted — say, hardware of a certain configuration, a software package’s latest version, a tool that I might have read about, and then ask him to submit his quotation. The poor sales representatives chasing numbers and targets would rush back with his proposal, hoping to cash in with an order. Little did I realize about the opportunity that I lost when it came to doing a proper evaluation and choosing the right solution!

I later changed my approach, and called in vendors to explain my requirement. After the detailing, I would ask them to suggest the most appropriate solution. Each vendor went head over heels, and used their ingenuity to suggest the best solution. This was revealing, as some of these were options that I could not have thought of myself. I used the suggestion of ‘A’ to confront vendor ‘B’, who came up with his own counter arguments. Vendor ‘C’ had his own story, and was critical of the other approaches. This interaction gave me an in-depth understanding of the subject. It was armed me with enough knowledge to make a decision based on facts.

I will talk specifically of a few incidents to explain my viewpoint. Faced with ever growing storage requirements, I asked our vendor to get me an additional extra storage box to bolster my storage. Those were the early days of enterprise storage. When the vendor suggested that I go in for a storage server instead, I blew my top. However, the vendor explained his stand. His suggestion was that given the projected growth, I would otherwise be continuously adding more boxes — a management nightmare. That made sense, and as I went about studying the details, I learnt a lot about storage technologies and the merits of using them.

Similar was my experience, when it came to introducing server virtualization. While evaluating servers, I would often ask for technical details. I was rewarded with considerable knowledge on IBM Power processors, HP’s Itanium, Sun Sparc processors, and other such platforms. The knowledge picked up on other technologies like UTM, digital asset management and unified communication also went a long way in developing a certain confidence.

I often ponder. I spent a lot of money over the years in getting myself educated and learning new tricks, but here I was picking up knowledge without having to pay any sum. Just turning a buying opportunity into one of learning — oh boy, what a reward.

We live in a dynamic world, and the environment around us undergoes change at a rapid pace. While we are busy putting out fires in our respective organizations, a lot is happening in the world around us. We do try to keep pace by reading various magazines, accessing information from the net, and subscribing to various news services on the web. I am not sure if that is enough.

There is a wealth of knowledge and experience that resides in the IT community consisting of CIOs, consulting professionals and vendor executives. There is a lot that can be learnt and applied for our benefit, and therefore a need to network with the IT community.

I have always been regular in attending events conducted by vendor organizations — introducing a new product or technology — or by professional bodies like the CII, Nasscom, CIO associations, etc. By doing so, I have picked up new learning and insights with these leads. I applied them in my own way for my organization. I have on many occasions shared my experiences in many of these forums, and also taken interest in taking sessions for students in management institutions. I call it ‘learning by teaching’, because I have to first read and prepare for these sessions. While teaching, my own doubts and partial understanding get cleared by itself.

If I were to pen down various ways in which I benefitted from these interactions, I would state the following:

By attending vendor events, I learned a lot about new and emergent technologies like storage, virtualization, UTM, cloud computing etc. Through listening and asking questions, you can elicit answers to queries that remain unanswered based on reading articles.

Through case studies presented by user organizations.

Next is networking with CIOs. In our case, we formed an association of CIOs and met regularly. By doing so, we could exchange our ideas and experiences. We also knew whom to speak to when we are struggling with technology and applications.

Interaction with vendors has been a rewarding experience. When I used to call a vendor for my requirements, I would pose my problem, and ask them to suggest a solution. For one, the vendor knows more about technology than we do. So when they come out with a solution, many a time it can be an eye opener. By letting vendors speak on the strength of their solution vis-a-vis a competitor, I could learn a lot from them – frankly, this is free education of sorts.

I would like to leave you with the experience of a colleague of mine — someone who shied away from networking with the community, and hence lost his edge. This nice chap worked with me, and I took personal interest in training him for higher level tasks. Impressed with his sincerity, I coached him to act like a CIO by asking him to do a few activities that I would otherwise do.

When I was leaving that organization, he wanted to make a change as well, and asked for my help in the process. My coaching helped him pick up a CIO position with a mid-sized company. He carried out that role, and then moved on to another organization. However, he kept to himself and tried to copy the solutions that he had learnt from his earlier organization. He did not network with peers or seniors in the community. Nor did he pick up new knowledge. After a while, I found him struggling for another job, at a loss to understand his career direction.

Gone are the days when the IT Manager used to sit securely in his glass cabin and manage back-end processing. Today’s CIO has to be a part of the business, and help in its effective management. He has to work alongside other functionaries and see that IT solutions fit into the business fabric. Therefore, the CIO has to interact with business heads, understand their plans, identify the constraints they face, and then try to work out solutions that help them execute their plans. He should also be in touch with the CEO to understand his vision and get a sense of direction of the business.

Having said this, CIOs should realize that they can’t always look serious — or talk shop all the time. Well, shouldn’t he be more open, jovial, sporting and social at times? I hate chaps who get somber after exchanging the initial customary greetings and start narrating their problems. I wonder what they would lose if they could smile and talk of general matters, before bursting out with their issues. Can’t they give me some breathing space?

Now, take it the other way around. If you were the serious looking CIO, wouldn’t the user look at you the same way?

The CIO will surely do better if he moves around the organization meeting fellow employees — asking if they are comfortable working on the systems and noting down their grievances (if any). He can meet the senior officials (say, over a cup of tea), and get into a general conversation. This is not only about developing a friendship, but also about stating the fact that you recognize his presence in the organization — that you value his company.

Whenever there are get-togethers or a party called to commemorate a success, the CIO should choose to join these (if invited). On, say a successful completion of a project, the CIO can throw a party. He can call relevant users and acknowledge their contribution. A good way of getting closer will be to call over a few close executives for a dinner at his residence on a week end. In many organizations that I have been in, I have seen a small greetings application which gives out the names of employees whose birthdays are due. It is always a great idea to wish these colleagues of yours.

All this is about networking with people within the organization. This improves your acceptability as a CIO, and become more approachable. You will be able to get a lot of information on the going-ons in the company and we can stay abreast with the changes. Access to the grapevine is yet another possible benefit, and nothing is wrong with it.

The biggest advantage is that your interactions with many become informal, though they remain official in nature. As the CIO, you will be able to cut across bureaucracy and resolve many a contentious issue in a friendly manner. When in a tight spot, these people may come to your rescue and offer help. After all, nothing is better than being in a place where you feel part of the family.

I have spent half my professional life spreading awareness among the senior management staff in various organizations, importance of Information Technology for the business, and the need of management attention. It was an enjoyable experience, since I got to observe them in various moods depending on their interest and grasp of the subject.

While some are curious and ask questions, others nod their heads as if they understand everything. A few look bored all through, and the rest of them remain cynical — not believing a word of what is being said. But all would sit through the sessions, enjoy their lunch, and cherish the break from routine work.

Of course, quite a lot depended on the CEO and his take on these awareness sessions. If the CEO was keen and attentive, you would find a couple of others serious about the awareness session and benefitting from it. But if the CEO yawned, others would do so too – the effect is contagious.

Some of these sessions would be a short session of two hours or span an entire day, depending upon the objective. In some cases, I took upon myself to deliver these sessions. At other times, I invited external experts to brainwash them into believing the importance of IT. I succeeded on a few occasions, and fell short of my expectations at other times. You would agree that this is a difficult task, but it is extremely important to get a buy-in from these top guys if one has to be successful.

I certainly cherish moments when some seniors came to me and confessed that they had undergone a certain transformation in understanding IT — afterwards their dealings reflected this change. They became supportive, started to participate, and offer suggestions. But these were a few picks from the lot. Most of the others stayed unchanged, and continued to be as ‘intelligent’ as earlier.

Let me narrate a couple of incidents. During the introduction of a whole new IT program in the new organization, I arranged a full day IT awareness session (with a leading global IT vendor) for the top brass. Their director in charge of training flew in from the US to pick up this challenge. He asked me to join only at the last session, as he wanted the directors and VPs to feel free in expressing their take on IT. He took a wonderful session (I was told), wherein he cited various examples and subjected them to case studies which had to be solved in groups. I joined them on the last hour, and I was impressed with the rapt attention with which the audience listened to him.

Just after the day ended, the head of marketing came up to me, and said that he realized that his department has been given a lesser number of PCs than the finance department. The next half an hour was on a discourse about the politics of PC distribution in the organization. He refused to get drawn into a discussion on the specifications of the new sales and distribution system (which was lying with him for his approval). Perhaps what he learnt from the session was that PCs are the most important aspect of IT.

In another organization, I made a comprehensive presentation of the IT strategy and plans that I had drawn up for the next three years. Since this was in keeping with the business plan drawn up earlier, I sincerely hoped that I had been able to inject a bit of IT into their hearts. However, the experience was to the contrary, as three of these vice presidents converged on me to complain about their PC and printer troubles.

I have often tried to draw these chaps into intellectual discussions. However, I often find that they talk more about PCs, printers, or troubles in accessing e-mail and the Internet rather than speaking on the business issues for which they need a solution. Well, IT seems to be all about these simple equipment and facilities. I wonder whether IT is so complicated that it frightens these simple beings. I have not given up still, as I continue my research on the subject.

I have been in circumstances which I would describe as embarrassing for me as a CIO. When busy dealing with serious and strategic matters relating to the business, I would often come across a demand from the CEO or some senior functionary, asking for their gadgets to be configured.

These blokes would often visit abroad, pick up some interesting objects, and come back — eager to get it running. At other times, it would be their children who pick up these toys, and hand it over to dad for getting them activated. These interesting gadgets would be say an iPod, iPhone, new mobile phones with 3G features, PDA, scheduler, digital photo frame, camera, videos, and so on. Some of these would be the latest models — those which are not yet been launched in India.

Ironically, these wise men would normally draw up plenty of excuses to put off important discussions involving important systems feigning busy demeanor. They would have all the time to follow up on these miscellaneous tasks. A lot of time would be spent seeking a demo run of the gadget and then play with it.

Really, how very romantic!

Now, these wise guys wouldn’t contact me, but instead call one of my assistants. The objects would be handed over to them for immediate attention. Not only would they politely request for priority, but also follow up with them through the day. Now this fall guy, often the system administrator or the Data Center in-charge, would feel rather cowed down by these polite but firm orders. So these personnel would not even tell the esteemed customer that they have important tasks on hand. They would then turn to me with a pleading look — asking me to rescue them from this situation.

There have been times when I thought it not prudent to intervene in such situations. This is because if I were to speak to the senior guy, he would reply that he never meant to disturb routine tasks. Besides, the system administrator had never apprised him that he was busy.

Tough dilemma, isn’t it? Let me share with you some of the measures that I took to handle such situations.

On a few occasions, I would tell my chap to do his regular work. If accosted by the senior person, he would tell them that I had assigned urgent work. He would attend to the gadget as soon he was through with his task. But if it is the CEO or the owner Director, such a stand would be a little risky to adopt.

Then I hit upon a new idea. I spoke to one of our service providers who used to deal with product imports. He had a few chaps who were adept on such fancy stuff. I then weaved a contract asking him to provide me a person who would be available when needed. In short, someone who could fix these fancy objects, and demonstrate them to the proud owner. The scope involved his visits to the Directors’ homes (as well as dealing with the children). Over a period of time, we asked them to directly call up the service provider, and this worked. My boys heaved a sigh of relief as they came up to me with broad smiles telling me that I got them out of captivity.

I am sure many of my CIO friends have faced similar situations, and found innovative ways to deal with it. But this is an interesting situation that we often come across. Such requests challenge our guiles and push us to our wit’s end. But we are also smart, aren’t we?

We have witnessed rapid technology changes around us, along with an evolution of the software landscape. Today we run a host of application software packages ranging from office application packages on desktops/laptops to enterprise packages like ERP. Some of these are user oriented, while other enterprise packages are often mission critical, and should be dealt with carefully. CIOs frequently face the challenge of upgrading these packages from time to time. Now let us examine situations in which the CIO has to take a decision.

User packages like office applications on PCs are not much of an issue. For proprietary packages, we may either pay up AMC or take an upgrade charge (depending on the vendor policy), and then decide when to upgrade. In case of open source software, the call has to be taken by the customer in consultation with the service provider. Many a times, we face problems when some users are on the upgraded platform, while others are not. Files generated on upgraded software are sometimes are not readable on the older platforms.

For other specific application packages, the decision for an upgrade has to be taken based on the necessity. It also depends upon the position of the version in the product upgrade cycle.

The decision is often a bit involved when it comes to packages like ERP. Being a mission critical application and closely linked to the day to day work, any decision on upgrade has to be well thought of, as it has organization wide ramifications. I have found that CIOs often get stuck, and therefore defer decisions for too long. One of the main reasons is that ERP upgrade is a project in itself. It requires justifications and involvement of the organization.

There are two factors that influence our decision while deciding to go for an application upgrade. One is that the vendor announces the date from which a particular version will go out of support. That is a reasonable call, as the vendor cannot be expected to keep staff to support an older version. In such cases, organizations scamper to complete the upgrade since they don’t want to lose vendor support. Some organizations prefer to continue with the old version, and appoint a support person externally at a much lower cost. I consider both these moves— that is, either waiting till the last minute to upgrade or continuing on with de-supported version—rather dangerous and perhaps to be avoided. CIOs can choose an appropriate time to upgrade once he is told about the support schedule by the vendor.

The second situation requiring an upgrade is when the organization gets interested in doing so to enable use of features offered by the new version. I will cite two examples. In one of my earlier organizations, the decision for our upgrade to SAP version 4.7 and the middleware (Netweaver), was influenced by the company’s desire to implement CRM and SRM packages. These could have worked best in the newer version. Similarly, in the current organization, we are upgrading our Oracle EBS version R11 to R12, as we intend to implement a Production Planning system (with discrete and process manufacturing features as well as product costing), which is well served in the new version.

In either case, it requires a balanced view and the courage to upgrade at an appropriate time. Such upgrades require involvement of all the stakeholders to make it happen.

We have a lot of equipment in the data center—servers, storage boxes, SAN switches and network switches. Many of these are expensive, and bought with approvals that require a lot of justification. But like all equipment, these too age, and cry for a replacement.

If the server gives trouble and there are frequent interruptions. Or in cases when spare parts for the equipment are scarce and difficult to get. Yet another scenario is when the machine tends to get obsolete.

When the OS version is old and cannot accommodate new versions of software packages. Or consider replacement if the OS becomes incompatible with applications on other servers.

The manufacturer notifies end of support to the equipment.

There is another scene that I had come across a few times. For example, once we were in discussion for an enterprise storage server enhancement. The vendor suggested that instead of adding more disks, it would be prudent to buy a new storage server. I thought he was out of his mind, and chided him for the suggestion. He asked me to cool down and listen to him, and what he said made sense. His rough calculation went on these lines – the new equipment will be much faster, have larger capacity, fall into obsolescence much later, and come with a three year warranty. As against this, I would pay a higher amount for addition of the low capacity disks by retaining the old machine. I would run out of space much faster, be less prepared for the increasing demand for performance, and pay huge amount as AMC (which was a fixed percentage on the original purchase price).

It pained my heart to part with the reliable old box which had served me for over four years. Better sense prevailed, and I put a note to the management with ROI calculations and lo-behold, it received approval. I have now followed this principle in a few other cases. So the lesson is to make a sound business decision, and not carried away by emotional attachment to old assets.

CIOs often wait till the end when it becomes imperative to change, and that creates a panic situation. The explanation is usually on the lines of “Why should I disturb something, if it is running fine?” When I joined my current organization, I found systems that were over a decade old. Even the OS version was not disturbed—neither was it factored in the immediate plans. The organization had to make do with sub-optimal systems till it found alternative approaches. It is therefore important to continuously review the status, and carry out necessary replacements as appropriate.

Nowadays, all office employees are provided with a system—either a desktop or a laptop—to carry out their work. While such equipment is added whenever new employees join the organization, old systems are replaced with new ones (as and when they become due). On this front, certain organizations do have a very clear policy for replacement, but many don’t.

It is necessary to define clear rules for refresh and also convey them to the organization at large. Users are often tempted to ask for a replacement because their colleague might have got a new machine with better features. This request often comes in the form of false complaints which incline towards a plea for a replacement.

Rules of replacement vary across organizations. While some specify a fixed time period for retiring old assets, others specify a batch that would be replaced. The time period for retirement also varies between three to five years. In fact, many such rules may often not be based on scientific assessment.

I have heard of such debates in organizations during times of stress—for example, in times of recession or when the company’s business and finances are under pressure. At such times, business questions the rules for replacement, and often asks for extension of the period. This is again an ad-hoc measure, and not based on sound judgment.

There have been several studies made on this subject. I recall a Wipro case study which pointed out a few factors to be considered for the purpose. For instance, if the ideal period to retire a client machine is three years, then the following considerations are necessary:

The PC usually comes with a three year warranty. Therefore, we will have to opt for an annual maintenance contract (AMC) after this period

Beyond this period, we generally face work disruption due to failure of parts. For example, often laptop displays start giving problems, batteries die out, and CPU (or RAM) needs replacement.

We spend on repairs, spends go up, but all these don’t enhance the resale value. The total cost of ownership goes up.

Delay often causes problems in terms of compatibility, For example, it could be in the form of not being able to read files created in a higher version by other colleagues. Or it could be in terms of difficulty faced in installing the newer version of a software package.

If we replace with a new machine, we get a three year warranty, and therefore save these costs.

We may often be tempted to defer replacements, thinking that we have saved in terms of spends for the year. However, when considered from a long term perspective, we may perhaps find that this was not the right decision.

Every other day we hear of a different product or service, a new software version, or an innovation. You hear on a constant basis about known companies being taken over and strange mergers. All these tend to leaves us confused, but that is only one part of the story.

IT is no longer the domain of techies, since there are umpteen users who read about, explore and operate new technologies. These users then put pressure on the IT manager asking why such new technologies or gadgets are not being used. The poor CIO is on the receiving end, and has to do his bit to prove his mettle.

Even otherwise, the lure of new technology, strong selling by vendors or just peer pressure, sucks in the CIOs into introducing new technologies without a full study. Many CIOs are very prudent and have been immensely successful on this front, but I am talking of those who catch the bait and struggle with the acquired technology.

It is important for a CIO to constantly scan the environment, regularly read up on new developments, as well as understand the new trends and the main principle behind the innovation. After grasping the subject, he should think about the applications that it can be applied to. Then he should apply his mind to figure out if there are situations in his business that such solutions can be applied to. In fact, the very interest in a particular technology emanates from the business need that stays on the top of the mind of the CIO.

I have noticed several mistakes that CIOs have made in the past. A quick look at some of these will tell us the kind of moves that we should avoid.

1. Often, CIOs trap the management into accepting ERP without a clear plan and business interests. In many such cases, the CIO might have thought that ERP experience will strengthen his resume. However, when he’s asked to manage the ERP project, our friend struggles to get users on board. Thus the ERP is reduced to a simple replacement of the earlier legacy system. Management questions the ERP’s usefulness, and the CIO has no answer.
2. Putting up a budget for a ‘disaster recovery plan’ without a proper risk assessment and recovery time objective (RTO) or recovery point objective (RPO) definition. Several such plans have come a cropper.
3. Installing a unified messaging system in the organization, but doing nothing more than instant messaging. Many a time this could be because of bandwidth or user adoption issues, but it lies largely unused.
4. Introducing mobility solutions to impress the management and end users, but struggle to start off applications like sales force automation, stock movement monitoring, and market info.
5. Getting IP phones for a few senior people without testing the voice quality and not realizing about the steady drop in telecom rates.
6. Installing enterprise storage, but not using its storage management features.

These are but a few examples that emphasize the fact that CIOs must put enough thoughts into any purchase. It’s essential that you conduct enough preparation before applying these technologies.

Today’s CIO faces a dilemma. He knows technology, and he thinks he knows the business that his company is in. However, he’s confronted with articles and seminars that discuss the CIO role, which emphasize the fact that he should understand and participate in business. All these mean well, but these emphasize so much times on other aspects that the CIO’s knowledge of technology is pushed far into the background.

In fact, some of the articles also state that the CIO should not be a technology person but one from business. These even suggest that the CIO can always have technical personnel to help him achieve his objectives. So our CIO ends up tearing his hair as he tries to understand his place in the corporate world—unsure of his relevance.

Now let us debate this point a little. Let us assume that a bright manager who manages some business aspect is assigned to lead the team as a CIO. He definitely understands the business scenario and the company’s needs that are to be addressed. However, he may not be sure about which of these aspects could be addressed through technology. So he calls his technology manager and asks for ideas; so far, so good. Now the techie explains new technologies, but is not able to convince our CIO. Here, the question is about whether you run your business the way you conceive. Do you just put in technology for automation? That may not be the optimal usage of technology for business.

So it’s important to know not just business. It’s equally important to know and understand technology; how it could be applied to business. In my opinion, the CIO should also scan the technology environment—pick out technologies that could be relevant to his business.

Then he has to evaluate these technologies in detail. To do so, he should not only read articles and other hand-outs, but also meet and discuss various aspects with the technology vendors. Now, to be in a position to evaluate technologies, you have to learn them first. This involves constant research about organizations that have applied various technologies, attending events that speak about technology applications (and success stories) as well as speaking to consultants (or user organizations) to learn of the new developments. Well, all these involve time. Therefore, knowledge of technology cannot be pushed aside.

In this connection, let me recount my stint in a management consulting firm. My counterparts working on accounts and inventory applications used to finalize all processes and forms. These would then be handed over to IT in order to automate the process. For them, IT enablement meant putting in a few square boxes on the form to help enter the account numbers or inventory codes. Many a time, during discussion of these processes, I used to point out many processes that could have been made simpler—just by just applying our minds to think of processes from an automation context. Many of these specifications changed as a result. This is why I feel that knowledge of just one side of the picture is not enough to do justice.

So, it doesn’t really matter whether the CIO is a business person with a fair comprehension of technology or a technology person with a good idea of business. It is important to know technology before we think of applying it.

CIOs need not feel shy talking about technology even though it is fashionable to talk of business. If he professes to know technology, it may not necessarily put him into a slot where he may be looked down upon. The issues rise when he talks only in technical terms. If he closes his eyes and ears to other matters concerning business, then he is definitely asking for trouble. I for one, feel that those types of professionals are slowly becoming scarce.

About This Blog

The issue is not information technology, but management. Optimal utilization of technology and management, and IT/business alignment are the components of a successful strategy. Information technology management can be a tougher job than meets the eye, so here are some useful mantras for the CIO’s arsenal.