So many development teams struggle with requirements. In my experience, it is the largest risk to a project (or at least, the #1 killer to the projects that I have seen fail).
Considering this risk, many teams tend to lean towards a business analyst when they have the budget to do so. IT folks have dreams of super-beings who hand-over requirements that are thorough, but not tedious or boring, that are concise and clear and eloquently identify the users needs and include great insight and even design considerations that are in-line with the development tool-set (but don’t lock you into a single solution either). Such amazing beings that we dream of, called business analysts. Now lets talk seriously about this.
Reality vs Fantasy
The cold reality of the situation is that most people with “business analyst” on their resume are not such super-beings. Think for a moment: how many universities are giving degrees in business analysis? Is Microsoft or Oracle offering certifications for business analysts? Is anyone? Maybe to a minor extent, but it is nowhere as clear and prevalent as it is with developers or project managers.
So, where do business analysts come from? Most business analysts that I have met, come from one of 3 places:
- Developers who were better at gathering requirements than they were at developing
- End-users that were very good at the requirement-gathering process and realized the higher-value of being a business analyst
- IT people who weren’t really very good at anything else but their company needed a business analyst so they thought, “how hard can it be?”
None of these options really knocks my socks off, especially the ones who get into business analysis because they couldn’t do anything better. The ones who moved-up from being uber-users are good, but unfortunately, lack the IT background and struggle to determine which information is going to be most useful to the developers vs PM vs testers.
Don’t get me wrong here. I am not saying that all business analysts are chumps. On the contrary. I have worked with some very gifted business analysts and I have the utmost respect for those people. However, those people seem to be rather rare. If you ever get to work with such a gifted individual, pay close-attention and try to figure out how to discern the difference between them and the lacklustre type of BA that I am warning you about.
Hiring a B.A.
Okay, it is hiring time and you have a few resumes for business analysts. How will you distinguish a good one from a bad one? If you can’t answer this question, the odds of finding a good BA are not in your favor. Keep in mind that [being a BA for several years] is not the same as [being a good BA]. It just means that the person interviews-well and doesn’t get fired very often.
When you interview a BA, he will tell you the same old crap:
- I get to know end-users so I can communicate effectively with them
- I align the goals of IT with the business need
- I speak “end-user” and “IT” fluently
- I am detail-oriented, nothing slips past me
- I write down everything for you and bring a lot of value to your organization
- and other clichés like these
Before I list the traits of a truly good business analyst, take a few moments to ask yourself the question behind the question:
What does a business analyst do that brings value to an organization?
Ponder that for a moment.
A business analyst should be really good a the following things:
- Documentation – He better have some examples, he better know the tools-of-the-trade by name, off the top of his head). This is his meat & potatoes. This is his oxygen.
- Tools for storing documentation – He must have anecdotes about what works and doesn’t work with a few technologies. He must have more than two opinions; he must have insight into which is better, when, and why.
- The value of documentation – He should be able to tell you about the value it brings and when/where you could compromise and what risks go along with each compromise and each type of documentation. Every doc is both a win and a loss. He should be able to reflect on both sides.
- Toolsets (dev tools, technology stack) – The better a BA knows each toolset, the better he will know what he can and cannot offer to end-users. He will know what features cost hours and which cost days/weeks.
- Templates – Any BA with experience should have documentation templates. Insist on seeing a few (more than 3). Never compromise on this. A BA without templates is like a developer without a personal code library or list of web browser favorites. He is a painter without a brush or a preacher without a bible. I don’t care if it is proprietary. If he cares about his job, he will care enough to have his own templates or have them memorized and be able to recite them by heart, on the spot.
- Non-persuasive – For a BA, persuasion is poison. The job of a BA is not to persuade a user or dev team. A pushy or opinionated BA is likely to derail your project and will kill your productivity. Avoid him at all costs, because he will drive you nuts and you will have to fire him. He should still be decisive and push for progress, but never push his own personal opinion. He should only push the agenda of the department and leave his opinion at home.
- Standards – A BA will have clear-cut standards about what is acceptable and what is not. He will understand his place in the software industry and within an IT department. He will be responsible for living up to those standards and you will be aware of those standards because he will make you aware of them.
- Software development process/methodology – It is another type of standard but it dictates the limits of a BA’s role and the expectations and documentation, etc. If he doesn’t know this, then how can he function within the boundaries of his job?
All of these things distinguish a dude-with-a-business-card-saying-“Business Analyst” from an actual quality BA.
So, before you pick a BA, do the same thing you would do before you write software: 1) analyze your needs 2) define criteria for success 3) develop a plan 4) get it done 5) determine how you can maintain what you’ve accomplished 6) analyze the results and consider your mistakes honestly, so you can do better next time.
Feedback from you: any lessons-learned that I may have overlooked?