Elsevier UK Jobcode:RTF Chapter:CH15-H8304 22-3-2007 5:13p.m. Page:278 Trimsize:165×234MM
Fonts used:Ocean Sans & Sabon Margins:Top:42pt Gutter:54pt Font Size:10/12 Text Width:30p6 Depth:47 Lines
278 Risk management technology in financial services
Every Thursday Mullaly painstakingly took his executives through every line of
He maintained this ritual throughout his tenure, so that he always knew exactly
what was going on.
In terms of the policy of direct control, which he instituted, Alan Mullaly was
regarded by his colleagues as an engineer’s engineer, basing his decisions on hard
data rather than vague hunches. And he was not averse to tough decisions, killing off
the Sonic Cruiser plane, just 18 months after it was unveiled in a blaze of publicity.
Airlines told Mullaly they wanted economy and comfort, not more speed,
Therefore, he went back to the drawing board to produce a plane to their liking.
On a smaller scale, specific to the nature of the project, this is what a major design
review should be doing. As we have seen in Chapter 14 in connection with three-year
long software development projects which cost dearly and go stray, there are different
related and unrelated reasons why a formerly valuable project no longer makes sense.
A competitor may have decreamed the market,
Customer requirements might have changed,
New government regulations made part of the project obsolete,
Embedded costs may not have left enough margin for profits, or
The company’s strategy may have shifted focus, and the way the project goes no
longer makes sense.
In conclusion, design reviews help not only to put a project straight but also to
kill it if it overruns its budget, is behind schedule or does not meet quality and
competitiveness novelty guidelines. It is much better to do away with a project when
it has consumed 10 per cent of its budget than to let it run without supervision and
let it fail at the end, with great loss of time, misuse of human resources and all or
most of the budget already spent to no effect.
15.2 Examples with design reviews of IT projects
The first basic principle is that the development life cycle of IT application software
projects should be short. For relatively simple projects and prototypes, development
and testing time must range from a few hours to a couple of weeks. For big ones
it might take up to three months, depending on a number of factors (more on this
These goals are doable if we employ highly skilled rocket scientists and high
productivity programmers, and if we use the best available tools. In the New York
subsidiary of one of the big banks at which I was consultant, typically a client called
at 4:30 pm saying: ‘I have $500 million to invest, make me an offer tomorrow at
9:30 am.’ This deadline had to be met, or the deal was lost.
Additionally, big buck clients don’t want just any offer. They always ask for a
novel derivative instrument, with high return and high risk. And they call up four or