Avoid the 60-80 trap Featured

7:00pm EDT November 25, 2007

Statistics tell us that 50 percent of all business productivity in the United States is attributed to information technology (IT). But, most organizations would never guess that 60 percent of all IT projects undertaken don’t meet original expectations, and 80 percent of those failures can be traced to bad business requirements. Business requirements reflect or represent an identified business functionality that’s going to be built into IT or a software application solution.

“Any organization looking to make IT applications a big part of the way they conduct business needs to be concerned with the capture and the identification of business requirements,” says Bill Russell, executive vice president, Allegient. “And the technology team and the business side have to get together and collaborate in the definition of those business requirements.”

Smart Business spoke with Russell about how IT success depends on finding, elaborating, articulating and managing requirements.

Are business requirements about improving processes or creating new ways to deliver products, services or processes?

It’s all that and more. It’s about finding and defining a business function that you want to utilize, the process that’s going to deliver that function and the business rules around that function. Any of those three can be built into software so it can then be automated. That’s how businesses accomplish scale. They could use people to do all of that, but they can’t afford to. So how do you replace people? You take the same thing they do by way of a business function and build that set of functions, processes and rules into software.

Who specifies requirements?

Typically, it’s the subject matter experts (SMEs) from within a business who truly understand the function, workflow and rules. Since SMEs are so constrained by time, they articulate these elements, typically to either outside consultants or internal specialized resources called business analysts, who ensure the information is translated into a standard, consistent set of artifacts to be handed to the technology team, who has to go about designing and building the software.

What approaches are used to find and elaborate business requirements?

The most common approach is for a designated group of resources, including SMEs, technology SMEs, business analysts and sometimes consultants, to collaboratively design or define the business functions, processes and rules. The group can break those down into representative parts and articulate them in a common format. There’s a few different ways to do that. One approach is called the Use Case Model, and another less formal model is called a Business Scenario Model or ‘agile’ method. These are planned methodologies for breaking down business requirements into useable parts that a software architect/team can take and build a technical design and software.

How do requirements come into play?

Business requirements are important at both ends of the process. First, the requirements analysis results go into the definition of what the user interface will look like and into a design model. The technology team then starts to develop a detailed design called an object model that represents all the functionality the team is going to build into the system. Second, if you have requirements, they become the platform or baseline for building and running a set of test scripts after the system is built to make sure the technology team delivered what you wanted.

What are the technology aspects?

You can’t build a quality-based IT application and software solution without business requirements. That’s why so many IT projects fail. There are a number of technology tools available to help guide an organization in how to state its business requirements, how to articulate the requirements and how to maintain and track them. The simplest are desktop tools like Visio charts to model the business processes and spreadsheets to build a feature and rule list. Frankly, those probably are not good enough for a complex IT project. There are more sophisticated tool kits on the market, like IBM’s Rational tool kit or Microsoft’s .NET, whose major function is maintaining business requirements.

What are best practices for managing business requirements?

Managing requirements starts at the very beginning of the process when you have to define them. It’s crucial to have extensive collaboration between the SMEs, the business analysts and the technology team because the better the collaboration, the better the definition, and the better the definition, the better the system is going to be. Once you have defined the requirements, they should be maintained throughout the life of the software application. As you make changes to the system by way of enhancements or a major new functionality, you want to make sure you drive those changes back into your use cases and back into your business requirements or scenarios. That traceability matrix will help you update your testing from the time those changes were made. You have to have consistency from your test case or test scripts, back to development and all the way back to your original business requirements. This is true for the more ‘agile’ style development approaches, as well.

BILL RUSSELL is executive vice president of Allegient in Indianapolis. Reach him at brussell@allegient.com or (317) 564-5701.