The world's not always perfect

In my previous post I mentioned the world is not always perfect. In this post I will list out some of the challenges of a business analyst.

These challenges can be thought of as originating within the project boundary, within the organizational boundary and those external to the organization (Read the blood sucking client!)

Challenges coming from within the project could manifest itself in the form of wrong resource skill mapping (How the hell can a tee-to taller mix a drink?) Attrition (Ask your self how often have you lost a good team member, and the problems you had to face with the knowledge transfers) . Of all said, Cloudy requirements is an Analysts biggest nightmare, and a good part of their free time is spent on devising ways to come up with concrete requirements for the team.

Challenges coming from within the organizational boundary might include company strategy, goals etc that might not just fit in with your project needs. Imagine executing a complex large project under an organization which has a policy of having at least 60% crowd in a project as fresher’s. Scary! I know, and even a bit exaggerated. How about a process which takes too much time, and yet is required to be implemented according the company policy.

I will talk about more example of the above two types later, for now let me tell you about the most important source of challenges or pains for a Business Analyst. Surprised? Yes, it the blood sucking Client. (Disclaimer: Even tough client is referred derogatively, some of them are nice. They are after all people doing a job, and sometimes their jobs are at stake over success of the project) The biggest challenge here is creating that shared understanding. You know the client wants an orange. The client knows they want an orange. Yet you and the client would like to be sure that the exact details of orange are mutual. Software’s are not like oranges, where every orange is the same, save for some variations. Every software is unique, unless you are working on products which have their own share of pains.

A client would typically like to know what you mean by an orange, and would fill in some important gaps and also provide additional inputs.

The shared understanding is requirements driven from the client side. These requirements are mostly functional, with some non-functional requirements thrown in. The set of capabilities represented by the functional and non-functional requirements is what the client is paying for. There may be other requirements related to training, maintenance warranty, support etc which would be needed to be defined in Service Level Agreements for the Client.

Another nightmarish challenge faced from the client side are changing requirements. Tough this is something that can not always be blamed on the client. Maybe your analysis was not detailed enough and you overlooked some features. Maybe this feature should have been a part of the initial shared understanding. Nevertheless, every Business Analyst is faced with the inevitable change. Remember- The only thing certain is Change.

These changes could be as a result of changes in the clients business domain, changes with the client strategy, goals for the software etc. This could also be because the client is yet not sure what should be the system's full capabilities.

Change can be a big killer. Imagine the change coming in at a stage where the software has significantly evolved over it's project phases. This change could not only be expensive, sometimes non-feasible with the overall design. What if a lot of features are dependent on the feature to be changed?

Handling change is a big job, and it's interesting how a business analyst has to tactfully act as a change agent at times.

So what does a business analyst do for a living?

I keep drawing curious looks when i tell people that I work as a Business Analyst. What do you do exactly as a business Analyst? they ask. Do you sell software?

I tell them that i manage the requirements for the project. Which in a sense involves "Creating a shared understanding" between the project sponsors and the tech people.

Note the stress on "Creating a Shared Understanding". Without a clear direction of what needs to be done there would be utter chaos. And my job is exactly to ensure that we never face such a situation. But then the world is not always perfect.

Creating is not enough, it should be documented and agreed upon. The level of documentation would depend on various factors like the methodology being followed, size of the project etc.

The next big question is "How does one create a shared Understanding?" Now this is something which will take some time to be explained. In fact it is not one single way of creating a shared understanding. I would be blogging posts about this later in more detail.

Be warned! the job does not end at just creating a shared understanding. An Analyst would be associated with the project throughout it's life cycle.

The Analyst has to ensure all the requirements are well covered in the designs. This would require the analyst to have some level of technical understanding.

The Analyst will be extensively involved in the development activity to ensure all developers are in sync with the requirements, and know what they are supposed to do.

This may also involve testing the functionality of the developers work, reviewing the test cases for the various features involved, ensuring all requirements are developed and tested. No one likes to give a buggy software do they (Unless you work in Microsoft)?

Ultimately if all goes well, the analyst would prepare for the release of the project.

This would involve preparing for the User Acceptance Test -The sponsors would definitely not accept the software blindly without conducting some tests on it to ensure it's of high quality and it satisfies all the shared understanding we had created and agreed upon initially. An analyst would also have to prepare for the training needs of the software, deployment of the software etc.

All said and done, this would be the some of the roles of a Business Analyst in an Ideal world scenario. But then---"The world's not always perfect".