Want to complete a project successfully?
Then you'd better have success at the start. That means getting requirements right, and there are as many ways to do that as there are business analysts charged with getting it done.
But impatience, miscommunication, misunderstandings and overlooked users can produce requirements that aren't clear or complete. "You want to have as little ambiguity as possible, because ambiguity creates defects," says Andrew Ari Clibanoff, a senior business analyst at GSI Commerce Inc., a King of Prussia, Pa.-based provider of e-commerce services.
Those defects can be costly. Ellen Gottesdiener, principal consultant at EBG Consulting in Carmel, Ind., and author of The Software Requirements Memory Jogger(Goal QPC Inc., 2005), says that roughly one-third of the budget for a typical project goes to fixing defects that originated in faulty requirements.
The following tips will help you avoid becoming part of that depressing statistic.
Understand the overall objective. "You need to have a point of reference: What is the strategy for the organization? What are they trying to accomplish in the medium and the long term?" says Josephine Day, director of customer care and technology at the Project Management Institute in Newtown Square, Pa.
When the objective is clearly defined, you can identify the right stakeholders and users, as well as which other programs could be affected by the proposed project -- all important steps toward success, says Day.
Use all your tools. Susan Burk, a systems architect at Massachusetts Mutual Life Insurance Co.in Springfield, Mass., promotes the use of "self-documenting facilitated workshops" to compile user requirements. "Get the people in a room [who are] empowered to make decisions, have a good facilitator, have a good scribe, discuss requirements, and at the end of the session, it's there," she says. This approach helps reduce miscommunications, because attendees can see draft requirements right away, Burk says.
But don't rely only on this or on any other single information-gathering approach. "There isn't one way to collect, communicate or verify requirements," she says.
Gottesdiener says common techniques include interviews, exploratory prototypes, facilitated workshops and plain old observation. Business analysts, who generally gather requirements, should interview all the stakeholders, including the business leaders sponsoring the project, the project champions and the people who will use the system to be developed.
Business analysts should also involve key stakeholders in workshops, Gottesdiener says, but they have to know who to involve and when to involve them. If the project team is still trying to develop a high-level vision, invite high-level stakeholders such as project sponsors. When it's time to "get down-and-dirty with the requirements," she says, invite prospective users.
Another way to gain useful information is by watching how business people currently handle the processes that the new project will address, Gottesdiener says. Apprenticing -- that is, actually doing the user's job -- is a helpful technique for business analysts, she says, although it's not always feasible.
Another creative technique is to get prospective users to write user manuals for the systems to be developed. This forces them to think about how they're going to interact with the system, resulting in a vision for how the product should work, according to Gottesdiener.
Know what ground to cover. Although there's no one-size-fits-all process for gathering user requirements, it's important to know what ground you need to cover. That's why Peter Roggemann found a checklist helpful.