Your first Business Analyst role is rarely about mastering every technique.

It’s about showing hiring managers (and yourself) that you speak the language of business change, requirements, and value.

That’s why certifications help, especially early on. But the question isn’t “Which one is best?”

It’s: Which one opens the right doors for the market you want to work in?

In this post, I’ll compare the International Institute of Business Analysis (IIBA), British Computer Society (BCS), and International Requirements Engineering Board (IREB) through a career lens: consulting vs. corporate, geographic reach, industry fit, and the professional community you’ll be joining.

And if you want to make this decision quickly, I also have a certification selection tool you can use (link at the end).

Most Business Analysis careers blend business change and delivery work: your certification should too.

Before we talk bodies and badges, here’s what most people get wrong: they think they need to choose between “business change Business Analysis” or “delivery Business Analysis” at the start of their career.

In reality, most Business Analysis careers involve both, sometimes in the same role. One month, you’re mapping stakeholders and defining benefits for a business case. The next month, you’re refining user stories and working through acceptance criteria with the development team.

IIBA and BCS both provide a foundation that naturally covers this range. They view Business Analysis as a profession spanning business change and delivery work.

IREB is different. It’s anchored in Requirements Engineering as a technical discipline: precision, quality, specification, and verification & validation. If your work sits close to engineering teams, or if requirements quality is a hard requirement (not a nice-to-have), IREB makes sense.

But for most people starting out, the choice is really between IIBA and BCS for general BA work, or IREB if your role is genuinely requirements-focused and engineering-adjacent.

IIBA: Best when your career is “Business Analysis as a profession” + strong community

If you want to grow into a Business Analysis role that’s recognized as a distinct profession (with levels from entry to senior), IIBA tends to be a natural path.

Why it opens doors:

* Experience-based progression: IIBA certifications align with your actual experience level, not just exam passing. If you’re starting out with little experience, you begin at the entry level. But if you’re switching careers and already have relevant experience, you can jump straight to the certification that matches where you are, no need to work through lower levels first. This is a real strength: your certification reflects your professional reality.
* Strong professional identity: “I’m a Business Analyst” is the point, not “I do requirements sometimes.”
* Community advantage: IIBA is known for highly active local chapters with events, networking, study groups, and mentorship opportunities—often a real accelerator when you’re new. IIBA notes 120+ chapters across 40+ countries and emphasizes access to chapters for members.

Geographic coverage (career reality):

Your location matter. IIBA is commonly recognized across the Americas and has a broad international footprint. IIBA itself positions its certifications as globally recognized and supported by a large network and ecosystem.
(Your market will still vary by employer—always check job ads in your region.)

Best fit if you’re aiming for…

* Corporate Business Analysis roles in varied industries

* Freelance Business Analysis roles

* Business Analysis career tracks with defined seniority levels

* A strong peer network while preparing for a job and job hunting

* People who learn best with cohorts, study groups, and local events

* Career switchers with transferable experience who want recognition at the right level from day one.

BCS: Best when you want a structured BA foundation that travels well

BCS is best when you want a structured BA pathway with clear progression.

BCS is especially useful if you like a step-by-step certification route. Its Business Analysis qualifications are progressive: to reach higher levels (for example, the Practitioner Diploma or Professional Diploma routes), you typically build your way up by passing specific exams along the pathway.

That structure is a real advantage for early-career professionals. It provides a clear learning sequence, builds breadth before depth, and makes progression visible to employers.

For senior professionals, the same progression can feel less convenient, because you may need to start at Foundation even when you already have substantial experience.

The good news: you don’t necessarily have to take a full course. Many experienced professionals choose self-study and simply sit the required exam(s) to meet the pathway requirements.

Why it opens doors:

* International recognition is a consistent theme in BCS messaging, and they note that over 100,000 professionals worldwide are certified with BCS.

* Freelance Business Analysis assignments within governmental organizations (certification is a pre-requisite to get a job)

* A Business Analysis curriculum that many employers recognize as “solid fundamentals,” especially where Business Analysis is tied to governance, process, and business change programs.

Geographic coverage (career reality):

BCS is frequently seen in the UK and many international contexts where UK-rooted professional standards are valued. BCS explicitly positions its Business Analysis certifications as internationally recognized.
This often aligns well with financial services and government-style environments where formal methods and common vocabulary matter.

Best fit if you’re aiming for…

* BA roles in structured corporate environments

* Consulting in markets where UK-aligned standards are familiar

* A broad BA foundation you can build on (analysis, stakeholder work, requirements, business change)

IREB: Best when “requirements quality” is the job (and engineering is close by)

IREB (CPRE) is often the best match when your work sits close to engineering teams—or when the organization treats requirements as a quality discipline.

Think about systems-heavy contexts, high-tech products, regulated domains, complex interfaces, safety/security constraints, verification and validation of requirements, systems, designs.

Why it opens doors:

* It anchors you in Requirements Engineering as a discipline, not just “writing requirements.”

* IREB positions CPRE as internationally recognized and structured across multiple levels.

* The Foundation Level is explicitly framed as an entry into RE principles and methods—useful if your role leans more technical or specification-driven.

Geographic/industry coverage (career reality):

IREB has strong visibility in continental Europe (particularly Germany, Austria, and Switzerland) and is commonly appreciated in sectors where requirements quality is a hard requirement, not a nice-to-have. IREB emphasizes worldwide demand for certified CPRE professionals.

Best fit if you’re aiming for…

* High-tech and engineering-adjacent BA/RE roles

* Projects with strong compliance, quality, or verification needs

* Roles titled: Requirements Engineer, Systems Business Analyst, Functional Analyst, Business/Systems Analyst (depending on country)

Two “often ignored” decision factors that matter a lot

1. Already mentioned geographic coverage: follow the job ads

If you’re serious about choosing what opens doors, do this quick test:

Open 20 job ads you’d realistically apply for.

Count how often you see IIBA / BCS / IREB mentioned (or implied).

It’s boring. It’s also the most honest way to decide.

2. Professional community: how you’ll learn and who you’ll meet

This is where IIBA stands out: chapters can give you momentum, especially if you’re career-switching, building confidence, or trying to network into your first Business Analyst role.

If you learn best solo, community matters less.

If you learn best with people, community can be the difference between “someday” and “this year.”

So… which one opens more doors?

Here’s the practical answer from my experience:

* Choose IIBA if you want BA as a profession + strong community support + broad industry flexibility.

* Choose BCS if you want a structured BA foundation that’s widely recognized and works well in formal corporate settings.

* Choose IREB if your “BA” role is really about requirements quality in complex, engineering-heavy environments.

And if you’re still torn: the best choice is the one that aligns with your target roles + your target region + your preferred learning style.

Use my certification selection tool

If you want to decide faster, I built a certification selection tool that guides you through the same decision logic (career direction, market fit, and learning approach).

The post Your First Business Analysis Certification: IIBA, BCS, or IREB? appeared first on BA Coach.

5 min reading time

Discovering Customer Value When Change Is Constant

Why Business Analysis Is a Strategic Capability

Change is no longer something organizations deal with occasionally. It is constant, rapid, and increasingly technology-driven. Over the years, I’ve worked with many organizations that delivered exactly what they planned and still failed to create value. The issue was rarely execution. It was that the problem they solved was not the problem customers actually had.

That is where Business Analysis becomes strategic.

Customer Value Is Not Defined Internally

One pattern I see repeatedly is organizations designing solutions from their own perspective. They know their products, their processes, and their constraints very well, so they assume they also understand customer value.

In practice, this assumption is risky.

Value is not what an organization intends to deliver. Value is what customers experience as useful, relevant, and worth paying for.

I have seen initiatives praised internally for efficiency or functionality improvements, while customers experienced no real benefit, or even additional friction. Do you remember the Picture-in-Picture feature in a TV set? Have you ever used it?  When analysis is inward-looking, teams optimize delivery but miss impact.

Why Customer Needs Are Often Hidden

Business Analysts often hear stakeholders say what they want, but much less often what they need. In workshops, people quickly move to solutions: new systems, new features, new dashboards.

In my experience, this is not resistance or lack of interest. It is human nature. People are natural problem-solvers. Stakeholders reason within today’s constraints and today’s tools. Future value often sits outside that frame.  If you ask stakeholders what they need in Google Docs, many will ask for a “Save” button, when what they really need is their work to be stored in real time.

These unspoken expectations, also called latent needs, are usually discovered only when we slow down and look beyond what is stated.

From Elicitation to Discovery

Traditional elicitation techniques still matter. Interviews and workshops remain essential. But on their own, they rarely uncover the full picture.

Observation: Evidence Over Opinion

Some of the most valuable insights I’ve seen did not come from meetings at all. They came from quietly observing how work is actually done: the workarounds, the spreadsheets kept “just in case,” the steps people skip because they slow things down.

These signals are easy to miss if you rely only on what people say they do.

Empathy: Understanding Context

Empathy is often misunderstood as agreement. It is not. It is about understanding context without judgment.

When Business Analysts take the time to understand why stakeholders behave the way they do, what pressures they face, what risks they avoid, the quality of analysis improves dramatically. Tools like empathy maps help structure this understanding, but the mindset matters more than the template.

Where AI Helps and Where It Doesn’t

AI has changed the discovery landscape. Today, we can analyze large volumes of feedback, detect patterns in usage data, and explore scenarios much faster than before.

What I see in practice, however, is that AI amplifies whatever discipline is already present.

When analysis is weak, AI helps teams move faster in the wrong direction. When analysis is strong, AI becomes a powerful accelerator. Judgment, prioritization, and trade-off decisions still sit firmly with people, not tools.

The Evolving Role of the Business Analyst

The Business Analyst role has changed significantly over the years. It is no longer about translating business wishes into specifications.

Modern Business Analysts act as:

• Interpreters of customer value
• Facilitators of shared understanding
• Advisors in uncertainty and change
• Connectors between business, technology, and stakeholders

This evolution is reflected in professional standards from International Institute of Business Analysis, International Requirements Engineering Board, and British Computer Society. Each emphasize disciplined thinking, value focus, and context awareness from different angles.

Why This Matters for Organizations

Organizations rarely fail because they lack ideas. In my experience, they fail because they misinterpret signals from customers, the market, or their own data.

In that reality, the Business Analyst becomes a critical sense-maker connecting people, data, technology, and strategy to ensure organizations don’t just change, but change in the right direction. If you want your organization to stay relevant, invest not only in tools and technology, but in the capability to understand what truly matters to your customers.

This does not happen by accident. It requires skilled professionals and a shared analytical language.

BA Coach Perspective

At BA Coach, much of our work starts when organizations realize that “more requirements” is not the solution. We help professionals slow down at the right moments, structure insight, and make better decisions before committing to change. Remember “Good analysis doesn’t happen by accident.”
It is learned, practiced, and refined.

Learn more about our consulting services.

The post Discovering Customer Value When Change Is Constant appeared first on BA Coach.

5 min reading time

Can You Switch Between Business Analysis Certifications?

Understanding the Dependencies Between IIBA, BCS, and IREB Certification Paths

Many business analysts don’t plan their certification journey end-to-end. They start with one scheme, gain experience, and then realize their career focus has shifted.

That’s when the question comes up:

If I already hold a certification, can I move to another scheme without starting from scratch?

The short answer: yes, but with conditions.
The longer answer depends on how the International Institute of Business Analysis (IIBA), British Computer Society (BCS), and International Requirements Engineering Board (IREB) certification frameworks overlap and where they don’t.

This article explains those dependencies, not the certifications themselves.

Existing Agreements Between IIBA, BCS, and IREB

To reduce duplication of learning, formal recognition agreements exist between the major Business Analysis and Requirements Engineering bodies. These agreements allow candidates to claim exemptions when moving between certification schemes, under specific conditions.

British Computer Society and International Institute of Business Analysis (IIBA)

BCS and IIBA have a mutual recognition agreement at the foundation and practitioner levels.

In practice, the IIBA CBAP® certification grants exemptions from selected BCS Business Analysis exams (specifically BCS Foundation in Business Analysis and BCS Requirements Engineering) for candidates who want to obtain the BCS Practitioner Diploma in Business Analysis.

