IT plans and budgets often look progressive and impressive. The bigger the organization, the larger would be the budget and speaks of the power that the CIO commands. But the real power is derived from implementing them and making the solutions work. The status of the CIO and of the IT group goes up a notch every time they make a success of any project.
As we make plans for the coming year and start working on them, it is the year-end review which lets us know if we were good enough in meeting our commitments. A good report card strengthens the position of the CIO in the management group. While this requires hard work and dedication on his part through the year, the approach direction he takes has a great significance. Let us take a look at various measures that he can take towards this end.
- Setting priorities: It is important that clear priorities are set and that execution plans give clear precedence to matters that stand high on the list. We have to ensure that these are business priorities that are in line with the strategic plan of the organization. The real success of IT lies in enabling business in meeting market expectations and in achieving growth. If the right attention is not given to such projects, all sundry matters occupy the space thus crowding out resources from important projects leaving them incomplete. When such projects of importance like supply chain automation, CRM, sales force automation, ERP etc, lie unfinished, they give a poor impression of the IT program, even though the IT staff we may have done a great job in storage deployment, Network implementation etc.
- Projects should be well-conceived: We have to avoid situations where we move three steps forward and two steps backwards. I often find people starting off a project under pressure from the user but later finding various gaps in understanding and scope definition. Such stoppages and getting back to review details puts back the IT plans by several weeks and are often difficult to make up. It is therefore crucial to put that extra effort to manage user expectations and to fix up the scope and coverage before kick-off.
- User involvement / ownership: Projects that start without a clear user involvement and those where the stake holder has not assumed full ownership are bound to falter. Many a time CIOs give this a pass and proceed as they try to complete their task as defined in their KRAs. In most such cases they get into trouble as they struggle with scope creep, and lack of user co-operation in defining specifications and subsequent testing. It is advisable to hold on to the project till the users get on board.
- Project management: This is an essential skill that the CIO has to possess and apply. Projects are always prone to delays and it is here that he has to apply his skills in undertaking regular reviews, use Gantt charts, and other project management techniques to intervene where necessary and on time. Delays have to be addressed immediately so that they don’t grow bigger needing escalation.
- Vendor management: Vendors are important constituents to the projects, whether they are hardware, software, network vendors or system integrators. Their knowledge and experience can easily be leveraged upon to fix problems at various stages of the project. It is important to build relationship with them and keep them engaged in the project. A good practice employed by many organizations is to have the vendor partner as a member of the Steering Committee. They can bring specific expertise at crucial junctures and get the project going.
A good handling of activities can see us achieve the objectives set at the beginning of the year. Even though all milestones may not have been crossed a good success rate draws appreciation of the organization since some of the projects get delayed because of various organization constraints. A plan capped with a sound execution signifies excellence.
We struggle with our IT budgets every year. As the year draws to a close, we try to estimate all that is in store for the next year and go about jotting it down. The problem is that the ‘budget’ not only carries what we want to do, but also carries the demands that users and user departments make. The challenge is two-fold—one is to arrive at a realistic estimate of expenses, and another is to get them approved by the management. Now how does one go about these tasks?
The act of making a wholesome budget and getting it cleared by the management is an art. It consists of a series of steps—right from carrying forward unfinished tasks from the previous year, to undertaking new and fresh programs in the New Year. The budget also covers routine tasks and maintenance of the current systems, aka keeping the ‘lights on’. A tricky job, this.
I suggest the following steps to make sure that we are right in our budget making:
1. Requisitions from functional departments: Ask departments to list out their requirements of IT support, along with their business plans which trigger these requirements. Try not to accept simple requests for the PCs, printers and software without them specifying the accompanying business need. This needs careful handling, as mere collation of requirements run contrary to our stated objective of being effective CIOs. We have to ensure that IT serves the business’ purpose. Unless the assets are put to right use, you cannot obtain benefits.
2. Bring out the Information Systems plan: Prepare a plan document that states the main business issues that IT plans to address. For example, these may include process automation in the plant, supply chain efficiency, ERP, work flow in specific areas, or sales force automation. This is the language that business understands, and the management is also clear about the addressed business challenges. In such cases, budget approvals are not very difficult to obtain. Routine expenses including maintenance and AMCs are usually not discussed on such occasions.
3. Translate in to an IT plan: Once the main direction for IT receives approval, we need to translate this in to a list of necessary equipment and software to be bought (or hired). This has to be executed carefully, taking into account new technologies and solutions offered in the market. It is advisable to review the current status of hardware and software—suggest upgrade or replacement where necessary.
4. Estimation of prices: This is often a challenge. I have been in both spots—situations when prices used to go up every year as well as the latter environment when prices saw a drop every year. In either case, it is best to apply our best judgment by obtaining prices from vendors—either formal or informal. You can formally ask vendors to submit their budgetary prices and then apply your judgment. This way, we come to a financial figure which may not vary widely with time—unless of course there are unforeseen changes.
5. Presenting to the management: On this front, you can put up a presentation to explain IT’s efforts to enhance business capability or efficiency, or send a note that clearly explains the direction being pursued and considered assumptions.
During my career, I have taken this approach and seen it work. I admit that getting a budget approved is not always easy—all the more so at times of low growth and recession, but proper persuasion would help avoid drastic cuts to the IT budget. The IT budget is often the first victim when cuts are imposed on spending, but if put across as a business initiative, spends may look justified. Lastly, it is important to work on the approved plans during the year and come out successfully–let us remember that we again have to approach the Board next year for approval of our budgets.
Procurement is one of the prominent tasks undertaken by a CIO regularly. In order to get ahead with his program, he has to constantly procure new hardware, software, network solutions, and services. Poor bloke; he goes about this difficult task and often gets entangled with the host of options thrown at him. Well equipped to deal with this he finds his way out and has the last laugh.
A few, however, bite their finger nails and look around for help. I have often received calls from my friends asking me how I dealt with a particular situation. Their dilemma is understandable. Vendors and media hurl jargons, shout from rooftops about new technology solutions, and send mailers to all including the CEOs. Sometimes the CIO is forced to look at a technology offering that either he or the vendor representatives know little about. One way to get through this problem is to do a detailed study, ask specific questions to vendors and ask them to convince how the solution would benefit the organization, once the need is defined by the company. A document in the form of RFP (request for proposal), clearly stating the objective, can be of great help.
Receiving the proposal and going through it is another challenge. Many a times vendors stretch the solution and increase the scope and it is here that the CIO applies his clear sense of propriety and calls in the vendor to stay within the limits of the actual requirement. However you cannot prevent the vendors from exercising their ingenuity in suggesting to us better solutions and this surely is to be appreciated. When receiving proposals from vendors, care has to be taken to see that main parts of the proposals are similar and only some specific areas are put up as value-adds, as otherwise it may become difficult to compare and evaluate the solution for decision making.
Juggling with the proposals is, again, a difficult task. We usually prepare a comparison sheet tabling features and the corresponding responses from each vendor. Most of the responses, however, look similar and we then have to draw out our decisions from the responses that go in favor of one or those points which go against the other. Here again, assigning weightages to various points could help as all features may not be of the same significance. There are also some qualitative measures that need separate treatment. So notes and explanation serve the purpose of supporting the decision that we make.
It makes a lot of sense to call in the parties for free discussion and clarify whatever queries that we have. Sometimes our own understanding could be at fault and therefore need to be whetted. A great advantage of open discussion is that each vendor brings in his perspective and says a word or two about the rival product. This brings in greater insight and opens up more points for discussion and evaluation. Of whatever I know of technology, a lot is due to vendors, who have given me free education during such meetings. An in-depth knowledge of technology makes our judgment surer and steps that we take to implement such technologies go in the right direction.
We may select one of the products/ vendors out of the whole lot that we evaluate. Vendors losing out are sore and feel that the evaluation has not been fair. It is a good practice to call the vendors not selected and explain to them the basis of their decision. Vendors may or may not agree with you but at least they go with the message that there was some logic applied to the selection. By doing so I have been able to retain my relationship with vendors over the years.
I followed one axiom very early in my career ― always try to get the most out of the technology we acquire. This may seem very simple to state but when practiced the results could be amazing. I would expect many to say that this is what they are doing but then where is the catch?
People implement technology in its various forms and do implement those projects ‘successfully’. But success is a relative term, it could either mean technical completion that is successful or that the purpose for which it was put in place has been served. More often than not it is a successful completion of a process. It is like scoring marks in an examination but not taking into account whether the student has thoroughly understood the subject or not.
Let me explain further with examples. We have seen many of our friend CIOs claiming their ERP program to be a success. I am no way doubting their claim of having putting in the ERP in their organization and making it run, but when asked about the main business drivers for ERP and their fulfillment, I do not generally get clear answers. I find very little transformation being attempted and no significant changes to the business processes. The usual refrain is that there is user resistance and that it is only for the functional heads to suggest and drive process changes, etc. So it’s usually a story of a job not fully done.
Another area that lacks full credibility is business intelligence. I have heard CIOs proudly announcing of their arrival into the BI club and that they are now ready to share their success story with anyone. When quizzed further, I find that their implementations speak of various reports and the ease of their generation. Many a time I find them to be routine reports comparing actuals against targets or budgets or reports showing analysis, say of region-wise, product- or category-wise, or salesman-wise sales; or may be, a simple inventory analysis.
Well, these reports can be generated otherwise though with some effort, but I don’t see any intelligence in them. These reports do not generate any insight or throw up hidden trends or exceptions to the general rule. How then we call it a BI project?
Let me also talk about sales force automation (SFA) ― a clear demand of business with the advancement of communication technologies. It’s good to see CIOs willingly pursuing this initiative and taking a lead. Implementation is done, field salesmen regularly send in data, and thus, the reports are generated. They give more information than was possible earlier and the marketing/ sales team can get data at a more granular level. But when asked whether the data has given them more insight into matters or trends that they did not know or whether they have got valuable info to re-strategize their moves, they draw a blank.
Now imagine if the ERP were implemented with noticeable process changes leading to elimination of non value-added steps, significant reduction in process time, savings in inventory, better customer order fulfillment and better response to market needs, the technology would work wonders.
Similarly if the BI implementation gave important information through deep dive analysis of production wastages, of market trends, customer behaviors not otherwise known, the result would itself pay back the investments in BI many times over. If SFA could give deeper understanding of markets and trends that we can immediately attend, the company can be a real winner.
My point of emphasis is that an IT system that we implement can be more comprehensive and the one that addresses the objectives of business. We need to apply ourselves fully, get into the depth of the business systems, and keep an eye on the competitive advantage that the business can derive.
Anything falling short of these requirements would be what I will term as ‘vanilla’ implementations.
Many years ago, as I was submitting the summary of our findings of study to the CEO of a client organization, his remarks stayed on with me for long. Our assignment was to assess the efficacy of their IT program, and suggest improvements in its functioning. Amongst other things, we found that some of the IT assets like PCs, printers were bought but not utilized; similarly, some software solutions were not implemented due to disagreement with the users. As expected, the CEO was disappointed, and said that he expected his CIO to be more responsible.
The CEO considered his CIO to be the custodian of all IT assets —one who ensured that right solutions are bought and put to proper use. When the CIO asks for a budget and subsequent buys, he clears them in good faith with the expectation that he would look up to the CIO to take care of them. I thought that these were significant remarks which clearly demonstrated the CEO’s expectations and consequences of the CIO not living up to those expectations.
What I learnt in that exchange helped me immensely when I moved on to the corporate world as a CIO. Whenever I put up a plan to the Board, I did sufficient homework, and then proceeded to ensure that all spends were properly justified. Let me share with you some of the actions that I took.
In early days, desktops were provided to officers and staff based on their requirements. However, certain senior officers would often misuse this facility. They would get a desktop or laptop on their table (as a status symbol). They ended up not using it; or occasionally asking their secretaries/assistants to come and type out their emails or letters. Sensing this as the waste of an asset, I sent a message on behalf of the management saying that PCs that not being personally used by officers would be withdrawn. This worked like magic. Officers scampered to learn usage, and were home.
To cite yet another example from another organization, I found that the previous CIO had ordered for VSATs a year ago, but couldn’t somehow put the solutions to use. The first thing I did was to introduce enterprise wide e-mail and use the VSATs – that helped in developing an immediate rapport with the CEO.
Later on, I was put in charge of the ERP project. Instead of just attempting a successful implementation, I felt that the real success of ERP was when it starts to benefit the organization. So I worked relentlessly on process improvement in all areas (including manufacturing, materials, sales and finance). That proved to be a great experience. In such cases I feel that the best approach is to resist the temptation of putting the blame on users—instead, try to work with them and turn them around.
Assuming full responsibility for IT assets means due evaluation of requirements, proper selection, full participation to ensure success of each implementation, regular scanning of all areas to ensure that the assets are being utilized, and to keep looking for continuous improvement.
The bright side of this approach is that the management and users develop confidence in us as CIOs. Budgets and proposals for new projects are easily cleared. People start trusting us, and the famed user resistance reduces to a low and a manageable level. Vendors are also happy that their product/service is being utilized well and they come forward to support our initiatives. This really works.
I recently attended a seminar, the topic of discussion being ‘Managed Support Services’. There have been too many seminars of late, and this was one of them. Organized by a technology media company and sponsored by a leading vendor, the seminar had the hapless CIOs come over and attend. I guess CIOs come in more because of their obligation to friends who are with these media companies or vendors, or also because of their need to network with peers. An evening of some talk followed by cocktails and dinner allows CIOs to socialize a bit.
Nevertheless, the program started off a little behind schedule as usual, and after a brief introduction of the subject, the topic was thrown open for discussion. The format of the session was in the form of a roundtable, and every participant had a chance to express his view. The initial discussion veered around the variety of applications that run in our organizations, multiplicity of platforms, and problems of managing them. Most said that it was difficult for the CIO to manage all these jobs effectively for ensuring continuous availability, and it was therefore prudent to outsource these support services. The difficulty stems from the fact that they need to develop expertise on multiple platforms, and at the same time deal with staff attrition which is common in the IT circles. Some CIOs were of the view that choosing all solutions from a single vendor would help reduce complexity, though many others disagreed with this view.
The conversation then slowly moved towards effectiveness of the outsourcing measures taken and the way to get them right. Many of the participants had their views to express about the pains they face. They complained that vendors have to be monitored very closely and need to be held them down brandishing the SLA document. The common refrain was that vendors promise something in the beginning, but act otherwise—deploy not so bright boys, and hardly ever monitor on their own. The second view was also not so charitable. The feeling was that vendor organizations do not work as partners, since they always have their billings and revenue in mind—that they hardly ever think of the customer pain points.
To me, somehow, the whole discussion sounded a little funny. While on one hand we talk of the need for working in a partnership mode, on the other we express such lack of confidence on the vendor who supports us. Is the vendor always wrong, and is it that leading vendors in India do not know their business? Isn’t the partnership always between equals? What if I wield the whip saying ‘customer is the king’, and hold down the partner because he is dying for my business? The question is, shouldn’t the CIO also feel an obligation to enquire whether the partner faces any constraint and take a step forward to help him, with a spirit of ‘helping him to help you’? It is always easy for the CIO to find fault with the vendor and replace him with another one at the earliest available opportunity, but I am not sure if that would solve his problem. Changing a vendor is again painful, and causes disruption during those periods of change over.
In my opinion, many CIOs need to understand the principle of partnership and seek to reform themselves before trying to look into the shortcomings of their technology partners. It may be fashionable to speak of their great bravado of taming vendors, but that doesn’t lead them too far. True partnerships often unleash creativity, and bring out solutions that are game changing–synergies from working together may be the real trick that could work wonders.
Whenever I visited developed countries, I learned quite a few things about their general infrastructure. For instance, when I went to Switzerland a few years back, I found it very easy to travel by train from one city to another. We could board any train without a prior reservation. The trains ran at fixed intervals, and had enough seats available at all times. Initially, I did have a feeling that too much infrastructure was provided, and therefore wasted. But as I reflected on this arrangement, I realized the positive side of things. Since there was no shortage, they had completely done away with the booking infrastructure — entire booking office facilities, as well as the need for each passenger to pre-plan their travel and do advance bookings.
Similarly, I was amazed to see the network of roads, flyovers and bypasses in countries like USA, Canada, South Africa and China. The first thought that occurred to me was that such a huge investment was not necessary; it was a simply a hype and luxury. But let us look at the positive side of the story – this facility does away with road crossings, red lights and policemen manning the crossings — not taking into account the time wasted by each vehicle which waits at such signals. Isn’t that a huge cost incurred by us?
Now, we in IT can learn from such an observation. Many a time, we evaluate projects on the basis of costs and then provide for facilities that we think are optimum. We face constraints as soon as usage goes up. For example, in one of the earlier companies that I was with, we often got complaints that the network was slow. So my team started to evaluate packet shapers as well as other network tools to monitor and regulate traffic. However, inspired by a foreign visit, I compared the cost of monitoring versus doubling of bandwidth. I finally decided to overprovision network bandwidth. By doing so, I could avoid network monitoring tool investments as well as my infrastructure team’s time, which would otherwise have been spent on this daily activity.
I then used the same learning for provisioning other resources like servers and storage in our data centers. Despite our best efforts in sizing, I always found worked out configuration to be on the lower side, leading to further additions. Problems with provisioning server resources with increasing usage were common, till we had a solution in the form of server virtualization. Similarly, howsoever smart I tried to be with storage sizing, I always fell short. So I adopted a simple solution – to add sufficient buffer to the calculations.
Contrary to common belief, this practice really doesn’t add to much cost. In fact, it’s an incremental cost which takes away the headache without hindering business. By saying so, I don’t mean that you should dump huge facilities, but add sufficient capacity so that you are not constrained in terms of work. The cost of restraining people or asking them to wait is a huge societal cost, and should be taken cognizance of.
We say that the CIO is an important functionary in an organization — one who plays a significant role in business growth and prosperity. It is but natural that he should occupy a position of responsibility and power. As a result, he is able to execute various projects which help the organization meet its objectives. However, the status is often different in practice, and the management in many such companies needs to take a serious look at this situation.
It’s common to find that CIOs are recruited at the senior manager or general manager levels, and made to report to the CFO. This was perhaps appropriate during the EDP days, when most applications were for the accounts department. Times have however changed over the years.
Today, IT covers all functions and cuts across all organization activities. Hence continuance of this old practice looks totally illogical. The CIO’s position becomes vulnerable, as rest of the organization looks at him as a finance representative and an automatic bias sets in. IT plans get a finance orientation, with greater emphasis on accounting and control. Budgets are tightly controlled, and new technologies frowned upon.
Some organizations make the CIO report to the HR, operations head, or the sales & marketing head, but the story doesn’t change much. The CIO is not senior enough and has no access to the management committee. He is in no position to understand the CEO’s vision or the main business strategies and priorities. He is not powerful enough to drive new initiatives, or to enforce compliance to systems.
Over the years, I have tried to raise the level of IT in organizations that I was with. Apart from some stints during the earlier years when I reported to the CFO, I set the condition of reporting to CEO as a part of my joining agreement. In that position, I was able to bring about sweeping changes and added considerable value to various processes. I could often intervene and help resolve many a disputes relating to cross functional disagreements on business processes that I was trying to automate. I could enforce compliance to systems and seek the CEO’s intervention on matters that I couldn’t handle on my own. Since I was a member of the management committee I was privy to various discussions on organizational directions, goals and priorities, and able to align my IT plans to the organization’s needs.
In all forward thinking organizations, CIOs are normally at the level of vice presidents or equivalent, and at the same level of seniority as the other functional heads. The CIO should report to the CEO, thereby ensuring a total organizational view of systems, devoid of bias, and stand at an equal footing as the other organizational functionaries.
I have chosen to take superannuation in my current company. Now, I discover that the management has decided to replace the position with a relatively junior functionary; one who is being made to report to the CFO. Such examples explain the lack of understanding of IT in many organizations. Therefore, it’s not a surprise that old practices are still prevalent in the industry.
All of us face attrition-related problems, more so when there is a boom or an economic revival. Though the problem is not unique to IT, it surely does get more acute in our case many a times. At such junctures, we get critical of the younger generation and accuse them of being greedy and non-committal.
Instead of such diatribes, we need to realize that whenever there are opportunities, people will seek greener pastures. Gone are the days of steadfast loyalty of employees to their masters or to their organization. We now have independent thinking individuals with high ambitions — people set their sights on bigger things in life. Staff attrition is here to stay, and we better understand how to deal with this situation in order to mitigate this risk.
Having said that, I admit that the task is easier said than done. Getting our tasks executed and at the same time ensuring that these blokes are taken care of, is an uphill task. I am often at my wit’s end trying to balance these factors. Stopping attrition sure is impossible, but we can try to reduce its occurrence to the maximum possible extent.
There are questions in our mind as to why people leave. There could be various reasons including inadequate pay, sad work environments, bad bosses, no growth prospects, insufficient work, or overwork. Although money is not the sole criterion for people to change jobs, it has to be realized that whenever people leave, it does impact the work environment. Separation is a big loss for the IT group and the organization. The time taken to identify a replacement to join, understand the organization, get trained and be effective, causes a loss in work during this period.
When faced with this problem, I had to take several steps which worked in some measure. Let me share the details of these efforts with you.
1. Standing of the IT department: Ensure that IT occupies a pride of place in the organization. The function should report to the CEO rather than to the CFO or commercial head. Staff feel reassured that they are important to the organization.
2. Participative management: Create a core group of seniors in the IT department to discuss and come up with ideas to effectively run the department. This gives them a sense of ownership, and they retain interest in work.
3. Maintain personal rapport with each member and take care of their career aspirations: It is important to treat each member differently, and be conscious of his competence and ambitions. We need to counsel them to fully apply themselves, and stay motivated. Appropriate work allocation and proper task assignment based on their aptitude and competencies plays a big role in retaining staff.
4. Keep on introducing new technologies: I was once advised by my seniors that it will be a mistake to adopt latest technologies, as people would learn and leave. I ignored their advice and upgraded the technology landscape; the result was a drop in attrition and the fact that we could get good talent from the market. There was one another great experience. As we were on the latest version of SAP and other technologies, some of our staff members who were selected by other organizations, refused to join them as these companies had older software versions. So during such processes of change, people keep themselves busy learning and pay less attention to opportunities outside.
5. User interaction on an equal footing: If not managed properly, users may at times weigh heavily on the IT folks. It is then important for the CIO to intervene and work out a proper work arrangement for collaboration with users. IT staff thus retains their dignity and feels good.
6. Express appreciation and recognize good efforts: It is an excellent idea to appreciate good work and give them an occasional award for outstanding work, or issue letters which go into their personnel files.
I have seen some of these measures work, and been able to retain staff longer than industry norms. So it’s worth experimenting with such initiatives in order make the environment a fun to be place.
This is a question that I am not sure of asking. As of today, the CIO is an important functionary, and has a role to play in the improving organization’s capability to function in the market and beat competition. Companies, in an effort to grow and expand, take various business risks — an inherent process. As the CIO assists in this process, he may also have to take various steps that are out of the ordinary, and in line with the business’ expectation. This means that the CIO has to often take steps that help the organization leap frog in terms of efficiency, cost cutting, and seizing new business opportunities.
Does the CIO measure up to this task? Some CIOs may do so on several occasions, but many may not. I have generally found CIOs to be careful, playing safe, and generally risk averse. Let me share a few experiences to illustrate my point.
In 1993, while looking for a good platform to develop applications in a GUI environment, I stumbled upon Gupta-SQL. Foreign IT magazines had spoken highly about this product, and therefore I decided to test out their evaluation copy. Impressed with the features, I placed an order, started work on it, and developed wonderful applications. A few of my CIO friends were also evaluating the Gupta-SQL, but decided to stay on with their Oracle environment saying that they felt comfortable with it and do not want to make a change.
During early 2000, when I wanted to add more disk space, the vendor suggested that I go in for a storage server. I thought he was crazy, but when he took me through my future projections for storage and the consequences, I got the point, and set up infrastructure to take care of the future. I learnt that I was one of the early ones to adopt this solution. For a few years thereafter, I observed that many of my friends did not take that step, and continued with their earlier arrangement — despite having checked with me.
Another interesting episode was in 2006, when SAP felt increased competition from Oracle. I decided to bet on DB2 as the preferred platform, after research on the topic, discussions with industry watchers, and advice from the Gartner group. There were clear indications that for a Greenfield site, it was better to choose DB2 over Oracle DB for SAP. I went ahead, but none of my other friends dared to do so — even though I shared my study findings with them. They preferred to stay with the familiar environment.
Finally, I would like to share my experience with server virtualization. We are on VMWare, but when we spoke about shifting our applications on Microsoft and Oracle platforms, we were strongly discouraged by these vendors. We were told that their software has not been certified, except for the respective virtualized platforms. They even went as much as to caution us that they would not be able to provide support. Despite these warnings, we have successfully implemented this, and been able to benefit from the shared infrastructure. I have shared the advantages gained at various forums, but I learn that CIOs still are averse to trying out this new step, preferring to stay safe with their current hardware arrangement.
So my take is that CIOs by and large are risk averse, and stay away from any adventurism. We are told in business that ‘no risk, no profit’ – perhaps that applies to business — not IT.