Skip to main content

Author: Anna Rajander

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

Delivering Analysis: Working With the System

Business analysis is an evolving profession characterized by change. However, not all businesses embrace evolution and change in the same way. This can result in business and delivery practices constraining the use of newer, more agile approaches to business analysis. This article presents some ideas and techniques to help business analysts identify, understand, and work with constraining business practices.

 

The Challenge

You may have heard the serenity prayer. It goes something like this:

God, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and wisdom to know the difference.

The origins of the serenity prayer date back to the 1930s and 1940’s. It is one of the most well-known and quoted prayers in the Christian world, with versions adorning posters, fridge magnets and trinkets across the globe. And while the prayer predates the business analysis profession by decades, the sentiment of the prayer is relevant for many analysts – even those of us who aren’t religious.

Business analysis is a profession of change. Indeed, the IIBA defines business analysis as the “practice of enabling change” in an enterprise. Whether it be learning a new technique or method, or applying skills to a new business domain, business analysts are encouraged to constantly experiment, learn and adapt. We are often looking for opportunities to apply new skills or techniques, or engage with enterprises that are using newer, more agile delivery methods. This constant exposure to change can make business analysts very comfortable with change.

It can therefore be frustrating when we find ourselves in environments where prevailing business practices prevent us from delivering analysis in the way we would like. Outdated systems, over-zealous governance, rigid templates and document heavy processes can constrain our ability to used more modern, agile delivery methods and techniques. And inflicting change on stakeholders using outdated delivery practices can seem like a double standard! Yet, working against such practices and processes can cause even more problems, resulting in business resistance, conflicts with stakeholders, delays, and even failure to deliver.

 

Advertisement

 

Identifying Constraining Business Practices

Business analysts need to fully understand the business context in which they are delivering change. This includes understanding the business and delivery practices being used to define, design and implement change, and how they impact business analysis. Early identification of constraining business and delivery practices gives business analysts an opportunity to find ways of working with them – rather than against them.

There are several common business analysis techniques that can be used to help identify and understand restrictive business and delivery practices. For example:

  • SWOT Analysis – A SWOT analysis can be used to help identify business practices that may impede or constrain business analysis activities (in other words, are a threat to the delivery of good analysis), identify opportunities to improve business practices, and identifying any strengths/weaknesses that may help/hinder delivery given the constraints.
  • Process Analysis and Modelling – Understanding when and how analysis activities will engage with constraining business practices can support the creation of efficient business analysis plans that meets all delivery requirements.
  • Stakeholder Analysis – Remember the saying It’s who you know – not what you know? This is too often true – particularly when it comes to governance and approvals processes. Understanding who the influential stakeholders are and engaging them early can often alleviate and even remove constraints.
  • Root Cause Analysis – There is usually a reason why things are done the way they are, although it may not always be obvious. Uncovering that underlying reason for a given business practice can help analysts a) identify areas for improvement, or b) accept it for what it is.

 

Conclusion

Understanding business and delivery practices that constrain business analysis can help analysts:

  • Identify and champion opportunities for business improvement
  • Identify ways of working with or within existing business practices that may better support analysis, or
  • Accept and work with prevailing business practices as efficiently as possible.

To paraphrase the serenity prayer – accept the things you cannot change, change the things you can, and understand the difference!

 

Anna Rajander, Dec 2022
Resources:
  1. Serenity Prayer – Wikipedia, accessed Dec 2022.
  2. A Guide to the Business Analysis Book of Knowledge (BaBOK) v3, IIBA, 2015.

Business Analysis Portfolio: An Aid for Professional Development

Have you ever had a sense of business analysis déjà vu – the feeling you have used a particular business analysis technique before, but can’t quite remember what you did or how you did it? I know I have!

Business analysis is a broad and varied profession that can involve everything from narrow, well defined tasks to broad, strategic assessments. Business analysis can be performed in the context of a specific project or initiative, as part of pre- or post-project activities, or in support of ongoing operations. Over the course of a career, a Business Analyst can be exposed to numerous project delivery methods, business domains, and organizational cultures. It is this variety and continuous learning that bring many practitioners to the profession in the first place.

The BABOK contains 50 techniques, the 3rd edition of BCS’s Business Analysis Techniques 123 – it is impossible to be an expert in all business analysis techniques! While some techniques will become the mainstay of a business analyst’s arsenal, other techniques will be used infrequently to assist in specific circumstances. A final, polished piece of analysis is often achieved by carefully selecting and combining multiple techniques to build a coherent picture that encompasses different perspectives. Business context, stakeholder preference and understanding, project constraints, and a Business Analysts own personal experience can all impact technique selection.

