When I wrote about requirement gathering versus solving business problems last week, I did not anticipate the kind of comments I would get. The agreements and flurry of lateral thoughts gave me enough impetus to continue the chain and focus on some of the views. Almost everyone agrees that we need to solve real business problems; the challenge is the definition of the business problem and changing the mind-set of our customers to stop thinking about technology and really tell us about what they want.
We talk about IT folks not speaking plain English or Spanish or whatever is the lingua franca, business tries to talk IT lingo and confuses the blazes out of the Business Analysts. Every industry has its slang and acronyms that add to the confusion (domain experts know this, but keep quiet). Between the domain expertise and the attempt to straddle the gap, the real problem gets lost in the chasm or some finer nuances remain uncovered. This then leads to what we classically refer to as out of scope functionality or scope creep.
The word creep somehow makes my hair stand up, that is the way of creepy guys or gals. Scope creep however indicates that no one articulated the problem or thought that it was unimportant or irrelevant to the discussion or just simply forgot to talk about. There are also instances of assumptions where the giver assumes that the taker has the knowledge by virtue of it being public domain or so obvious that it does not merit being explicitly being specified.
Translated to a document which the developer (read coder) in some faraway place sitting in a cubicle totally disconnected from the discussion is now writing the software that will be put up to the business. S/he does not have domain expertise and depends on the document to decipher what should be. We all have faced the end results that have missing pieces and functionality since it was not captured. Even when the development is undertaken internally these gaps exist albeit to a lesser extent.
So now the IT team gets beaten up and the Business Analyst bashed up for not translating adequately the business problem. Then the dance starts on what was said, how it was interpreted, and why does not IT make efforts to understand business. Escalations get nasty with the CIO having to face the music. While I generalize the problem, I have not come across too many instances of stupidity or wilful exclusion of documented features or functionality.
The skill of the Business Analyst to ask the right questions and probe are critical to the definition of the problem and thus the document that becomes the Holy document on which the system will be based. Leave out anything and you have a system that does not meet requirements thereby giving rise to “change requests”, the bad word for any developer, business user, IT team, CIO, CFO and whosoever is a stakeholder in the success of the solution.
Is there a way out? I believe that the CIO needs to play an important role in setting expectations upfront and defining the rules of engagement. S/he should educate the business teams on the criticality of the discussion and the necessity of clearly spelling out every aspect of the business and process irrespective of how stupid it looks or its obvious nature. A system is as good as the people who define it; trainees and junior staff with shallow expertise will provide only that, an incomplete system. Creepy no?
The journey of a thousand miles begins with a small step; similarly, the development or deployment of systems and solutions begins with requirement gathering. Conventional wisdom has it that IT teams talk to business users to gather their requirements, and then go about creating or finding a solution which fulfills defined selection criteria. When an agreement is reached between the users and IT, the system is then implemented. No user requirement, no solution.
Over the years many research papers have been written on the methodology and science of gathering requirements. Consultants created templates and promised success with common and uncommon sense. It has also been the subject of ridicule with challenged implementations, many of them attributed to requirements either not being articulated adequately or changing requirements leading to scope creep and thus sliding timelines. The most famous amongst these has been the pictorial representation below.
Image courtesy: © Paragon Innovations
When I reflect back on the time I was a rookie programmer, I too went through the journey albeit with not too many such experiences. I remember instances when the disconnect was complete while in many the users loved the solution and the benefit delivered right first time. It never occurred to me at that time to analyse why I got it right sometimes while everyone was miserable in other instances. Eighty percent success was deemed good and that kept everyone happy.
Seeking some expert advice
So last weekend over dinner when I met a CIO who recently inherited a legacy of many challenged projects, I was curious to find out how he planned to overcome history and get everyone moving in unison in the right direction. When he took on the new position, the buzz in the market was that the veteran of many industries and acclaimed implementations had taken on more than he should have. Everyone wished him luck and wondered what went wrong in his previous company for him to take such a risk.
The first month was spent assessing status, understanding and cataloguing projects, getting the team to wake up from inertia, and getting the business teams to start talking. In the company with many custom solutions, there were many stories on what went wrong in the past with fingers pointing at lack of business domain, incorrect interpretation of requirements, discipline, engagement, low skills, sliding timelines with projects not delivering even with 200% escalation in time and budget. The IT team was demoralized and had given up all hope.
Many months into his new role the vendors were on fire hearing about the transformation, change and the investments that had suddenly mushroomed. Old projects rejuvenated, new initiatives being aired; there was a direction where none was thought possible. The story had believers inside as well as outside. Having heard about this I was excited to be in his company to extract some insights on how he went about solving the unsolvable problem.
The CIO smiled at the questions and said, I coached my team to ask all the right questions and did the same myself with the CXOs. He elaborated user requirements will always contain not just what they need, but also what they think they want or should have. The requirements always contain many elements that are nice to have and not necessarily aligned to current reality. That is why they are referred to as “requirements”. So what are the right questions?
Ask the right questions
“What is the business problem you are trying to solve?”, “What will change for you or your customer once you have this new capability?”, “Is the benefit measurable in money or time or efficiency?”. We all ask these questions but not too often; we are happy gathering requirements and then executing solutions which are then sub-optimally used. Requirements tend to get unwieldy with all the exception conditions being mapped; in the end it does not solve the original problem but creates new ones.
Winning teams today do not focus on requirements, they ask the questions above and create solutions that solve real business problems or capture real business opportunities. I believe that the future holds a lot of promise to those who follow the new way of thinking and discard the old requirements lead approach. What do you think?
Earlier in the month I was invited to a session by a senior well-known IT Research Associate who advises many global CIOs on tactical and strategic agenda. He is a good story teller and had the audience of 20 odd CIOs spellbound with his anecdotes, examples and occasional taunts which most took sportingly or sheepishly depending on how you interpret the expressions on their faces. His consistent grouse was that while CIOs have done a lot for enterprise productivity, they have neglected IT productivity improvements.
Internal IT under scanner
Tracing through history he illustrated the role IT has played in enterprise process re-engineering and productivity improvements driven by automation, new tools and technologies, mobile enabling the enterprise, and providing time sensitive information in the hands of the decision makers. However during this era the IT team has not demonstrated commensurate improvements; solutions still take as long if not longer than what they did many decades back. He postulated despite progress across the industry, the in-house IT team has lagged behind by a big margin with no major visible improvements.
He went on to compare internal IT teams with the work being done at start-up and tech innovation companies globally. Across comparison parameters on innovation, time, productivity, quality, or sheer volume of work done, IT departments lag behind. He blamed this on mind set, archaic beliefs focused on process compliance to whatever framework the IT team had adopted. ITIL, COBIT, PMI, CMMi were boon in the past; they are the bane now. Agile development methodologies find rare favor with IT.
A reality check
He did not offer any empirical data or prescription, but no one from the audience disagreed. They sat there silently reflecting on their own realities. Post the hour, I sat ruminating over the discourse trying to figure out if this was indeed universal truth; if it was so evident, how is it that no one has thus far talked about it because everyone loves beating up IT and if it was so evident a simplistic comparison, it would have been well searched and figuring in the Top 5 priorities of the CIO and every vendor!
How do we measure IT productivity: Lines of code per day? That no longer seems relevant with the shift from procedural to new way of creating programs. How about number of people to support per 100 compute or network assets, or servers; even that is now irrelevant with virtualization and clouds taking over. Maybe number of locations, or solutions in the IT portfolio, time to respond or time to repair; most of these activities are anyway outsourced with SLAs.
Business value of IT
The baseline has been shifting and IT has adapted well to the change. In linear motion it is easy to measure a shift; in the real world it is a little difficult to quantify. So what efficiency parameters should the CIO use to demonstrate improvements if at all? The CIO dashboard and reports have evolved from technology availability to business value. Productivity gain is not specific any more but interconnected and interdependent. People do not measure activity but outcomes.
IT-influenced results are business agility, competitive differentiators, low cost of operation (Business and IT), and growing revenue faster than market. If the CIO is indeed driving these and well accepted and recognized by the enterprise, does it really matter if the lines of code generated by the IT team is lower than the industry benchmark?
The pitch was passionate enough to keep the audience awake. The speaker and his assistant were animated in professing the virtues of their products. They kept on imploring the CIO to consider their wares instead of the market leader, even though they had only 10% market share in comparison to the leader’s 60%. The CIO who had listened patiently for more than 30 minutes thanked them for the presentation signaling an end to the meeting. The entire sales team was aghast! No questions?
It was a large deal that had every vendor wanting to show their wares with a hope of getting the business. The company had embarked on a major transformation after many years of hibernation. Thus there was a sense of expectation in the market and rightly so since whosoever bagged the order would become the standard supplier for a long time to come. The total business potential was very large commercially as well as from market visibility perspective.
For the vendor having discussed the architecture and the overall strategy with the IT team, the final stage to qualification was expected to be the meeting with the CIO. So the vendor pulled all plugs and brought together the best possible team for the presentation to the final decision maker. They knew that they had a chance of making the cut since the market leader had no presence as yet in this account. The CIO was also known to be fair in his approach and that added to the expectation.
The meeting started well with the setting of expectations and illustration of the approach, product features, open standards, and recent wins across industries. So far so good, but midway something broke and the fervent pitch turned awkward; rather than discussing merits of their product, approach and solution, the sales head started talking about the problems the CIO is likely to face if they selected the leader’s products. Now it was not about what they did but what the leader did not do.
It was not evident to them that they were no longer connected to the audience and had lost. The CIO patiently heard them out through the leader bashing; he proceeded to close the meeting with a polite remark that once the decision was finalized, it would be communicated to everyone who participated in the evaluation. As they left there was a sigh in the room; the CIO and team sat quietly trying to shrug off the negativity. Nothing needed to be said; everyone unanimously agreed that this was curtains.
Why do some people resort to negative selling? Why do they not sell on merit? Don’t they realize that it puts off the environment and has an adverse impact on the outcome? Is it the desperation of targets or month/ quarter/ year end, and the need to sell at any cost (ends justifying the means) that brings to fore such behaviors? Despite losing almost every such deal (I am sure CIOs can see through this clearly), the tendency remains to put down others to show superiority.
I believe that good is not always relative to something else where the other has to be proven not good. This maxim has to be understood for the behavior to change. A product or service can be classified superior by illustrating the benefits or features; let the recipient of the information decide in his/ her frame of reference whether it is a better fit than others. Everyone does not use the same yardstick neither does everyone compare the same products/ services every time. It would be great if our IT vendor community understands this and starts creating better services and products.
As a CIO I would love to do business with such a company, wouldn’t you?
I had an interesting discussion with an executive search professional who called to ascertain interest in a position with her client. Her company is known as one of the premier head hunters that work only on C-level placements and does a good job of that. Her client, a large diversified group, wanted a business IT professional for the position of a CIO, reporting to the Group Chairman. She believed that the position was exclusive and merited attention.
As the discussion progressed, she sought my view on current CIO compensation levels. I pointed her to research done not too long ago by an IT publishing house that provided the range in which CIOs were placed with slices for industry, experience and location. She expressed dismay on the median and the fact that most of the IT leaders titled CIO were underpaid in her opinion in comparison to other CXOs. Her data points were the placements her company had executed.
The CIO-compensations analysed
Ruminating over the discussion I saw a thread on one of the professional social sites on a similar subject. Is CIO compensation in line with other CXOs in the company? Does a company perceive similar value contribution by the CIO? Are there CIOs out there who earn more than their other CXOs? The answers validated the revelation the head hunter had a few days back. Most CIOs are ill positioned and not on par with their peers (my definition: 5% variance is on par); the exception group is miniscule.
What contributes to this situation? Is the gap due to the position being still seen as a service provider and not an equal to say the CMO or the CFO? Does the person in position influence the decision on the monetary value? The industry variance exists though the gap varies. I started scanning data from other countries and found that the story was similar. Exploring age or experience gap, the data revealed that this factor was not relevant.
What is the CIO’s worth to a company? S/he keeps the business humming 24X7 across locations with connectivity, business applications, mobile connectivity, information on demand anytime anywhere, business intelligence and analytics, sales force enablement, supply chain visibility, production planning, customer relationship and engagement management, ecommerce and m-commerce, scheduling and operations of flights, hotels, information security, business continuity, phew! Is all this of any value?
Ask anyone in a company the challenges and chaos or the disruptions when any of the above stops working. The impact varies by company and industry as the elasticity is defined by multiple factors. Antagonists will say all this can be outsourced; yes it can be, however someone has to first set it up before the operations can be given away. Even total outsourcing retains part of the IT team along with the leadership to strategically keep the technology in line with the changing market and needs.
You define your worth
I believe that the value of the CIO is defined by the CIO. The discussion, debate, and engagement of the IT team with stakeholders; articulation of change, success and the value creation with IT systems contributes to the perception of value. Contributions to business decisions add up; taking a position on issues not just limited to IT make a well-rounded business leader and earns respect at the table. How the IT team interacts and presents itself is a reflection of the CIOs leadership.
Will all this bring value commensurate to the effort and monetary reward comparable to others in the enterprise? The suggestions above are a small representation of CIO behaviours that contribute to his/her locus standing. Each person has to find their balance and align it to their reality; don’t try to change the world, change yourself for your own sake. I am saying this from personal experience.
The relationship between the CIO and the CFO has been discussed with adversarial undercurrents as the general perception about the CFO portrays a beanie counter. This is analogous to the CIO remaining the EDP Manager, but the prototype has stayed stuck; in a similar vein where the belief continues that the CIO has not evolved and is still the Chief Technician who fixes Boardroom projectors and the Boss’s email.
Recent time, with the resurgence of social media, has seen the emergence of another debate about the CMO cornering a large proportion of the IT budget. This news which could be based on some data points in a survey in a small geography for a sub-segment of a domain, the conclusions depict the CMO usurping the CIO chair; a real stretch of imagination, but which has a group of CIOs vehemently opposing this purported trend. Some discussion groups even want the CIOs to confront their respective CMOs and assert their power over the IT budget.
The CEO factor examined
So when I had an opportunity to partake in a CEO get together, I was looking forward to clarifying a few assumptions and doubts. If you are wondering what this has got to do with the CFO and the CMO, well along with the CIO, they all typically report to the CEO who is expected to mediate in case there is a conflict within his team. The above presumed conflicts will sooner or later end up for arbitration or follow the general trend where the CIO backs off.
I love interacting with CEOs (including my own CEO); they are the better barometer of IT progress and use within their company than the CIO is. As the primary leader of the enterprise, s/he sets the behavioral norms and culture of the company. Their belief system percolates down the spine of the company influencing processes, process discipline, technology deployment and use, risk behavior and finally the cohesiveness of the Executive Committee that runs the company.
Since I knew most of their CIOs it was easy to create correlations: big manufacturing CEO used social media extensively, his CIO is well known for success; mid-pharma CEO who thought of IT as a cost center had high attrition in IT; a diversified group’s young digital native CEO had the CIO soaring high from success to success. You get the trend; the CEO is the lead indicator of how the job of the CIO is likely to be in a company and where s/he will stand in case of a conflict with other CXOs.
The reporting structure
If you benchmark companies with CIO reporting to CEO versus other CXOs, the comparison set clearly demonstrates the ones with the CEO fare better even when the CEO is not necessarily IT friendly. In the control group which ranges from 30-80% (CIOs reporting to CEO) depending on the geography and industry, the next differentiating factor is the CEOs appreciation, tolerance, averseness or indifference to IT. It is evident that the CIO directly or indirectly influences the success of the CIO.
Should the CIO be insecure about the span of control, budget, or technology disruptions? Most CIOs aren’t but the hype created by various factions would make you believe that the CIO is shivering with fear uncertainty and doubt (FUD factor) on his/her future. Reality being diametrically opposite, I believe that CIOs should stop reacting to rumors and instead start proactive communication on the contributions to different parts of the enterprise in making the CMO or the CFO successful. Let them be at the receiving end for a change!
A recent edit in an IT publication discussed the pitfalls of the CIO going out on the field meeting the end customers of the company’s products or services. It highlighted the fact that most CXOs wanted the CIO to stay away from the customers and not encroach on their territory. The CIO meeting customers was seen as disruptive and a threat to their relationship and the final moment of truth with the consumer. This observation was believed to be consistent across industries as well as size of the company.
A call to the Editor resulted in her portraying the reality she had witnessed on the discussion table that included some heavy weight CIOs. They were tentative in their approach to reaching out to customers; this was not viewed kindly with heavy brick-walling. A casual interaction was fine, but not continued engagement that may result in a different reality for the sales / marketing teams. Of course, there were a few outlier CIOs who did systemically meet the customers and shared insights with their teams.
My reality being different from the majority, I decided to chat up with some CXOs to determine if reality was indeed that grim. I picked a few high-touch industries like retail, banking and airlines, and added some low touch ones like pharmaceuticals and FMCG where the end consumer is largely faceless. Then I started searching through the good old visiting card rolodex, my connections on social media and professional networking sites; finally adding some with help from industry bodies.
I had some apprehension if I will get candid responses, so I decided to use the research envelope which does normally get open answers; you know researchers are perceived as non-threatening since in a statistical model, there is no identity. The modus operandi worked well and my research was successful in capturing reality with high fidelity. The correlation to industry or size of company was not decisive, the general trend was however quite evident.
Marketing and Sales have over the last few years faced uncertainty due to the global economic uncertainty and the impact it has had on consumer sentiment. Corporate as well as individual spending has seen a general holding back. Do we really need to spend? Do I really need the latest gadget? Such decision points have resulted in pressure that has everyone looking inward more than outward. Natural reaction has been to hold on to the fragile relationships. What if the discussion turned away the customer? What do you know about customers anyway?
Mr CIO, you have no business to …!
One of them quite paranoid went on to state that IT has no business prying into relationships; he had advised his team to keep everyone at bay like the pirates; auditors, information security, anyone who asked for data was turned away. Even the BI reporting was curtailed lest it be used by someone to create different conclusions. The company in question was struggling for growth though doing better than some of their competitors. In the high growth era, they were the leaders, now that appeared to be chapters in a history textbook.
Can the CIO change this behavior? Being an optimist, I would say, probably yes! Is it worth the effort? Many would say, certainly not! And I tend to agree with the collective wisdom though with a caveat. I believe that CIOs are always at the short end of disruption; so they should not back off in the face of this push back but continue the dialogue while getting others behind the cause. Different perspectives have always created new opportunities. After all, you cannot expect different results if you continued doing the same thing over and over again. I have lived by this maxim and I am still alive.
The IT industry has many types of vendors; some focusing on niche solutions, some specializing in specific technologies or domains, some who offer a menu of products / services ranging from infrastructure to applications, and then there are large diversified companies who do everything from consulting to implementation of technology solutions or packages backed by support services in a local, offshore or multi-location model. The big guys manage all kinds of requirements and bring to the discussion table a comprehensive long-term engagement model.
Different vendors set different expectations on what they can deliver; the niche providers do not promise a breadth of services, they stay focused on their expertise. The big ones claim to have expertise across the legacy to contemporary and cutting edge; they have industry practices and business consultants who profess incremental to transformational change capabilities. You name it we can do it; even if you cannot put a name to it, we will find a way to do it!
Complexities in governance
The large one-stop-shop engagements typically begin with setting of scope and expectations on delivery, timelines, and quality of service, rewards, penalties, force majeure, arbitration, cost, escalations and a lot more. The larger the scope, or the longer the time period of the contract, the governance becomes complex. We know that Total or Strategic outsourcing can cover everything; in recent times though the number of such deals has been dwindling.
So it was an interesting debate when a few CEOs on a panel berated the one-stop-shop companies giving it a new twist. Consider you wanting to reach a far-far away destination and the only option is to go by bus. Every bus gets you there, some are slower than others, some offer many comforts through the journey; the cheaper ones just get you there. Depending on what you can afford, there are many options to choose from. Caveat is once you have bought a ticket, a change is difficult and painful.
When someone advertises ‘one-stop-shop’, the conventional understanding is that I get from where I am to the final destination with no stops with the advertised and agreed comfort. Reality as we know is not always as advertised. A CEO remarked on his journey with one of the global biggies; he signed up for a long journey wanting to focus on his business. Very quickly he was on the discussion table with the bus driver, conductor and the entire fleet management company.
Why is my journey so excruciatingly slow? Why is the transformation promised not happening? When will I see any impact to my employees, stakeholders, customers, or for that matter any efficiency to business operations? Whatever happened to the pre-sales promises made by the various function heads of your company on various domains and technologies? Pat came the answer, “we are a one-stop-shop company; we go one stop at a time. This is what we promised; we did have a driver change and a breakdown; that is part of the contract. We meet defined service levels.”
Devil lies in the detail
Both are right in their frame of reference; so where is the problem? I believe that any such engagement should have common definition of reference points with clear understanding of step-by-step process, impact and governance. Otherwise the semantics of the one-stop-shop can be painful for everyone involved, the deliverer and the recipient. The bus is still moving but not in the way that makes the journey a pleasure. CIOs will be at the receiving end if there are such gaps.
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 as 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.
Twist in the tale
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 (three-letter acronym), 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.
What’s in a name?
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 behavior 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.
Last year was a very difficult year for most software companies with slowdown in new license 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 license 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 centers, 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 a user identity or a database, or an instance of the application, it needed to be licensed. Office automation and other fringe app vendors joined the fray and added to the already harried CIOs’ blood pressure.
No debate that license compliance is non-negotiable; licenses 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 set up 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.
The ways of the vendors
Some also allow test and development instances to be set up; 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 licenses 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!
Killing with the fine print
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 license 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 behavior; the management takes a not-so-kind view but goes ahead with the devil’s choice.
A global issue?
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.