Author: Anna Rajander

Anna Rajander is a Certified Business Analyst Professional with almost 20 years’ experience in both business analyst and project management roles.

A Natural Born Manager

Everyone, it seems, wants to be recognized for their leadership abilities. ‘Leader’, ‘leading’ and ‘leadership’ are in vogue terms for CVs and professional social media profiles. Everywhere you look, there are books, articles, and presentations on the topic, and leadership courses abound. Indeed, being called a ‘natural born leader’ is considered a high compliment. But could this obsession with leadership be at the expense of other, possibly more important qualities?

This article will look at some of the characteristics associated with leadership and management, the role they play in defining and driving organizational change, and what they mean to business analysis.

Leadership vs. Management

The table below lists qualities often attributed to leaders and managers respectively.

You can find similar lists each lauding slightly different traits, but they all share the same sentiment – leadership is about inspiration, innovation, and change, while management is about structure, problem-solving and routine. For some, leadership is something an individual possesses innately – a natural tendency, as opposed to a skillset that can be learned and improved. Management, on the other hand, is usually viewed more as a skill set that is developed over time and with experience. But are they really that different? And can one set of qualities be used to accentuate the other?

Leadership and Management in Times of Change

For an organization undergoing transformational change, there is no denying leadership is important. Having a charismatic leader who can articulate a vision to a wide audience can make the change journey easier. But organizations do not need many leaders. For most organizations, a single, visionary leader may be enough. Indeed, having too many leaders may be detrimental to an organization, particularly if the leadership group is unable to agree on a single, coherent vision.


Now consider how many managers are required to execute change. This question is far more problematic and influenced by many variables, such as the size, scale, and complexity of the change. However, two things are for certain:
  • Leadership does not guarantee change success. Indeed, leadership in the absence of management capabilities is unlikely to result in successful change.
  • Measures of change success are likely to draw on management qualities. A change is only successful if it can be embedded and maintained over time… or in other words, whether it results in a level of stability – a quality associated with management.

It is important to remember that leadership and management are not mutually exclusive. Indeed, good managers will often have leadership qualities, and good leaders certainly require management skills. In some instances, the distinction between leaders and managers may not be clear. Individuals may be required to move between roles depending on the situation, particularly in more agile or dynamic contexts.

Business Analysis: Leadership, or Management?

Business analysis is often at the forefront of efforts to translate the vision of leaders into maintainable solutions. As such, the good analysis may be confounded with leadership. Analysis that is produced through wide consultation succinctly describes the situation and context, considers different perspectives, and clearly communicates a solution may be able to achieve more in envisioning and driving change than anyone recognized as a ‘leader’. Yet, it would be wrong to diminish the contribution of an analyst’s management capabilities in the delivery of such analysis. A good analysis involves problem solving, persistence, and structure – all qualities associated with management. And should that analysis lead to the implementation of an innovative, proactive solution – Is that leadership? Or just a by-product of good management?

A range of techniques is available to assist Business Analysts in delivering quality analysis.  If we look at the available techniques, many of them epitomize management qualities. Take for example the 15 business analysis techniques in the Business Analysis Book of Knowledge (BABoK)2 that are sometimes considered the core techniques. Figure 1 shows these techniques on a Venn diagram based on whether they generally accentuate management or leadership qualities:

Figure 1: Core Techniques of the BABoK

This diagram shows the majority of these techniques on the management side of the Venn diagram as they involve analyzing and structuring information – qualities associated with management. There are some techniques that are more flexible and can be employed to promote innovation and experimentation – more traits associate with leadership, and others that can emphasize different qualities depending on the context. This is good news for Business Analysts who want to improve and expand their capabilities into different areas or contribute to an initiative in a different way – there is usually a technique that can help.

Of course, Business Analysts also require underlying competencies across a number of areas. The BABoK includes a whole set of competencies grouped under the heading Analytical Thinking and Problem Solving, which are qualities (as per Table 1) associated with management. However, the BABoK also lists creative thinking, adaptability, and even leadership and influencing as underlying business analysis competencies – qualities associated with leadership.

