Evaluating the Facts and Data

Getting the information, data, and facts pertaining to a problem is of critical importance if Business Analysts are going to solve any problems.

It is of crucial importance to analyze the facts and data before choosing a course of action when seeking solutions to a problem. Informed problem-solving not only provides the guardrails that prevent the deployment of inadequate solutions but also prevents those solutions from worsening the problem.

This does not mean taking longer than is necessary to resolve an issue because the Business Analyst is still “researching” the problem; rather it relates to obtaining the key facts and seeking a speedy solution based on available information and data.

Working in Concert with the Project Team

This may seem counterintuitive given that we just stated that Business Analysts should be pumped up to personally resolve problems. The best Business Analysts don’t have to have all the answers to the problems in front of them, but what they are good at is knowing who has the answers or solutions they need.

They realize that project teams have a mix of team members with diverse sets of skillsets as well as experiences and that in crisis situations they can leverage those skillsets and experiences to beat back problems.

Creativity helps Business Analysts figure out the best resource or means to resolve a problem in the shortest time while also minimizing possible risks that are likely to arise from the solution.

Acting with Urgency

If a Business Analyst got word of a problem last month, why are they picking it up for resolution a month later?

This is hypothetical, but the wider point is that ace Business Analysts act with urgency when they are faced with a problem that stalls or is likely to stall project progress.

This is not to say Business Analysts should just dive in like headless chickens in seeking issue resolution; facts ought to be collected, and a course of action set in as short a time as can be reasonable.

And no, a 30-day lead time for acting is unacceptable.

Problem-Solving Keeps Projects on Track

A software development project in some ways (but not literally) can be compared to being in the trenches of a pitched battle with projectiles flying in all directions.

While some projects are well-organized and run smoothly, those tend to be the exceptions; most projects are going to be bedeviled by multifaceted problems of varying magnitudes.

Planning for eventualities does help, but it’s not a foolproof insurance policy against project gremlins. However, a project that enlists a creative and methodical problem-solver as a Business Analyst also acquires an insurance policy that will own and resolve those problems.

That insurance policy by way of a problem busting Business Analyst is the one that corrals the resources and brains necessary to remove the blockers and problems stalling project progress.

Improves the Knowledge Base

Solving problems provides Business Analysts with the expertise and knowledge they need to resolve similar problems should they arise in the future. Without problem-solving there is not much learning or new knowledge gained for either the project or the Business Analyst.

Fosters Transparency and Communication

Ever tried hiding a candle in the dark? Same analogy applies to diagnosing and attempting to resolve problems without openness or transparency. If a project component is troubled, the first course of action would be to inform the wider project team and depending on the severity inform stakeholders as well.

In other words, bring the problem out in the open where help can be sought and more brains can be brought to bear on the problem so as to get a quick resolution.

Suppressing information about problems can turn a minor spark into a major blaze with unpredictable outcomes later in the project cycle.

Needless to say, it’s also unprofessional not to flag problems as they arise.

Active Listening

This is a big one.

A Business Analyst who does not carefully listen is likely to either solve the wrong problem or solve nothing at all. Active listening is the first line of defense in the problem-solving process, and Business Analysts who underrate it are courting trouble.

Problem Identification

This is a difficult skill to master as it grows the more problems a Business Analysts solves, but at its heart, it refers to checking if there is clarity of thought that identifies the problem.

What strategies are in place for locking down the source of the problem or why is there a recurrence of the problem? Those types of questions are essential for identifying the “problem behind the problem” well before laying down strategies to resolve the problem.

Clarity of the problem is way more important than how to solve it or which tools to deploy toward problem resolution.

Downplaying Confirmation Bias

A Business Analyst who always uses a hammer to solve problems comes to view every problem as a nail. Confirmation bias refers to using data or selecting solutions that confirm one’s personal biases—in other words, it is the viewing of every problem as a nail when you have a hammer. The thinking is that if the data or solutions don’t conform to a Business Analyst’s worldview, then the data or solutions are not part of the problem-solving process.

Removing confirmation bias when evaluating data and solutions to problems gives Business Analysts the opportunity to consider a wide range of conclusions from the data as well as alternative solutions to problems .

Being Open-Minded

Closely following on confirmation bias is the tendency to be close-minded or narrow-minded. It’s a different take on confirmation bias.

Business Analysts who have solved a problem a certain way in the past are closed to new and better options to solve the same problem. Sometimes it is encouraged by the attitude; “that’s how we have always done it here.”

