Mastering Business Analysis

In this episode, Bob Prentiss shares some hard truths about what we must be to achieve success in business analysis and other endeavors.  After listening to this episode, you'll understand: The hard truths we need to understand to achieve success How to overcome discomfort and have crucial conversations Why it’s important to be intelligently disobedient Why knowing yourself is the first step in building a relationship with others  Show Notes Bob’s teaching approach is about sharing little slices of bigger truths that allow us to think differently so we can learn and work differently. Those truths go beyond the theory you’ll find in many books and allows people to apply the meaning to their own situations. These big truths are life lessons; advanced competencies to allow you to expand your leadership and job specific skills.   Crucial Conversations Most people shy away from difficult conversations, but it’s those crucial conversations that are key to changing behaviors that are impeding progress. You need to have the courage and openness to discuss difficult topics. The truth behind the myth is that not everything is solvable. Having the conversation will often help, but go into it with an understanding that not everything is repairable.   Get Comfortable with Discomfort These crucial conversations often make us feel uncomfortable. We need to be able to feel that discomfort and do it anyway. Having a mentor, coach, or someone you can bounce ideas off of helps you overcome the discomfort. Having a strategy is also key to success. Having heroes or an imaginary mastermind group can give you insights and confidence to handle difficult situations.   Intelligent Disobedience Sometimes we may need to disobey requests from managers or stakeholders if it’s not the right thing to do. If you’re not being intelligently disobedient at least once a week, you’re probably doing a disservice to your organization. The key word is “intelligently”. This requires you to think strategically, understand impacts, and have those difficult conversations. Don’t blindly follow orders; think through the consequences and do the right thing. Follow the value systems of your organization.   Stretch Open your mind to create your own path and push your boundaries to know what you’re truly capable of. To grow, you need to be able to influence your organization to accept progress over perfection. Having strong relationships and a support system in place will allow you to stretch yourself safely. Create a safe to fail environment where you can experiment, learn, and grow.   Listen to the full episode to hear all of Bob’s conversation about hard truths that you need to understand to take you career to the next level. http://traffic.libsyn.com/masteringbusinessanalysis/MBA075.mp3   Homework Notice everything! Expand your awareness and start noticing everything around you. This includes people, how they are behaving, and anything new. Having a greater awareness gives you the data to build better relationships. Strong relationships is how work gets done.   Links mentioned in this episode: Bob the BA Website Get Bob’s book Bob’s previous episode       Bob Prentiss Bob the BA Bob the BA provides badass business analysis training, consulting and mentoring services. Bob is passionate about helping you think, learn and work differently. Bob is CBAP® certified with 25+ years of experience in corporate America; with a background in managing BA centers of excellence, assessing and managing BA maturity, quality, and competency. Bob is an award winning curriculum developer and has presented numerous keynote, workshops, seminars, conferences, and training sessions across North America. He is also founding member and past President of the IIBA® MSP Chapter. TwitterLinkedIn 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. 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. The post MBA075: Slices of Big Truths appeared first on Mastering Business Analysis.

In this episode, Luke Johnstone helps us to eliminate waste in our BA practices using Lean Business Analysis.    After listening to this episode, you'll understand: Why the four values of the Lean Business Analysis Manifesto are so important The 8 forms of waste in analysis How to combat those forms of waste  Show Notes Lean business analysis is about doing the right thing at the right time and removing things that don’t add value. Those non-value add activities are referred to as waste. To help business analysts better align to Lean principles, Luke and his organization created the Lean Business Analysis Manifesto with the following four values. Producing what is needed when it’s needed versus doing all of the analysis upfront Working with the right people at the right time versus working in silos Building quality in from the outset versus checking for quality at the end Avoiding unnecessary steps that don’t add value versus following a prescribed process Having a Lean mindset helps us to avoid some anti-patterns that lead to waste. These eight forms of waste are: Unfinished work – Analysis or requirements completed but not implemented Unnecessary features – Features customers don’t need or want Silos and handoffs – Working without a shared understanding and transitioning work items Unnecessary processes – Steps that don’t add value Context switching – Moving from one task to another without focus Waiting – Delays due to waiting for an answer or availability Rework – Work that needs to be done over Knowledge hording – Keeping knowledge to yourself In this interview, Luke discusses these forms of waste in detail and shows us some tools and techniques to eliminate the waste.   Listen to the full episode to hear all of Luke’s advice for eliminating waste in your BA practice. http://traffic.libsyn.com/masteringbusinessanalysis/MBA074b.mp3       Z Your Homework Reflect on your analysis practices and create a value stream map of your process. Doing so helps you to identify value add and non-value add activities. Then, try to eliminate of reduce the amount of non-value adding activities. Links mentioned in this episode: Luke’s company website Assurity Impact Mapping Luke’s Presentation from Agile NZ   Luke Johnstone Lean Business Analysis at Assurity Luke has led Assurity’s Christchurch-based Lean Business Analysis Service for three years and has recently been appointed their National BA Service Owner. He is an outcome-focused, commercially astute Agile Business Analyst with significant experience in Business Analysis, Software Development projects, leading IT projects/teams and organization-wide Change Management. TwitterLinkedIn 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. 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. The post MBA074: Lean Business Analysis appeared first on Mastering Business Analysis.

In this episode, Barbara Carkenord helps us understand the difference between requirements in agile and waterfall and how to be successful with agile requirements.    After listening to this episode, you'll understand: How requirements in agile environments differ from waterfall requirements The shift that you need to make to be successful with agile requirements How to overcome perfectionism What to do if the details aren’t needed right now  Show Notes What’s the difference between requirements in an agile environment versus a waterfall environment? Not much . . . and a lot. On one hand, agile requirements approaches are very similar to traditional approaches. You still need to analyze, facilitate, use good listening skills, and manage the requirements. On the other hand, agile requirements differ in that the traditional, heavy documentation becomes a lot less important. We need to shift our thinking to focus on requirements as an analytical, thinking process. It’s more about discovery and collaboration than about documentation. You’ll still document requirements in agile, you’ll just likely do so in a lightweight way such as starting with Post-Its or using a flipchart. Think about documentation in more creative ways.   Audit Considerations If you’re concerned that audit needs more comprehensive documentation, work to understand their true needs. Ask the ‘why’ questions to the audit department, leadership team, PMO, or whoever is asking for extensive documentation. This approach helps shift the thinking in your organization and helps everyone to understand what is truly needed and the value that an output provides. Asking questions about why documentation is needed and the value can help you to produce what is needed to the extent required to deliver the expected value. Instead of making assumptions, look at what’s actually required, why, and look for creative ways to meet that need.   The Difference with Agile Most of the tools and analysis techniques you use in waterfall environments are still valuable and useful in agile. With agile, many of the business analysis techniques can be same, but the timing and approach may be different. You will likely still need to perform a current state analysis to understand your starting point. The difference will likely be in how much you need to document and in what format. The key to success with agile requirements is to know when to keep things at a high level and when to get into the details. Agile requirements and documentation should be barely sufficient; just enough to meet the needs of the team and the organization. Anything more is wasted effort. Remember that your outputs don’t always need to be perfect. Do just enough to meet the need and create a shared understanding. Force yourself to let go of perfectionism when it doesn’t add sufficient value. Requirements should also be completed at the last responsible moment. If we create requirements too far in advance, things will likely change and your effort would have been wasted. Often a scrum team will have 1-2 sprints of ready stories and the BA is working slightly ahead to refine the user stories. You’ll need to balance your time between working slightly ahead of the team and helping the team in the present moment with and questions or issues. Focus your effort on the most important thing you can do right now today. Know what can wait and know what can benefit from waiting because you’ll learn along the way and may have more information later. Keep in mind that things may change and doing too much upfront can be wasted time. When you come across ideas that are too soon to discuss, have an organization system for future ideas. It’s important to know when to be detailed and when to keep things at a high level. You’ll need strong analysis and facilitation skills to bring the team through cycles of discussing high level requirements, diving into the details when the team needs to, and then pulling everyone back up to the high level. Get comfortable with letting conversations take place until you cover the topic just sufficiently to create a shared understanding. A parking lot or other lightweight ways of capturing thoughts and ideas can help you rein the group back in. This gives the group a level of comfort that their comment or idea will not be lost. Of course, you’ll need to eventually go back to that topic when you need to.   Listen to the full episode to hear all of Barbara’s tips and advice on succeeding with requirements in an agile environment. http://traffic.libsyn.com/masteringbusinessanalysis/MBA073.mp3   Z Your Homework Keep asking yourself if what you’re working now needs to be done perfectly or if you can let go of some of that perfection. Work to understand what level of detail is needed to achieve the desired outcome and what value it provides.   Links mentioned in this episode: Barbara’s website, RMC Learning S

In this episode, author and coach Leslie Stein helps us to discover the keys to successful facilitation.  After listening to this episode, you'll understand: The difference between leading a meeting and facilitating Why it may be better if you don’t know the subject matter How to deal with multi-taskers How large group facilitation is different than small groups  Show Notes Most people have misconceptions about facilitation. Good facilitation looks like nothing. Facilitation is a gentle guiding of people in the room and creating a container where they can do the work that needs to happen. Being a successful facilitator requires some upfront preparation work to get the best out of people when they come together. Understanding why you are coming together and allowing people to share information. It’s like being able to get everyone to put their pieces of the puzzle on the table and together create a picture.   The Most Important Skills The two most important skills needed to be a successful facilitator are curiosity and the ability to find patterns. Being generously curious and asking great questions allows you to uncover information people don’t realize is important. It also sets the tone for the meeting and allows people to be more open in their communication. The ability to notice patterns may allow you to see things emerging before the rest of the group. This allows the facilitator to redirect the group or ask a pointed question to refocus everyone on the goal. To do this, the facilitator should not be a contributor to the conversation aside from helping the group communicate and discover information. Facilitation is about the process, not the topic. You don’t need to be an expert (or know anything) about the topic content.   The Key One of the biggest keys to facilitation is helping the group understand the purpose of why they are coming together. Help attendees understand why they should attend the meeting and how they can contribute. A lack of clarity on the purpose may lead to other issues such as people multitasking or failing to attend the meeting. A Purpose Statement answers the question “Why are we here?” and the Goal is an expression on the expected outcome of the meeting. The purpose is the North Star that keeps everyone on track when they stray away from objectives. A good purpose statement should have three qualities. Be short: The length should be 1-2 sentences Be testable: you should be able to test whether or not you achieved the purpose and expected outcomes. This can be done with a simple thumbs up or thumbs down vote. Be resonant: The purpose must be something worth spending time on. If you have a strong purpose statement, attendees will know how they can contribute to the purpose of the meeting.   How to Prepare To prepare for your next facilitation opportunity, give attendees the POW. Include in the invitation the purpose, outcomes, and what’s in it for my (WIFFM). The outcomes should express the expected result of the meeting and the what’s in it for my (them) helps attendees understand how they will benefit from engaging in the conversation. The POW helps keep everyone focused and on track to achieve the meeting objective. Near end of the meeting, leave enough time to test whether or not the purpose and outcomes were achieved and address any concerns from attendees who don’t think the group achieved the purpose. For shorter meetings (about one hour), this can be done in 5-10 minutes. The longer the meeting, the more time you’ll need for this test and wrap-up step. Without a good facilitator, dysfunctional behaviors will likely come up in the meeting. This may include dominating personalities, silence, multi-tasking, and more. People will leave without accomplishing goal and feel that their time was wasted.   Large Group Facilitation The larger the group, the more you need to give up control. You can’t possibly be involved in every conversation and you’ll need to trust the group to have the appropriate discussions. One approach to large group facilitation is Changing Frames. To change frames, start with a whole group discussion to get some initial inputs and then shift to small groups to continue the conversation. Give those small groups specific instructions such as having them answer a specific question. This allows everyone to have a voice and provide input. If you need to collect a lot of data in a short time, you can use the Rotating Flipcharts approach. Start by parsing out the topics and have small teams go to one of the flipcharts. Allow the teams 5-10 minutes to work at a flipchart and then rotate to the next flipchart. When they see what the previous team at the flipchart wrote, they can add a check mark if they agree and an ‘X’ if they disagree before adding their own thoughts.   Listen to the full episode to hear all of Leslie’s tips for better facilitation. http://traffic.libsyn.com/masteringbusinessanalysis/MBA072.mp3

In this episode, Jonathan Babcock helps us to understand the essence of business analysis and how though a better understanding the principles behind this essence, you can improve your performance.  After listening to this episode, you'll understand: Where the true value of business analysis lies How understanding the essence of business analysis leads to more meaningful ways to measure performance  Show Notes Why does business analysis exist? What is the underlying essence of the analysis activities? Many people confuse the role with the associated tasks such as stakeholder management and requirements elicitation. Business Analysts who confuse the essence of the role with the tasks they need to complete will fail to reach new levels of performance. The underlying essence of business analysis is finding out ways to get what’s in a stakeholder’s head out and onto a whiteboard where it can be modeled in such a way that other people can understand it and used to establish a shared understanding among stakeholders and confidently move forward with a solution. In short, the essence of business analysis is the value gained in creating a shared understanding and getting thoughts out of another person’s mind without a loss of fidelity is hard. Focusing on the essence of business analysis opens our eyes to new opportunities; new ways to create value and put the team in a position to be successful. It also allows us to use different techniques and tailor our approach to meet the needs of our stakeholders. Documentation has its place and its purpose, but creating documents in isolation and then sharing them is a poor way to communicate requirements and create a shared understanding. It’s much more effective to get the right people in a room and work through it together to the extent that the documentation we create becomes the sum of our conversation.   How to Know if You’ve Done a Great Job You’ll know you’ve been successful in focusing on the essence of your role and in helping others to succeed if the stakeholders ask you to help on another project. If you’ve done your job well, it will be recognized and people will want to work with you again. Another way to find out if you’ve been successful is from 360-degree feedback or a net promoter score. 360 feedback allows team members at all levels provide feedback as to your performance. A net promoter score is a way to get quantitate feedback as to whether or not you’ve performed well and people would like to work with you again.   The Impact of Focusing on the Essence Aside from the ability help others and your organization to be successful (and advance your own skills), seeing the essence of your role as communicator and facilitator helps you to understand where your skills can be used outside of your current role. The next leap forward for your role may be in moving out of the in-project work and helping executives with business cases. Here, you can make sure the delivery organization is working on the right things for the organization instead of just delivering the right way. In order for this to happen, people need to see us as communication experts and not just requirements experts. When we are viewed in this way, more career opportunities open up for us.   Living the Essence To get to a point where we can focus on the essence of business analysis, we need to shift our focus away from written documentation. If we try to be more precise in our written communication, we tend to become more technical and use approaches (such as BPMN or UML) that are difficult for stakeholders to understand and consume. While the documentation has value, there’s more value in ensuring a shared understanding through the use of visuals. Visual models are easy to understand and can be as precise as formal written documentation. The highest bandwidth form of communication is talking together in the same room and using visuals to ensure a common understanding. The real value is doing the work together.   Listen to the full episode to hear all of Jonathan’s advice including using the softer side of the essence to deliver more value for your organization and how to define success. http://traffic.libsyn.com/masteringbusinessanalysis/MBA071.mp3   Z Your Homework When we create something, be it a document or a visual, think of who is going to use it as our customer. Focus on their needs and afterwards, get their feedback on how you could have done better or how you could have helped them to be more successful. This kind of mindset builds trust and allows you to reach higher levels of performance. Links mentioned in this episode: Jonathan’s website Practical Analyst Jabian Consulting Jonathan Babcock Senior Manager, Jabian Consulting Jonathan has over 15 years’ experience delivering business solutions and has found his professional passion in helping organizations and individuals

In this episode, Ori Schibi discussed how Business Analysts and Project Managers can collaborate better to achieve success on projects and deliver more value to their organization.  After listening to this episode, you'll understand: Why BAs and PMs often don’t collaborate well Techniques for improving collaboration Why a combined BA/PM role doesn’t help  Show Notes When Project Managers and Business Analysts work together well, projects tend to run smoothly. This kind of partnership means that issues are identified and resolved quickly, knowledge is shared, and everyone gets the support they need to be successful. Often, good collaboration between PMs and BAs is absent and leads to confusion, loss of productivity, and poor quality. The role of the Business Analyst is on the rise and the role of the Project Manager continues to evolve. Unfortunately, many times people in these two roles don’t fully understand what the other does. This gap in understanding means that the two roles can’t fully collaborate and support each other.   A Contentious Relationship The Project Manager and Business Analyst have different areas of focus and this at times leads to a contentious relationship. The PM focuses on time and budget while the BA focuses on scope and quality of the solution. Pressure from the PM to complete requirements elicitation faster can cause requirements to be missed. Pressure from the BA to slow down to take time to get the requirements late can result in missed milestones and deadlines. The key is to understand that we’re all working towards the same goal. Failure to understand the needs and goals of people in each of these roles can lead to a hostile environment.   Better Alignment and Collaboration Part of the issue is that Project Managers and Business Analysts are measured and rewarded based on different metrics. If your organization can reward both roles based on the same goals and the overall outcome of the project, the result will be better alignment. Another approach is to work to understand the value and contribution that each brings to the project. A Project Manager can start by reaching out to the Business Analyst to understand each other’s areas of focus and preferences so you can apply your strengths in the appropriate area. A Business Analyst can help by preparing a brief package about the project and reviewing it with the Project Manager. Because the BA is often involved earlier in the project (for the business case and project selection), they may have additional information about the project that the PM would need to know to understand the context. From there, meet to discuss strengths and rules of engagement. Keeping communication open throughout the project will also lead to a better partnership.   Collaboration Exercise A technique to better understand each other’s role involves meeting to understand the value each person brings to the team. To start, provide each person with two blank flip charts or pieces of paper. On the first page, each person writes down the value and contribution we bring to the team. Each person switches paper so you can see the value that the other person brings. On the second piece of paper, write down how you can help the other person achieve that value, what you need from that person, and what you should do together. When done, review each page together and ask questions to gain a better understanding.   The Problem with a Combined Role In some organizations, we find a combined PM/BA role. While this solves the role understanding issue, this leads to other challenges. On larger projects, a person in a combined role may experience capacity issues. This could lead to delays, which is one of the issues we were trying to prevent with a combined role. The other issue with a combined role is focus. While the focus of the PM (time and budget) and that of the BA (scope and quality) can by opposing forces, they balance each other. With a combined role, it’s difficult to see both sides and achieve the balance needed to satisfy both areas of focus and bring value to the organization.   Listen to the full episode to get all of Ori’s tips and recommendations on improving collaboration between Business Analysts and Project Managers. http://traffic.libsyn.com/masteringbusinessanalysis/MBA070.mp3   Z Your Homework Talk to each other. Realize the value that each other brings and how we can help each other. Meet at the beginning of the project to identify collaboration opportunities right at the start.   Links mentioned in this episode: PM Konnctors Website Ori’s books Ori Schibi President, PM Konnectors Ori Schibi is President of PM Konnectors, a company that provides a wide range of innovative business solutions with a focus on strategy, change management, project management and business analysis. Ori has over 25 years experience in project and program management, training and facilitation, an

