True Story No31


Define the risk = No risk (written in 2002)

In the early 80s when a nuclear holocaust was still a distinct possibility our lads at the Ministry of Defence were asked to come up with a communications system which would permit the fragmented elements of law and order, in the aftermath of a projected missile attack on the UK, to have a chat and work out what on earth to do next.

In those days there was a tug of war in Government circles, between the people trying to cut defence spending and those trying to keep in full employment and carry on building their little empires until their pensions cut in.

The compromise was an understanding between the Government Departments responsible for procurement and those footing the bills.

The Exchequer would allow things to basically carry on as before but only if Industry was brought to heel and wasn't allowed to charge what they thought a fair price for a job.

So out went "Cost Plus" which was a method of paying for military hardware when the buyer didn't really know what he wanted and Industry really didn't know how much to charge.

I nearly said the "user" but "buyer" is better because in the days of the cold war the user often didn't get a look in.

The Procurement Executive would tell the user what he was getting and maybe the latter would have his say a bit later when things got firmed up.

Numbers of people in the Ministry of Defence grew which was a good thing for them because responsibilities increased, grades got better, and of course pay was also rather good. Not quite as good as in Industry but then again the pensions were better and it was a job for life and if you played your cards right you might even end up with a square of carpet under your desk and lesser mortals calling you "Sir".

In Industry things were equally rosy.

Projects were lucrative, as you might expect when you were paid a profit on every penny you spent.

Teams grew in strength, management grew to cope with increasing numbers of staff, grades and salaries grew and everyone was happy.

Some people in Industry even managed to make extra money by giving away bits of large contracts to other people.

Of course the Ministry footed the bill by paying the bottom line figures but individuals in Industry benefited by claiming even more responsibility and even more pay.

Sometimes jobs were given away to other companies that were actually the same company.. a sleight of hand.

This was done by creating a second company which, in reality headed up to the "big" boss of the first one.

The big boss then had two companies working on the same project, the second working for the first.

Of course this was an excellent idea because the second company could charge a profit on its work which it would pass on to the first.

The first would then charge a profit on the payments to the second and things looked even rosier.

A nominal 10% profit was magically converted to… not 20% but 21%.

Neat eh!

You may think that the two companies were in different towns?

No the two companies were co-located.. in fact members of the two companies often sat side by side.

A defence company could have virtually any number of indirect support staff as their salaries were included in the "overhead" and the Ministry paid this overhead when they paid for the direct staff.

Anyway all that came to an end, and in the 80s, Industry had to think up new ways of making money.

Back to the main story…in the new scenario the Procurement Executive, who didn't really know much about the real cost of things and even less on how difficult things were to actually make, would tell Industry what they wanted for their customers.. the end user, and also how much they were prepared to pay and for how long they were prepared to wait.

You can't blame them really because in turn they were being told how much there would be in the kitty and the end users were always clamouring for their new toys yesterday.

Often it wasn't cut and dried.

First there had to be a stage which may be called a "Definition Study".

This was the phase where different companies would be asked to make a proposal and quote a fixed price for a particular requirement, and so as not to waste too much time, during this stage PE would let the companies into the secret of how much money was in the coffers.

Not in cast iron terms of course and in such a way that everyone didn't ask for the same amount.

And of course it was invariably much less than the job, if done properly, was worth!

The overall timescale would also be imparted but this tended to shrink because the overall timescale often included the definition phase, subsequent pondering and to-ing and fro-ing.

The longer the time taken to agree a contract the shorter the time left to actually make the "toys".

Of course during negotiations the successful contractor felt obliged to agree with the shrinking timescale otherwise he may not get the job.

Part of the important new understanding between Government Departments was that the lowest price would net the job.

Providing all the requirements were said to be met in the proposal.. so be it.

There was often a separate section in a proposal, a form stating each individual requirement and against each a box to be filled in by the tenderer.

No tick in the box…no contract and the most important boxes were next to the delivery timescales.

So there it is.

A recipe for failure.

Industry would have to supply something for a sum basically determined in advance by the "political" Government in a timescale, which may have looked half reasonable when the money was allocated by the Treasury, but by the time the contract was let was often ludicrous.

Once a contract had been negotiated, Industry tried to get more money by any sort of device it could dream up, whereas PE on the other hand, would have to sort out any failing in their requirement by negotiating changes for no extra money and no timescale over-run.

A lot of effort was therefore expended, not on trying to make the product, but arguing over the price and delivery dates.

A dodgy specification and a dodgy timescale would get worse and corners were often cut, risks escalated, and projects would be doomed to failure.

If only Industry could have specified exactly what they could do, at what cost and in what timescale, things might have been better.

As it was, the engineers responsible for the design and development, were not asked when they could deliver but were told how long they had.

Managers were forced not so much to control the technical aspects but to firefight cost and delivery slippages.

In support of these ways of working PE would often talk about risk assessment.

This had, of necessity to be based on their previous experience, the results of a separate study by someone unconnected with the implementation, or on what someone had read somewhere in a book!

I have even seen a stupid timescale made shorter by asking Industry to, "identify a risk", "solve it", in theory of course, and "add a bit on the price to cover it".

In most contracts involving state of the art design and development the risks that really come into play are as a result of the unknown and as they are unknown can't possibly be quantified!

I quote from a specific MoD contract let in the mid 80s.

"The MoD is able to go directly from feasibility study to procurement by incorporating definition of the risk content of the project, which normally is the subject of project definition, in the specification of the feasibility study"

This doublespeak was clearly aimed to placate or to bring about a sense of confidence in Government circles.

The said project was let, ran into trouble, was cancelled, re-bid, and re-let to the same company.

The project then ran into trouble again, was cancelled, re-bid, and re-let, again to the same company.

It is now still proceeding in one form or another after no less than 15 years after it was initially let anticipating a two year in-service date.

All the user's staff trained to use the system have long since retired!

Why was all this?

Because although PE had correctly identified that the majority of the hardware to be employed was already established, the software to make it all work hadn't even been specified.

Most large projects needing software, especially "real time" software will fail if adequate time isn't allocated to its production and testing.

The less realistic the timescale the more pressure on the programmers and more are the mistakes that will be made!

Return to stories page

or.. Return to HDRS