OMG, I saw a Data Center

Last week one of the global IT biggies invited a bunch of CIOs to their R&D Centre with the defined agenda being a discussion on future trends and movements in their technologies; the idea was to get some early traction with old and potential customers and field testing that helps fine tune a product. Apart from all this were the good old peer networking and some high spirits if you know what I mean. So I was enticed enough to join the group to give away a weekend in the name of learning and networking.

Like all such gatherings it was a good start with key leaders and guys oozing tech from their ears talking about new disruptive technologies are coming our way in the next 2-4 years. They held sway in the graveyard sessions post lunch with sleep overpowering only the infirm or the bored indifferent which did not matter. Most cynical CIOs on the wrong side of forty acknowledged the prowess and the future opportunity.  Good things don’t last and this one too didn’t.

After the first two sessions started the mundane, the irrelevant and the hard sell; data centre density, cooling, and power consumption. Virtualization and private cloud are good, a higher virtualization ratio even better, but 20K VMs in a rack ? Why do I need 20K virtual servers ? The nail in the wall was when someone decided it’s a good idea to teach CIOs how to configure a VM and then move it across racks with no downtime. I am not sure if CIOs want to be doing that or enterprises want high cost CIOs to do that !

I mean does a CIO teach the technology architect the finer nuances of VM management ? To rub salt into the wounds, they extended the session over the coffee break to cover private cloud extension to the public cloud. Now I am sure that my server admin would be kicked by this demo, none of the CIOs in the room were. They expressed their displeasure in no uncertain terms, some decided to leave the premises as soon as the break was declared closed. I asked the presenter if their CIO knew how to ! Patience too has its limits…

The climax was waiting for the following day; a visit to the R&D facility ! We all got into a bus, arrived at the big building, signed in with sobriety and were taken to the show. We entered a room with biometric authentication to be faced with rows and rows of racks with cables dangling from some. Proudly the scientist pointed to one of the racks and started talking about why it was different and the innovation that went into making the hardware inside and why we should immediately order it.

I could not remember the last time I had visited a data centre (even my own); digging deep into memory it dawned that it was more than a decade back. I whispered to the CIO next to me and he too reminisced a long time back. A few others had been to their outsourced or co-located data centres when they had signed the deal. I wished my infrastructure head was present; maybe he would have appreciated the significance. To us the CIOs it was a lost experience, we did not share the enthusiasm.

Does or should the data centre matter to the CIO ? The vehement answer would be yes from many. Then what about the cloud ? Have you visited the Google or Amazon or Salesforce.com data centre ? Do you know when you buy SaaS where it is delivered from ? I believe that we need to come out of this obsession; the vendors need to start defocusing the data centre and start engaging on business outcomes. Yes the data centre makes the IT run, but to pick a line from Nicholas Carr, the data centre does not matter anymore !

Out of scope or scope creep

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 ?

Part 3 was added later

Requirement gathering

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 fulfils 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.

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. 80% success was deemed good and that kept everyone happy.

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 ?

“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 ?

Comments and feedback lead to Part 2 and Part 3 !

IT productivity improvement

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.

Tracing through history he illustrated the role IT has played in enterprise process reengineering 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 favour with IT.

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.

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), 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 ? 

Negative Selling

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 signalling 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 closed 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 behaviour 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 ?