In this episode, Ron Ross shares his insights on Business Rules. Ron discusses what they are, how they differ from Business Requirements, and ways to harvest Business Rules.  After listening to this episode, you'll understand: What Business Rules are How Business Rules differ from requirements Why Business Rules are important How to harvest Business Rules  Show Notes There’s a lot of confusion around what a Business Rule is (and is not). A Business Rule is a guide or a statement that shapes behavior or decisions. In real live, a rule removed degrees of freedom. A rule is simply how we deal with a complex world. A Business Rule should not be thought of as technical. It’s not a specification or a specific requirement. It’s a statement to guide business behavior and business decisions. It’s a way of having a conversation in business language about constraints in the business. There’s an important distinction between Business Requirements and Rules. When you design a solution to a business problem, in some ways, it’s the end of life for your requirements. However, for Business Rules, the point of deployment is the start of life. Business have a continuing role over time and it’s important to provide the appropriate infrastructure to manage, review, reuse, and retire Rules over the life of the solution.   Sources of Business Rules Business Rules can arise from contracts, regulations, warranties, and certifications. The important thing is that you need to interpret the rules in those documents as they apply to your organization. Other rules can come from the business strategy. These Business Rules protect the organization from a significant risk or align you to achieve a significant goal. Some rules stem from the specialized knowledge of individuals in your organization. Because of the complexity of this knowledge, it’s best to think of it as a set of rules. Rules can also come from workflow and process. The coordination of activities, limits, and alerts can be expressed through business rules. Keep in mind that a process model tells you the right things to do while Business Rules tell you how to do those things right.   Harvesting Business Rules There are several ways to harvest Rules. The three approaches Ron mentioned are: Pattern Questions: These are forms of questions you can ask that will lead you to the rules that coordinate the activities around a particular deliverable (e.g., models). Decision Engineering (Decision Modeling): This is a method for modeling and decomposing operational decisions until you arrive at the rules needed in order to coactively make that decision. Source Documents: Rules can be harvested from documents such as contracts, regulations, policies, and the like. You’ll need to make business sense out of the language used in those source documents.   Well Defined Rules Ron helped define a set of guidelines for creating Business Rules called Rule Speak. There are three basic rules for writing rules. Every Business Rule must be a complete sentence: A rule is one complete thought that can stand alone. Example: A customer that purchases a product must have a valid credit account. Every Rule should start with a subject: Don’t start with ‘if’ or ‘when’. Start your sentence with the subject. Use one of two key words: Use either ‘must’ or ‘only’ in your rule.   A Business Rule is about human communication. It’s not a technical specification. It’s about achieving clarity of meaning upfront with business people in clear English so that you take the guesswork out of things when developers work on implementing the solution. You can improve the quality of your requirements and ensure alignment with business needs by defining your Business Rules.   Listen to the entire episode to hear all of Ron’s tips and advice for using Business Rules. http://traffic.libsyn.com/masteringbusinessanalysis/MBA069.mp3 Z Your Homework Keep track of how long it takes to roll out a change that you perceive to be a business rule or set of rules. This may give you data you need to persuade your organization to implement a Business Rules approach. Links mentioned in this episode: Ron’s Website BRSolutions.com BRCommunity.com Rules Speak website Building Business Capability (BBC) website Ron Ross Co-Founder of Business Rule Solutions, LLC (BRS) Ron Ross is recognized internationally as the “father of business rules”. He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book. Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He was also a contributor to the IIBA’s BABOK v3. TwitterLinkedIn 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. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to co

In this episode, Kent McDonald discusses the realities of being a Product Owner including what it was like to transition to that role, the pitfalls he experienced, and how you can avoid them.  After listening to this episode, you'll understand: What a Product Owner does Why a strong network is so important How to create a shared understanding within your team What Business Analysis skills you can apply in the PO role  Show Notes The Product Owner (PO) is a critical role on a Scrum team. It’s an extremely complex role and even experienced practitioners stumble at times. While the tools and techniques vary across teams and organizations, the underlying skills and pitfalls are common to the role. A PO is an individual on a Scrum team who acts as the voice of the customer and is accountable for managing the Product Backlog so as to maximize value. Click Here to Get Your Free Guide to What a Product Owner Should Be, Do, and Know As a Product Owner, you’ll need to create a strong network inside your organization to get answers quickly for the team. Any delay in responding to team questions or addressing impediments that slow down or stop progress will mean delays in product delivery. You’ll also need to establish a clear and compelling vision of the product and create a shared understanding within the team. Use the highest bandwidth form of communication available; ideally, face to face communication with a whiteboard. Make sure you work towards minimizing outputs and maximizing positive business outcomes.   Listen to the full episode to hear all of Kent’s tips and advice on success as a Product Owner. http://traffic.libsyn.com/masteringbusinessanalysis/MBA068.mp3   Your Homework Change the way you’re creating a shared understanding. Talk through examples with different perspectives (business, developer, and tester). Be willing to have a conversation about the product, talk through examples of the features, and most importantly, explain why.   Links mentioned in this episode: Kent’s Blog kbp.media About Kent’s book, Beyond Requirements Live lessons on Analysis Techniques for Product Owners Get 40% off Kent’s books and training – Use code MBAPODCAST 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 include 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. TwitterLinkedIn Get your free guide to What a Product Owner Should Be, Do, and Know.   Related Episodes MBA222: Testing Your Business Ideas Jun 15, 2021David Bland discusses the importance of testing your business ideas and shares ways to dramatically reduce the risk and increase the likelihood of success for your product, initiative, or project. read more MBA215: The Challenges with Leading in Product Management Jan 5, 2021Roman Pichler discusses the challenges associated with leading in a Product Management role and what you can do to overcome those challenges. read more MBA201: Tips From an Accidental Product Owner Nov 5, 2019Richard Larson shares his experiences as an accidental Product Owner and provides tips and advice for others moving toward a role in Product Ownership. read more « Older Entries 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. 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. The post MBA068: Realities of Being a Product Owner appeared first on Mastering Business Analysis.

In this episode, Dayle Beyer gives us an overview of PMI’s Professional in Business Analysis (PMI-PBA®) certification. she’ll help us to understand the requirements and benefits of the certification, what the exam covers, and give us some advice on preparing for the exam.    After listening to this episode, you'll understand: What the PMI-PBA® certification is The value of that credential to you and organizations Focus areas that the exam covers How to prepare for the exam  Show Notes Many organizations are shifting toward a dual role for Project Managers in which they act as both Project Manager and Business Analyst. PMI’s Professional in Business Analysis (PMI-PBA®) certification is designed for project professionals who play both roles of PM and BA. The need for Business Analysis certifications is growing along with the role. The U.S. Bureau of Labor predicts that by 2022, business analysis will increase by 18.6%. Additionally, Business Analysts ranked the highest for wage growth on Glass Door with a 10% increase from 2014 to 2015 and we’re seeing more organizations include certifications in their hiring criteria. According to research from the Project Management Institute, in the next five years, more than half of organizations plan to integrate their PM and BA practices. Much of this change is driven by agile adoptions. In agile environments, the role of the Business Analyst doesn’t go away; the approach changes. Instead of performing analysis only at the beginning of a project, analysis in done throughout a project and different techniques may be used. The PMI-PBA® certification is really about the different kinds of analysis that are needed. This includes needs assessment, analysis planning, traceability, and other analysis tools and techniques. The questions on the exam are situational based and not simply memorization of information in a book. Where the International Institute of Business Analysis’s CBAP® certification is geared toward senior business analysts with 7-10 years of experience and includes a deep dive into the BA role, the PMI-PBA® looks at analysis activities at the business level and focuses on what you should consider along with requirements.   Listen to the full episode to hear all of Dayle’s advice for preparing for and passing the PMI-PBA exam http://traffic.libsyn.com/masteringbusinessanalysis/MBA067.mp3   Your Homework Pick a date for the exam and drive toward that date. The hardest part is getting started and picking a date is a great way to motivate yourself. Links mentioned in this episode: Dayle’s website Information from PMI about the PBA certification Watermark Learning‘s website Dayle Beyer Senior Instructor, Watermark Learning Dayle Beyer is a Senior Instructor for Watermark Learning. For over 25 years, she has inspired excellence in thousands of people by providing best practices, tools, and techniques for project management and business analysis. Dayle is a member and active contributor of the Project Management Institute (PMI®) and International Institute of Business Analysis (IIBA®). She is also a frequent speaker at industry events. TwitterGoogle+LinkedIn Related Episode: MBA020: The Value of Certifications In this episode, David Mantica, President of ASPE-SDLC, shares his views on the value of professional certifications – both to the individual and to the organization.       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. 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. The post MBA067: All About the PMI-PBA Certification appeared first on Mastering Business Analysis.

In this episode, Hans Eckman helps us to understand how to set up a Community of Practice or Center of Excellence, even in an organization that may be resistant to the idea.    After listening to this episode, you'll understand: How a CoP or CoE can benefit Business Analysts and the organization Why some organizations may be resistant to the idea of starting a community How to start a community of practice or center of excellence How to use a story telling approach to convince people of the value of the community  Show Notes Starting a Business Analysis Community of Practice or Center of Excellence is a great was to develop the skills of all BAs in an organization as well as share good practices and tools for a consistent experience. However, some organizations can be resistant to the idea. How do you start a community in an unfriendly environment? Let’s first be clear on some terms. Center of Excellence: A CoE is a group of thought leaders and change agents who act as advisors, experts, or facilitators for that practice. Apply their knowledge to improve a particular role or area in an organization. Community of Practice: A CoP is a group of people in similar roles or with a similar background to share and exchange information and help better the organization. If you’re dealing with a small group of people trying to lead and help an organization evolve. Larger group of people sharing information and good practices. It’s not an either/or proposition; organizations can use both models at the same time.   Getting Started It’s much easier to start a Center of Excellence or Community of Practice if you can have an open discussion with the leadership team to get their buy-in and together decide what type of model you need. Unfortunately, you may not get the organizational support you seek. One approach that worked for Hans was to operate as an informal group for the betterment of the Business Analyst role. Then put together a charter to form an official CoP or CoE and meet with appropriate individuals to get approval. If at that point, you do not get approval, you can continue to meet informally and drive change. Getting small wins within the group can help build up your credibility and allow people to see the benefit of a group of likeminded individuals all driving towards a goal. Part of your process for starting a Community of Practice or Center of Excellence may be to start by analyzing your current environment to identify the benefits and challenges would be. Performing something like a SWOT analysis allows you to apply your BA knowledge and skills to create a community for the betterment of Business Analysts in your organization. With limited resources and limited authority (before official approval of the CoP or CoE), you’ll need to make sure what you do has a positive impact and rack up some quick wins. Above all, we need to become advocates for our own role, career, and organization. In an environment that undervalues the role and contribution of the Business Analyst, Hans recommends a quieter and assumed authority approach. Helping others to understand the role and develop training that will improve and standardize BA interactions will help others see the value of your group.   Listen to the full episode to hear all of Hans’ examples, tips, and advice for starting a CoP or CoE. http://traffic.libsyn.com/masteringbusinessanalysis/MBA066.mp3   Z Your Homework Links mentioned in this episode: Hans Eckman’s website www.HansEckman.com Link to Hans’ presentation The BA 2020 Vision Hans Eckman GVP at SunTrust Bank Hans Eckman provides linchpin leadership and consulting for rapidly evolving companies, with 19 of his 25+ years’ experience creating workflow & support optimization solutions across diverse industries. Hans rejoined the Innovation Programs team at SunTrust Bank, where he helps develop disruptive programs and products that drive innovation, process improvement, and engagement across the enterprise. Hans co-founded the SunTrust BA Center of Excellence. His presentations can be viewed at http://hanseckman.com. 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. 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. The post MBA066: Starting a BA Community of Practice appeared first on Mastering Business Analysis.

In this episode, Doug Goldberg help us to understand the true value that Business Analysts bring to a project and organizations.    After listening to this episode, you'll understand: Where Business Analysts can deliver value Why the value isn’t in the documentation (and where it really is) How to deliver value at every point in a project life-cycle How to change perceptions about business analysis  Show Notes As Business Analysts, we traditionally create documentation and manage requirements, but is that the value we deliver? We need to realize that we provide more value than what is captured in document. Documentation is just a mechanism to capture the value that a Business Analyst creates. Documentation is a means to an end and that end is a successful business outcome. Business Analysts contribute to that successful outcome by putting together relevant information to create a vision of the proper solution to a problem or opportunity. The value isn’t in the documentation, it’s in the analysis activities that help define the scope, vision, and solution. What creates value in the end of an initiative is critically important. We also need to understand what creates value right now and how we can provide value right away. Figure out how you can show value early in the project (before documentation) through facilitation, creating a shared vision, or whatever else creates value for the organization. The analysis effort needs to provide some sort of value proposition at any point throughout the lifecycle. How can you show people the value of your analytical capability early on? In the end, the effort may result in higher revenue, a better customer experience, or solving an organizational problem. Helping people to understand the value that you will contribute to the organization can help you achieve small wins along the way to that end result. Communicating the value of your efforts at the beginning may increase your involvement throughout the project and allow you to add value incrementally.   Communicating the Value of Business Analysis Before we can communicate the value that a Business Analyst brings to an initiative, we need to change the way we view ourselves. Think about the way in which you operate on a daily basis. If you’re the type of analyst who simply acts as a note taker, you’re cementing a lower perception of what you do. Think about how you can show the value in your analysis work. Produce something that people can use and that is valuable. Next, take both a top-down and bottom-up approach in your organization to communicate the value you bring. Get a sponsor to help shepherd the message. Show them evidence of your contribution to influence their perception. For a grass roots approach, take accountability for your message as an individual and start sharing and promoting that message with your peers. Carry your message into a social setting by joining and participating in professional organizations to help bolster your message.   Analysis Paralysis Shift your value emphasis to analysis work and make sure you aren’t caught in analysis paralysis. Don’t focus on the “what” and the “where”; focus on the “who” and the “when”. Think about who needs information and when they need it. This allows you to focus on the individual and their needs and constraints. This approach keeps you aligned to what’s really important to your customer; the time, the scope, and end result.   Listen to the full episode to hear all of Doug’s advice and tips for understanding and increasing the value you bring to your organization. http://traffic.libsyn.com/masteringbusinessanalysis/MBA065.mp3   Z Your Homework At the beginning of an initiative, think about the value that you will produce. Consider the “who and when” and what you need to do to meet that value proposition. Allow the team to understand your capabilities and the value of your analytical capability. Links mentioned in this episode: Doug’s website Doug’s blog post on documentation and requirements Doug Goldberg DougGtheBA.com Doug Goldberg is a Certified Business Analysis Professional (CBAP) with more than 22 years of experience. His background includes graphic design, printing, proofreading, typesetting, corporate communications, commercial kitchens, software support, online help development and training, J2EE/Java development, quality tester, and a few other sundry experiences. Doug mentors other business analysts and has a blog at DougGtheBA.com. TwitterLinkedIn 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. 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. The post MBA065: The Value of Business Analysis appeared first on Mastering Business Analysis.

In this episode, Angela Wick explains the skills needed to successfully transition to a Product Owner role and how to overcome some of the associated challenges.  After listening to this episode, you'll understand: Which business analysis skills overlap with those of a product owner The mindset shift needed to become a product owner Common gaps in the business analyst skill set and how to address them What you need to do to successfully transition to a product owner role  Show Notes Can a Business Analyst be successful in a Product Owner role? There’s so much overlap between the roles and many opportunities to collaborate with the Product Owner. Because of the overlap in skills, the Product Owner role is on the career path of many Business Analysts. The two roles are so closely aligned that almost everything in the Guide to the Business Analysis Body of Knowledge (BABOK) is part of the Product Owner role. The most foundational difference between a product owner and a BA is decision making authority. Business Analysts facilitate the conversation with decision makers to arrive at a decision while the Product Owner has the authority to make decisions about the product themselves. Many teams and organizations view the Product Owner as the decision maker and customer/business facing role and the Business Analyst as the internal, team facing role. Bob Galen’s Product Owner model describes the role in four dimensions; Product Manager, Project Manager, Business Analyst, and Leader. These elements are also in the Business Analyst role and the BA can either partner with the Product Owner or transition to the PO role.   What is a Product Owner? A Product Owner is a role on a scrum team that is responsible for determining priorities and what gets build. The delivery team then can focus on how to deliver that product. The product owner may perform elicitation, analysis, prioritization, visioning, and more to ensure a shared understanding of customer value. It’s their responsibility to create a healthy, prioritized list of backlog items that the team can deliver.   Core BA skills that are transferrable to a PO role Facilitation: Facilitation is a key skill. That includes facilitation to create a shared understanding and to elicit requirements. Decision Making: A Business Analyst may be used to making decisions through models and analysis. Decision Making is also needed for Product Owners to decide the best features and capabilities of the product to maximize customer value and return on investment. Prioritization: Prioritization may be an issue for some Business Analysts because they’re accustomed to prioritization through consensus building. However, as a Product Owner, you have decision making authority and the expectation is for faster prioritization decisions. Systems Thinking, Modeling, and Analysis are also needed to be a successful Product Owner. One area where Business Analysts transitioning to a Product Owner role may struggle is documentation. If BAs see their value as producing documentation, there is a mindset shift needed to be successful as a Product Owner. We must shift from the need to create documentation to the need to facilitate a conversation. When we do need to create documentation, it should be just enough, just in time.   Where are the gaps? The most basic gap between the Business Analyst role and the Product Owner role is the mindset. While Product Owners use many of the same skills and techniques, there is a fundamentally different way of thinking about the role and the product. We need to understand our own mental model and how that drives our behaviors. From there, challenge some of those thought patterns. It takes time to shift your thinking to incremental work, empowerment, and a culture of collaboration over documentation to get a shared understanding. The other area with which Business Analysts often struggle is Product Management; understanding the product and the value it provides to customers. As a Product Owner, you need to understand the product and which changes will be valuable to customers. This includes talking to customers to understand them better and create a vision of the product to align the team. From there, you can create a roadmap to develop a shared understanding of priorities and where the product is going. You may also need to create a release plan based on delivery customer value (instead of based on technical changes) and aligned to the product vision. We need to put customer value first and let that drive the roadmap. Listen to the full episode to hear all of Angela’s advice on transitioning from a Business Analyst to a Product Owner role. http://traffic.libsyn.com/masteringbusinessanalysis/MBA064.mp3     Z Your Homework Keep learning! The role keeps changing and evolving. You need to have a mindset of continuous improvement and continuous growth. Links mentioned in this episode: BA-Squared website Angela’s cou

In this episode, Laura Brandenburg explains how to use your existing skills and grow your experience to start a career in business analysis.      After listening to this episode, you'll understand: What key skills you need to become a successful business analyst How to expand your business analysis experience How to know what skills hiring companies need Benefits of connecting with other business analysis professionals  Show Notes To get started in the business analysis career, you’ll need to have a few key skills. The most important skill is communication. This includes not only written communication as in the documenting of requirements, but also verbal communication and facilitation. You’ll need to be able to draw information out of people and relay that information in a clear and direct way. Good communication skills are foundational. From there you can layer on other skills such as visual modeling, facilitation, and business analysis techniques.   Getting started It’s difficult to get a role as a business analyst without experience as a business analyst. We need to be able to find a way to grow our experience without having that role. There are a lot of people were performing business analysis work without having the title of business analyst. There may be skills and experience in your current role or in your past that you can leverage. What’s relevant is that you have experience doing the kinds of things that a business analyst does. You may have experience in communicating with stakeholder groups, facilitating meetings, mapping of business processes, or working with the software solution. The first step is to reflect back on your experience and pull out the skills and knowledge you’ve gained that aligns to business analysis. You can then learn the BA terminology and translate your experience into the skills and techniques of the business analyst. Once you’ve mapped your skills and experience, look for opportunities to apply those skills and techniques in your job. Use this to not only build your business analysis experience, but also demonstrate that you can perform business analysis tasks successfully. This can lead to a snowball effect where small successes can lead to more opportunities and more experience.   Find out what skills you’ll need You can learn more about what kind of skills employers are looking for by joining local professional groups such as the International Institute for Business Analysis (IIBA) or the Project Management Institute (PMI). There, you can talk to other professionals to learn more about their role in what skills and techniques are born to be successful. You can also read books such as the Guide to the Business Analysis Body of Knowledge (BABOK) and listened to podcasts (such as this one). There are many great books, webinars, and training classes you can take to learn more about the role of the business analyst. You should also look at business analyst job postings in your area to understand the skills and capabilities employers are looking for. This can be done early on is your exploring the possibility of a career in business analysis. However, you should also do this throughout your career to identify potential gaps in your knowledge and experience and to stay current. Looking at job postings within your organization or externally in your local area is a great way to understand the skills required and identify gaps in your experience.   Filling in the gaps Once you’ve identified gaps in your skills and experience, you can seek out opportunities to try new skills and gain experience. This can be done within your organization or by helping charity groups and nonprofit organizations. You can also gain experience by helping out friends who own businesses or volunteering at professional organizations.   Listen to the full episode to get all of Laura’s tips on starting a career in business analysis and what to do when you land your first BA role. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_063__Starting_a_Career_in_Busine.mp3   Z Your Homework Take one technique from the BABOK or another business analysis book and apply it in your work or outside your organization to gain practical experience. If you can apply that technique while engaging with a stakeholder, it well do even more to enhance your experience and give you confidence. 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 free course on starting a BA career 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 an

