LeslieJ.net :: Leslie J. Morse

2010 was the year of interviewing for me. I hinted on that in a previous post, and while taxing at times. I am pleased to be part of a team that added 17 team members over the course of a year.  One of the standard scenario type questions I pose to candidates is around resolving conflict. It typically goes something like this…

Being able to gain consensus among stakeholders is an important skill for a BA and as an analyst we have all encountered situations where our stakeholders are in conflict. For example, say you were eliciting requirements for the Add-to-Cart button on a Web site, the button could only be one shape. What techniques would you use to resolve conflict between two stakeholders when one wanted it to be a rectangle and the other wanted it to be oval?

Naturally I get a myriad of answers. They have ranged from, “I would just make the choice,” all the way to, “I would do competitive research and present what I believe to be the best choice and let them make a decision.” Clearly the second one is a much better response.

Some of the better responses have included:

• Explore beta testing options
• Use customer research to make a decision
• Present cost of each option to assist in decision making
• Competitive Research/Industry Standard (as mentioned)

Although, the one answer no one ever clearly gives me is…
Look to the ultimate stakeholder to make a decision.

A good BA should do stakeholder analysis at the beginning of any project, and that analysis should result in defining one single ultimate stakeholder – the ‘chief’ of decision maker (one and single are the key words there).It isn’t always an easy task, but a necessity. Individuals all have their own opinions and objectives, so conflict is inevitable.

It is important for analysts to remain neutral in these situations as strong positive relationship with stakeholders make for a much easier road down the path of elicitation and analysis. In stead of trying to arbitrate on your own make your life as an analyst easier and identify a primary stakeholder that is the ultimate decision maker. Use tactics such as industry research, cost-benefit analysis and the like in order to make a decision paper for the key stakeholder, and allow them to make the decision.

Continue Reading

My head is full of business analysis topics and thoughts. However, Chris Gurney‘s post ‘How to Be Awesome at Being a BA‘ assisted in inspiring me for my first business analysis related writing. In his post he does a great job of hitting on key skills BAs need to have, and is also on the money when it comes to saying, “Chances are, if your career has landed you in the role of a business analyst, it was probably by accident.”

Disclaimers:

• I too am someone that accidentally ended up in the role of Business Analyst
• I too have had very little formal training on being a Business Analyst
• I am relatively new to being a team lead
• I have no training on how to interview people

Last fall the BA team I worked on had 5 people on it. Today we have 15 with another staring next week, 3 current positions open, and one more position slated to open in the next month. Over the past 3 months I have reviewed 60+ resumes, interviewed at least 25 people and selected 6 for placement on my team. That’s almost a full time job in and of itself.

Through this, I consistently wondered, where do I find awesome BAs? Granted, I am hiring all contract positing and considering I operate within a mammoth sized IT organization there are lots of processes and restrictions related recruiting. I am essentially limited to considering only resumes submitted by our strategic sourcing providers. Given that, perhaps the more appropriate question is… How do I identify an awesome BA?

Clearly BAs need to be analytical and detail oriented individuals that communicate well, but what I have found is that being detail oriented conflicts with communicating well. First off, if I am not an aggressive interviewer its tough to get a word in edgewise after the candidates start talking. I find myself wondering, do I ramble like this when I talk? Gosh, I certainly hope not. To me a good BA will get down there in the weeds and have the ability to tell you every single nitty-gritty detail about something, but a great BA can give you the elevator speech about requirements and effectively communicate whats important to the audience at hand. As a result, I’ve landed on one question that makes it or breaks it during an interview: Can you take a moment to describe for me your ideal process for gathering and documenting requirements?

What I don’t mean is…Tell me about the process you used to gather requirements on your last project. But 9 times out of 10 that’s the answer I get and I have to painfully ask leading questions in order to try and uncover what I am really looking to understand. There are lots of technical answers someone could give me, and in a moment I will outline for you a BABOK inspired response, but first – my answer.

I would say my preferred process for gathering requirements involves a handful of key steps:
- Review the scope of the project I am working on
- Gain a foundational understanding of current state (if it exists) and the organization so I know my sandbox
- Gather requirements using techniques best suited for the project
- Distill content from those meetings into clear and testable requirements
- Validate the accuracy of the requirements with stakeholders
- Verify that requirements are truly feasible and in the scope of the project with my PM and technical counterparts
- Prioritize requirements with stakeholders
- Present a comprehensive package of requirements to all stakeholders
- Obtain approval/sign-off on the requirements

It’s not that hard. The answer should take about a minute, and if you are less wordy than I am you can probably capture it in a distinct list of verbs. The BABOK Table of Contents is a great place to pick up on the keywords a BA needs to effectively answer this question.

• 2.1 Plan Business Analysis Approach
• 2.2 Conduct Stakeholder Analysis
• 3.1 Prepare for Elicitation
• 3.2 Conduct Elicitation Activity
• 3.3 Document Elicitation Results
• 3.4 Confirm Elicitation Results
• 4.1 Manage Solution Scope & Requirements
• 4.4 Prepare Requirements Package
• 4.5 Communicate Requirements
• 6.1 Prioritize Requirements
• 6.2 Organize Requirements
• 6.5 Verify Requirements
• 6.6 Validate Requirements

There are a wealth of techniques one can use to achieve these steps, but it all comes down to four must-haves in my mind:

1. Assess the Environment
2. Elicit Requirements
3. Organize Requirements
4. Validate/Verify Requirements

Interviewing has certainly given me appreciation for what it takes to find talent and when it comes time for me to interview for a position again I will certainly do a better job presenting my own skills. So please, do me and any other hiring manager a favor. Know how to answer this question, and if the person interviewing you doesn’t ask it and you have an open ended opportunity to summarize yourself – include this topic. You should look stellar.

Continue Reading