Assume you are CBAP-certified and want to achieve the BCS Practitioner Diploma in Business Analysis. You must:

• Pass two written exams: BCS Business Analysis Practice and BCS Modelling Business Processes
• Pass an additional oral examination

After successfully completing these, you are awarded the BCS International Diploma in Business Analysis. This video illustrates this situation (no audio).

The BCS Practitioner Diploma in Business Analysis does not grant candidates any exempts towards IIBA certifications.

British Computer Society and International Requirements Engineering Board (IREB)

BCS and IREB agreed that their courses BCS Requirements Engineering and IREB Certified Professional for Requirements Engineering (CPRE) Foundation Level are equivalent. This results in the following scenarios.

If you hold CPRE Foundation level, you can switch to the BCS Practitioner Diploma in Business Analysis. The IREB CPRE Foundation Level grants an exemption from the BCS Requirements Engineering course as illustrated in the video (no audio).

At the same time, you can continue  with your IREB certification path.

Holders of the BCS Practitioner Certificate in Requirements Engineering can easily switch to IREB, gaining deeper expertise in the requirements engineering practices, as illustrated in the video (no audio)

IIBA and IREB

There is no formal cross-certification agreement between IIBA and IREB. This means  that IIBA certifications do not grant exemptions in the IREB scheme and consequently, IREB certifications do not grant exemptions in the IIBA.

The lack of formal agreements between IIBA and IREB or BCS is largely due to differences in certification design. IIBA certifications are experience-based and rely on direct entry, meaning candidates qualify based on professional experience and BABOK® knowledge rather than progressing through mandatory modules. In contrast, BCS and IREB follow modular, progressive certification models, where learning outcomes are built step by step through defined courses and exams. These structural differences make cross-recognition and exemptions difficult to align.

Conclusion: Plan Before You Switch

Switching between Business Analysis and Requirements Engineering certification schemes is possible, but it is not automatic. Recognition depends less on the topic area and more on how each certification framework is designed.

• BCS acts as the main bridge, offering formal exemptions for both IIBA and IREB certifications where learning outcomes align.
• IIBA certifications do not receive exemptions from BCS or IREB, due to their experience-based, direct-entry model.
• IREB and BCS align well on requirements engineering, allowing smoother transitions between their schemes.
• Exemptions are always module-specific, never qualification-wide.

The key lesson: certifications are not interchangeable, but they are strategically combinable. Analysts who plan their certification path with their long-term role in mind can avoid unnecessary exams, reduce cost, and build a more coherent professional profile.

Not sure which certification path fits your role or career goals?

We help professionals choose and combine IIBA, BCS, and IREB certifications in a way that avoids duplication and supports long-term growth.

Talk to us about your certification strategy

The post Switching between business analysis certifications appeared first on BA Coach.

Most organizations invest heavily in employee development, but much of that investment is lost when newly acquired skills quickly fade. Why does this happen? What can companies do to ensure their training actually sticks? As the corporate training landscape evolves with new technologies and learning methods, one thing remains clear: without effective reinforcement, even the best training programs are unlikely to deliver lasting results.

Understanding the Need for Continuous Skill Development

We have to constantly work on our skill sets to keep up with the relentlessly fast-changing world; companies recognize this urgent need to build on skills and capabilities. The corporate training market size has grown steadily in recent years, reaching $398.78 billion in 2024 and projected to reach $417.53 billion in 2025, with a compound annual growth rate (CAGR) of 4.7%. This growth is driven by factors such as expanding markets, increased learning and development budgets, greater penetration of digital platforms, and growing demand for mobile-based learning (source: Research and Markets, 2025).

New skill development now takes place through blended learning, virtual classrooms, and classical classrooms. In 2014, 47% of training hours were delivered via physical classroom, but this percentage has dropped to an average of 27% in recent years, while the popularity of virtual classrooms and online (e-learning) options has increased dramatically. Interestingly, coaching and mentoring as a support delivery method have remained steady at 28% (source: Training Industry Report 2025).

The Challenge of Retaining New Skills

The expectations around training are high: we sign up for training with the hope that, after two to three, or sometimes more, days of intensive learning, we will leave the classroom wiser, with our new skill reasonably developed. After the training, we are filled with ideas, enthusiasm, and improvements for our daily work that we have discovered during the course. We promise ourselves that we will apply new ways of doing things just as soon as we hit the work floor. We go to work a day after, open our e-mail to find 100 urgent messages awaiting us, receive a couple of new requests from the stakeholders, have a good chat with a project leader about what still needs to be done, and … get sucked into daily operations. We keep resisting old habits, but after a couple of weeks, we give up and go with the flow… I believe you have similar stories of your own.

The Data on Training Effectiveness

What was the effectiveness of such training? Low. Research conducted by Saks and Belcort in 2006 shows that without any reinforcement, employees will retain as little as 35% of what they learnt in training after one year. The forgetting curve below shows the decline in skill use. Also, recent research continues to support the broader conclusion that training outcomes, including knowledge retention and transfer, deteriorate over time unless reinforced with structured follow-up, contextual support, and effective learning design.

Figure 1: Decline in the use of skill over time (based on Saks and Belcort)

Why Coaching Matters After Training

Training is an excellent first step in developing a new skill; it isn’t the end, but the start of a learning journey. Practice is the hardest part. Finding ways to incorporate the newly learnt skill into one’s work will help the skill strengthen and allow employees to get better at it. The time just after training is the most vulnerable because a person still has to actively work on a skill, and executing it may require a lot of thought. In this phase, we can still easily fall back into old habits or even abandon the skill.

Figure 2: Skill maturity versus skill development overview