In this episode, you’ll find out why peer reviews are so valuable, how they can improve the quality of your requirements, and much more.  After listening to this episode, you'll understand: Why peer reviews are important for improving requirements quality How peer reviews can reduce cost How to implement different types of peer reviews Why some peer review initiatives fail and what to do about it  Show Notes A Peer Review is a way to improve quality of work products through having individuals in the group review the product and provide feedback. A Peer Review can be applied to requirements documents, software code, prototypes, wireframes, technical documents, or anything else for which quality is important. The added benefit of a Peer Review is that it can help spread knowledge within your group. This is possible because the creator of the work product shares information with the review participants as part of the process. As a result, you share knowledge about upcoming product changes and may discover effective practices. Because the cost of a defect discovered late in the development cycle is much more costly than something found in the analysis phase, peer reviews can improve quality in the beginning stages and save organizations time and money. Click Here to Get Your Free Guide to Getting Started with Peer Reviews   No One Size Fits All There’s no one right way to perform a Peer Review. The type of Peer Review you use depends on your specific needs and the type of feedback that will help you improve the quality of your work product. Types of Peer Reviews range from quick, ad hoc reviews to formal inspections. For requirements documents, I have found that an approach between formal inspections and walkthroughs provided the biggest benefit.   Role-Based Peer Reviews ​A Role-Based Walkthrough is a review in which meeting attendees take of different roles such as tester, developer, sponsor, and various stakeholders. The author then walks through the document and attendees provide feedback based on their assumed role. ​This type of walkthrough would be done before reviewing the document with the project team and can be done early in development before the document is complete. This allows the author to make changes early in the process to avoid rework and delays due to further analysis. Listen to the full episode to learn the benefits of peer reviews, how to avoid common problems, and start a peer review program. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_062__Peer_Reviews_for_Better_Req.mp3 Z Your Homework Find ways to conduct brief peer reviews to improve quality and spread knowledge. If you don’t have a peer review process in your organization, consider starting one. The guide to Getting Started with Peer Reviews can help. Links mentioned in this episode: Click Here to Get Your Free Guide to Getting Started with Peer Reviews 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. 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. Click the image below to get your free guide. The post MBA062: Peer Reviews for Better Requirements appeared first on Mastering Business Analysis.

In this episode, David Nimmo shares some strategies to help us overcome common roadblocks to success on complex projects.    After listening to this episode, you'll understand: Why projects are becoming more complex What to do if you are pressured to create a full design/requirements upfront How to overcome analysis paralysis  Show Notes The pace of business is moving faster and projects are getting more complex. With the push for more speed and added complexity, we often find ourselves hitting roadblocks limiting our ability to be successful on projects. The challenge is to find the right way do things to help business and technology teams to achieve success together.   Roadblock: Big Design Upfront One common roadblock is the push to have everything to lock all of the details in upfront in order to mitigate risk. Ironically, identifying all of the details upfront may actually lead to increased risk over more adaptive methods. Even if we identified everything correctly upfront, by the time the project solution is delivered, the business need, environment, or technology may have changed. The solution may no longer be fit for purpose. We need to try to work with more adaptive and flexible approaches, both with requirements and contracts. Outcome oriented contracts allow the flexibility to adapt the approach while still meeting the goal or expected outcome of the project. Beyond flexibility in the contract, using the 80/20 rule (Pareto principle) can help you deliver the most valuable items early. Usually 80% of the value can come from 20% of the requirements. Understanding what that valuable 20% is and focusing on delivering that portion early will allow you to deliver the most valuable capabilities early and then work on the remainder of the deliverables. Using the 80/20 approach delivers value for the business and allows us to learn and adapt along the way. Breaking large efforts into phases or iterations allows you to deliver value early and adapt to changes. To find the critical 20%, it’s often best to use a collaborative approach and understand what’s important to each stakeholder and technology teams. Having agreement and a common understanding of priorities will provide focus and clarity.   Roadblock: Analysis Paralysis We often find ourselves in a state of analysis paralysis; continuing research and analysis activities without moving to the next step. There are several reasons for this including the desire to ensure high quality in the analysis activities. We don’t want any missing or incorrect requirements, so we work to keep digging and never move to action. To combat analysis paralysis, use time boxing. Set a specific time limit (e.g., one month) for analysis work. This forces focus in analysis activities and means that you will complete what’s critical and delay some non-critical activities. It also encourages appropriate risk taking. Nothing important or worthwhile was done without risk.   Cynefin Framework The Cynefin framework allows you to categorize your project and understand the actions that are appropriate for that category. Categories include Simple, Complex, Complicated, and Chaotic and the framework includes suggested approaches to address those categories.   Listen to the full episode to hear all of David’s tips and suggestions for overcoming chaos on projects. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_061.mp3   Z Your Homework Don’t be held back by chaos, complexity, or uncertainty. Make a decision and take the next step forward. If you’re unsure which way to go, seek help from peers, mentors, coaches, etc. Links mentioned in this episode: David’s Website, NeoViz Contest for David’s book launch David’s book, Chaos to Success David Nimmo Executive Consultant & Lead Innovator, NeoViz David Nimmo has over 20 years’ IT and business consulting experience, about two-thirds of which was with IBM, where he led a community of over 400 Business Analysts in career and skill development. He has spoken to audiences at conferences in Australia and the US on topics including high performance leadership, agile, and innovative project success methodologies. TwitterLinkedIn David Nimmo’s book “Chaos to Success!” outlines innovative strategies you can use for creating clarity and progress for complex projects. The book includes information on several roadblocks you may encounter on your projects and strategies to overcome them. The book is now available on Amazon. 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. 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. The post MBA061: Overcoming Roadblocks to Success on Complex Projects appeared first on Mastering Business Analysis.

In this episode, Daniel Lambert helps us to understand what Business Architecture is, how it differs from Business Analysis, and the value it can bring to an organization.  After listening to this episode, you'll understand: What Business Architecture is How Business Architecture differs from Business Analysis How a BA can get value from Business Architecture What a Business Analyst needs to do to become a Business Architect  Show Notes Business Architecture is more of a model than a method. It gives you a snapshot of your organization to better understand it’s capabilities, products, and how it delivers value. Often, Business Architecture is documented via a series of maps (value stream maps, strategy maps, etc.). It’s used to get an accurate picture of your company so that product and IT leaders can extract opportunities and create initiatives. It also allows you to build epics and user stories that tie back to opportunities and capabilities of the origination. You’ll be able to see elements in the business architecture model and be able to grasp the full picture and be more accurate in requirements and avoid redundancies. When we look at the top reasons for project failure (missing requirements, unrealistic expectations, etc.), knowledge and application of Business Architecture can help address these issues. Business Analysts can use the Business Architecture model to help define your requirements or User Stories. Linking your requirements to the architecture helps to find errors, unneeded requirements, and omissions. Additionally, understanding organizational capabilities can help accurately frame expectations.   The Business Architect and the Business Analyst Business Architects main focus is at the organizational level and understanding the capabilities, market, products, and how value is delivered to customers. The Business Architect does not focus on delivery, but the information that they develop can lead to projects and ensuring alignment with organizational capabilities. They’re all about planning and generally not at all about delivery and execution. That’s where the Business Analyst comes in. You can think of a Business Architect as a scaled up version of a Business Analyst. Business Architect: Understands and creates maps and models to represent the organization’s capabilities, delivery of value, products and services, etc. Business Analyst: Understands value of their project/initiative and focuses on business needs and solution delivery. Ensures alignment of their projects and requirements to business strategy and business architecture. Enterprise Architect: Understands and helps define the roadmap for the technology used by an organization. May lack business acumen. Solutions Analyst: Understands requirements created by the Business Analyst and devises solutions that meet the requirements while aligning to the organization’s technology roadmap.   The BA Career Path The Business Architect can be described as a Business Analyst with a more strategic, higher level focus. As such, the Architect role may be on the career path for the Business Analyst. Often, the Business Architect reports to the Director of Business Architecture under the CIO. However, because they have a business focus, it may be more effective to report up through the COO instead of technology. To learn more about the Business Architect role, you can join the Business Architecture Guild. They created the Guide to the Business Architecture Body of Knowledge (BIZBOK), which you can use to learn more about creating and using the maps and models that make up business architecture. You can (and should) also seek out the Business Architect in your organization to learn more about what they do.   Listen to the full episode to hear all of Dan’s tips and advice. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_060.mp3   Z Your Homework Find out about the Business Architecture information in your organization and use it to enhance your ability to link requirements and solutions to the organization’s strategy and capabilities. If there is no Business Architecture information in your organization, it represents your opportunity to add more value and advance your career. Links mentioned in this episode: Business Architecture Guild Read the introduction to the BIZBOK Guide Daniel’s article on BA Times   Daniel Lambert Vice President at Benchmark Consulting Daniel Lambert has over 25 years of experience in IT. His company’s software, IRIS Business Architect, enables the rapid creation of Business Architecture meta models and allows for collaboration by making it easy to share the Business Architects’ work. He recently wrote an article on Business Analysts and Business Architecture for Business Analyst Times. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subs

In this episode, Matt Fishbeck shares a six step problem solving framework that can help you to address the right problem and come up with the best solution for your organization and customers.  After listening to this episode, you'll understand: Why the skill of problem is so critical How to apply a 6 step problem solving framework How to apply problem solving techniques  Show Notes As business analysis professionals and change agents, one of our most important skills is problem solving. Problems present an opportunity to bring value to our customers and organization. Without the crucial skill of problem solving, we’re limited in our contribution to the organization as well as career growth. Many people conduct problem solving intuitively simply by “thinking” without pausing to consider what the underlying process and mechanism for problem solving is. Problem solving is a discipline; a science of applying logical and analytical techniques to identify the underlying cause and recommend solutions that address the root cause. Matt’s Recommended 6 Stage Problem Solving Approach The problem solving approach that Matt uses is a simple six stage process. The staged do not need to be completed sequentially; the individual stages may repeat and be completed in iterations. The stages consist of: Defining the problem statement Defining scope Elicit information & resolving ambiguity Identifying associations and relationships Root cause analysis Solution proposal The Problem Solving Process Start by creating the problem statement. The problem statement is a well-defined statement or question to frame the context. After you have a clear and unambiguous problem statement, define the scope of the effort. The scope definition is probably the most important stage since it basically whether or not the problem can be solved satisfactorily. Scope is defined to apply constraints to the domain of consideration. When we have scope we know what to consider and what not to consider. Therefore, all possible solutions are directly dependant on the information within the scope. Once the scope is defined, you can move on to eliciting information & resolving ambiguity. Perform a stakeholder analysis and elicit information from all known stakeholders/sources as a basis for investigation. You can use workshops, focus groups, interviews, document analysis, and other approaches to elicit information. When we elicit information, we try to remove ambiguity as ambiguity represents the unknown, liability, and risk. To reduce ambiguity, we need to consider the taxonomy of ambiguity to provide a frame of reference to how we will resolve it. Ambiguity may be: Missing information Incorrect information Duplicate information Conflicting information Incomplete information The above provide a basis to ask questions concerning all information that is within scope, to challenge this information to be reliable and suitable for use. Context diagrams and domain diagram can help resolve ambiguity. Next, we identify associations and relationships to organize the information so we can derive meaning from it. Information needs to be structured, aligned, and associated that provides an additional level of meaning. This is the basis for traceability. The linking of concepts. It’s not just solely used for requirements. Once we thoroughly understand the information, we can move on to performing a root cause analysis. A root cause analysis helps you to understand the underlying cause of the problem so you can address it instead of addressing a symptom of a greater issue. There are many techniques for root cause analysis including 5 Whys and Fishbone diagrams. Now that we understand the real root cause, we can propose solutions that will address that root cause. When identifying proposed solutions, consider the scope, constraints, and relative cost and value of each option. Problem solving is not some illusive black art; it’s an analytical process that can be broken down, quantified, and analyzed to identify the root cause to give rise to a viable solution. Listen to the full episode to hear all of Matt’s examples and tips for problem solving. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_059.mp3 Z Your Homework Begin applying Matt’s six-stage problem solving approach. Often, the most difficult part of problem solving is knowing where to start. Start learning the root cause analysis techniques in the Guide to the Business Analysis Body of Knowledge (BABOK). The techniques will give you more tools to help in your problem solving efforts. Links mentioned in this episode: Matt’s Problem Solving article on ModernAnalyst.com Matt Fishbeck Senior Business Analyst and Writer Matt Fishbeck is a Senior Business Analyst and a thought leader in Business Analysis. He takes an active interest in Business Architecture, Enterprise Architecture, and Change Management in addition to helping run a Business Transformation meetup. Matt

In this episode, Mark Des Biens shares an approach to reuse requirements and accelerate requirements elicitation.  After listening to this episode, you'll understand: Why it takes so long to elicit requirements How to use a hypothesis to better understand customer needs How to build a repository of requirements and tests to accelerate requirements discovery  Show Notes One of the most frequent complaints about requirements elicitation for a new feature or capability is that it takes too long. In addition, you need to repeat the analysis for additional features or future projects. The reason why it takes so long is because we need to get the requirements right and we only have one chance to do it. In Agile, having only one chance is not as much of a driver, but the need for speed is greater.   Reusable Discovery Testing Imagine being able to have a thorough understanding of your customer’s needs and wants even before you begin a project and having a repository of tested requirements from which to pull. Reusable discovery testing may allow you to reduce the time needed to elicit requirements by up to 60% by identifying new channels for collecting information, capturing the results of discussions with stakeholders, and reusing information. To get started with reusable discovery testing, begin with questions for stakeholders and customers related to your current objectives (project or feature) and broaden your questions for facets outside of your immediate objective. Perhaps an understanding of the roadmap or future state of the product will help you identify questions and hypotheses to ask and test. Ask these additional questions to expand the amount of data you’re collecting. Instead of asking a few focused, closed-end questions, ask stakeholders broad, open ended questions that expand beyond the current feature or project. Think of your questions as hypotheses that you’re trying to test. This can be related to preferences (customers prefer dark backgrounds), needs, and wants. This gives you a better understanding of your customers and what solutions may satisfy their needs. The number of hypotheses (tests) grows organically and becomes more of a conversation with the product owner and ultimately, customers. The key is to not only ask about customer preferences, but also ask why to understand what’s important to them. You can test your hypothesis by asking customers directly, by building prototypes (high or low fidelity), focus groups, and split testing. Split A/B testing is a great way in a digital setting to quickly understand customer preferences based on real data. Developers may attach old tests to new requirements instead of needing to re-document or come up with new acceptance criteria. The data collected could also lead to new features and capabilities of the product. The information can also lead to more fully developed personas.   This approach can help you reduce elicitation time by decreasing the amount of documentation needed and give the team a head start on the process. Listen to the full episode to learn how to get started with reusable discovery testing. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_058.mp3   Z Your Homework Start documenting what you’re doing and the questions you’re asking. Use the answers as a starting point to ask new questions and build a repository/list. Links mentioned in this episode: Mark’s Blog: a12p.blogspot.com VersionOne Mark Des Biens Solutions Engineer, VersionOne Mark Des Biens is a solutions engineer and implementation consultant at VersionOne. Mark has more than 20 years of project experience and has worked with dozens of companies looking to improve their enterprise agility. He has been a ScrumMaster and agile program manager, and is one of the founding members of the Midwest Agile Community Meetup group. Twitter 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. 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. The post MBA058: Reusable Discovery Testing appeared first on Mastering Business Analysis.

In this episode, Vince Mirabelli introduces us to the six worst types of stakeholders and shows us what to do if you have one of these stakeholders on your project.  After listening to this episode, you'll understand: What the six worst types of stakeholders are What to do if you have one of these stakeholders on your project How to perform a stakeholder analysis that works  Show Notes A stakeholder can singlehandedly make or break a project and there are some that are . . . less than cooperative. People will behave in a way that promotes their own self-interest and sometimes that runs counter to what you’re trying to achieve in your work. You’ll need to manage those people differently than that stand to benefit from what you’re trying to do. There are six worst-of-the-worst types of stakeholder of which you should be aware and know how to engage and interact for best possible results.   Stakeholder #6: The Psychic The Psychic is a stakeholder who knows (or at least thinks they know) what will happen and what needs to happen on the project. They sometimes jump to conclusions about the solution and could sometimes take you down the wrong path. You’ll likely encounter The Psychic right away at the beginning of the project. They may be a very experienced person who tries to dictate what should happen based on their experience or they may be someone who is very “by the book” on how things should be done. To deal with The Psychic, keep them engaged. Take their comments into consideration and help them to understand that their ideas have some merit and we want to explore other ideas as well.   Stakeholder #5:Mr./Miss Resister The Resister is someone who wants to keep the status quo and dislikes any kind of change. They can be across a spectrum of mild resistance to outright withholding information and taking action to make a change effort unsuccessful. The two types of Resisters that are most problematic are those who resist outright and those who are two-faced. Two-faced Resisters are stakeholders who communicate their support to you, but withhold needed information and do not cooperate.. To deal with the Resister, have a solid change management process in place and engage them in that process. Keep them involved and in support of the change. Make the change easier for them by breaking it down into smaller pieces or calling it a tweak or enhancement instead of a change. Help them to understand why we’re making the change and what’s in it for them.   Stakeholder #4: The Career Climber The Career Climber is someone who wants to get ahead and often work to prove their value. This could even be someone on your team. There’s nothing wrong with being a Career Climber, unless it’s at the expense of the project. The Career Climber may undermine you, the project, and the team if it means getting ahead. You may get doubletalk from them; they say positive things to you, but negatively about you or the project to others. To deal with The Career Climber, figure out what they want and what’s important to them. Perhaps you can involve them in some way that gets them what they’re looking for such as face time with the leadership team. You can also have them own a piece of the project and take accountability.   Stakeholder #3: Mr./Miss Emergency For this stakeholder, everything is an emergency. Mr./Miss Emergency can derail your project at the last minute. They feel that they’re not ready and any defect should bring the project to a halt. Mr./Miss Emergency may also withhold information, thereby causing the emergency. It may be a lack of engagement or purposeful withholding of information. You can handle Mr./Miss Emergency keep them engaged and get someone of equal or higher level who is more level headed to have a casual conversation with them about their concerns and interaction (after having that conversation with them yourself, of course). Leverage your stakeholders – especially those who strongly support you.   Stakeholder #2: The Bulldozer The Bulldozer is often the most overtly disruptive and aware of what they’re doing. They often don’t have good intentions or they’re unaware of what they’re doing. Their actions may include yelling, throwing things, or inappropriately belittling you and the team. They really want to be heard. The Bulldozer likes to have an audience. To deal with them, give them an audience, but one of your choosing. Build an audience with those who support you and the project (especially stakeholders at or above The Bulldozer’s level). This makes The Bulldozer hesitant to act out when they know the support you have from those above them.   Stakeholder #1: Conrad Hilton Conrad Hilton refers to the personification of a character as portrayed in the show Mad Men. Conrad would share his requirements and the team would create something that meets the requirements, but upon delivery, Conrad would tell the team that it wasn’t what he wanted. His famous line is “You

