Curiosity

You may not believe the client or some stakeholder when they tell you something. What they are saying might contradict what another stakeholder had to say.  But let curiosity outweigh judgment.  Why is this person saying what they are saying?  Even if it isn’t right there must be a reason for it. As my friend Karl Weigers says, “The customer may not always be right, but he always has a point.”  Do you know what the point is? Be curious, ask questions.  As George Nathan Miller says in what is now called “Miller’s Law”: “If you truly want to understand what another person is saying, first assume that it is true, then find out what it is true of.”  Value curiosity over judgment.

BA without IT knowledge

A recent posting on LinkedIn was by a training company looking to attract prospective business analysts to their classroom to learn how to gain IT knowledge in order to become a business analyst.  The pitch was based on some idea that all business analysts are IT based and need IT experience and knowledge, and this training company could provide those elements and make you a business analyst.

We have to remember that there were business analysts (and there still are) who do not work with IT.  They do not prepare requirements for software development.  There are business analysts who analyze the business for purposes of merger, acquisition, divestiture or other organizational change. There are business analysts who analyze the market for new products potential, or the competition for weaknesses that can be exploited or the business climate to identify new investment or market potential.  There are business analysts who assist executives in making strategic decisions.  All of these business analysts existed long before computers were used for business, long before software developers needed requirements. 

If you are coming from a business based background do not be concerned about getting into business analysis.  There is a wide range and big need for people who can communicate, analyze, understand the business, and solve business problems, with or without computers, IT or software development.

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.