Skip to main content

Tag: Business Analysis

The Skeptical Business Analyst – 9 Tools to Build a Baloney Detection Kit

Skeptical is a highly-charged word. Are you skeptical? In business being skeptical is akin to being a nay-sayer, difficult to work with, not being a team player or a trouble maker.

Skeptical does not need to be destructive or negative. You do not have to be a jerk to be skeptical. Skeptical can mean looking at things with a critical eye respectfully and politely to create thoughtful and meaningful discussions to elicit business requirements and build business solutions.

Carl Sagan (November 9, 1934–December 20, 1996) was an American astronomer, cosmologist, and astrophysicist who was known as a master of the balance between skepticism and openness. In Carl’s last book, he wrote a chapter titled “The Fine Art of Baloney Detection” where he outlines the “Baloney Detection Kit.” With the introduction of new ideas, Carl Sagan used the kit to evaluate them. If the new idea survives examination by the tools in the kit, the idea was given a warm reception and sometimes a provisional acceptance of the idea. If the new idea was challenged by the kit and didn’t fare well, the idea was refined and modified.

The Baloney Detection Kit is a collection of tools that can apply elegantly to business solutions and requirements elicitation in the Business Analyst profession. Although these tools were designed for the larger realm of cosmic exploration, physics, and science, they are equally at home with a Business Analysts thinking. Let’s focus on how these tools are used for elicitation and design as a part of the Business Analyst role.

1. Wherever Possible There Must Be Independent Confirmation of The Facts

Several hard lessons were learned in dealing with Commercial Off-the-Shelf (COTS) vendors and when dealing with reporting dashboards for business intelligence projects. The mistake was accepting the facts at face value and not verifying those facts.

For the COTS project, it meant accepting the vendor’s statement that the solution would perform the desired function without verifying the desired function worked. Building a sandbox to use as a playground to verify the desired function worked in the COTS application is very beneficial.

For the Business Intelligence project, it was confirmation of the meaning of the data, and it’s overall quality and accuracy. A simple data discussion has turned into a spirited debate about what a data field means and the data it contains. Learning to avoid useless reports by carefully evaluating the quality and accuracy of the data has been my greatest lesson. Just because data is captured doesn’t mean it is captured accurately or that it has quality. I have had many cases where all stakeholders trusted the quality of the data without question, but after thoughtful and careful review it was determined the data was of low quality.

2. Encourage Substantive Debate by Knowledgeable Proponents of All Points of View

A forest is seen in many ways. From above you see the canopy of green leaves. From the ground, you see the tree trunks and branches. Looking from below ground, you see the roots of the trees. Different perspectives give you a deeper understanding of the overall situation that leads to more efficient and meaningful solutions.

When eliciting the requirements or validation of the business solution, a Business Analyst needs to see the whole picture. By looking more globally, you can determine how the solution will fit into the organization. An example of this would be only looking at the needs for a Customer Relationship Management tool from the perspective of customer service and ignoring marketing and sales teams in eliciting requirements. Marketing and Sales have specific requirements when interacting with customers just as the Customer Service Team. Even though the scope of the project is entirely within Customer Service, care should be taken to understanding Marketing and Sales teams that could in the future utilize or connect with the system.

Systems created in a silo was a pitfall for many of my clients by not looking at the larger organization and how it would use a CRM solution. So, each department that interacted with a customer – 9 different teams in all – created their separate systems which created a costly solution to maintain 9 CRM solutions and 60+ interfaces to pass data between them. The solution was to combine all 9 CRM solutions into a single CRM solution to save costs. It took two years to complete the consolidation. It was very costly for the organization not to look at a more global approach to creating a CRM application.

Another example of this would be from another client that had three different locations for product testing laboratories. The labs mostly did not talk with each other because they were in different parts of the world. The project was to upgrade a Laboratory Information Management System (LIMS) in one of the locations because the vendor no longer supported the version the lab was working on and it did not connect to all their new lab equipment. The lab manager assured me that talking with the other labs would be a waste of time. The team saw an article on the web about one of the other labs upgrading to a new system. We reached out to them to get a better understanding of the cost and project effort that would be required. Surprisingly we discovered they had a tool that would meet all our needs, an enterprise license for the software that would save our project money and desired a better connection to our lab. The overall result was the reduction of the project budget and project duration cut in half.

3. Arguments from Experts Carry Little Weight