In this episode, Blair Loveday and Kupe Kupersmith discuss the benefits of design thinking and show us how to apply design thinking for better business analysis.      After listening to this episode, you'll understand: What design thinking is and how it applies to business analysis The benefits and value proposition of design thinking How to get started with design thinking  Show Notes Design thinking is a creative approach to solution-based problem solving and innovation that puts people at the center. It allows you to create solutions that customers truly want and need. Design Thinking is quickly becoming a leading approach for product development, innovation, and problem solving. Business problems are getting more complex and harder to solve. Without innovation and a human centered focus, we will find it difficult to satisfy and delight our customers in the future. A Design Thinking approach allows you to focus on tackling a problem with a people lens and a customer experience angle. In the end, Design Thinking is just good business analysis applied the right way.   Design Thinking is the New Agile Many organizations have adopted an agile approach to product and project delivery. Most are now focusing on maturing their agile practices. While Design Thinking has been around for several decades now, there has been a big push lately to develop Design Thinking skills. It has been highlighted by research and training organizations as a major trend and “The Next Big Thing”. There’s not one way to apply a Design Thinking approach. It’s taking the principles of Design Thinking and figuring out what works for you. Design thinking and agile go well together due to some of their similarities, but you don’t need to use an agile approach to apply design thinking. A lot of the success in agile comes from collaboration and understanding what skills you bring. Similarly, Design Thinking allows you to apply a number of lenses to look at problems in different ways, apply different skills and perspectives, and focus on solutions that address customer needs. Design Thinking gives Business Analysts a ticket to get involved earlier to project conception. It allows you to express an idea in a way that creates a shared understanding and develop that idea into something that the customer wants.   Design Thinking vs. UX Design Many people have a misconception that Design Thinking is the same as User Experience (UX) or Customer Experience (CX) design. While UX Design deals with how the customer will interact with the solution, Design Thinking comes before the solution is identified and ensures that the right solution is built.   Blair and Kupe’s five-step Design Thinking process   This approach is something Business Analysts should be doing anyway – just possibly using different tools. The techniques of Design Thinking are not a big jump from what Business Analysis professionals do today. People have a perception that Business Analysts work is exclusively in the domain of requirements. Business Analysts have the skills to apply Design Thinking and find opportunities to get a seat at the table and involved earlier in shaping projects and solutions. Get your Design Thinking Guide now. Click Here to Get Your Free Guide to Getting Started with Design Thinking The Design Thinking Value Proposition Design Thinking brings value to organizations by allowing you to innovate and create a solution that meets the customer’s needs. This is predicated on the ability to understand who your real customers are and understanding their point of view. You must get the right people in the room; and the right people are customers.   To be successful, focus on the customer and take them on your journey. It creates a fail-fast-and-learn culture and helps you build products that our customers really want and will consume. Listen to the full interview to hear all of Blair and Kupe’s advice on Design Thinking and how to get started. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_056.mp3 Z Your Homework Kupe’s Tip: Learn more about Design Thinking and how you can incorporate a Design Thinking approach into your work. Don’t be afraid to try new approaches and learn. Having a supportive network helps with this. Blair’s Tip: Just do it. Imbed something into your day to day routine, such as visualizations or adjust the way you facilitate. Surround yourself with like-minded individuals. Links mentioned in this episode: Blair’s company, Redvespa Kupe’s company, B2T Training BATimes Kupe’s radio show – Technology Expresso Café Blair Loveday Chief Designer at Redvespa Blair thrives at the intersection of inspired design, business, and people. He has an insatiable curiosity for design and design thinking and combines his expertise and passion for business analysis, alongside a multi-disciplined design thinking approach to help clients to not just realize solutio

In this episode, Ryland Leyton, author of The Agile Business Analyst: Moving from Waterfall to Agile, joins us to talk about what it means to be an agile business analyst and how to be successful in an agile environment.    After listening to this episode, you'll understand: How a business analyst can support organizational change How to use the Discovery and Delivery framework in an agile environment How to be transparent in your analysis work Why agile isn’t simply a series of short waterfall phases How to use an elevator pitch to show your value proposition  Show Notes How can a business analyst support organizational change in the move from waterfall to agile? Think in terms of enterprise analysis. The business analyst is well-positioned to think about all of the impacts of the project across the enterprise including funding, managing, supporting, training, and any number of business processes affected by the product. By keeping enterprise analysis in mind, were able to interface with all affected groups and individuals to ensure any impacts are identified and addressed. Because of our nature of being communicators and interacting with many areas of the organization, we’re well positioned to help the various groups within our organization to understand the change needed and how to adapt to those changes.   Applying the Discovery and Delivery Framework The Discovery and Delivery Framework provides a way of thinking about what you’re doing in an agile context. The Discovery and Delivery Framework provides several concepts including: See the whole – Are we looking at everything in the context of the entire system? One technique to use for this is value stream mapping. Think as a customer – Understand who is going to use the product and the value that the customer expects to get out of it. Personas and story mapping are techniques you can use to think like a customer. Get real with examples – Do you have an example of how the customer will use the product? This allows you to have a better understanding of how the customer will use the product and any impacts or challenges. Behavior Driven Development (BDD) is a frequent technique used here. Understand what is valuable – Understanding who the customer is and the challenges they face will help you to understand what will be valuable to the customer and design the product to provide that value in the fastest way possible. Some of the techniques that support this concept are backlog management and Kano analysis. Analyze to understand what is doable – Understanding what can be done to provide value given what we know about the other areas of the Discovery and Delivery Framework. One technique you can use here is real options. Keeping these concepts in mind helps you maintain an agile and value mindset when speaking with customers and stakeholders.   Make Analysis Visible with the Analysis Wall The Analysis Wall is very similar to the development wall, which is a physical wall (or electronic version of one) that shows the progress of a user story. The progress can include stages such as ready, development, testing, and deployed. Instead of showing progress of a piece of development work, the Analysis Wall shows the progress of analysis work in getting a user story ready to be picked up by the development team. Stages on the analysis wall may include backlog, analysis, sent to Product Owner, sent to UX, ready to estimate, ready to play. The analysis wall allows you to prioritize analysis work, avoids creating a full analysis upfront, and makes transparent the progress of getting a story to a ready state.   Iterative vs. Phases People often ask “Isn’t iterative development just waterfall done in very short phases?” On the surface, there are many similarities between iterative development and a phased approach. It can also be a step in the right direction to make your waterfall projects a little more adaptable. What’s missing with simply implementing small phases is the ability to learn. With iterative development, the cycles are very short (usually between one and four weeks) to product a tested, working product. Users can then interact with the working software and provide real feedback that can be incorporated into the backlog and prioritized to adapt the product to the user’s needs. The faster feedback loops allow you to learn and adapt the product so that you build the product for customer value and don’t build shelf ware.   The Business Analyst’s Value Proposition Ryland has developed a short elevator pitch to articulate the value proposition of the Business Analyst role in an agile environment. The elevator pitch can help others to understand how you as an agile business analyst can support the team, organization, and its customers. “As a BA, I free the product owner to focus on the needs, desires, and interests of the end customer. The product owner can then maximize the value of the full suite of products and f

In this episode, Adrian Reed speaks with us about organizational strategy, why it’s important for business analysis, and how to link your efforts to the overall organizational strategy for greater influence and alignment.    After listening to this episode, you'll understand: Why understanding organizational strategy is critical How to trace your projects back to your organization’s vision and mission How to better understand your organization’s strategy and gain alignment  Show Notes Strategy can become an abused word; something used to make things sound more important. Understanding what strategy is and how it traces back to organizational objectives, you can gain alignment within your project team and move the organization closer to it’s vision. According to Richard Rumelt, author of the book Good Strategy, Bad Strategy, a strategy is a cohesive response to an important challenge. Unlike a standalone decision or goal, a strategy is a coherent set of analyses, concepts, policies, arguments, and actions that are in response to a high-stakes challenge. It’s about the thread from the organizations mission and vision to the projects that helps deliver upon the mission and get you closer to the vision. Strategy is what drives everyone in the same direction. Without clarity into the mission, vision, and strategy, how can we be sure that we’re not working on several projects that are pulling the organization in many different directions? Often we’re handed a project (or a solution to implement). We need to help stakeholders step back from that solution illusion and articulate the need and expected outcomes. Once outcomes are understood, you can verify if the outcomes are aligned to the strategy, mission, and business environment. If there is misalignment, you should bring this to the attention of stakeholders and the sponsor for discussion. The Business Analyst is in a great position to be a guardian for strategic alignment. By applying systems thinking, you can see the big picture of how your organization delivers value and the individual pieces (processes and projects) that contribute to value delivery. You can also see how each projects aligns (or fails to align) with the organizational strategy.   VMOST Adrian uses an approach called VMOST to ensure alignment from the organization’s mission to its projects. VMOST is an acronym and stands for Vision and Mission, Objectives, Strategy, and Tactics. The mission is the organization’s core purpose and the vision is an envisioned future state. The mission likely won’t change whereas the vision may be updated from time to time. The vision and mission help provide clarity and alignment within the organization. However, they’re not directly executable. They need to be decomposed to take action. The objectives are the measurable goals that move us closer to the mission and vision. Objectives are still too big and aspirational to directly action. Objectives are therefore decomposed into multiple strategies. The strategy provides direction as to how the organization will achieve the objectives. Strategies are further decomposed into tactics. The tactics are the actionable projects and tasks that will be done to achieve the strategy and objectives. Through an understanding of VMOST, you can trace your projects and tasks back to the strategy, objectives, mission, and vision to ensure that they align and question those that do not align. Projects should have an objective or opportunity statement that traces back to a higher level.   Gaining Alignment Starting off a project with a kick-off meeting in which you explain the project and tie it back to an organizational objective and the company mission is a great way to gain alignment within the project team. You can also start a project by developing a strategic problem statement such as the one below to get all stakeholders aligned with what you’re doing, the expected outcomes, and how it aligns with organizational objectives. The problem of ___________ is affecting ____________. The impact of which is _____________. A successful solution would _____________. This aligns with our stated strategy by ______________ and would help us to meet our objectives of _____________.   Listen to the full interview to get all of Adrian’s tips and advice. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_054.mp3   Z Your Homework Get to know your organization’s VMOST. If you don’t know it, ask. This has many benefits included being seen as a leader and strategic thinker.   Links mentioned in this episode: Adrian’s blog Blackmetric Business Solutions website Adrian Reed Director and Principal Consultant at Blackmetric Business Solutions Adrian is Principal Consultant at Blackmetric Business Solutions, providing business analysis consultancy and training solutions to a range of clients in varying industries. He is President of the UK chapter of the IIBA and

In this episode, Ivar Jacobson shares with us the birth of Use Cases, how to apply Use Cases in agile environments, and what lies beyond Use Cases.      After listening to this episode, you'll understand: How the concept of a Use Case was first developed How to use Use Cases in an agile environment Why Use Cases can be a powerful tool in agile development  Show Notes The term ‘Use Case’ has become a common term even outside of software development. To project professionals, it’s a way of describing the interaction between a user/role and the system and is a powerful tool for analyzing and documenting requirements. But where did the idea of Use Cases come from?   The Birth of Use Cases In the mid-1980s, Ivar Jacobson was working in telecommunications and needed a way to describe the flow of events for a system function. Ivar decided to treat the system as a black box. He was less concerned about the internal working of the system and more concerned with how users would interact with the system and the value that users get from the system. From his abstraction, he created a generic construct (Use Cases) that could be used in many situations to describe a system’s functionality through its interaction with the user. Ian Spence and others helped iterate on the Use Case concept through the popular tool it has become today. Use Cases not only allow you to specify requirements; they are the beginning of test cases. As we describe the system interactions with Use Cases, the corresponding test cases emerge in a way similar to test first design.   Use Case 2.0 for Agility As Ivar began looking at Use Case analysis and development, he realized that each Use Case may be made up of multiple threads (flows of events, scenarios, or slices). The best approach is to start with the most important thread an only about 10% of threads represent the architectural baseline. By slicing Use Cases, the system can be developed and tested in small, valuable pieces that represent the architectural baseline. In looking at scrum, Ian Spence connected Use Case slices to a product backlog. Each slice represented one or more user stories. This makes it possible to scale by seeing the whole system through a Use Case Diagram and delivering the system in small slices that can be used in iterative development. Ivar and Ian wrote a book (Use Case 2.0) describing how to apply Use Cases in agile environments while including testing and reusable elements. Listen to Ivar’s full interview for more details and find out what lies beyond use cases. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_053.mp3 Related content: Episode 34 – Use Case 2.0   Z Your Homework Learn about applying Use Case 2.0 so that you can apply this approach in either traditional or agile environments. It allows you to see the big picture while also slicing large efforts into smaller, prioritized pieces. Links mentioned in this episode: Use Case 2.0 eBook (Free Copy) Ivar Jacobson website: http://www.ivarjacobson.com/resources/ Use Case 2.0 Training from Ivar Jacobson International   Dr. Ivar Jacobson Founder, Ivar Jacobson International Dr. Ivar Jacobson is a father of use cases, the Unified Modeling Language, and the Rational Unified Process. He has contributed to modern business modeling and aspect-oriented software development. He is the principal author of seven influential and best-selling books including Business Process Reengineering with Objects, Object Oriented Software Engineering: A Use Case Driven Approach, and Aspect-Oriented Software Development with Use Cases. Most recently, Ivar has been working on how to deal with methods and tools in an agile and lean way. 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. 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. The post MBA053: Use Cases and Beyond – with Ivar Jacobson appeared first on Mastering Business Analysis.

In this episode, Shane Hastie helps us to better understand how to use the Agile Extension to the BABOK and shows us how Business Analysts can benefit organizations through better portfolio management.    After listening to this episode, you'll understand: What kind of information is in The Agile Extension to the BABOK How to get and use The Agile Extension How to apply agile principles and backlog management to portfolios Why fixing portfolio management can have a big impact  Show Notes The Agile Extension to the BABOK® The team creating the Agile Extension to the BABOK® looked at some of the techniques that are unique to or applied differently to business analysis in agile environments. While it started as an effort by the International Institute of Business Analysis (IIBA), in 2011 it became a joint effort between the IIBA and the Agile Alliance. The agile extension provides more depth than is in the Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Whereas the BABOK provides information on what to do, the agile extension provides information on how to do it. Certified Business Analysis Professional™ (CBAP®) or Certification of Competency in Business Analysis™ (CCBA®) exams, only information in the core BABOK is examinable. Information in the Agile Extension will not be on the exam. There are two aspects to the Agile Extension to the BABOK; a broad guideline as to what you would be doing as part of analysis in an agile environment and a framework heavily influenced by Ellen Gottesdiener’s and Mary Goreman’s Discover to Deliver approach.   Discover to Deliver Projects or initiatives broadly have two aspects; discovery and delivery. When you’re doing analysis work, you’re either doing it for discovery (to figure out where next to go) or delivery (getting to the needed just in time detail). You would move between discovery and delivery at a regular cadence as an analyst. Information in the Agile Extension to the BABOK includes techniques for discovery such as personas and value stream mapping and techniques for delivery such as Behavior Driven Development (BDD) and Real Options. The extension describes the techniques and how to apply them.   Portfolio Management in Agile In agile, we need to be prepared to constantly adapt our plans. That approach works extremely well at the project or initiative level, but at an organizational level, budgets and plans tend to be longer term and less adaptable. The current rate of change often means that those plans are negated and organizations find it difficult to adapt quickly to changing market conditions. We need to take the concept of backlog management and apply it at a higher level to programs and portfolios so that we are able to adaptively respond to changes in the world around us. The traditional definition of project success has been on time, on scope, and on budget. Those constraints still exist, but they are not the driving factors today. Instead, we look at maximizing customer value and producing a quality product before focusing on the constraints within which we need to work. Changing to a value focus changes our mindset about the way we work. If we apply this thinking to the portfolio level, we are able to chunk it down and deliver the most valuable pieces first while constantly reviewing what we delivered and determining if we need to shift team backlogs to focus on something else.   Where Can We Start Impacting the Portfolio? The first thing we need to do to allow more adaptability at a portfolio level is to express the portfolio backlog in terms of discrete chunks of value. The chunks of the portfolio, which can be referred to as epics, features, or capabilities, should be no longer than half of the typical release cycle (often three months). These smaller chunks of value allow the organization to frequently get feedback and adjust their backlog. Consider the metaphor of a roadmap. If you know where you are and where you want to go, a roadmap can show you several ways to get there. You will need to adapt your journey based on your experience in the moment. You may need to take a different route based on traffic conditions or construction. Applying similar thinking to portfolio roadmaps, you need to have small enough pieces or value to be able to adapt your route and make rapid changes as the environment around you changes. Listen to the full episode to hear all of Shane’s advice. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_052__Portfilio_Management_and_th.mp3   Z Your Homework Find ways to visualize the backlog not as a linear queue, but as a map. You can do this through Story Mapping, a powerful yet often underutilized technique. Story Mapping is great for visualizing the work to create a shared understanding, seeing the big picture with the ability to also see the details, and provides an opportunity to prioritize group backlog items into MVP, releases, or features. What&#

In this poem adapted from Clement Clark Moore’s “A Visit from St. Nicholas”, we get the Business Analyst version and find out what happens when the BA visits a struggling project team.    A Visit From the Business Analyst ‘Twas the night before planning and all across the floor People were in a panic; the sponsor, stakeholders, and more. The team was certainly trying their best While secretly hoping to get out of this mess. The developers at their computers, not sure what to do Because the vision was lacking – no one had a clue. The product owner was sitting, with palm against face. Nothing made sense; not even the business case. When out from the conference room there rose so much chatter I looked up from my iPhone to see what was the matter. Up from my seat to the conference room I flew And peered in the window to see what I can view. The reflection from the whiteboard lit up faces and feet While attendees were sitting at the edge of their seat. And to whom were attendees all shouting hooray? It was none other than our friend the BA. With facilitation so engaging and the way he behaved I knew in a moment that our project was saved. More rapid than eagles the diagrams he drew To get better context and collaborate too. Now process flows, scenarios, context diagrams, and rules On whiteboards, on post-its, Visio and other tools. Up from their seats and out to the hall Now together in small teams, dash away all. As ideas they strike when you’re in the shower, When inspiration hits, you waste not an hour. So out from the conference room attendees they flew With a few great ideas and the analyst too. And then at their desks they collaborated more. The goal was now clear there was a buzz ‘cross the floor. As I spun around, turning my head Past flew the business analyst with markers of red. He was dressed in a suit, how smart he did look; Carrying a laptop and markers and a leather notebook. A stack of post-its he held in his hands. He was a rock star with plenty of fans. His eyes how they twinkled giving an inspiring talk. His movements were confident from his stance to his walk. His words like a song the lyrics we all know. His network was vast, not one was a foe. The way his mind worked, he knew what to do; He saw the big picture, and details too. I went to shake his hand for all he had done; He just cocked his head saying “To me this is fun”. He had a smile on his face and a grip of my hand. I smiled when I met him; we can go on as planned. With a shared understanding and the goal so clear, Soon gave me to know I had nothing to fear. He wasted not a word but cut right to the chase; He helped adjust the backlog and cheers filled the place. I asked him candidly “how’d you pull off such a feat?” He answered quite simply “it’s easy – I cheat”. “When people collaborate and work well together We accomplish our goals. Alone? No, never.” But I heard him exclaim as he walked out of sight Let’s change projects for good . . . and to all a good night. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_051__A_Visit_From_the_Business_A.mp3   Thank you for listening to the show. Merry Christmas and happy holidays however you celebrate. I wish you, your family, and your organization a joyful and prosperous New Year!     The post MBA051: A Visit From the Business Analyst appeared first on Mastering Business Analysis.

