When Too Long Isn’t Long Enough

Does Requirements Gathering Slow Projects?

In a recent social media poll, business analysts (BAs) reported that their top obstacle to success was the perception that requirements gathering takes too long. If you’re a BA and you haven’t heard this complaint, consider yourself lucky—it’s one that we frequently are asked to “fix” when we visit a client site.

The truth is that requirements gathering and requirements management—when done correctly—are essential to producing outcomes that meet the needs of users.  And, because the process is so necessary, it takes time.

The paradigm needs to change from “BAs write requirements during the requirements phase” to “BAs conduct business analysis throughout the project lifecycle, and the product of good analysis is high quality requirements information.”  In this new paradigm, everything is requirements related in some way: the goal of the project itself is a requirement, stakeholder needs are requirements, systems have requirements, etc. 

BAs believe (and analysts like Gartner agree) that more time, not less, should be spent conducting business analysis.

Here are a few good arguments to support what may at first seem like a somewhat unpalatable message.

The Invest Now or Pay More Later Argument

The reasoning behind this argument is pretty powerful and exists in most organizations.  Start with a general line of thinking—An incorrect requirement can have many aliases: bad specification, correction, bug, defect, test failure, or customer complaint; the different names correspond to when the problem appears in the project execution process.

Next, use the Voke graphic (below) or research from Forrester, Gartner or  another organization.  All reach the same conclusion; when you correct a requirement later in the project execution process, it costs more—a lot more.  In fact, the cost to repair a requirement grows exponentially as the project progresses.  This fact makes sense when you consider that correcting a data requirement after an elicitation activity often takes less than hour.  However, discovering, fixing, testing and re-launching a solution defect traced to that incorrect requirement can take over 100 hours during implementation.

The Quality Solution Argument

Part of the job of a business analyst is to carry the requirements “message” across the divide between the business sponsor and the IT development group.  Regardless of which side of the divide you reside, the phrase to use is “if I just spend a little more time” to clarify things for “those” folks, we will avoid headaches later.  This approach is best accomplished when you have a collaborator on the other side of the IT/business divide.  Ironically this is a best practice, and the more often it is done, the narrower the divide becomes…and the less likely the requirements message is to get shot.

The Better Backlog Argument

Your enterprise is probably working in some way with Agile.  If your organization is like most, an executive has probably complained that business change is not happening fast enough and Agile seems like a great way to address the complaint.  After all, who could possibly have issue with something called “Agile”?

A common illustration of the Agile approach is what is often called “the journey.” The illustration goes like this:  Instead of spending a lot of time mapping out the journey up front (i.e. the waterfall approach) SCRUM methods use quick sprints where you start in one point and end at another moving closer to the desired destination as it is known at that point in time (see Washington D.C. on the illustration to the right).  Once the team completes a sprint (see Terre Haute, IN on the map) it evaluates if the same destination is still desired by the business sponsor.  If so, the development team will work with the next user story in the backlog.

Agile is a great concept and one that works well if it is done right.  But as the BA you need to prepare for the journey by addressing two major pitfalls in the way backlog requirements are defined and managed.  The first pitfall happens when functionality is added in such a way that only partially satisfies the business requirement.  The other pitfall occurs when there are two alternatives which need to be evaluated to determine which is best for the intended user.  Selecting the wrong fork may reduce the overall experience for the intended user, though the SCRUM team provided exactly what the business requested.

More comprehensive requirements with frequent validation will mitigate the risks associated with both of these pitfalls, but the approach requires a bit of time up front verifying the journey as it progresses.  If your team has a customer advocate or user experience expert, these resources should support your justification for taking a bit more time to revisit the roadmap.  Tools BAs can use for verifying the journey often take the form of a business process model or storyboard.  Using either method will force stakeholders to think at a higher level throughout the project—time well spent, especially if you get an “ah ha” moment.  Document the experience and testimonial.  You will be ready when a sponsor asks you to sprint a little faster.

Five Tactics To Help Support Your Arguments

1. Localize your argument that bad requirements are directly tied to poor outcomes. Conduct an anecdotal or simple online survey at the beginning of a project. Ask each respondent to think about his or her last project and “guestimate” how many errors could’ve been avoided if the requirements were clearer up front. You can also ask them to directly tie a defect to a poorly-defined requirement.
2. Recognize—and work within—the divide that exists between the business and IT. The expression to remember to use with both sides is “if you allow me to just spend a little more time” to clarify things for “those” folks, we will avoid headaches later.
3. Avoid placing blame. Some people, such as stakeholders, hold interests that aren’t directly part of the solution so it is natural that your project and its deadlines may not get his or her full attention. But don’t complain. Most people have long memories and will remember your actions on the next project. A variation that does work is to approach the individual directly, asking for his or her help. When we do this we often find that the person needs to be involved sooner with more frequent, low time commitment reviews.
4. Sponsor a learning session. Get the help of a member of the PMO to talk about the need to step away from the traditional “requirements as a checkbox” approach and toward the idea that requirements are a continual process.
5. Use patience, praise and food. Even professionals need encouragement along the way especially when tasks cannot be done quickly and easily. And remember people always learn better when food is on the agenda, so quid pro quo could involve a wheat wrap or a chocolate chip cookie!

Don’t forget to leave your comments below.