|
Your boss has asked you to oversee the development of a new billing system,
and you’ve brought together a capable project manager and a group of handpicked
developers. They’ve chosen state-of-the-art technologies and tools to
build the system. The business analyst has talked at length with the accounting
manager, and has written up a detailed set of requirements. The project has
everything it needs to be a success—doesn’t it?
Apparently not. Six months later the project is already late and over
budget. The developers have been working overtime for weeks, and one has
already quit, but despite this the software never seems to get any closer to
completion. Part of the problem is that the accounting team keeps claiming
that the software doesn’t do what they need, and they have pushed through a
steady stream of “essential” change requests, not to mention a flood of bug
reports. Your boss will be furious when she hears about this.
So what went wrong?
Whatever it is, it must be something that most companies get wrong.
According to Standish Group [2001] research, only 28 percent of software
projects in 2000 succeeded outright (see Figure 1-1). Some 23 percent were
canceled, and the remainder were substantially late (by 63 percent on average),
over budget (by 45 percent), lacking features (by 33 percent), or, very
often, all of those issues combined.
At New Zealand’s Ministry of Justice, the new $42 million Case Management
System was $8 million over budget and over a year late when it was
rolled out in 2003. Of the 27 benefits expected from the system, only 16
have been realized. Instead of boosting productivity, the system has actually
increased the time needed to manage court cases by doubling the amount of
data entry. A postimplementation review identified over 1,400 outstanding
issues. But “the only challenges faced by the developers were those common
to large and complex systems” [Bell 2004]. |
