Downscaling for better projects

THE END OF the golden age of massive IT projects came suddenly for a food service provider about to embark upon a major ERP implementation. “We got approval from the board and we were closing in on it,” says the company’s IT executive. “And then [Sept. 11] hit.”

The company’s sales are linked directly to the travel industry, says the chief technologist, who requested anonymity. The terrorist attacks caused the company’s travel-related sales to drop “instantly — 15 percent across the board — literally one week later,” the source says. The ERP project, priced at $800,000, was put on hold and a $10,000 content management project was moved up. But the ERP software vendor was relentless and offered the company “a 10-user pack that will allow our team of testers to go forward,” the source says. This incident was a revelation for the executive.

“In the future, I don’t think I’d ever buy a system again without doing [incremental implementation],” the source says. “Because you spend half a year to a year implementing [anyway], and then you need the benefit of the full-blown package.”

Other enterprises are also learning quickly that downscaling is not only a realistic response to a down economy and competing projects, it is also an opportunity to craft better projects. Going forward, implementing projects incrementally according to an IT architecture hammered out with business leaders will be the rule rather than the exception, say users and analysts. Although there may still be the occasional behemoth, most projects will roll out in modular strides that must be flexible to constantly shifting business needs and conditions, according to analysts and users who also stress that CTOs will increasingly be the architects and caretakers of these new frameworks.

The “more intensely interactive and intensely iterative process of these smaller projects [makes it] more likely that they will reach a successful completion,” says Andy Efstathiou, an analyst at The Yankee Group in Boston. “[Smaller projects] will achieve a much higher level of functionality than they would otherwise have achieved. I think those are the real benefits of this changed way of doing it,” Efstathiou says.

Strategic planning

Caleb Rutan, CTO of Ann Arbor, Mich.-based Techstreet, an Amazon.com-like site for multi-industry technical books and materials, has found downscaling can also lead to more focused, easier-to-manage projects. In this case, a Web storefront-creation initiative deferred by a sales slump in the first quarter of 2001 was streamlined before it was resurrected.

“We were looking at targeting corporate audiences with that, and we sort of moved it down to targeting individuals more directly,” Rutan says. Techstreet will help industry experts set up a Web store via its site. The storefront project was supposed to have been completed in the first quarter of 2001. “We had begun looking at that [in the fourth] quarter of 2000,” Rutan says. It was completed in January 2002.

Almost in the same time frame, Techstreet also revived a customer-retention application that notifies customers about upcoming books, white papers, and related materials in which they had shown a previous interest, Rutan says. “[The project] was going to need a lot of development to make sure that we could get the data in from publishers in a manner that was smooth and quick.”

With two rebooted projects under his belt, Rutan is confident that downscaling is not a failure but a victory against the odds. “In our case, we didn’t not do [the projects],” he says. “We had to do a lot of number crunching, a lot of strategic planning trying to figure [which customers] we can talk to that will best fit … for low-cost, low-risk but high-return [projects].” The corporate insight has proven to be very useful, and will make the project selection process more rigorous, Rutan adds.

Rutan says CTOs must be prepared to ask and answer questions reflecting a scale change in project requirements. “Is this something that’s going to bring loyalty in the door? Is this something that’s going to bring new customers and new audiences to interface with us?”

Re-energizing a project

Looking inward, Textron — a $13 billion conglomerate — faced its own set of questions when its portal project “went into a quiet mode” 18 months after its genesis and an initially successful six-month run, says Phyllis Michaelides, chief technologist at the Providence, R.I.-based company.

“Sometimes a hiatus is not a bad thing,” Michaelides says. It’s a time for an enterprise to take stock of what it’s doing as well as for CTOs to lobby for something they believe in. “If you are completely convinced that this will save money and bring the corporation together, then it’s time for re-energizing,” she says. Evangelizing the potential ROI, corporate-unification benefits, and cost savings of portals paid off — Textron re-energized the portal project. The result: “In the last six months … it’s been on a clearer path,” Michaelides says.

To light that path, Textron will be using a framework built upon the iPlanet Portal Server platform. “I like frameworks because they don’t dictate actually what the person sees, but they provide all the reusable pieces so you don’t have to reinvent those wheels,” Michaelides says.

Setting up a framework will be a key step that CTOs will have to take, but in a much tighter lockstep with their business-side counterparts, analysts say. The increased interaction will mean greater friction and more work, but that “in fact, improves the chance of a meeting of the minds,” The Yankee Group’s Efstathiou says.

Meeting end-user expectations

A meeting of the minds and a framework would have helped El Segundo, Calif.-based Prime Advantage with a CRM project that fell short of expectations, says Joe Neuhaus, CTO of the online business-to-business buying consortium for manufacturers.

When he inherited the project in July 2001, Neuhaus found that his users were quite unhappy with a CRM system that had been delivered without a lot of input from them. During a six-month implementation of the platform for Prime’s customer service, customer care, and sales departments, the CRM supplier ran into integration challenges and performance stability problems, Neuhaus says. “Our budget [for the CRM project] was $250,000 and after six months that money was gone. And we were left with something that didn’t work,” Neuhaus says.

“We trashed it, extracted all of the data, and replaced it with two [internally developed] systems,” Neuhaus says. “We punted on the monolithic [method of doing] everything for everybody all at once, and we went back to the individual [projects].”

The end-users had been polled for what they needed, “but they weren’t involved in the design, or the prioritization of what was really critical in a CRM system,” Neuhaus says. “I think that if I were given a project like this now, clearly, I’d bring these departments together and I’d make them a critical component of the requirements design.”

This tighter integration between CTOs and business leaders on project management will have to extend to the creation of architectures that will guide future development efforts, particularly those based on Web services — a good fit with incremental project management, say several analysts.

But enterprises will have to assert a tight rein on projects — big and small — especially when it comes to Web services development, says Melinda Ballou, an analyst at Meta Group in Stamford, Conn. Although hyped as a way to ease development efforts, unrestrained Web services projects could cause major problems for the unprepared, Ballou says. “You better have cogent business requirements driving what you’re doing,” she says.

Even as CTOs adjust to a downscaled world, there’s more than a glimmer of hope that their efforts will be justified by the componentized paradigm that standards-based Web services development promises.

“You’d be foolish to invest in any other kind of a system [than the Web and the Internet],” says the IT executive at the food services provider. “And so every single package that we evaluate, any project we put together, that is the central thinking — can it communicate there? Is there a way to share information over the Internet? Is it an open system? If it passes all those tests, then you look at it. If it doesn’t pass these tests, you don’t.”