The “after the training” phase (the conscious competence phase) is where any post-training follow-up activities (e.g., coaching, reviews, interactive meetings) help sustain the learning. Multiple studies reveal the important role of managers in coaching employees after training. The effectiveness of the training can be increased by 40% if managers take up a coaching role. These activities are necessary if we want to sustain the learning and prevent the “learning dip”. Personally, I think that combining the newly learned skill with practice and coaching, in particular, is the most effective way to get the most out of training. As the old proverb says, “Practice makes perfect”: by doing and even making mistakes, we learn the best. We achieve this when an employee applies a new skill in projects, discusses it with peers, even during a coffee break, dares to challenge the old ways of working, and dares to make mistakes. It is not an easy time as it is definitely outside his/her comfort zone. Coaching sessions offer time for analysis, reflection, and action that ultimately enable a person to take the necessary steps to develop the required skill. This simple graphic (figure 3) illustrates how coaching prevents an employee from falling into the “learning dip”.

Figure 3: How coaching reinforces training

Conclusion: Making Learning Stick with Coaching

In conclusion, I think that if companies want results from their employee development, they need to ensure that, in addition to the training itself, a series of follow-up activities is in place. Training is just the start of the journey of developing new skills; practicing the skills in the workplace is the hardest part of learning. The follow-up activities, such as coaching, will help employees through the vulnerable phase when executing a new skill requires a lot of thought, and the risk of falling back into old work habits is high. Curious how coaching can reinforce your recent training? Get in touch with us.

The post Increase the effectiveness of your training with coaching appeared first on BA Coach.

Weak prompts force the model to guess. Strong prompts guide its reasoning. When your instructions are structured, the model delivers more accurate, reliable, and usable results. This is where the CRAFT framework comes in. It offers a simple, repeatable, and highly effective way to design prompts that work across all major models while allowing small adjustments for tool-specific behavior.

Why Prompt Structure Matters

LLMs interpret instructions based on patterns. If a prompt lacks focus or detail, the model fills in the gaps with assumptions. Structured prompts reduce that guesswork and help the AI understand:

• What background and context it needs,
• Which perspective or role to take,
• What tasks to perform,
• What format to produce,
• Who the content is intended for,

The clearer these elements are, the better the results.

The CRAFT Framework Explained

The CRAFT method organizes a prompt into five essential components that guide the model more effectively.

C: Context

Provides background and purpose, preventing invented details.

R: Role

Assigns the expert persona the model should adopt, shaping tone and depth.

A: Action

Describes the exact task, avoiding vague summaries.

F: Format

Defines how the output should be structured, improving clarity and usability.

T: Target Audience

Aligns the tone, complexity, and language with the intended readers.

All together, these elements form a blueprint that significantly improves prompt consistency and quality.

CRAFT in Practice: From Weak Prompt to Strong Output

A weak prompt such as “Explain systems thinking.” leaves too many decisions to the model. Tone, depth, structure, and audience all become guesses.

Using the CRAFT structure provides clarity:

Context: You are creating material for a business analysis workshop.
Role: Act as an experienced BA trainer.
Action: Define systems thinking and provide one simple example.
Format: Two short paragraphs followed by three bullet points.
Target Audience: Beginners.

This simple structure already produces more consistent, high-quality results.

If you want more, watch this video from Lawton Learns that explains in more details how this prompt works:

Why Different LLMs Need Slightly Different Prompts

Not all models respond to prompts the same way. Differences in training, architecture, and instruction tuning affect how they interpret your request.

For example:

• ChatGPT follows roles and structure very well.
• Claude tends to expand unless given tight boundaries.
• Gemini performs best with step-by-step instructions.
• Copilot prefers short, direct prompts.
• Perplexity excels at retrieval-style answers and concise summaries, but benefits from very clear task framing and explicit output instructions.

The strength of CRAFT is that it keeps your structure consistent while allowing you to adjust only the parts each model is most sensitive to.

Looking Ahead

As LLMs continue to grow in capability and variety, prompt engineering will shift from a “nice to have” to a core professional skill for business analysts. Models will become more specialized, organizations will demand more from AI-assisted work, and expectations for clarity, accuracy, and reliability will rise.
A structured method like CRAFT helps you stay ahead of that curve. It gives you a scalable, repeatable way to get better results from any model — today and in the future.

If you want to start applying CRAFT immediately, download the free CRAFT Prompt Template and use it in your next AI-assisted task. The more intentionally you prompt, the more value you unlock.

 Download the CRAFT Prompt Template here

The post Why Prompt Engineering Matters And How the CRAFT Framework Helps You Get Better Results from Any LLM appeared first on BA Coach.

When I work with organizations on change initiatives, one pattern repeats itself. Teams often jump straight into solution mode. They rush into selecting tools, writing user stories, or planning training — without first understanding what is changing and why. Over time, I learned that the best results come from following a clear, structured approach: the Business Change Lifecycle.

This lifecycle is a standard professional framework; it is not theoretical. It’s a practical framework that helps me guide stakeholders, structure analysis work, and prevent common mistakes. In this article, I explain each of the five stages and show how I apply them in real projects. If you’re a business analyst, project professional, or change leader, this gives you a reliable way to navigate any change initiative — large or small.

What is the Business Change Lifecycle?

The Business Change Lifecycle [1] is a structured approach that guides organizations from the initial idea of change to the moment they realize its benefits. It consists of five stages:

1 Alignment between business and IT,

2 Definition of improvements,

3 Design business change components,

4 Implementation of a business change,

5 Benefits Realization.

Every business change — small or extensive — goes through these stages. The lifecycle brings order and clarity. It prevents teams from skipping critical steps and keeps the focus on value delivery rather than deliverables.

Let’s explore each stage.

Stage 1: Alignment between business and IT

Alignment is the stage where we clarify why change is needed and ensure everyone understands the underlying business problem or opportunity. It sets the initiative’s direction and prevents teams from solving the wrong issue. At this point, we work with stakeholders to analyze the business context and assess alignment with the external environment and the internal strategy to identify drivers of change.

During this stage, we facilitate early discussions between the sponsor, subject matter experts from business and IT, operational teams, and other key stakeholders. We investigate business challenges, capture initial needs, and frame the problem or opportunity the initiative must address. This helps us create a shared understanding of why change is required and what the organization aims to achieve. When Alignment is done well, it becomes clear what the next steps should be; when it’s skipped, the initiative lacks direction and quickly becomes a guessing game.

Stage 2: Definition of improvements

The Definition stage translates the early understanding from Alignment into clear options that the organization can consider. Here, we define the scope of the change, outline the desired future state, and assess possible ways to achieve it. This is where we determine exactly what is included — and what is not — and prepare the foundations for selecting the most suitable business option within the business case.

During this stage, we clarify objectives and desired outcomes, identify constraints and assumptions, and evaluate each business option in terms of impact, risk, and financial viability. To support this work, we analyze current processes and pain points, define future-state processes, outline the required business changes, and capture the initial functional and non-functional requirements. We work closely with stakeholders to align the business and technical perspectives and avoid misunderstandings later in the lifecycle.

We take a holistic view of changes across people, processes, organizational structures, information, and IT. Tools such as Leavitt’s Diamond help ensure nothing is overlooked. Typical deliverables at this stage include the business context diagram, stakeholder analysis, the list of constraints, high-level requirements, and a benefits dependency network [2]. These artefacts bring clarity and prevent circular discussions. A strong Definition stage creates a stable foundation for Design; without it, Design quickly becomes chaotic.

Stage 3: Design of business change components

Design is where the selected business option becomes a concrete solution or its components. The Design stage focuses on converting the agreed scope and high-level requirements into a complete, detailed specification of the business solution. This includes designing the future business processes, defining organizational changes, identifying required skills, and specifying the supporting software and data structures. Technical development work often begins during this stage, and the resulting components are built, configured, and tested to ensure they meet the defined requirements.

During this phase, the business analyst plays an active role. We clarify requirements for designers and developers so they fully understand business expectations. We provide business domain knowledge, represent stakeholder perspectives, and facilitate communication between business and technical teams to avoid misunderstandings. We also support the design of processes, organizational roles, and behavioral changes, using frameworks such as the Leavitt model.

At the same time, we create supporting artefacts, including process definitions, role descriptions, task details, data requirements, and decision logic. Throughout the phase, we assess the impact of proposed design decisions to ensure alignment with business objectives and constraints.

Design creates the foundation for successful implementation. If design is weak, implementation becomes a series of surprises.

Stage 4: Implementation of a business change

Implementation is the stage where the planned business changes are deployed and adopted. This stage focuses on ensuring the organization is ready for the new way of working and that the solution is introduced effectively. In practice, this is where change becomes visible to users — and where strong support from the business analyst makes a significant difference.

During implementation, we help business staff understand the new processes and behaviors expected from them. I make sure I am available to clarify requirements and solution intent, especially when users or teams encounter uncertainty. My role is to help the business adopt new practices with confidence and ensure the change lands smoothly.

Preparing the organization for change is another core responsibility. This often includes developing artefacts such as process descriptions, job role definitions, task guidelines, and other materials that support deployment. Communication is critical here. We facilitate conversations between technical teams and business representatives so that everyone interprets the solution correctly and understands the implications of design decisions.

Although user acceptance testing formally occurs earlier in the lifecycle, we remain involved during implementation to ensure the delivered solution continues to meet the acceptance criteria. We often support training, communication, and transition activities to help users move from old practices to new ones.

After deployment, business analysts also contribute to post-change reviews. This includes assessing business readiness, reviewing change strategies, and gathering information for benefits realization to check whether the predicted outcomes were achieved.

Implementation is where change becomes real. It’s also where strong analysis work pays off.

Stage 5: Benefits Realization – benefits delivery check

Benefits Realization takes place after the business changes have been deployed. Its purpose is to confirm whether the organization has actually achieved the benefits predicted in the business case. At this point, the sponsor reviews each expected benefit and determines whether it has been fully, partially, or not at all completed. If a benefit has not materialized, we identify the underlying reasons and propose actions that could help, such as additional training, process adjustments, or small system enhancements.

This stage also confirms whether the investment was justified. A benefits report clarifies the extent to which the expected outcomes have been delivered and whether the time, cost, and effort were worthwhile. Sometimes unplanned benefits occur as well; these are captured and incorporated into updated benefit plans.

Finally, the insights gained from this review are an input for future projects. Understanding why certain benefits were achieved or not strengthens future business cases and improves project selection decisions.

Conclusion: A simple structure for a complex change

The Business Change Lifecycle gives us — and the teams we work with — a clear, reliable structure for delivering successful change. It ensures we:

• Understand the purpose,

• Define what we want to achieve,

• Design the right solution,

• Implement it effectively,

• And finally, check whether it delivered value.

Whether we support a small improvement or a complex digital transformation, the lifecycle brings order, clarity, and confidence to everyone involved. In large organizations, these business analysis activities are split among different roles, such as business consultants, implementation managers, or information analysts.

This lifecycle applies to both traditional (waterfall) and agile approaches. In a traditional environment, the stages often appear more sequential, with each phase completed before the next begins. In agile delivery, the same stages are followed. Still, at a much higher frequency: each increment moves through definition, design, implementation, and benefits realization, allowing value to be delivered and validated multiple times throughout the initiative.

If you want to learn how to apply this lifecycle in your own projects — and develop stronger analysis and change skills — explore our training options at BA Coach.

References

[1] IT Enables Business Change by Sharm Manwani

[2] Benefits Management by J.Ward and Daniel E.

Image by freepik

The post A Practical Guide to the Business Change Lifecycle appeared first on BA Coach.

The Cynefin framework: navigating complexity

Examples of sense-making by using the Cynefin framework

Example 1: Organizational change in a global corporation

Example 2: Public health crisis response

Extending your analyst’s toolkit: beyond Cynefin

1 Systems Thinking — seeing connections, not just symptoms

2 Scenario Planning — preparing for more than one future

3 Emotional Intelligence — helping people through the change

The analyst’s mindset: humility and curiosity

Conclusion: from analysis to sense-making

The post The Analyst as Sense-Maker in the VUCA World appeared first on BA Coach.

Introduction: Beyond the One-Dimensional Fix

Every business analyst has seen it happen: a new system is launched to streamline processes — yet productivity drops, morale falls, and support calls skyrocket.  The problem isn’t the technology. It’s the thinking.
Too often, organizations approach change as a linear upgrade, assuming that fixing one component will automatically improve performance. But as any experienced analyst knows, organizations are living systems, and changing one part inevitably affects the rest.
That’s where holistic thinking comes in. It’s not just a buzzword — it’s a mindset rooted in Leavitt’s Diamond and systems thinking, two timeless ideas that help business analysts see the whole picture before making a single change.

Leavitt’s Diamond: Seeing the Organization as a System

Developed by Harold Leavitt in 1965, Leavitt’s Diamond proposes that every organization is made up of four tightly interrelated components:

1. People – the individuals, teams, culture, and skills.

2. Tasks – the work that needs to be done and how it’s performed.

3. Structure – the formal and informal frameworks of roles, governance, and communication.

4. Technology – the systems, tools, and infrastructure that enable work.

Change one, and the others will adjust — sometimes in unexpected ways. For example, introducing new technology (like automation or AI) affects tasks (what people do), people (skills and motivation), and structure (roles and reporting). If these dependencies are ignored, the result is friction, resistance, and unintended consequences.

The Leavitt’s Diamond reminds analysts to think in terms of balance rather than silos. It’s not about improving a process in isolation — it’s about ensuring that improvements align across all four dimensions.

Systems Thinking: The Mindset Behind the Model

Where Leavitt’s Diamond provides a structure, systems thinking gives a philosophy. INCOSE defines systems thinking as the ability to view organizations as complex systems of interdependent parts — each with feedback loops, boundaries, and perspectives.

The approach was championed by Peter Checkland’s Soft Systems Methodology (SSM), which teaches that there’s rarely one “right” solution. Instead, business analysts must explore multiple worldviews and understand how different stakeholders define the problem itself. At its heart, systems thinking challenges the BA to ask: What relationships exist between the parts of this system? How might a change in one area ripple through others? Whose perspectives are shaping our understanding of success?

By combining Leavitt’s practical model with this reflective mindset, analysts move from problem solvers to organizational sense-makers — professionals who can diagnose, predict, and guide sustainable change.

Applying Leavitt’s Diamond in Business Analysis

So, do you know how this plays out in practice? Let’s look at how a business analyst can use the model to guide discovery and impact assessment.

Example: The Healthcare Transformation Project

A hospital implements a new digital patient record system to improve accuracy and speed. Initially, delays increase. Why?

People: Clinicians lacked training and confidence.

Tasks: Data entry took longer per patient.

Structure: Approval processes for new entries were unclear.

Technology: The system wasn’t optimized for bedside use.

Revisiting the change through Leavitt’s lens revealed the missing alignment. By retraining staff, simplifying workflows, and updating governance, the project achieved its intended benefits — and staff satisfaction improved dramatically.

Why Holistic Thinking Matters More Than Ever

In today’s environment of digital transformation, Agile delivery, and constant disruption, the ability to think systemically is a defining skill for modern business analysts. Here’s why it matters:
Agility requires balance. Rapid iteration means rapid ripple effects — without holistic analysis, short-term wins can create long-term problems.

Technology isn’t neutral. New tools reshape collaboration and user expectations. Analysts must anticipate those shifts.

Value comes from connections. Modern enterprises rely on cross-functional integration; seeing interdependencies is essential to delivering value.

Business analysts today act as organizational integrators — translating strategic intent into change that works across people, process, and technology. That integration begins with holistic thinking.

Practical Tips for Applying Leavitt’s Diamond

1. Start with a diagnostic workshop. Use Leavitt’s four components as discussion headings when investigating a problem or opportunity.
2. Map dependencies visually. Create a simple “diamond map” showing how a proposed change in one area affects the others.
3. Revisit during every project phase. Use the model at initiation, design, and implementation reviews to maintain alignment.
4. Blend with systems techniques. Combine Leavitt’s Diamond with tools like rich pictures, causal loop diagrams, or stakeholder maps to deepen understanding.
5. Communicate holistically. Present findings in a way that connects people, process, structure, and technology — not as separate streams.

Conclusion: The Analyst as a System Thinker

In complex change, the analyst’s role is not to fix problems — it’s to rebalance systems.  That simple insight captures the essence of holistic business analysis.

Leavitt’s Diamond provides a framework; systems thinking provides the philosophy. Together, they remind us that every solution exists within a living, interdependent network of people, processes, and structures.

When business analysts learn to see these connections clearly, they stop reacting to problems — and start shaping change that lasts.

From Thinking Holistically to Practicing Strategically

The ability to see the bigger picture is the first step. The next is knowing how to turn that insight into actionable business change.

That’s exactly what the BCS Business Analysis Practice course focuses on. It builds on the concepts of Leavitt’s Diamond and Systems Thinking by teaching analysts how to apply them when defining business needs, assessing strategic options, and developing business cases that deliver sustainable value.

In this course, you’ll learn how to:

• Use strategic analysis techniques (such as PESTLE, SWOT, and VMOST) to understand the business context.

• Apply holistic models like Leavitt’s Diamond to explore interdependencies between people, processes, structure, and technology.

• Engage stakeholders to co-create feasible and balanced solutions.

• Build a compelling business case that aligns with organizational strategy and ensures measurable benefits.

If the ideas of holistic and systems thinking resonate with you, this course is the natural next step to strengthen your skills and bring those principles into practice.

Learn more or register here.

The post Why Good Business Analysis Starts with Holistic Thinking appeared first on BA Coach.

Yet one of the most overlooked steps in business analysis is planning how you’ll elicit those requirements in the first place.

That’s where a requirements elicitation plan comes in. It turns chaos into structure and helps you ask the right questions, involve the right people, and collect information that leads to clear, validated requirements.

In this article, we’ll explore what an elicitation plan is, why it matters, and how to create one, step by step, using best practices from the IIBA BABOK® Guide and BCS Requirements Engineering framework.

What Is a Requirements Elicitation Plan?

According to the BABOK® Guide, elicitation refers to the tasks used to “draw out, discover, and understand stakeholder needs.” The plan ensures that this process is not left to chance. A requirements elicitation plan is a document or outline that defines how a business analyst will gather information about stakeholder needs, goals, and constraints.  

It typically answers:
– Who needs to be consulted (stakeholders)
– What techniques will be used (interviews, workshops, etc.)
– When and how the sessions will take place
– How information will be documented, verified, and approved
In other words, the elicitation plan acts as your map through the discovery phase of business analysis.

Why an Elicitation Plan Matters

Without a plan, elicitation becomes reactive—you chase stakeholders, miss critical perspectives, and risk incomplete or conflicting requirements.

A well-prepared plan brings several benefits:
– Clarity: Everyone understands the purpose, scope, and expected outcomes of elicitation activities.
– Stakeholder alignment: The plan helps build trust and engagement by showing transparency in how information will be gathered.
– Efficiency: Resources, sessions, and documentation are well-organized, saving time and rework later.
– Risk reduction: Anticipating constraints and dependencies prevents missed requirements or surprises during solution delivery.
Think of it as preventive medicine for project misunderstandings.

Core Elements of an Elicitation Plan

Every effective elicitation plan contains a few essential elements. Whether you use a spreadsheet, Word document, or online collaboration tool, include the following sections:

1. Stakeholder Identification

List everyone who has a stake in the outcome of the project: users, customers, managers, sponsors, IT staff, regulators, etc.
Use techniques like the Stakeholder Checklist or Onion Model to ensure coverage. Don’t forget indirect or supporting roles.

2. Elicitation Techniques

Specify which techniques you’ll use for each stakeholder group. Choose based on a.o. the stakeholders’ availability, knowledge, and the type of information needed.

3. Logistics and Scheduling

Define how and when activities will take place:
– Date, time, and duration of each session
– Location (physical or virtual)
– Tools used (e.g., Miro, Zoom, or MS Teams)
– Required materials (e.g., templates, process maps)

4. Documentation and Validation

Explain how findings will be recorded (e.g., meeting notes, requirements log, stakeholder register) and how you’ll confirm accuracy with participants.

How to Create Your Own Elicitation Plan (Step-by-Step)

Let’s bring it all together. Follow these five steps to develop your own elicitation plan.

Step 1: Define the purpose and scope

Start by clarifying why you are performing elicitation.

– What is the business problem or opportunity?

– Which part of the project or product are you focusing on?

– What outcomes do you expect from elicitation?

Documenting scope prevents overreach and keeps sessions result-oriented.

Step 2: Identify and document stakeholders

List all relevant individuals, groups or organizations that contribute to the requirements elicitation. Previously mentioned techniques like stakeholder  nomination, stakeholder checklist, or onion model can help you here. It is recommended to document the stakeholder together with some additional information, e.g. what is role and stake of the stakeholder in the project.

Step 3: Match elicitation techniques to stakeholders or stakeholder groups

Choose the right combination of techniques.  When preparing the requirements elicitation, we need to consider the nature of our project, the characteristics of the business situation, stakeholders’ availability and, based on advantages and disadvantages of elicitation techniques, then select the most appropriate techniques.

The research shows that business analysts do not select elicitation techniques based on their suitability to the business situation; instead it is based on how proficient a Business Analyst is in a particular technique. Doing so is like trying to use a screw and a hammer. Consequently the result of elicitation may not be satisfactory. Use the right tool for the job, always!

Step 4: Plan Logistics

Schedule sessions, book rooms, or set up online tools. Define responsibilities—who will facilitate, take notes, or manage recordings.
Don’t forget to consider time zones and accessibility if you have remote participants.

Step 5: Define Outputs and Validation

Decide how findings will be captured: templates, mind maps, or requirement logs—and how you will confirm their correctness.
A simple review meeting or email confirmation can prevent misunderstandings later.

Expert advice for using the Elicitation Plan

1. It is a living document, it is not set in stone. As you learn mode about the project and stakeholders, you may revisit and update the plan.

2. Communicate the plan and share it with your project team and key stakeholders. It helps managing the expectations.

3. Include justification of your choices. If you want to conduct a survey among users, explain why you think it is the best technique to apply.

4. Keep it proportional, a small project needs perhaps less formal approach to documenting that a big one.

5. Always confirm the elicitation results with stakeholders. It helps keeping them engaged, too!

Bringing It All Together

A strong requirements elicitation plan sets the tone for a successful project. It helps you approach discovery with structure, confidence, and professionalism—key traits every business analyst should master.

If you’re just starting your BA journey, use the BABOK® and BCS materials as your compass. Over time, you’ll learn to adapt and refine your elicitation approach based on project type, culture, and stakeholder dynamics.

Final words

Ready to take your business analysis skills further?  Explore more practical resources on techniques on BA Coach or visit IIBA.org to deepen your professional journey. Our course BCS Requirements Engineering guides you through all the activities needed to develop and manage requirements successfully. 

The post Don’t Start Eliciting Without a Plan! How to Structure Your Requirements Discovery appeared first on BA Coach.

As a consultant who teaches business process modeling, I’m often asked to explain foundational concepts. Recently, a student posed a brilliant question: “What’s the actual difference between how a company is organized and how work actually gets done?”

This question lies at the very heart of business analysis. The answer requires understanding two distinct but complementary perspectives every organization has: the functional view and the process view.

Paul Harmon, in his book “Business Process Change”, distinguishes two complementary ways of understanding how organizations work:

-the functional view, and

-the process view.

Each represents a different perspective of how value is created and how work is managed. Harmon argues that while both are legitimate and necessary, modern performance improvement depends on an organization’s ability to move beyond purely functional thinking and adopt a process-oriented perspective.

The functional view–vertical efficiency

Functional view

The functional view is the traditional way organizations are structured. It divides the work into specialized departments, each responsible for a specific function such as marketing, production, finance or human resources. People with similar expertise are grouped together so they can build deep knowledge, standardize their practices, and achieve efficiency within their domain. This structure supports clear lines of authority and accountability. Managers within a function optimize resources, define procedures, and monitor performance indicators that relate to their area, such as departmental productivity or cost control.

