I have been  pondering recently on the importance of adaptability for a business analyst.

Definition of adaptability

It seems to me that adaptability is a key skill of a business analyst because no two projects are alike. It’s not possible to apply a template approach to every project situation with which you are confronted.

However, I looked up synonyms for adaptability and came across these - malleable, pliable, adjustable, compliant, easygoing. You need to be adaptable but these are sending out the wrong message - although it is important to be adaptable, equally you cannot be a pushover! The business analyst must have a set of principles that they work with and these should not be contravened.

Example

In a recent engagement, an existing project was in flight but hadn’t accommodated the requirements of another business unit as they had been unable to supply resources at the time requirements were being gathered. It was also understood that many of their requirements would match the existing set as the project was driven by new regulations that introduced new processes which all would have to follow.

I was invited to gather their requirements but time was of the essence as the existing project had progressed and was completing high level design. Any delay could risk the main project and there was a fixed deadline when the new regulations had to be met.

I recognised that we had to attempt to dive to the detail during requirements gathering in order to rapidly identify the ‘hot areas’ where the differences existed or were most likely to exist. We agreed an approach that would start with the new business process walk through without an analysis of the project goals and/or identification of the critical success factors. Once the hot areas were established, we would drill down into the detail and identify detailed requirements in these areas. This was the adaptable bit.

One principle I operate is to ensure that the early stages of the project are conducive to successful business acceptance testing. This means that all the requirements must be complete,  clear, unambiguous and measurable (for more on this, see Requirements engineering and quality). In order to achieve this, the critical successs factors, business objectives and all of the existing requirements would need to be revisited after this accelerated approach. It would have to be analysed and documented whether and how they would apply for this new business unit.

Dogma

I have mentioned before (and will again) that I don’t like dogma. Anything that encourages you to follow an approach blindly feels, instinctively, that it has to be wrong. However, there is a paradox as I have certain rules that I see as inviolable which must always be observed.

The difference is that these are principles which don’t dictate how you go about something but it is important to be aware of them at all times. At any time in a project, you can refer to these principles, consider if you have adhered to them and measure your success on the project against these.

These are just my views - as ever, I would welcome any other points of view.

Alex Papworth, (this was taken from www.businessanalystmentor.com)