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."