In this episode, David Mantica shows us why it’s important for a Business Analyst to be T-shaped and how to develop the broad professional skills needed to be successful.    After listening to this episode, you'll understand: What a referent power base is and how to use it The five tangible professional skills you need to be successful How to make changes and quickly adapt to your environment What steps to take to build your professional skills  Show Notes The business analysis profession is built upon being T-shaped. That means that the position requires both deep technical knowledge along with the core analysis skills and a broad set of professional skills and human understanding to deal with the complexities of the role. T-shaped skills are critical for problem-solving positions, creative positions, and roles that need to bring alternate sides of a table together to collaborate and quickly come up with a high quality solution.   The T-Shape When we look at a T-shaped employee, the top part of the T is comprised of two sections. On one side is the whole self and the other side is professional skills. The whole self deals with your understanding of stress. That includes an understanding of stress management and the way the brain processes information as well as nutrition and health. The site also includes a servant and pay it forward mindset. The whole self is important because it allows you to deal with the stress that could otherwise lead to illness and loss of productivity. It also helps you to better understand some of the biases that influence our decision making. Some tools for developing the whole self include meditation and even hobbies and activities outside of work. These tools allow you to enhance your cognitive skills which will allow you to be more effective in your role. There are real and tangible benefits to developing this side. The professional skills side is made up of five skills that build upon each other. It starts with emotional intelligence which then builds and the conflict management. From there you build facilitation and negotiation skills. From those skills you develop change management and finally influencer skills. These five skills are the bedrock upon which you need to build your professional toolkit you need to be successful. The five professional skills The foundation of the professional skills side is emotional intelligence. Emotional intelligence ties into biochemical elements as well as professional management. The biochemical portion includes an understanding of brain function and reactions to stress including the fight or flight response. It also includes tools that you can use to cope with some of those unconscious reactions. Emotional intelligence has four levels. Those four levels are self understanding, self management, situational understanding, and relationship management. You use emotional intelligence when you’re managing conflict, when you’re negotiating, when you’re dealing with change management, and to influence others.   Soft skills are hard The five areas on the professional skills side can be difficult to develop. It’s not as easy as learning a new technique. Start by developing emotional intelligence. This can be done by creating a better understanding of yourself, your hot buttons, and how you deal with others. Taking time to be introspective and reflect on your thoughts and behaviors can help develop emotional intelligence. The next step is to use stretch assignments. Stretch assignments are great tool to get someone to go beyond their limits. The stretch assignment may put you in an environment or situation with which you are unfamiliar. You may even make mistakes and fail. The mistakes and failures allow you to learn and adapt as long as you are provided a safety net in the support you need. This creates a learning experience that will make you more productive and effective going forward. Role-playing is also an effective way to develop professional skills. Role-playing allows you to practice certain skills in different situations and allows you to quickly get feedback and adapt. The fourth action that you could take to develop your professional skills is to find a mentor. Find someone who is strong in the skills that you’re trying to develop and engage in a mentoring relationship. Of course, reading and taking training classes can help you to understand theories and practice some of these soft skills. Understanding the theories behind some of these soft skills allows you to develop your awareness and self-awareness and recognize the behaviors in yourself and in others so you can take action to adapt. Listen to the full episode to hear all of David’s tips and advice for building your skills and career success. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_050__T-Shaped_Business_Analyst.mp3   Z Your Homework On the whole self side . . . Read Dan Brown’

In this episode, Hans Eckman helps us to understand how the Business Analyst is perfectly suited to be the first line of defense in preventing security breaches. Hans also shares some approaches and advice for handling security related requirements.  After listening to this episode, you'll understand: How your application may be used to gain access to another system How to use systems thinking to discover security needs Why records retention is an important security consideration Where to start when looking for security needs.  Show Notes By the time you tried to build security into your product, it’s probably already too late. The business analyst needs to be the advocate for security-related requirements as well as fraud prevention. The business analyst also needs to understand what data is at risk and the impacts of data retention. It’s often not your system that gets breached but another system on the network and the interconnectivity of applications on the network have made all systems vulnerable. The business analyst should understand the relationship and connectivity between applications to appropriately understand the risk. Think not only of the system aspect but the process as a whole. We need to consider all aspects of the process including the technology, the access of internal personnel, and paper used in the process. Take ownership and consider the security-related risks for the entire process to develop security-related nonfunctional requirements as well as record retention requirements.   Where do we start? A good place to start is with the context diagram. This helps you to see the interrelation between the people and the systems within a process. You can then start drilling down to identify the risk and focus on the highest value and highest risk areas. Once you identify the high-risk areas, you can work with subject matter experts from security teams to better understand security policies and record retention requirements. Developers and architects can also help you to understand security needs. The basic goal of security is to keep people out. However, there will be people who need access. As a business analyst, you need to understand the various roles and levels of access needed. We also need to understand what needs to happen when the user makes a change. Do we need to log that change or update the version? Start to think of the data as an actor itself. This goes beyond abuser stories which we discussed in episode 43. This access control model will drive out most of the value you’ll have in a project.   Capturing Requirements When it comes to capturing some of the security requirements, we often use functional or nonfunctional requirements. In agile, you can do the same with user stories or acceptance criteria. A good approach is to get together with a tester any security representative to try and pick apart the requirements and find security holes. Any time you can build a set of baseline security requirements, you will likely be able to reuse those requirements for future enhancements or other projects. Essentially, you are establishing the security and records retention policy in a set of requirements that can be maintained in a repository for future use.   With the prevalence of identity theft and stolen data, guarding against a security breach is everyone’s responsibility. The more we learn from each other, the harder it will be for criminals to gain access to critical data. Listen to the full episode to hear all of Hans Eckman’s advice for defending against a security breach. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_049__The_First_Line_of_Defense_A.mp3   Z Your Homework We don’t have to learn by ourselves from our own mistakes. There are plenty of resources on the Internet, through podcasts, through industry associations such as the IIBA, and conferences that we can use to build our skills and share information. Leverage your network and the work that’s been done by others; start with some of the effective practices in your industry. What’s your take? What’s your approach to discovering and capturing security requirements? Please share your tips, experience, and comments in the section below.   Links mentioned in this episode: Hans Eckman’s website Hans’ presentation slides and video Hans Eckman GVP at SunTrust Bank Hans Eckman provides linchpin leadership and consulting for rapidly evolving companies, with 19 of his 25+ years’ experience creating workflow & support optimization solutions across diverse industries. Hans rejoined the Innovation Programs team at SunTrust Bank, where he helps develop disruptive programs and products that drive innovation, process improvement, and engagement across the enterprise. Hans co-founded the SunTrust BA Center of Excellence. His presentations can be viewed at http://hanseckman.com. Thank you for listening to the program

In this episode, Jeff “Cheezy” Morgan helps us to understand why the Minimum Viable Product (MVP) concept is so important and how to find the MVP for your project.      After listening to this episode, you'll understand: The real meaning of Minimum Viable Product (MVP) How to use the MVP to ensure you build the right solution How to find the MVP – even on legacy projects  Show Notes Most teams have a misconception about what the Minimum Viable Product (MVP) is. The MVP is really the simplest way possible to prove a hypothesis. That hypothesis is often related to the software solution we’re trying to build and our assumption that the solution will meet customer needs. Finding the Minimum Viable Product allows teams and organizations to create the simplest thing possible to prove or disprove their assumption that their solution is viable by getting customer feedback. The thought behind the MVP is to rapidly get feedback from customers in the cheapest and fastest way possible without having to build a full, final product that might not meet customer needs. Some examples of companies that used the MVP concept are Apple, Zappos, and Dropbox. Zappos, an online shoe retailer, started without have any shoes in stock. When a customer placed an order, they went to a local shoe retailer to purchase the shoes and sent them to the customer. For Zappos, their MVP was a website from which customers could see information about shoes and place an order. They used this MVP approach to prove that customers would be willing to buy shoes online. When Dropbox started, they weren’t sure that people would be comfortable storing their files on the cloud. Instead of investing to build out their infrastructure before they knew that their product would be viable, they started with a very small MVP; a video. They went live with a website and a three-minute video.   MVP isn’t just for startups and new products Many organizations don’t use the Minimum Viable Product concept because they don’t think it applies to them. They may be working on legacy systems and established products with existing customers. The MVP requires a different way of thinking about products and solutions. Any enhancements to existing products or existing systems are unknowns and can be tested using an MVP. We need to think about shorter release cycles and simple ways to test for some of our hypotheses. MVP allows you to make sure you’re on the right track and course correct when needed very quickly and at lower cost. The belief that we know what the customers want has been proven wrong again and again. There are hundreds of products in the market with features that are rarely or never used.   Finding the MVP To discover the MVP, have an experimentation mindset. Start with a hypothesis stating we expect to happen by implementing a solution and how we will measure the outcome. Once you have a hypothesis, think of small ways that you can test that hypothesis to prove (or disprove it). Question assumptions about what the customer needs and would find valuable and come up with small, cheap experiments to prove Possible options may include simple prototypes (physical or paper) or anything you can show to customers to get feedback and make adjustments based on that feedback. One possible way of expressing a hypothesis is: We believe that by [creating this solution] we will [solve this problem] which will have [these benefits] as measured by [these metrics] Listen to the full episode to hear all of Cheezy’s tips. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_048__Finding_the_MVP_-_Interview.mp3   Z Your Homework Understand that just because we believe users will value something doesn’t mean it’s correct. Question that assumption and come up with ways to test that idea. Become familiar with continuous delivery as the ultimate form of MVP. This is the essence of putting small things in front of users and getting feedback to make small adjustments. What’s your take? Have you used any techniques to find the MVP or similar approaches? Have you had any challenges in discovering the MVP? Please share your experience and comments in the section below.   Links mentioned in this episode: Cheezy’s website CheezyWorld ExtremelyCheezy YouTube Channel   Jeff "Cheezy" Morgan Chief Technology Officer of LeanDog Jeff “Cheezy” Morgan is the Chief Technology Officer and a co-founder of LeanDog. He has been teaching classes and coaching teams on agile and lean techniques since early 2004. Most of his work has focused on the engineering practices used by developers and testers. He has authored several popular Ruby gems used by software testers and the book Cucumber & Cheese – A Testers Workshop. Twitter 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. Also, reviews on

In this episode, we’ll explore the elements that make up the DNA of a great Agile Business Analyst, help you understand the impact of having (or not having) these traits, and find out what you can do if you or other team members don’t have these traits as part of their DNA.    After listening to this episode, you'll understand: Understand the mindset and key traits you need to become a great agile business analyst Discover how combinations of traits will allow you to bring more value to your team and organization Find out what you can do if you don’t have these agile characteristics as part of your DNA  Show Notes Agile is more than a way of delivering a product to customers faster. It’s a mindset, a philosophy based on a set of values and principles. The best Business Analysts in agile environments have several key characteristics in common that allow them to bring value to their teams and organizations. Watch this video of the presentation. http://traffic.libsyn.com/masteringbusinessanalysis/Video_-_DNA_of_a_Great_Agile_Business_Analyst.mp4           Z Your Homework Reflect on your own traits to determine if you have any weaknesses related to the key traits and behaviors of a great agile business analyst. For any shortcomings, devise a plan to pair with someone or develop your skills in that area. 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. 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. The post MBA047: The DNA of a Great Agile Business Analyst appeared first on Mastering Business Analysis.

In this episode, Bob Galen help us to better understand the role of the Product Owner and how Business Analysts can best support the PO and the team.  After listening to this episode, you'll understand: The role and responsibilities of a Product Owner The four quadrants that make up the Product Owner role How a business analyst can best work with and support the Product Owner  Show Notes The Product Owner role There’s a person referred to as a Product Owner on Scrum teams, but in Bob’s view, it’s not a stand-alone role; they need help. It’s extremely difficult to find someone who is outstanding in each of the four quadrants. They will need complimentary help to supplement those areas where they have weaknesses.   If a Product Owner (PO) has strong product management skills, they may be weak in Business Analysis. A Business Analyst can partner with the Product Owner by breaking down features and capabilities into smaller chunks that the team can deliver in small iterations, creating meaningful user stories or use cases, and helping the PO understand impacts and dependencies.   In some organizations, instead of having a Business Analyst on the team, there’s a pool of Business Analysts coupled with the product organization from which the Product Owner can pull for support.   Sometimes, organizations convert Business Analysts to Product Owners. In those cases, the Product Owner has strong Business Analysis skills, but lack strength in product management or another area.     The Four Quadrants The Product Owner role is an aggregate role and the Business Analyst can partner with the Product Owner to complement the role with their skills. Leadership: This quadrant includes having the ability to create an inspiring vision, leading by example, defending the team, and being viewed as a leader in your organization. A person weak in this quadrant might augment their ability to create an inspiring vision by inviting other leaders in to create and communicate that vision and the ‘why’ behind it.   Business Analysis: This quadrant includes story writing and defining acceptance criteria. It may also include approaches such as modelling and behavior driven development (BDD). A Product Owner with weak Business Analysis skills may partner with a Business Analyst or Quality Engineer to support this area. One of the challenges for a traditional (waterfall) Business Analyst moving to agile is in the shift to creating lightweight requirements with the team.   Project Management: This quadrant includes understanding the backlog and linkages between backlog items, and addressing risk. It also involves the ability to forecast delivery or functionality based on the backlog and team’s ability to deliver. The Business Analyst can also supplement the Product Owner in this area as could a Project Manager or someone with similar skills.   Product Management: This quadrant includes roadmaps and working with customers and stakeholders. Often this is outwardly focused.     Product Owner: “BA, you complete me” Business Analysts and testers have the ability to connect the dots. They understand the lifecycle from concept (ideation) to cash (delivery to end user). Having this end-to-end view and sharing it with Product Owners will help ensure the delivery of value to customers.   Sometimes, teams focus too much at the story level without seeing the big picture. Try to rise above the story and understand the goal. Make the demo yours. Focus not on the stories, but the story behind the stories and make sure the team sees the big picture.   As a Business Analyst, you need to bring curiosity and openness to the team. Ask why and don’t be afraid to suggest that the team shouldn’t do something. Listen to the full episode to hear all of Bob’s tips. http://traffic.libsyn.com/masteringbusinessanalysis/MBA_046__The_Product_Owner_-_Busines.mp3 Z Your Homework We’ve lost the essence of the User Story; the story. Start talking more and writing less. Richer conversations around the narrative of the story and ‘why’ behind each story will create a better understanding between the Product Owner and the team. The Business Analyst should be a storyteller can convey the goal and intention behind each User Story so that the development team can create the best solution.   Links mentioned in this episode: Bob’s website Bob’s podcast Meta-Cast Books by Bob Galen   Bob Galen President and Principal Consultant of RGCG, L.L.C. Bob Galen is the President of RGCG, L.L.C., an agile methods coaching & training consultancy. He is a deeply experienced agile coach who is active in the agile community and regularly writes & teaches on all topics related to the agile methods. Bob wrote the book Scrum Product Ownership, which is focused on that role and driving value in team delivery. He is a frequent contributor to BA Times and often speaks at industry conferences.

In this episode, Bob Woods helps us understand how a Business Analyst can complete an agile team and dispels some of the myths and misconceptions about agile.   Bob Woods Agile Coach & Delivery Manager at MATRIX Resources Bob Woods is an Agile Coach and Delivery Manager at MATRIX. He has been in IT for over 18 years serving in such roles as Sr. Systems and Networking Engineer, Project Manager, Program Manager, and Agile Coach. Bob has spent years working with organizations on collaborative lean development, Agile testing techniques, requirements analysis, project envisioning, relationship management, and Agile leadership. TwitterLinkedIn  After listening to this episode, you'll understand: The myths about the role of a business analyst in agile The realities of being an Agile BA and how a BA can support an agile transition How a BA can complete an agile team  Show Notes In many organizations transitioning to agile, the Business Analysts feels like either they have no place or are unsure what their role should be. As a result, some myths about the role of a Business Analyst on an agile team are common. The reality is that organizations that are embracing the agile concepts are finding that the Business Analyst is a critical role on agile teams. There are types of Business Analysts with the right mindset to go from a strict waterfall environment to an agile environment and really help the team to be successful. A strong Business Analyst with the right mindset can also help dispel some of those myths about agile that are holding organizations back from transitioning or seeing the benefits of agile.   Myth: There’s No Documentation in Agile This is a common misconception. Documentation is needed in agile, especially in regulated environments. However, it’s not the same type of documentation in traditional (waterfall) approaches. The focus is on Lean documentation. Business Analysts can help by understanding documentation needs and prune it down and create lean, valuable documentation in the right ways so we can still be compliant and do the right thing. Think of documentation as the simplest thing that will work done just in time.   Myth: There’s No Role for a BA on an Agile Team The fact that the Business Analyst is quickly becoming a critical role for agile teams. There are strong parallels between what a great agile team does (adapt quickly, work with the business daily, deliver business value, collaborate, continuously improve, etc.) and the role of a great Business Analyst. The Business Analyst can use their skills in these areas to create a high performing agile team. What about the Product Owner? There seems to be a lot of overlap between the role of the Product Owner and the Business Analyst. While there can be some overlap between roles, the Product Owner is often more outward (customer) facing while the Business Analyst is often more inward (team) facing or right in the middle. Product Owners can focus on product vision, ordering the backlog to achieve the highest value, and even marketing and other operational aspects of delivery. Business Analysts often create models to develop a shared understanding of customer needs and other approaches to help decompose and refine small pieces of value (via User Stories or Use Cases) that the team can deliver. Image from Bob Woods’ Agile 2015 Presentation   Where overlap in the roles exist, there’s an opportunity for the Product Owner and Business Analyst to collaborate and work together to help the team deliver superior value to the customer. Each can be both inward and outward facing, just to different degrees.   The Mindset Shift The change in mindset that needs to take place for a Business Analyst to be successful in an agile environment includes a shift towards lean, simplicity, and transparency. This also requires maximizing the amount of time spent on the right things. Remember . . . It’s not about you, it’s about the team. A great Business Analyst will use their skills to set the team up for success. In agile, you either succeed as a team or you fail as a team.   Agile BA, You Complete Me A great agile Business Analyst can complete a team. A BA can help the team to collaborate better, create a shared understanding, be a final set of eyes on quality, and help the team focus on delivering the right value to the customer. “Having a BA on the team is not a Get Out of Engagement Free card for the Product Owner.” However, it’s important to note that just because you have a Business Analyst on the team, that doesn’t mean you can drop some of the activities important to each agile team member’s role.   Z Your Homework Read the book, Discover to Deliver and learn about the Seven Product Dimensions and structured conversations. Help individuals focus on the seven dimensions that make up a great product. Continue to provide a leadership

In this episode, Glenn Burnside talks to us about business process automation; what it is and how to get started with a BPA effort.     Glenn Burnside Executive Vice President of Operations at Headspring Glenn Burnside has been delivering software projects and leading development teams for over 15 years, ranging from high-speed data acquisition libraries to global e-commerce solutions, as well as enterprise products for both the medical and financial industries. Glenn is also a regular speaker at community user groups. Twitter  After listening to this episode, you'll understand: The difference between business process analysis, process management, and business process automation How to identify opportunities for process automation How to create a business case for business process automation What to look for in an automation tool  Show Notes Business process automation (BPA) can lead to increased quality, higher throughput, and increased capacity to take on more business. BPA is any undertaking in which you want to apply automation tools to existing activities that are performed manually today. Process automation often leads to faster processes with less errors. In some organizations, governance over the process (Business Process Management) doesn’t exist. That’s where business process automation can be used to not only accelerate the process, but to also create the rules and governance around a process. Automation can also provide metrics and intelligence about the process that can be fed back into analysis to continuously improve the process.   Analysis is Key In order to have a successful business process automation effort, you need to start with an analysis of the process. Business Process Analysis (the ‘other’ BPA) is critical for two reasons. First, the analysis determines the specific process to automate. Secondly, it ensures that you optimize the process definition and quality of outcomes you want to achieve from a process before trying to automate it. Without analyzing the process first, you may end up automating a process that is inherently ineffective or ought not to be done in the first place. Don’t forget to observe the process yourself so you can see the true process. “The system of record for an existing business process is the process itself, not anyone’s recollection of it.”   Where to Begin In any workflow, there are points at which humans need to make informed decisions based on heuristics or expert judgment. The decision points in this process are often difficult to automate. Some of the easiest areas to automate are activities that are administrative in nature, data capture, and the conveying of information to the right end points for humans to make the right decision. The first place to look for automation opportunities and areas of information transfer, administrative activities, and data capture and logging. Understanding the queues and data validation components of a process will also help in understanding what to automate. Let machines do what they’re good at, which are objective, repeatable activities and let the people focus on where they add value, which are the expert, cognitive thinking processes. The next generation of machine learning will change the way we automate processes. Analysts will spend more time defining the decision making model and then allowing the machine learning platforms to start applying that model to large data sets rather than trying to rely on human expertise for every decision.   The Business Case for BPA The value proposition for automating a business process is waste elimination and increased throughput. Understanding the value added activities in a process and automating them allows for reduced errors due to manual intervention and an accelerated delivery of value. BPA can help reduce or eliminate many of the lean forms of waste such as wait time, hand-offs, and overproduction. You can increase the delivery of value without increasing headcount and free individuals to contribute more value to an organization in ways that only humans can do. BPA projects can pay for themselves very quickly through increased capacity and the ability to take on new business. Business process automation can lead to increased quality, higher throughput, and increased capacity to take on more business. Begin by analyzing the process to identify waste, understand value added activities and identify opportunities for automation.   Z Your Homework When analyzing a process, you’ll need to go observe the process for yourself. Often, there’s a vast difference between a documented process, what a manager says a process is, and the actual process. Without this knowledge, your analysis is likely to be incorrect. What’s your take? Have you used any business process automation tools or worked on a BPA effort? Please share your experience and comments in the sect