This tool is the most charged of the tools in the kit. The statement here is that no one is all knowing or God-like in his or her knowledge of a system or process. Experts have made assumptions based on their experience, but handle assumptions of all kinds with great care. Systems and processes are ever evolving and changing. This situation seems to happen on projects where a business team member is considered the all-knowing expert for a process or system that doesn’t like to be challenged. These individuals begin to “spin” the facts to avoid looking like they made a mistake and their desire to maintain the status of all-knowing. They do not want to lose face. It becomes tough to understand the overall current state but probing gently and thoughtfully in a non-threatening way can lead to the discovery of the current state issues and root causes. Care if taken to avoid the expert feeling that you do not trust them. Seek to understand first and gain the agreement of the current or future states.

No one is infallible or all-knowing. Care should be taken to verify what an expert gives you facts or requirements. It is not disrespectful to challenge an expert. If done thoughtfully and gently it can build a strong business relationship.

4. Spin More Than One Hypothesis

In Business Analysis, we create solutions to problems, and we help build designs to solve those business problems. In a way, a business design or a business solution is a hypothesis. It is a potential way to solve a business problem. In Business Analysis, we typically don’t create multiple business solutions and then compare them against each other, but one of the strengths of a COTS project is that you are comparing multiple vendor solutions against each other to ensure you get the best possible. In several recent projects, I have taken to building multiple potential internal solutions and then comparing them against each other in a similar fashion to comparing COTS solutions to each other.

The outcome of this was that I could see a broader range of solutions. Additionally, my stakeholders and sponsors felt they had an opportunity to pick a solution, feel invested in that solution and not feel Technology was forcing them to accept only one solution. The other interesting outcome of this approach is stakeholders and sponsors pulling ideas from one solution into another solution to create a whole new approach.

If there’s something to be explained, think of all the different explanations. Then think of tests by which you might systematically disprove each of the alternatives. What survives has a much better chance of being an effective solution than if you had simply run with the first idea.

5. Try Not to Get Attached to a Hypothesis Just Because It is Yours

A better way to state this would don’t get hooked on a solution you came up with and ignore other potential solutions. Be open to other potential business solutions and be open to modifications or changes to the business solution you have put forward. Building the best business solution needs flexibility and collaboration.

Ask yourself why you like the idea. Compare it fairly with the alternatives. See if you can find reasons for rejecting it and modify the idea to strengthen it.

6. Quantify

If whatever it is you are explaining has some measure, some numerical quantity attached to it, you will be much better able to discriminate among competing hypotheses or solutions. Quantification of requirements and business solutions are important. Ensure the requirement or solution can be quantified by analysis. Every solution should have an objective measurement that can be used to determine its value when compared to other solutions.

Anything that is vague and open to many different explanations will result in requirements and business solutions being confusing, frustrating, and easily misinterpretation. At the beginning of a project either when we are creating the business case or just been assigned to a project there is a lot of uncertainty and assumptions. As you move through the project, it is important to track all the assumptions made and verify them as you move forward. I have had some assumptions that were never resolved until the project was almost completed. Challenge assumptions made and resolve them continuously throughout. A bad assumption can lead the project down a path to a bad or ineffective business solution.

7. Every Chain Link Must Work

If there’s a chain of argument or solution, every link in the chain must work (including the premise) — not just most of them. Business solutions are systems, hardware, software, processes, data, interfaces, integrations and business rules that are chained together. This is where traceability shines brightly.

Ensuring that scope aligns with requirements and requirements to test cases is the basic traceability. Advanced Traceability is making sure every part of the business solution is in alignment and supporting each other and that nothing was missed from the overall solution design.

Business process neatly falls into this discussion. Each task in a business process is connected by the task ahead of it or after it. To verify a business process each task’s input, processing, and output are verified. The SIPOC can be a good technique for verification.

8. Occam’s Razor

When faced with two hypotheses or solutions that solve the business problem equally well, it is wiser to choose the simpler or less complicated solution. Simplicity has great power in that it can be understood more easily. The greatest challenge of any business analyst is taking complex business problems and solving them with simple business solutions.

9. Always Ask Whether the Hypothesis Can Be, At Least In Principle, Falsified.

This tool is the second most charged tool in the kit because of the word falsified which has a strong negative reaction. The hypothesis in this context can be related to a business solution. In the Business Analysis context, this is the verification or validation of the business solution.

Let’s take the word falsified in a new direction and away from a negative space and any ethical discussions. To apply this tool to Business Analysis the proposed business solution should be testable and verified. Building a sandbox or prototype helps test a business solution without having to completely build it.

