No rules! No fear! Everything you know is obsolete. That's the Internet mantra, and for a while, even the stock market played the game. But as the Nasdaq bubble has deflated, Internet exhilaration has yielded to practical concerns like quality.
"The market has clearly sent a signal in the last six to 12 months that we've entered into the next phase of Internet evolution, and the same goes for business models and software models," says Eric Singleton, director of electronic business at Raytheon Co. in Lexington, Mass.
It's clear that the ad hoc development that characterized early, content-oriented Internet brochureware doesn't measure up to the demands of today's transaction-intensive environment. But are Web projects simply projects, presenting the same quality challenges as projects of the past? Or does Internet development demand a new approach to quality?
For Singleton, a project is a project. People claim they're "flying by the seat of the pants and really being creative, saying this is a whole different world and we have to make it up as we go along," he says. "But that's the oldest argument in the world, and it's been proven wrong time and time again."
In the 1990s, Singleton recalls, "there was a subculture that said the development of [Windows-based systems] was such a fluid thing, it really didn't fit in with any type of process modeling." But it soon became clear that the old rules still applied, he says.
Singleton says he suspects that a no-rules approach to Internet development began in the early days, when people could still get away with it. "There did seem to be a proliferation of activity largely about creativity and look-and-feel," he says. "The emphasis in brochureware was on content, art, layout - soft, frilly stuff without many moving parts."
Changing Nature of Projects
But the nature of Internet projects has changed from being content-oriented to more business-transaction-focused, says Jim Highsmith, a consultant at Cutter Consortium in Arlington, Mass. "It's not cool to drop transactions, so the quality, in terms of defect levels, has got to be higher," he says.
Unfortunately, just the opposite has been happening. According to Howard Rubin, a research fellow at Meta Group Inc. in Stamford, Conn., U.S. software development was on an upward spiral from 1997 to 1999, with defect rates improving by about 10 percent. But from 1999 to 2000 - paralleling the big bump in Internet development - quality rates in software programming deteriorated 15 percent, he says. Rubin says that a drop in design time and documentation has paralleled the decline in quality.
"Some rigor was building up," he says. "But now, people are trying to build stuff at Net speed, and some are falling back into old habits."
Bill Sanders, CIO at Honeywell International Inc. in Morristown, N.J., says that good software development processes actually save time. "Speed doesn't always equal quality, but true quality always equals speed," he explains.
For example, Sanders says, in the old IT world, mainframe architectures were fairly inflexible. "Big mainframe systems used this operating system, and you had to define the files this way or that way, but there was an architecture that was all set up," says Sanders. With Internet-based environments, there are more choices, so an undisciplined shop could waste time by starting from scratch with a different architecture every time, he says.
In contrast, a quality methodology should include a predefined template outlining the best architecture choices for various types of business systems.
Sanders stresses that he's not advocating a standard set in concrete, but rather a framework, "so you're not starting out from ground zero, yet you're not so prescribed that every business problem uses the same architecture." People who don't understand real quality processes may think that they don't work in the Internet environment, he says, but they're wrong.
"They say, We've got to go fast and we've got to go by the seat of the pants,' and that's why we make mistakes," Sanders says. "I just wouldn't accept it."
"I don't see much difference between Internet and other projects," says Tim Byers, CIO at Shell Energy Services Co. in Houston. He says that some projects do require adjustments in quality methodology, but those are based more on the nature of the project than on the environment in which it operates. "I define quality as fit for purpose,' " he says. "There's not just one quality you have to shoot for. You need to understand what quality the business is willing to accept, [and] you test to that quality."
Byers' team often builds Internet projects with predetermined, short life spans. For such projects, he says, "we may do things we wouldn't do on a larger project where the quality needs to be higher because it needs to be around longer."
For example, Shell Energy recently developed a Web site to enable residential customers to sign up for service during a two and a half week regulatory window. Rather than having programmers develop the site, testers validate it and support people maintain it, Byers brought in a team of eight programmers and testers who worked to get the site up quickly and then doubled the support staff to maintain it for two weeks. "They built it and supported it while it was out there, and after that, they went on to something else," he says.
The key difference in that project was the duration, Byers says. "I'd do the same thing on a client/server application that will be out there just a little while," he says. "And if it's a strategic application on the Internet, you do the same classical things but with a different tool set. It all comes down to fit for purpose."
But Cutter's Highsmith says Internet projects are different because of their high speed, changeability and uncertainty and require an approach to quality that he calls "light methodology."
"In the past, we have equated discipline with formality, and we've got to unlink those," Highsmith says. "Documentation is not understanding; formality is not discipline; process is not skill." He says the question for quality-oriented Internet project managers to ponder is, "How do I lighten up and maintain quality and improve speed and flexibility?"
The folks at GE Aircraft Engines (GEAE) in Cincinnati seem to have found an approach to quality that does just that. When e-process leader Debby Sollenberger put together a "digital desktop" intranet last year, she used a methodology cobbled together from traditional GEAE and General Electric Co. quality processes, GE's companywide Six Sigma quality initiative, and e-business requirements.
The digital desktop allows GEAE employees to customize their access to any of 400,000 online files and interactive sites that they may need. Sollenberger's group had the site operational within one month. "This was very, very fast and very exciting," she says.
Sollenberger says the aircraft parts maker follows what it calls the New Product Introduction (NPI) process. The NPI is spelled out in "a huge notebook - about 2 inches thick - laying out step-by-step what you do, day to day, to introduce a new product or process," she says. "It's extremely rigorous and detailed and about as thorough as you can imagine."
But NPI wasn't designed for e-business, so GEAE condensed 2 inches of notebook pages and five years of Six Sigma experience into one page of deliverables, combining the speed of the Internet with the rigor of the Six Sigma program and NPI. The result was called eNPI. "Of course, behind each deliverable is a checklist, so it's really longer," she says. "But the one-pager is the critical things an e-project needs to consider."
ENPI takes the angst out of lightning-speed development, Sollenberger says. "We're confident that now that we have this in place, we're not going to miss something huge and let quality suffer," she says.
One quality methodology doesn't fit all, and the Internet may require some flexibility. But whether your quality methodology is heavy, light or hybrid, it's a tool that's designed to save time, not consume it.
"If you start with a true quality focus and a methodology, those actually help you do things faster," says Honeywell's Sanders. "They are fully consistent with speed and what we want to do in an Internet world."
Building In E-Quality
GEAE's eNPI quality program is designed to build quality into Internet projects that have to be done quickly. Here are some of the steps that less-disciplined developers might miss.
Prework. Analyze the project's scope by defining, measuring and analyzing the customer's requirements to clearly understand the whys behind the project.
Charter. Who's buying into the project? What's the current process, and what will the new e-process look like? What issues are critical to quality?
Reality check. Conduct an examination of issues such as resources, best-in-class technologies, options for outsourcing and build vs. buy.
Tollgates. These are 10 points at which the previous steps are checked and important questions are answered before the initiative can continue.