In this episode, Judy Neher shows us how to use an approach that she calls Abuser Stories to address potential security gaps in your system. Judy Neher President/CEO of Celerity Technical Services, Inc. Judy Neher is an agile trainer and coach, passionately transforming government software teams from traditional development practices to agile practices for the last 12 years. Judy has over 27 years of experience with the Intelligence Community as a mathematician, computer scientist, traditional software manager, and ultimately, as an agile coach, trainer and leader. Twitter  After listening to this episode, you'll understand: How to apply Abuser Stories to address security features How and when to include security related non-functional features in your definition of done, User Stories, and Abuser Stories What tool you can use to identify security features for your software How to prioritize security features  Show Notes Abuser stories take the concept of user stories and flips it on its side so we start thinking from a hacker’s perspective. Instead of looking at who are our users, we look at who are our adversaries. Who wants access to our data, who wants access to our systems, and what is their motivation? Abuser stories allow us to put the bad guy hat on to help us identify potential security gaps and other risks. It allows us to look at our systems from an attacker’s perspective. An example of a typical user story might be: “As a Facebook user I want to be able to log into Facebook so that I can get access to my profile.” That story inherently has a lot of places were a hacker would want to gain access. We can take this user story and look at it from an attacker’s point of view. An abuser story might be “As an attacker I want to be able to get a user password so that I can access their personal data.” This approach allows us to understand where we might introduce vulnerabilities into our system by implementing a simple login story. It allows us to identify potential threats and understand how to address those threats. Abuser stories also help us understand the threat and how to prioritize features to address those threats based on the potential risk. Abuser stories will go on the product backlog along with your other user stories. As were defining our features, we’re looking at the security around those features and were able to prioritize the security around those features based on the threat. If the threat is likely to happen and will have a high impact, the abuser stories will be prioritized higher.   Acceptance criteria With user stories we have acceptance criteria to confirm that the story is done and acceptable. With abuser stories, the details are defined by reputation criteria. How can we define that the attack is not possible? The reputation criteria allows us to prove that the threat has been mitigated. We can include security needs in a variety of ways. Security concerns can be addressed as part of user story, as part of your definition of done, or as part of the acceptance criteria in a user story. Judy advises including security professionals in your story refinement sessions to help you identify specific security needs and perhaps brainstorm some of the abuser stories. Story demos are also a great place to include security professionals to provide feedback on potential threats and risks. Due to the lack of availability of security professionals, everyone on the team needs be responsible for system security. Security cannot be an afterthought. That’s where abuser stories can help you to think differently about potential threats.   Abuser stories in practice Whereas user stories can be prioritized based on business value, abuser stories carry negative business value. Consider the amount of damage it would cause if an attacker gain access to your data. The goal in each sprint is to optimize the net business value. If there is a low likelihood of an attack taking place and only a small amount of potential damage, the negative business value would be low. The use of personas for potential internal and external attackers can also help you discover and address threats.   Z Your Homework Think about both internal and external threats to your software and create personas to represent individuals who may intend to exploit your system. Identify features and user stories with potential risk in your backlog and create abuser stories to address security gaps. What are your thoughts? Do you have any tips address system security? Have you used any of the techniques Judy mentioned? Please share your experience and comments in the section below.   Links mentioned in this episode: Judy’s Website Celerity Technical NIST Security Controls Catalog 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. Also, reviews on iTunes are highly appreciated! I rea

In this episode, author, speaker, and Kanban pioneer Jim Benson advises us to ditch User Stories and shows us what to do instead. Jim’s recommendation: use the scientific method. Jim Benson CEO of Modus Cooperandi Jim Benson is an internationally recognized speaker and author. He is a pioneer in applying Lean and Kanban to knowledge work, and his books include Personal Kanban and Beyond Agile. Jim is CEO of the collaborative management consultancy Modus Cooperandi and founding partner of Modus Institute. Twitter http://traffic.libsyn.com/masteringbusinessanalysis/MBA_042__Stop_Using_User_Stories_-_I.mp3  After listening to this episode, you'll understand: Why Jim recommends against the use of User Stories The problem with User Stories How to use the scientific method for better results The impact of using a hypothesis instead of a user story  Show Notes In the last few episodes, we’ve discussed how you can be effective using User Stories. Now, thought leader Jim Benson suggests that we should stop using User Stories in favor of an approach better aligned to the scientific method.   The Problem with User Stories Jim’s main issue with User Stories is that they’ve moved away from their original intention and become functional requirements in a pretty wrapper. Developers read the User Story (functional requirement) and build it. This assumes that the who, what, and why of the User Story is correct and it will properly address the business goal. We started using User Stories because we lacked empathy towards our customers. However, we still took our own assumptions that we used to put in the detailed design document and put it in the wrapper of a User Story.   Use a Hypothesis In reality, everything we’re doing is an assumption or a hypothesis. When we present ideas as a hypothesis, we’re saying three things: I think this is true, but I’m not sure This is the hypothesized solution for the hypothesized problem I’m giving you a set of unit tests upfront A well-crafted hypothesis will encapsulate everything that agile is supposed to do in a more honest way. The original thought behind User Stories is that the team could write them. As we’ve moved away from that original intent, the Product Owner often writes the story with their assumptions, pushing them on to the team. Using a hypothesis allows us to have better conversations about our assumptions and goals.   Getting Started To get started using a hypothesis instead of a User Story, we must first understand the organization’s goals for the next three months. This is what the organization wants to accomplish in the next three months, which Jim calls “strategic intents”. Get everyone in the organization together to discuss the strategic intents so that everyone is aware of the goals. Everyone can then share their ideas as to how to support those strategic intents. Ideas are then gathered into big bets and small bets. Big bets are similar to projects, but Jim finds that if you call them bets, people make them smaller (up to one month). All of the ideas and strategic intents are based on hypotheses. Because most organizations don’t do this, you can start by decomposing your User Stories by challenging your assumptions about who the customer really is, what you’re trying to achieve, and how you would test that. Then take that information and create a hypothesis.   Hypothesis Design A hypothesis might be stated as: We believe that if we do <what the action is>, we will get <result>, and we will test it by <metrics, criteria, and other tests>. You should also think about and articulate who your customer is. The hypothesis has initial acceptance criteria and tests to understand when the code is complete and working properly. It also has acceptance criteria and metrics based on after the solution is implemented and people interact with it to understand how (if at all) the solution impacts the strategic intents. This allows organizations to rapidly learn and adapt. A hypothesis still follows the three “Cs” of a User Story; Card, Conversation, and Confirmation. The hypothesis should be short (fits on a card), it needs to be discussed to understand and challenge assumptions (conversation), and it has acceptance criteria (confirmation). A team can use spikes to experiment and learn what will work. Jim’s approach to using a hypothesis drives collaboration, adaptability, and creates a learning organization.   Z Your Homework Take a few User Stories (especially those that the team is doubtful about) and rewrite them as hypotheses. Treat it like a guess that you can prove or disprove and learn something. What are your thoughts? Have you used any variations on User Stories? Please share your experience and comments in the section below.   Links mentioned in this episode: Jim’s Website Modus Cooperandi Jim Benson’s books on Amazon Personal Kanban website Thank you for listening to the program To

In this episode, consultant and author James Robertson helps us to break down user stories into smaller, more manageable pieces. He also shows us how to look critically at user stories to make sure they don’t specify a solution. James Robertson Co-founder of The Atlantic Systems Guild James Robertson is a consultant, teacher, author, and project leader whose area of concern is the requirements for products and the contribution that good requirements make to successful projects. He is the co-author of the best-selling book “Mastering the Requirements Process, Third Edition”, which provides guidance on finding requirements and writing them so that all the stakeholders can understand them. He also co-founded the Volere approach to requirements engineering.  After listening to this episode, you'll understand: How to get started with user stories How to break down large, high level stories How to look critically at user stories Why the second best user story may be better  Show Notes We often see people creating initial user stories and then treating them as if they are cast in concrete. Instead, think of user stories as an opportunity to explore the real need. Think of agile development as two parts; discover and deliver. Use the story to discover the real need. Start by think of it as not a user story, but as a story of a need. Using “I want” in a story sometimes leads us to prematurely identify a solution. To instead focus on the real need, switch to “I can”. After the story is initially written, it needs to go through processing or refinement. The initial story does not need to be written so as to fit in a single iteration. It can be later refined and right-sized. Focus on the business or user need and keep the stories high level. After you have the initial story, you can refine and split the high level story (epic). One way to do this is to look at the user role to identify if there are different roles that have a similar need and split the stories based on that more detailed role. The key is to make sure the epic is the right story. The most common format for a user story is: As a <role>, I want <need> so that <goal>. When you look critically at the user story, make sure the role is valuable to the organization, the need is truly a need and not a solution, and that the goal is valuable to the role. Look for the second right story; the story that digs deeper to discover the real need. Often, people assume that they know the answer. Challenge assumptions to find a user story that expresses the real need and allows software engineers to find the right solution.   Z Your Homework 1. Don’t write stories starting with “I want” because that leads you to a solution. Instead, start with “I need” or “I can”. 2. Look for the second right story. Look critically at your user story and identify ways to improve it. 3. Don’t forget non-functional requirements. Review your user stories to make sure and non-functional aspects are identified. What’s your take? What do you find challenging about User Stories? Please share your experience and comments in the section below.   Links mentioned in this episode: James’ Website Volare Requirements Pearson LiveLessons video course YouTube video: Perfectly Formed Requirement YouTube video: Brown Cow 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. 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. The post MBA041: What’s the Second Best User Story? appeared first on Mastering Business Analysis.

In this episode, Leslie Morse helps you get started with User Stories – what they are, common pitfalls, and how to know when a story is ready. Leslie Morse Managing Director at Davisbase Consulting Business Analyst by trade, collaborative entrepreneur at heart; Leslie has over 15 years of experience in information technology, digital business strategy and consulting services. Her diverse experience across business and IT roles in start-up, small business, and Fortune® 50 organizations allows her to quickly assimilate to new client situations and rapidly uncover ways to add value. TwitterLinkedIn  After listening to this episode, you'll understand: The three “C’s of a user story How user stories can increase outcomes while reducing output Common pitfalls when using user stories (and how to avoid them) How to know when a story is ready  Show Notes User stories are pretty simple; they’re nothing more than a construct for phrasing on option for something we could deliver to satisfy a customer. This differs from what we would traditionally think of as a product or software requirement. The word “requirement” is not the most appropriate because of the negotiable and adaptable nature of stories. The most commonly used format for user stories has three parts; a role, a function that the role is trying to accomplish, and why they are looking to accomplish that function. Teams often use the “As a <role>, I want <what they want to do> so that <goal>”. User stories help us to understand the who, what, and why behind the solution. Some teams prefer to put the “why” first because that is often the most important component of a user story. A user story is still incomplete with those three parts. User stories need to have acceptance criteria or conditions of satisfaction so that we understand what kind of a solution will meet the customer’s needs.   Acceptance Criteria The simplest way to start using acceptance criteria is with a bulleted list of what would need to be true for the solution to be acceptable. Acceptance criteria gives us boundaries for what’s good enough, which helps us understand when to stop and avoid gold plating the solution. Acceptance criteria sets the parameters for what is “just enough”. Think of acceptance criteria as a checklist of things you’re going to look for in order to make sure you have built the functionality to satisfy the user’s needs. It’s the first level of extra detail and clarity that gives us context for what it is we’re looking to build.   The story alone is not enough Even with the acceptance criteria, a user story cannot convey all of the information needed to develop a solution. Some teams make the mistake of trying to imbed all of the details and specifications in the user story. Agile thought leader Ron Jeffries talks about the three C’s of user stories. This approach helps us to better understand the intent of a user story. The three C’s are: Card, Conversation, and Confirmation. We’re looking for user stories to fit on a small index card. While often the current practice is to enter the user stories into a software tool, keep the spirit of the physical card alive and keep your stories brief. A physical card that can be read from several feet away forces the user stories to be concise and exclude a lot of the detail. If you can’t Tweet your user story, it’s probably too long. Cards also serve as a physical placeholder for a conversation. The card is a single atomic product option about which we can have a conversation. In agile, documentation should be the result of a conversation and collaboration instead of a replacement for it. Cards don’t need to include a lot of the detail because the detail is provided through a conversation. The confirmation is the acceptance criteria we mentioned earlier. It is used to confirm our understanding of the story and helps drive the conversation.   Why not create and refine all your stories upfront? A large component of agile is about risk mitigation and cost of delay. Think of user stories as inventory. The more inventory you have in the warehouse, the more capital you have tied up in that inventory and if something changes, your inventory will go to waste. The more we invent in this inventory of information, we’re increasing the risk that we’ve spent time building out details that we’ll never actually use. We need just clarity of user stories in the backlog for this release horizon.   INVEST in good user stories Bill Wake created an approach for identifying the qualities of a good user story using the acronym INVEST. Invest stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Independent implies that each story is an independent piece of functionality that could work on its own. Negotiable means that stories

In this episode, Cormac Walsh helps us to better understand what big data is, why you should care about big data, and how to get started. Cormac Walsh Head of Data Analysis at Fonacta Enterprise Solutions Cormac Walsh is the head of data analysis at Fonecta Enterprise Solutions where he helps organizations by producing quality and actionable insights. Fonecta Enterprise Solutions is a leading provider of data driven insight. They provide the right answers to industry, allowing them to make better decisions. Cormac frequently writes and speaks on big data topics. TwitterLinkedIn  After listening to this episode, you'll understand: What big data really is The difference between a Data Scientist and an Analyst How to get started using big data  Show Notes What makes data big data? Big data characterized by a diversity of sources and a correlation and connection of different data sources together. It doesn’t matter how much data you have; if there isn’t diversity of sources, it’s not big. As you add an increasing number of diverse sources that make sense together and the data quality is sufficient, then you have the opportunity to explain past events. Of course, what people really want is the ability to predict what’s going to happen in the future. With sophisticated modeling of data, you have the opportunity to start predicting the future for short to medium horizons. Similar to predicting the weather, the farther out into the future you attempt to predict, the higher the risk that the predictions will be inaccurate. Big data can be used for everything from ice cream sales and positioning of gas stations to predicting crime and reducing credit card fraud. The first step is to understand what problem you’re trying to solve. From there, you can begin to determine what data is available internally to help address the problem. If needed, it’s fairly easy to add data from external sources to improve the quality and depth of the data you have. Once we find the data that we have, we bring it into a secure and coherent environment and then work on how to use the data to achieve the desired results. It’s not just the data; just giving people numbers doesn’t work. Insight doesn’t come from interacting with a spreadsheet. Information needs to be presented in a way that promotes a playful interaction with the data.   What You Need to Know About Big Data A word of caution . . . In any project or experiment with big data, the client must be made aware that too often, these types of projects turn into huge efforts without seeing a benefits for a long time. This is usually due to far too ambitious and aggressive scope at the beginning of the project. To address this, understand at the start of the project what the end point should be and then distill the requirements down to find the simplest thing that we can measure to which we can very quickly access. After you achieve the first small win, build the platform on the small, incremental benefits. Every iteration should depend on the success and the delivery of insight from the previous iteration.   Data Scientist vs Data Analyst The term Data Scientist implies that you will use the scientific method. It helps if you have a scientific and mathematic background. A data scientist does not bring an opinion; they let the facts speak for themselves. They are skilled at and comfortable with manipulating and working with data. Analysts such as web analysts understand at their core how things work and trends. They bring their opinion into it as they use their past experience and judgment to make some decisions. This applies whenever an analyst has domain expertise.   Big data is a very powerful technology opening capabilities and opportunities which, if done properly, look like magic to your competition. In any successful implementation, it’s likely to have been built incrementally and started with small goals and promises. In any learning system, it will start from basic and obvious ideas and then test, measure, and adapt. It’s an evolutionary system.   Z Your Homework Don’t try to do it internally or by yourself. In many organizations, the data is shielded by vested interests (“It’s my data”). The vested interests of the data holders may override the interest of the company. Try to control ambitions. Start small and incrementally build on results. If someone tells you that a big data system will be able to flawlessly predict the future of your business, don’t believe them. What’s your take? Have you been involved in a big data project? Please share your experience and comments in the section below.   Links mentioned in this episode: Fonecta website Cormac’s Blog 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. Also, reviews on iTunes are

In this episode, Kurt Bittner shares his thoughts on the problem with eliciting requirements from Subject Matter Experts and how to bridge that gap with approaches from Customer Experience (CX) and User Experience (UX). Kurt Bittner Principal Analyst with Forrester Research Kurt Bittner is a leading expert on Agile and iterative software development approaches. Kurt is the author of three books, including The Economics of Iterative Software Development. Kurt was previously with the consulting firm Ivar Jacobson International where he was CTO—Americas and guided Fortune 100 companies in their Agile transformation journeys. He also led requirements tool strategy and development for Rational Software and led the early development of the Rational Unified Process. Twitter  After listening to this episode, you'll understand: Why eliciting requirements from a SME is dangerous How approaches from CX and UX can lead to better requirements What keeps analysts from talking to users  Show Notes The Problem With Requirements Elicitation Despite all of the requirements elicitation and documentation techniques we have, there’s still a high percentage of requirements that get implemented and are never used or no one cares. Based on research by Microsoft, which matches Kurt’s anecdotal evidence, about one-third of the ideas for new features are good, one-third don’t change anything, and one-third actually make things worse. The research also shows that highly paid people’s opinions tend to dominate discussions around product ideas, but their ideas aren’t any better than anyone else’s (they’re not worse either). You don’t know where in your organization good ideas are going to come from. This aligns with Kurt’s research with DevOps and continuous delivery because the faster you create feedback loops and get valuable feedback, the faster you can understand if your idea was a good one or not. You can then decide what to do more or less of. This relates back to requirements because there is a fundamental flaw in the belief that you will get a Subject Matter Expert from whom you will elicit, document, and implement the right set of requirements. In reality, that Subject Matter Expert is only one person and they are subject to the same distribution mentioned earlier. If you don’t talk to the right person or enough of the right people, no matter how good you are at eliciting requirements, the end result is unlikely to have the desired outcome. To prevent this from happening to you on your project, you can get faster feedback on the idea. Try out the idea (or small parts of the idea) with A/B testing or blue/green deployments where you deploy to a smaller subset of users and get feedback that way. Focus groups and expose the idea to a broader set of stakeholders also helps in getting rapid feedback.   Using Customer Experience Techniques More recently, Kurt has been using some of the techniques from Customer Experience (CX) such as ethnographic research (a fancy way of saying “get out and talk to your customers). Observe real users to see what they do and how they work. Don’t ask them what they do – observe them. Often people say they do something different than they actually do. As you observe them, ask them questions to understand why they’re doing what they do. It’s not that our normal elicitation techniques are bad and we need to get rid of them. We just need to broaden the sources of input and get as close to the end user as possible.   The Problem With Agile So often in agile (specifically with Scrum), we see a similar problem with Product Owners. If people perceive the Product Owner to be the single source for product ideas, we fall into the same trap. In reality, the Product Owner doesn’t have the time or ability to talk to all possible stakeholders and users to become the expert on all things. If you demonstrate working software at the end of each sprint to not just the Product Owner, but to actual users, you can get much more meaningful feedback. While this doesn’t solve the input problem related to the original idea, it does give us feedback that we can use to adapt or pivot. The approach of using Customer Experience ethnographic techniques and User Experience (UX) tools such as personas with our elicitation helps to improve the inputs.   Personas and Use Cases In Use Case modeling, we have the concept of an actor, but we never really talk about how to describe that actor. Using personas from UX allows us to get more detail about that actor and better understand their needs and how they would use the system. User Experience people have rediscovered the concept that Use Case modeling discovered 25 years ago and has added to it. Personas allow us to better understand the actor and their needs.   Connecting with Customers Observing and talking to your customers and end users is easier than you

