Government outsourcing ailments in IT

Governments outsource IT / IT-related projects for three broad reasons:

1. Risk taking ability, work ethic, ability to deliver results
2. Superior technical skills
3. Work needs more people than the government has

It is surprising then, that having set out to outsource, the government procurement processes are tuned to kill two of the three reasons for outsourcing. Here is how:

• By laying down stringent (often one-sided) conditions, penalties and an overall attitude of "we don't trust you or your work ethic"; the bidders are often scared stiff into risk aversion.
• By insisting that they work to government procedures and work-style - convert the vendor's employees to government work ethic
• By insisting that vendor's technical work be reviewed and evaluated by internal / NIC people (see #2 above!)
• By weighing most projects towards the lowest-bidder. Even where QCBS is touted as the method, pseudo experts and lame duck consultants water it down to elaborate tabulations in the name of objectivity.
• By causing project delays with interminable paper work, refusing to accept responsibility for the delays and needlessly harassing vendors for payments.

The private sector, over the years seems to have adapted well. Effectively killing their own competencies. 

• Bid management teams are nearly exclusively focused on "winning the deal" - at any cost. Often this requires convenient interpretations of the requirements and taking short cuts that can "later be rationalized". As a result, #1 is left out in the lurch. Project outcomes are sacrificed at the altar of "win the bid first". 
• Blame the government and its procedures for all their compromises. Surely the government isn't innocent. But then, what about business ethics?
• Experts cost money. Good tools, technologies and methods cost money. Money that wasn't included in the bid. 

All this leaves only one reason to outsource. Not work ethic. Not result orientation. Not technical competencies. "#3: Work needs more people than the government has". Situation has deteriorated so much that it is not easy to recover from this downward spiral.

To get out of this quagmire, perhaps we could try:

Private sector reform its bid management approach. Bid to compete as much on quality as on price. 
Government stop trivializing technical evaluation. Hire experts and find ways to give weight to their opinion.

One last point for emphasis. Hundreds of technical evaluation criteria achieve only one thing. Unsurprisingly, that is not "best technical bid". They ensure that bids with glaring weaknesses in several areas can still get through - as long as they bid "some standard stuff". One would think that such an obvious possibility would've been apparent to all.

I would like to hear from you all - on what you think is wrong; and how you think they can be fixed.

Are software products overpriced?

It seems to me that a lot of software - especially the non-shrink-wrapped variety, has become unbelievably and unjustifiably pricey. As already alleged in a previous article (Need for massive reforms in procurement), we in the consulting industry have brought this upon our clients.

Let me dive into a ready example. Here is a government client who wants to implement an end-to-end solution for all offices across the state. Let us look at the application software component - with a reasonable obfuscation of particulars without missing my point.

