By Amy Rogers Nazarov
Despite decades of advances in programming languages and testing tools, application development projects still fail at an uncomfortably high rate.
While The Standish Group reports a lower rate of outright failure -- 19% of software development projects in 2006 as opposed to 31.1% in 1994, when the organization's flagship CHAOS report was first published -- there is still substantial room for improvement.
If more progress is to be made, experts say, it will hinge on the extent to which business requirements evolve in tandem with the application; the degree to which requirements are clearly communicated to developers; and the clarity with which business analysts -- those liaisons between the development and business sides of the house -- explain each side's needs to the other.
Looking to the future
"The key with a BA is not to just understand business needs at that moment, but rather to ask questions -- what could happen, why it could happen, and when," says Dan Walker, group leader for supply-chain business systems at International Truck and Engine, Warrenville, Ill.
Walker notes that his company began evolving the BA's role several years ago, when it realized that IT was not fully synchronized with other business areas. "We didn’t want IT to be the black hole" into which insufficiently described business requirements are lost.
Joe Marasco, CEO of Ravenflow, an Emeryville, Calif.-based company whose products seek to align requirements with development, says that at least half of the errors in struggling software projects come from "poorly understood requirements."
Indeed, some 93 percent of readers of Requirements Development Journal (http://www.requirementsdevelopment.com/) complained that users expect functionality they did not originally request, while 89 percent cited incomplete requirements as a source of aggravation and 85 percent of respondents said they had to struggle with requirements that were ambiguous. Given these miscommunications, "it’s a bum rap to blame [a failed project] on the developers," Marasco says.
Further complicating matters, requirements are in a state of constant flux. Yet Ian Knox, a product manager for Microsoft’s Visual Studio Team System, notes that the more changes tracked and collected, the more accurately the resulting application should reflect the needs of the organization.
Set a baseline
While every change has a time and/or budget impact, establishing a set of baseline requirements for the application will help all stakeholders gauge the effect of the inevitable changes.
"You have to spend a lot of time in the design phase," says SeemaPhull, founder of the Arsu Group, a Phoenix-based firm that consults with clients on supply-chain business process reengineering. It’s at this time, when applications are first conceptualized, that discussion is most critical among representatives from business and from software development, she says. "Otherwise the IT people may run off and start putting the technical specs together, perhaps picking the technology with the most bells and whistles, not the one the organization needs most."
People give short shrift to the process of soliciting and documenting requirements, says Ravenflow’s Marasco. What’s more likely to happen is the business analyst will generate a set of requirements as thick as "a Manhattan phone book" -- requirements that are often handed off without being validated.
Others believe that in those early meetings, it’s incumbent upon the BA to help management grasp the range of options in a new application. "Senior executives are not stupid," explains Kevin Brennan, vice president, body of knowledge for the International Institute of Business Analysis and a business analyst at blue sands, an IT process consulting firm in Toronto. "Show them what they could do [with new software] and why they should care."
Business problems may sometimes be solved by non-technological solutions. It’s up to the seasoned BA to recognize when that might be the case.
"If you come from an IT background, you tend to think the answer to everything is software," says Barbara Carkenord, who was a programmer at General Motors before co-founding B2T Training LLC, the Knoxville, Tenn.-based BA training company where she serves as president. "But some [fixes] may be procedural; others may be organizational."
Michael Blechar, vice president and research director at the Gartner Group, Stamford, Conn., says that the place in an organization from which the BA hails -- and where they are ultimately housed -- can affect the success of the development project.
"Usually it has been the lead analyst from the IT side who is responsible for gathering requirements," Blechar says. "But as business process management and improvement initiatives have been springing up in business areas, the role has been moving from IT over to the business units." That’s because as many as two-thirds of business processes, Blechar contends, are "human-to-human in nature. They do not involve computer systems."
Obscure no more
Historically, those in the BA community -- who may hold a variety of titles, but all serve as that link between technology and business -- have "labored in obscurity," says Marasco. Yet their stature is being elevated through new certification and training options.
The IIBA recently created the first industry certification exam for business analysts, to be offered around North America this year. And about 5,000 people per year go through B2T’s two-week training curriculum for business analysts, Carkenord estimates. Among other issues, they learn that "it almost always takes longer to gather and document the requirements than for a coder to create the application," she notes.
In an attempt to rectify this disparity, software vendors are changing the way they communicate with developers and the types of best practices they advocate. "About five years ago, we realized we couldn’t focus [exclusively] on the developer anymore," says Microsoft’s Knox. "We had to include BAs and [application] testers."
Ashok Reddy, director of Rational platform offerings at IBM, confirms that the "waterfall" approach -- in which developers attempt to gather all business requirements at the outset, put together an application, then unveil for users who have until now had little or no idea of what they were going to get -- has fallen from favor. Projects that take an iterative approach -- in which chunks of code are developed, then demonstrated to the line-of-business people, who test it against their requirements and suggest needed changes -- "let you flush out risk as you go," Reddy contends.
The more risk is expelled along the way -- in other words, the more opportunities users have to give input into development projects -- the more likely it is that the finished product will meet real business needs, and expensive re-writes minimized.
Setting and meeting iterative proof points will go a long way toward ensuring that software works as expected, says the Arsu Group’s Phull.
"Define the business processes, then define the end state," she says. "Too often, companies focus on simply automating what they are doing today."