3 Ways to Change the Perception That Requirements Take Too Long

If you’ve been a BA for any period of time, I’m sure you’ve heard this complaint.

Requirements take too long. Why don’t we just start coding?

I’ve worked in several informal environments where the business analysts are in a constant fight to earn a bit of respect for the business analysis process and the analysis that goes into developing a really good set of requirements. And in fast paced environments the requirements process can feel like a slow moving turtle while the rest of the team is scurrying along.

We’re going to tackle this problem from a couple different angles. First, why do stakeholders think requirements take too long? Second, what can we do to help counteract the perception that they take too long.

Why Do Stakeholders Think Requirements Take a Long Time?

Assuming you are not actually taking “too long” (and being ineffective), I think there are two reasons business stakeholders perceive that requirements taking too long.

  • One is duration: it seems like requirements work is spread out over a long period of time.
  • Second is effort: it seems like they have to invest more time in requirements than should be necessary.

Like it or not, most stakeholders do not really realize that they don’t know exactly what they want or that there are still decisions to be made. They feel that they are clearly stating their requirements. They might feel that you are the one who isn’t getting it. We don’t get it (or their requests don’t hang logically together) so we ask lots of questions.

I’ve witnessed smart stakeholders get visibly frustrated with BAs as they ask the most intelligent of questions. I’ve had A-type personalities tap their pens and triple check their Blackberry for a diversion while I’m trying to elicit a key point. They want the process to move fast and elicitation can seem slow.

Stakeholder perception: Why doesn’t this BA get what I’m saying? Why can’t I just talk directly to someone who will get it?

On top of this after elicitation, we analyze.  From a business stakeholder perspective, they can only see and touch the fact that we ask them questions and then write something down.They don’t see the analysis because we often do this independently. Analysis is the stuff that happens “in our heads”. We think about a problem. The more highly trained among us might apply some visual models to help understand the problem and analyze it more fully. But we think, think, think. Then we organize. And then we write something down, the specification. From the stakeholder perspective, there is a big gap of time between the elicitation and the specification.

Stakeholder perception:  Why does this take so long? What’s that darn BA up to? I’m ready to get started.

How Can We Change This Perception?

#1: Elevate awareness of the analysis

So how do we address this? Well, I think that we need to (just once in awhile) let them see the analysis. If you are on your game you can bring analysis into elicitation, asking questions that root out issues with what your stakeholder is telling you they want. If this is tough, look for other ways to elevate the awareness that you helped clarify their thinking so that stakeholder thoughts and concerns could become requirements.

You’ve got to use some judgment here. You don’t want your stakeholders feeling put down or stupid. If you do that, they are more likely to spend more time prepping before they meet with you (this creates a whole new issue, where you aren’t involved early enough, so be sure to avoid it!). You want them to feel like you really are helping them realize their best ideas.  That “you are better together”. That’s corny but key. You know you’ve got it when the stakeholder says something like “oh, I didn’t think about it that way” or “that’s a really good point, let’s think about that”.

#2: Set clear expectations for the analysis process

A second key means to counteract this perception is to set clear expectations.  You need to do this through the entire project. I typically start a meeting by framing what I hope to accomplish and I end by summarizing what we accomplished and where we’re going next. I try to let them know what I’ll be doing, how long it will take, and when they will hear from me again. As the project unfolds, the requirements plan evolves so over-communication is key. Once in awhile the meeting goes in a completely unexpected direction and I can’t really come up with a good set of next steps on-the-fly. In these situations I be sure to follow-up with notes and next steps after I’ve had the opportunity to sort it out.

#3: Take smaller analysis steps

The third suggestion I have is to complete the requirements process in smaller steps.It’s important to validate requirements early and validate often. Smaller steps mean that stakeholders will get more involved (and that this will take more of their time) but it helps them see what’s happening so they are less likely to say “this is taking too long”.  Validating early and often elevates the ambiguities and the discovery process you go through in crafting good requirements.

>> Learn More About Increasing Your Perceived Value

We have a whole chapter in Professional Development for Business Analysts about how to increase your perceived value as a business analyst. A higher perceived value = more time for analysis.

Click here to learn more about Professional Development for Business Analysts

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.