TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Education

    Mastering Business Analysis

    Your key to advancing your career as a Business Analyst and beyond

    Advertise

    Copyright: © MasterClass 247 LLC

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    MBA116: Implementing Solutions vs Problem Solving Mar 21, 2017
    Show notes

    In this episode, Matt Adams helps us understand what to do when we’re given a solution to implement. His approach leads us to become trusted advisors instead of note takers.

    

    After listening to this episode, you'll understand:

    • The problem with implementing a solution that you’re given
    • How to identify the underlying need and value to the customer
    • What to do about specific requests from a single customer
    

    Show Notes

    What do you do when customers ask you to write the requirements for a solution you’re given? If you simply write the requirements as requested without considering whether or not that solution is the right solution, you’re not providing much value.

    The tendency for customers to provide a solution and ask you to write the requirements is a common problem. The requested solution may only solve symptoms of the real problem or might not solve any problem at all.

    Finding the Real Problem to Solve

    When presented a solution, one of the first things you can do is work to discover the problem your customer is trying to solve through that solution. Using a root cause technique such as 5 Whys allows you to dig down deep to discover the intended value of the solution.

    Asking ‘why’ at five levels helps you to understand the root problem. For example, asking “Why do you want to send a message to the inventory system?” may help you discover an underlying problem that the proposed solution won’t actually solve.

    Understanding workarounds that the customer currently uses to address the problem may also give you clues as to the underlying problem and solutions to address that problem.

    Observe to Discover

    Observation is another technique you can use to discover the real underlying problem. Identifying workarounds and observing the way customers use their current system help you gain a better understanding of the challenges and opportunities faced by your customer.

    Observation may also help you to find a faster, simpler solution that will meet your customer’s needs.

    Process maps and data about the problem also lead you to better solutions.

    So What?

    With User Stories, we often include a ‘so that’ clause. The ‘so that’ portion answers the ‘why’ question.

    While some people skip the value portion of the User Story, it’s critically to understand the value. You should also dig deeper into the ‘so that’ clause and ask ‘why’ to make sure the User Story is solving the right problem.

    A ‘so that’ clause isn’t just for User Stories. Adding a value clause (so that) to traditional requirements helps you to better understand the driver behind the requirement. You can also use it to make sure you’re digging deeper to understand the ‘why’ behind each requirement.

    Listen to the full episode for all of Matt’s advice on what to do when you’re given a solution to implement.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA116.mp3

    Z

    Your Homework

    Add a ‘so that’ clause to all of your requirements and make sure you dig deeper by asking ‘why’ about the ‘so that’ clause to make sure you’re solving the right problem.

    Also, ask about current workarounds your customer uses to solve the problem. This helps you to better understand the curent process and discover the real problem.

    Links mentioned in this episode:

    • Matt’s website BA-Guru
    Matthew Adams

    Matthew Adams

    Founder, BA Guru

    Matthew Adams is the founder of BA Guru, a website devoted to helping you develop your business analysis skills. Matt specializes in delivering tangible system and process improvements, while sharing his best BA techniques, tips, and experiences through BA Guru.

    • X
    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA116: Implementing Solutions vs Problem Solving appeared first on Mastering Business Analysis.


    MBA115: Political Martial Arts – Navigating Office Politics Mar 14, 2017
    Show notes

    In this episode, Paula Bell shares her tips and advice to break through the bureaucracy and red tape that holds many organizations back.

    

    After listening to this episode, you'll understand:

    • How bureaucracy can slow down your progress
    • Why networking and stakeholder management is critical
    • Approaches to navigate office politics
    • How to NOT lose your integrity
    

    Show Notes

    Office politics can slow progress and even make it impossible to run a successful project. The bureaucracy affects more than morale; it slows progress and makes it harder to get work done. Understanding office politics and developing a strategy for managing stakeholders will help you to have greater influence and get more done.

    Listen to the full episode to hear all of Paula’s tips on successfully navigating office politics.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA115.mp3

    Z

    Your Homework

    Work to understand your company’s culture and how decisions are made. This allows you to better understand people’s motivation and adapt your approach to get things done.

    Links mentioned in this episode:

    • Paula’s website paulaabell.com
    • Paula’s past episode on Systems Thinking
    • Paula’s past episode on Collaboration
    Paula Bell

    Paula Bell

    Paula A. Bell Consulting, LLC

    Paula Bell is a Business Analyst, consultant, mentor, author, and speaker known for providing guidance to aspiring business analysts. She’s held just about every role in a RACI matrix including business analyst, technical writer, project manager, developer, test lead, and product owner.

    Paula is a frequent speaker at industry conferences and writes articles on BA and project related topics.

    • X
    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA115: Political Martial Arts – Navigating Office Politics appeared first on Mastering Business Analysis.


    MBA114: Value Proposition of the BA Role Mar 07, 2017
    Show notes

    In this episode, David Olson discusses the evolution of the Business Analyst role and its true value proposition.

    

    After listening to this episode, you'll understand:

    • How the definition and perception of the BA role has evolved
    • Why the Business Analyst field requires multiple roles
    • The real value that BAs bring to organizations
    • How Agile changes the value proposition for the BA role
    

    Show Notes

    A common perception of the Business Analyst role is that they are responsible for documenting requirements and nothing else. That perception leads to limitations and challenges with showing the true value of the role.

    In reality, business analysis involves much more than requirements. Some of the biggest value a Business Analyst can provide happens before the requirements stage and even before the project starts.

    There is tremendous value in helping the organization understand the current situation better and identify the real problems and opportunities they face. This leads to a better understanding of options, which could be addressed through projects or other approaches.

    The real value in business analysis is in helping the organization make the right decisions.

    Evolution of the BA Role

    We’ve seen an evolution in the Business Analyst role and the way it’s defined by the International Institute for Business Analysis and the UK Chartered Institute for IT. That evolution has gone from a requirements focus to a focus on needs and recommending solutions.

    There are some potential threats to that evolution from organizational perspectives and the description of the role by other professional organizations which focus on requirements and in-project work.

    The progress in the evolution is headed in the right direction, but still has a way to go.

    The Multiple Roles of the BA

    With the evolution of the BA role, the focus on out-of-project work, and the rise of Business Architects, there is a need for different types of Business Analysts.

    Similar to the healthcare field, there should be one overarching definition that encompasses the full value delivered and individuals who specialize in a specific area of value delivery. This can include in-project BAs who focus on requirements and viable solutions, Business Architects, and Strategic Analysts who focus on overall organizational strategy outside of projects.

    All of these roles have a core set of skills and purpose that tie them together, but the specialties allow each role to focus on and go deep in a specific area.

    The Business Analyst Value Proposition

    Through analysis work at any level, whether inside a project or outside of a project across the organization, BAs can make information consumable and help their organization make the right decisions. We become a trusted advisor, present information and options, and advise decision makers on making the right choices.

    That can include decision option identification, examination of alternatives, facilitating the decision-making process, and facilitating the implementation on those decisions. This requires BAs to be proactive in identifying solutions and recommending options and alternatives.

    In the book, Smart Choices, the author recommends using Proact decision making method. The Proact method includes:

    1. Define the decisions
    2. Specify your objectives
    3. Identify Alternatives
    4. Understand the consequences
    5. Understand the trade-offs between the options
    6. Clarify what you’re uncertain about
    7. Understand the risk tolerance level
    8. Consider the link decisions

    Supporting this process is where Business Analysts can add value. By structuring this information in an understandable way and presenting it clearly to decision-makers with recommendations will allow you to influence your organization to make informed choices, leading to better outcomes.

    Listen to the full episode to hear David’s advice on how to shift the perception of your role and how Agile changes this advice.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA114.mp3

    Z

    Your Homework

    Change the way you approach your job. Focus less on the change aspect and focus more on the decision-making aspect. Bring some of that approach (the way you frame questions and how you present information and recommendations) to your daily work.

    Links mentioned in this episode:

    • BAWiki.com Website

    David Olson, CBAP

    Creator of BAWiki.com

    David Olson is a Senior Business Analyst with experience in defining, enhancing, and supporting applications and business processes primarily in the areas of Sales, Marketing, Web, Data, and Regulatory areas. Outside of his work, he also researches and write articles and reference materials for the BAwiki.com web site.

    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA114: Value Proposition of the BA Role appeared first on Mastering Business Analysis.


    MBA113: Problem Solving – The RIGHT Stuff Feb 28, 2017
    Show notes

    In this episode, Sinikka Waugh shares a problem solving approach to take you through incovering the right problem, identifying the right solution, and putting the right plan into action.

    

    After listening to this episode, you'll understand:

    • Why problem solving is a critical skill
    • How to uncover the right problem and find the right solution
    • What you can do to put your plan into action
    

    Show Notes

    Problem solving is a vital skill, regardless of your role or level in the organization. Without an effective problem solving approach, you will likely treat the symptoms instead of the underlying cause and have little positive impact.

    A problem is anything preventing you from going where you want to be next. This can be at an individual, team, or organizational level.

    The Right Stuff problem solving approach involved identifying the right problem, uncovering the right solution, and creating an action plan to enable that solution.

    The Right Problem

    When beginning any problem solving, bring others in to get diversity of thought. Once you include others, start with the Five Whys technique by asking ‘why’ five times.

    The focus should be on why the problem exists. For each answer to the Five Whys, ask ‘why’ five more times. For each of those, you can ask ‘why’ five more times.

    From that rapid list of many causes, patterns and commonalities will likely emerge. Focus on the items that you can solve, want to solve, and should solve. Those common themes are the right problem to solve.

    The Right Solution

    Once you identify the right problem to solve, brainstorm to identify possible solutions. Go for quantity at first without filtering of judgment.

    After you have a list of solutions, you can narrow down the list to those that are feasible and vote on the top solutions to explore.

    For each feasible solution, gather information and find the solution with the best BODI. The acronym BODI stands for Benefits, Obstacles, Data, and Instinct.

    The Best BODI

    To discover the solution with the best BODI, make a chart for each potential solution to list the benefits, obstacles, data, and instinct information.

    • Benefits: What are the benefits of this solution?
    • Obstacles: What are the obstacles associated with this solution? What could potentially prevent it from being successful?
    • Data: What data do we have about this solution? Do we have data that makes sense to us?
    • Instinct: Do we believe this is a right solution for us right now?

    Complete the benefits, obstacles, and data for each solution, and then see what your instinct tells you about each option. Is it a right solution for now?

    You want to find the solution with the best benefits, fewest obstacles, and that your instincts tell you that this is a good choice.

    The Right Action Plan

    To be successful in any action, you need to know what, why, and how. The previous steps of identifying the right problem and solution as well as uncovering the benefits tells you the what and why.

    The well thought out ‘why’ also helps get the right people involved once you take action. Additionally, you’ve already discovered risks when you identified obstacles, so you can work to address those risks.

    Now that you have the what, why, and associated risks, you can focus on the how – executing your plan. You can also use the data you identified earlier to help drive the action plan.

    See the links section for introductory worksheets and materials from Sinikka to help you solve problems.

    Listen to the full episode to understand how to implement Sinikka’s problem solving approach.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA113.mp3

    Z

    Your Homework

    Include others in your problem solving approach. Include others in the process and time box the approach to finding the right solution to the right problem.

    Links mentioned in this episode:

    • Sinikka’s website Your Clear Next Step
    • Introduction to Problem Solving
    • More worksheets from Sinikka
      • Problems Worksheet
      • Solution Worksheet
    • See me at the Wisconsin Business Analyst Development Day in May
    • in May 2017
    Sinikka Waugh

    Sinikka Waugh

    Your Clear Next Step

    Sinikka Waugh is a recognized leader in understanding people and in adapting tools, techniques, and processes to meet the demands of the situation at hand. As a project manager, business analyst, facilitator, trainer, and coach, Sinikka is known for consistently helping teams find innovative ways to solve problems and get things done.

    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA113: Problem Solving – The RIGHT Stuff appeared first on Mastering Business Analysis.


    MBA112: User Centered Design Feb 21, 2017
    Show notes

    In this episode, Caleb Carroll helps us deliver better business value through a User Centered Design approach.

    

    After listening to this episode, you'll understand:

    • The difference between UX, UI, and CX
    • Why user centered design is critical to your success
    • Tools you can use to take a user centered design approach
    

    Show Notes

    A user-centered design is focused on who users are, how they think, and what they’re trying to do. This episode focuses on how user centered design techniques can enhance your Business Analysis skills set. Focusing on the user increases value delivered, faster solutions, and greater productivity.

    Caleb discusses the importance of a user centered design approach and the tools and techniques you can use to make sure you’re building valuable solutions for your customers.

    Listen to the full episode to hear all of Caleb’s advice and tools recommendations for using a User Centered Design approach.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA112.mp3

    Z

    Your Homework

    Shift your mindset to focus on who are you ceating a solution for, what they need, and how are you going to make their lives easier. Get close to your customers and use observation to get information you need to find the right solution to their needs.

    Caleb Carroll

    Caleb Carroll

    User Experience Design Lead

    Caleb Carroll is a User Experience Designer, technology lover, whiteboard enthusiast, and professional question-asker. He is a Certified Usability Analyst through Human Factors International and has a Graduate Certificate in Human Computer Interaction from Iowa State University.

    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA112: User Centered Design appeared first on Mastering Business Analysis.


    MBA111: Design Thinking IS Good Business Analysis Feb 14, 2017
    Show notes

    Design Thinking is business analysis done the right way. In this episode, we’ll explore the tools of Design Thinking and how this approach helps ensure you build valuable solutions.

    

    After listening to this episode, you'll understand:

    • What you can do about shelfware and wicked problems
    • How to use common techniques to understand the real problem
    • Why a human centered approach helps you find the right solution
    • The mindset shift needed to adopt a Design Thinking approach
    

    Show Notes

    Design Thinking is good business analysis done the right way. It helps ensure that we build the right things; solutions that will be valuable to our customers.

    You can use Design Thinking to solve wicked problems. Wicked problems are complex problems for which the right solution isn’t immediately clear.

    The real problem is shelfware; creating a solution that’s what the customer asked for but isn’t what they really need and therefore goes unused. We’re often given a solution to implement and fail to explore whether or not it’s the right solution.

    Without innovation and a human centered focus, we’ll find it more and more difficult to surprise and delight our customers or provide significant business value.

    The Three Lenses

    To find the sight solutions for our customers, we need to look at solutions through three lenses. Those lenses are Business Value, Customer Experience, and Technical Feasibility.

    Is it valuable to the business and customers? Focusing on business value (the ‘Why’) helps to develop solutions that maximize value. That value can be in the form of income, cost reduction, risk reduction, or anything else important to your customer.

    Is it a great customer experience? Without a positive customer experience, we’ll create shelfware or lose customers, which results in less business value.

    Is it feasible? If the proposed solution isn’t technically feasible, you can’t build it (or at least it would take too long or be too expensive). Consider whether or not your organization has the technical skills, architecture, personnel, and skills needed to build and maintain the solution.

    You need all three lenses to create a valuable solution that customers will love.

    Design Thinking Process

    Design Thinking is more of a mindset than a process. While there are many tools, techniques, and approaches to Design Thinking and we’ll explore the approach used by the Stanford Design School.

    The Stanford approach applies five modes in an iterative process to break things down into the Problem Space and the Solution Space.

    The five modes are:

    1. Empathize
    2. Define
    3. Ideate
    4. Prototype
    5. Test

    The Problem Space

    Use the Empathize Mode to gain a deeper understanding of the customer. This helps us to better understand pain points and what customers would find valuable. Here, we can use tools such as Five Whys, Personas, Empathy Maps, interviews, Observation, and Customer Journeys.

    In the Define Mode, we define the problem to clarify scope. Using the outputs from the Empathize Mode, you can define a problem statement or hypothesis. This allows the team to focus on solving the right problem.

    The Solution Space

    In the Ideate Mode, you come up with many potential ideas focusing first on quantity and then focusing on quality. We use divergent thinking to find many possible solutions and then convergent thinking to eliminate, combine, and otherwise reduce the number of potential solutions (essentially brainstorming).

    When you move into the Prototype Mode, you build something that customers can react to and provide feedback. Start with the simplest thing possible such as paper prototypes and then move to move robust prototypes.

    In the Test Mode, you provide the prototypes to customers and get their feedback. That feedback can then be used to adapt, come up with new ideas, or even modify your hypothesis.

    These modes occur in an iterative cycle, not linear steps.

    Listen to the full episode to learn about the mindset shift necessary to be successful and the techniques you can use in Design Thinking.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA111.mp3

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA111: Design Thinking IS Good Business Analysis appeared first on Mastering Business Analysis.


    MBA110: Managing Ambiguous Requirements Feb 07, 2017
    Show notes

    In this episode, Scott Stribrny shares four techniques to help you identify and address ambiguous requirements and create a common understanding.

    

    After listening to this episode, you'll understand:

    • The impact ambiguous requirements can have on your project
    • How to identify and address ambiguity
    • How to get started implementing techniques to reduce ambiguity
    

    Show Notes

    Ambiguous or unclear requirements lead to confusion and waste and result in failed projects. Luckily, there are a few simple approaches for identifying and fixing ambiguous requirements.

    To discover ambiguity in project requirements, we can use a set of four heuristics.

    1. Search Subjective Terms
    2. Memorization Technique
    3. Mary Had A Little Lamb Technique
    4. Ambiguity Poll Technique

    Search Subjective Terms

    One of the easiest ways to identify ambiguous requirements is to search for subjective terms. Subjective terms are words that are not specific and can mean different things to different people.

    Words and phrases such as fast, easy, user friendly, and state of the art are all subjective. How fast is fast? What’s easy for one person may be difficult to another.

    Start by creating a checklist of subjective terms by brainstorming and then scan your requirements for those terms. When you find a subjective term, change it to something move specific and testable.

    For example, “fast” may be changed to “a response time of 3 seconds or less”.

    Memorization Technique

    With the memorization technique, you read or otherwise briefly share the requirement with stakeholders and then have them recall the requirement from memory. Often, stakeholders will leave out or replace words or phrases when they recall the requirement.

    Missing or replaced portions of the requirement often indicate ambiguity. This is because the stakeholder’s mind is working to find meaning in what they heard and they omit or add to the requirement to fill in gaps.

    Mary Had a Little Lamb Technique

    The written word is a terrible way of conveying information. People can read the same words with different inflection and interpret the meaning differently.

    With the Mary Had a Little Lamb technique, you read the requirement out loud stressing different words or phrases to uncover areas that can be interpreted differently.

    For example, saying “MARY had a little lamb” implies that it was Mary’s lamb and not Cathy’s or Ann’s lamb. “Mary HAD a little lamb” implies that Mary had a lamb in the past, but no longer has one.

    Ambiguity Poll Technique

    The ambiguity poll technique helps you to identify misunderstandings be having stakeholders size the requirement using a common metric.

    Differences in the sizing among stakeholders possible indicates that there is not a shared understanding about the requirement. This leads to a conversation about why people voted or sized it the way they did to uncover any misunderstandings.

    This approach is very similar to story sizing used by many agile teams. Wide differences in story points frequently means that there are differences in understanding about the user story and more clarification is needed.

    Listen to the full episode to find out more ways to reduce the ambiguity in your requirements.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA110.mp3

    Z

    Your Homework

    Pick one of the techniques to reduce ambiguity discussed in this episode and apply it to your requirements. You can do this on your own or for even more impact, do it together with a co-worker. That will give both of you practice in applying the technique.

    Links mentioned in this episode:

    • Group Atlantic website: Group Atlantic
    • Scott’s presentation on Managing Ambiguity
    • Scott’s prior episode – Step Up to Leadership
    Scott Stribrny

    Scott Stribrny

    President, Group Atlantic, Inc

    Scott is a senior advisor to Fortune 500 CXOs, and program and project managers worldwide on the effectiveness, rewards, and risks of their high-tech programs and policies. Currently advising on agile organizations, high-performance teams, techniques for effective product requirement definition and risk management, as well as adapting modern software development techniques to fit specific business needs.

    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA110: Managing Ambiguous Requirements appeared first on Mastering Business Analysis.


    MBA109: Foundations in Business Analysis Jan 31, 2017
    Show notes

    In this episode, Greg Kulander and Charlene Ceci help us get back to basics and establish a strong foundation for your business analysis skills and techniques.

    

    After listening to this episode, you'll understand:

    • Why it’s important to go back to basics – even for experienced professionals
    • The who, what, when, where, why and how of the project
    • Basic (yet critical) techniques for obtaining requirements
    • How to tailor your review process to ensure approval
    

    Show Notes

    A good process can help an organization create and sustain good requirements. A requirements tool can help a team be more efficient. However, we often focus too much on the process and tools and not enough on the fundamentals of business analysis.

    Foundational practices in business analysis come down to three areas; asking good questions, eliciting requirements, and gaining approval. These three components not only make up foundational competencies for the role, they also provide a base upon which to build to much higher levels.

    Asking Good Questions

    Asking good questions helps you to discover the real problem your customer is trying to solve. Think of the five Ws and one H you likely learned in school. Questions beginning with who, what, where, when, why, and how help you to explore the problem context.

    Example questions include:

    Who is the solution being developed for? Who are we creating the requirements for (who is the team consuming requirements)?

    What business problem are you trying to solve? Make sure that there’s alignment and agreement within the team as to the problem being addressed.

    What’s the motivation for trying to solve this problem?

    When does the solution need to be completed? When does the new system need to be available ((this helps you to understand non-functional requirements such as system uptime)?

    Why is this project being requested and why is it important?

    Why is one solution favored over another? What are the factors against which we’re judging the solution? These questions help you to understand trade-offs and priorities.

    How is the solution going to be used? This question helps you to understand expected benefits.

    How do we judge the success of the solution (success criteria)?

    The good questions mentioned above can help you to discover the right problem to solve, understand priorities, and identify the right solution.

    Eliciting Requirements

    Once we have an understanding of the right questions to ask, we can prepare to elicit requirements. Three core requirements elicitation approaches are interviewing, job shadowing, and facilitation.

    When preparing to interview, you need to understand who to interview. Consider all parties impacted by the problem you’re trying to solve and the different types of users of the proposed solution.

    Be mindful of the time of the people you’re interviewing and get buy-in from their manager.

    Job shadowing allows you to see how users interact with the system or deal with the problem you’re trying to solve. It gives you the opportunity to connect with the person performing the job. It also helps you understand much more quickly the process, approach, and problems faced by the user.

    During job shadowing, you will likely be asking questions throughout the process. Be sure to ask the person you’re shadowing why they do things in a certain way that deviates from process manuals or the way you understand the process to work.

    Perform job shadowing in a respectful way. Make it clear that you’re trying to understand the process and any challenges in completing the process so that you can help create a solution that meets their needs. Be sensitive to the fact that shadowing takes time away from their job or at least slows them down.

    To be successful at facilitation, you need to be able to think on your feet. The biggest challenge is keeping the group on track and working toward the goal. Using tools such as a parking lot and ensuring everyone’s voice is heard helps make the session valuable.

    Gaining Approval

    Once you have the information from your elicitation, you need to find a way to package and deliver it to your stakeholders.

    Templates can help you organize information about the requirements into a consistent format. This makes it easier for stakeholders to review and use the information. Templates can also serve as a reminder of anything you may have missed and provide a stricture for reviewing requirements with stakeholders.

    In most cases (especially in waterfall environments), you’ll need to get stakeholder approval of requirements to move forward. Key to success in this area is knowing your stakeholders and ensuring that you’ve identified everyone who may be impacted by the project and the proposed solution.

    Requirements reviews and walk-throughs help facilitate a discussion about the requirements to create a shared understanding and agreement. Acting as an advocate for your stakeholders will make it easier to gain approval.

    Have a plan for communicating and gaining approval from stakeholders, especially if your stakeholders are geographically diverse. Using a divide and conquer approach in which you meet separately with different groups of stakeholders to get their input and feedback before bringing everyone together can help make getting approval easier.

    Always Be Closing

    Continuously work on building relationships and move toward approval by reviewing small increments of the requirements and seeking feedback.

    Incremental reviews and discussions about requirements help you to adapt throughout your project.

    Listen to the full episode to get all of Greg and Charlene’s advice on building a solid foundation within your business analysis skills.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA109.mp3

    Z

    Your Homework

    Build on your facilitation skills. Whether you’re new to facilitation or experienced, look for opportunities to facilitate and continuously practice. If you’re inexperienced, start with smaller groups. Seeking feedback after you facilitate also helps you improve and hon your skill.

    Know your stakeholders. Think visibility, alignment, and commitment. Having visibility with your stakeholders and acting as an advocate for their needs helps you to build trust. Then work with all of the stakeholder groups to ensure alignment toward a common goal. All this helps you get commitment toward contributing to the goal and gaining approval throughout delivery.

    Greg Kulander

    Greg Kulander

    Principal Consultant

    Greg Kulander, CBAP has been working primarily as a Business Analyst on software projects since 1999 for such companies as JP Morgan Chase, U.S. Bank, and NAVTEQ (now Nokia Location Services). Greg is also the Vice-President of Membership for the Chicagoland Chapter of the International Institute of Business Analysis.

    • LinkedIn
    Charlene Ceci

    Charlene Ceci

    Senior Project Manager / Senior Lead Business Analyst

    Charlene Ceci has over fifteen years of experience in all aspects of business analysis and project management. She is widely recognized for her talents in building high-performing teams, cross organizational communication, and complex problem solving. In her role at Geneca, Mrs. Ceci plays an influential role in the adoption and success of Geneca’s business analysis best practices.

    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA109: Foundations in Business Analysis appeared first on Mastering Business Analysis.


    MBA108: Prioritizing with the MVP Jan 24, 2017
    Show notes

    In this episode, Amanda Tygart and Jenny Swan help you to find the minimum viable product and use it to identify work that you should deliver first.

    

    After listening to this episode, you'll understand:

    • How to use personas to help with prioritization
    • How to slice work into valuable chunks
    • What minimum viable product (MVP) really means
    • How to identify the MVP for your project
    • What to do after you deliver the MVP
    

    Show Notes

    When everything is important, nothing is important. If we elicit a long list of wants or a requirements backlog, how can we know where to start? The approach that Amanda and Jenny share will help you to find the first slice you should take to get feedback and ensure you’re building the right solution.

    Start with a Goal

    To help you prioritize, start with the goal. If you don’t have clarity about the goal, it’s hard to discover the right priorities. When a stakeholder starts talking about a solution to implement as a goal, you’re clearly going down the wrong track.

    Use Personas

    Once everyone has clarity as to the goal, it’s important to understand who the end users are. There are likely different types of users with different needs. Understanding your customers should be done before you discuss potential solutions.

    One way to get clarity on your customer needs is to create personas for each of your customer types. Personas are avatars for your customers and help you better understand needs, wants, and constraints. They also help you focus on a specific person (albeit a fictional person) instead of a vague notion of a customer group.

    Observation

    Another powerful yet underutilized tool to help understand your customers is observation. You can observe customers interacting with your system or working through the problem you’re trying to solve for them. This helps you gain empathy and better understand their needs.

    Using personas and observation helps you filter the list of wants from stakeholders. It puts a fact based framework around what’s important to your customers.

    The MVP

    The minimum viable product (MVP), may be different things depending on your context and situation. Minimum means that we’re looking for the simplest thing we can do to get feedback and learn.

    Viability is about sustainability and scalability. The MVP doesn’t necessarily need to be scalable, but you need to consider the viability within your context and what you’re trying to learn. Be intentional about viability.

    When working toward the MVP, you can start with a low fidelity prototype such as a paper prototype. Starting with the simplest form allows you to learn and adjust without wasting time potentially building a high fidelity prototype of the wrong thing.

    Brainstorm to Extract the MVP

    To help you identify the MVP, use brainstorming techniques to generate a lot of ideas without judgment. Once you have all your ideas (or wants), look at it through different lenses such as location or customer segment.

    These lenses help you filter the ideas to what applies to a limited area of focus; something that you can build and on which you can get feedback.

    Story mapping can also be used as a form of brainstorming to generate ideas and find a slice through the journey that will create an opportunity to learn and adapt.

    After the MVP

    Sometimes, you’re done after delivering the MVP. More often, you’ll iterate and build on that MVP to create additional capabilities (minimum marketable features).

    It’s important to get feedback and observe how customers are using your MVP and subsequent releases so that you can adapt your strategy going forward.

    We often treat backlogs as a to do list. Instead, think of it as a list of options and consider the diminishing returns as you get to lower value items in your backlog.

    Listen to the full episode to understand how to use the MVP and personas to prioritize your project.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA108.mp3

    Z

    Your Homework

    Go through the project goals with the team to gain clarity. Also, remember that you can always build personas; even in the middle of a project.

    Use the tactic of observation throughout your project to watch what users are doing and how people go about solving a problem. This helps you reevaluate your assumptions and assess future work.

    Links mentioned in this episode:

    • Link to Amanda and Jenny’s presentation at Agile 2016
    Amanda Tygart

    Amanda Tygart

    Process Engineer-Agile Coach

    Amanda is a Business Analyst by heart. She’s passionate about Agile and the BA role within Agile. Amanda loves to teach and spread the gospel about the benefits of Agile and how it can improve programs and domains.

    • X
    • LinkedIn
    Jenny Swan

    Jenny Swan

    Agile Coach

    Jenny is a Business Analyst turned Agile Coach. At Agile 2016, Jenny and Amanda gave a presentation entitled “Everything is important RIGHT NOW! How do I determine a Minimum Viable Product?”

    • X
    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA108: Prioritizing with the MVP appeared first on Mastering Business Analysis.


    MBA107: Backlog Refinement – From Misunderstanding to Collaborative Discovery Jan 17, 2017
    Show notes

    In this episode, Richard Dolman helps us take backlog refinement from an underutilized meeting that doesn’t get the respect it deserves to a powerful forum for collaborative discovery.

    

    After listening to this episode, you'll understand:

    • The pitfalls of not refining your backlog regularly
    • What is needed to make a refinement session successful
    • What should happing during refinement
    • How incomplete user stories can actually help a team
    

    Show Notes

    Backlog refinement meetings can be a great opportunity for teams to ensure near term priorities are understood and ready for the team to work on. Unfortunately, many teams rush through this activity, leading to misunderstandings and acting like the backlog is a simple to do list.

    Backlog refinement is the act of the team reviewing the items in the backlog and discussing the detail to get clarity as to priorities and plan their work. It’s an opportunity for the team to come together and collaboratively discover what they’re being asked to do.

    Refinement includes elaborating on the backlog items for further clarity, decomposing large items into smaller pieces, doing lightweight functional design, elaborating on acceptance criteria, and even some sizing. The goal is to have near term, high priority backlog items that are small enough and understood by the team to begin working on in the next iteration.

    What defines a user story or backlog item as “ready” is up to the team. That Definition of Ready should be clearly understood and agreed upon by the entire team.

    Prerequisites to a Successful Refinement Session

    Start with a vision. A vision that’s understood and visible helps the team to focus on achieving that goal and allows them to question anything that may be taking them away from that goal.

    Next, a roadmap should be used so that the team understands the progression and what they’re working towards with each iteration or release. The roadmap also gives the team context so they know where they are in the product delivery cycle and if any architectural runway needs to be build out.

    Making Your Refinement Sessions Better

    Once a vision and roadmap is in place, the team can address how they see their ability to deliver the work and uncover opportunities to provide value. The team should feel confident that they understand the work that’s coming, how it ties to the vision, why it’s important, and how they’ll approach the work.

    The techniques and approach teams can use during backlog refinement can range from simply talking about the backlog item to creating visualizations and models to better understand the work.

    Teams may also compare what they need to do to the architecture to better determine if the need architecture is in place. Similarly, team members should uncover and discuss any dependencies.

    The refinement session can include writing new stories, slicing large backlog items into smaller stories, elaborating on backlog items to get clarity on the detail, and asking questions about and negotiating acceptance criteria.

    All of these activities and conversations drive confidence that when the team is ready to pick up one of the backlog items, they’ve exposed the critical aspects of the story and the work is understood.

    Go DEEP

    While good user stories follow the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable), the product backlog should be DEEP.

    DEEP is an acronym standing for Detailed appropriately, Emergent, Estimable, and Prioritized.

    Emergent refers to the fact that new information and feedback can come in at any time that may affect what’s in the backlog as well as its priorities. This means that not everything will be known upfront and we need to get comfortable with letting some of the details emerge as part of the refinement process.

    Don’t treat your backlog like a vague to do list. Make sure it’s an interactive session where team members can collaborate and create a shared understanding, which will have an impact on not only what the team products, but the quality and speed as well.

    Listen to the full episode to hear all of Richard’s tips on getting more value out of a backlog refinement session.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA107.mp3

    Z

    Your Homework

    Use visualization as much as possible. This includes having a visual roadmap, making the architecture visible, and using techniques such as story mapping, empathy maps, wireframes, and other approaches. Bring those visualizations in to your refinement session to help create a shared understanding.

    Secondly, don’t follow the same pattern for every refinement session. Consider what you need to know in each refinement meeting and adapt your approach to meet that need.

    Finally, look at the patterns in your team during refinement sessions and see the downstream impacts. If the team experiences unfinished backlog items or other impacts, it may be an indication that you’re not going deep enough in you refinement discussions.

    Links mentioned in this episode:

    • Agile42 Website
    • Richard’s article on backlog refinement
    Richard Dolman

    Richard Dolman

    Agile pragmatist, coach, and trainer

    Richard’s professional passion is helping companies solve critical business and technology challenges and enabling collaborative, high-performing teams.

    He is an independent professional Enterprise Agile Coach and Trainer, currently working with agile42, LLC. He has been practicing Agile/Lean for 10+ years and is a Certified Scrum Professional (CSP), Certified Scrum Master (CSM), and PMI Agile Certified Practitioner (PMI-ACP).

    • X
    • LinkedIn

    Thank you for listening to the program

    To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

    Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA107: Backlog Refinement – From Misunderstanding to Collaborative Discovery appeared first on Mastering Business Analysis.


    Previous 1 15 16 17 18 19 28 Next

    Related Podcasts

    Making Sense with Sam Harris

    1

    Making Sense with Sam Harris Education
    Grammar Girl

    2

    Grammar Girl Education
    Good Life Project

    3

    Good Life Project Education
    Explain It to Me

    4

    Explain It to Me Education
    Team Never Quit

    5

    Team Never Quit Comedy
    Optimal Living Daily – Personal Development and Self-Improvement

    6

    Optimal Living Daily – Personal Development and Self-Improvement Alternative Health
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights