When software projects go bad, the results can be disastrous. Every few months, a new horror story pops into the headlines -- like Hewlett-Packard Co.'s recent, flawed SAP deployment. The company had done dozens of smooth ERP (enterprise resource planning) migration projects, but when its latest ran into problems, the cascading disruptions contributed to HP missing its third-quarter financial projections.

A new study from the Delphi Group suggests that a significant part of the problem in tackling major IT projects lies not in the software itself, but in the business processes surrounding the deployment. Seventy percent of the respondents to an ongoing Delphi survey said they consider capturing and documenting business requirements a difficult process -- and more than 60 percent said their organization has trouble implementing changes to its processes and policies.

"In this survey, what was really notable was the very definitive responses," said study author Nathaniel Palmer, chief analyst at Delphi (a unit of Perot Systems Corp.) "Respondents were very explicit in identifying problem areas, like capturing business requirements. That's something that you'd think should be a core competency, but respondents overwhelmingly said they struggle with it."

More than 75 percent of Delphi's respondents said their requirements data resides in a number of separate sources, and close to 90 percent said incomplete definition or capture of business requirements is at least a moderate problem in their organization.

Those findings resonate with John Oliveira, the director of operations for Horizon Casualty Services Inc., a Newark, New Jersey provider of insurance services such as claims processing and bill payment.

Last year, Oliveira confronted the problem of reducing the resources required for his organization's heavily manual processing system, which involved human handling of every bill that came through. Oliveira's first thought was that his IT group would need to rewrite and improve its homegrown bill processing application. But as he began investigating options, he connected with BPM (business process management) software vendor RulesPower Inc. -- and found that what he'd assumed was an applications problem was actually a business processes problem.

"We had to really change the way we think about things," Oliveira said. "It was a significant cultural change in our company to come to grips with: How do you identify the business requirements? How do you document them? How do you use them most effectively in an automated solution?"

Horizon graphically modeled its bill payment process, and in doing so discovered workflows that didn't make sense, like the two different payment processes that had evolved for handling claims from two separate but similar clients. After four months of work to develop formal processes and configure RulesPower and their bill payment application to follow them, Horizon rolled out the first phase of its revamped processing system in July. Horizon's initial goal was to have 20 percent of the bills it handles pass through its system with no human intervention. On day one, it began automatically processing 40 percent.

Training both the business and IT staff to think in terms of rules and processes has been challenging, but the results are dramatic, Oliveira said: Because Horizon Casualty is now processing in real time bills that used to take days to handle, it has discovered bottlenecks in its system it hadn't known of before. Oliveira is now working on addressing those bottlenecks, like delayed claim authorizations.

"The greatest thing you come away with is understanding your processes better than you did before," he said.

Delphi Group's Palmer said his firm's survey is aimed not at offering solutions, but at identifying pain points, so that managers like Oliveira will be conscious of the role business processes play and of the advantages of formally defining and documenting requirements. The survey, targeted toward IT managers at organizations of all sizes, can be completed online at http://www.questionpro.com/akira/TakeSurvey?id=185741.

"People have been throwing around statistics for a long time about huge failure rates on software system projects, but companies are still investing in and building on software," Palmer said. "We're looking at the root causes of why the failures are so widespread."

» posted by abennett

IDG News Service

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine