27 January 2013

Chess and the Art of Business Analysis - Part 5

Knowledge area 5: Requirements Analysis

This is the fifth post in a series which identifies similarities between the thinking skills required to play the game of chess and those demanded by the discipline of business analysis. Each post has used one of the knowledge areas described by the BABOK to frame the ideas, in this case knowledge area 5 which is Requirements Analysis.

This knowledge area is about consolidating all the information gathered during the business analysis process and using this information to develop and describe a possible solution to whatever business problem you are attempting to solve. The challenge for BA's working in this knowledge area is that not only do you have to develop a solution, you also have to be able to propose a way to get there. This requires an understanding of the current state, as well as the desired state and the gap between them.  Often the gap is tricky territory to navigate; delivering business value in terms of costs and benefits is not always the highest priority, there will always be assumptions, dependencies, constraints and risks to manage. Requirements analysis must take all these things into account when proposing a solution.

In practical terms, this usually means that an agreed set of tools and techniques are used to define, build and describe one or more solution models which solve the business problem and clearly take into account the priorities of the business. The objective being to describe the requirements of the solution in sufficient detail for them to be understood and implemented.  In plan driven environments, this tends to be done in phases and is seen as a discreet activity, resulting in a complete/finished model. In change driven environments this is recognised as an activity which is done on a continuous basis and which results in a model which evolves in it's level of detail. However, whilst the form and frequency of requirements models vary greatly from project to project, the thinking skills required to produce them are methodologically agnostic and demand the ability to use abstraction to think inductively and recognise patterns.

In chess, the very specificity of the valid moves for a given chess piece lead to necessary improvements in your ability to recognise patterns. Without a clear understanding of chess attacking patterns, also referred to as tactics, you are vulnerable to them. Not recognizing a  discovered attack or fork quickly leads to dismay. 

Many of the principles which apply to the game of chess could be very usefully applied to requirements analysis, such as "develop plans, not just pieces" which reminds the player to think about the why of every move. Asking why, until you understand your opponents strategy is fundamental to survival for the chess player. Another key skill  is the ability to extrapolate the most likely outcome from a series of moves, both yours and your opponents. The sheer number of possible outcomes which result from the interactions of the pieces is massive, however understanding the  relative or perceived value of a particular piece to your opponent, assists you in planning not only your moves, but anticipating the most likely of your opponents possible responses to your move.  In requirements analysis, this is analogous to understanding business drivers and the extent to which these influence the way in which a given business will prioritise its requirements.

Chess and requirements analysis both require you to generate an overall strategy, or more realistically several strategies, and then to work using a set of  principles to inform your selection of the best tactics which will fulfill your goal. Both activities require not only systems thinking, but also the ability to develop, construct and maintain multiple mental models.