Soapbox: Zen And The Art Of Computer Projects
Zen and the art of computer project
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 arrives.
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 operating system.
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 still running.
So where's my consultant's fee, then?
Copyright (C) 1999 Matthew Thomas (mpt @ mailandnews . com).
Related Scoop stories
Hawkins demands full inquiry into Incis [Labour, 1999-08-09, 5:15 pm]
Newsflash: IBM pulls plug on Incis [1999-08-09, 5:19 pm]
Incis -- Government's great white elephant -- ACT [ACT, 1999-08-09, 6:28 pm]
Incis soap opera looks destined to head to court [1999-08-10, 9:18 am]
United wants expert inquiry on Government IT [United, 1999-08-10, 9:20 am]
Cancel the Police Review says Labour [Labour, 1999-08-10, 12:01 pm]
Government should come clean on computer contracts [ACT, 1999-08-10, 12:57 pm]
Incis was always going to fail -- Prebble [ACT, 1999-08-10, 1:54 pm]
Incis: once again the consultants are smiling [NZ First, 1999-08-10, 3:02 pm]
Labour must stop bashing Police, again [National, 1999-08-10, 3:05 pm]
Doone: either back him or sack him -- ACT [ACT, 1999-08-10, 4:48 pm]
IBM repudiation of Incis contract [NZ Government, 1999-08-10, 5:25 pm]
Shipley to blame for IBM pull-out [Labour, 1999-08-11, 4:08 pm]
Related sites (external sites are not endorsed by Scoop)