Creative problem-solving requires open and flexible minds as well minds that consider different perspectives.

Groupthink

Ever been in a room where the audience does not want to disagree with the boss out of deference, fear, intimidation, or conflict avoidance? It happens, and it also happens to be one of the worst ways to resolve problems.

The boss thinks they have the best idea, but without questioning or validating the idea, how else can anyone say with conviction that it is the best idea on the table?

Groupthink may reduce the likelihood of conflicts or ensure that there is forward motion, but it stunts the creative process and consideration of alternative solutions.

Keeps Project Actors on the Same Page

In the previous hypothetical scenario where the Business Analyst was indecisive, the Business Analyst might be aware of the technical limitation but does not convey the information to end users who are ultimately the customers of the project. Making decisions and communicating those decisions (whether good or bad) keeps end users, stakeholders, and project team members on the same page.

Keeps Projects in Motion

Making decisions and standing by them keeps projects in motion, while sitting on decisions creates inertia. When decisions are made, it has cascading effects on the components and actors of the project who are relying on this decision. Without this decision, there is inertia and slowed project motion.

Resolves Sticky Problems

This is an obvious one.

Problems, challenges, and blockers don’t disappear by themselves; that would be too easy. Someone, usually a Business Analyst, must make the hard decisions that expunges problems, challenges, and blockers. The alternative is also true; when Business Analysts don’t make the decisions that resolve problems, then those problems start to fester and become more difficult to resolve by the day.

Builds Trust and Credibility

When a Business Analyst reaches out to stakeholders and end users with a difficult decision they made, stakeholders can see that the Business Analyst is making an effort at resolving their pain points. It may have been the wrong decision and probably didn’t work either, but they will appreciate the effort. This action-oriented attitude builds trust and credibility with end users and stakeholders.

Builds and Maintains Relationships

Another obvious one and closely following on how Business Analysts build credibility is by making the hard calls. End users, stakeholders, and project team members will be well disposed to have a great relationship with a Business Analyst who is making the tough calls on their behalf. Likewise, they won’t be well disposed to a Business Analyst who does not treat their pain points urgently going by the glacial pace at which decisions are made and communicated.

Manage Analysis Paralysis

This is when overanalyzing and overthinking a problem eventually creates paralysis, and the problem does not get resolved. Analysis paralysis occurs when a Business Analyst tries to collate and analyze all the information or data regarding an issue or problem. Of course, in the real world, Business Analysts cannot get and evaluate in a timely fashion all the information pertaining to a problem. What is required are the key facts, consensus, and flexibility as the solution is implemented.

Plug Key Information Gaps

This is the opposite of analysis paralysis, and it is where a decision is taken with scanty or incomplete information. As mentioned, it’s impossible to have all the required information, but it is also ideal to have the key pieces of information before pulling the trigger on a decision.

Focusing on the Trees Instead of the Forest

Focusing on small insignificant details or obsessing over the odds of a failure of a decision also contributes to situations where Business Analysts sit on decisions or are afraid of taking decisions. It takes the focus away from the long-term project objectives (the forest) and focuses on the trivial details (trees) of a situation.

Can a Business Analyst be 100% sure that the decision that has been made will be successful? Not unless they are into fortune-telling. Obsessing over minute details or the success odds of a decision is a waste of time. This time is better spent figuring out how to improve the odds of success or taking the actions that will ensure that the decision is successful.

Removing Emotions and Fear from the Decision

The emotions a Business Analyst carries into the decision-making process can either make or break the decisions. The fear that a decision will be a colossal failure can create indecisiveness just as the fear of “looking bad” will achieve the same result.

In order to make better and informed decisions with greater chances of success, Business Analysts need to do their best to remove negative emotions from this process. Positive emotions like overconfidence can be just as destructive to this process as it can lead to glossing over risks and potential pitfalls.

As human beings we want to be emotionally involved in the decisions we make, and this is acceptable. What is unacceptable is letting emotions drive the decision-making process for Business Analysts.

Managing the Sunk Cost Fallacy

Sunk costs refer to expenses that have been made that are irrecoverable regardless of the size of the investment. As humans we, for example, rationalize that we don’t want to give up on a business because we have already spent so much time, effort, and money on it. To economists what has already been spent is an irrecoverable sunk cost done in the past and should not determine decisions that the business owner needs to make today.

