Indian Defence Review

Rationalisation

Two logical requirements need to be rationalised. The first is the principle of the “Lowest Tender”. The second is the principle that “The Customer is Boss”.

The Lowest Tender Problem

The quantum of preference would need to be kept flexible to attract reputable private sector companies to the defence sector.

A private sector company will participate in defence production only if it can make profits. It has this responsibility to its shareholders.

Since public money is involved, tenders have to be invited. Contracts for initial development are awarded to the lowest tender. After development is completed, specifications and drawings are frozen. Tenders are invited for bulk production. Profits are made mainly in bulk production and not during initial development.

Until recently, the position was that should the company that undertook the initial development not be the lowest tender for bulk production and the contract was awarded to another company, the developer company was neither assured reimbursement of a portion of development cost nor assured of a portion of the bulk production order. The first step has been taken to rationalise this vexed issue. Preference is now given to companies who were involved in the development process. The quantum of preference would need to be kept flexible to attract reputable private sector companies to the defence sector.

The “Customer is Boss” Problem

The Army, Navy and Air Force have clearly established responsibilities. Prima facie, they know best what equipment is “acceptable” and what is not.

Self-reliance, indigenous development, transfer of technology, joint ventures and offsets are not their primary concerns. When their force levels decline and indigenous projects are delayed, they resort to imports wherein

The “acceptability” benchmark is taken care of by the Army, Navy and Air Force being fully involved in the competitive evaluations and the final negotiations.

A private sector company will participate in defence production only if it can make profits. It has this responsibility to its shareholders.

In indigenous projects however, the ‘Customer is Boss’ problem takes a different twist. The Army, Navy and Air Force lay down the Staff Requirements and expect, rightly, that the end product will meet these requirements. This rarely happens in major projects because a number of sub-contractors and original equipment manufacturers (OEMs) have their own problems.

Cumulatively, this merry-go-round affects operational readiness, undermines confidence in indigenous capability and defeats self-reliance.5

In one form or another, the same dilemma affects even those countries that have well developed military-industrial complexes.

INNOVATIONS

Replacing Staff “Requirements” by “Staff Desirements”

It is interesting to examine the relevance of a reform initiated in 2002 of the Pentagon’s weapon acquisition process, which reportedly “takes two decades to produce a finished product”.6 Under their old procedure, “a weapon did not enter production until 100 percent of the requirement was met”. The reform aimed to field new systems in as little as five to seven years. This was to be achieved through two interlinked concepts – Evolutionary Acquisition and Spiral Development.

Evolutionary Acquisition

In simple terms, this called for the Services to accept a weapon if it met over half the original staff requirement. And thereafter, to improve and upgrade the weapon as it aged instead of creating a new weapon system. Successive upgrades would aim to fulfill the original staff requirement.

Defence staff officers are trained to assess future threats and formulate staff requirements for weapons that would be able to cope with those threats. Staff requirements do not make allowance for the limitations of indigenous capability or changes in technology.

The idea of upgrades, per se, is not new. The British practice of designating systems as Mark 1, Mark 2, Mark 3, and the American practice of designating missiles as Block 1, Block 2, Block 3 have been there for decades.

The new idea was for the services to consciously accept into service a new weapon that is known to be short of the staff requirements by, say, 30% to 40% and accept that the weapon would gradually evolve as it is updated. In short, it is an incremental approach to delivering new weapon technology.

Spiral Development

Traditionally, a staff requirement defines, as precisely as possible, the weapon/system that is required and the time frame. Spiral development is a method borrowed from the software industry. Its underlying principle is the need for rapid adaptability to change. If during development, the technological risk of rigidly adhering to a staff requirement is likely to negate its timely fulfillment, the development organisation should have the flexibility to redesign what the staff requirement seeks to accomplish.