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..
..by 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!