To make better decisions, Business Analysts need to be wary of the sunk cost’s fallacy. Business Analysts can compare how decisions were made in the past as well as outcomes, but past decisions regardless of their outcomes should not scuttle decisions that need to be made in the moment .

Project Lifespan Planning

This is not so much as forward planning that plans so many years into the future but more like a strategic roadmap that focuses on the overall lifespan of the project. Can all the requirements be delivered in the stipulated time frame? Can the project move through the entire Software Development Life Cycle in the 6 months that the Project Sponsors will fund? What happens if the project is incomplete in that 6-month period? These are the types of questions that a Business Analyst will strategically think about where the lifespan of a project is concerned.

Risk Assessment and Mitigation

Working in concert with Project Managers, Business Analysts review risks that are likely to derail or slow project delivery. More importantly they can work with end users, stakeholders, and project team members to mitigate those risks.

Closely allied to risk management is scenario building in concert with project leadership that reviews worst and best case scenarios and what that means for project delivery.

Aligning Project Goals with Organizational Goals

This refers to applying strategic thinking to end user requirements by challenging requirements, use cases, and assumptions that appear to defeat organizational goals and objectives.

Tactical Challenges and Their Impacts on Project Goals

Consider delays arising from changes to the scope by end users and stakeholders. Changes to scope may look like manageable impacts to a project, but more often than not, if not managed properly, they lead to costly project extensions. This is because the project is taking on more work than it initially committed to, and extending the project by even a few days has financial and resource implications.

A Business Analyst faced with problems like proposed scope changes or indecisive stakeholders relies on strategic thinking to evaluate what these tactical challenges mean for the longer-term objective of delivering a functional software product.

Evaluating Requirements for Future Environments

End users and stakeholders more often than not are more concerned with how a pain point they have today can be quickly resolved. When requests are made for new or improved software products, the focus of end users is not so much as what happens a year or two from now but how quickly a pain point is eliminated today.

Who can blame them? They are the frontline soldiers who have to deal with angry customers, declining sales revenue, and all the nastiness emanating from unpredictable market environments. Thinking about the future be damned!

In the current business environment, strategically thinking about the future in terms of the end user requirements requested today is a role that has largely been outsourced to Business Analysts and other project members like technical architects.

Upon receiving requirements, Business Analysts need to review if the ask is compatible with the long-term goals and objectives of the organization. End users who, for example, request software products based on current usage need to be asked about scalability. They need to be challenged about whether they have considered the fact that the product they requested cannot scale, and it certainly cannot handle the rapid business growth that the organization is targeting.

This is the essence of strategic visioning and thinking at the requirements scoping level.

Embrace Strategic Thinking As a Mindset

This refers to inculcating a mindset that considers the long term for any tactical actions that are undertaken during the project delivery process. Will the solution meet end user requirements a few years from now? How can end user adoption and ease of product use be incorporated in the delivered product so that end users will easily and quickly adopt the product now and in the future?

Growing this mindset is easier said than done, but with exposure to more project environments especially those that didn’t turn out so well, Business Analysts can grow this mindset. It also develops when it is nurtured as a habit and treated as an ongoing process during the project delivery process.

Using an Entrepreneurial Mindset

Entrepreneurs are in the business of creating solutions and efficiencies where none currently exist. Does a solution eliminate a complex problem while adding more value? Will the solution do it efficiently and save money and other resources? Are there cheaper and more efficient alternatives? There are many more questions that an entrepreneur can ask in the pursuit of efficient solutions.

The Business Analyst practice is no different, and the best Business Analysts in the business will be asking the same if not similar questions during the project delivery process.

Business Analysts who deploy this mindset are not only thinking like entrepreneurs, but they are also using strategic thinking to flag inefficiencies inherent in the project delivery process.

Unstructured and Undefined Requirements

Anyone who has held a Business Analyst position for even a day can relate to this situation. Requirements are unclear, and in many cases, they have more than one interpretation. End users and stakeholders think they know what they need until Business Analysts start asking questions, and from the answers, it becomes clear end users are not sure what they need. At other times the end users know what they need, they are just having a hard time articulating that need. This lack of articulation is not helped by shifting boundaries of what end users classify as a functional product. The laundry list of these situations is never ending, but this is precisely how ambiguity is created and manifested.

Lack of Documented Processes

Many organizations have business processes and workflows that are “documented” only in the minds of certain end users. There is scanty documentation that details how those processes work or how they are used. As long as the organization is meeting its objectives, this is largely acceptable until, that is, requirements need to be scoped. End users cannot agree on how workflows and processes actually work, why they work differently from how they were designed, and what triggered those changes. When Business Analysts start eliciting requirements, they find that requirements are open to many interpretations and impacts. What is obvious to end users is not so obvious to Business Analysts, so those unstated requirements become missed requirements. This lack of structure and process disorientation is the true definition of ambiguity.

Poor Communication and Information Gaps

An organizational culture that prizes the hoarding of information is certain to infect projects with ambiguity. With scanty information, some project actors’ resort to guessing or hypothesizing as a way of plugging the information gaps. This is akin to walking in the dark, and it is certain to worsen ambiguity.

Related to information gaps is poor communication modes where critical information is couched in techiy jargon or “corporate lingo” that masks the real meaning behind the communication.

Fear of Failure

How does an organization treat failure? Is it a hammer and tongs or a learn from the experience approach? Much like indecision, the fear of failure causes project actors including Business Analysts to be extra cautious during project delivery for they are not sure whether they are going be flamed or lionized whichever direction they take. One minute they are confident about a course of action, and the next minute they trash the plan as there are “indications” that project sponsors are unhappy with the plan even though they won’t say so explicitly. This second-guessing and “mind reading” breeds ambiguity.

Acceptance of Ambiguity

Most people live their lives with structure and habits that help them navigate the different demands and challenges they face. We are also taught from childhood that if we are going to be successful in life, we have to live structured lives. It therefore comes as a shocker to many Business Analysts when they realize that while software development projects have structures on paper, the reality is that many times project delivery is going to be an unstructured maze. They discover that there is a lot of ambiguity and gray areas in the project delivery process.

One key to the management of ambiguity is to grow a mindset that accepts ambiguity as part of the software product development process. These questions illustrate this point succinctly: Will Business Analysts have all the answers to the various challenges that arise during project delivery? Very unlikely. Will Business Analysts miss requirements? Definitely. Assuming that they somehow had all the answers they needed, is there a guarantee that the solutions deployed will be successful? Nope!

Accepting that ambiguity is a part of software project delivery is the first step toward managing and reducing ambiguity. Well, that attitude is defeatist you say; it isn’t, and I will accept that it’s defeatist when I start seeing projects delivered free of ambiguity.

Identify the Known Quantities

If the requirements scoping process is plagued by information black holes and gray areas, Business Analysts can plug them by identifying what they do know. Once they collate the available information, the next step of identifying the missing information while still challenging becomes more manageable. Sometimes it turns out that the unknown information has very little bearing on the proposed solutions and that the available information is enough to move forward with problem resolution. Coloring the part of the information black hole as a known quantity is effective in ambiguity reduction.

Quit the Waffling

As stated previously, fear and the absence of direction create ambiguity and even worse leads to indecision or waffling. This can be combated when Business Analysts boldly and directly communicate the course of action as well as being transparent about the ambiguity surrounding the decision. Put another way, by putting their plan out there to end users, stakeholders, and project team members, Business Analysts are inviting help that improves their ideas and fleshes out the ambiguity as well.

The best Business Analysts start by asking, “what is the worst that could happen?” and just run with the ball with the available information plus a dash of confidence. Ambiguity is not one to be beaten with indecision and a lack of confidence.

Effective Communication

Clearly communicating intention regardless of the communication channel used helps reduce ambiguity. Concise emails and presentations that use language tailored to the audience can reduce ambiguity where it exists. The use of technical jargon or unnecessarily complex grammar and vocabulary does little to reduce ambiguity; if anything, these actions are likely to intensify ambiguity. The use of nonverbal cues also helps Business Analysts gauge whether an audience is clear-eyed on what needs to be done or whether the presentation has created more confusion and ambiguity.

Process Flexibility

As they go about the project delivery process, Business Analysts can be sticklers for process, structure, and convention. In extreme cases, they trust the processes so much that they become hostages to these strictures. A good example is when Business Analysts want to always work through a structured requirements elicitation process as they scope requirements on software projects. But what happens when the end users cannot define their requirements and don’t know what the end product should look like or what it should do for them? Does this mean that the requirements elicitation process is dead at that point? Of course not; it just means that the Business Analyst has to embrace methods that can handle such vague and ambiguous situations.

This scenario is the true definition of ambiguity, and it cannot be resolved by Business Analysts who typically use a “one size fits all” approach for requirements elicitation.

The other aspect of flexibility refers to the ability to literally “turn on a dime” as and when new information becomes available depending on the challenge or problem that is being resolved. The reality is Business Analysts solve problems without all the important information which causes even more ambiguity about outcomes. The readiness to course-correct as conditions and circumstances change is one way to reduce ambiguity.

End User Collaboration

Requirements ambiguity causing nail-biters? Business Analysts can opt for the oldest trick in the book—engage with more end users to gain more insights and information. The more information and data that is collated and evaluated, the more likely that the Business Analysts will start to see previously unrecognized patterns and trends that provide structure to requirements. In general terms the more brain power that is enlisted to clarify vague concepts, the more likely it is that more facts and information useful to the requirements scoping process will be brought to light. Old school requirements scoping techniques like job shadowing are very effective in ambiguity reduction as they clarify vague concepts in real time.

Visualizing Information

Sometimes end users and stakeholders cannot accurately articulate what a software product or business process should do for them or what pain points it will resolve. In those instances, laying out current processes visually by using process maps, use cases, mock-ups, and prototypes clarifies end user needs and assumptions as well as exposing the risks inherent in both the current and proposed solutions.

Visualization goes a long way in reducing ambiguity especially around the requirements scoping process, and the best Business Analysts when faced with a lot of ambiguity use more of visualization than verbalization.

Using Agile or Scrum Software Development Methodology

Without doubt, the development of the Agile/Scrum methodology was targeted at the management of ambiguity on software development projects. By using an iterative process of software development for project delivery, the Agile methodology essentially accepts the fact that projects will be plagued by uncertainty and ambiguity. If end users and stakeholders keep coming up with new requirements, it’s probably because their processes are undefined or they are at the mercy of external push and pull factors that demand these changes.

End users and stakeholders without accurately defined or shifting requirements cause a lot of requirements ambiguity which is best managed by using an iterative software development methodology like Agile. If end users are unsure what a product should do, developing a prototype and showing it to them clarifies their needs and forms the basis for the next round of requirements scoping and actual product development.

By trusting the Agile methodology, Business Analysts can get a handle on the ambiguity hovering over the requirements scoping process and the wider project delivery process.

Understanding Interconnectedness and Dependencies

This refers to reviewing how different systems and processes are interconnected to each other before the process of change is undertaken.

An analytical Business Analyst will build mental models of system or process interconnectedness, and those mental validations will be manifested in the questions they ask end users during the requirements scoping process.

These sample mental scenarios are what Business Analysts use to understand how processes are interconnected or dependent upon each other.

Moving these validations from the mind of a Business Analyst to requirements scoping sessions is the next logical step, but for this to happen, the heavy lifting of analytical and critical thinking needs to have taken place first.

Assumption Testing and Validation

This is especially the case with implementing new software products when unverified assumptions can go unchallenged as the project moves toward the final stages of delivery.

The Business Analyst by playing devil’s advocate—it’s not that they don’t trust the assumption—is asking valid questions that can stave off future choke points simply because nobody bothered to do assumption testing.

Back to the product adoption scenario.

The Business Analyst checks the data for previous application adoption by the organization and discovers that it hovers in the 40%–50% range; there is no historical record of a 90% adoption rate. Analytical and critical thinking have blown the cover of this assumption so to speak.

This is a good thing (unless you are the project sponsor) for the Business Analyst can now work with the project team and project sponsors to ensure that they deliver the targeted 90% adoption rates.

Essentially the Business Analyst by going through this analytical process and validating the adoption assumptions has increased the odds of the adoption target being achieved. Validating this scenario would not be possible without the magical powers of assumption testing.

Requirements Validation

This is an obvious one as Business Analysts rely on analytical and critical thinking abilities to test the different scenarios resulting from end user requirements.

These may seem like pedestrian questions, but by verbalizing them, they have the unintended effect of exposing other scenarios and assumptions that need to be investigated in order to build a more coherent case for change. It’s more about the thinking process and its outcomes than about what is being asked for.

Also, as previously mentioned, it’s not that the Business Analyst does not trust end users or stakeholders; it’s in the interest of the Business Analyst to build a defendable watertight case for change, a case that at a minimum has validated key assumptions, scenarios, use cases, and facts.

Uncovers Hidden Use Cases

By thinking through a process as it was designed and how it works, Business Analysts can uncover hidden use cases and assumptions that may easily go under the radar during requirements discovery sessions.

A good example is when end users get so much trouble using a process that they repurpose it to work differently to achieve the same result. While they have “hacked” or “short-circuited” the process, the reality is that this cool trick does not exist in any manual and resides only in the minds of end users.

The Business Analyst seeking to change this process will need to analyze and consider the process as it was meant to work and how it has been repurposed and incorporate these scenarios in the requirements scoping process.

Analytical and critical thinking are some of the best tools that can be deployed to uncover hidden use cases, assumptions, and scenarios.

Improves Situational Interpretation

Giving an unfolding situation deep thought will equip a Business Analyst with the powers of perspective and analysis in order to accurately interpret what is happening.

That hostile or near-aggressive stakeholder or end user is probably just frustrated and just wants their problems gone; they have nothing against the Business Analyst. What is itching them is the glacial pace of change that makes their workdays miserable as hell.

Prevents Expensive Surprises

Is a Business Analyst procrastinating about a festering blocker, or are they thinking through the ways that blocker can be put to pasture?

We all know what happens to festering blockers if they are left unattended for even a short period of time; they get worse. It’s the same analogy with a Business Analyst who by omission or commission does not think through an issue especially around requirements that leads to expensive mistakes down the project cycle.

Motivates and Drives More Analysis

Uncovering likely pitfalls lurking about and pointing them out before they become major issues gets everyone on the same page and spurs even more critical analyses of other requirements that are being proposed.

Asking uncomfortable questions gets end users and stakeholders to think through the requirements and changes they are proposing to Business Analysts.

For Business Analysts critical thinking is a gateway to generating more ideas and concepts that can be used to improve requirements and triage difficult challenges.

Deploying Communication Skills

Critical and analytical thinking is triggered by information flowing to the Business Analyst, and these triggers are set off when a Business Analyst takes the time to actively listen to end users or stakeholders. Without engaging end users or stakeholders by asking questions and actively listening to them about proposed changes, critical and analytical thinking has no inputs to work with, and the critical abilities of the Business Analyst cannot be fully utilized.

This role-playing enables Business Analysts to view an issue or challenge from different perspectives which generates the ideas and concepts that are required to improve requirements and resolve challenges during project delivery.

Process Mapping

Using visualization tools like process maps to highlight how different business systems or applications work together gives Business Analysts the opportunity to lay out entire processes and expose even the most minute or hidden processes.

By simply reviewing a process map, a Business Analyst can critique an entire process in one view and thereby unearth hidden processes as well as validate use cases inherent in the process map.

Process mapping has the added benefit of bringing to light underlying or unstated assumptions that can distort the requirements scoping process if they are not brought out in the open early in the project cycle.

Staying Open-Minded

Analytical and critical thinking is improved by reviewing the information that is received as it is without bias or judgement. The times when requirements are being submitted by end users is a time to actively listen and ask probing questions. The time to decide when a requirement is superfluous or “nice to have” will come later when the facts, data, and use cases have been analyzed and critiqued on their merits.

Some may opine that this is a waste of everyone’s time by eliciting requirements that will not be worked on and that may be true to a point. What is more important is to figure out how end user requirements fit into the overall objectives of the project delivery process.

Self-awareness of the biases of a Business Analyst does improve the process of analytical and creative thinking. During the process of idea conception, Business Analysts have to be conscious whether they are merely copy-pasting another idea or if they are being too confident in a solution. They also need to be conscious of being plagued by the “sunken costs fallacy” (see section on Decision-Making) that focuses on past irrecoverable sunk costs instead of analytically assessing the present situation on its merits.

Collaboration

Analytical and critical thinking abilities are best harnessed by working in concert with other team members and using them as sounding boards for the ideas and concepts that a Business Analyst has developed. By having their ideas critiqued before they are circulated to other project actors, Business Analysts get the opportunity to think through their ideas and further refine them. The refining of ideas and concepts cannot take place when Business Analysts are unwilling to place those ideas under the microscope that is analytical examination. It’s one of the best ways for Business Analysts to grow better ideas and concepts.

Critical and analytical thinking skills are important skills that a Business Analyst uses to cut through the unstructured maze that the project environment can sometimes resemble. With creativity, critical thinking, and analytical skills, Business Analysts can make decisions and judgment calls that have wide-reaching impacts on different project components as well as overall project delivery.

For now though we consider a couple of unconventional non-technical skills that are just as critical as the conventional non-technical skills that have just been reviewed by this chapter and the preceding chapters.