Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

Five Fatal Errors for Business Analysts

Proper business analysis can bring untold benefits to a business by bring power through simplicity and enabling quality information systems to be built to support and accelerate business success.

Bad business can bring untold misery to a business and can lock the staff inside complicated and inefficient procedures supported by poor information systems that severely restrict business growth or can even bring about the demise of the business.

Good analysis is in fact easier to do than bad analysis, so why do so many analysts choose to do bad analysis.

In this article I have listed the five errors 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 business 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:

1)     Novice analysts do not know how to do it

2)     Older analysts think they don’t need to do it

3)     Senior executives abdicate their responsibilities

The Novice Analyst

Inexperienced and novice analysts often feel intimidated with the thought of interviewing senior members of the business.  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 business. 

Being inexperienced, they usually go to people in the business who operate the current systems and are doing the hands on day-to-day activities within the business, 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 business requirements. Wrong!

The Older Analyst

Analysts who have been around the business 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?

What’s wrong is 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 business requires?

Far too often, legacy systems are 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 business 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 business 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 business 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 business 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 business 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 business who operate the current systems on a day-to-day is the ideal place to learn what the business requires.

Older analysts, who know exactly what the business 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 business.

At this point some analysts may be prepared to concede that what is currently happening in the business 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 a business 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 Modelling as the Primary Business Modelling Technique.

The practice of using Process Modelling 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 a business is a Business Process and should not be modelled as such.  Using Process Modelling 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.

It also introduces logically flawed structures when people attempt to decompose processes, because Processes are structurally networks, not hierarchies.

The only modelling technique that is ideally suited for modelling all activities across all or part of a business is Function Modelling.  This is true at three levels:

1)     Everything that happens in a business is a Business Function

2)     Business Functions are hierarchical in structure

3)     It produces no redundant models

Fatal Error 4: Modelling How as Opposed to What

Having made all of the above errors, 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 business is that of separating what people call “business analysis” from “data analysis”.

This separation can happen at two levels:

1)     Organisations employ or produce “Business analysts” who cannot do data.

2)     Those analysts doing data analysis start looking for data elements using entirely different sources used 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 business 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 business functions but instead modelled mechanisms and procedures then the correct data elements will be hard to find!


Are all of the above errors 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?  Yes and it is simple.  Simply apply the following rules at the start of any business change or a systems development project:

  1. Find out from the most senior executives in the business what the business OUGHT to be doing
  2. Never try to infer what ought to happen in the business 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 business.
  3. Never use Process Modelling as the primary modelling technique and never decompose processes.  Function modelling is the only modelling technique ideally suited for this.
  4. 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.
  5. Always model data from exactly the same source materials from which you derived the business functions.


5 Responses to “Five Fatal Errors for Business Analysts”

  1. James June 14, 2009 12:50 pm #

    Mr. Owens:
    Let me try to explain about process ownership. We cannot assume that when processes have assigned owner, and that manager is going to say,”this is my process and I will run it anyway I want”. This is where policies come in in the governance. The manager being a process steward is responsible and accountable for abiding by the governance policies. Any improvement or adjustment to this processes responsibility is solely fall on the responsibility of this individual. Collective ownership will not work in this regard. Ofcourse, the nature of the process cutting across many organizations only bring people to get collaborated for the benefit of the whole instead of the one. Just like there data ownership, there should be process ownership as well. It is actually trace back most of the business problems today related to business processes that has not owner and therefore no accountabilty. When asked who is accountable, there would be many since there is no single owner. Carefully defining ownership, assigning responsibility and deligating authority with limitation are some of the key responsibilities of governance council and steering committee. This would lead to successful process governance execution.

  2. John Owens June 14, 2009 12:30 pm #

    Hi James

    The power of a business process is that it is independent of organisation structure and cannot be owned by any single manager in a business can say “this is my process and I will run it any way I want”.

    A single manager might be assigned the primary responsibility for leading the definition and optimisation of the process on behalf of the business but the process will have many stakeholders or “owners”. There will often be arguments and disagreements and these will need to be resolved.

    The term “Governance” has a very specific meaning in law which is not valid when talking about the management of business processes. When people are tempted to use this term I advise them to ask themselves “what do I really want to mean?” and the say that in plain English. This avoids the misuse of the term and brings clarity to their message.

  3. James June 13, 2009 6:34 am #

    Your comment regarding “Ownership” of process has to be well managed, is very valid. But, your comment “it (namely, process) cannot be owned by a single manager” is not necessarily true. When you are looking at the organizational structure (org chart), it may appear individuals and their job functions and responsibilities. Org Charts are developed to manage business resources and have responsibility and accountability. Process Ownership concept is promoted heaviliy in the Business Governance aspect of the enterprise. Process Ownership is a must and should be assigned to an individual. Although, processes cut across multiple organizations, assigning core business processes to individuals and defining the responsibility of that individual regarding that assigne process is the key. Without such ownership, there would be room for many arguments and disagreements. Collaboration is essential at the same time, process ownership brings its own benefit in the Process Governess.

  4. John Owens May 5, 2009 9:35 pm #

    Hi Larry

    I totally agree that at the stage of designing processes and procedures that the managers who will be responsible for running those processes should be heavily involved in the design of what will be “their” processes.

    It is essential that they are ably assisted in this by an experienced business analyst who can show them how to achieve power through simplicity and help them to tune the processes.

    Having the business “own” processes can bring huge benefits in the “buy in” to change – provided it can be demonstrated that the change will bring real business benefits and not be yet another failed project.

    “Ownership” of processes has to be well managed. Because a process will cut across the organisational boundaries of the business, it cannot be owned by a single manager but by a body of stakeholders.

  5. Larry Maccherone May 5, 2009 12:22 am #

    Not being a business analyst myself, I’m not exactly clear on the distinction and comparative benefits of function modeling over process modeling, but as a facilitator for software process definition and a developer myself, the other four ring true.

    For Fatal Error #1, I would even go a bit farther. Senior management clearly set the requirement priorities. In software process design, that’s necessary but not sufficient. The design for how to meet those requirements must be created by those who will implement and execute the process. My role is to facilitates the design and implementation process and to make sure that the team calls it their process. If they call it my process or Senior Executive X’s process, we’ve failed. The implementation will be implemented half-heartedly.

Leave a Reply