Problem
Projects lose direction when the business need is unclear.
Action
Identify the business need before discussing possible solutions.
Outcome
Analysis stays focused on business value.
Chapter: Scope: What Is Business Analysis? - Business analysis
Problem
Weak business analysis reduces project success.
Action
Develop the knowledge, skills, and responsibilities expected of a business analyst.
Outcome
Your analysis creates greater value for the organization.
Chapter: Scope: What Is Business Analysis? - Business analysis profession
Problem
Assumptions and bias lead to poor decisions.
Action
Question information and base conclusions on verified evidence.
Outcome
Your recommendations become more reliable.
Chapter: Scope: What Is Business Analysis? - Business analyst mindset
Problem
Solutions fail when they address the wrong problem.
Action
Understand the underlying business problem before defining requirements.
Outcome
Requirements solve the right business need.
Chapter: Drivers: Why Are Requirements Required? - Business problems and needs
Problem
Change is difficult to plan without a clear target.
Action
Describe both the current state and the desired future state.
Outcome
The required changes become easier to identify.
Chapter: Drivers: Why Are Requirements Required? - Current state and future state
Problem
Some changes consume more value than they create.
Action
Evaluate whether the expected benefits justify the change.
Outcome
Resources are invested in worthwhile improvements.
Chapter: Drivers: Why Are Requirements Required? - To change or not to change
Problem
Business goals become unclear when requirements focus on solutions.
Action
Document the business outcomes that the solution must achieve.
Outcome
Requirements provide clear direction for solution decisions.
Chapter: Drivers: Why Are Requirements Required? - What are business requirements?
Problem
Requirements become incomplete without understanding their environment.
Action
Analyze the business context before defining requirements.
Outcome
Requirements fit the real business situation.
Chapter: Context: Who and What Is Involved? - Setting the context
Problem
Hidden constraints create delays and unrealistic plans.
Action
Document the limitations that affect possible solutions.
Outcome
Planning becomes more realistic.
Chapter: Context: Who and What Is Involved? - Recognizing constraints
Problem
Recommendations fail when they ignore how the organization works.
Action
Understand the organization’s structure, governance, and way of working.
Outcome
Analysis fits the organizational environment.
Chapter: Context: Who and What Is Involved? - Business analyst in organizational context
Problem
Missing stakeholders lead to incomplete requirements.
Action
Identify everyone who influences or is affected by the change.
Outcome
Requirements reflect the full business perspective.
Chapter: Context: Who and What Is Involved? - Stakeholders of change
Problem
Conflicting stakeholder interests complicate decision-making.
Action
Analyze how stakeholders influence and depend on one another.
Outcome
Communication and collaboration improve.
Chapter: Context: Who and What Is Involved? - Stakeholder relationships and interactions
Problem
Unclear ownership creates conflicting priorities.
Action
Identify the client with authority over the business need.
Outcome
Requirements receive consistent direction.
Chapter: Context: Who and What Is Involved? - Who is the client?
Problem
One source rarely provides complete information.
Action
Collect information from stakeholders, documents, systems, and observations.
Outcome
Requirements become more complete and accurate.
Chapter: Process: How Do We Do Business Analysis? - In search of requirements: where do they come from
Problem
Unstructured analysis produces inconsistent results.
Action
Use a repeatable process from discovery through validation.
Outcome
Business analysis becomes more dependable.
Chapter: Process: How Do We Do Business Analysis? - Doing business analysis: the process
Problem
Unknown information weakens analysis.
Action
Investigate the business thoroughly before documenting requirements.
Outcome
Important information is discovered earlier.
Chapter: Process: How Do We Do Business Analysis? - Discovery: we don’t know what we don’t know
Problem
Unchecked assumptions introduce hidden risks.
Action
Verify assumptions with evidence before relying on them.
Outcome
Requirements become more reliable.
Chapter: Process: How Do We Do Business Analysis? - Assumptions: the good, the bad and the ugly
Problem
Needed improvements remain hidden without careful comparison.
Action
Compare the current state with the desired future state.
Outcome
The required changes become clear.
Chapter: Process: How Do We Do Business Analysis? - Analysis: finding the gaps
Problem
Teams cannot work toward an undefined future.
Action
Define how the business should operate after the change.
Outcome
Stakeholders share a common target.
Chapter: Process: How Do We Do Business Analysis? - Synthesis: defining future state
Problem
Disorganized information is difficult to understand and maintain.
Action
Group and structure requirements consistently.
Outcome
Requirements become easier to use.
Chapter: Process: How Do We Do Business Analysis? - Packaging: creating order
Problem
Limited resources prevent everything from being delivered at once.
Action
Rank requirements by business value and priority.
Outcome
The most valuable work is delivered first.
Chapter: Process: How Do We Do Business Analysis? - Prioritizing: scope refinement
Problem
Using the wrong analysis activity wastes time and effort.
Action
Select the business analysis activity that best aligns with the current objective.
Outcome
Analysis becomes more effective.
Chapter: Activities: What Do Analysts Do All Day? - Business analysis activities at a glance
Problem
Useful information is overlooked when existing artifacts are ignored.
Action
Examine available documents, models, systems, and records before gathering new information.
Outcome
Requirements build on reliable knowledge.
Chapter: Activities: What Do Analysts Do All Day? - Due diligence: artifact analysis
Problem
Incomplete information leads to weak requirements.
Action
Ask focused follow-up questions until every important point is understood.
Outcome
Requirements become more complete and accurate.
Chapter: Activities: What Do Analysts Do All Day? - Questions: asking and asking again
Problem
Interviews alone do not reveal real business practices.
Action
Watch users perform their daily work in real-world environments.
Outcome
Requirements reflect actual business operations.
Chapter: Activities: What Do Analysts Do All Day? - Immersion: learning by experience
Problem
Problems return when only symptoms are addressed.
Action
Identify the underlying cause before defining requirements or solutions.
Outcome
Solutions resolve the real business problem.
Chapter: Activities: What Do Analysts Do All Day? - Root cause analysis: why do we have a problem
Problem
Inefficient processes waste time and effort.
Action
Examine each process step to identify unnecessary work and bottlenecks.
Outcome
Business processes become more efficient.
Chapter: Activities: What Do Analysts Do All Day? - Process analysis: making it flow
Problem
Text alone cannot clearly communicate complex relationships.
Action
Create visual models that represent important business information.
Outcome
Stakeholders understand the analysis more easily.
Chapter: Activities: What Do Analysts Do All Day? - Modelling: getting the picture
Problem
Mixing different requirement types creates confusion.
Action
Organize requirements into clearly defined categories.
Outcome
Requirements become easier to manage.
Chapter: Product: How Do We Define Requirements? - Requirement types
Problem
Projects lose direction without clear business objectives.
Action
Document the strategic business outcomes that guide all other requirements.
Outcome
Solutions support organizational goals.
Chapter: Product: How Do We Define Requirements? - Strategic requirements
Problem
Unclear functionality leads to incorrect implementation.
Action
Describe the behaviors and capabilities the solution must provide.
Outcome
Delivered features meet business needs.
Chapter: Product: How Do We Define Requirements? - Functional requirements
Problem
A solution can function correctly but still fail to meet user expectations.
Action
Document measurable non-functional requirements for the solution.
Outcome
The solution performs as the business expects.
Chapter: Product: How Do We Define Requirements? - Non-functional requirements
Problem
Deployment becomes difficult when implementation needs are overlooked.
Action
Document the conditions required to implement the solution successfully.
Outcome
Implementation proceeds with fewer surprises.
Chapter: Product: How Do We Define Requirements? - Implementation requirements
Problem
Poor quality requirements create costly rework.
Action
Review requirements for risks that reduce their quality.
Outcome
Problems are prevented earlier.
Chapter: Quality: How to Deliver a Good Product? - Requirements quality factors and risks
Problem
Weak requirements create confusion during implementation.
Action
Check every requirement against agreed quality standards.
Outcome
Requirements become more reliable.
Chapter: Quality: How to Deliver a Good Product? - Quality criteria
Problem
Inconsistent documentation causes misunderstanding.
Action
Use clear language and a consistent structure throughout the documentation.
Outcome
Stakeholders interpret requirements the same way.
Chapter: Quality: How to Deliver a Good Product? - Documentation best practices
Problem
Errors remain hidden without systematic quality checks.
Action
Perform quality reviews before requirements are finalized.
Outcome
Requirement quality improves.
Chapter: Quality: How to Deliver a Good Product? - Requirements quality assurance
Problem
Different interpretations lead to implementation mistakes.
Action
Validate that stakeholders understand the requirements in the same way.
Outcome
Requirements are implemented more accurately.
Chapter: Quality: How to Deliver a Good Product? - Validation of understanding
Problem
Requirements are misunderstood when they are communicated poorly.
Action
Choose the communication technique that best fits the audience and the purpose.
Outcome
Stakeholders understand requirements more accurately.
Chapter: Communication: Requirements Sharing Techniques - Goals and challenges of communicating requirements
Problem
No single communication format works for every requirement.
Action
Select the technique that best represents the information being shared.
Outcome
Requirements become easier to understand.
Chapter: Communication: Requirements Sharing Techniques - Tools and techniques overview
Problem
Ambiguous wording creates misunderstandings.
Action
Use simple, precise, and unambiguous language when documenting requirements.
Outcome
Readers interpret requirements consistently.
Chapter: Communication: Requirements Sharing Techniques - Natural language
Problem
Inconsistent writing makes requirements difficult to review.
Action
Document requirements using a consistent structure and format.
Outcome
Requirements become easier to maintain.
Chapter: Communication: Requirements Sharing Techniques - Structured language
Problem
Tasks are performed inconsistently when instructions are unclear.
Action
Document each procedure as a clear sequence of steps.
Outcome
People complete tasks more consistently.
Chapter: Communication: Requirements Sharing Techniques - Procedural text
Problem
Requirements cannot be verified without clear success conditions.
Action
Specify measurable criteria that every requirement must satisfy.
Outcome
Acceptance decisions become objective.
Chapter: Communication: Requirements Sharing Techniques - Satisfaction and acceptance criteria
Problem
Written descriptions alone leave important interaction details unclear.
Action
Create simple visual representations of the expected user experience.
Outcome
Stakeholders provide more accurate feedback.
Chapter: Communication: Requirements Sharing Techniques - Wireframes and storyboards
Problem
Design issues remain hidden until users interact with the solution.
Action
Build interactive prototypes before implementation begins.
Outcome
Usability problems are discovered earlier.
Chapter: Communication: Requirements Sharing Techniques - Interactive prototypes
Problem
Repeated design decisions create unnecessary inconsistency.
Action
Maintain a catalog of reusable design elements.
Outcome
Solutions provide a more consistent user experience.
Chapter: Communication: Requirements Sharing Techniques - Design elements catalogue
Problem
Large amounts of related information are difficult to compare in plain text.
Action
Present structured information in tables or matrices.
Outcome
Relationships become easier to analyze.
Chapter: Communication: Requirements Sharing Techniques - Tables and matrices
Problem
Complex decision logic is difficult to verify in narrative form.
Action
Represent business rules with decision tables or decision trees.
Outcome
Decision logic becomes easier to validate.
Chapter: Communication: Requirements Sharing Techniques - Decision tables and decision trees
Problem
Copied requirements become outdated when the source changes.
Action
Link to external requirements instead of duplicating their content.
Outcome
Documentation stays accurate and consistent.
Chapter: Communication: Requirements Sharing Techniques - References to external requirements
Problem
Text alone cannot clearly show important relationships.
Action
Create diagrams that visually explain business concepts.
Outcome
Complex information becomes easier to understand.
Chapter: Diagrams: Modelling Requirements - On the value of modelling… again
Problem
Poorly designed diagrams reduce communication quality.
Action
Follow clear and consistent modeling standards.
Outcome
Models communicate information more effectively.
Chapter: Diagrams: Modelling Requirements - Modelling best practices
Problem
Unclear boundaries create scope confusion.
Action
Create a context model that shows the solution and its external interactions.
Outcome
Everyone understands the solution scope.
Chapter: Diagrams: Modelling Requirements - Context model
Problem
Opportunities for improvement are difficult to identify without a business view.
Action
Create a value chain model that shows how work creates value.
Outcome
Improvement efforts focus on high-value activities.
Chapter: Diagrams: Modelling Requirements - Value chain model
Problem
Functional scope is difficult to understand without a visual overview.
Action
Model the interactions between users and the solution.
Outcome
System responsibilities become clearer.
Chapter: Diagrams: Modelling Requirements - Use case diagram
Problem
Data dependencies are difficult to understand.
Action
Create data flow diagrams that show how information is processed.
Outcome
Data movement becomes easier to analyze.
Chapter: Diagrams: Modelling Requirements - Data flow diagram
Problem
Process weaknesses remain hidden without a complete view of the workflow.
Action
Create process flow diagrams that show all major activities.
Outcome
Process improvements become easier to identify.
Chapter: Diagrams: Modelling Requirements - Process flows
Problem
System behavior is difficult to predict when state changes are undefined.
Action
Create state transition diagrams for important business objects.
Outcome
Expected behavior becomes easier to understand.
Chapter: Diagrams: Modelling Requirements - State transition diagram
Problem
Requirements lose value when they are not managed after approval.
Action
Track requirements from discovery through implementation and evaluation.
Outcome
The solution stays aligned with business goals.
Chapter: Solution: Getting Value Out of Requirements - Solution lifecycle
Problem
Design decisions drift away from business needs without clear guidance.
Action
Base solution design on approved business requirements.
Outcome
The solution reflects business expectations.
Chapter: Solution: Getting Value Out of Requirements - From requirements to solution design
Problem
Changes are difficult to assess when requirements are not connected.
Action
Link every requirement to its source, design, implementation, and validation.
Outcome
The impact of change becomes easier to manage.
Chapter: Solution: Getting Value Out of Requirements - Traceability: requirements GPS
Problem
A completed solution may fail to deliver the intended business value.
Action
Evaluate the solution against the original business objectives.
Outcome
Business success is confirmed.
Chapter: Solution: Getting Value Out of Requirements - Acceptance: did we achieve business goals?
Problem
Unnecessary meetings waste time and attention.
Action
Schedule meetings only when discussion or collaboration is needed.
Outcome
Time is used more effectively.
Chapter: Collaboration: Managing Groups and Meetings - Why hold a meeting?
Problem
Meetings lose focus without a specific purpose.
Action
State the expected outcome before the meeting begins.
Outcome
Discussions stay focused on results.
Chapter: Collaboration: Managing Groups and Meetings - Objectives
Problem
The wrong participants reduce meeting effectiveness.
Action
Include only people who contribute information or make decisions.
Outcome
Meetings become more productive.
Chapter: Collaboration: Managing Groups and Meetings - Participants
Problem
Poor preparation leads to inefficient discussions.
Action
Prepare the agenda, materials, and questions before the meeting.
Outcome
Participants contribute more effectively.
Chapter: Collaboration: Managing Groups and Meetings - Preparation
Problem
Logistical issues interrupt productive discussions.
Action
Arrange the meeting environment, tools, and materials before the session.
Outcome
The meeting runs more smoothly.
Chapter: Collaboration: Managing Groups and Meetings - Logistics
Problem
Meetings drift when discussions are not actively guided.
Action
Lead the conversation to encourage participation and reach decisions.
Outcome
The group achieves better outcomes.
Chapter: Collaboration: Managing Groups and Meetings - Facilitation
Problem
People remember meeting outcomes differently.
Action
Document decisions, responsibilities, and agreed actions during the meeting.
Outcome
Everyone leaves with the same understanding.
Chapter: Collaboration: Managing Groups and Meetings - Recording
Problem
Meeting decisions lose value without action.
Action
Track agreed actions after the meeting.
Outcome
Commitments are completed more consistently.
Chapter: Collaboration: Managing Groups and Meetings - Follow-up
Problem
Solutions create little value when they ignore business objectives.
Action
Evaluate every requirement against the desired business outcomes.
Outcome
Solutions deliver greater business value.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Focus on business - Calibrate solutions to business goals
Problem
Teams waste effort by solving symptoms rather than causes.
Action
Verify the true business problem before defining a solution.
Outcome
The solution addresses the real business need.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Solve the right problem
Problem
Accepted beliefs can become incorrect requirements.
Action
Challenge important information until it is supported by evidence.
Outcome
Analysis becomes more accurate.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Question everything
Problem
Groups struggle when collaboration lacks direction.
Action
Facilitate discussions that help stakeholders reach agreement.
Outcome
Collaboration becomes more effective.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Lead and facilitate
Problem
Requirements become unreliable when documented too early.
Action
Understand and analyze available information before defining requirements.
Outcome
Requirements better reflect business reality.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Analysis before synthesis; Information before requirements
Problem
Hidden gaps create avoidable project risks.
Action
Document missing information and unresolved questions openly.
Outcome
Issues are addressed earlier.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Uncover gaps - Do not cover them up
Problem
Unnecessary complexity makes solutions harder to deliver and maintain.
Action
Remove anything that does not contribute to the business need.
Outcome
Requirements become easier to implement.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Simplify until nothing can be removed
Problem
Different interpretations lead to inconsistent implementation.
Action
Confirm that all stakeholders understand the requirements in the same way.
Outcome
Teams work from a common understanding.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Take responsibility for shared understanding of business requirements
Problem
Requirements become outdated as the business evolves.
Action
Update your analysis and requirements when business conditions change.
Outcome
The solution remains relevant.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Accept and embrace business change
Problem
Requirements alone do not guarantee successful outcomes.
Action
Support the team throughout implementation and delivery.
Outcome
The solution achieves better business results.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Be part of the solution
Problem
Solutions fail when they ignore how people actually behave.
Action
Consider normal human behavior when defining requirements and solutions.
Outcome
Solutions are adopted more successfully.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Expect human behavior from human beings
Problem
Professional skills become outdated without ongoing learning.
Action
Learn from every project and adapt your approach.
Outcome
Your effectiveness as a business analyst continues to grow.
Chapter: Business Analyst Mindset: The Glue That Holds It Together - Learn, adapt, and thrive