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:
    MBA133: What BAs Need to Know About Agile Aug 08, 2017
    Show notes

    In this episode, Kent McDonald helps us to dispel some myths and helps you discover what you need to know about working in an Agile environment.

    

    After listening to this episode, you'll understand:

    • Why Agile alone won’t get you better, faster, and cheaper
    • How a Business Analyst can play a valuable role in Agile
    • Why you shouldn’t focus on writing User Stories (and where you should focus)
    

    Show Notes

    There are a lot of myths and misconceptions when it comes to Agile. In this episode, Kent McDonald helps dispel some of those myths by sharing seven key things you need to know about agile.

    1. Agile is not a methodology. It is a mindset.
    2. There’s more to agile than just Scrum
    3. Analysis is still relevant
    4. Agile alone will not get you better, faster, cheaper
    5. Writing and slicing user stories is not the whole story
    6. Business analysts can be product owners
    7. Business analysts do not have to be product owners

    Listen to the full episode to hear all of Kent’s insights about Agile.

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

    Z

    Your Homework

    In your current role, look for ways to do your work iteratively and incrementally. Ideally, get feedback after ever iteration and use that feedback to adjust not only the product, but also your approach.

    Links mentioned in this episode:

    Beyond Requirements book

    Kent’s Book, Beyond Requirements

    • Kent’s website KBP.media
    • Article – 7 Things Business Analysts Need to Know About Agile
    • Kent’s Blog BeyondRequirements.com
    • Live lessons on Analysis Techniques for Product Owners
    Kent McDonald

    Kent McDonald

    Founder, Knowledge Bridge Partners

    Kent McDonald uncovers better ways of delivering value by doing it and helping others do it. His more than 20 years of experience includes work in business analysis, strategic planning, project management, and product development in a variety of industries. As the founder of Knowledge Bridge Partners, he helps organizations figure out the right things to do in their IT and product development work. He currently practices those ideas as Product Owner for the Agile Alliance. Kent is also the author of the book, Beyond Requirements.

    • 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 MBA133: What BAs Need to Know About Agile appeared first on Mastering Business Analysis.


    Lightning Cast: Requirements Quality Aug 01, 2017
    Show notes

    In this Lightning Cast, I discuss requirements quality – What is it and how you can increase the quality of your requirements.

    A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.

    Quality . . . I can’t tell you what it is, but I know when I see it.

    There’s a lot of talk about producing high-quality requirements but what does it really mean? Quality is a standard against which something is measured. It’s a degree of excellence or the ability to satisfy a need or expectation.

    When it comes requirements, people often talk about the characteristics of good requirements. The most common characteristics mentioned are: complete, concise, correct, clear, testable, traceable, and prioritized.

    • Are your requirements complete? Do they contain all the necessary information to convey a shared understanding?
    • Are they concise? Do they contain enough information but not too much information or unnecessary information?
    • Are they correct? Can they help us to achieve the right business outcome?
    • Are they clear and unambiguous? If you use terms like fast or user-friendly, those are ambiguous terms and open to interpretation.
    • Are the requirements testable? Instead of saying ‘fast’, you can say ‘the screen refreshes in 10 milliseconds.
    • Are they traceable? Do we know where those requirements came from and can we trace it to a higher need or goal?
    • Are they prioritized? Do we understand the value behind each one and are we able to make trade-off decisions?

    With user stories, we often talk about INVEST criteria. INVEST stands for independent, negotiable, valuable, estimable, small, and testable. There’s some overlap between regular requirements and user stories.

    Both are independent. User stories and requirements should be independent in that you should be able to implement each one without dependencies on others.

    Requirements and user stories are valuable. They generate some kind of desired outcome.

    They should both be estimable. They are well enough understood and small enough to be estimated. Additionally, both are small. They’re small so as to fit within a single iteration or least be completed quickly. We want to create things in small increments so that we can use feedback loops to adapt and adjust.

    Finally, both requirements and user stories are testable.

    Upon reflecting about the characteristics of good requirements, I started thinking about SMART goals. You may remember SMART stands for specific, measurable, achievable, realistic, and time bound. By making a slight change, we get SMART requirements.

    • Specific: They are clear, concise, and help us work towards a specific outcome
    • Measurable: They can be tested (possibly with metrics identified)
    • Achievable: The requirements are feasible and realistic. We have to consider the organization’s current capabilities and resources for this.
    • Results-focused: They are correct, traceable, lead to a higher goal, and help us to achieve a desired outcome
    • Time-bound: The cost of delay is understood. This leads to the ability to order your backlog or break a project into phases.

    In the end, high-quality requirements create a shared understanding. They help us get clarity on steps toward achieving a goal. You can spend months trying to craft the perfect requirements or you could spend very little time and do a quick and dirty requirement. Think about your goal. We need to focus on the outcomes, not just requirements.

    Do your requirements lead to the right objectives that help propel your mission and vision forward?

    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 Lightning Cast: Requirements Quality appeared first on Mastering Business Analysis.


    MBA132: Next Generation Competencies Jul 25, 2017
    Show notes

    In this episode, Kupe Kupersmith shares a new competency framework for the next generation of professionals in the project field.

    

    After listening to this episode, you'll understand:

    • Why the current environment requires new competencies
    • How focusing on four critical areas can lead to success
    • What to do to make your team and your customers awesome
    

    Show Notes

    The world is more complex and changing faster than ever. The skills and competencies that got you where you are today won’t get you to the next level.

    The Next Generation Competency Framework helps you to understand the skills and ways of working that will allow you to succeed in today’s environment. The framework combines four focus areas and key competencies within those areas:

    • See Opportunity: Having a customer focus and applying approaches that help identify opportunities and discover real value
    • Decide Smarter Faster: Focusing on approaches that will help you learn quickly, make good decisions, and manage risk
    • Engage for Buy-In: Using improv and other playful inquiry techniques to have fun while developing better engagement
    • Evolve the Culture: Developing relationships and an environment that contributes to success

    Next Generation Competencies

    Listen to the full episode to hear all of the details about this Next Generation Competency Framework.

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

    Z

    Your Homework

    Reframe the work you do to center around decisions. With the work that you’re doing, how are you helping someone make a decision?

    You’re helping people make decisions about priorities and opportunities to go after. Figure out the criteria people need to make that decision. That should drive the work you do.

    Links mentioned in this episode:

    • Kupe’s Website KupeTalks.com
    Kupe Kupersmith

    Kupe Kupersmith

    As the founder of KupeTalks and Atlanta Engagement Director, Market Rate Consulting, Kupe’s main objective is to help you connect, collaborate, and be ready for the future. For the past 20 years, Kupe has been helping organizations achieve business value with an improvisational advantage.

    Kupe is an author, keynote speaker, coach and a trained improv actor. Some think Broccoli & Cheetos is an odd combination, but you will be delighted with Kupe’s combination of laughter and learning. Kupe is a connector and has a goal in life to meet everyone!

    • 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 MBA132: Next Generation Competencies appeared first on Mastering Business Analysis.


    Lightning Cast: The Agile Business Analyst Mindset Jul 18, 2017
    Show notes

    In this Lightning Cast, we explore the mindset shift needed to be successful as a Business Analyst in an Agile environment.

    A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.

    How can a Business Analyst be successful in an Agile environment? We can use a lot of the same tools, techniques, and approaches that we would use in a traditional environment. By adopting a different mindset, we apply those tools in a different way.

    Using lean and Agile approaches, we’re able to iterate by delivering smaller chunks and get feedback along the way so that we can adapt to changing customer needs.

    What is Agile?

    Agile isn’t quite a methodology, although when the signatories of the Agile Manifesto got together to create it, they called that meeting the Lightweight Methodology Conference. At its root, Agile is a way if working. It’s a set of four values that guide why we act the way we do and 12 principles to guide what we should be doing. Those principles and values are supported by a series of practices and frameworks such as Scrum and Kanban to help us understand how will achieve some of those outcomes.

    Underlying it all is the mindset. Without the right mindset, we follow the rules but don’t understand why you’re doing it. It’s like learning to dance versus learning martial arts. When you learn dance, you learn the movements but you don’t understand why. In martial arts, every movement has reason. Every movement is to achieve a singular outcome.

    The Traditional BA Mindset

    What is the Agile Business Analyst mindset? First, let’s take a look at the mindset of a traditional waterfall Business Analyst. If we look inside the mind of a traditional Business Analyst, we see that they have a drive towards documentation. They want to make sure everything is very clearly documented to create a common understanding with our customers. We need those documents to help our customers understand what will build for them and ensure that we’ve accurately captured their needs.

    Traditional BAs also need those documents to share with the software engineers so that they can build an appropriate solution. Good documentation may be made up of models, use cases, and various other forms to convey a shared understanding.

    Traditional Business Analysts also need to manage change. They want to be able to control change so that the change still remains within the scope of the project and doesn’t get out of control. As a result, we create a lot of processes around managing that change such as change review boards and change requests.

    Customer needs are always top of mind for traditional Business Analysts. We need to sort out the needs from the wants and make sure that we’re delivering a solution that meets those needs.

    Because we focus on the needs and manage change, we create a full design up front. We don’t move forward until we have all the information to go to the next stage. We need all the details so that we’re able to see the big picture and to move forward.

    As a traditional Business Analyst, I do my job and I do well. My job is to discover the user requirements, document them, and ensure an appropriate solution is delivered.

    In order to deliver that solution, I need to analyze everything. We analyze the current conditions, organizational capabilities, and information that we’ve gleaned from user interviews and other organizational assets. From that analysis, I’m able to synthesize a set of requirements which I deliver to our software engineers to create a solution.

    The Problem

    That mindset and approach works in a traditional waterfall environment. People can be very successful doing that type of work. The problem is something that I call the Success Paradox.

    Is being successful at something holding you back from being really exceptional something else?

    The Agile BA Mindset

    Let’s make a shift and look at the mindset of an Agile Business Analyst.

    Instead of focusing on documentation, Agile Business Analysis realize that conversations matter. Written documentation is one of the worst forms for conveying information. It opens to door for different interpretations and misunderstandings. Realizing that conversations are more important than documentation is a key mindset and it’s one of the reasons why we apply user stories.

    User stories and very small and don’t contain all the information. The details are in the conversation. Remember that user stories are just a placeholder . . . a reminder to have a conversation in the future or a reminder of a conversation that has already occurred.

    In a traditional environment, you want to manage change. In an Agile environment, you expect change. You know that changes can happen and in Agile we harness change for the customers benefit. We want to be able to adapt based on customer feedback and deliver the right solutions that are meaningful to the customers, not create shelfware.

    Because we expect change to happen, we develop solutions in small increments and iterate as we go based on that feedback.

    At top of mind is always customer value, not just the needs and wants. We understand the true value that customers get out of the solution. This implies that we understand what the customer wants and needs, but it goes beyond that. It involves exploring various options, discovering needs that customers weren’t able to articulate, and being able to prioritize work based on that value.

    Because of that customer focus and expectation of change, we do just enough just in time. Instead of getting a big design up front before we move along, we work in small increments doing just enough just in time.

    Getting into the details too soon is actually waste because we seek feedback and adapt along the way. If we work too far ahead, that information may change as we go and we will learn new things. As a result, some of the detailed analysis and planning we did is wasted effort.

    Of course, we need to understand the big picture at a high level. But for the details, do just enough just in time.

    In a traditional environment, I do my job and I do it well. In an Agile environment, we adopt a team focus. That means I need to stretch my skills, step outside my role, and see what kind of support the team needs. That may be helping a product owner with some customer discovery or helping the testers. I likely won’t be as good as a tester in testing the software, but I can provide support where the team needs.

    We develop fungibility. In the context of an Agile team, fungibility means that I develop my skills so that I can help other team members. On an Agile team, we succeed or we fail as a team. We all need to step outside our role and help each other.

    Finally while analysis is needed, we have a bias towards action. We do just enough analysis just in time and then take action. Similar to the Plan Do Check Act loop from W Edwards Deming, we do a little bit of planning and then build something. You then check the impact of what you built through customer feedback and adapt yourapproach based on that feedback.

    We need to take action! Small, incremental action and then get feedback and adapt along the way.

    The Agile BA Mindset

    Make the Shift

    The real challenge is making that mindset shift. One way to do that is to consider the six concepts of an Agile BA mindset:

    1. understanding that conversations matter
    2. expect change
    3. focus on customer value
    4. do just enough just in time
    5. have a team focus
    6. have a bias towards action

    Think about what the six components mean to you in your role and put them into practice.

    Listen to this lightning cast to hear more about the mindset shift for success in an Agile environment.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBALC002.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 Lightning Cast: The Agile Business Analyst Mindset appeared first on Mastering Business Analysis.


    MBA131: Interviewing for a Business Analyst Position Jul 11, 2017
    Show notes

    In this episode, Laura Brandenburg helps us prepare for interviewing for a Business Analyst position.

    

    After listening to this episode, you'll understand:

    • How to prepare for an interview for a BA position
    • What kind of questions to expect
    • How to address some of the tricky questions in an interview
    

    Show Notes

    One of the first steps in preparing for a business analyst interview is understanding the types of interviews and what your interviewer is seeking from each. With this knowledge, you can come prepared with the right type of focused answers and be confident in your delivery.

    The initial interview will often be a phone screen with the recruiter. These interviews are often short (30 minutes or less) and are focused on your experience and work history. The goal of the recruiter is to determine if you have the prerequisite skills, knowledge, and experience required for the position.

    To prepare for this interview, review the job posting and qualifications for the position and think about how your experience demonstrates the necessary qualifications and duties. Be aware that recruiters often may not use the same industry terms you’re used to, so using the language from the posting or explaining how your experience is relevant will be key.

    Behavioral Interviews

    Provided that you make it past the initial phone screen, you will likely interview with someone in the organization who understands business analysis and the specific role more deeply. Questions in this interview usually focus on your experience, culture fit, and behavioral interview questions.

    Behavioral interview questions and the “Tell me about a time when . . .” questions where the interviewer is looking for a real situation in your past and what you did in that situation.

    To answer behavioral questions, use the Situation, Action, Result approach. Tell the interviewer about the situation that matches their question, explain what action you took because of that situation, and what the result was. Keep your response to five minutes or less and be prepared for follow-up questions.

    Examples of behavioral interview questions include:

    • Tell me about a time when you had to deal with a challenging stakeholder
    • Tell me about a time when you had to put the goals of the team above your own
    • Have you experienced a time when there were competing priorities on a project?
    • Tell me about a time when you had to manage unrealistic expectations

    To prepare for this interview, review the posting and come up with three or four situations that will likely relate to common questions.

    Listen to the full episode to understand how to prepare for different types of interviews and how to really impress your interviewer. You’ll also find out what not to do during your interview.

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

    Z

    Your Homework

    Prepare for your interview by not only thinking about what you’ll say, but also practicing what you’ll say out loud. You can also role play with a friend or record yourself prior to the interview and adjust what you’ll say in the real interview.

    Links mentioned in this episode:

    • Laura’s website, Bridging the Gap
    • How to Start a Business Analyst Career and other books by Laura Brandenburg
    • Laura’s Interview Prep Guide
    Laura Brandenburg

    Laura Brandenburg

    Bridging The Gap

    Laura Brandenburg is an internationally-recognized leader known for helping mid-career professionals start business analysis careers. Laura brings more than a decade of experience as a full-time business analyst to help you find transferable BA skills, expand your experience, and start your business analyst career with confidence. Laura is also the author of How to Start a Business Analyst Career.

    • 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 MBA131: Interviewing for a Business Analyst Position appeared first on Mastering Business Analysis.


    Lightning Cast: The Business Analyst Career Path Jul 04, 2017
    Show notes

    In this Lightning Cast, we discuss the Business Analyst career path. It might not be what you expect.

    A Lightning Cast is a shorter form episode modeled after lightning talks. You’ll get valuable content in 8 minutes or less.

    I’m often asked what the Business Analyst career path looks like. A common misconception is that your career is a straight line where in reality, there are many twists and turns.

    The question is what does career growth mean to you?

    Career Growth for a Business Analyst

    Career growth isn’t necessarily just moving up. It can include things like lateral moves. We can move from one position to another at the same level. These moves give you a variety of experienced and allow you to grow and develop new skills.

    Career growth also includes the traditional path of moving up to higher level roles. That can be from business analyst to senior business analyst to business architect. Each stage will require development of new skills and the ability to expand your influence. You will likely need to move from tactical to strategic to offer greater benefits your organization.

    Sometimes career growth involves relocation. You may need to move outside your company or to a different facility within your organization to explore different career opportunities. Be careful with this because you don’t want to be seen as a job hopper. You want to stay with the role long enough to develop good skills and foundational practices. This usually takes 18 months to two years.

    Career growth may also involve exploring your current role. Explore the edges and parameters of your role as well as related roles. If you’re a business analyst, that may include working with and exploring roles such as project manager, product owner, and user experience designer. By working closely with people in these roles, you can pick up some of the techniques, skills, and practices of those roles. That allows you to further develop and enhance your skill set.

    One thing that people often don’t consider is that true growth also includes realignment. That may mean taking a step down from your current role to explore a different role. For example, if you’re a senior business analyst and want to explore project management, it might not be a lateral move to senior project manager. You may have to start at the bottom of that role. However, if you can apply the skills and techniques you’ve developed is BA, you can likely accelerate your growth and career trajectory.

    Finally, career growth may include enrichment. That means staying within your role and developing those core skills that make you great. For a Business Analyst, that might mean developing your elicitation techniques, communication skills, facilitation, and influence.

    You may feel that your career is going through peaks and valleys and even plateau at some point. Those plateaus are enrichment opportunities . . . a way for you to develop your skills in the foundational practices. Think of it as a platform where you can jump to a higher level.

    The Train Map

    I like to think of the BA career path not as a straight line, but as a train map with different stops, stations, and transfers along the way. I consider four different starting points:

    1. A traditional business analyst aligned to the business side and works in a traditional environment
    2. Business analyst in an agile environment
    3. Business systems analyst aligned to the technology group
    4. Project management

    BA Career Path

    The traditional business analyst may go from BA to senior business analyst, to architect, to senior business architect and so on. Similarly, in an agile environment you may go from business analyst to product owner and possibly branch off to managing a team and then PMO director. From there, you may climb to vice president, senior vice president, and CIO.

    A Business Systems Analyst may become a senior analysts and then a technology architect or an enterprise architect. From Project Manager, you may go to senior project manager, to program manager, to business owner, and so on.

    One path isn’t necessarily better than the other. There are a variety of different options you can explore.

    To continue in the train analogy, to get to each of the stops and transfer between stations, you need to buy a ticket. Each of those tickets will require you to develop different skills.

    As I mentioned earlier, to get from a senior business analyst to a business architect, you’ll need to switch from tactical to strategic, from inward focused to outward focus, and have a holistic view of the organization. To shift from business analyst to product owner, you need develop different leadership skills, have a customer focus, and decision-making authority.

    As you move up to higher levels in the organization, you will need to move outside the project box and think more holistically to contribute more value to your organization.

    What’s your desired destination and what does it take to get there?

    http://traffic.libsyn.com/masteringbusinessanalysis/MBALC-Career_Path.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 Lightning Cast: The Business Analyst Career Path appeared first on Mastering Business Analysis.


    MBA130: Exploring Requirements with Jerry Weinberg Jun 27, 2017
    Show notes

    In this episode, author, consultant, and thought leader Jerry Weinberg shares his thoughts on the challenges with software requirements and why we need to take requirements seriously.

    

    After listening to this episode, you'll understand:

    • Common problems with requirements elicitation
    • How to avoid too much upfront detail in requirements
    • The impact of not taking requirements seriously
    

    Show Notes

    We need to start taking requirements seriously. The impact of missed requirements can cost organizations millions and damage reputations.

    The problem is actually a people problem. Communication, collaboration, and the ability to properly use techniques such as observation will help address some issues.

    Don’t get more detailed than you need to for the situation. Doing so artificially constrains creativity to develop a solution.

    Listen to the full episode to hear Jerry’s views on the challenges associated with software requirements and what to do about it.

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

    Z

    Your Homework

    Start talking requirements seriously. Explore options and impacts to understand your requirements. Finally, iterate on your requirements. You can’t know everything upfront.

    Links mentioned in this episode:

    • Jerry’s Website GeraldMWeinberg.com
    • Author page on Amazon
    • Author page on Leanpub
    Jerry Weinberg

    Jerry Weinberg

    Author, Teacher, Consultant

    For more than half a century, Jerry Weinberg has worked on transforming software organizations, particularly emphasizing the interaction of technical and human issues. After spending between 1956 and 1969 as software developer, researcher, teacher, and designer of software curricula at IBM, formed the consulting firm of Weinberg & Weinberg to help software engineering organizations manage the change process in a more fully human way.

    Jerry has published more than 40 books and more than 400 articles including books on quality software management, systems thinking, and requirements.

    • 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 MBA130: Exploring Requirements with Jerry Weinberg appeared first on Mastering Business Analysis.


    MBA129: Real Life Agile, UX, and Design Thinking Jun 20, 2017
    Show notes

    In this episode, Brent Severson shares how he has successfully integrated Design Thinking, User Experience Design, and Agile into his BA practice to make himself valuable to teams working in the digital space.

    

    After listening to this episode, you'll understand:

    • How combining Agile, UX, and Design Thinking can increase the value you provide to organizations.
    • Why discovery and feedback approaches from UX and Design Thinking help you build the right solution.
    

    Show Notes

    Listen to the full episode to hear how Brent applied all of these disciplines to provide more value to his organization.

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

    Z

    Your Homework

    Seek out some UX or design professionals in your organization and ask how you can help them with their project definition work. Also, start building a portfolio of your work to showcase the type of work you can do for organizations (excluding confidential and proprietary information out, of course).

    Finally, take an online course in UX design and seek out local design associations and meetups to expand your knowledge in this area.

    Links mentioned in this episode:

    • Long story short podcast
    Brent Severson

    Brent Severson

    Business Systems and Process Analyst / Business User Consultant

    Brent places user-centered design needs at the heart of the SDLC story by leveraging over two decades of experience in business analysis, IT operations, and consulting on process management. He leverages business analysis tools to define and create concepts that demonstrate when users feel good about their interactions, the business sees successful conversions and value follows naturally.

    Brent has successfully integrated Design Thinking, User Experience Design, and Agile to make himself valuable to teams working in the digital space.

    • 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 MBA129: Real Life Agile, UX, and Design Thinking appeared first on Mastering Business Analysis.


    MBA128: Where Should the Business Analyst Reside? Jun 13, 2017
    Show notes

    In this episode, Lora McCoy shares her views on where business analysts should reside in an organization to enable better collaboration, growth, and prevent solution bias.

    

    After listening to this episode, you'll understand:

    • Why the right organizational placement is important to project success
    • The pros and cons of BAs reporting to IT, the business, or independent from both
    • How a Business Systems Analyst differs from a Business Analyst
    • Why organizational placement leads to biases
    

    Show Notes

    What’s the right organizational structure that allows business analysts and other project roles have the greatest impact?

    Some organizations have people assigned to Information Technology (IT), some have a pool of Business Analysts from which to pull for projects, and some have people assigned to specific business areas. Each of these structures have benefits and drawbacks.

    Business analysis is intended to be a strategic function. As such, what’s the optimal organizational placement for Business Analysts?

    Alignment with Technology

    The most common structure is to align Business Analysts to the IT group.

    The advantage with this approach is that Business Analysts understand the technical capabilities and feasibility of solutions. They can offer technical solution options and easily relay information to software engineers about the solution requirements.

    Despite these advantages, there are a number of disadvantages that make alignment with the IT group less than ideal.

    When you’re aligned with IT, every problem gets solved through technology. This is the case even when the best solution isn’t technology based. Perhaps the real problem can be solved by a simple process change or better communication. This type of bias leads to sub-optimal solutions.

    When working with business teams, BAs aligned with IT are seen as outsiders. As a result, some business subject matter experts (SMEs) may become defensive and reluctant to share all relevant information with you.

    Alignment with the Business

    For Business Analysts imbedded in the functional areas of the business, they can develop a deep understanding of business processes and functions.

    With a network of SMEs with whom you’ve developed a relationship, it’s easier to influence change.

    There are several disadvantages with aligning the BA role with the business.

    Because you’re so imbedded with the business functions on a daily basis, it’s difficult to think holistically. As a result, upstream and downstream impacts of changes may be missed. Additionally, you may be unable to see innovative or disruptive solutions because you’re too close to the problem.

    Additionally, BAs aligned to the business are often less familiar with technology. When you work with the technology group to recommend solutions, they may be reluctant to consider your solution recommendations because you’re seen as an outsider.

    Bridge the Gap from the Gap

    Instead of alignment with IT or the Business, being part an objective, strategic group outside of both of those areas brings together the best of both worlds.

    With alignment outside both IT and the business, you can learn just enough of both areas to avoid bias and see the problem holistically. You can be seen as a partner and an internal consultant.

    This allows you to be objective and challenge both areas while offering an objective viewpoint. This gives you the potential to be seen as an expert and better influence change.

    The challenge with this type of strategic alignment is that is can be difficult to manage. It takes an organization at a certain level of maturity and openness to learning.

    Listen to the full episode to understand the benefits of this organizational structure, how it impacts your personal development, and the different types of BA roles,

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

    Z

    Your Homework

    The first action is to understand your organization’s culture and current level of maturity of business analysis practices. How does the organization see change? Is it ready for shifting its structure for the BA placement approach outside of both IT and the business?

    You’re working toward a Center of Excellence, so you need to understand your organization’s current state. From there, influence leaders on making the culture shift to create the right placement for your Business Analysts.

    Links mentioned in this episode:

    • LMc3 Consulting on Facebook
    • Business Analyst World Chicago
    Lora McCoy

    Lora McCoy

    Founder, LMc3 Consulting

    Lora McCoy is the Founder and Principal Consultant of LMc3 Consulting, an organization focused on assisting organizations and individuals in understanding the “right” change at the “right” time while ensuring the change is enabled for the “right” reasons.

    Lora is also the president of the IIBA Oklahoma City Chapter of the IIBA and a frequent speaker at industry conferences.

    • Facebook
    • 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 MBA128: Where Should the Business Analyst Reside? appeared first on Mastering Business Analysis.


    MBA127: Guiding Principles for the Business Analyst – part 2 Jun 06, 2017
    Show notes

    In part 2 of this interview, author and consultant Steve Blais shares with us the remainder of his 11 principles of the business analyst, which provides guidance as to what a business analyst should do to achieve success.

    

    After listening to this episode, you'll understand:

    • How to apply Miller’s Law for better elicitation
    • Why transition requirements are as important as solution requirements
    • How to focus on benefits realization
    • Why some Agile leaders believe a BA isn’t needed
    

    Show Notes

    This is part 2 of a two part episode. To listen to part 1, click here. Part 1 covered the first four principles which are:

    • Principle 1: Focus On the Product
    • Principle 2: First Define the Problem and Then the Solution
    • Principle 3: Users Do Not Have Requirements
    • Principle 4: Focus On Information Not Individuals

    Principle 5: Separate Elicitation from Analysis

    When you elicit information, don’t analyze. When you’re analyzing, don’t add new information.

    If we analyze information by asking analytical questions as we’re receiving information, the stakeholder will feel judged. In this case, you’ll receive less information and people will be less forthcoming in sharing their knowledge.

    We don’t want to do anything that would be detrimental to the flow of information.

    Instead, apply Miller’s law which states “If you truly want to understand what a person is saying, first assume that it’s true and then try to find out what it is true of”.

    Failing to apply this principle could lead to biases, assumptions, and incorrect or missing information.

    Principle 6: Improve the Process First, Then Add Technology

    Often, the solution to the problem is not a technology solution. It may be a communication or process issue, in which case a technical solution won’t solve the problem.

    Look for a non-technical solution first.

    We should also come up with more than one potential solution to a problem. By doing so, we’ll be forced to look at other options (including non-technical solutions) and avoid confirmation bias.

    Principle 7: Communicate, Cooperate, Collaborate

    The Business Analysts primary job is a communicator and collaborator. That’s how you solve problems.

    Constant communication, collaboration, and betting input is critical to success as a Business Analyst. This also helps in the areas of negotiation, influence, mediation, presentations, and conflict resolution.

    You’ll be much more successful if you work collaboratively with others. Don’t let documentation substitute for communication and collaboration.

    Principle 8: The Business Analyst Owns the Solution Requirements

    We need to adopt the mindset that we own the requirements. No one can change the requirements except you.

    Ownership of the requirements includes the responsibility if something is wrong.

    Principle 9: Gain Acceptance As Well As Approval

    Get confirmation of all of the requirements prior to seeking approval. Once you’ve discussed and confirmed the requirements with stakeholders, then you can request approval from those with authority to approve the requirements.

    Often, requirements approvers will seek input from those stakeholders before submitting their approval. Gaining acceptance of your requirements prior to asking for approval makes the approval process easier.

    Principle 10: Make the Business Community Ready For the Product

    Don’t forget about transition requirements. Consider what is needed to make sure the business or customer is ready to use the solution.

    Transition requirements may include training, documentation, and creating awareness in addition to a change management process. We need to prepare the user for the solution before we implement it.

    Principle 11: Measure Twice, Cut Once

    As Business Analysts, we want to measure, cut, and then measure again. We need to understand the problem and identify metrics to determine outcomes, implement a solution, and then measure those areas again to see what kind of an impact the solution had.

    Benefits realization is a key focus for successful Business Analysts. Before we implement a solution, we need to understand how to measure success and track those metrics before and after we implement the solution.

    There are several categories of measurements you may use to determine the impact of your solution including intrinsic, satisfaction, and value measurements.

    You’re job isn’t about writing requirements. It’s about making improvements to the business. The way you show the improvement is by measuring it before the solution and them measuring after.

    Listen to the full episode to understand how to apply the 11 principles in your role and why some people believe a BA isn’t needed in a Agile environment.

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

    Z

    Your Homework

    Focus on critical thinking and apply Miller’s Law. You can do this by asking questions about your own thinking. Doing so not only improves the quality of your thinking, it also helps remove biases. Building your critical thinking skills also helps improve your problem solving and decision making ability.

    Links mentioned in this episode:

    • Episode 126 – Part 1 of this interview
    • Steve’s website EssenceoftheBA.com
    • Get Steve’s book, Business Analysis: Best Practices for Success
    Steve Blais

    Steve Blais

    Author and Consultant

    Steve Blais is an author and consultant with almost 50 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. Steve was on the committee for the IIBA’s BABOK Guide version 3.0 and is the author of Business Analysis: Best Practices for Success.

    • 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 MBA127: Guiding Principles for the Business Analyst – part 2 appeared first on Mastering Business Analysis.


    Previous 1 13 14 15 16 17 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