Creating a work portfolio is a good way to keep track of the techniques you have employed in the past and the outputs you have delivered. As you move through your career, your portfolio can provide:

  • reference material to support the delivery of similar analysis products.
  • illustrative examples to use when explaining analytical approaches and deliverables to managers and junior Business Analyst colleagues.
  • a record of professional development and growth.
  • inspiration when applying for new positions or promotions.

Your portfolio can include:

  • Work Samples: Where possible, maintain copies of business analysis outputs you have produced for future reference.
  • Templates: Templates are particularly useful for those structured techniques that are performed infrequently. Generic templates can be adapted to different business contexts and domains.
  • Articles and Reference Material: Keep a record of the sources you have referenced when delivering analysis, either by keeping copies and/or maintaining a catalogue of useful books, articles, and websites.
  • Work Diary: Narrative descriptions can be used to record what you did and how you did it in enough detail for you to reference should you ever need to perform a similar task again. Use a work diary to record information about the business context, tasks perform, stakeholders consulted, and/or techniques used in the production of an analysis deliverable. Work diaries are particularly useful in circumstances where contractual restrictions, privacy and/or secrecy prevent you from holding original copies of your work. You can also use business analysis techniques in your work diary entries, such as mind maps, process models and scenarios.
  • Course Material: Include information from any courses, study groups and/or conferences you attend that might be of use in the future.

 

Advertisement

 

Some things to consider for your portfolio:

  • Maintain it – review your work and add to your portfolio regularly. While routine maintenance is recommended, project gateways, end of employment/contact, and/or end of year are good times to take stock of what you have achieved, what you have learnt, and what information you want to retain.
  • Organize it – you are more likely to use an organized resource then an unorganized one. How you organize your portfolio is very much dependent on you and how you work. However, aligning your portfolio with BABOK Knowledge Areas or stages of the Business Analysis Process is often a good starting point. Also consider using naming conventions and keywords to tag portfolio items to assist with searching as your portfolio grows.
  • Remember context – the amount of work required to deliver a single, pristine business analysis output is often deceiving. A myriad of techniques may be employed on route to the final, acceptable product. It is good practice to file your work with some contextual information to remind yourself of the business situation, intermediate steps, additional techniques, and issues you had on the journey to the polished artifact.
  • The good, bad and ugly while you shouldn’t dwell on the negative, remember that bad experiences are learning opportunities too. Using a work diary entry to reflect on a situation where a particular approach didn’t work can provide useful learnings for the future, as well as help put bad experiences behind you.
  • Be mindful of copyright – remember that the copyright for work you have been paid to produce for another entity is almost certainly held by a third party. Take care to respect all copyright. When in doubt, de-identify information and/or use work diary entries in place of original copies. In cases where you do own the copyright, you may still want to take care when sharing material as it is your IP!
  • Be creative – while you will most likely draw on your professional roles for the most of your portfolio examples, there are other, creative ways to build your portfolio. Many aspects of life can benefit from a bit of business analysis rigour – getting your home budget under control, selecting the best suburb to move to, or assisting a community organization to suggest a few. It may sound flippant but using techniques in general life can be a good way to try new techniques, apply techniques in a different context, and build examples to draw on in the future, particularly when you are just starting your business analysis journey. (You never know, it may also help you achieve a better outcome for you, your family, and/or community group!)
  • Use it – a portfolio is only valuable if it is used… so remember to use it!
References:
1.  Business Analysis Book of Knowledge v3, Institute of Business Analysis, 2015.
2. Cadle J, Paul D, Hunsley J, Reed A, Beckham D, Tuner P, Business Analysis Techniques: 123 essential tools for success (Third edition), BCS, 2021.

The Strawman: When a Wrong Makes a Right

Sometimes, the easiest way to find out what someone really wants is to show them what they don’t want.

The strawman approach is frequently used by business analysts – sometimes knowingly, and sometimes not. Actively inviting stakeholders to engage with and criticize an inaccurate reflection of requirements can provide insights that greatly speed up the requirements elicitation process. However, it can also be a risky approach.

This article describes that strawman approach, its potential pitfalls, and tips for using the approach to support productive requirements elicitation.

What is the Strawman Approach?

You may have heard of a strawman argument – an argument that distorts an opposing stance to make it easier to attack [1].