At the end of the day, even the most revered business analyst ‘leader’ is likely to extol management qualities over leadership qualities as that is the nature of the analysis. For example, any Business Analyst with a new, innovative, or interesting idea is likely to immediately start asking questions such as:

  • Is there a business need?
  • What is the impact of the change?
  • What does success look like?

…and, thus, immediately start analyzing and creating structure. In the end, we can’t get away from the fact that business analysis is focused on the delivery of viable solutions to problems. Therefore, while leadership qualities may be an asset to a Business Analyst, management capabilities are fundamental to business analysis.


The intention of this article is not to deride leadership qualities or diminish their value. Indeed, leadership skills are important, and I would encourage any Business Analyst to work on developing their leadership capabilities. However, focusing on leadership is not healthy. Over-emphasizing the importance of leadership can be at the expense of other qualities and detract from the core capabilities required to elicit and understand requirements, analyze solution options, drive change, and support sustainable services – things that are fundamental to business analysis.

I, for one, would consider it a compliment to be called a natural-born manager.


  1. Capowski G., Anatomy of a leader: Where is the leader of tomorrow?, Management Review Vol. 83 Issue 3, 1994, p. 10-18.
  2. Business Analysis Book of Knowledge v3, Institute of Business Analysis, 2015.

Waterfall vs. Agile: A Relative Comparison

The merits of Agile versus Waterfall are well documented. However, it is useful to understand the relative differences between the paradigms and how they impact Business Analysis – particularly if you work in an environment where both approaches are used.

This article attempts to provide a visual, relative comparison between:

  • A traditional Waterfall method that moves through defined phases that include Requirements, Design, Implement and Verify, with a defined gateway denoting the point at which the method moves from one phase to the next.
  • An Agile method that aligns with the 12 principles of the Agile Manifesto.

The approaches are compared across three areas that matter to many Business Analysts:

  • The relative effort is involved in specifying and managing requirements.
  • The relative risk posed by ill-defined requirements.
  • Time to realize benefits.

Requirements Management

The timeline for discovering, specifying, and managing requirements differs greatly between the two approaches. A traditional Waterfall approach includes the requirements phase early in the initiative where the focus is on requirements specification and management activities. At the end of this phase, the ability to change requirements is limited. Therefore, most of the effort to elicit and manage requirements happens during this early phase.

By comparison, requirements elicitation and management activities for an Agile initiative are more evenly distributed over the life of the initiative as requirements are constantly reviewed, updated, and prioritized.

The relative requirement management effort over time for each approach is shown in Figure 1.

Figure 1 – Waterfall vs. Agile: Relative requirements management effort over time

Relative Risk

Missing, incorrect, and/or otherwise ill-defined requirements put the delivery of fit-for-purpose products at risk.  However, the relative risk associated with ill-defined requirements is quite different when comparing Waterfall and Agile approaches.

The risk posed by ill-defined requirements for a traditional Waterfall approach is lower during the requirements phase of the initiative as this is the time when requirements can be added and changed without impacting other areas. After this phase, the risk posed by ill-defined requirements dramatically increases and continues to increase for the duration of the initiative. By comparison, the risk posed by ill-defined requirements to Agile approaches is largely constant throughout the initiative. Figure 2 shows the relative risk of both approaches side-by-side.

Figure 2 – Waterfall vs. Agile: Relative risk posed by ill-defined requirements over time

However, it is worth analyzing the relative risk by its constituent components – the likelihood requirements will be ill-defined and the impact of having ill-defined requirements.

For a traditional Waterfall approach, all the effort to elicit and document requirements happens at the beginning of an initiative with limited mechanisms in place to revise or revisit requirements in later stages – regardless of what new information may come to light. This means that it is comparatively more likely (i.e. higher likelihood) that there will be ill-defined requirements. The likelihood of having ill-defined requirements is fairly consistent throughout the initiative as it is the result of a constraint imposed by the methodology.


In contrast, the impact of ill-defined requirements is low for Waterfall approaches during the initial requirements phase of the project as this is when there are mechanisms in place to actively review and change requirements. After this point, the impact of ill-defined requirements can increase quite dramatically (particularly for initiatives that involve the procurement of resources and/or base products as per the requirements as part of the next phase) and continues to increase throughout the life of the initiative. This is because the cost of changing products increases as the initiative progresses through the design, implement and verify phases.  This is demonstrated in Figure 3.

Figure 3 – Waterfall: Likelihood and impact of ill-defined requirements over time

In comparison, Agile methods include mechanisms to incorporate new information into requirements throughout the life of the initiative, meaning the likelihood of ill-defined requirements decreases as the initiative progresses. By comparison, the impact of ill-defined requirements increases over the life of the initiative as products are incrementally released. This is shown in Figure 4.

Figure 4 – Agile: Likelihood and impact of ill-defined requirements over time

By the end, the impact of ill-defined requirements on comparable initiatives is relatively similar for both Waterfall and Agile methods – it is the likelihood that contributes to the overall difference in relative risk.

Benefits Realisation

Another key point of difference between Waterfall and Agile methods is when benefits are realized. For Waterfall initiatives, benefits cannot be realized until after its core products are fully delivered. There is limited opportunity for early benefits realization in traditional Waterfall initiatives. By comparison, Agile methods offer opportunities to realize early benefits with the incremental delivery of products, as demonstrated in Figure 5.

Figure 5 – Waterfall vs. Agile: Relative time to the realization of benefits

Why does it matter?

So why is it useful to understand the relative differences between Waterfall and Agile approaches? There are a few ways increased understanding of the relative differences between methodologies can help, including:

  • Resource Planning – helping you to plan and allocate resources where they are needed most based on the approach being used.
  • Communication – better able to describe the relative merits and risks of an approach to stakeholders.
  • Arguing your case – provide some talking points to help you argue for an alternative approach.
  • Assessing alternatives – provide a basis for assessing alternative approaches and for tailoring methodologies.


This article has provided a relative comparison between Waterfall and Agile across three areas. In comparing Waterfall and Agile paradigms in relative terms this article does not seek to promote one over the other – both have their place. In addition, this analysis has not accounted for all the available variations, flavours, and mashups of approaches. However, understanding the relative differences between the basic paradigms can assist when preparing and planning to work with a specific methodology – particularly in environments where analysts may be expected to work with multiple different approaches.


Rising to the Challenge

Visions. Missions. Goals. Objectives. They are great for creating a shared understanding and bringing teams together for a common purpose… until they’re not.

Having a team contribute to the goals and objectives for their project or area can be a great way to communicate the organisations vision and promote team cohesion. Measuring progress against objectives can help maintain momentum and allow the team to see progress, identify issues, and share success.

Sounds great, right? Or alternatively…

Visions and goals are just overly-optimistic business jargon that serve no real purpose. They have no bearing on my work and discussing them is a waste of time when I could be doing something more important. Objectives are just a way for management to shirk their responsibilities, and measuring objectives leads to unnecessary paperwork and micromanagement.

As Business Analysts, it is drilled into us how important a shared vision and/or goal is when coordinating a team of individuals to implement and sustain business change. Cascading visions and objectives can be a great way to align work across an organisation, ensuring the goals and objectives of the component parts contribute to the organisation vision and/or mission as-a-whole. It is accepted practice to set, regularly review and tweak goals and objectives, and there are several techniques to support the discovery, definition, communication and monitoring of goals and objectives, including MOST, SMART, and Balanced Scorecards.

However, for some, it can be hard to see the point of goal and objective setting. There can be a variety of reasons for this, including but not limited to:

  •     Feeling threatened by the prospect of being managed/measured
  •     Disappointment with previous efforts to define and deliver on goals and objectives
  •     Difficulty seeing how the wider vision relates to their day-to-day work
  •     General resistance to change

In cases where you have several individuals that feel this way, trying to define goals and objectives as a group is likely to prove fruitless.

So how can you bring a team together without a shared goal? Are there other ways to create a clear, shared purpose for a team?

The Challenge.

An alternative to setting a goal is to set a challenge. Having a challenge to overcome can create the clear direction and purpose required to coordinate work across a team.

The difference between a goal and a challenge you ask? Not a lot.

Overcoming a challenge is as good a goal as any. However, while the end-result may be the same, the mindset for getting there can be quite different:


  •      ‘How can we contribute to the organisation vision?’ vs. ‘What challenges do we face in meeting the demands of the organisation?’
  • ‘What is our common purpose?’ vs. ‘What is stopping us from moving forward together?’
    •     ‘How do we measure progress against the objective?’ vs. ‘What steps have we taken to overcome the challenge?’