In the functional view, the organization appears as a hierarchy, with the CEO at the top and departments arranged vertically underneath. Each unit operates with high autonomy and typically pursues its own goals and performance metrics. Communication and coordination across departments occur through handoffs — the transfer of work products or information from one function to another. While this view brings stability and specialization, Harmon notes that it also tends to produce silos. Each department becomes efficient at its own tasks but often at the expense of overall performance. As work moves between functions, delays, rework, and misunderstandings occur because no one is directly responsible for the entire flow from customer request to product or service delivery.

Harmon calls this local optimization: each department seeks to improve its own operations, but the organization as a whole may still perform poorly from the customer’s point of view. Traditional management information systems reinforce this separation by reporting results by function rather than by the total experience of the customer or the end-to-end performance of a value chain.

The process view–horizontal value creation

Process View

The process view cuts across this vertical structure and focuses on how value is actually created and delivered. A business process is an end-to-end sequence of activities that together achieve a specific outcome for a customer or stakeholder. Typical examples include “Hire-to-Retire” and “New Product Development.” These processes cross-functional boundaries and need collaboration among departments.

In the process view, the organization is seen horizontally: workflows through marketing, sales, production, logistics, and accounting, but the process itself is the unit of analysis. The focus is not on who performs the task, but on how the flow of work transforms inputs into valuable outputs. Performance is measured by process indicators such as lead time, cost per transaction, error rate, and customer satisfaction.

Harmon explains that adopting a process view shifts management attention from isolated functional performance to end-to-end value delivery. The goal becomes to improve the total process so that the customer receives faster, higher-quality, and more consistent service. This view underpins the discipline of Business Process Management (BPM), which Harmon describes as a horizontal management system layered over the traditional hierarchy. BPM introduces roles such as process owners, who are accountable for results that cross departmental boundaries, and continuous improvement mechanisms such as process modeling, measurement, and redesign.

Comparing the two views

In essence, the functional view is vertical and inward-looking, while the process view is horizontal and outward-looking. The functional view emphasizes specialization, control, and efficiency within each domain; the process view emphasizes integration, coordination, and effectiveness from the customer’s perspective.
From a modeling standpoint, the functional view is typically represented by an organizational chart or functional decomposition diagram, showing who reports to whom and what capabilities exist within each department. The process view, on the other hand, is represented by flow diagrams, BPMN models, or value chain maps showing how work moves through the organization. Harmon often uses “swimlane” diagrams to connect both views — each lane represents a function, while the process flow runs horizontally through them, making visible where handoffs and delays occur.
Performance metrics also differ. Functional managers look at departmental efficiency and utilization, while process managers look at overall cycle time, throughput, and customer value. The functional perspective asks, “Who handles this activity?” The process perspective asks, “How well does this activity contribute to the overall flow of value?

Integration rather than replacement

Harmon cautions against seeing the process view as a complete replacement for the functional view. Functions are still essential; they provide a home for professional expertise and manage resources. No process could operate without the skills and discipline that functional departments supply. The key, thus, is integration. Organizations must recognize that they are both vertically and horizontally structured systems.

To achieve this balance, Harmon suggests creating a process architecture, which is a broad outline of key value-generating processes. These processes are then related to organizational units that implement them. This architecture allows management to:
-identify process owners,
-align strategic goals with end-to-end processes, and
-establish governance mechanisms that coordinate functional and process priorities.

In mature organizations, functional managers and process owners share responsibilities: one ensures that people and resources are available, while the other ensures the process delivers results that meet customer and organizational expectations.

How business analysts use both views

Your value as a BA comes from being fluent in both the language of functions and the language of processes.

1. When starting an assignment:
Use the functional lens to identify who you need to talk to. Map the stakeholders, decision-makers, and teams. Understand the political landscape and policy constraints.
Technique: stakeholder map, RACI, organizational chart, capability map.

Use the process lens to understand what you need to talk about. Define the process scope: What triggers it? Who is the customer? What is a successful outcome?

Technique: SIPOC, high-level process map, current-state BPMN/swimlane diagrams, value stream map, pain-point log.

2. During analysis:

Use the functional lens to uncover capability gaps. Do people have the right skills? What training is needed? What compliance rules must be followed?

Use the process lens to identify flow inefficiencies. Where does work wait? Where do we do rework? Can we remove, simplify, or parallelize steps?

3. In measurement & governance:

Functional KPIs tell you how efficiently resources are being used (e.g., utilization rates).

Process KPIs tell you how effectively value is being delivered (e.g., lead time, quality).

Governance: The ideal model blends both. A process owner is accountable for the end-to-end outcome, while functional managers are accountable for providing skilled people and resources.

Sample questions to uncover each view

In your next workshop or interview, you may try the following questions:
To understand the functional view:
-“How is your team’s performance measured, and who defines those goals?”
-“What specific expertise or unique capabilities does your team have that others in the organization rely on?”
-“When your team needs to get a decision made, where do you go for approval?”

To understand the process view:
-“Could you please describe the complete process, starting from when it begins until when it is finished?”
-“Where does the work spend the most time waiting?”
-“How often are cases resolved accurately on the initial attempt, with no need for further work?”

The final takeaway

Customers don’t make purchases based on the company structure. They experience the business processes that your organization implemented and executes. Mature, high-performing organizations don’t choose between building expert internal functions and focusing on customer-driven processes—they master both.

As a business analyst, your superpower is:
-the ability to see the organization through both lenses at the same time,
-to ensure both views align to drive meaningful change.
As Harmon says (paraphrased):

“The customer doesn’t experience your departments; they experience your processes.”

Balancing the two views—functional for stability and expertise, process for agility and customer focus—is the hallmark of a mature, process-managed organization, and business analysis contributes to that.

Learn More with BA Coach

Would you like to develop your competencies to model, analyse, and improve business processes?
Our  EXIN BCS Foundation in Business Analysis and EXIN BCS Modelling Business Processes courses explore these perspectives in depth. You’ll learn to connect organizational structure with process flow, using real-world cases and practical exercises.

Visit our Calendar to discover upcoming training dates, delivery formats (classroom, virtual, or e-learning), and certification options.

References:

Pictures: Image by freepik

Business Process Change 4the edition

The post Seeing Your Organization Through Two Lenses: Functional vs. Process View appeared first on BA Coach.