Conference room pilots and simulations are other ways of testing to ensure the business solution will solve the business problem. In Business Analysis terms this is the verification of the proposed business solution. Testing is one part of the equation. Verification and validation which can be managed in requirements traceability are equally important. Resolving assumptions and verification of those assumption used in the business solution should be addressed.

Review the solution and open it up to critical feedback from stakeholders. This opens up collaboration with stakeholders and sponsors on the business solution. Allow your assumptions, experiments, prototypes to be interacted with by stakeholders and sponsors to see if they get the same results you did when interacting with the business solution.

Summary

There are a lot of good things that can come from being a positive skeptical Business Analyst. Are you a skeptical Business Analyst? Do you think you can be skeptical without being seen as mean spirited? Let me know your thoughts in the comments below.

References
In The Demon-Haunted World: Science as a Candle in the Dark by Carl Sagan published February 27, 1997. Available on Amazon.com. ISBN-10: 0345409469
Carl Sagan Autobiography – https://en.wikipedia.org/wiki/Carl_Sagan
The Baloney Detection Kit: Carl Sagan’s Rules for BS-Busting and Critical Thinking – https://www.brainpickings.org/2014/01/03/baloney-detection-kit-carl-sagan/

7 Things Business Analysts Need to Know About Agile

1. Agile is Not a Methodology. It is a mindset.

Agile has reached and frankly blazed past buzzword stage. It is also no longer new (the term being applied to software development over 16 years ago). As people become familiar with it for the first time, it is frequently referred to as a software development methodology or a project management methodology.

It is neither of those things or anything. It is a way of looking at and thinking about how to approach knowledge work. Instead of a noun, it is an adjective.

Alistair Cockburn described it best on his blog. The essential part of his argument is that methodology is a set of conventions the team agrees to follow. Scrum, Kanban, XP, SAFe, etc. are frameworks that teams use as a starting point for creating their methodology to fit their context. (Some people in the Scrum and SAFe worlds forget that).

The agile mindset provides some guidance that teams can follow when creating their methodology, including the idea that teams should create their methodology in the first place. I have my own way of viewing the agile mindset, and I like the description that Joshua Kerievsky has championed recently:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

2. There’s More to Agile Than Just Scrum

The Scrum framework has won the market share wars as the most commonly used framework when organizations adopt agile. That leads many people to conclude that agile = scrum. In reality, Scrum is only one of many frameworks that you can use as a starting point to approach work in an agile fashion. I like to use an analogy here: Scrum is to agile as Kleenex is to facial tissue.

Why is that important? Because Scrum is only one way to approach living agile values and principles, it is not appropriate in every situation, and it is not a complete solution. If people think that they have to do scrum to be agile, they also conclude they have to have sprints, even when the nature of work lends itself to reprioritizing and deploying much more frequently than once every two weeks. It also leads them to ignore the excellent technical practices found in extreme programming.

Corollary: Scrum is not an acronym. It is a term borrowed from rugby.

3. Analysis is Still Relevant

Just because most of the frameworks do not mention business analysts does not mean that business analysis is still not necessary. The frameworks are not intended to be all-encompassing.

The agile frameworks were created by software developers to solve problems that software developers face. They all have a role that is responsible for determining the right thing for the team to work on. In Scrum, that is the product owner. In XP, that is the onsite customer. Most of those frameworks do not say how that is done.

That is where analysis comes in. Analysis techniques are still useful, but you will find that how and when you use them changes. You perform small amounts of analysis more frequently to aid communication and build a shared understanding rather than do all of your analysis at once to produce the only means of communicating.

4) Agile Alone Will Not Get You Better, Faster, Cheaper

Teams and organizations can also use analysis to determine the right things to deliver, and the things not to deliver. Because most of the agile frameworks do not mention this, they defer that responsibility to a specific role, without much insight into how to do it.

When organizations adopt agile in their IT and development organizations and do not make corresponding changes in how they manage their portfolio of work, they soon find that they have become more efficient at producing the wrong things.

When organizations combine proper decision making and a focus on outcomes with well-functioning development teams that build quality into what they build do they truly realize the benefits of an agile mindset.

5) Writing and Slicing User Stories Is Not The Whole Story

Business analysis does not exist to elicit, document, and manage requirements. It exists to “enable change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.” Requirements are only a means to those ends.

Along those same lines, there’s much more to analysis with an agile mindset than writing user stories and slicing them down to a certain size. Those are just a couple of mechanisms that you can use to help build a shared understanding with your team about the problem and the solution. Many other techniques are helpful to have in your toolkit such as job stories, specification by example, story mapping, context diagrams, process decomposition, mockups, wireframes, and a host of others.

