How to not choke your business analyst

Guest post by Laura Brandenburg of Bridging the Gap.

In an ideal world, the business analyst and project manager work seamlessly together to help the business achieve the most valuable solution. The Business Analyst owning the scope of the solution and the Project Manager owning the scope of the implementation.   The ideal world is dependent on your organization having standard roles, clear project sponsorship, and every individual understanding their role and being perfectly qualified to fulfill that role.

The ideal world rarely happens.

I know within the Business Analyst profession, we often find professionals with a varied background that may or may not have had the opportunity to learn about how to do the role. We come from the ranks of SMEs, QA, and sometimes even PM. We find our way into business analysis because we are good communicators and learn the techniques of business analysis as we go. On the other side of the fence are formally trained BAs (and PMs) who know how everything should work and nearly nothing about how things happen in real organizational life.

To top things off we Business Analysts are a fairly idealistic bunch. We have some great ideas and a passion for our products but we can also wreak havoc on a nice little project with a specific estimate and a set-in-stone target date.

What follows are a few frustrations I’ve heard about business analysts from my project manager cohorts and a few ideas for how you can help the Business Analyst in these situations. No choking allowed. Work your PM magic.

No estimates

My BA has no idea how long the requirements will take!

We are hard-pressed to provide an estimate, or provide estimates for such a broad range with so many assumptions that they do little to help you plan the project.

How you can help

Recognize that we often start a project from an ambiguous hole of muck. “Defining scope” and “gathering requirements” sound simple but in reality are mucky processes. Some stakeholders know exactly what they want, others are difficult to work with and eliciting the requirements is like finding a needle in the haystack. Others are unavailable for our meetings, cancel at the last minute, or send someone in their stead who knows nothing about the project.

When you ask “how long will it take to gather requirements”, first we get frustrated because you said “gather” instead of “elicit” and then our mind goes into a tailspin trying to think of all the factors and tasks we need to do and all the things we do not yet know because we haven’t had the time to ask. We want to provide you with a number that we can deliver on. And very often the factors are complex and the details to hang out to scarce.

Instead of looking for a hard number at the outset, agree to talk through the factors, list out reasonable assumptions that you’re willing to help us realize, securing commitments from stakeholders, and giving us an appropriate amount of time to dig into the project before coming up with a detailed plan and meaningful estimate.  This is often the starting point of a new project and a great time to start with a collaborative effort. After all, we’ll be in this together for quite awhile…

Analysis takes a seemingly long time

“We are still discussing it.”

We go off into a hole to “analyze” for weeks on end, producing nothing that fits into your WBS charts and generating a lot of meetings and discussion.

How you can help

First off, did you ask us for a plan before you set us off to do requirements? Were we given full license in our discovery process or did you explain the project constraints so we could help you manage them?

If the answer is yes, and you did not get an answer, recognize that you are probably not working with a senior Business Analyst. Help them set milestones, break down the work they need to do, and track toward some intermediary goals.

If the answer is “no” then what were you doing while we were off analyzing? We are probably just as frustrated with you for not starting a plan and providing input on project boundaries. In fact, we probably think we’re doing part of your job while you are “waiting for the requirements”.

Dig in and start the conversation. A senior Business Analyst should be able to give you a plan for what they are doing in this analysis phase. The plan will probably have a lot of “if/thens” meaning that as we go through discovery and make preliminary decisions, the plan takes different paths. A senior BA will appreciate your help in aligning the rest of the team at the appropriate touch points and helping drive the key decisions that will keep the analysis moving.

We like perfect solutions

“No, you can’t cut scope. We absolutely have to do….”

We tend to be perfectionists. We spend a lot of time understanding what the business wants and we can get invested in our ideas about the solution. We can gold plate the requirements.

How you can help

Trust that we are committed to delivering value. Expect that we’ve already done some work to separate out the truly low priority requirements (if not, again a sign your working with a junior analyst that may need a mentor). Given that we’re working from a defined set, tell us what it will take to achieve our requirements. Help us help the business make informed decisions about priorities at a more granular level by providing some idea of the cost of implementation. (Like it or not, it’s really difficult to prioritize a list of “must haves” without having a general idea of the cost of implementation.)

Just three ideas. I’m sure there is more.  I’d like be interested to hear your comments or additional frustrations…

Related posts:

1. What is a Business Analyst?

Tagged as: business analyst, project manager