If you're associated with software development and you haven't seen the movie office space you should. The particular scene in the movie to watch out for is the one where Tom Smykowski, the business analyst is questioned about his role and what it is that he does in the organization.
If you are content with a low-resolution version of the scene just so that you can get the reference-to-the-context of this post and follow along, there is a rather ugly version here. Having pointed you to that, I highly recommend, renting a DVD and enjoying it in the comfort of your couch.
The question the business analyst was asked in the scene might sound hilariously funny; but is, in reality, a rather profound question every business analyst out there should be made to answer:
What would you say you do here?
Ask this question to a truck load of business analysts around the world and I'm sure you'll get similar versions of the answer, that you heard in the movie. That and you'll get a truck load of similar crap about:
- Developers not being good at communicating with the client.
- Developers not being good enough to understand the business domain and the problem.
- Developers not being expressive or articulate enough.
For the truck load of answers I tend to get, I usually have one standard reply that fits them all: Bullshit.
At Multiplitaxion Inc, projects with one or more dedicated business analysts who did nothing else, had a notorious history and reputation of failing miserably. Somehow our resource management group leaned towards believing that having a dedicated business analyst associated to a project has nothing to do with it's success or failure.
The resource management group, of any organization, however, is not exactly the kind of people expected to be following up project management, software development, or for that matter, how the craft of software development is evolving over time. Put simply there are not the group of people expected to be following up on process mavens like Scott W. Ambler or questioning the very existence of the role of a business analyst. Scott in his rather elaborate and pragmatic article explains:
| You definitely need to do analysis, but whether you need someone who just does that is a really big assumption. Agile developers are generalizing specialists, people with one or more specialties, a general understanding of the software process, and a knowledge of the domain. One of their specialties might be in analysis, or then again it might not. It is unreasonable to expect everyone to be an expert at every aspect of software development, but it is reasonable to expect IT professionals to have some analysis skills and for some people to have deep skill in this activity (amongst many of their skills). You need to do analysis, but that doesn't imply that you need analysts. |
The article is full of warnings, which are not just based on personal opinions or random theory; but based on real life experience instead; quite a bit of which I've personally been a witness during my years of association with software development. Scott explains:
| A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills. Remember, BA is also the abbreviation for band-aid. |
It is a rather long-winded, pragmatic and objective article, not just interested in nailing the role of the business analyst, but trying to understand pragmatically where a role of that sort fits in the larger scheme of things. It is an article every person, responsible for making hiring decisions, in any organization that wants to do anything meaningful other than what a typical body shop out there does, should read.
I've never been against the idea of doing analysis; but working under the assumption that people who are capable of building the entire system, testing it and taking it to a production ready state are incapable of understanding what it is that they need to build sounds a little over-the-top and absolutely stupid.
Every time I get into a discussion with folks who are still into Big Design Upfront approaches of software development or people who draw their inspirations out of Indian body shops, that sell bodies, pull frauds and offer no meaning to the larger scheme of things; the importance of the role of a dedicated business analyst just keeps coming up all the time.
If you are trying to run a project with programmers who are fundamentally incompetent, have no talent or desire to communicate and if your selection criteria of programmers is based on principals formed during the cheap outsourcing era, throwing a business analyst in the equation will not set things right. If you have a kick-ass team of one man armies, removing a business analyst from the equation will hardly make any difference.
Some of the best business analysts that I have met and worked with, have been people from the development or testing team. They are people who rise to the occasion of doing analysis when required and then get back to participating in the development or testing once the analysis is done; rising up to the occasion every time it is needed in the course of the project.
Long story short, most kick-ass business analysts that I've worked with have been development leads, QA leads or project managers, who have coupled up as a business analyst. So much so that I've started believing that you 'find' a business analysts in teams of kick-ass individuals. You don't hire one.
I'm sure I'll have quite a few knitting your brows as you read this; quite a few of you, dear reader, are already thinking of telling me about that ninety page requirement document that the developers cannot prepare is really important; or you are flexing your management mussel and thinking about telling me telling me how developers are not good with UML.
You know what --- don't even bother.
I've been there and done that. The documentation that you are thinking about, if you are thinking about one, is nothing more than CYA.
During the early part of my career, my role was to reverse engineer 'use cases' and UML models out of C++ code base which had been written by a team for literally more than fifty lousy individuals who had been outsourced purely for cost reasons.
If there is one conclusion that I came too, after brining some sense, into that specific project; collectively screwed by fifty developers and a very senior business analyst; it was this: CMM, other process or UML will not result in a successful project. Hiring a kick-ass team of competent individuals will.
Besides, Stewart Armstrong in his article where he questions if we should shoot the business analysts, seems to suggest that, eighty percent of the errors which cause projects to fail happen at the so-called requirement-gathering stage.
Now, go ahead; get a full time Business Analyst for your project if you must, but before you do; ask him the million dollar question:
"What would you say you do here?"
If he is able to give you a convincing answer; by all means, hire him; but if he can't; and gives you the I-can-help-you-understand-the-requirements-because-your-developers-can't-or-I-can-help-you-draw-up-your-specifications-because-your-developers-cant crap consider not hiring him.
If you do end up hiring him, chances are high that you're not just wasting your money; you are, as a matter of fact, risking your project by introducing an additional monkey that'll have to be subdued and sedated as your project moves on and the rest of your team starts doing some real work.
Comments are closed.