X
Business

The bigger the system, the greater the chance of failure

IT projects will see more success as smaller, bite-size chunks.
Written by Joe McKendrick, Contributing Writer

Roger Sessions, CTO of ObjectWatch, provides some controversial views on what he sees as a looming meltdown of IT systems, brought on by out-of-control complexity. In an interview with NetworkWorld's John  Dix, he issues a warning, and even discusses the role of service oriented architecture.

IT projects will see more success as smaller, bite-size chunks

Perhaps we should call it "Session's Law": "the larger and more expensive an IT project is, the more likely it is to fail. A system that costs less than $750,000 "has a good chance of succeeding," but a system or project exceeding $2 million "has less than a 50 percent chance of succeeding... by the time it gets much larger than that, the chances of success drop to near zero."

For a wealth of insights on classic examples, as well as how to avoid IT project failures, check out the site of my colleague Michael Krigsman.

"Most failures are in the $2 million to $4 million range," says Sessions. In the interview, he plugs a methodology he and his company developed, but the gist of his argument is that systems projects will see a higher chance of success if they're kept in smaller pieces.

Sessions makes sense, and major projects and processes are better off served up as bite-sized chunks. Henry Ford accomplished this a century ago with the automobile assembly line. Later, we saw the chunking of operational or office-based processes with the advent of the computer. When I was director with the Administrative Management Society in the late 1980s and 1990s, the chunking of white-collar and administrative tasks into more standardized and automated tasks (word processing, reporting, database management) was sweeping through organizations.

Tom Peters, co-author of In Search of Excellence, talked about chunking as a strategy for breaking up complex tasks and projects into manageable components.  Service-oriented architecture does the same, but the question is -- can we achieve simplicity by breaking down complex software operations into manageable, bite-size chunks? Or will things end up as brittle as the CORBA (Component Object Request Broker Architecture) efforts of the past decade?

Interestingly, in the interview, Sessions talks about the role of SOA in IT complexity, observing that companies have tended to build SOAs though arbitrary "decompositional design," versus a more predictable mathematical approach. It's this randomness that sinks many SOA efforts, he says.

The bottom line is big systems have become too unwieldy.

Editorial standards