In theory the idea of having traditional BSAs involved with a project should work quite well, and in practice it often does.  The best analysts are organized and great communicators, having the ability to distill the critical information from your project stakeholders out of the “information noise” that they provide – often through a wide range of modeling techniques. For many organizations the addition of BSAs clearly improved the quality of the requirements elicitation and analysis modeling.  It also opened up communication between the “tech weenies” in IT and the “business morons” that the system was being built for. 

Clearly this was a step in the right direction.  However, some very common problems have been known to occur: 

BSAs often lack the right skills.  Many organizations have difficulties hiring the right people and/or nurturing the right skills in people.  The end result is that people are often thrust into the role of BSA but do not have the skills to fulfill that role, nor do they have an opportunity to gain those skills.   

BSAs can have undue project influence.  A strong-willed BSA may inadvertently influence a project, perhaps by playing down requirements that they don’t agree with or even influencing architecture decisions by being biased towards one type of analysis technique (such as focusing just on use cases or just on data models).  This is particularly dangerous when BSAs act as stakeholder surrogates AND the developers and stakeholders have little interaction other than via the BSA.

BSAs can be out of date.  Having previous development experience is critical for a BSA because it grounds them in reality. However, it may also lead them astray.  For example someone with a data-intensive background may struggle when working with a development team that is using object technology (and vice versa) because they don’t know which issues they need to focus on.

BSAs can act as a communication barrier.  Although BSAs can act as a communication bridge between the two groups they also act as a communication barrier.  On the Agile Modeling (AM) mailing list Ron Jeffries depicted the communication approach of traditional BSAs to look like “stakeholder => BSA => developer => BSA => stakeholder”.  This looks a lot like the game of telephone tag, doesn’t it? When you play this game you quickly discover that the signal degrades between hops, decreasing the chance that the actual message gets through successfully.  Although a highly skilled BSA, one with excellent communication skills, will reduce this problem it will never go away completely.

BSAs can reduce stakeholder influence.  An interesting implication is that your project stakeholders don’t have as much influence over the software as they may think.  They’re influencing the traditional BSA, and the models and documentation that the BSA creates, but have no direct influence over what the developers are creating.  This can even be said of user interface prototyping efforts, particularly when those efforts are led by a traditional BSA.

BSAs often over analyze.   Another inherent problem with traditional BSAs is their tendency to actually do their perceived jobs.  What?  When you specialize in something you will naturally focus on that task.  The implication is that the task of business analysis will be stretched out, instead of Iterating to Another Artifact as AM suggests, such as a design model or even source code, a BSA will likely focus on expanding the artifacts that they specialize in.  Not only is your development effort likely to devolve into a more serial process, instead of an evolutionary approach, the BSAs are likely to develop more documentation than is required.  Your goal should be to create models and documents which are just barely good enough.

BSAs can reduce feedback.  When analysts are only responsible for analysis efforts, for creating models and documents that are meant to be handed off to developers, there is less opportunity for feedback.  There is the danger that they will create theoretically sound models, and make unrealistic promises based on those models to your project stakeholders, that don’t work in practice.  The feedback of people working with software is critical, feedback that you can’t get from models and documents.  The BSA quickly learns what actually works, and from the resulting changes requested by stakeholders quickly improves their analyst skills because they recognize mistakes they made.

BSAs can reduce opportunities for developers to gain communication skills.  With traditional BSAs in place developers aren’t given as many opportunities to improve their own communication skills, skills that are critical to success in today’s environment.  Nor are they given the opportunity to work closely with business experts, opportunities that would allow them to learn about the nuances of the business environment and thus increase the chance of them building a system that actually meets their users needs.  

Nor are they given the chance to discover that the “business morons” are actually pretty smart after all, with interesting knowledge worth learning.  Similarly, project stakeholders miss the opportunity to learn about how software is developed, arguably a good thing in some organizations, and to discover that the “tech weenies” are actually very interesting people.