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.

Management maladies: Committees

In all my 20+ years in the private industry I've never seen a committee in the context of project. Two committees I was a part of, were both management committees addressing organization level matters - and both were utterly ineffective.

Quite interestingly, there is no dearth of committees in governments. It seems quite the normal way of doing things. The results are not surprising. Rather than naming specific committees and launching into the often-employed critical tone, let me explore the possibilities of where and when committees might be suitable.

In order to bring about some clarity, let me deliberately reclassify the roles (perhaps to the chagrin of management purists) of people.

Those who do things; and those who don't

In any project organization, there are some whose job it is, to do things. To my mind, all others can be clubbed under overheads.

As a general principle if we are to get anything done at all, the doers in any project must far outnumber the overheads.

Further, the facilitators must not get into the critical path of the doers - and at a minimum, allow the doers to do their job - though some might argue saying they should also monitor and facilitate.

Keeping these principles in mind, I would come up with the following broad guidelines:

1. There should be no committees of doers. Doers and groups/teams of doers must be focused on the deliverables. 
2. Decisions within a doer's domain must be taken by the doer, in his/her individual professional capacity. If a decision requires consultation, the doer can surely consult others and then decide. 
3. An individual overhead may take the responsibility of taking decisions for the doers/teams reporting to him/her. As in the earlier case, if a decision requires consultation, by all means he/she can consult others and then decide. 
4. Someone in an overhead's garb, unable to take a decision in their domain is unsuitable for that job -- and should be replaced. Resorting to a committee on this account (of inability to take / own-up a decision) is a big no-no, IMHO.
5. There should be no committees of the overheads either.
6. Where a project involved multiple independent stakeholders (such as multiple departments), a steering committee (perhaps the one and only committee justifiable) is necessary - if only to ensure the representation of each stakeholder's interest. Though they are clearly not doers, let us treat this committee as different from the overheads.
7. Since members of the steering committee are likely to be somewhat removed from the operational details of the project, they will need input from others (either overheads or doers). So each committee member should ensure that they have the necessary input from within the project, by deploying their own overheads / doers in appropriate roles in the project, without resorting to further lower-level committees.
8. A steering committee should not directly provide operational fixes. Instead, if an operational issue is escalated to this level - they must examine whether they have missed out filling a key role in the project team, especially at the overhead level. They must then proceed to fix that problem and then ask the correct person to do the operational fix.
9. Committees/sub-committees under a committee should be treated as compounding sins of the management kind.
   e.g., technical committees under the implementation committees that report to empowered committees. 
10. A committee in any other name should also be treated as a committee.

I don't know whether this is enough. But I guess it is a starting point. 

Now for the reality. 

As mentioned in my earlier blog (the many management maladies), competency in any government department tends to be concentrated at the top - generally at the secretary / principal secretary level. By virtue of their rank, they tend to be in the steering committee. This skewed competency concentration at the top means that nearly all decisions (operational or otherwise) tend to get pushed up all the way up. Thereafter, whether it is provision of some input or contention of a stakeholder interest -- (as often as not) tends to be an exercise in individual-wisdom, seniority and protocol - instead of competence and sanity.

However, if we start shedding committees, there might be hope still.