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.