Inteq Blog

Welcome to the Inteq Blog

Business Process Reengineering

What is the Role of a Business Analyst?

Today’s rapidly changing business environment favors high-performing agile organizations capable of delivering extraordinary customer and business value. Business processes and supporting business systems need to continually change, adapt and in many cases transform to keep pace.

Business processes, however, in many cases evolve informally, ad-hoc and slowly. The result is that many business processes are a tangled web of inefficient work activities, ambiguous policies and legacy procedures that consume resources and impede performance.

These same processes, unfortunately, often provide the source for business and business systems requirements - requirements that reflect legacy business rules that constrain, rather than improve, business processes.

What is the Role of a Business Analyst?

For the purpose of this post I’ll go with IIBA definitions as a baseline – with some clarifying commentary. The role/title “Business Analyst” includes, per IIBA, “business systems analyst, systems analyst, requirements engineer, process analyst, product manager, product owner, enterprise analyst, business architect, management consultant, business intelligence analyst, data scientist, and more.” Business Analysis, per IIBA, “is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”.

The value of business analysis, per IIBA, “is in realization of benefits, avoidance of cost, identification of new opportunities, understanding of required capabilities and modeling the organization. Through the effective use of business analysis, we can ensure an organization realizes these benefits, ultimately improving the way they do business.”

For the remainder of this post, I’ll narrow the scope of IIBA role/titles above to Business Analysts (BAs) and Business Systems Analysis (BSAs):

  • The focus of a Business Analyst (BA) is on business requirements – particularly from a business process perspective – including work activities, workflows, work activity procedures, mechanisms (including supporting information systems), roles and organization reporting relationships, etc.
  • The focus of a Business Systems Analyst (BSA) is on business systems requirements – the requirements that specify how a business system supports/enables work activities in a business process and the user roles performing the work activities in a business process or in a decision making role.


With that distinction noted, I’ll use the term Business Analyst to include the business analysts and business systems analysts. So, in a nutshell, the role of a Business Analyst is to get the “requirements” right.

The Big Problem – Superficial Analysis!

Getting the “requirements” (business requirements and business systems requirements) right is difficult. Most organizations struggle to get the requirements right, regardless of the amount of time and resources expended on the effort.

Business analysts are intelligent and well-intended. However, a core problem is that analysts, in many cases, superficially scratch the surface of the business space being analyzed. The resulting “requirements” are not sufficiently deep, precise, thorough, or accurate enough to be useful.

The primary reason for superficial analysis is not due to inadequate time for good analysis - although there is rarely sufficient time to get it perfect. The primary reason is that many business analysts, even very experienced BAs are not asking the right business questions.

Superficial analysis results in superficial requirements, usually in the form of bullet lists and indented outlines of vague business ramblings, which are subject to substantial interpretation, frequently resulting in business processes, procedures and supporting applications that do not adequately support business and user requirements.

Many critical business requirements and deep core supporting business rules (including the numerous variations and exceptions to the rules) are not discovered until the business process and/or business system goes live.

These core rules and requirements were not articulated by the business stakeholders (subject matter experts, end users, functional managers, etc.) during analysis, because the business analyst did not fully engage the stakeholders and did not ask the right kind of business questions during analysis.

Missing, incomplete and/or inaccurate requirements that are discovered in production are, at best, extremely expensive to resolve in production. More often than not, the production systems (new development, modification of existing system, vendor software, etc.) which are based on superficial requirements cannot support the core rules and requirements discovered during production.

What is an Effective Business Analyst?

An effective business analyst gets the “requirements” right. An effective business analyst is a professional that deeply engages stakeholders in requirements discussions vs. an order-taker that superficially / transactionally interacts with stakeholders. An excellent way to think about this distinction is to compare a fast food restaurant experience versus a fine dining restaurant experience.

Fast food server taking a woman's orderVisualize that you are at a fast food restaurant and think about that person at the service counter. The person at the service counter superficially interacts with the customers, but there level of engage is transactional. The role of the person at the service counter is to act as a set of hands for that customer that wants to place an order. The service counter person asks questions such as “what do you want?” “Do you want it with this or that option?” “What size do you want?” “Can I supersize it for you?”

The interaction between the counter person and the customer is very transactional level. Which is fine for taking a fast food order. I’m not critical of that person’s role by any means - that’s the role of the counter person - to interact with the customer in a rules based manner to ensure what the customer wants is properly enter into the point of sale terminal. It’s a superficial transactional level of customer interaction.

A server at a fine dining restaurant helping customers choose a wineNow let’s look at a fine dining experience. The server at a fine dining restaurant deeply engages the guests at the table. The server is no going to say things like “hey, what do you want, what do you need, can I supersize it?” No way, the server is a professional – not simply an order taker. The server understands how to engage the guests at the table. The server has product knowledge, business knowledge – the server understands tonight’s specials and which wines pair with which appetizers and entrees. The server creates a very engaging customer experience with the guests at that table. That’s the deep level of sophisticated customer engagement that is essential for effective business analysis.

Right there is the distinction between a professional server and an order taker. The person at the counter at the fast food restaurant is an order taker. I could onboard a new employee at the fast food restaurant, provide 30 minutes of order taking training and they are ready to start taking orders. The server at the fine dining restaurant is a professional. It takes years of experience to acquire the level of skills, knowledge and judgement to become an effective professional server and to fully engage guests at the restaurant.

The distinction between a fast food order taker and a fine dining server is precisely the distinction between a business analyst that is an order taker and a professional business analyst. A business analyst that is an order taker interacts with business SMEs and stakeholders from a transactional perspective.

A professional business analyst deeply engages business SMEs and stakeholders using skills, knowledge and judgment gleaned through significant hands-on experience. A professional business analyst gets the “requirements” right!

For a deeper discussion and best practice tips on engaging SMEs and stakeholders in analysis I encourage you to read my white paper “The 5 Essential Business Analysis Questions."

Read White Paper

* * * * *

Today’s rapidly changing business environment favors high-performing, agile organizations capable of delivering extraordinary customer and business value.

Meeting this challenge often requires transformative change - and sustainable on-going improvement in business processes, organizational culture and supporting technologies.

The Inteq Group is uniquely qualified to assist your organization with this challenge.

James Proctor

James Proctor

James Proctor is the Director of Professional Services for The Inteq Group, Inc. and author of Mastering Business Chaos. He frequently lectures on business strategy, innovation and business transformation and serves on the board of commercial and non-profit organizations. Proctor is the author of Inteq’s acclaimed Business Analysis training series - reaching over 300,000 business and I.T. professionals worldwide. Proctor developed Inteq’s MoDA/Framework™ and Inteq’s BPR360/Framework™ - which have been adopted as a standard for business analysis by organizations around the world. In his book, Mastering Business Chaos, he reveals secret patterns he has discovered in thousands of client interactions ranging from Fortune 500 to emerging growth companies and government agencies throughout the spectrum of industry. The Inteq Group is a team of top industry professionals that provide business analysis training and consulting services, application software development services, and big data solutions to commercial and governmental organizations worldwide. Proctor has a B.S. in Industrial Management and Operations Research and an MBA in Information Technology from Indiana University. He started his career with the firm of Ernst and Young (formerly, Ernst and Whinney) with their consulting group in Dallas and specialized in the aerospace, financial services, manufacturing and defense industries.