2 Business Analysis Fundamentals
In the previous chapter, I introduced you to Business Analysis as a discipline and explained why it matters for your career. Now let us go deeper into what Business Analysts actually do and how they fit into organizations.
2.1 Who Is a Business Analyst?
Here is a surprising truth that many people miss: a Business Analyst is not always someone with “Business Analyst” in their job title. A Business Analyst is anyone who performs business analysis activities. This distinction matters because it means you may already be doing this work without realizing it.
What exactly are these activities? Let me walk you through them.
Business Analysts discover, synthesize, and analyze information from a variety of sources. Think about what this means in practice. When a company wants to launch a new product, someone needs to gather information from customers, competitors, internal teams, and market research. That information comes in different formats, from different perspectives, with different levels of reliability. The Business Analyst makes sense of all this information, finding patterns and insights that others might miss.
Business Analysts elicit stakeholder needs, investigate and clarify desires, and work to understand issues and their underlying causes. Notice the word “elicit” here. It suggests drawing out information that stakeholders may not even know they have. A customer might say they want a “better” system, but what does “better” actually mean? Faster? Easier to use? More accurate? Less expensive? The Business Analyst asks the questions that reveal what people truly need, which is often different from what they initially request.
Business Analysts align designed and delivered solutions with those needs. This is the bridge-building work I discussed in the previous chapter. The Business Analyst ensures that what gets built actually solves the problem it was meant to solve.
Finally, Business Analysts understand enterprise problems and goals, analyze needs and solutions, devise strategies, drive changes, and facilitate stakeholder collaboration. These activities position the Business Analyst as someone who sees the big picture while also attending to important details.
2.2 Where Business Analysts Fit in Organizations
Look at Figure 2.1. It shows Business Analysts positioned between the IT team and the business side of the organization. This placement is intentional and important.
On one side, you have business leaders, managers, and frontline employees who understand their work deeply but may not speak the language of technology. They know what problems they face. They know what outcomes they want. But they may struggle to translate these needs into terms that technical teams can act upon.
On the other side, you have IT professionals who understand technology deeply but may not fully grasp the business context. They know how to build systems. They know what technology can and cannot do. But they may not understand why certain features matter more than others to the business.
The Business Analyst sits in the middle, speaking both languages. This is not just a nice skill to have. In many organizations, it is essential for success. Without this translation function, businesses build systems that technically work but fail to solve actual problems. They spend money on solutions nobody wanted. They miss opportunities because technical possibilities never reached decision makers who could act on them.
2.3 What Business Analysts Actually Do
At the highest level, Business Analysts create or improve information systems. But what does this really mean? Let me unpack it.
A system is a group of components that interact to achieve a purpose. Your body is a system. Your car is a system. Your university is a system. The key idea is that components work together toward some goal.
An information system is a specific type of system where computing components work together to produce information. The banking app on your phone is an information system. So is the registration system you use to enroll in classes. So is the inventory tracking system that helps a warehouse know what products are in stock.
When I say Business Analysts create or improve these systems, I mean they figure out what these systems should do and how they should work. They do not necessarily write the code or configure the databases. But they determine what the code should accomplish and how the database should be structured to serve business needs.
2.4 The Components of Information Systems
Business Analysts must understand all the components that make up information systems (Figure 2.2).
Hardware refers to the physical equipment: servers, computers, mobile devices, printers, and all the tangible technology that makes systems run.
Software includes the programs and applications that run on hardware. This is often what people think of first when they imagine information systems. But software is only one piece of the puzzle.
Processes describe how work gets done. A process is a series of steps that transform inputs into outputs. Business Analysts often spend significant time understanding and improving these processes.
Data is the information stored and processed by systems. Data includes customer records, transaction histories, product catalogs, and countless other types of information.
People are the humans who use, maintain, and benefit from systems. This includes end users who interact with systems daily, administrators who keep systems running, and stakeholders who depend on the information systems produce.
Networks are the connections that allow systems to communicate with each other and with users.
A skilled Business Analyst understands how changes to any one component affect all the others. Upgrading software might require new hardware. Changing a process might require retraining people. Adding new data might require modifying how networks handle traffic. This holistic thinking is what separates good Business Analysts from those who merely follow procedures.
2.5 Two Approaches to Building Systems
When organizations build or improve information systems, they generally follow one of two approaches: the predictive approach, often called Waterfall, or the adaptive approach, often called Agile.
2.5.1 The Waterfall Approach
The Waterfall approach (Figure 2.3) works like its name suggests. Work flows downward through distinct phases, each one completing before the next begins. First, you gather all requirements. Then you design the complete system. Then you build everything. Then you test. Then you deploy.
When should you use Waterfall? This approach works best when certain conditions exist. The objectives and solution should be clear from the start. The project should be large, complicated, and expensive enough to justify extensive upfront planning. There should be no urgent need for immediate results. The project team should already understand what solution they are building. Requirements should be stable and unlikely to change. The organization may require formal approval at each milestone.
Think about building a bridge. You would not want to build half a bridge, get feedback, and then modify your approach. The physics of bridge-building require complete planning before construction. Many software projects in highly regulated industries, such as medical devices or aviation systems, follow similar patterns.
2.5.2 The Agile Approach
The Agile approach (Figure 2.4) takes a different philosophy. Instead of planning everything upfront, Agile projects deliver working functionality in small increments. Each increment provides an opportunity to learn, adjust, and improve.
When should you use Agile? This approach works best when requirements or deliverables are unclear at the start. It thrives when stakeholders are willing to participate actively and provide ongoing input. It works well when the cost of changing direction is minimal. It fits organizations that value teamwork, transparency, and continuous improvement.
Think about developing a new mobile app for consumers. User preferences change rapidly. Competition is intense. Getting something into users’ hands quickly provides valuable feedback that no amount of upfront planning could replace. Many modern software projects fit this profile.
Neither approach is universally better. The right choice depends on the specific situation, and many organizations use both approaches for different types of work.
2.6 How Business Analysts Work: Core Competencies
Being a Business Analyst requires more than knowing techniques and tools. It requires a set of competencies that enable effective performance (Figure 2.5).
Analytical thinking and problem solving sit at the core. Business Analysts constantly face ambiguous situations where the right answer is not obvious. They must break down complex problems, identify patterns, and develop solutions that others may not see.
Behavioral characteristics matter enormously. Business Analysts interact with many different people, often in stressful situations. How you conduct yourself, how you handle disagreement, how you respond to pressure, all of these shape your effectiveness.
Ethics guides decision-making in difficult situations. Business Analysts often have access to sensitive information. They may face pressure to skew their analysis in certain directions. Strong ethics keep them honest and trustworthy.
Personal accountability means taking responsibility for your work. When Business Analysts commit to deliverables, stakeholders must trust that those commitments will be honored.
Trustworthiness extends beyond accountability. It means that people believe you will act in their interests, keep their confidences, and tell them the truth even when it is uncomfortable.
Time management enables Business Analysts to handle multiple competing demands. Most Business Analysts work on several projects simultaneously, each with different stakeholders and deadlines.
Adaptability allows Business Analysts to adjust when circumstances change. And circumstances always change.
Business knowledge provides the context for analysis. A Business Analyst who understands finance will be more effective working on financial systems. One who understands marketing will be more effective on marketing systems. Deep domain knowledge multiplies the value of analytical skills.
Communication skills, both written and verbal, allow Business Analysts to convey their findings clearly. The best analysis in the world means nothing if it cannot be communicated effectively.
Interaction skills enable collaboration. Business Analysts rarely work alone. They must facilitate meetings, resolve conflicts, build consensus, and maintain relationships across organizational boundaries.
2.7 Why Clear Communication Matters
Let me try something together with you. Read this phrase quickly: “A walk in the the park.”
Did you notice anything unusual? Read it again more slowly.
Most people miss the repeated word “the” on first reading. Our brains fill in what we expect to see rather than what is actually there.
This simple exercise reveals something profound about communication. What people hear or read is not always what we intend to say. As Business Analysts, we must be extraordinarily careful about clarity because miscommunication causes real damage. Requirements that seem clear to us may be interpreted differently by developers. Statements we think are precise may contain ambiguities we do not see.
The best Business Analysts develop a habit of checking understanding. They ask stakeholders to explain requirements back in their own words. They use multiple formats to convey the same information. They invite questions and treat confusion as a signal to clarify, not a failure to be defended.
2.8 Critical Thinking in Action
Here is a puzzle that demonstrates the kind of thinking Business Analysts must develop.
Three playing cards are placed face down on a table. You know the following facts:
- A jack is to the left of a queen.
- To the left of a spade is a diamond.
- A king is to the left of a heart.
- A spade is to the right of a king.
Can you identify the three cards?
Take a moment to work through this. Do not rush to the answer.
The solution requires systematic analysis. You must consider each constraint, test possibilities, and eliminate options that violate any rule. This is exactly what Business Analysts do when they work through complex requirements. Multiple stakeholders have different needs. Technical constraints limit what is possible. Business rules must be followed. The Business Analyst finds solutions that satisfy all these constraints simultaneously.
The answer, by the way, has two valid solutions: King of Diamonds, Jack of Hearts, Queen of Spades; or King of Diamonds, Jack of Spades, Queen of Hearts. Both satisfy all four constraints.
2.9 The Interconnected Nature of Skills
I want to share a quote that captures something important about the skills we have discussed:
“Interpersonal skills are not singular in nature meaning that one skill is intertwined and co-dependent on one or more other skills taken together. The vital point to understand, however, is that each skill is one that not only can separate you from the crowd of those seeking to enter an organization or for those who wish to assume leadership role but also to highlight that each of these interpersonal skills is applicable to everything you do no matter where you work, live or to whom you relate.”
Catherine Pulsifer, Author
These words remind us that developing one skill supports the development of others. As you improve your analytical thinking, you also become a better communicator because you can organize your thoughts more clearly. As you develop business knowledge, you become more trustworthy because stakeholders see that you understand their world. As you practice time management, you become more accountable because you can actually deliver what you promise.
This interconnection means that any effort you put into improving one competency pays dividends across all the others.
2.10 Case Example: The Accounting System Upgrade
Westfield Manufacturing had used the same accounting system for twelve years. The system worked, but it was showing its age. Reports took too long to generate. The interface confused new employees. Integration with other systems required manual data entry that introduced errors.
The CFO approved a project to upgrade the system. The IT department selected a modern cloud-based solution. Everything seemed straightforward.
Then the problems began.
The IT team configured the new system based on their understanding of accounting workflows. But their understanding was incomplete. They set up the chart of accounts differently than the accountants expected. They configured approval workflows that did not match actual authority levels. They assumed certain reports were unnecessary and did not include them in the migration.
When the system went live, chaos ensued. Month-end closing took twice as long because accountants had to work around system limitations. Auditors raised concerns about controls that had been inadvertently removed. The CFO received reports that did not match the format she had used for years to present to the board.
What went wrong? The project lacked effective Business Analysis. No one systematically gathered requirements from the accounting team. No one documented the existing workflows in detail. No one validated the system configuration against actual business needs before going live.
The company eventually hired a Business Analyst to fix the problems. She spent three months interviewing accountants, documenting requirements, and working with IT to reconfigure the system. Most of the issues were fixable, but the organization had spent months struggling with a system that should have worked from day one.
The lesson is clear. Technical capability alone is not enough. Someone must bridge the gap between what the business needs and what technology delivers. That someone is the Business Analyst.
Now that you understand the fundamentals of what Business Analysts do and the competencies they need, we are ready to explore strategy analysis, where organizations decide what problems are worth solving in the first place.
2.11 Review Questions
According to the course material, who qualifies as a Business Analyst?
- Only those with a formal Business Analyst job title
- Anyone who performs business analysis activities
- Only those who have earned the CBAP certification
- Only those who work in IT departments
What are the six components of an information system?
- Analysis, Design, Development, Testing, Deployment, Maintenance
- Strategy, Planning, Elicitation, Documentation, Validation, Implementation
- Hardware, Software, Processes, Data, People, Networks
- Inputs, Processes, Outputs, Feedback, Controls, Boundaries
Which approach to system development is best suited when requirements are clear, stable, and unlikely to change?
- Agile
- Waterfall
- Scrum
- Kanban
The communication exercise involving “A walk in the the park” demonstrates what important concept?
- Business Analysts must be excellent writers
- What people read is not always what we intend to convey
- English language skills are the most important competency
- Proofreading is unnecessary for experienced professionals
Which of the following best describes the Business Analyst’s position in an organization?
- Part of the IT team with occasional business interaction
- Part of the business team with no technical involvement
- Between IT and business, speaking both languages
- Above both IT and business in the organizational hierarchy
1-b, 2-c, 3-b, 4-b, 5-c