In business analysis, a strawman can be created by presenting knowingly incorrect, incomplete or distorted requirements to stakeholders in order to provoke a response. This is usually done in the form of a model or prototype solution, providing a visual representation that stakeholders can engage with and refute. The idea is that the way stakeholders respond to the inaccurate strawman will inform more complete, coherent and representative stakeholder requirements.

Stakeholders often find it difficult to articulate their requirements. They can be vague when it comes to specifying their wants (I want a bright color…), yet very specific when it comes to specifying what they don’t want (…but not pink!) This is because people often find it easier to specify their wants and needs in opposition to something. In such cases, presenting an inaccurate or incomplete model/prototype representation of requirements as a strawman can provoke a strong response from stakeholders, creating a better understanding of what they don’t want, and providing a starting point for conversations about what they do want.

 

Advertisement

 

The Pitfalls of the Strawman Approach

While the strawman approach can be a powerful requirements elicitation technique, the approach should be used with caution. Some of the potential pitfalls associated with using a strawman include:

  1. Impact on your credibility: When done right, presenting a strawman to stakeholders can make a business analyst appear open, co-operative, and responsive to stakeholder needs. However, presenting something that is clearly wrong can also impact a business analysts’ credibility, leading some stakeholders to question the analyst’s abilities.
  2. The strawman becomes the answer: The point of the strawman is that it isn’t accurate! You want stakeholders to refute it and provide information that will allow you to change and/or improve it. However, in cases where stakeholders really do not know what they want, they may not challenge the strawman. This could lead to the strawman (either in part or whole) becoming the answer.
  3. The business analyst can feel exposed: Presenting a strawman is not an easy thing to do. It takes a degree of professional courage to produce a piece of work and present it, only to have it criticized – even if that was the intention.
  4. Some stakeholders are too nice: Some people find criticism difficult and may be unwilling to say what they really think about a strawman, particularly when they are being asked to criticize it in a group setting.

Tips for using the Strawman Approach

The following are a few tips to consider when using a strawman to elicit requirements:

  • Do you research. Make the ‘strawman’ as accurate as possible. Differentiate between elements of the strawman that are based on known, more accurate requirements, and those that are ‘best guesses.’
  • Know your stakeholders. Think about how your stakeholders might react to the strawman. Think about how you present the strawman to different stakeholder groups. Consider presenting the strawman to ‘friendly’ stakeholders 1-on-1 to get feedback to improve it, prior to exposing it to more influential stakeholders and/or a larger group.
  • Acknowledge it is a strawman. Sometimes acknowledging what you are presenting is a ‘strawman’ will give stakeholders the permission they need to constructively criticize it.
  • Don’t rely on it. The strawman approach should not be used as a primary requirements elicitation approach, but rather a tool that may be deployed to elicit those more subjective requirements, engage a particular stakeholder group, or as a check for validating what you know and what you don’t.
  • Clearly label your strawmen. Once in the wild, the strawman can obtain a life of its own, being reproduced and/or discussed in unintended places. Therefore, it is important to clearly label, store and/or otherwise indicate the strawman is a draft, prototype or experiment.
  • Don’t take is personally. Remember, the stakeholders are reacting to and criticizing what is presented to them – not you personally!

 

