Elsevier UK Jobcode:RTF Chapter:CH14-H8304 23-3-2007 12:27p.m. Page:263 Trimsize:165×234MM
Fonts used:Ocean Sans & Sabon Margins:Top:42pt Gutter:54pt Font Size:10/12 Text Width:30p6 Depth:47 Lines
Project management for IT and risk control 263
UNRESOLVED
PROBLEMS
TIME
COMPLETION
DATE
Figure 14.2 Project status chart plotting unresolved problems and issues
over time
changes in the ocean, which was responsible for hurricanes. The AMO was widely
accepted as a rule in the hurricane business.
But two influential papers published in 2005 challenged the ‘obvious’ by arguing
otherwise. One, by Peter Webster, Judith Curry and colleagues, said the data they
examined supported the idea that there was a long-term increase in the number
of category 4 and 5 intense hurricanes. The other, by Kerry Emanuel, professor of
tropical meteorology and climate at MIT, suggested that the intensity of Atlantic
storms had on average doubled over thirty years.
To some, the Webster paper was a shock, particularly to people who have been
long-term supporters of AMO. ‘Initially,’ said one of these hurricane specialists, ‘I was
very enamoured of the idea of natural cycles. But we’ve gone back to look at the
data, and what you see is anything but a natural cycle.’
2
By and large, reliance on long established notions considered to be unchallengeable
is a failure of developers, implementers and users. The project’s manager evidently
shares the responsibilities for it. Last but not least, a fundamental principle is that
projects must never be permanently structured; they must be dismantled upon comple-
tion. If they become another department, then they forego their original purpose, and
their continuing existence will soon prove to be counterproductive to the organization.
14.3 The project’s life cycle
One of the very bad habits that developed in information technology in the 1960s,
and still persists, is the very long life cycle of software developments. Three years is
nothing unusual for a software project – a legacy of mainframe programming. Apart
Elsevier UK Jobcode:RTF Chapter:CH14-H8304 23-3-2007 12:27p.m. Page:264 Trimsize:165×234MM
Fonts used:Ocean Sans & Sabon Margins:Top:42pt Gutter:54pt Font Size:10/12 Text Width:30p6 Depth:47 Lines
264 Risk management technology in financial services
from costs and frictions with end users, long development timetables see to it that by
the time the deliverables come there is no assurance they will be acceptable.
The business opportunity may have disappeared,
Customer demands have significantly changed, or
The law of the land is no more the same, requiring major changes to the new
software.
As consultant to the board of one of the best known banks, in the mid-1980s I had
suggested expert system projects. This was accepted, but the mission was relegated
to old data processing, with the result that it took three years to complete a project
which should have been done in no more than a month.
Originally, senior management had looked favourably at the project. In 1985, the
executive vice president in charge of investments spelled out the rules the expert
system should follow. When in 1988 the project was completed the EVP rejected
what he got. The project manager was surprised: ‘But the rules were those you told
us.’ ‘Yes,’ answered the EVP, ‘but in the meantime came October 1987 (the stock
market crash), and the rules have changed.’
It is as if legacy analysts and programmers, usually working with deadly obsolete
Cobol, have established a rush jobs calendar for deliverables, with ‘best dates’ some
years down the line. Yet, not only have we plenty of shells for prototyping, but also
technology provides us with a wealth of tools for time compression. Computer-aided
design (CAD) is an example. ‘Time compression is going to be critical in all areas
of testing and product development,’ said an automotive industry executive, adding
that:
Time is money, and
Competitors around the world have demonstrated they can bring product to
market.
Therefore, the quicker a company can bring its produce to the market, the better –
and the less it costs. Additionally, in all competitive domains of product design and
development, virtual approaches are becoming more and more a factor of success.
Computer-based testing enables to validate specifications, and
It allows to fine tune them, to make sure they are accurate for the mission they are
expected to perform.
Another principle of good project management in software development is that a
significant part of the testing effort should focus on program maintainability, which
must be a preoccupation since the drafting board. A successful program for software
maintenance integrates, pulls together and pays attention to all aspects of futures
upkeep. This must be done in concentrated manner.
What exactly are the characteristics of the software that affect the maintenance
process?
How can difficult-to-maintain aspects of the software be recognized and distin-
guished from those easy-to-maintain; and how can this be done in advance?
Get Risk Management Technology in Financial Services now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