(currency: INR)
1. Reasonable estimates by several *people and organizations* for bespoke development of the s/w: way below 10 cr
2. Estimates of a software product (let us call it COTS #1) with 30% customization estimate: ~50cr
3. Estimates of another software product (say, COTS #2) with 50% customization estimate: ~50cr
(okay, I have changed the numbers sufficiently to obfuscate - while still staying well within the estimate range)

Assuming all of us are quite well-versed with the buy-vs-build debates, how should the client go about deciding? Let us make some reasonable assumptions and some gross simplifications so that we can make a half-decent (yes, only half-decent so that we need not lock horns in a perfect-the-evaluation-model debate, missing the point) comparative analysis.

First off let us look at premium-over-cost model. Next we can look at the value-pricing model.
Assumption/Approximation #1: Customization efforts / costs of COTS for the purpose of evaluation:
30% customization => COTS #1 is shaving off 70% of bespoke development schedule => 70% of bespoke-dev-cost can be assigned to COTS as *payable-premium* => 70% of 10cr = 7cr.
Similarly, 50% customization => 5cr payable premium for COTS #2.

Assumption/Approximation #2: Annual maintenance costs for both bespoke (bug fixing & change management) and COTS products (updates, bug fixing & support) are both at 22% per annum. Let us assume a 5 year operational period to calculate TCO.

Assumption/Approximation #3: Since the bespoke software gives the IPR over the software to the government, and the government can (and will) make it available to all other government entities free of cost there is a benefit associated with it. Let us assume that only one entity will reuse the IPR and that this (second) entity will need 30% customization - so the benefit (of bespoke software) may be quantified as 70% of 10cr = 7cr.

Assumption/Approximation #4: COTS means higher quality & robustness. Let us assume that the bespoke developer will need to spend 50% more effort (I know, we are out on a limb here, but we need to begin somewhere) to reach a comparable state, bespoke software's *real* cost should be considered 50% higher => 5cr

Now for the premium-over-cost model of comparison:
Bespoke software: 10cr + 5yrs x 2.2cr/a (#2) + 5cr (#4) - 7cr (#3) = 19cr 5yr TCO
COTS #1: 50cr + 5yrs x 11cr/a (#2) - 7cr (#1) = 98cr 5yr TCO
COTS #2: 50cr + 5yrs x 11cr/a (#2) - 5cr (#1) = 100cr 5yr TCO

Clearly, COTS are a rip-off. How can I ever recommend this to a client, without going over to the value-pricing arguments?

So let us go over to the value-pricing approach with equally half-decent assumptions:
Client has a revenue of 5000cr/a. This is at risk, if we go with "lower quality" bespoke software; apart from "lost time".
Assumption #5: Revenue leaks better plugged by COTS, say at 1% better than bespoke. => 50cr value.
Assumption #6: Bespoke software by virtue of being less robust, lower quality, etc., impacts productivity to the tune of 10% (as compared to COTS) => 500cr value.

Since the pricing of COTS is only a small fraction of this (50+500 = 550cr vs 50cr), it is justifiable, you say? I might agree with this, if I were not to consider:
a) To another client department that has a revenue of only 55cr/a, would the software OEM offer the same software at the same value pricing ratio? i.e., at 5.5cr? To yet another, where there is no revenue at all (a cost center), would this be offered at close to zero price? I don't think so.
b) The 30% - 50% customization is done by equally good/bad developers as the bespoke software; leading to similar quality / robustness issues. Not to mention 30% customization schedules often run pretty close to 100% bespoke schedules (not on plan documents in proposals, but in reality when executing).

Overall, I believe software OEMs are taking my clients for a ride. Not just with application software; similar ripoffs are occurring with other software too (e.g., Cloud solutions, Storage solutions, ...).

Therefore, my recommendations to my clients: By all means, consider bespoke software favorably and manage the risks (including paying for it) with top-quality project managers. Where you can, use open source software (no, not necessarily free-of-cost) and ask bespoke developers to develop on open source platforms; pay for the support and eco-system costs.

Take COTS only if the TCO with premium-over-cost models are comparable to alternatives. After all, COTS are supposed to be *cheaper* than bespoke. If customization is only 30% effort, then cost to OEM is only 30%; what are you paying the 400% premium for? The "cost of building and maintaining such high quality products"? Really? So why the 22% annual maintenance costs then?

Need for massive reforms in procurement

In all my engagements with the Government, one factor remains constant. The government needs help in procurement of IT Solutions. Depending on the stage of the project and the officers involved, the nature of help they request from me varies from mere "rubber-stamping" to "do-everything-from-conceptualization-to-program-management".

I began my journey in this area with a conviction that the government is the villain from whom the private players need protection. This, in a way is still a truth. Every government body I've worked with is guilty of

• utter disregard to the project schedule - adversely impacting project plans right from the word "go"; leading to inordinate schedule delays and cost overruns;
• inexcusable delays in processing payments of vendors; and
• not discharging their responsibilities diligently even in utterly clear situations like taking delivery of products / services - thereby frustrating vendors in no small way.

However, the vendors are not angels either. Their crimes (in a figurative sense of the word) range from "minimalistic interpretations of requirements" to "brazen undermining of customer interests" and every shade of gray in between - arising from sheer profiteering, lack of competence, risk aversion at the cost of the customer, and so on. In this, the consulting community is as guilty as is the SI community. There are loud whispers of unholy alliances between consultants and OEMs. I hang my head in shame for being a part of such an eco-system.

Due to the increasing emphasis on end-to-end solutions procurement, it has become a field day for 

• consultants (cut and paste RFPs at exorbitant price-tags to the customer rule the roost), 
• large systems suppliers (thriving sales of consultant-sponsored over-sized high-end systems), 
• software product vendors (sale of product licenses and grossly overpriced annual-maintenance charges that would otherwise struggle in any cost-justification)

I haven't included large System Integrators in this list because they are as much victims in this scenario as they are perpetrators. On one hand they bear the brunt of the Government's "crimes" - and in return, they try their best to pass on the costs to the hardware and software OEMs. 

As a result of all this, the Government eventually ends up paying an exorbitant price for something that doesn't deserve a fraction of the price-tag. Since it is all coming from the tax-payers, no one cares.

To compensate for this the government only responds by increasing the eGov budgets - thus, enriching the vendors at the cost of the citizens. This is the reason why we need massive reforms in eGov procurements. 

Consultants must stop playing to large budgets and OEM partner interests. Instead of playing on the customers' fears  they should show to the customer, lower cost alternatives that may cause some uncertainty in SLAs, but are not significantly inferior. They must challenge SIs to deliver value and OEMs to rationalize their pricing structures.

It may be possible a fill whole book if we are to explore all the issues involved. However, I will focus on one area that is firmly in the hands of those who write the RFPs and do the technical evaluations of large projects. 

On a concrete note, I propose that:

1. Clear benchmarking and sizing exercises must precede system configurations and put an end to hidden OEM-sponsored sizing;
2. Include open source alternatives; ensure these are done not just to satisfy technologists, but to arrive at clearly understandable cost-benefit structures;
3. Instead of overplaying on fears, propose to the customer, how the downsides of lower-cost alternatives may be compensated - and what the cost (of such compensating measures) would be;
4. Convert as many components into commodity components; encourage purchase of commodity components (hardware and software); and
5. Demand that all non-commodity and premium-feature components be declared openly and cost-justified.

I don't know where it will lead, but it will surely be a good beginning to do these. I don't claim that it will rid us of all evils. But it will put a check on one area that we (in the consulting community) have reasonable control of.

If we don't help our customers bring in these reforms, we will all lose our credibility. That much is certain.