Zen and the art of computer project management
Soapbox 0048, 1999-08-15
In the aftermath of the death of Incis -- the announcement, this week, that IBM was walking away from its contract with
the Police to supply them with a crime-fighting information technology system -- there has been a predictable chorus of
calls from Opposition parties for an inquiry into the failure of the system.
Well, I'm always keen to save people a bit of money, so let's not bother with an inquiry. While an inquiry might explain
the particulars of who said what and when and to whom, and who did what and why and for how much money, I can explain
much more cheaply -- for free, in fact -- why the project failed. And the reason it failed is this: quite simply, it
would have been a miracle if it had succeeded.
The reason it would have been so surprising if Incis had succeeded is that information technology projects of this size
have an abysmal success rate worldwide. A landmark 1995 report, Chaos, by the Standish Group reported that only 16 percent of organizational information technology projects are completed on
time and on budget -- and for large organizations, this figure drops to 9 percent. A full 31 percent of projects are
cancelled altogether. The remainder go over time or over budget, and usually both.
There are two fundamental reasons for this. The first is that people don't understand computers, and the second is that
projects are built on the quicksand of the fast-changing computer industry.
First, people don't understand computers. No other thing so heavily relied on by organizations is so poorly understood.
Whenever you have a large information technology project, large enough that an outside organization is hired to do it,
you are going to come across this problem.
This difficulty has two parts. Firstly, the people buying the system hardly ever know what is possible -- they don't
know just what a computer system can and can't do for them. Even if they do know this, they are not likely to know
whether or not the system supplier is recommending appropriate technology for the job.
This problem is bad enough in itself, but it is made far worse by the fact that the supplier hardly ever knows exactly
what the clients want, either. Even with the most exhaustive requirements analysis -- interviewing potential users and
administrators of the system, running surveys, even preparing prototype systems -- what people need and what the system
supplier thinks they need can end up being wildly different things. The fact that the users and the suppliers are likely
to use different language to describe the same things doesn't help.
The second major problem is that the industry moves too fast. The original contract for Incis was signed by the New
Zealand Police and IBM way back in 1994. That's a long time ago in computing terms -- the Internet only really began to
become popular in 1994, for example. And technology has changed hugely since then. So any computer system which is
planned on such a long time scale is almost guaranteed to be out of date, or even completely obsolete, by the time it
Depressing, isn't it?
Now, these problems I have described apply to computer projects in general, and not Incis in particular. It's difficult
to talk about Incis in particular, because the parties involved are headed for the courts, so they're not saying much.
But just as an illustration, here's one simple example to demonstrate my arguments: Incis's initial reliance on the OS/2
If you don't know what OS/2 is, perhaps a little history lesson is in order. When the Apple Macintosh was released in
1984, the vast difference in usability between its friendly MacOS operating system and DOS -- the arcane operating
system supplied by Microsoft for IBM-compatible PCs -- was embarrassing for both Microsoft and IBM. So the two companies
began work on a replacement operating system: what was intended to be the second really popular operating system, hence
the name OS/2.
Meanwhile, however, Microsoft had developed a primitive graphical interface for DOS, just to keep up appearances with
Apple, and it called this front-end -- wait for it -- Windows. In about 1994, however, when the fourth (and first
tolerable) major release of Windows, Windows 3.1, was really becoming popular, Microsoft and IBM had an almighty fight
over which system should become the operating system of the future.
As part of the divorce settlement, IBM got to keep OS/2, and also got the rights to develop OS/2 so that it could run
Windows 3.x programs alongside its own OS/2 programs. Despite this ability, OS/2 always had much less market share than Windows
did. And Microsoft's Windows 95 and Windows NT systems pretty much put paid to OS/2 as a major alternative operating
system, although it still survives under the moniker OS/2 Warp.
Right, thus endeth the history lesson. Now, the initial Incis contract was signed in 1994, when IBM was -- for obvious
reasons -- pushing its own operating system, OS/2, for all it was worth. So IBM convinced the Police that it would be
best for the Incis systems used by police staff to be running OS/2, and this was written into the contract. But by 1997,
when the contract was renegotiated, OS/2 was a distinctly backwater operating system -- not able to run the Windows
applications which the Police wanted to use (like Microsoft Word, for example). So the Police had to get IBM to `port'
(reprogram) the then-completed parts of Incis from OS/2 to Windows NT.
This, in my opinion, is an example of a supplier pushing a particular solution which isn't necessarily the best for the
client -- espite the fact that Windows 95 hadn't been released in 1994, it should have been fairly obvious that OS/2 was
never going to get the range of popular applications that Windows had. It's an example of the client not knowing what
they want, in that the Police should have realized that they would want a system on which they could run other popular
applications as well as Incis. And it's an example of the quick-changing nature of the computer industry, in that basing
Incis on OS/2 went from a barely plausible option to a downright bad idea within three years.
So what's the solution to this catastrophic failure rate in project management? What's the key to organizing large-scale
computer projects? My answer would be fairly simple -- don't have any. Don't have any large-scale computer projects; instead, have dozens of smaller computer projects, each with a definite
measurable benefit to the client. If a large project can't be split into a number of smaller independent projects, then
that large project is almost certainly badly designed.
Splitting large projects up into small projects has several advantages. By the very fact that a project is smaller, it
becomes easier to budget for, and it's less likely to be out of date by the time it is completed. Also, the
interconnections between various parts of the larger project are clearly defined, so that a mini-project can be changed
or replaced without other parts of the major project having to be changed too. And finally, if one mini-project does
fail, it's not a catastrophic waste of money -- you can pick up the pieces and start again, with the rest of the system
So where's my consultant's fee, then?
Copyright (C) 1999 Matthew Thomas (mpt @ mailandnews . com).
Related Scoop stories
IBM repudiation of Incis contract
[NZ Government, 1999-08-10, 5:25 pm]
Related sites (external sites are not endorsed by Scoop)