In this episode, Jim Tamm will share some essential skills for effective collaboration and practical tools designed to help you manage your own defensiveness, build trust, reduce conflict, and create a more collaborative working environment. Jim Tamm Radical Collaboration Jim Tamm is an author and former Senior Administrative Law Judge where he had jurisdiction over public sector disputes in the workplace. He was also a member of a collaboration special task force to design and teach collaboration skills to highly conflicted public sector organizations. Jim gave the closing keynote at Agile 2015 with a presentation entitled “Want Better Collaboration? Don’t be so Defensive!”. FacebookTwitterLinkedIn  After listening to this episode, you'll understand: The importance of good collaboration Five key skills to promote better collaboration Why being defensive reduces your ability to collaborate How to lower your defensiveness How to deal with others who won’t collaborate  Show Notes The environment you create has a great impact on your ability to collaborate. According to research by Kotter & Heskett, there is a real and measurable difference between collaborative and adversarial workplaces. In collaborative workplaces: Net income improved 755% Stock price grew 826% Revenue increased 516% Workforce expanded 246%   What is collaboration? Collaboration is a level of cooperation and active collaboration that goes beyond simply working together. We want to get individuals and teams to be proactive in working together effectively with other counterparts and looking out for the interests of all parties involved, focusing on mutual gains.   Where do we start? Start by realizing that collaboration is critical to success. There’s no way that companies can compete externally if they can’t collaborate internally. There are some specific skills needed if you want to build a more collaborative working environment or just get better at individual collaboration.   Red Zone vs. Green Zone Green Zone (collaborative mindset) environments are high trust and low blame, allowing for greater collaboration. These environments allow for mutual support, honesty, openness, and appropriate risk taking. People in the Green Zone are internally motivated and find work more pleasurable as a result. In red zone, if you try something new and it fails, someone is blamed. In the green zone, if you try something new and it fails, the conversation revolves around what was learned. Red Zone (combative mindset) environments are those with low trust and high blame. They are characterized by risk avoidance, cynicism, suspicion, and people are externally motivated. Beware: The shift from Green to Red can happen fast!   The Path to Better Collaboration There are five key skills needed to create better collaboration. Collaborative Intention – Be able to stay focused on mutual gains when you hit a rough patch. When someone makes a mistake, do you get curious or get furious? Truthfulness – Create an environment where it’s safe for people to speak the truth. You can’t solve problems if people aren’t able to raise difficult issues and have truthful conversations. Self-Accountability – What choices are you making on a regular basis? Get people to understand the choices they have and empower them to make the right choices. They must then take responsibility for the resulting outcomes. Self-Awareness – Become more aware of your own defensiveness. When people feel threatened, they often become defensive, their IQ drops 20 points, and they get stupid (due to the fight or flight response). They can’t solve problems in this state and it invites others to become defensive. The ability to reduce your defensiveness has a positive impact on collaboration. Negotiating and Problem Solving – Being able to work your way through the conflicts that are inevitable in most working relationships. This allows you to resolve the conflict in a way that supports the relationship instead of undermining it. These skills can all be learned, practiced, and improved.   Don’t be so defensive Our own reaction of defensiveness leads to lower collaboration. Defensiveness does not protect us from other people, it defends us from fears we don’t want to feel. The key is to understand and be aware of your own signs of defensiveness and take action. Lower your own defensiveness to increase your collaboration and ability to solve problems. How do we know if we’re getting defensive? When we get defensive, it’s often because we feel that someone has done something to us and we need to defend ourselves from that person. In reality, when we get defensive, it’s because there’s some fear inside us that we don’t want to feel. Common fears include fears about our significance, competence, and our likability. Most of us aren’t

In this episode, leadership and performance coach Cillín Hearns explores what it means to be a leader and how to advance your leadership skills regardless of your current role or level. Cillín Hearns Leadership and performance coach with Setanta Consulting Cillín Hearns is a leadership and performance coach helping business and IT professionals become more successful in their roles. Cillín is also a frequent speaker at IIBA and PMI events. TwitterLinkedIn  After listening to this episode, you'll understand: What leadership really is (hint: It’s not what you think) Why our brains run on automatic so much The shift you need to make to move toward leadership How to grow and develop your leadership skills  Show Notes Real leadership has to start from within. It’s what’s known as authentic leadership. Leadership is about being, doing, and saying. Before you can do and say, you must be. That requires self-awareness, awareness of the impact you have on others, on your environment and the impact that others and your environment have on you. When you have that awareness, conscious choice comes into play. This drives how you want to be . . . how you want to show up tomorrow, in your next meeting, with your team, or with your family. Instead on running on automatic, conscious choice means that you have the ability to decide to be the best that you can be.   Running on Automatic People are wired to default to automatic behaviors. The brain is inherently lazy; if you have a strategy that has worked in the past, your brain will tell you to reuse that strategy rather than waste cognitive energy to come up with a new solution. If we had to re-think every encounter, decision, and situation, we wouldn’t be able to function as efficiently as we do. The brain creates shortcuts that allows us to very rapidly make decisions based on the information available to us.   Cillín’s Philosophy of Leadership The definition of leadership doesn’t come from a book or from a class. You need to find their own vision of what leadership means to you, otherwise the definition won’t be the truth for you. Leadership must come from within. Some people might focus on getting things done while others may focus on inspiring others. It comes down to what you’re passionate about and following your passion. Reflect on your passions and what kind of impact you want to have on the world or on your team. This is leadership at any level, regardless of your title or authority. You don’t need a title to be a leader. When you behave in certain ways, you’re true to your values, and you have a vision, people will naturally start to follow you. That’s real leadership. You need certain skills to do the job as you move up in an organization’s hierarchy, be it technical skills, financial skills, or whatever else you might need in that role. But with that, you also need the soft skills – skills that will motivate people and get people to want to follow you.   The Halo Effect If you do a great job, you may find yourself promoted to managing teams or individuals. You may even start managing those who have knowledge and experience outside of your expertise. They may come to you with questions for which you don’t know the answer. Unless you make a mental shift, you won’t be successful in that new role. You will have been promoted to a level of incompetence. Instead of continuing to rely in your technical leadership and expertise as you have done in the past, shift your thinking to helping people solve their own problems. Be able to step back and get comfortable with not knowing the answer all of the time. Rather than solving everyone’s problems, help them solve the problems themselves. Have the trust and faith that they can do that.   Are Leaders Born or Made? While I honestly believe that leadership is a skill that can be practiced and developed, we do see some natural leaders. People can develop leadership skills primarily due to the environment in which they grew up. Exposure to others with strong leadership skills who communicates with you as a good leader would, you may begin to communicate in a similar way. To you, it’s not trying to be a leader, this is simply how people behave. If you weren’t exposed to those leadership personas during your formative years or if the strategies you used as a child don’t work in the adult world, that’s where self-reflection comes in. The ability to step back and create an awareness of why you’re doing the things you’re doing and what outcomes you’re experiencing. If you want different and better outcomes, you need to change what you’re doing.   Grow Your Leadership Skills You may want to develop your leadership skills to be better in your current role or for career advancement. Start by understanding your strengths and what you’d like to improve. Mod

In this episode, Susan DiFabio discusses a skill that’s critical to success as a business analyst, product owner, or project manager. It’s a skill that allows you to build trust and ensure an accurate, shared understanding. That skill is active listening.  After listening to this episode, you'll understand: What active listening is and why it’s so important How and when to use reflective and exploratory listening How to use silence to increase communication What powerful questions are and how to use them  Show Notes What is the most important skill needed by every business analyst, product owner, and project manager? It’s a key component of good communication and it’s skill that allows you to build trust and ensure an accurate, shared understanding. That skill is . . . active listening. What is Active Listening? Active listening can be defined from two perspectives: What is the outcome you’re looking for and what’s your starting stance. The outcome we want with active listening is accurately sending and receiving a message. This includes not only sending a message, but also confirming correct receipt of the information. This creates a virtuous circle of communication – the more I fully understand you, the more trust you feel to continue the conversation with me. Anything that produces that outcome is what is considered active listening as long as it aligns to the opening stance. The opening stance must start with authenticity, meaning that I need to be genuinely curious to understand what you’re saying. Along with authenticity, we need acceptance, which means that I accept what you’re telling me as a gift with appreciation and without judgment. Active listening can go beyond spoken words. It can include written and other forms of communication that confirm that I have heard and understand you.   Can active listening be developed as a skill? Much like the skill of playing an instrument or sports, active listening can be developed with deliberate practice. Active listening can be improved through first understanding what those skills look like. Susan breaks active listening into two categories: Reflective Listening and Exploratory Listening. Reflective listening entail feeding back the same information to the speaker to show that you have heard what they said. It might be identical words or different words with the same meaning. If you change the speaker’s language, you may want to test that you have accurately understood by adding “Did I get that right?” This gives space for the speaker to elaborate on what they said.   Using Silence Get comfortable with and make strategic use of silence. Most people are uncomfortable with silence and they want to fill the gap. They do this by elaborating on what they’ve said. They may need the silence to figure out how to articulate their thoughts. Get used to silence be building in small increments. Practice in conversations by being silent for 5 seconds and then 10 seconds. Building your comfort with silence by slowly increasing gaps in talking will allow you to get used to silence. It’s surprising what people will offer to you if you give them the silence and the space to do that.   Exploratory Listening Exploratory listening involves asking questions and other approaches to allow the other person to dig deeper and expand on what they’ve said. Be aware of the type of questions you’re asking – are they open or closed? They each have their place and you’ll need to understand when to use each.   When should you use each type of listening? Reflective listening works well at the beginning of the conversation, especially if you don’t know yet where the conversation is going. Once you understand the other person, you can move to exploratory listening to dive deeper into the issue. You also need to be aware of your relationship with the other person. To someone with whom you haven’t built a strong relationship, a series of ‘why’ questions can come across as an inquisition.   Reframing Questions for Better Results Be aware of how you’re presenting your questions. Instead of asking ‘why’, ask ‘what’ or ‘how’. Starting with ‘why’ questions can come across as accusatory. For example, instead of asking “Why did you do that”, ask “What was the outcome you were trying to achieve by doing that”. Tone of voice and the way you present your question affects how well your question is received. Using a tentative approach and checking for understanding also helps to make sure the message is correctly received.   Using Powerful Questions Powerful questions cause the person you’re speaking with to have a new insight. It makes the person reflect and explore something they may not have considered. See the links section for a list of sample

In this episode, author Ian Spence introduces us to a different way to utilize Use Cases in agile environments – Use Cases 2.0. Ian Spence specializes in large-scale agile adoptions and practice-based organizational change. He’s an experienced agile coach and has worked with hundreds of projects to introduce iterative and agile practices. He’s also the co-author of two influential software development books, “Use Case Modeling” and “Managing Iterative Software Development Projects”. After listening to this episode, you will understand: The advantages of using use cases How to use cases can be used in an agile environment Why and how to create thin slices of use cases http://traffic.libsyn.com/masteringbusinessanalysis/MBA_034__Use_Cases_2.0_-_Interview_w.mp3 Show Notes   Why Use Cases? The biggest advantage to using use cases is that it provides you with a way to create a visual model of the system as a whole. They give you a great way of understanding the boundary and entirety of a system in a way everyone can understand. People often go wrong with use cases when they don’t understand the relationship between the use case diagram and the requirements or design of the system. People forget that software engineering is about the art of the possible and try to write these incredibly detailed requirements specifications that remove any ability of teams to innovate. Rather than focusing on the goals and the value, they get caught up in the design and create large, detailed specifications that don’t allow for fast feedback. Done well, use cases are great for creating a shared understanding of the system as a whole which is invaluable as you start to plan, design, and build any kind of software system. When you build a use case model, it’s to build understanding. Keep it simple.   The Birth of Use Case 2.0 Ian published an eBook to demonstrate a way to address using use cases in the iterative and incremental development environments of agile after seeing people struggle with use cases. The idea behind Use Case 2.0 came from Ivar Jacobson’s work on slicing use cases to support aspect-oriented software development and Ian Spence’s work on populating the backlog with use case slices. Use Cases 2.0 encourages people to develop use cases slice by slice with varying levels of detail. It encourages collaboration and emergent design.   Getting Started with Use Case 2.0 One of the principles of Use Case 2.0 is to start with and understand the big picture. Start by building a simple use case model, find your actors (which will help you understand your user types), and identify the goals that the system is going to support. From there, you can think in terms of a minimum viable system and identify the use cases that will be most critical to achieving the goals. This may also allow you to eliminate some low value or low importance use cases. “Over 60% of software code written is for error handling.” Once you understand the big picture and critical use cases, focus on the “happy path” scenarios and create a use case based on that with just enough detail. Perhaps you can simply bullet out the happy path or if required for regulatory or other reasons, you can provide more detail. Find the basic path and most obvious alternatives and create a slice through it. That could be one path or one test case through the scenario to give to developers to develop. Have a conversation with developers as to the requirements and test cases associated with that thin slice. This allows for emergent design. As developers are working on the first few slices, analysts can be working on the next few slices of use cases.   How Do We Slice Use Cases? When we slice use cases, we look at them in terms of a series of steps for a basic flow without all of the variants. Look at the basic flow for certain types of customers or products to reduce the potential variants. Afterwards, you can look at which alternatives or other ways of achieving the goal are important and create slices for those. Slice around flows and scenarios, around the data, risk, size, and value. Don’t try to find all alternatives up front. Just start with one and iterate from there. Creating thin, vertical slices allows you to get feedback and adapt based on that feedback. Keep it lightweight at first and then fill in to the minimum level of detail needed.   YOUR HOMEWORK (Ian’s Tip) Stop detailing all of the requirement upfront. Create thin slices and build out from there iteratively and incrementally. If you are in an agile environment and are using user stories, build a simple use case model to find the use cases and understand how the stories fit together into the big picture.   What’s Your Take? Do you use Use Cases in an agile environment? Do you have any advice to share? Please share your experience in the comments below.   Links men

In this episode, consultant and blogger Alex Papworth shares his advice for starting a career as a Business Analyst – how to get and succeed in your first role as a BA. Alex Papworth has over 20 years’ experience in IT. Through his website, Business Analyst Mentor, Alex has facilitated the sharing of expertise and experience for the business analyst community. Alex also provides resources and services to support business analysts pursuing professional development. After listening to this episode, you will know: How to find opportunities to advance your BA skills and experience How to target your job search What you need to do to be successful as you begin your BA career http://traffic.libsyn.com/masteringbusinessanalysis/MBA_033__Landing_and_Succeeding_in_Y.mp3 Show Notes Know Thyself Do inventory of your skills and see how they align to the requirements of the position. Focus on characteristics and capabilities around soft skills as those skills gives you the greatest long term ability. Those skills include communication, influencing, and active listening. Once you’ve completed your self-assessment, you can begin your job hunt by crafting your resume or CV to highlight those skills as they would be applied to a Business Analyst role. Next, define your strategy for pursuing your first role. The key is understanding your strengths and identifying your unique selling proposition (USP) that will give you a leg up on the competition. Some examples may include project management experience or business domain experience. The knowledge about your strengths and skills will allow you to hone your strategy about which roles and employers you will target as part of your job search. Don’t aim for every company and every role. Pick and choose the ones that provide the best opportunities for you to use your strengths.   How to Land Your First BA Role Keep in mind that even if you don’t have the title of Business Analyst, you may still be doing business analysis work that is applicable to the role. Start by looking at BA roles with your current employer and see if there are opportunities to work alongside business analysts. Start building contacts and offer help to the business analysts. Ask if you can shadow or observe them as they work to learn more about the role. Outside of your organization, look for opportunities with family, friends, volunteer organizations, and other areas that might benefit from your skills. Offering your time and services for free can allow you to build your experience.   Success is All About Mindset To be successful in your new role, you need to have a learning mindset. Look at work as an opportunity to learn and take up new challenges. A well-known study showed some important information about how people learn. 70% of learning occurs on the job, 20% occurs with other people, and 10% is from formal learning. Typically we look at formal learning as the way to increase our skills and knowledge. We need to recognize that instead, the workplace is the best place to learn. Maximize your learning from everything new you do by reflecting back on what worked and what didn’t. You can even form a small community of peers and share ideas and experiences to learn from each other. Self-awareness is a critical quality to be a top Business Analyst. It allows you to focus on continuous improvement.   Alex’s Tip Contribute to the BA community. This can be done through a blog or participation in discussions on social media communities or industry events. Sharing your knowledge and experiences creates openness and allows you and others to increase your skills and knowledge. Look to give before you receive anything. Start sharing and building connections.   What’s Your Take? How did you get your first BA job? Do you have any advice to share? Please share your experience in the comments below.   Links mentioned in this episode Alex’s website: http://businessanalystmentor.com/ Alex’s YouTube playlist Follow Alex on Twitter: https://twitter.com/alexpapworth 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. 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.   The post MBA033: Landing and Succeeding in Your First BA Role – Interview with Alex Papworth appeared first on Mastering Business Analysis.

In this episode, consultant and author Paula Bell shares her approach to Systems Thinking – a holistic analysis approach to understanding how the parts of an organizational system interrelate. 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. After listening to this episode, you will understand: What Systems Think is and why it’s important How to begin How you can better understand your customers and build a solution for their needs http://traffic.libsyn.com/masteringbusinessanalysis/MBA_032___Systems_Thinking_-_Intervi.mp3 Show Notes Simply put, Systems Thinking is understanding the whole, not just the parts. The system isn’t just technology. It can include people, processes, and anything else related to how things get done. Have a holistic view of what you’re doing. Understanding the individual parts of a system and how they interrelate can help you to identify gaps and understand upstream and downstream impacts. When you work in a silo, you tend to make decisions without considering upstream and downstream impacts. This leads to inefficient or even failed processes and systems. We need to understand impacts up, down, and across the organization. Sometimes, even subject matter experts don’t understand the big picture and do things because they’ve always been done that way. Asking questions and having a holistic view will help us to identify inefficiencies activities that don’t contribute to organizational goals. “That’s how we’ve always done it” is the most dangerous phrase in organizations today.   Where Do We Start? When starting a new project or new role, start by understanding how the organization is structured. Identify who the key players are, which departments are involved, and who makes the decisions. An organization chart can help you to understand how the organization is structured. Once you understand the structure, start building relationships. Once the stakeholders know who you are, one question to ask is “If you can change one of your biggest challenges today, what would that be?”. You will likely hear patters or themes that will allow you to better understand the organization. Keep those thoughts and patterns in mind when proceeding with the project to have a holistic view and make informed decisions. This helps with understanding and negotiating scope as well as managing scope creep.   Learn to Love Challenge Don’t be afraid to ask why. Often, we may be given a solution to implement instead of a business need or problem to solve. Challenge assumptions and work to understand the business goals and how the solution is expected to meet those goals.   The Importance of Systems Thinking If you fail to understand how the parts of a system interrelate, changing one part can have negative impacts on another part. While your project may be successful, the organization as a whole could experience a negative outcome.   Systems Thinking Approach Leverage org charts as well as vision and mission statements to understand the structure and goals of the organization. Process maps help you to identify inefficiencies within the system. For root cause analysis of some of the issues you’ve considered, Paula often uses a fishbone diagram Use a consequence matrix to understand solution options and the pros and cons of each option.   Paula’s Tips Understand how your organization functions by reviewing organizational charts and vision/mission statements Begin building relationships Learn about tools such as 5 Whys, a Consequence Matrix, and Fishbone diagram   What’s Your Take? Do you have a different approach to systems thinking? Please share your experience in the comments below.   Links mentioned in this episode Paula’s website 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. 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.   The post MBA032: Systems Thinking – Interview with Paula Bell appeared first on Mastering Business Analysis.