In the same way you can analyse and decompose goals to create objectives and requirements, a challenge can be further decomposed into target conditions and steps. Ultimately, challenges can be reworded to create goals, target conditions objectives, and steps requirements – meaning they can still be analysed and aligned to the visions/goals of the wider organisation/department.

Are there techniques that can help?

Yes, there are. More generic techniques such as Brainstorming, Mind Mapping and Affinity Mapping can help with the initial identification of challenges. However, when it comes to decomposing challenges into target conditions and steps, the A3 is a particularly useful technique.

The A3 (so named because they generally cover a single sheet of landscape A3) is a technique that has been developed and used as part of the Toyota Kata and adopted by Lean organisations. It is used to identify, define and manage process improvements. While Toyota uses A3’s as part of a wider process improvement philosophy and cultural mindset, an A3 can be a powerful stand-alone technique for supporting the discovery, definition and documentation of challenges, as well as record any progress in overcoming them.

The main idea behind the A3 can be summarised in four simple steps:

  1.      Understand the Challenge
  2.      Grasp the Current Condition
  3.      Establish the next Target Condition
  4.      Experiment towards the Target Condition

Templates for setting out an A3 vary. I have provided an example below. However, it is important to note that regardless of how sections are laid out on the page, it is important that the four key elements of the A3 are tackled in the order set out above – Challenge, Current Condition, Target Condition, Experiments. It’s also important to realise that the Target Condition should be the next Target Condition – there may be multiple Target Conditions before a Challenge is overcome.


There are a couple of benefits to using the A3 technique:

  •     Its very logical, so will likely suit people who have a more logical mindset
  •     It’s can be used as a way of documenting and allocating discrete pieces of work
  •     It works well for situations where the path from the Current to the Target Condition is unclear, allowing time to think, explore options, and experiment – rather than feeling forced to articulate a solution straight away.

In the end…

Challenges and Target Conditions may be used as an alternative to the traditional approach of setting cascading goals and objectives. Involving team members in the process of discovering and defining challenges can be a good team-building exercise, especially in circumstances where a team feel removed from the vision of the wider organisation. A3’s can be used as a framework for documenting challenges and working towards overcoming them. While not a panacea for dealing with resistors and detractors, it is another tool that may prove useful in any journey the involves coordinating groups of people, aligning goals and objectives, and creating a shared vision to support the successful implementation of business change.  


Toyota Kata: Managing People for Improvement, Rother, Mike, 2009.

Anna Rajander, February 2021.

The Focused Analyst

Have you ever:

  • Started what you thought was a simple analysis task, only to find yourself unravelling a web of mystery?
  • Revised work that was completed early because things changed in the interim?
  • Suffered from Analysis Paralysis – continually re-analysed a situation instead of moving forward?

If you answered yes to the above, you’re probably a business analyst. So what steps can you take to promote the delivery of analysis that is relevant, has a clear purpose, and is available at the point-of-need? Perhaps there are some lessons to be learnt from agile delivery.

A distinction is often made between agile and “other” business analysis techniques. However, many of the techniques that are used to organise and prioritise work in agile projects can be employed more generally. This article summarises agile principles and techniques that can be used to plan work, manage stakeholder expectations, and focus on the delivery of real value – regardless of the delivery environment… agile, waterfall, other or undefined.

1. Definition of Done

The Definition of Done is a list of criteria which must be met before a work item (usually a user story) is considered “done.” In agile delivery, the criteria are agreed by the agile team prior to commencing work. Once a work item meets the criteria, it is considered done – and “done” means done!

The idea of “done” can be expanded to work performed outside of agile projects. Agreeing a Definition of Done with relevant stakeholders is a good way to set and manage expectations and identify priorities, prior to commencing work. This can promote more focussed analysis by providing a clear end-point, reducing the risk of both over-analysis and scope creep.

2. Relative Estimation

In agile delivery, effort is a relative measure. Effort is measured by comparing tasks and assigning points. Each task is assigned a single point value (usually a number from the Fibonacci sequence) individually by each agile team member to denote how much effort they believe the task requires. Tasks that are considered more onerous compared to others are assigned a higher number of points, while tasks that are considered comparable are assigned the same number of points.  Where individual point values differ, the team discuss the reasons why to reach a consensus value. As tasks are completed over the course of an initiative, the actual effort-to-point ratio becomes apparent leading to more accurate estimates.

Relative estimation is useful as it is generally easier for individuals to predict whether a task will take more, less, or the same effort compared to another, as opposed to accurately measuring the time and resources required to complete a single task without comparison. Receiving estimates from multiple stakeholders/individuals is likely to result in more accurate estimates as additional variables may be considered. While it may take time to estimate enough tasks to accurately understand how points translate into actual effort, the result should ultimately be better, more reliable estimates for a range of work activities.


3. Just Enough, Just In-Time

As a rule, analysis and design activities in agile are performed on a just enough, just in time basis – just enough to not waste time conducting analysis and/or completing documentation that doesn’t add value, and just in-time to ensure analysis is current and available at the point-of-need.

Analysis is rarely done for its own sake – it is an input for further analysis, design and/or decision-making activities. Ideally, analysis work should be completed as-and-when it is required to ensure it is relevant. Focusing on why and when analysis is required provides a foundation for delivering just enough value-adding analysis, just in time.

4. Regular Reflection

In agile delivery, a retrospective is held at the end of every iteration. Agile team members reflect on the previous iteration as a way of learning lessons and implementing changes to improve the delivery process. Open and honest feedback is encouraged, and elicitation techniques such as Stop-Start-Keep, Affinity Mapping and Brainstorming are used to promote full participation. Because reflection happens regularly, the changes required to address concerns are usually small and/or incremental, making them easier for the team to implement and monitor.

While most project methodologies promote the logging and reviewing of lessons at fixed points in time, this often happens too late to be applied to current initiatives. The regular reflection and change promoted in agile has the benefit of allowing learnings to be applied early when they may be of most benefit to the initiative. Including regular retrospectives in normal work practices can be a good way of promoting and implementing continuous improvement.

5. Focus on Progress – Not Perfection

Agile focuses on making progress – not obtaining perfection. Agile delivery sets up a system that can respond to new information through iterative feedback and refinement. Work items are constantly reviewed and revised as new information comes to light. As work items are completed, they are made available to stakeholders who are encouraged to provide feedback. It is generally accepted that initial versions will not be good enough, but that open and regular reviews will provide the information required to make them acceptable.

There are some simple steps for promoting the principle of progress over perfection in everyday business analysis. Set expectations early – never promise perfection. Engage stakeholders regularly – multiple short, sharp engagements can be more productive compared to longer one-off meetings. Focus on analysing what is important. Produce deliverables in a format that supports regular updating. Where possible, create “living documents” that are updated as-and-when information becomes available. Don’t be afraid to present work that may be incomplete or incorrect – showing the wrong answer can be an effective route to right answer.


Many of the principles and techniques associated with agile delivery can be employed in business analysis more generally. Pigeonholing techniques into “agile” and “non-agile” may mean suitable analysis techniques are overlooked.  The principles and techniques that help agile teams organise and focus on delivering can assist in the delivery of timely, value-added analysis – regardless of the delivery approach.


The Agile Samurai: How Agile Masters Delivery Great Software, Rasmusson, Jonathon, 2010.

Agile Alliance – Definition of Done,, accessed October 2020.

The Unbiased Analyst

Whether it be interviews, surveys or questionnaires, business cases, observations, or root cause analysis – any technique can introduce bias into a business analysis initiative.

Bias can result in the collection and synthesis of erroneous information leading to the delivery of sub-optimal, discriminatory, and/or inadequate solutions. It is therefore important that Business Analysts are aware of the different types of bias and the risk they pose to any analysis.

The following outlines some common forms of bias, as well as provides some simple approaches for mitigating the risk of introducing bias into an analysis.

Selection Bias

In cases where there is a large group of stakeholders, it is often not practical to elicit information from every individual. Instead, information is elicited from a selection of group members.

Selection bias is where individuals are more or less likely to be selected from the larger group. The risk posed by selection bias is that the information solicited from the selected individuals is not representative of the larger group.

Any business analysis technique that involves selecting individuals to represent an entire group is at risk of introducing selection bias. For example:

  • Surveys and questionnaires often depend on individuals taking the time to respond, which may be depended on a range of variables, including being aware of the survey/questionnaire, having access to complete the survey/questionnaire, having the time to respond, and/or having the ability to respond.
  • Interviews usually involve selecting individuals or asking for volunteers from a larger group.
  • Observations may introduce selection bias based on when and/or where the observation takes place.

It is also important to be aware that any elicitation that involves self-selecting is inherently biased towards those who chose to be involved.

Response Bias

Response bias is a general term that accounts for range of bias that influence the response of participants away from an accurate or truthful answer. Some areas that may contribute to response bias include:

  • Recall – human memory can be unreliable, particularly if the information being recalled is complex, regards an event that took place a long time ago, or involves information that may be considered traumatic.
  • Perception – this is where a response is influenced by what is perceived as a ‘good’ or ’bad’ answer. The responder essentially changes their response or behavior based on what they think the interviewer/observer wants to hear/see, ultimately leading to the collection of erroneous information. An individual’s response can also be impacted by how a question is framed. For example, using overly negative language, positive language, or language that is associated with a particular ‘side’ can influence response.

Any business analysis technique that involves collecting information direct form stakeholders may be at risk of introducing response bias.


Personal Bias

Personal bias is where an individual unintentionally or unwittingly introduces unwarranted opinions and feelings into a situation, making objective opinions difficult. Business Analysts are at risk of introducing bias into an analysis because of their own views and believes.

Some particular areas of personal bias include:

  • Observer Bias – this is bias introduced when an individual’s point of view or understanding impacts how they perceive a situation. For example, an observer may misinterpret a situation because the language used has a specific meaning in the given context that the observer is not aware of.
  • Confirmation Bias – this is the tendency for an individual to seek out evidence that confirms their own personal views, while downplaying or discounting evidence to the contrary.
  • Overconfidence – this is where the credibility and/or knowledge of an individual or source is overestimated.

Introducing personal bias into analysis is a risk for any Business Analyst regardless of the technique being used.

Avoiding Bias

The following is a non-exhaustive list of ways Business Analysts can mitigate, counteract or avoid introducing bias into analysis:

  • Understand your stakeholders – take the time to understand your stakeholder groups, including understanding attributes that may impact the particular needs of individuals within a group. Attributes to consider include demographic information such as age, geographic location, socio-economic status, and/or access to technology. Techniques such as stakeholder maps may assist in identifying attributes and decomposing stakeholders into more relevant sub-groupings.
  • Don’t rely on a single technique – when eliciting information from a large population of stakeholders, consider using multiple techniques across non-mutually exclusive groups. For example, follow-up surveys with interviews, consider confirming results from an observation using a follow-up questionnaire etc.
  • Support with hard evidence – where you are soliciting complex or historical information from stakeholders, confirm with hard evidence wherever possible, such as using emails, audit logs, meeting minutes and/or policy documents.
  • Census, not survey – where possible and practical, consider making responses to surveys and questionnaires ‘compulsory’, essentially turning them into a census. This approach can also be applied to interviews and observational studies where a stakeholder group is small.
  • Use advisory groups – where available, include advisory groups, unions, or other available advocacy group in your elicitation exercise to represent stakeholders. Advisory groups are more likely to have in-depth knowledge about a stakeholder group that may allow them to identify areas analysis may have failed to address. Advisory groups may also be useful when validating the findings of an elicitation exercise and understanding if further elicitation is required.
  • Understanding the context – take the time to understand the full context of the situation you are analysing, including the terms, acronyms and phrases that have a specific meaning to stakeholders. Consider keeping a glossary of terms and making sure it is validated by stakeholders to ensure language isn’t taken out-of-context.
  • Be self-aware – take the time to reflect on your own personal perspective and how it may influence your analysis. Where you are aware of a personal bias, consider finding and confiding in a colleague who can critique your approach to ensure it remains unbiased. Consider removing yourself from initiatives where you have a clear conflict of interest.


Bias is a risk to any business analysis initiative. However, with a little planning and self-awareness, any risk of bias can quite easily be mitigated or avoided.

  • 1
  • 2