Many of my business analysis colleagues and friends have been through the business analysis body of knowledge (BABoK). BABoK clearly describes that there is really no timing relationship possible in business analysis tasks.  It is true. Business analysis can start at any point can iterate many times during an initiative. However, most often thoughts around the business analysis have been confined to project perspectives. However, business analysis as an activity is beyond project perspective.

In this blog, I am going to share my experiences of dealing with requirements for almost the last 25 years now and what I have observed as a business analyst and as a business owner as well.

As per BABoK, we usually start with Strategy analysis or Solution evaluation knowledge area. This is possibly true from a project perspective.

When we think from an enterprise perspective, the knowledge area that extends almost the entire life cycle of an entity or business is Requirements lifecycle management. The moment an organization is born, the needs also take birth. For example, when we start a new business, we need to start bookkeeping. Will we run any business without bookkeeping? When would needs completely vanish? Only when possibly the organization dies. This means requirements lifecycle management tasks would survive the entire lifespan of the enterprise.

Should we plan requirements lifecycle management activities at the enterprise level? Ideally, yes. However, I have not seen this really being practiced in most organizations. The possible reason again could be our focus being quite intense at project level but quite low at an enterprise level.

The solution evaluation life cycle is quite interesting. When a change is implemented, we would usually carry out solution evaluation once the solution is in use for a certain period. We need to check if the solution is providing you the right value and modify the solution to get the maximum value that you can.

However, one can do periodic solution evaluation for already existing solutions. We do this activity once in half-year in our company looking at what kind of situations we have and what kind of value they bring to the business. This way, we can see that solution evaluation has been repeated multiple times in the enterprise life cycle.

To elicit, we need planning. So, from that perspective, planning starts before elicitation. Sometimes elicitation can be unplanned as well. I would leave these two tasks to be quite close to each other in a timeline perspective.

Once we have elicited high-level needs, the time comes in the business analyst life to choose how to fulfill the needs in an effective manner and that's strategy analysis. If we look at the diagram, the strategy analysis usually kicks off after we do some elicitation. Some elicitation is needed so that we have reasonably detailed idea about our needs. Once strategy analysis is done, we can start requirement analysis and design definition area which follow elicitation.

I am no way prescribing any methodology saying that one has to do this kind of work but possibly one should keep this map in mind to understand what type of business analysis activities would possibly be getting an importance over others in a specific and Enterprise timeline I would be quite happy to receive feedback and suggestions on how do we make this map proper correct and more useful to our business analysts thank you and have a great day.