Flickr photo by Aoife City womanchile
Guest post by Laura Brandenburg, Bridging the Gap
The ideal scenario is for the business analyst to work seamlessly with the project manager to help the company achieve the best solution. The scope of the solution is owned by the Business Analyst, while the implementation is managed by the Project Manager. ? Your organization must have clear roles and project sponsorship. Every individual must understand their role and be qualified to do so.
The ideal world is rarely possible.
I know that many Business Analysts come from diverse backgrounds and have not had the chance to learn the skills necessary to succeed in their role. We have worked in SMEs, QA, or even PM. We are excellent communicators and quickly learn the business analysis techniques. On the other side is a group of formally trained BAs and PMs who are very familiar with how everything should work, but not much about what happens in real organizational life.
We Business Analysts are an idealistic bunch. We have great ideas and passion for our products, but we can also wreck havoc on a small project with a precise estimate and a set-in stone target date.
Below are some frustrations I have heard about business analysts through my project manager cohorts. Also, a few suggestions for how to help them in these situations. No choking. Use your PM magic.
No estimates
My BA doesn’t know how long it will take to complete the requirements!
We are unable to give an estimate or provide estimates for a wide range of assumptions, so they will not be able to help you plan your project.
How you can help
Recognize that many projects are started from a murky hole of muck. Although “Defining scope” sounds easy, “gathering requirements”, in reality, these are complicated processes. Some stakeholders are clear about what they want, while others are more difficult to work with. Eliciting requirements is like looking for a needle in a haystack. If others are unable to attend our meetings, they can cancel at the last moment or send someone who doesn’t know anything about the project.
We get frustrated when you say “gather” instead “elicit”. Then our minds go into hyperdrive trying to figure out all the factors and tasks that we need to accomplish and all the things we don’t know yet because we didn’t have the time to ask. We want to give you a number that you can trust. The factors can be complex and the details can be difficult to find.
Instead of asking for a hard number, it’s better to discuss the factors and make reasonable assumptions. This will help you secure commitments from other stakeholders and give us enough time to look into the project before we can come up with a detailed plan. This is often the beginning of a new project, and a great opportunity to begin a collaborative effort. We’ll be in this together for quite a while…
Analyses take a long time.
“We are still discussing it.”
We get lost in a maze of “analyzes” for weeks, producing nothing that matches your WBS charts, and generating lots of discussion and meetings.
How you can help
First, did you ask for a plan before we started to fulfill requirements? Did you give us full permission to explore the project or did you explain the constraints so we could help you manage them.
If you answered yes and did not get an answer to your question, you probably are not working with a senior Business analyst. You can help them set milestones, break down their work, and track towards some intermediary goals.
If the answer is “no”, then what?