Not all business analyst jobs are created equal

I have a client who is a systems integrator, that is, most of the work the client does is for other clients.  We are working on a business analysis process for the company.  My point of contact asked me if there is a difference in the activities or approach of business analysts based on whether the business analyst is doing work for a client or for an internal project.

Clearly the job of business analysis is basically the same regardless of whom you are doing it for.  The business analyst still has to determine the real problem, analyze the environment and problem domain, and come up with solutions.  Then the business analyst has to define the solution in such a way that the solution team can implement the solution. And this is done whether the problem is the organization’s problem or a client’s problem. 

But there are some differences.  The obvious one is in documentation.  Different companies and organizations have different standards for documentation. So a consulting business analyst will have to be fully cognizant of the client’s standards before starting the project.  As much as we hate to admit it, as human beings the output format has a direct effect on how we do the job.  We will actually focus on different aspects of the problem or problem domain depending on how we have to document the result.  For clients this is not a bad thing. If they want UML diagrams of the solution or fully dressed workflow diagrams of the problem domain, they are, after all, paying for it.

Keep in mind that the client has another agenda.  In house we may not be as concerned about the documentation because we can always have a quick meeting and discuss the issues and make changes as necessary.  The client cannot be sure that your company will be around for the length of the contact to fully implement the solution, and most likely will not be around after the job is done.  So the client has to protect itself and make sure that everything you do is fully documented to a state that the client can pick it up without loss of momentum or progress, or hand it off to another contractor to finish.

It is easy to complain about having to be a documenter especially if your solution team is doing an Agile development process.  But remember your point of contact is only concerned about getting the problem solved. The client organization is concerned about getting what they paid for. The client organization wants to limit dependency on you as a contractor and be able to continue to use the solution you install long after you have gotten your last check in payment for a job well done.

There are more differences that are important to know if you are considering changing jobs from an in house business analyst to a consulting company or, indeed, if you are thinking about going out on your own to be a consulting business analyst.

Confirmation, acceptance and approval

Once the solution has been chosen and the requirements to implement the solution have been developed, the next phase requires three steps: confirmation, acceptance and approval, or in the vernacular of the BABOK: verification, validation and approval.  The tendency, driven mostly by tradition, but also by time, is to do all three steps or passes at the same time.

The process is somewhat like that of getting an article published. First you have to make sure the content is correct, then you make sure the grammar, spelling, and so forth are correct (typically called copy editing) and then you have to get the final result approved by the editor or publisher.  When journalists write their articles they go through each step independently with different individuals involved.

While it might be convenient to dress up the requirements document or, as we call it, the solution document, by running it through editing to prepare it for the “requirements review session” and during that session identity what needs to be changed and then get that sometimes elusive sign-off, it is better to separate the three steps.

One step involves the stakeholders who will be using the system or functionality or features you are defining to solve the problem.  The focus is on the content. There is no approval, nor any discussion of format or grammar.  There are tricks to ensure the conversation remains focused on the content.

The second step is an “internal” step with other business analysts or authors of the same material.  This is where the grammar, formatting, conformance to organizational standards, and so forth are verified.  This is typically a peer review or inspection, and the discussion of content should be minimal. This is true especially if the business stakeholders have already confirmed that the requirements solve the problem.

The final step is the approval and the only thing that happens in the approval step is a sigh off. If the other two steps have been completed, the approval becomes a “rubber stamp” exercise since we know beforehand that the document is going to be approved because all parties to it have seen it, confirmed the content, verified the format and accepted it. 

Separating the three steps ensures approval of the document with little delay.  Of course, you have to be sure that in fact the document has been accepted by all the previous reviewers before the approval takes place.

BA - more biusiness or technical?

A recent question came up that is a common one I've been hearing for years. I had thought the concern had been put to rest, or answered once and for all. Apparently it hadn't.  The question: how much business and technical should a typical BA be? What percentage of each? Should a business analyst focus on technical knowledge or business knowledge? 
Here is my answer:

I think there has been an assumption since the BA moved from a very specific position in telecommunications companies in the early 90s to a profession related to IT that the business analyst has technical chops as well as business acumen.  I recall business analysts of the mid-90s being drafted from the ranks of "super-users" (business people who took to computers and helped the others in their business department with user problems).  IT countered by moving Systems Analysts more to the business side starting in the late 80s without giving them the name "business analyst". (I was one of those).  So as can be seen by where the BA hails from, the amount of technical knowledge will vary. 

That said, we should remember that a business analyst analyzes the business. The business analyst solves business problems.  The solution of a business problem may not include software development and maybe not even technology. Note the definition of business analysis from BABOK V3: "Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value."  Doesn't mention software development or technology, only solutions.