The next time you get obsessed with how you write user stories, remember what Jeff Patton says “Stories get their name from how they should be used, not what should be written.”

6. Business Analysts Can Be Product Owners

Product ownership boils down to three things:

  • Focus everyone on outcome over output.
  • Build and maintain shared understanding
  • Make decisions.

As I describe in a series of posts on product ownership models, there are several circumstances where business analysts perform product ownership and do those three things. To make that happen a business analyst needs to be able to make decisions. Good BA’s should already do the other two things as a matter of course.

In some cases business analysts do not make the decisions themselves. This occurs when they are dealing with several stakeholders who do not own the internal product but have a considerable say in what it looks like. In those situations, the business analyst may still be a product owner, but the third item is more appropriately worded “Make sure decisions get made.” If the business analyst does her job right, the development team will not experience a difference. They will not experience interruptions due to delays in decision making. They just may not have insight into how those decisions got made.

7. Business Analysis Does Not Have to Be Product Owners

If a business analyst is not a product owner that does not mean there is no place for them in an agile setting. A common model is where there is both a product owner and business analyst work on the same team. This model often occurs where the product owner makes decisions, and the business analyst focuses on building and maintaining shared understanding. This model is also prevalent when there are multiple teams working on a complicated product.

I have also seen business analysts slide into the role of coach (scrum master) because they have excellent facilitation skills and can work through team dynamics issues. This situation is a good indication that people should fill the roles that their experiences and expertise prepare them for, not solely based on their job title.

Did I Miss Anything?

I would like to hear your thoughts. Is there something I missed that business analysts need to know about agile? Do you have questions about anything I listed?

Let me know in the comments.

Is Business Analysis the Foundation for Innovation?

Every organization performs business analysis and good business analysis is all about better business performance.

Together, technology and good business analysis is the key to superior results—and, in this century, it also means innovation.

“There is no such thing as a new idea. It is impossible. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope. We give them a turn, and they make new and curious combinations. We keep on turning and making new combinations indefinitely, but they are the same old pieces of colored glass that have been in use through all the ages.” Mark Twain

Innovation is “the process of translating an idea into a good or service that creates value for which customers will pay” (from businessdictionary.com). Invention is not innovation — invention is coming up with a great idea, while innovation is executing a great idea and getting it to spread.

When Elon Musk was asked by TED Talks why he was a natural innovator, he said, “A good framework for thinking is Physics where the first principle is the reasoning. Boil things down to fundamental truths and reason up from there rather than reasoning from analogy.”

I think innovation only comes from fully understanding the present state (as is), asking “why not” and testing, rather than asking why something would not work. Asking why is exactly what the six knowledge areas of the BABOK® Guide encourages and many business analysts (BAs) perform every day.

A typical process we would follow is Design Thinking, Lean and Agile from strategy, investment, delivery, and change. A shared understanding of current state is a must and is often a trap for young players as they jump to flash innovation. Ideas are easy to generate—we find no shortage of ideas within an organization. The key is to conduct enough research (which is often lacking as the “let’s jump into it” is the louder call) and do enough prototyping and building, prioritizing innovative ideas, then make the change to a future state both internally and externally.

Many BAs are great at facilitating innovation as the intellectual property retained, having a deep knowledge of business analysis, which in some cases is better than end users of how end-to-end services and products are delivered to customers.

I have been delivering through Agilely for over fifteen years. Many people who follow Agile approaches focus on software, sometimes throwing out words around software innovation. Again, this is a trap: Software can help innovation, but it must be started with good business thinking. Creating a new “funky” piece of software that is user-friendly is no good unless it is delivering services and/or products to customers.

Often Agile approaches are great for engaging stakeholders and satisfying their wishes, but better business performance is so much more. Customer experience (CX) is more important than user experience (UX).

Large business transformation occurs at the business layer, not at the software layer. Uber is the perfect example—using private vehicles to transport people is nothing new and neither is matching supply and demand, while mobile apps have been around since 1992 when I used an Apple Newton. Combining these concepts under a single scalable business model, with a well-designed UX mobile app, a transparent service-delivery rating system, and improved CX is new.

Remember: The acid test is not just companies that have great software, but those companies that have great customer experiences through their apps, and that are continually and consistently innovating to provide their customers better experiences through end-to-end products and services delivery.

Being a bank that is “the best at Agile” is not useful if the bank is not great at selling products and services to customers.

A business analyst who is well trained, experienced in the breadth of business analysis from strategic to detail, and who is industry aligned, certified, and practice-supported, is the best person to improve business performance through innovation.

