The QoS Factor

Analysts say that the only constant in the world of IT is

change. They are partially correct. In fact, there are two constants in the

world of IT. The second constant is perpetual dissatisfaction with the Quality

of Service (QoS) offered by IT vendors. Most users are constantly disgusted with

the service they receive–be it from an assembler or a leading multinational.

Which is surprising, as poor service is normally the hallmark of sectors that

suffer from too little competition. The IT market, on the other hand, is

probably the most competitive business in the world. Strangely enough, this

paradox arises because of too much competition in IT.

The IT marketplace is characterized by two things: (1)

Relatively low barriers to entry and (2) Very fast commoditization of products

and services. The low entry barriers create a situation where dozens of new

companies are set up every day. Potential entrepreneurs see a huge market and

start ventures at the drop of a hat. The mindset seems to be ‘so what if there’s

competition. We will offer better quality/customer care/products, etc. This

brings us to the second point above–no matter what you offer it’ill soon

become a commodity. Most IT companies soon reach a point where they no longer

have a USP to offer. They become one of the dozens of similar companies. The

only way to get a customer seems to be to offer the moon where service is

concerned.

Adding fuel to the fire is the fact that the average buyer

has very little idea of the product that he is buying. Being unable to assess

the technical aspects of the situation the buyer starts playing one supplier

against the other on service parameters. Sellers soon realize that they are in

no position to refuse. For instance, if the customer insists on a response time

of four hours then the only thing for the seller to do is to say yes, and for

the customer to do is to hope for the best.

The seller has little fear of the repercussions of making a

wild claim. In most cases he has no way of calculating what his response time is

anyway. The response time depends on a host of parameters and a vendor has

little control over most of them. An assembler may employ 15 people, handle 100

sites, and be able to claim a response time of six hours for hardware

breakdowns. His future response time will depend on what his site to personnel

ratio is at that point of time. Even more dramatic is the case of a software

developer promising that an application will have a response time of less than a

minute. Designing applications to predefined response times is a very demanding

task and can double the cost of an application. But the developer thinks it’s

better to mislead the customer on a key parameter and gain the order rather than

be honest and lose the order.

One way out of this mess is to have the vendor sign a Service

Level Agreement (SLA). A SLA spells out parameters on which service will be

measured and the criteria that will be used to decide deficiency in service.

Unfortunately, this route is available only to large organizations because

drafting SLA’s takes a long time and they make sense when the purchase is

hefty. Enforcing an SLA is equally difficult because one has to continuously

measure and monitor the parameters that define the QoS. There is also the risk

of using the wrong parameter. For instance, I might define response time to

hardware failure as a parameter and measure this parameter by noting the time

between the time of complaint and the arrival of a technician. It’s another

matter altogether that the technician might be totally incompetent and unable to

fix the problem. In a hypothetical case the vendor might conform to every clause

in the SLA and yet provide terrible QoS.

The only real fix to the problem is to educate both buyers

and sellers. Buyers must become more capable of separating the wheat from the

chaff and concentrating on the basics. Sellers must realize that nonsensical

claims hurt them in the long run. Sellers should not buckle down and give-in to

the absurd demands of the customer. Only then will the QoS improve.

The bottom line One can but hope that the IT industry’s QoS

will improve as the industry matures.

Gautama Ahuja, a

contributing editor of PC Quest, runs a turnkey software development company,

AHC Infotek, in Delhi