One of the biggest challenges now facing business analysts is this: how do we successfully engage with stakeholders, elicit requirements, and have productive workshops and meetings, without actually meeting in person? The tried-and-tested methods of getting together in a collaborative space, using sticky notes and whiteboards, and bribing attendees with baked goods, are no longer quite so straightforward in a world where some or all of the stakeholders are on the far end of an internet connection.

There are several factors to consider when moving out of the purely physical realm as a business analyst.

There’s always more than one design solution for a software problem and seldom a single best solution. The first design approach you conceive won’t be the best option. As one experienced designer explained it:

You haven’t done your design job if you haven’t thought of at least three solutions, discarded all of them because they weren’t good enough, and then combined the best parts of all of them into a superior fourth solution. Sometimes, after considering three options, you realize that you don’t really understand the problem.

Is your requirements approach friendly to vocabulary, policies and messages? I mean directly. Wouldn’t it be of great help to your organization in achieving its goals if they were? In our experience, policy sources almost always need interpretation and disambiguation to achieve an effective practicable form. As this column discusses, the rule message ‘Reserved for Green Car’ provides an excellent case in point.

It is true that a structural element of the conceptual framework of the BABOK knowledge areas is tailoring. The philosophy that a specific sequential approach does not fit in all circumstances is clear across all the knowledge areas and techniques presented. A business analyst has to critically filter and pick up the most useful techniques and approaches given the specific circumstances.

I was teaching a business analysis course recently and noted that few students had used a Fishbone Diagram along with the Five Whys for root cause analysis. This motivated me to write an article on root cause analysis using the combo method along with a short example.