By using an expert in business analysis, your innovation will be created for you to the highest of standards, and your risk of failure will be far lower. Proper business analysis engages and empowers stakeholders, enabling them to deliver value to customers in better ways.

It is all about helping more companies to think about the “why” before going ahead,

preventing a technology project or initiative providing little or no value to an organization.

An expert business analyst requires a unique skillset many senior executives have never experienced, so it is difficult for management to distinguish between average business analysis and good business analysis. Often, subject-matter experts or untrained individuals are used as business analysts to deliver suboptimal business analysis.

Good business analysis is the foundation for organizational

  • innovation
  • business agility
  • cost reduction
  • cyber security
  • risk control
  • technology efficiency.

The BABOK® Guide also states that “a business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role.”

The BABOK® Guide does not make the distinction of business analyst quality, competency, and experience in the breadth of tasks and techniques; however, IIBA® certification does require breadth across the six knowledge areas (KA). Evidence in the field strongly suggests that good business analysis is more likely to be achieved by a well-trained, industry-aligned, certified, and practice-supported business analyst who is experienced in multiple approaches and end-to-end business analysis across the BABOK®.

As organizations look to become more innovative to survive and prosper with technology in overcrowded industries, employing skilled business analysts is critical. Businesses today are more competitive than ever, and good business analysis can deliver an advantage that gives businesses the differentiating edge they require to prosper.

Is innovation just good business analysis? If good business analysis is about better business performance and innovation is about improving business in an innovative and distributive manner, then good business analysis is the foundation of innovation. Business analysis is much broader than just innovation as it includes continuous improvement, delivery, and business as usual, but good innovation uses business analysis.

Stuck in the Middle

As Business Analysts, we have all been there.

We held high hopes for a collegial give-and-take in a workshop or a productive meeting where processes and requirements are teased out. In our imagination, visions of cooperative brainstorming danced before our eyes along with the shimmering promise of decisive and swift stakeholder agreement. The solution would be optimal and deliver a quality outcome.

Then the project starts, and the original objectives are lost. It moves from the potential of an excellent solution to a half-baked compromise. The users only have a fraction of what they wanted, and that fraction does not do anything useful. Everyone swears they did not ask for what he or she got although our requirements management spreadsheet/system says otherwise (and so do the stakeholder signatures). In the world of Scrum, the product owner looks at the design and keeps saying, “Is that what I asked for?” Moreover, the design keeps changing.

The Business Analyst struggles their way through the project feeling like a failure, wondering why the exciting techniques described in the BABOK (brainstorming, collaborative games, experimenting, research!) seem so ineffective.

For example, the BABOK 3 notes that “Workshops can promote trust, mutual understanding, and strong communication among the stakeholders and produce deliverables that structure and guide future work efforts.” However, the BABOK does list some limitations. “The success of the workshop is highly dependent on the expertise of the facilitator and knowledge of the participants. Workshops that involve too many participants can slow down the workshop process. Conversely, collecting input from too few participants can lead to the overlooking of needs or issues that are important to some stakeholders, or to the arrival at decisions that don’t represent the needs of the majority of the stakeholders.”

Research argues that the long-standing advice about collaboration in the workplace may be entirely wrong. The paper “Equality bias impairs collective decision-making across cultures” suggests that decisions made during meetings, workshops or as part of a collaborative team, will likely not only be less than optimal, but possibly substandard unless all participants are at an equal level of expertise and (just as important) awareness.

Ali Mahmoodi and his coauthors wrote, “When making decisions together, we tend to give everyone an equal chance to voice their opinion. To make the best decisions, each opinion must be scaled according to its reliability. Using behavioral experiments and computational modeling, we tested (in Denmark, Iran, and China) the extent to which people follow this latter, normative strategy. We found that people show a strong equality bias: they weight each other’s opinion equally regardless of differences in their reliability, even when this strategy was at odds with explicit feedback or monetary incentives.”

The problem is compounded by the inability of most people to recognize when they are not competent. “A wealth of research suggests that people are poor judges of their own competence—not only when judged in isolation but also when judged relative to others. For example, people tend to overestimate their own performance on hard tasks; paradoxically, when given an easy task, they tend to underestimate their own performance (the hard-easy effect) (1). Relatedly, when comparing themselves to others, people with low competence tend to think they are as good as everyone else, whereas people with high competence tend to think they are as bad as everyone else (the Dunning–Kruger effect) (2). Also, when presented with expert advice, people tend to insist on their own opinion, even though they would have benefitted from following the advisor’s recommendation (egocentric advice discounting).” (Mahmoodi et al., 2015.)

This suggests that even in a facilitated workshop, the bias will not be sufficiently neutralized to get the desired outcomes. People will still insist on their own view of requirements, even if they are faced with differing opinions. Alternatively, they defer to the person perceived as having higher competence, even if that is not true. As suggested by Mahmoodi’s paper, and contrary to received wisdom, the best strategy for arriving at a set of optimal requirements might first involve determining the participant’s skill levels before deciding which requirements are more valid. The research also suggests fewer, more knowledgeable participants in a workshop or meeting could produce a clearer set of requirements.

The danger of assuming expertise (the Dunning-Kruger effect) and the demonstration of equally weighting people’s opinions are witnessed in a real-world project example from New Zealand. Novopay was an infamous education sector payroll project, and the government ran an inquiry to identify the issues that led to its failure. The inquiry specifically called out the SMEs (Subject Matter Experts) in the report. “The Ministry had difficulty providing sufficient SMEs with adequate knowledge, and there were many examples of SME input being incomplete, inaccurate or contradictory.” (Jack and Wevers, 2013.) The Ministry did not have the expertise to realize their SMEs were not providing competent information, and the SMEs thought they had sufficient expertise to provide advice on a software development project. As the SMEs and the Ministry agreed with each other and at the same time deferred to each other, it is no surprise that the project had major issues.

This behavior is not unique, and anecdotal evidence suggests many projects fall into the same trap. David Dunning (one of the researchers who identified what is now called the Dunning-Kruger effect) points out that our minds can be, “(…) filled with the clutter of irrelevant or misleading life experiences, theories, facts, intuitions, strategies, algorithms, heuristics, metaphors, and hunches that regrettably have the look and feel of useful and accurate knowledge. This clutter is an unfortunate by-product of one of our greatest strengths as a species. We are unbridled pattern recognizers and profligate theorizers.” (Dunning, 2014.)

The problem of cognitive biases may also help explain some of the frustrations evident in the Agile world. Scrum tries to deal with the issue of identifying who can guide the product vision by assigning one role to the task—the product owner. Scrum aims to reduce the hazards associated with everyone making decisions by making one person responsible for the product. Of course, the pitfall is that the product owner needs to have real expertise, as opposed to thinking they have expertise. Although the Agile approach seems instinctively better, (collaboration, sustainable pace, self-organizing teams, business people and developers working together), Agile remains as susceptible to failure as the waterfall model. Perhaps it comes down to the simple fact that the Agile Manifesto was conceived by experts who may have assumed that everyone else was highly skilled. In the ordinary world, there are enough people trying to use Agile that are precisely none of those things.

So, what’s a business analyst to do in the face of the knowledge that we are all affected by cognitive biases and metacognition errors?

Luckily, business analysts have the only role on the project that stands a chance of seeing past the biases. We are tasked with collecting information and reviewing it as best we can, and producing (what we hope) is an optimal solution. We are forced to keep an open mind and arrive at our conclusions by weighing up options. As a business analyst working on a project by project basis, there are many occasions when we have little or no knowledge about the business area/organization that we are working for. It makes it impossible to maintain an illusion that we are competent because it is obvious that we are not. Therefore, we have already cleared one hurdle: we have enough expertise to realize we are not an expert and seek assistance from others.

This of course, can be a double-edged sword. If we have worked in one industry for a period of time, there’s a danger (as per the Novopay example) that we assume we know the job intimately enough to produce a sound set of requirements without consulting anyone else in the business.

We also need to contemplate whether we have the right business analysis skills for a project or if we are at the right level to tackle the task ahead. If we consider the pitfall of cognitive biases, it is obvious that we could fall into the trap of thinking that we are proficient in analysis when we are not. Therefore, the IIBA certifications become an important instrument in helping to offset this delusion. By gaining certification, we have gone some way to proving we have a level of mastery in the business analysis arena.

Even certification does not completely get us off the hook. Dunning points out education’s limits. “Here’s a particularly frightful example: Driver’s education courses, particularly those aimed at handling emergency maneuvers, tend to increase, rather than decrease, accident rates. They do so because training people to handle, say, snow and ice leave them with the lasting impression that they are permanent experts on the subject. In fact, their skills usually rapidly erode after they leave the course. Months or even decades later, they have confidence but little leftover competence when their wheels begin to spin.” (Dunning, 2014.)

Recertification, although painful, may be the necessary thorn in our sides that prevents us from assuming we are still good business analysts twenty years after we read a book on the subject.

Finally, there’s one consoling aspect of learning about cognitive biases: we can be less hard on ourselves if we are struggling to get any agreement on requirements, or if the user stories cannot be corralled into a sensible design. It may be a clear demonstration of Dunning-Kruger and the equality bias in full effect rather than the fault of the business analyst.

Then again, maybe that is just another example of an error in thinking. As David Dunning notes, cognitive biases are, “the anosognosia of everyday life.” (Dunning, 2004.)

“As such, wisdom may not involve facts and formulas so much as the ability to recognize when a limit has been reached. Stumbling through all our cognitive clutter just to recognize a true “I do not know” may not constitute failure as much as it does an enviable success, a crucial signpost that shows us we are traveling in the right direction toward the truth.” (Dunning, 2014.)

Bibliography
IIBA, BABOK v3 A Guide to the Business Analysis Body of Knowledge: (International Institute of Business Analysis, Toronto, Ontario, Canada, 2015)
Al Mahmoodi, Dan Bang, Karsten Olsen, Yuanyuan Aimee Zhao, Zhenhao Shi, Kristina Broberg, Shervin Safavi, Shihui Han, Majid Nili Ahmadabadi, Chris D. Frith, Andreas Roepstorff, Geraint Rees, Bahador Bahrami, “Equality bias impairs collective decision-making across cultures”, Proceeding of the National Academy of Science (2015): http://www.pnas.org/content/112/12/3835.full.pdf.
Murray Jack and Sir Maarten Wevers, KNZM, Report of the Ministerial Inquiry into the Novopay Project, (New Zealand Government, 2013).
David Dunning, “We are all Confident Idiots,” Pacific Standard. Miller-McCune Center for Research, Media, and Public Policy (2014): https://psmag.com/we-are-all-confident-idiots-56a60eb7febc#.tvb54we9p.
David Dunning, Self-insight: Roadblocks and Detours on the Path to Knowing Thyself: (Taylor & Francis, 2004).

Editor’s Notes
(1) The hard–easy effect is a cognitive bias that manifests itself as a tendency to overestimate the probability of one’s success at a task perceived as hard and to underestimate the likelihood of one’s success at a task perceived as easy. (Wikipedia definition – https://en.wikipedia.org/wiki/Hard–easy_effect)

(2) The Dunning–Kruger effect is a cognitive bias in which low-ability individuals suffer from illusory superiority, mistakenly assessing their ability as much higher than it really is. (Wikipedia definition – https://en.wikipedia.org/wiki/Dunning–Kruger_effect)

Strategy Spotlight: Roles, Responsibilities, and Skills – Project Managers and Business Analysts Meet Business Analysis

Project Managers and Business Analysts meets Business Analysis (clarify your perspective)

It still amazes me, after 14 years of speaking, teaching and writing about Business Analysis I still get this question: “What is the difference between a Business Analyst and a Project Manager?” I was teaching a Fundamentals of Business Analysis program for Project Managers when this question was raised. Since the program was focused more on Project Managers, we are using the Project Management Institutes (PMI), Business Analysis for Practitioners: A Practice Guide as a reference.

Related Article:  The Project Manager Vs. The Business Analyst

So here I am with 47 of my new closest best friends having a dialogue about the role and responsibility differences in these professions. The simple answer to this question is the Project Manager is responsible for the beginning, middle and end of a project with initiation, planning, execution and closure whereas the Business Analyst is concerned with the end product and business solution making sure the requirements are met for the key stakeholders.

Here’s the thing: the question being asked is about titles and positions but does not actually ask about roles and responsibilities. For example, as a Director of Operations, you would have the title and a position. In a traditional organization, you might even think you have some authority rights, which in today’s rapid business climate is a bit passé. As Director, you would take on certain roles and responsibilities beyond the position sitting on committees, running initiatives (projects) and even doing Business Analysis work. Maybe at a different level, but you would be.

In reality, Business Analysis can be performed by anyone tasked with understanding the business problem, business opportunity, potential business solutions, implementation of a potential business solution, and measuring project, program or strategic initiative results. So really, Business Analysis is done at all levels and across all departments (strategic, tactical and operational) within a specific context. It gets messy when you seek to place traditional structures around Business Analysis through titles and positions. Unfortunately, a lot of organizations have no choice but to put Business Analysis or at least the

Business Analyst in a box.

Some time ago I was hired as a Program Consultant by a Director of Enterprise Services and the CIO of a large resource company to get ITSM on the strategic agenda of the organization. It meant as a Program Consultant I had to put on a senior Business Analysis hat and get three distinct organizations (utilities, gas, and oil) in two continents to agree ITSM was a good investment for everyone. This was a pure bottom-up initiative where Project Managers would not have been involved since the initiative was not yet approved and funded. The key stakeholders were middle and senior management. Therefore, there was nothing yet to implement. I truly love these kinds of initiatives. Discover if something is a good idea and then, maybe, we’ll bring in the Project Managers.

The program analysis required me to use the soft and hard skills of Business Analysis to determine if service management was a good idea. That meant an assessment and one-on-one interviews with key people to discover their challenges, get their thinking on potential solutions and what the benefits would be before even mentioning the potential solution domain, ITSM. It took 4 to 6 weeks to do.

I reported back to my Sponsor and CIO with a discussion and recommendation we engage key stakeholders from each organization to discuss their maturity levels, what they would like to achieve, the benefits and a develop a set of 6 key recommendations for the executive team. My sponsor approved the next phase of the initiative to work towards building consensus among the management team and the best course of action.

To make a long story short 6 to 8 months later, we got the initiative to the business case stage and presented a business case to the executives and board of directors for approval. From a business standpoint, it made sense to proceed with the initiatives since there was a huge opportunity to standardize and share support services across three distinct organizations. Upon approval, Project Management kicked in. The Project Managers prepared their plans for execution while intermediate to junior Business Analysts joined the team to further flesh out the detailed requirements. In this case, senior Business Analysts started the process, and other Business Analysts completed the process downstream.

In this scenario, for the initiative to get ITSM on the agenda of the organization, I was called a Program Lead and Consultant. The title relevancy allowed me to be categorized within an organization so I could carry out my sponsor’s mandate. From a role and responsibility skill set, I used Project Management and Business Analysis expertise needed to get the job done. For the phase one initiative, we had a project charter and Business Analysis charter blended. This set the boundaries for the evaluation work to be done.

We developed a requirements management plan and a communication plan to ensure we had a path to follow and a means to communicate what we were doing. There was a summary of findings and status meetings, financial evaluations, business case development, and not to mention the one-on-one meetings, interviews, and group facilitations sessions. If you love Business Analysis and Project Management blending at the senior levels, this was a consultant’s dream, a real enterprise initiative working at the senior management and executive levels.

Over the course of my career, I have been a senior consultant and senior Project Manager running small and large scale projects for organizations. The interesting thing is that I have always had to use the Business Analysis skill set in Project Management. I have also been a Business Analyst. In my junior years, I did small Project Management work to get things done.

The big change I have seen is really the change in titles. For me, Project Management has been reasonably stable since the mid 90’s. Business Analysis, on the other hand, has not. I recall a time when I was called a CSR (client service representative). I came to work one day, and I was told my title had been changed to Business Systems Analyst and Coordinator. My job didn’t change at all nor did my pay. Eventually, someone asked me what I did. I told them, and they said, “Oh you’re a Business Analyst.”

Business Analysis is all over an organization. It is not the rightful domain of any one department, group or individual. It is a role, a skill set, and crossing over boundaries to better understand the business need and to come up with creative strategic business solutions to challenging situations. This is a significant difference when it comes to Project Management work of getting it done. Organizations will find Business Analysis being used on agile teams, with process and systems analysts, product managers and owners, Project Managers, requirement managers and a whole host of other places.

I do believe in the importance of advancements in creativity and strategic Business Analysis thinking and abilities. Business intelligent and artificial intelligent will strip away the fibers of traditional thinking, titling and wage structures. Pure talented Business Analysts will rise to the top of a number of organizations where building business brainpower is rewarded. The professional who is willing to master the application of the Business Analysis skill set will rule the future business kingdom while everyone one else will still asking, what just happened. The Business Analyst will already know the answer.

Final Thought – It is not often I write this kind of article, walking the fine divide and complexities of the Business Analyst versus Project Manager’s work. When you are locked in a room with 47 people, and they are all asking the question regarding the difference between a Project Manager and a Business Analyst. What are you supposed to say? Really it comes down to the size of the organization and the many hats you wear. Maybe, the Project Manager asks, is it done yet, and the Business Analyst asks, what solution options are available. The reality is both title professions use the Business Analysis skill-set. You just need to choose which side fits you more naturally.

I suggest you dig deeper and look at the skill set you need to develop for success in your business, career, and life and you will see there is a bit of Business Analysis in all of us. Good Luck.

Remember; do your best, invest in the success of others, make your journey count, Richard.