In this episode, User Experience designer and researcher Neil Turner will share his thoughts on how and when to interact with UX professionals in your company as well as give you some practical tips and tools you can use to create a better experience for your customers. Neil Turner is a User experience designer and researcher with over 10 years of commercial UX experience. Neil also runs a blog called UX for the Masses where he shares tips, techniques, and tools everyone can use to design a better user experience. After listening to this episode, you will understand: What User Experience Design is and how it differs from Customer Experience Design (CX) Tools you can use to begin building a better experience for your customers How you can better understand your customers and build a solution for their needs http://traffic.libsyn.com/masteringbusinessanalysis/MBA_031.mp3 Show Notes What is UX? User experience design (UX) is more than the buttons and interface of an application. It encompasses the entire experience of a user to make sure their journey through system interaction is a positive one. A large part of UX is user-centric design, essentially giving the user a seat at the table when designing an application. UX helps to mitigate risk by getting frequent customer feedback when it’s easier and cheaper to make changes. UX differs from CX (customer experience) in that CX may cover customer interactions through multiple channels and multiple touch points. Both User Experience Design professionals and Business Analysts often ask questions to understand the goals so that then can ensure the resulting solution meets the needs of the user and the organization. They may work together to get design feedback and iterate on the design. “Design isn’t the sole responsibility of the designer, it’s the entire team’s responsibility” Any opportunity to work directly with users allows UX professionals (and business Analysts) to develop empathy and build a solution the better fits the user needs. Getting a lot of ideas on the table and exploring alternatives is helpful in developing a great solution through iterating and getting feedback.   UX Tools You may already be using some User Experience Design tools. Some common tools include personas, story maps, and process maps. A UX professional may also use prototypes and wireframes to solicit feedback on their design. Another tools Neil recommends using Customer Experience Maps. This maps out a customer’s journey end to end (the different touchpoints and experiences) to better understand the customer, identify key parts of their journey and creating a seamless experience. There are generally two types of User Experience maps: Existing experience based on qualitative and quantitative research Future experience when designing a new product or changing an existing project More important than tools, however, is the mindset. Put yourself in the customer’s shoes and design something that meets their needs (and is a pleasure to use).   Neil’s Tip As much as possible, get out and interact with users. It’s easier than you think and understanding the user’s needs and pain points is critical to developing a solution that will solve their problems.   What’s Your Take? Have you worked with UX Designers or used some UX tools? Please leave a response below and share your experience.   Links mentioned in this episode Neil’s Website: http://www.uxforthemasses.com/ 25 Great and Free UX Tools: http://www.uxforthemasses.com/free-ux-tools/ InfoDesign: www.informationdesign.org/ UX Magazine: https://uxmag.com/ Smashing Magazine: www.smashingmagazine.com/ UX Matters: www.uxmatters.com The UX Booth: www.uxbooth.com/ 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. 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.   The post MBA031: UX – Are you Experienced? Interview with Neil Turner appeared first on Mastering Business Analysis.

In this episode, author, speaker, and consultant Linda Rising helps us to better understand resistance to change and some of the myths and patterns associated with leading organizational change. Linda Rising is consultant, speaker and author of four books on topics ranging from organizational change to patterns in software development. After listening to this episode, you will understand: The myths of organizational change that lead us down the wrong path Why simply stating facts doesn’t persuade people How you can convert naysayers into allies http://traffic.libsyn.com/masteringbusinessanalysis/MBA_030.mp3 Show Notes   Linda Rising has combined her knowledge of neuroscience and software design patterns to develop ways to better influence organizational change. Along the way, she had identified some myths and patterns that stall organizational change initiatives.   The Myths Myth #1: Smart people make decisions rationally and can be persuaded by a presentation of facts and benefits. Fact: People aren’t rational decision makers. Research results from the field of economics shows us that we are in fact irrational. We make decisions for a variety of reasons such as emotion and even reasons that may be hidden to ourselves. How to address this myth: Be aware that people aren’t rational decision makers and have a set of cognitive biases that we need to overcome. Approach change with a personal touch. Take the advice of Stephen Covey and “seek first to understand and then be understood”. Instead of concentrating on your message, focus on the audience, the person who is afraid of the change, the person with anxiety, and put yourself in the other person’s shoes to understand their point of view. This goes beyond explaining what’s in it for them.   Myth #2: The idea is so good, that the quality itself is convincing. We believe that good ideas will triumph in the end. Fact: This is known as the “just world fallacy”. There’s plenty of history to show us that often bad ideas win over good ideas. It’s not about goodness. It’s not about rationality. It’s about trying to understand the deep seeded feelings and needs of other people. How to address this myth: Use the Fear-Less Pattern. Sometimes seeking to understand others is enough to convince them to be open to your idea. Instead of avoiding them, seek out people who are negative or are “naysayers” and seek to understand their perspective. Don’t try to reason or argue with them. Be genuinely, sincerely interested in what they have to say. “Listen them into agreeing with you.” Let naysayers play the role of Champion-Skeptic. It’s useful to have someone in a discussion who sees the downside so that you can understand possible issues and have a broader understanding of concerns. It also keeps the group from getting carried away with an idea without considering the downside and alternatives.   Bonus Tip: Do food. We’re hard wired to have food on the table when we get together with people we trust. Having food makes us more trustful and more open to ideas. It doesn’t need to be anything extravagant . . . just a little food makes people more open to new ideas. This even works with distributed teams by sharing a recipe and sharing the food during the meeting.   What can we start doing today and see positive results right away? Remember that none of us make rational decisions. There are many biases that we carry around with us that get in the way of making rational decisions. Call up the fact that we have biases and combat those biases by slowing things down by counting from 10 to one. If in a meeting that requires a critical, contentious decision, consider taking a break to slow things down.   What’s Your Take? Do you have any tips or suggestions for leading organizational change iniatives? Please share in the comments below.   Links mentioned in this episode Linda’s Website: http://www.lindarising.org/ Follow Linda on Twitter @RisingLinda: https://twitter.com/RisingLinda Linda’s Book on Amazon – More Fearless Change 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. 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.   The post MBA030: Myths and Patterns of Organizational Change – Interview with Linda Rising appeared first on Mastering Business Analysis.

In this episode, Business Process Consultant Brian Hunt shares with us his approach to starting a business process improvement initiative and some simple tools you can use to get started. Brian Hunt, CBAP is a Business Process Consultant specializing in business process improvement and simplification initiatives. Brian is a 6 Sigma Black Belt and believes that achieving simplicity in business processes is the most effective way to reduce waste and enable an organization to respond to market opportunities and threats. After listening to this episode, you will understand: How to start a business improvement initiative The right people to talk to to discover improvement opportunities Simple techniques and shortcuts to identifying areas to improve What a wombat has to do with process improvement http://traffic.libsyn.com/masteringbusinessanalysis/MBA_029.mp3   Show Notes Starting Out When starting a process improvement project, it’s important to discover if you are looking at a symptom or causes. Also, understand what the sponsor wants – a quick fix or systemic change. A systemic change requires a much higher level of leadership support than a quick fix. Assuming that you have full support of the initiative, you need to know how that processes connects to upstream and downstream process and how it fits in with other processes in the organization. To get a view of how processes interrelate, Brian uses IDEF0/IDEF3 models.   Why is Process Improvement Needed? As an organization grows, processes become more complicated. Informal processes stop working properly and you get workarounds and undocumented processes without consistency. To address process improvement, we need to: Find the current processes – Identifying workarounds and undocumented procedures Classify and catalog the processes – Identify what they are and where they fit Evaluate the processes – Identify which processes are not needed, which are duplicated, what needs to work better, and what needs to be created Correct processes as needed and connect them all together for the organization As you go through the processes, you need to create a common business language. Finding duplication and improvement opportunities will be very difficult without a common language.   Identify Opportunities To identify inefficiencies and opportunities for improvement, you need to speak with the people performing the process and identify pain points. One technique you can use to uncover the root cause of the inefficiencies is the Five Whys technique in which you seek to understand why each step in a causal chain is happening. Often the true root cause is uncovered in three whys.   Take Action Once the problem or inefficiency has been uncovered, we need to take action. Create an action plan that notes the problems that were found, the planned actions to address each problem, who will be responsible for carrying out that action, and by when. Make the action visible by publishing in to the company intranet or some other means. If you can make the issues raised by the front line workers visible and can show that they are being listened to, that will encourage more people to submit their own issues and suggestions. Research by Sidney Yoshida in “The Iceberg of Ignorance”, concluded that 100% of the problems are known by the employees at the bottom of the organization, 74% of problems are known by supervisors, 9% are known by middle management, and only 4% of an organization’s front line problems are known by top management. That means that 96% of the problems within an organization are invisible to top management, which is unsettling because many improvement initiatives originate at the top of the organization.   Tool: SIPOC A SIPOC is a simple yet powerful tool to understand the process inputs, outputs, and people impacted. SIPOC stands for Suppliers, Inputs, Process, Outputs, and Customers. It helps you to understand how the output from one process or step can be an input to the next step. This model can help you understand the internal customer/supplier relationship. Understanding the inputs and outputs needed helps you to understand what is needed and by whom. It may also help you to identify non-value added (waste) inputs, steps, or outputs. A SIPOC can also help you to understand impacts or a change made to any part of the model. Brian frequently uses color coding in his SIPOC. He uses red, yellow, or green to indicate the quality of that SIPOC stge.   Technique: TPN Analysis Once problems are identified, you may discover that some changes can be made by front line employees while other changes require approval from the leadership team. To decide what can be done, use a TPN (Totally, Partially, Not) Analysis to determine if the change is totally, partially, or not within the control of the department.   Decide Which Changes to Implement Brian recommends creating a spreadsheet of the change ideas and developing a mind map. Fro

In this episode, Melissa Marshall will help us to understand how to bridge the gap between technical terms and business terms and present information in a meaningful way. Melissa Marshall is on a mission to transform how scientists, engineers, and other technical professionals present their work. That’s because she believes that even the best information is destined to remain undiscovered unless it’s presented in a clear and compelling way that sparks innovation and drives adoption. In 2012, she gave a TED talk entitled Talk Nerdy to Me about the need to present complex information in an understandable manner.   After listening to this episode, you will understand: Why it’s critical to be able to communicate complex information to a general audience How to use an audience centered approach to make your presentation better How to make numbers more meaningful How to address one of the biggest challenges in presenting http://traffic.libsyn.com/masteringbusinessanalysis/MBA_028.mp3 Show Notes Audience Centered speaking Anytime you’re presenting your ideas, craft your communications considering the needs of your audience. There are three ways to employ an audience centered appoach: 1. Preparation: Think about the detail that you choose to share. You’re at risk of losing your audience if you get too much down in the weeds. To avoid this, write down where you want your audience to end up when you finish your presentation. What do you want your audience to know, believe, or understand as a result of your presentation? Once you know that end state, you can work backwards from there to build your presentation by identifying what your audience needs to know to get to that end state. 2. Use of Visual Aids: Instead of creating slides for yourself, reminding you of the points you wish to get across, think about the impact you want to make on your audience. Cognitive science has shown us that there’s a limit to how much word based information an audience can process. Having a lot of words on a slide means that the audience has to process not only the words you say, but also the words on the slides. This causes cognitive overload. Instead of words, consider using images that do something for us that words cannot. Use charts, graphs, and images to help get your point across. 3. Language Choices: Make your language more concrete through the use of analogies, examples, and stories. This will make the information you’re sharing easier to understand and more memorable. You want your audience to be able to recall and explain your ideas to someone else after your presentation. Stories, analogies, and examples are sticky pieces of information that people will remember and give them a structure to share information.   Make Numbers Meaningful When presenting numbers, give your audience context. Show numbers in relation to other numbers (budget, distance, size, etc.) or in the context of what that would mean to the audience. Creating an anchor point for your numbers allows your audience to form a judgment as to what that number really means.   The Biggest Challenges The most difficult audience is a mixed audience – one with both technical and non-technical people. To address this type of audience, we must return to points of common ground. A point of common ground is something that everyone in the room understands. Plan throughout your presentation for points at which you provide a wrap-up of technical concepts and return to common ground. “You’re only as successful as how well your message is received.”   Melissa’s Tip When creating a presentation, start with a blank template instead of the text / bullet based template. Instead, use meaningful images and put text in the notes pages that can be shared after the presentation.   What’s Your Take? Do you have any tips or suggestions for communicating technical information to a general audience? Please share in the comments below.     Links mentioned in this episode Melissa Marshall’s Website: http://www.presentyourscience.com/ Robert Ballard’s TED Talk: http://www.ted.com/talks/robert_ballard_on_exploring_the_oceans Nancy Duarte’s Books (Get a free copy of her book, Resonate): http://www.duarte.com/perspective/#books Information on Melissa’s training services 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. 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.   The post MBA028: Talking Techie and Presenting Complex Ideas with Melissa Marshall appeared first on Mastering Business Analysis.

In this episode, Ellen Grove speaks with us about how to use Legos (the building blocks for kids) to elicit user requirements. Ellen Grove is an agile coach and trainer who helps teams make better software through coaching them to create the circumstances in which they can work most productively and effectively. She uses team-building and facilitation approaches to support the transition to collaborative Agile work practices at the team, managerial and corporate level. After listening to this episode, you will understand: Why games make collaboration easier What Lego Serious Play is How to use Legos to elicit user requirements Steps you can take to enhance communication, engagement, and collaboration in your team http://traffic.libsyn.com/masteringbusinessanalysis/MBA_025.mp3   Show Notes   About Lego Serious Play LSP is a structured facilitation approach for getting work done using Legos. It can be used for strategic visioning, team building, individual career planning and more. It’s used anywhere you’re trying to get people to pull ideas out of their head and out on the table and then have a conversation about those ideas or create a shared landscape. It’s a repeated cycle of posing a question, having people build an answer to the question, having people share the story of the model they’ve built, and deciding what to do with the story the new shared understanding they’ve developed. In the end, it’s an approach to get people talking to each other and create a shared understanding.   Why Lego Serious Play? Sometimes this approach gets people to share that they didn’t know they had or didn’t know how to articulate or share things they wouldn’t have otherwise. When you use Lego Serious Play, it levels the playing field so that everyone is participating on the same basis. It harnesses the creative capacity of everyone in the room.   Legos for Requirements Elicitation When we’re designing a system, it’s less about the technical capabilities of the system and more about the users’ relationship with the system and the relationships of the people involved in the process. It’s about how people share information with each other. Using Legos for requirements elicitation can help fill in the gaps of other approaches to requirements discovery. It does this by getting participants to talk to each other about their understanding of users of the system and what people want from the system. This quickly creates a shared landscape and a vivid shared understanding of the problem you’re trying to solve and for whom you’re trying to solve it. This approach also brings to the surface areas where there is not a shared understanding or where there are gaps in our understanding.   How to Use the Lego Elicitation Workshop To use this technique of requirements elicitation, gather all needed parties in the same room. This includes the development team and the users of the system. Once everyone is in the room, have participants create a series of builds – A warm-up exercise, who we are as a development team, who are the users, what are the needs or the users, what are the key components, and more (see links for full instructions). This approach allows us to start with the Who and the Why instead of What and How, which allows us to build a more robust solution.   When to Use the Lego Elicitation Workshop There is no one right time. This approach can be used any time after some initial discovery is done so that we have a good understanding of the purpose and key objectives and well as have an understanding of who to include in the workshop. This can be done in place of a JAD (joint application development) for traditional projects or for agile projects, it can be done as part of the effort to build out the backlog. Having a time box for each step allows participants to focus on the most important elements.   Ellen’s Tip Jump in and try a small experiment with Legos or innovation games. You’ll be surprised (pleasantly) by the results.   What’s Your Take? Have you used Legos or other games for better communication, engagement, or team building? Please share in the comments below.     Links mentioned in this episode Ellen’s presentation deck: http://www.slideshare.net/egrove/user-requirements-with-lego-serious-play-agile-india-2014 User Requirements with Lego (URL) guide: https://d3gxp3iknbs7bs.cloudfront.net/attachments/c6a2cc2e83a9849916a88ffc6548b6736cc51250.pdf Lego Serious Play: http://www.lego.com/en-us/seriousplay/ Innovation Games: http://www.innovationgames.com/ Ellen’s Blog – Mastering the Obvious: https://masteringtheobvious.wordpress.com/ 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. Also, reviews on iTunes are highly appreciated! I read each review and it helps

In this episode, you’ll find out about the importance of guarding against scope creep and tools to help stop scope creep. Dave Saboe is the host of the Mastering Business Analysis podcast. He has two decades of experience as a Business Analyst and has experienced the negative impact scope creep can have on projects. His scope creep alarm goes off whenever someone says “could you just . . . ” or “while we’re in there, we might as well . . . “ http://traffic.libsyn.com/masteringbusinessanalysis/MBA_026.mp3   Show Notes Scope creep isn’t just the nickname of that weird guy with chronic bad breath down the hall. It also refers to uncontrolled changes or the continuous growth in a project’s scope. Often, this addition to scope comes without corresponding changes to the budget, resources, and schedule. Scope creep is also known as requirements creep and can occur when the project scope is poorly defined and as a result, requirements are added that do not align with the objective of the project. By “scope of the project”, we’re referring to the boundaries of the project, problem, or intent. Scope helps define the project’s parameters.   Fight scope creep daily Certainly, there are requirements changes that don’t fall into the category of scope creep. If a requirement was previously missed and yet is needed to achieve the objective of the initiative, that is not scope creep. Similarly, a change of detail such as needing a field to appear on the first screen of an application rather than the last page is not scope creep. Scope creep can lead to gold plating, which is the practice of going beyond the project scope in the belief that you are adding value. However, these additions to scope may not be needed by the customer and certainly don’t add sufficient value to make up for the increased time and cost. Scope creep is consistently listed as one of the top three reasons for project failure. Depending on which study you read, failed or challenged projects (those that exceed budget or time constraints) account for between 34% and 75% of all projects. So one to two thirds of projects outright fail or exceed constraints, and scope creep is a major contributing factor. The common perception with some stakeholders is that it’s cheaper to make additional changes while you’re making changes to the system. Often that’s true. By taking advantage of bundling similar tasks together, you achieve certain cost and time savings. However, there’s also an opportunity cost that is frequently not considered in these decisions. Taking time and resources away from the main objective of your project leads to delays and increased cost. The benefit of the additional scope may not sufficiently support the cost associated with the lost time and resource constraints. There are also downstream impacts to consider. The later in the project lifecycle you add scope, the more costly it is to implement. Having to rework the code, testing (including additional regression testing), the time to perform proper change control procedures, and related activities all result in delays and increased cost. You may lose your first mover advantage or violate regulations if timing is critical to your project.   Not all scope creep is created equal Scope creep is not always negative, depending on the situation. New features and functionality can give your product the edge over the competition if you implement it early enough. It may be the case that while the additional scope does not exactly align to your project’s objectives, it is sufficiently important to add this scope to your project to gain an advantage.   No worries . . . We’re Agile! While it’s true that changing requirements have less of an impact with Agile and other iterative delivery methods, scope creep still sneaks into those projects and pushes out your backlog, leading to delays in delivering high priority intent. Agile allows you and your team to focus on the next priority. When scope that is not aligned to your project or objective is added to your backlog, there must be proper prioritization and a trade-off with something in your backlog that is properly aligned. Again, there’s an opportunity cost and the potential for delays to your shippable product and increased budget requirements. You must educate your team on the trade-offs and opportunity costs associated with adding scope.   The Five Main Causes of Scope Creep Poorly defined scope and objectives Miscommunication or misunderstandings about the project intent and vision Poorly defined, ambiguous requirements Lack of a proper change control process Weak project management and negotiation skills   Solutions to Scope Creep 1. Make sure that you understand the project vision, goals, and objectives. Share the project intent and vision with your team, document the objectives and scope statement to clarity the boundaries of your project, and establish key metrics to evaluate the pr