Reference
[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology, www.effectiviology.com/straw-man-arguments-recognize-counter-use/

The Philosophical Data Analyst (Part 2): The Problem of Induction

Most organizations understand data is an asset, providing a rich resource that can be analyzed to unearth predictive insights. Many organizations invest heavily in their data operations to ensure the ongoing completeness, integrity, and accuracy of collected data. However, regardless of how complete, correct, and/or unbiased collected data may be, there are limits as to what insights can be gleaned from a given dataset. Acting on analytical insights outside these limits introduces risk.

This article describes the problem of induction – assuming you know more than you do – in the context of predictive analytics. It describes how the problem can be exacerbated by seemingly improbable or unlikely events. Finally, it outlines how PESTLE can be used to explore the limitations of the analysis, allowing Business Data Analysts to assess and mitigate risks.

Advertisement

The Problem of Induction

The Problem of Induction is not new. It has been explored by philosophers since at least the 18th century (Henderson, 2018).  Simplistically, the problem is the illusion of understanding – when people think they know what is going on when the situation is more complicated (or random) than they realize (Taleb, pg. 8).

In his book The Black Swan, Nassim Nicholas Taleb uses the plight of a Thanksgiving turkey to illustrate the problem (Taleb, pgs. 40,41). Assume a given turkey is fed every morning for 1000 days. On the first day, being fed is probably a welcome surprise to the turkey. After a few days, the turkey will start to notice a pattern and become more confident that it will be fed the following day. Over the course of the 1000 days, the turkey’s level of confidence will grow to the point that they expect – indeed are quite certain – that they will be fed the following day.

However, on day 1000, the turkey is not fed and is instead slaughtered – an event that would seem completely unpredictable (a black swan) to the turkey given its experience over the prior 1000 days. Of course, if the turkey had known about the tradition of thanksgiving, it may have been able to factor this into its predictions. Alas, this information was outside the realms of the turkey’s knowledge and experience.

Black swans are used by Taleb to describe events that seem improbable and/or unfathomable. Before the “discovery” of Australia, the idea that a swan could be anything other than white seemed preposterous to Europeans. However, a single sighting of a black swan by European settlers was enough to invalidate the understanding of an entire continent (although for the local Whadjuk Noogar people*, the idea of a swan being anything but black would have been equally preposterous – perhaps making the coming of European settlers their white swan event?)

The year 2020 provided us with an example of a black swan that no doubt exacerbated the problem of induction for many organizations. Most organizations failed to foresee the rise of COVID and its impact simply because it was outside their lived experience – a black swan. Neither its occurrence nor impact could be reliably inferred from the information they had – just as the turkey could not foresee its demise. As such, predictions for 2020 based on historical information were unlikely to be accurate. 

Note that this does not mean the pandemic and its impact could not be predicted to some degree. In the same way, the Whadjuk Noogar have always known swans could be black, health and virology experts have been publicly predicting and even planning for a pandemic for some time (see Rosling 2018, pgs. 237-238 and NHS England, 2013). In addition, available analysis from previous outbreaks of disease, such as SARS and Swine Flu, could have provided some insights into the impact of a pandemic (see Smith et. al. 2009, Australian Government Treasury 2007). However, until 2020, a pandemic was not part of the lived experience for the vast majority of organizations. Therefore, it was unlikely to be factored into their analysis and planning.

Containing the Problem of Induction: Know Your Limits

In the context of predictive data analytics, the problem of induction is often exacerbated by:

  • Assumed Continuity – when analysis implicitly assumes that the conditions under which data were collected and analyzed will be sustained. An organization may believe they are thinking about the future, but they are usually just extrapolating the present, and that’s not the same thing at all.” (Lovelock, 2020).
  • Information Blind Spot – this is where information is not considered in or has been omitted from the analysis.

Relying on predictive analytics without understanding its limitations can lead to a false level of confidence in predictions. This may mean organizations continue to ‘trust’ analysis beyond the point of reliability, taking longer to respond to changes in conditions. (It worked before; it should work now!)

Techniques such as PESTLE can provide an effective frame for exploring the limits of predictive analysis. By assessing the reliability of analysis under different scenarios, Business Data Analysts can understand and communicate limitations. The table below uses PESTLE to help identify some high-level scenarios to explore.

Political

Change in government; Market intervention (think quantitative easing); Legislative changes; Change in political stability (think Arab Spring); Act of terrorism (think 9/11); War;

Economic

Interest rate change; Cost-of-living changes; Global trade and/or supply chain issues; Recession or economic shock;

Social

Health care or housing availability crisis; Social movement (think Me Too, Black Lives Matters); Mass migration (think Syrian Civil War); Epidemic/Pandemic;

Technological

ICT security incident (think ransomware); Disruptive technology (think Uber, Air BnB); Scientific discovery/scrutiny (think smoking and cancer); Severe defect/breakdown (think Boeing 737 MAX);

Legal

New regulations/de-regulation; Employee malpractice; Legal scrutiny;

Environmental

Infrastructure outage; Natural disaster; Man-made disaster;

The technique can be used to identify more detailed scenarios that are applicable to a given organization. The idea is to think of a range of scenarios, from the probable to the seemingly improbable. Once identified, you can assess if analytical outputs are likely to be valid under each of the scenarios, thus identifying the ‘bounds’ within which the analysis can be applied. For example, you may deem that analytical outputs would continue to be reliable in the event of a democratic change of government, but not in the event of a military coup.

Once the limits of analysis are identified, steps can be taken to:

  • Identify additional information sources that may be used to strengthen analysis
  • Identify types of events that should trigger a review of analytical models, measures, and outputs
  • Identify and mitigate any risks posed by the scenario
  • Inform decision-makers of the limitations of the analysis so that it may be factored into decision-making.

Conclusion

Predictive analytics can provide useful insights to support decision-making. However, the conditions under which data is collected and analyzed naturally limit the situations under which insights should be applied. Understanding these limits can prevent analytical results from being relied on in circumstances outside of these bounds.

At the end, it’s better to have some understanding of what you don’t know than to think you know what you don’t.

*The author acknowledges the Whadjuk Noogar people, the traditional custodians of the Derbarl Yerrigan (or the Swan River), and pays her respects to elders’ past, present, and emerging.

References:

  1. Taleb, Nassim Nicholas, The Black Swan: The Impact of the Highly Improbable, Random House, 2007.
  2. Rosling H., Rosling O., Rosling Ronnlund A., Factfulness: Ten reasons we’re wrong about the world – and why things are better than you think, Flatiron Books, 2018.
  3. Henderson, Leah, The Problem of Induction, Stanford Encyclopedia of Philosophy, March 2028. (Last Accessed January 2022).
  4. Lovelock, Christina, The Power of Scenario Planning, BA Times, July 2020. (Last Accessed January 2022).
  5. Operating Framework for Managing the Response to Pandemic Influenza, NHS England, (Last Accessed January 2022).
  6. The economic impact of Severe Acute Respiratory Syndrome (SARS), The Australian Government Treasury, 2007. (Last Accessed January 2022).
  7. Smith, Keogh-Brown, Barnett, Tait,The economy-wide impact of pandemic influenza on the UK: a computable general equilibrium modelling experiment, The BMJ, 2009. (Last Accessed January 2022).

The Philosophical Data Analyst: Some Variables are from Extremistan

Most organizations understand data as an asset, providing a rich resource that can be analyzed to unearth both descriptive and predictive insights. Data-driven decision-making is promoted by many organizations. More and more, organizations are processing and analyzing data in real-time, automating operations based on results, making them reliant not only on the data but on the methods used to analyze it.

Many organizations invest heavily in their data operations to ensure the ongoing completeness, integrity, and accuracy of collected data. However, regardless of how complete, correct, and/or unbiased collected data may be, there are limits as to what insights can be gleaned from a given dataset. Acting on analytical insights outside these limits introduces risk.

Advertisement

This article describes risks posed by data variables that are susceptible to seemingly improbable or extreme values. It explains the characteristics of susceptible data variables and outlines a simple technique for identifying them.  Once identified, Business Data Analysts can assess the impact of using these variables in the analysis, allowing any risks to be quantified and mitigated and/or alternatives analytical approaches explored.

Mediocristan vs. Extremistan

It is common to describe the range and frequency of variable values using statistical distribution patterns. The ability to describe data variables using a particular distribution pattern is a prerequisite for many data modeling methods. The most common statistical distribution pattern is Normal Distribution or the bell curve.

Image credit: MathsIsFun.com

For a normally distributed data variable, the frequency of values is symmetrically clustered around a mean – the further away from the mean, the less likely the data variable will take on that value. However, in some cases, data variables may appear to hold a certain statistical distribution pattern when, in fact, they may legitimately take on values that (given the distribution pattern) are deemed improbable or extreme – particularly in cases where a variable is subject to complex and/or unknown external influences.

In The Black Swan, Taleb introduces the idea of Mediocristan and Extremistan. Taleb defines Mediocristan as subject to the routine, obvious and predicted, while Extremistan is subject to the singular, accidental, and unseen (Taleb, pg. 35).  Applied to data analysis, data variables from Extremistan are susceptible to extreme and/or unpredictable values, while those from Mediocristan are not. The argument is that data from Extremistan cannot be accurately described using common statistical distribution patterns – and certainly cannot be described using normal distribution as value frequency is not symmetrical.

For example, take a sample of 1000 randomly selected human beings. If you were to calculate the average height of the group, what would you expect the answer to be? Now add the tallest human on earth to the sample (which will now comprise 1001 humans) and recalculate the average height of the group. How much would you expect the result to change? The answer is not a lot as there is a limit as to how tall a human can be. While adding the tallest human on earth to the sample would cause the overall average to rise, the impact would be minor. Human height is an example of a variable from Mediocristan.

Now perform a similar thought experiment, except this time use net worth instead of height. What would you expect to happen to the calculated average net worth of a randomly selected group of 1000 human beings if you were to add the richest person in the world to the group? In 2021, Forbes identified Jeff Bazos as having the highest net worth in the world, estimated to be around US$177 billion. You would expect the average from the sample that included Jeff Bazos to be dramatically higher compared to one that didn’t. Net worth is an example of a variable from Extremistan.

The problem is that if you were to take a random sample of 1000 humans from earth, what is the likelihood that it would include Jeff Bazos? Or Bill Gates? Or Jay-Z? Or the Queen? Or anyone else with a much higher net worth than average? And if the sample did happen to include one of these individuals, what would you do with the offending value? Would you treat it as a true representation of the entity being described? Or would you discard it as an outlier?

Extreme values can be mistaken for outliers when they are in fact indicative of the behavior of the entity they are representing. Analysis that does not account for Extremistan variables properly may prove unreliable – particularly when accurate but extreme values enter the underlying data. Extremistan variables may also be subject to extreme changes in value as a result of seemingly unlikely or improbable events (for example, a sudden stock market shock impacting the net worth of some individuals more than others).

What to do in Extremistan?

Taleb proposes a method for modeling Extremistan variables based on the work of the mathematician Mandelbrot, the pioneer of factual geometry. However, mathematics is complicated and beyond the capabilities of most organizations. (As most Business Data Analysts would know, explaining analysis based on simple mathematics to stakeholders can be a struggle – let alone analysis that uses more complex mathematical modeling techniques). Understanding Extremistan variables, how they contribute to the analysis, and mitigating any risks their use poses is a more realistic goal for most organizations.

Start by classifying data variables into the categories ‘Mediocristan’ and ‘Extremistan’. The table below provides some guidance on the characteristics of Mediocristan and Extremistan variables.

Mediocristan

Extremistan

Non-scalable

Scalable

The most typical member is mediocre

There is no ‘typical’ member

Winner gets a small segment of the pie

Winner takes all

Impervious to Black Swan (seemingly improbable) events

Vulnerable to Black Swan (seemingly improbable) events

Often corresponds to physical quantities with limits

Often corresponds to numbers with no limits

Physical, naturally occurring phenomena are often from Mediocristan

Variables that describe social, man-made aspects of human society are often from Extremistan

Examples include height, weight, age, calorie consumption, IQ, mortality rates…

Examples include income, house prices, number of social media followers, financial markets, book sales by author, damage caused by natural disasters…

 (Adapted from Taleb, pg. 35, 36)

Once classified, Business Data Analysts can identify where and when Extremistan variables are used in the analysis, and whether they pose any risk to the accuracy/reliability of analytical outputs. In many cases, this can be done simply by identifying or estimating extreme data points (such as the Jess Bazos in the example above), adding them to the underlying data, and assessing their impact on the analysis.

Note that using Extremistan variables in the analysis is not necessarily a problem – it depends on how they have been analyzed and the insights that are drawn from the analysis. Some analytical and modeling techniques will be able to deal with Extremistan variables without introducing much risk. However, be wary of analysis the assumes Extremistan variables to be normally distributed and/or simply treats legitimate extreme values as outliers.

When classifying variables, it is also important to consider the scope of the data collection, and the context in which it is being analyzed. Take for example a sample of bakers who live in a certain region. You may want to use data collected from this sample to predict the income of other bakers in the same region. Assuming there are no issues with data quality and/or data collection, baker income is likely to be a variable in Mediocristan as there is a limit to how much bread a baker can bake in a day, and price/demand variability for baked goods is usually low.  On the other hand, take the same example and replace ‘baker’ with ‘social media influencer’. A social media influencers income is subject to a more complex and ephemeral range of factors, such as numbers of clicks, ‘fame’, the popularity of social media platforms, etc. As such, social media influencer income is more likely to be from Extremistan.

Conclusion

Data is an asset. Data-driven decision-making can help increase efficiency, drive innovation, and reduce bias in decision-making. However, it is important to understand that there are limits to the insights that can be drawn from a given dataset. By identifying variables that may be subject to extremes, analysts can ensure these variables are appropriately accounted for in analysis by assessing any risks, and ensuring analytical insights are considered in context.

But know this – variables from Extremistan are anything but normal!

References:

  1. Taleb, Nassim Nicholas, The Black Swan: The Impact of the Highly Improbable, Random House, 2007.
  2. Guide to Business Data Analytics: Getting Better Insights. Guide Better Informed Decision Making. IIBA, 2020.
  3. Normal Distribution, MathsIsFun.com, 2021. (Last accessed Jan 2022).
  4. Dolan, Kerry A., Forbes 35th Annual World’s Billionaires List: Facts and Figures 2021, Forbes, Apr 2021. (Last accessed Jan 2022).
  5. Penn, Amanda, Extremistan: Why Improbable Events Have a Huge Impact, Nov 2019. (Blog last accessed Jan 2022).