Fundamentals of Business

The Fundamentals of Business Analysis

Business Analysis is a straightforward process of analysing business change requirements. Why, then, are there so many methods, approaches, techniques and tools for doing what is - essentially - the same job? In order to understand this, we need to rewind a bit in time to look at where Business Analysis came from, where it currently is and projections for where it will go.

The History Bit Business Analysis was born out of the fact that IT change projects started to go wrong in the 1980s. Before that, IT change projects could solve a limited set of problems in a limited way because the only options were to turn paper based data into electronic data and have simple programs automate the use of that data.

There were many limitations such as:
. storage of the electronic data was expensive
. the way data was stored was cumbersome (flat files read sequentially in one direction only).
. programs were difficult to write in abstract languages
. there was only a limited set of functionality based around mainframe processes
. user interfaces were delivered on basic green-screens

Since the 1980s things have changed: data storage has become cheaper and covers not just paper based data but audio and visual data too; relational, object orientated and other databases have made access to data easier; programming languages have evolved in usability and functionality; processing is no longer constrained to mainframes but distributed with increasingly sophisticated user interfaces.

...Then along came the internet generating a whole new market place and set of business models, as well as a new set of technological possibilities. We also now have thousands of 'legacy' systems being upgraded, merged and replaced. It seems the universe of business solutions is an ever expanding one.
The result of all this was that there are many more choices to make at each stage of an IT and/or any other type of change project and with that increase of choice comes the increasing likelihood that the wrong choices are made – wrong not in the sense of not working, just wrong for what the Business require. Unfortunately, not only does making the wrong choice invalidate the subsequent work based on that wrong choice, the earlier in the project that a wrong choice is made, the greater the damage is in terms of how much re-work is required. To make matters even worse than that, the larger the project or programme the bigger the disaster (Government projects seem to hold the trophy here!).

The following diagram illustrates this principle: