Problem Solving

[av_section min_height=” min_height_px=’500px’ padding=’default’ shadow=’no-shadow’ bottom_border=’no-border-styling’ bottom_border_diagonal_color=’#333333′ bottom_border_diagonal_direction=’scroll’ bottom_border_style=’scroll’ scroll_down=” id=” color=’main_color’ custom_bg=” src=” attach=’scroll’ position=’top left’ repeat=’no-repeat’ video=” video_ratio=’16:9′ video_mobile_disabled=” overlay_enable=” overlay_opacity=’0.5′ overlay_color=” overlay_pattern=” overlay_custom_pattern=” av-desktop-hide=” av-medium-hide=” av-small-hide=” av-mini-hide=” av_element_hidden_in_editor=’0′ av_uid=’av-3divr8′] [av_heading tag=’h1′ padding=’20’ heading=’Problem Solving’ color=” style=’blockquote modern-quote modern-centered’ custom_font=” size=” subheading_active=’subheading_below’ subheading_size=’15’ custom_class=” admin_preview_bg=” av-desktop-hide=” av-medium-hide=” av-small-hide=” av-mini-hide=” av-medium-font-size-title=” av-small-font-size-title=” av-mini-font-size-title=” av-medium-font-size=” av-small-font-size=” av-mini-font-size=” av_uid=’av-3a6gvo’] Defining a problem and generating ideas to solve them.
[/av_heading] [av_one_fifth first min_height=” vertical_alignment=” space=” custom_margin=” margin=’0px’ padding=’0px’ border=” border_color=” radius=’0px’ background_color=” src=” background_position=’top left’ background_repeat=’no-repeat’ animation=” mobile_breaking=” mobile_display=” av_uid=’av-33jsac’] [/av_one_fifth][av_three_fifth min_height=” vertical_alignment=” space=” custom_margin=” margin=’0px’ padding=’0px’ border=” border_color=” radius=’0px’ background_color=” src=” background_position=’top left’ background_repeat=’no-repeat’ animation=” mobile_breaking=” mobile_display=” av_uid=’av-2vxy9g’] [av_textblock textblock_styling_align=” textblock_styling=” textblock_styling_gap=” textblock_styling_mobile=” size=” av-medium-font-size=” av-small-font-size=” av-mini-font-size=” font_color=” color=” id=” custom_class=” template_class=” av_uid=’av-2pr6z0′ sc_version=’1.0′ admin_preview_bg=”]

Tools versus experience

A common concern for business analysts is a lack of experience, especially in the application of tools, i.e. frameworks and modelling techniques and the software that supports them. There are so many things to know and learn, and it can be very overwhelming. It seems that there are so many techniques to apply these days and it is confusing to know where to start.

However, there is a tendency by the business analyst to over rely on having a swag of tools and techniques to provide confidence. It is like if you are good at the tools then you are a good business analyst, but this is not true. Tools are only as good as the problem that is being solved. Of course, tools and techniques are important, but they are not the place to start.

The real value in business analysis is understanding the problem. You gain true experience in engaging with stakeholders, understanding their issues and aligning with their needs.

When the problem is properly understood, then the real difference can be made. You are able to narrow down and choose the right tool and use it to analyse and communicate the problem and articulate a possible solution. This way there is less overwhelm, and you can produce better results.

Problem solving

The business analysis process can be viewed as an exercise in solving a series of problems to produce beneficial outcomes for an organisation. Those problems may be related to:

  • issues occurring in the business (see ‘Example business problems’ below)
  • project methodology and personal skills
  • people and organisation (see ‘Common problems encountered by business analysts’ below).

Being a confident problem solver is fundamentally important for your success as a business analyst. Having a good process to use when approaching a problem helps you solve problems quickly and effectively. Without a process, your solutions may be ineffective, or you will get stuck which can produce painful consequences.

Here is a basic approach to solving a problem in four steps:

  1. Define the problem.
  2. Generate ideas to solve the problem.
  3. Evaluate and select alternatives.
  4. Implement solutions.

There are other more complex approaches such as Simplex, Appreciative Inquiry and Soft Systems Methodology.

You will find on closer examination that you may already use a combination any of the above-mentioned techniques. Problem solving is something we do in every aspect of our daily lives and therefore it occurs largely as an unconscious activity, i.e. something we do so often we don’t have to think about it.

Possibly without knowing it, your unconscious mind is constantly used as an engine for problem solving. But you can use your unconscious mind to solve problems in a deliberate fashion. This is the process of listening and a readiness to record ideas as they percolate into your conscious mind. To do this requires the ability to relax and allow ideas and solutions to flow into your mind. One common technique is to saturate yourself in understanding the problem, ask yourself the question as to how to solve the problem, and then take a break or ‘sleep on it’.

You would have heard of this before, however conscious utilisation of this form of problem solving will greatly benefit your business analysis work. It can produce some very creative ideas that are very satisfying to include in the evaluation and selection of alternatives. The important thing is not to try too hard. Go with the flow. Incubate.

Defining the problem

Problem solving does not have to be an elaborate and difficult process.

Firstly, you need to understand what the problem is. Half the battle is won when you can identify the true source of the problem, as ideas to solve the problem may then be readily available.

It is not enough to only treat the symptoms of the problem, as this will not solve the underlying issue and symptoms will keep occurring. Just treating the symptoms will eventually come at significant cost for an organisation.

Here are some useful tools to help you work through the layers of a problem to uncover what’s really going on:

  • Five Whys. The ‘Five Whys’ technique is simply the process of asking “why” enough times that you eventually get to the root cause of a problem. It is about getting to the root of a problem quickly. It is an effective way to solving problems that can be used by any business analyst to improve a business process or write better requirements. Learn more here.
  • Root Cause Analysis. Root Cause Analysis is another common technique and assumes that systems and events are interrelated. An action in one area triggers an action in another, and another, and so on. By tracing back these actions, you can discover where the problem started and how it grew into the symptom you are now facing. There are three basic causes of problems: physical, human and organisational.
  • Mind Mapping. This visual technique is used to outline information around a central word or phrase. This central concept may form the known issue that may be causing the problem. Learn more here.
  • Fishbone Analysis. Like Mind Mapping, Fishbone Analysis is a visual technique for exploring a central problem or concept. This tool is also called the Ishikawa Diagram as it was first used by Doctor Kaoru Ishikawa of the University of Tokyo in 1943. Learn more here.
  • CATWOE. CATWOE can be used as a stand-alone tool or can be combined with one of the above techniques to ensure that the identified problem has been given full consideration, i.e. you don’t have a problem statement that is really a solution instead. CATWOE allows you to look at the issue from a variety of perspectives: customers, actors, transformation process, world view, owner and environmental constraints.

These techniques can be used in a group setting or as a personal tool for uncovering possible causes that can be later examined in a group setting.

When working with stakeholder groups you can simply use one or a combination of the above-mentioned tools and a brainstorming approach to uncover the root causes of a problem. In this case, you would start with the perceived ideas about what the problem is and use a problem identification technique to arrive at a true problem statement.

Problem identification can also be combined with other elicitation activities, e.g.

  • Business process mapping workshops. In this case, the business analyst is defining and documenting the current state of how the organisation operates. In these workshops, the business analyst captures the activities performed by various functions in the organisation, pre-defined roles, information used and created (e.g. reports), systems used, location and temporal information, and other inputs and outputs. Often through the process mapping issues are raised by stakeholders and a quick ‘Five Whys’ analysis can uncover root causes that can be later examined in a separate session.
  • Business process analysis and blue skies workshops. In these workshops, the focus is on uncovering ideas that will affect change on a business process or system that supports a business process. Without the exclusion of other approaches, there are two good ways of doing this.

The first approach occurs when you are examining the ‘as-is’ business process in a step-by-step fashion for improvements (business process analysis). A short and powerful questioning technique is described here, but through the analysis of processes you may encounter issues that required clarification. Again, the ‘Five Whys’ method is a good approach as it is more conversational than other problem identification techniques and therefore it does not break from the flow of the process analysis workshop.

The other approach is to disregard close examination of ‘as-is’ business process maps (blue skies workshops). This option depends on what you plan to achieve in your business analysis process, but it is very useful in situations where the stakeholders are more senior in the organisation or have no patience or desire to pay close scrutiny to business processes. Here you would develop a questioning technique that points at a process or function in the business but allows a free style generation of issues and ideas to overcome the issues. In this situation Lean Six Sigma principles can be used as the basis for questioning (using the acronym: DOWNTIME) to give the session structure, identify process improvements without looking at a map, and allow a free thinking and brainstorming approach to ideas generation. Again, the ‘Five Whys’ method is a good way to test the identification of a problem without breaking the flow of the workshop.

Generating ideas to solve the problem.

One way to generate ideas to solve problems has been described above, i.e. through blue skies workshops. Other methods mostly involve creative techniques such as brainstorming. There are different ways to structure brainstorming sessions, but it is important to note that:

  • Good stakeholder analysis will inform who you include in which session so that you can optimise for best ideas generation and different points of view.
  • You must have a planned approach which includes pre-planned questions and an agenda.
  • You must set the scene so that participants know what their role is and what they will be doing in the session (no surprises).
  • You facilitate rather than dictate the solutions.

It is important to note that participants know their own business and usually have an idea of what could be a good solution to a problem. If they don’t, then instead of telling the answer it is better to ask questions to trigger ideas. If they are supported in arriving at the answers, then they are more likely to invest ownership in the outcome of the project. Good questioning and conversation flow will support participants in producing good ideas. Participants should be challenged and pushed beyond the obvious solutions – this is where the real thinking starts – to get the best possible results from the brainstorming session.

Evaluating and selecting alternatives

The evaluation and selection of options to resolve a problem is part of these BABOK Knowledge Areas:

  • Requirements Analysis and Design
  • Solution Evaluation.

The work performed by the business analyst may culminate in the following deliverables:

  • Business requirements specification (see example template). This deliverable encapsulates the analysis of elicited, validated and prioritised requirements.
  • Business case (see example template). This deliverable summarises solution options and recommendations.

It is important to note that the templates provided above are more suited to Waterfall methodology or a ‘big requirements upfront’ approach to requirements documentation. At the very least they can be adapted or provided as a guideline for the type of information required in analysing requirements and making a recommendation. More about standard business analysis deliverables can be found here.

Implementing solutions

The implementation of solutions depends on the pathway described in the options analysis and recommendation (business case). This depends on the type of problem you are solving.

Properly identifying the business problem helps ensure you understand the project’s end game. You may be faced with documenting business processes to enhance business efficiencies, developing or purchasing a software system to support a changing business environment, or developing some kind of architecture to support an organisation’s strategic process.

Therefore, the implementation of the solution is defined by problem being solved and can take a number of pathways. The pathway to take is therefore another problem to be solved and another challenge for the business analyst and the project team (we must not forget that project management has a big role to play).

After all, business analysis is a series of problem-solving activities that delivered the best outcomes for an organisation.

Example problems

Common business problems solved by business analysts

There are many business problems that you will solve over the course of your career and many will have a similar pattern. The list below describes some common examples of problems, their possible causes and some skills and techniques that would be utilised by the business analyst to deliver satisfactory outcomes for the organisation.

Example problem Possible causes Skills / techniques for further research
The organisation is not meeting the strategic objectives that supports their mission. Initiatives are poorly aligned with business objectives and overall vision.

Initiatives are poorly coordinated across business functions.

Siloed implementation of projects.

Governance processes are not well defined and enforced.

Poorly developed understanding of roles and responsibilities in relation to strategic initiatives.

Untimely retrieval of information for strategic decision making due to poor data quality and manual collation of reports.

No or little understanding of benefits realised from previous strategic initiatives.

Stakeholder analysis (see template).

Communication and influencing with senior leadership, governance, strategic planning and information management stakeholders.

Strategy analysis.

Elicitation techniques (meeting/workshop facilitation, interviews, desktop analysis, brainstorming).

Asking the right questions for clarification of issues, requirements and ideas for resolution.

Requirements analysis.

Strategy documentation.

Domain modelling, process mapping, information architecture.

Business requirements documentation.

Business case documentation.

Solutions options and recommendations.

Benchmarking.

Service delivery is not meeting targets causing poor customer experience.

High level of product returns due to errors made on sales orders.

Lack of coordination in the delivery or services and products due to poor alignment with, or awareness of, the organisation’s mission.

Poor or non-existent strategic coordination (and governance) in service delivery causing unclear definition or roles and responsibilities and little or no enforcement of contracts and service levels.

Untimely retrieval of information creating poor responsiveness to customer / product enquiries.

Poor responsiveness in customer service / product delivery due to manual, duplicated or out of date processes.

Poor responsiveness in customer service / product delivery due to lack of supporting functionality.

Poor responsiveness in customer service due to lack of understanding of customer needs.

Poor service delivery due to staff capacity and training issues.

Degraded product quality due to intensive manual processing creating a high level of errors.

Degraded product quality due to poor quality product information or untimely retrieval of customer feedback.

Stakeholder analysis (see template).

Communication and influencing.

Elicitation techniques (meeting/workshop facilitation, interviews, desktop analysis, interface analysis, brainstorming, customer and stakeholder surveys).

Asking the right questions for clarification of issues, requirements and ideas for resolution.

Requirements analysis.

Domain modelling, process mapping, value stream mapping, customer journey mapping, information architecture, lean methodologies, data analysis, process re-engineering.

Requirements documentation (high level envisioning, process overview, capability overview, systems context models, roles and responsibilities, epics, user stories, use cases, wireframes, data/information flows, glossaries, data dictionaries, state modelling, architectural design principles, non-functional requirements).

Business case documentation.

Solutions options and recommendations.

Vendor assessment.

Prototyping.

Requirements management.

Benchmarking.

Organisational workers are experiencing increasing operational demands which creates time pressures and bottlenecks in service delivery. Policy / legislation changes, changes in government, changes in business strategy, or changes in business practices.

Myriad of duplicated business processes and applications.

Intensive manual processing due to lack of supporting systems or out of date processes and functionality.

Double data entry and manual maintenance of data in spread sheets or personal databases.

Lack of consistency in processes and systems across business functions.

Inadequate training of staff and/or lack of capacity for staff to support areas of the business experiencing bottlenecks.

Untimely retrieval of information for operational decision making due to poor data quality and manual collation of reports.

Untimely retrieval of information that would ensure the best performance of staff during peak periods.

Operational performance management processes are not well defined and enforced.

Stakeholder analysis (see template).

Communication and influencing.

Elicitation techniques (meeting/workshop facilitation, interviews, desktop analysis, brainstorming, surveys).

Strategy analysis.

Operational performance analysis.

Asking the right questions for clarification of issues, requirements and ideas for resolution.

Requirements analysis.

Domain modelling, process mapping, value stream mapping, information architecture, lean methodologies, data analysis, process re-engineering.

Requirements documentation (high level envisioning, process overview, capability overview, systems context models, roles and responsibilities, epics, user stories, use cases, wireframes, data/information flows, glossaries, data dictionaries, state modelling, architectural design principles, non-functional requirements).

Business case documentation.

Solutions options and recommendations.

Vendor assessment.

Prototyping.

Requirements management.

Functionality does not support business processes causing delays and errors in service delivery and increased operational costs. Lack of support in the business strategy for the ongoing development and maintenance of systems.

Poorly developed functionality due to inadequate definition of business and functional requirements.

Out of date functionality caused by a constantly evolving business climate.

Out of date infrastructure affecting overall performance of applications used by the business.

Little or no application support due to proprietary or redundant software.

Inadequate allocation of resources for definition and implementation of new functionality.

Untimely or no retrieval of information about the impact of organisational changes on systems and processes.

Stakeholder analysis (see template).

Communication and influencing.

Strategy analysis.

Elicitation techniques (meeting/workshop facilitation, interviews, desktop analysis, interface analysis, brainstorming).

Asking the right questions for clarification of issues, requirements and ideas for resolution.

Requirements analysis.

Domain modelling, process mapping.

Requirements documentation (high level envisioning, process overview, capability overview, systems context models, roles and responsibilities, epics, user stories, use cases, wireframes, data/information flows, glossaries, data dictionaries, architectural design principles, non-functional requirements).

Business case documentation.

Solutions options and recommendations.

Prototyping.

Requirements management.

Limited or untimely access to quality information causes delays in strategic and operational decision-making.

Corporate information is not fully utilised.

Lack of integrated information due to fragmented and incomplete data sources (or data stored on various devices).

Structured and unstructured data stored on various devices making search and retrieval very difficult.

No metadata attached to information making search and retrieval difficult.

Disparate methods of coding the same types of datasets in disparate repositories.

Difficult in managing information and content without significant technical input and/or skills.

The production of reports is time consuming and highly manual.

Difficulty in managing information accuracy, ownership, versioning, duplication, currency or orphaned content causing bad information and bad decisions.

Governance for the management of data is not well defined i.e. poorly defined roles and responsibilities and data quality management policies.

Lack of supporting systems to store and/or federate data for the purpose of timely retrieval for decision-making.

Stakeholder analysis (see template).

Communication and influencing.

Elicitation techniques (meeting/workshop facilitation, interviews, desktop analysis, interface analysis, brainstorming, surveys).

Asking the right questions for clarification of issues, requirements and ideas for resolution.

Requirements analysis.

Domain modelling, process mapping, information architecture, data modelling, data schema modelling, process re-engineering.

Requirements documentation (high level envisioning, process overview, capability overview, systems context models, roles and responsibilities, epics, user stories, use cases, wireframes, data/information flows, glossaries, data dictionaries, state modelling, architectural design principles, non-functional requirements).

Business case documentation.

Solutions options and recommendations.

Vendor assessment.

Prototyping.

Requirements management.

Supporting technological infrastructure unable able to support operational demands causing breakdowns and delays in business operations and increased costs. Not a lot known about all systems making the strategic coordination of maintenance difficult.

Multiple applications are supported on multiple systems creating unnecessary maintenance overheads by supporting duplicate systems.

Requirements for supporting infrastructure for new business initiatives is poorly developed.

Infrastructure is unable to support new or upgraded technologies.

Maintenance contracts have expired, or vendor support is withdrawn for deprecated or ‘sunsetted’ systems and services.

Support for applications and infrastructure is out of date creating a security risk for corporate information and physical assets.

Stakeholder analysis (see template).

Communication and influencing.

Strategy analysis.

Elicitation techniques (meeting/workshop facilitation, interviews, desktop analysis, interface analysis, brainstorming).

Asking the right questions for clarification of issues, requirements and ideas for resolution.

Requirements analysis.

Requirements documentation (high level envisioning, process overview, capability overview, systems context models, component models, roles and responsibilities, use cases, architectural design principles, non-functional requirements).

Business case documentation.

Solutions options and recommendations.

Requirements management.

Common problems encountered by business analysts

Aside from the problems that business analysts solve as part of their work, there are other problems that they encounter in their work that are due mainly to people and organisational issues. The table below shows a list of common problems face by business analysts, possible mitigation activities to reduce or resolve the occurrence of the problem, and possible skills and techniques used as part of the mitigation strategy.

Example problem Possible mitigation / resolution activities Skills / techniques for further research
Lack of ownership by stakeholders Ensure senior leadership involvement in communicating to stakeholders about the purpose and benefits of the project and expectations.

Escalate according to the project’s lines of communication, e.g. to project manager or project board.

Stakeholder analysis (see template).

Communication and influencing.

Conflicting views and opinions from stakeholders Ensure all stakeholders can express their points of view.

Promote collaborative resolution of conflicting viewpoints in one-on-one and group settings.

Stakeholder analysis (see template).

Meeting/workshop facilitation.

Brainstorming and focus groups.

Communication and influencing.

Asking the right questions for clarification of requirements.

Requirements validation and prioritisation.

Lack of access to subject matter experts Ensure senior leadership involvement in communicating to stakeholders about the purpose and benefits of the project and expectations.

Identify underlying reason for SME unavailability and then escalate the issue according to the project’s lines of communication.

Stakeholder analysis (see template).

Communication and influencing.

Lack of big picture vision by users and stakeholders Ensure senior leadership involvement in communicating to stakeholders about the purpose and benefits of the project.

Promote big picture thinking by clearly describing the benefits of the project and how these benefits will directly and positively impact stakeholders.

Promote big picture thinking and ownership by encouraging stakeholders to participate in ideas generation activities.

Stakeholder analysis (see template).

Meeting/workshop facilitation.

Brainstorming and focus groups.

Communication and influencing.

Asking the right questions for clarification of benefits.

Hidden or unknown stakeholders Ensure leadership involvement in identifying areas of the organisation that need to be involved in the project.

Identify all process/functional areas impacted by the project and cross reference those areas to stakeholders.

Stakeholder analysis (see template).

Domain modelling or capability modelling to define the scope and boundaries of the problem domain.

Gap analysis of process/functional areas to stakeholders.

Resistance to change from end users Ensure senior leadership involvement in communicating to stakeholders about the purpose and benefits of the project.

To consolidate ownership and buy in to the process, ensure stakeholders participate in requirements definition and validation activities, and ideas generation sessions for solutions to identified problems.

Ensure all concerns are heard in one-on-one and group settings.

To further consolidate that their voice was heard, ensure that issues and requirements are clearly expressed back to the stakeholders in business natural language.

Stakeholder analysis (see template).

Meeting/workshop facilitation.

Brainstorming and focus groups.

Asking the right questions for clarification of issues, requirements and ideas.

Requirements validation and prioritisation.

Glossary of terms and colloquialisms used within the organisation.

Unrealistic timeframes Ensure clear and upfront communication with project leaders about what is required in the business analysis process.

Write down what is required and ensure that the relevant parties review the plan and provides input.

Communication and influencing.

Business analysis approach planning (see template).

Unrealistic user expectations of a solution’s capability Ensure senior leadership involvement in communicating to stakeholders about the objectives the project

Ensure the scope and boundaries of the problem to be solved is well defined and communicated with stakeholders.

Manage expectations through clear and upfront communications via meetings and documentation.

Escalate issues according to the project’s lines of communication, e.g. to project manager or project board.

Communication and influencing.

Meeting/workshop facilitation.

Asking the right questions for clarification of issues, requirements and ideas.

Poorly defined business needs and objectives Ensure elicitation activities include full coverage of the problem domain and that all stakeholders are identified and have provided input.

Ensure requirements are validated and prioritised via stakeholder input.

Ensure adequate time is given to elicitation activities.

Communication and influencing.

Desktop analysis.

Meeting/workshop facilitation.

Asking the right questions for clarification of issues, business drivers and requirements.

Requirements validation and prioritisation.

Business analysis approach planning (see template).

Information siloes across departments Identify gaps and disparities are resolve them via elicitation activities and analysis of data.

Ensure elicitation activities include full coverage of the problem domain and that all stakeholders are identified and have provided input.

Ensure elicitation activities include questions about data/information used and created by the business.

Escalate potential impacts according to the project’s lines of communication, e.g. to project manager or project board.

Stakeholder analysis (see template).

Communication and influencing.

Desktop analysis.

Meeting/workshop facilitation.

Asking the right questions for clarification of data and information.

Glossary, data dictionary.

No planning (or over planning) in the business analysis process Ensure clear and upfront communication with project leaders about what is required in the business analysis process.

Write down all activities is required and ensure that the relevant parties review the plan for common understanding of the business analysis approach.

Escalate issues according to the project’s lines of communication, e.g. to project manager or project board.

Communication and influencing.

Business analysis approach planning (see template).

Under estimation of scope, funding and necessary resources Ensure clear and upfront communication with project leaders about any impacts on the project timelines as a result of requirements analysis.

Escalate issues according to the project’s lines of communication, e.g. to project manager or project board.

Communication and influencing.

Requirements analysis.

Solutions options analysis and recommendation.

Lack of expertise on the project team Escalate issues according to the project’s lines of communication, e.g. to project manager or project board. Stakeholder analysis (see template).

Communication and influencing.

IT (not business) driven solutions Ensure clear and upfront communication with project leaders about the potential impacts to the organisation of an IT driven initiative.

Escalate issues according to the project’s lines of communication, e.g. to project manager or project board.

Stakeholder analysis (see template).

Communication and influencing.

Scope creep and/or shifting requirements Ensure clear and upfront communication with project leaders about any impacts on the project timelines as a result of changes in requirements.

Manage stakeholder expectations of the scope and boundaries of the problem being solved, and current limitations in time, resources and funding.

Involve project leaders (e.g. project manager, scrum master, sponsor) in discussions with stakeholders about expectations.

Involve stakeholders in the validation and prioritisation of requirements.

Escalate issues according to the project’s lines of communication, e.g. to project manager or project board.

Stakeholder analysis (see template).

Communication and influencing.

Meeting/workshop facilitation.

Asking the right questions for clarification of issues and requirements.

Requirements validation and prioritisation.

Not asking the right questions Ensure that problem domain and the expected outcomes and deliverables of the project are well understood.

Against the expected outcomes and deliverables plan out the information and artefacts needed to deliver the required results.

Plan all elicitation activities to include the questions that will provide all data needed to deliver outcomes for the business analysis process.

Stakeholder analysis (see template).

Business analysis approach planning (see template).

Communication and influencing.

Requirements elicitation.

Asking the right questions for clarification of issues, requirements and ideas.

Requirements validation and prioritisation.

Poor communications between analysts and developers Develop rapport with relevant stakeholders.

Escalate issues according to the project’s lines of communication, e.g. to project manager or project board.

Stakeholder analysis (see template).

Communication and influencing.

Requirements analysis.

Asking the right questions for clarification of business requirements and technical requirements.

Exercises

Using your worksheet.

If possible, describe a business problem that you have identified and solved in the past. If you cannot describe a work-related business problem, then choose another problem that has occurred in your life, e.g. anything associated with club/social events, moving to a new house, changing career, travel or other. What was initial perceived problem (problem description)? What were the root causes of the problem? What approach did you take to identify and solve the problem (approach taken)? What tools and techniques did you use? What was the final outcome?

In consideration of the problem you described above, how could you have improved on the problem identification and resolution process? Is there anything you could have done better? What problem identification techniques could you incorporate in future work?

This exercise not only helps you reflect on problem solving in general but can be used in job interviews and conversations around problem solving.

If you are keen, add another row to the table above and repeat the exercise. The more you can spell out how you have solved problems and where you can improve, the more articulate you will be in describing this very important skill.

[/av_textblock] [/av_three_fifth][av_one_fifth min_height=” vertical_alignment=” space=” custom_margin=” margin=’0px’ padding=’0px’ border=” border_color=” radius=’0px’ background_color=” src=” background_position=’top left’ background_repeat=’no-repeat’ animation=” mobile_breaking=” mobile_display=” av_uid=’av-2kaxdw’] [/av_one_fifth] [/av_section]
Item added to cart.
0 items - $0.00

Sign up for latest news. Grab the latest deals, guides, tips and tricks directly from Sam Cordes and be seen as a professional who delivers value and succeeds.