Good business analysis can bring untold benefits to an enterprise by bring power through simplicity and enabling quality information systems to be built to support and accelerate business success.
Bad business analysis can bring untold misery to an enterprise and can lock the staff inside complicated and inefficient procedures supported by poor information systems that severely restrict enterprise growth or can even bring about the demise of the enterprise.
In fact, good analysis is easier to do than bad analysis, so why do so many analysts choose to do bad analysis?
I have listed the five errors below that cause most business analysis projects to go wrong from day one.
Fatal Error 1: Starting Requirements Gathering at Too Low a Level.
Most business analysis projects fail right at the start.
For any major project to be successful the enterprise requirements must be defined by the most senior executives within the enterprise. Sadly, this is rarely done, or done so ineffectively that it is a total waste of time.
The are three main reasons why this is not done:
Novice analysts do not know how to do it
Older analysts think they don't need to do it
Senior executives abdicate their responsibilities
The Novice Analyst
Novice and inexperienced analysts often feel intimidated with the thought of interviewing senior members of the enterprise. They are afraid of getting it wrong and wasting the time of these busy people. So they try to avoid doing it and try to gather information wherever else they can across the enterprise.
Being inexperienced, they usually go to people in the enterprise who operate the current systems and are doing the hands on day-to-day activities within the enterprise, believing that these people will surely know what is required. Wrong!
People who are dealing day-to-day with the existing systems will definitely be fully aware of their inefficiencies and some will be full of bright and imaginative ideas of how to overcome these inefficiencies. The novice analyst will then gather a list of these bright ideas and, understandably, think that these represent the true enterprise requirements. Quite Wrong!
The Older Analyst
Analysts who have been around the enterprise for a long time, "know" what is needed. They have seen it all before. They have become business "experts" they do not need to ask senior management; indeed they have been around longer than any of the managers.
So, they take over the role of senior executives and put together yet another list of requirements like they have done so many times before. Wrong!
Senior Executives
Senior Executives, whether they are directors or managers, are busy people. They have more things to worry about than what a computer screen should look like or how best to tune a business process. This is why the business has business analysts and an IT department.
If asked for time for an interview they will often reply "You are the systems experts. That's what we pay you for. Get on with it. We trust you." Flattered by being given such trust, the IT department gets on with it. Wrong!
What's Wrong With That?
All of the above approaches start the project off in entirely the wrong place.
The novice analyst's list of suggested improvements for the existing systems may well improve the performance of the existing systems in doing whatever it is they are doing, but is what they are doing what the enterprise requires?
Legacy systems, are far too often doing something that might have fitted the bill at one time but is now far from what is needed. Making them more efficient is, in a perverse way, accelerating the enterprise to the wrong place.
The older analyst needs to learn that age is not experience and longevity is not learning.
If the older analyst is so good at analysis and such an expert on what the enterprise needs, how come the systems need changing yet again?
Analysts are not and ought never see themselves as business experts. Analysts are analysis experts - well good analysts are.
A good analyst will always ensure that the enterprise requirements of any project have been clearly defined by senior executives before proceeding further.
What do you do if senior executives are not willing to give their time to make clear what their requirements are? Simple - Stop the project!
It would be foolhardy and irresponsible to do anything else. If the captain of the ship is not willing to take time to tell the crew what the ship is meant to be doing and where it is meant to be bound then it is not up to the crew to set sail and hope for the best.
Neither can analysts or senior executives use "confidentiality" as an excuse for not eliciting or giving the necessary information. It is better for the business to stop the project than to waste time, effort and money heading blindly forward with the illusion that doing something will benefit the enterprise more than doing nothing.
Fatal Error 2: Modelling What is Currently Done in the Business Believing it to be What Ought to Be Done.
This error arises as a result of Error 1. When nobody has bothered, for whatever reason, to find out from senior executives what it is the enterprise is meant to be doing, then all paths taken after that are the wrong paths.
For the novice analyst the error is understandable, for the older analyst the error is inexcusable.
As I pointed out in Error 1, novice analysts, being inexperienced, mistakenly believe that talking to people in the enterprise who operate the current systems on a day-to-day is the ideal place to learn what the enterprise requires.
Older analysts, who know exactly what the enterprise needs, will want to cover their backs by producing some sort of documentation or business model prior to building or modifying a system, so they will start documenting, or get a junior analyst to document what already happens in the enterprise.
At this point some analysts may be prepared to concede that what is currently happening in the enterprise is not what is required but, instead of asking the appropriate people what OUGHT to be happening, they make the error of thinking that they can use their analytical skills to infer what ought to be happening from what is currently going on. Wrong!
This is perhaps the most common error perpetrated around the globe and is, perhaps, the prime reason why so many IT departments fail to deliver real business improvement.
Trying to infer what OUGHT to be happing in an enterprise has been likened to trying to infer what ought to be happening in a five star restaurant by looking in the garbage bins out back.
Fatal Error 3:Using Process Modeling as the Primary Business Modeling Technique.
The practice of using Process Modeling to model all of the activities was introduced when Business Process Engineering (BPM) was in the ascendancy.
The concept of Business Processes that transcend departmental boundaries is a powerful one and ought to be embraced by all organisations where departments are managed by different individuals.
However, not all that happens in an enterprise is a Business Process and should not be modelled as such. Using Process Modeling in this way is a huge waste of time, effort and money. It generates up to 300% more diagrams than are necessary and misses out up to 30% of essential business activities.
When people attempt to decompose processes it also introduces logically flawed structures, because Processes are structurally networks, not hierarchies.
The only modeling technique that is ideally suited for modelling all activities across all or part of an enterprise is Function Modeling. This is true at three levels:
Everything that happens in an enterprise is a Business Function
Business Functions are hierarchical in structure
It produces no redundant models
Fatal Error 4: Modelling 'How' as Opposed to 'What'
Having made all of the errors above, analysts then compound them all by modelling mechanisms as opposed to functions and procedure as opposed process. In other words they model the "how" as opposed to the "what".
This error now permeates nearly the whole of the business modelling industry as can be evidenced by the majority of the "Process Modelling" on sale being essentially procedure modelling tools.
The saddest part of the story is that the majority of analysts cannot tell the difference.
Fatal Error 5: Modelling Data Separately From Function
The final error that prevents the maximum benefit being delivered to the enterprise is that of separating what people call "business analysis" from "data analysis".
This separation can happen at two levels:
Organisations employ or produce "Business analysts" who cannot do data analysis.
Those analysts doing data analysis start looking for data elements using entirely different sources used by the business analyst for function analysis.
All good business analysts should be able to do data analysis. Contrary to popular belief it is not a dark art and can be practiced quite easily by any intelligent business analyst - provided that they are given the proper training.
The only data required in any enterprise is that needed to support the business functions - nothing more, nothing less.
So all of the information regarding the required data elements - entities, attributes and relationships - can be found from the same source materials from which the business functions were derived. Put simply, every noun in a Business Function name is a Data Entity or Attribute.
However, if the analysts did not model the business functions but instead modelled mechanisms and procedures then the correct data elements will be hard to find!
Are all of the errors above common?
Sadly, yes. Have a look at all of the blogging being done on the Internet regarding business analysis and requirements definition and you will see what I mean.
Is there a solution?
Simply apply the following rules at the start of any business change or a systems development project:
Find out from the most senior executives in the enterprise what the business OUGHT to be doing.
Never try to infer what ought to happen in the enterprise from what is currently being done. To do so is little more than an entertaining - but expensive - analysis conundrum that can bring no benefit to the enterprise.
Never use Process Modelling as the primary modelling technique and never decompose processes. Function modelling is the only modelling technique ideally suited for this.
Always model WHAT OUGHT to be happening as opposed to how things are currently done. When you have sorted out the "what" and the "ought" you can then, when you get to modelling business procedure, define HOW things ought to be done.
Always model data from exactly the same source materials from which you derived the business functions.