Gaining New Business Analyst Skills
Getting training for a specific skill set has always been somewhat of a challenge. Way back in the "good, old days", it was at least simpler because most folks had a single job to do, like "Programmer", "Analyst", "Project Manager", or some such. Those of us involved in providing training were able to focus our offerings on the skills required to execute these focused albeit complex jobs. Unfortunately, one of the fallouts from the job pruning process known as "down–sizing" (or more politically correct, "right–sizing") during the last 15 or so years was that many jobs were mashed together to keep organizations competitive. As a result, fewer people are able to stick to a single task–focused job nowadays. Instead, we see a myriad of combinations of jobs that a single individual is responsible for in the corporate world.
On the plus side, this "mashing" of jobs can be very people–friendly — if your unique combination of skills and interests happen to coincide with the needed combination. Unfortunately, all too often, the combinations that evolve require conflicting or at a minimum non–complimentary skill sets. Let us take a quick look at a couple of these combinations to point out some pros and cons and dispense free advice (that’s worth the cost) to help you figure out how to best build your skills for these multi–faceted jobs.
First off, let us take a look at the individual roles that interest us to see what responsibilities they entail. After that, we’ll take a look at the various combinations.
The Purist Perspective
The "Business Analyst (BA)" role is primarily responsible for enabling the communication between the business community (those who need technology) and the IT group (those who provide technology). Apparently, these two disparate groups evolved in separate universes and never learned how to speak each other’s language. As a result, the BA is expected to understand the business community‘s needs and translate them into business requirements.
The "System Analyst (SA)" role predates that of the BA and is really more focused on the technology than on the business need. Whereas in years gone by, the system analyst had enough time to keep on top of technology developments and still chat with the business community about their needs, those times are fading. Modern system analysts need to spend all of their time keeping up with the technological innovations and trying to make sure that their technology is "up to snuff".
The "Project Manager (PM)" role deals primarily with projects (hence the title, perhaps?). They plan, track, and report activities of people that they manage, empower and support. History has shown that projects that are not managed tend not to get done — at least not on time, in budget or to deliver what the customer expects.
The "Subject Matter Expert (SME)" role should know what the business community wants and needs and be able to make decisions on those desires. They are the primary source of business requirements and other resources we need to deliver the technology they can use. Ideally, these people live in the business world currently and are busy honing the skills they need to be good at whatever they do.
The "Developer (DE)" role is, as the name implies, the only critical role (at least according to the developer I asked) in the process. After all, if they don’t develop the software, nothing else matters, right? Seriously, developers need to focus on creating business solutions using technology components which might be bought or built.
The "Test Engineer (TE)" role assumes the responsibility for proving that the software does what the software should do — and nothing else. This role takes the solution developed by the Developer (or bought by the purchasing department whom we are blithely ignoring here) and tries to figure out how to prove that the requirements from the Business Analyst were implemented.
A Rational Limitation
There are many other roles involved in the process of determining, developing, and delivering information technology solutions to the business community, but in the interest of keeping this article to a reasonable size, we are going to focus on these six. Since the business analyst role is the one central to our interest group, we are going to look at the combinations from that perspective.
The Great Mash-Ups
The first (and relatively common) combination of responsibilities is that of BAPM (Business Analyst/Project Manager". Whereas both need negotiation, planning, and people skills, the PM role delegates and empowers the people while the BA has to interview and understand them. This situation leads to trying to play "good cop, bad cop" at the same time — frustrating at best, impossible under all but the best of circumstances.
Another common combo is the BASME (Business Analyst / Subject Matter Expert). This role is extremely complex because the person defining the business needs is the business person himself/herself. Ever try interviewing yourself? The SME needs to focus on whatever their role in the business world is and keeping current with that world. As a result, they are more likely to try to get the technology that they personally want instead of achieving the consensus of the SMEs that a business analyst is trained to develop.
The BASA (Business Analyst / System Analyst) role might seem to be a happy convergence based on the need for analytic skills in both roles. However, the diverging focus (technology versus people) tends to be a fly in the ointment. People who enjoy delving into technology all too often are not very people–friendly and that is one of the primary skills needed by effective business analysts.
An arguably even more challenging combination is the BADE (Business Analyst / Developer). Developers really tend to get turned on by the latest, greatest technology and would rather try to find a problem that this technology would solve than to bother figuring out what the business community wants. Since the prime focus of the business analyst has to be on the latter, the primary skill required by a BADE would appear to be schizophrenia — not a skill we teach or recommend.
The BATE (Business Analyst/Test Engineer) is actually a combination that we can at least support to a certain degree. Since the BA has to define the requirements and the TE has to test whether they were implemented, this role appears to be a match made in heaven. The only caveat here is that testing should not focus solely on the requirements but should also encompass dimensions of which the business analyst may be blissfully unaware — things like infrastructure limitations, coding standards, and so on. If the TE component is restricted to end–user acceptance testing, we actively support this combination in our training offers.
The Rest of the World
We realize that there are many other potential combinations of responsibilities out there in the corporate world, especially super–combinations such as BAPMSA, BASATE, SMEDE, and more, but this should get the idea across. In order for us as a training organization to deliver value to our customers, we are forced to make trade–off decisions. We group the tools and techniques that we teach into skill sets that map in some manner to the real world. Unfortunately, as you see above, the real world steadfastly refuses to conform to our ideal concepts. Most people involved in business analysis also perform other duties. It is these combinations that make finding the right training package challenging for all concerned.
The best recommendation we can offer is to remember that building skills is just like any other building project. It requires focusing on each individual element. Regardless of the myriad of responsibilities assigned to a single individual, the best way to build better employees is one skill at a time. We can build better business analysts — building better people is out of our scope.
