Mastering Business Analysis

In this episode, author and consultant Steve Blais shares with us his 11 principles of the business analyst, which provides guidance as to what a business analyst should do to achieve success. This is part 1 of a 2 part episode. The interview was longer than my usual episodes and full of such great information that I decided to split it into two episodes. You can listen to part two in episode 127.    After listening to this episode, you'll understand: What a Business Analyst truly is Why you should focus on the product instead of the project Users don’t have requirements (and what that means for you) How focusing on individual SMEs can lead to problems  Show Notes The concept of a Business Analyst as a position is somewhat constraining. A person doing business analysis is not necessarily someone creating software requirements, but one who solves problems for the business. Regardless of your role title, there are certain guiding principles that lead to success.   Principle 1: Focus on the Product So often we focus on the solution; how the software will be written, the project timeline, and the budget. Instead, we should focus on the product, not the project. The product exists whether you make changes to it or not. By focusing on the product, we can focus on the problem domain instead of getting caught up in the particulars of the project. This mindset shift also helps you to see the impact that a change to a product will have on the people and processes. You also will consider the value of the change before you start to determine if it’s worth doing.   Principle 2: First Define the Problem, then the Solution We are frequently given a solution to implement instead of a problem to be solved. But how do we know if it’s the right solution if we don’t understand the problem? To combat this problem, ask ‘why’ when we’re given a solution. Before you implement a solution, make sure you’re solving the right problem.   Principle 3: Users Don’t Have Requirements Users and stakeholders don’t have requirements. All they have is information. We need to elicit that information and analyze it within the context of the problem to determine the requirements. Remember that requirements don’t exist until we analyze them into existence. This mindset shift alleviates some of the main complaints from Business Analysts; namely the business doesn’t know what they want and the requirements keep changing.   Principle 4: Focus on Information, Not Individuals Instead of following the trail of subject matter experts (SMEs) to get answers, first determine the information you need to solve the problem. Then find out how to get that information. This solves the problem of biases toward a particular area and delays due to lack of availability of SMEs.   Listen to the full episode to hear about what a Business Analyst actually is and how to apply the guiding principles. http://traffic.libsyn.com/masteringbusinessanalysis/MBA126.mp3   Be sure to check out episode 127 for the second half of this interview and to hear the remaining 7 principles.   Links mentioned in this episode: Steve’s website EssenceoftheBA.com Get Steve’s book, Business Analysis: Best Practices for Success Part 2 of my interview with Steve Steve Blais Author and Consultant Steve Blais is an author and consultant with almost 50 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. Steve was on the committee for the IIBA’s BABOK Guide version 3.0 and is the author of Business Analysis: Best Practices for Success. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA126: Guiding Principles for the Business Analyst appeared first on Mastering Business Analysis.

In this episode, Ian Huke helps us to become the conscience of the business by doing the right thing, building a following, and becoming a trusted advisor.  After listening to this episode, you'll understand: Why the BA is positioned to become the conscience of the business How you can avoid pet projects and local optimization Ways to gather a following and create a movement  Show Notes As Business Analysts, we have an obligation to ensure the success of not only the project, but also the organization. Unfortunately, many organizations are plagued by pet projects which are of little value or projects that optimize one area at the expense of another. Many projects are pushed forward without a strong business case behind it. While everyone in the organization should be responsible for ensuring we do the right things and drive forward with the right initiatives, BAs are uniquely positioned to have line of sight to understand value. This allows us to influence the organization in the pre-project phase and advise at a strategic level. Through being a trusted advisor, we can become the conscience on the business.   What’s Holding Us Back? There are a number of factors that hold us back from influencing the organization to avoid or stop projects with little or no value. First, it’s difficult for people to challenge organizations and leaders. It takes courage to push back when we feel that a project has no merit. Another factor preventing us from becoming the conscience of the business and advising the organization is the need for permission. We often feel that we need permission to make such recommendations. Culture certainly plays a role in the hesitancy to speak up. In some organizations, it’s inappropriate for people in lower level roles to speak to leaders.   Becoming the Voice of Reason There are a number of ways we can find legitimacy in making the challenge to leadership about these projects. Is there something in your job description (actual or implied) about ensuring successful outcomes? If so, that’s your opportunity to put your challenge into context; that you’re trying to ensure successful outcomes. Another opportunity is to try to trace the project back to the organization’s mission and vision. You can question how the project aligns with or moves us closer to that mission.   Build a Following You can build support for your cause by developing your leadership skills and building a following. Having a group of supporters behind you allows you to gain momentum and influence change. To build a following, first work to understand the needs of those you’re trying to influence and try to meet those needs. Their needs may be achieved within the project or possibly personal needs. Recognize that you can build your followers over time and at lower levels; you don’t need to start with leaders. How to Start a Movement TED Talk   Listen to the full episode to understand how to be the conscience of the business and build your influencing skills by building a following. http://traffic.libsyn.com/masteringbusinessanalysis/MBA125.mp3   Z Your Homework Take time to think about who your current followers are. Then, consider who you need behind you to influence the organization and work to gain a following in those areas.   Links mentioned in this episode: Ian’s website Build-BA.com Ian’s article on LinkedIn Ian Huke Consultant, Business Analyst Ian provides interim management and consulting services focused on leading and managing change professionals. His expertise covers developing internal change capabilities, evaluating new change initiatives, and stabilizing in-flight programs. Ian also works with organizations to enhance their business analysis capabilities by addressing individual competencies and pre and post project outcomes. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA125: Become the Conscience of the Business appeared first on Mastering Business Analysis.

In this episode, author Lynda Girvan discusses how BAs can succeed in Agile environments by applying a lean and adaptive approach.  After listening to this episode, you'll understand: How to make your BA process more Agile The three ways of thinking that lead to success in Agile The difference between real Agile and a series of small waterfalls  Show Notes Do we need Business Analysts in Agile? It depends. The skill of analysis is certainly needed in Agile product development. Either the people within the team need to develop their business analysis skills or the Business Analyst needs to become more “T” shaped. Outside of product development, specialized Business Analysts can contribute even in Agile environments.   The Agile Business Analyst Business Analysts in an agile environment do many of the same things that they do in a traditional waterfall environment, just with a different mindset. You still create models, but do just enough just in time instead of creating everything upfront. You still document information, but do so with a service thinking approach. The skills that you’ve developed as a traditional BA are still valuable in Agile if you apply an Agile mindset. The Agile mindset includes Lean thinking, service thinking, and systems thinking.   Lean Thinking Lean is about reducing waste to deliver value. There can be a lot of waste in traditional business analysis activities and Lean thinking seeks to reduce that waste. One form of waste is overproduction. When we create monolithic requirements documents (many features of which are never used), that’s a form of overproduction. Over processing is another form of waste. This is seen when we provide more detail that is needed. Partially done work (e.g., incomplete models or those that don’t provide value) is another form of waste because this becomes inventory that we now need to store and maintain.   Service Thinking Service thinking is the concept that we can’t deliver value. We can only propose value. Once we deliver something, we can get feedback from the customer to determine if it was of value to them. If we understand that concept, we can get into value co-creation. This is when we understand who the customer is and understand what their needs are and what’s valuable to them. Value co-creation involves tight collaboration between the team and customers.   Systems Thinking Systems thinking is about being able to see all of the interrelated parts. These parts need to work together. This approach helps you to avoid silos. Systems thinking also helps you to understand how changes to one part of the system affect other parts. Agile teams often focus on one product and fail to see the wider implications across the organization.   All of these concepts lead to one thing: Shortening the loop between concept and delivery. Requirements are just a means to an end. We need to figure out how to analyze just enough to deliver something and get feedback so we can learn and adapt.   Listen to the full episode for more on how to prioritize work, the difference between Agile and a series of small waterfall efforts, how to make your requirements more agile, and how to succeed in an Agile environment. http://traffic.libsyn.com/masteringbusinessanalysis/MBA124.mp3   Z Your Homework Start being Agile Apply Agile as a mindset. Think about how you can apply Lean thinking, service thinking, and systems thinking to your work. Forget about frameworks and start being agile.   Links mentioned in this episode: Lynda’s website Agile-Analysis.co.uk Assist Knowledge Development website Get Lynda’s book for 25% off at the BCS Shop. Use discount code agilebamaster17 Lynda Girvan Principal Consultant and Trainer Lynda Girvan is a Principal Consultant and Trainer for Assist Knowledge Development. She has over 25 years experience in business analysis, agile development, agile coaching and transformational change programs. Lynda is also a mentor for the BCS International Diploma in Business Analysis and co-authored the book Agile and Business Analysis. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA124: Business Analyst in an Agile Environment appeared first on Mastering Business Analysis.

In this episode, Kitty Hass explains the evolution of the Business Analyst role and what you need to do to be successful in the 21st century.  After listening to this episode, you'll understand: How the BA role has evolved in the last 20 years Why the typical task of documenting requirements is no longer enough What skills you need to be successful in today’s complex environment  Show Notes In the later part of the 20th century, Business Analysts were looked upon as team members. They were certainly not seen as leaders. It was seen as a tactical role and BAs spent most of their time analyzing and documenting requirements. The amount of time spent on strategic analysis, competitive analysis, and facilitating discussions on how the organization can innovate was less than 10% of their time. Being seen only as a documenter is demoralizing and limits the value that a BA can bring to the organization. The linear, waterfall approach at that time assumed we were smart enough to define all of the requirements upfront. The methods we were using were deficient for the complex, fast-changing environment we were in.   The Real Problem It’s not just on time and on scope for a project anymore. We’re less than 30% successful in our projects in terms or on time, on budget, and with a satisfactory result. The cause is twofold; we have gaps in strategic, value based business analysis and we have gaps in complex project management. Shoring up these gaps can add countless wasted dollars to the bottom line.   The Challenge of the 21st Century The 21st Century challenges us to change. With the growing complexity of today’s business and technological environments, we can’t influence positive change without bringing together differing points of view. We need to move out of our past tactical role and focus more on strategic level thinking across the organization. This requires an understanding of the business domain and the changing business environment. We also need to shift our communication style (both verbal and written) to a more collaborative and iterative style. Focus less on large, complex documentation and more on just enough to develop a shared understanding. The International Institute for Business Analysis (IIBA) issued a research and impact study in 2016 that showed the evolving role of the Business Analyst. The study showed that we need to evolve from requirements manager and documenter to Agile adaptive adoption and innovation influencer. The skills that you will need over the next three to five years are strategic thinking, strategic analysis, leadership, creativity, and innovative thinking. Additionally, you’ll need your current sills of critical thinking, domain knowledge, competitive awareness, investigative techniques, and knowledge of technology your organization uses.   Radical Collaboration Don’t underestimate the power of collaboration. You are expected to be able to bring together a group of smart people to solve big problems. You must be able to get the right experts in the room and know how to facilitate a discussion to understand the opportunity and determine the path forward.   Listen to the full episode to discover what organizations need and how to be successful in the 21st century. http://traffic.libsyn.com/masteringbusinessanalysis/MBA123.mp3 Z Your Homework Your job is to manage the value of what you’re delivering. For each release, you should understand the cost, the value to the customer, and how we’re going to measure success. This includes having an overall business case for the effort. Focus your development on leadership, innovation, and understanding the new enterprise roles.   Links mentioned in this episode: Kitty’s Website – Kathleen Hass & Associates Kitty’s books on Amazon Kitty Hass Kathleen Hass and Associates, Inc. Kitty Hass is the leading expert in Strategic Business Analysis and Complex Project Management. She has written nine books, dozens of influential articles, and given lectures at corporations throughout the world. She is a professor of Strategic PM and BA Practices at Villanova University and a keynote speaker at conferences around the world. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA123: The 21st Century Business Analyst appeared first on Mastering Business Analysis.

In this episode, Alaeddin Hallak shows us how to deliver real business value through our business analysis approach.  After listening to this episode, you'll understand: How to determine what value really means Why you should focus on outcomes instead of outputs Approaches you can use to contribute more value to your organization  Show Notes What exactly is business value? We as Business Analysts help our organizations realize business value when we do things that either sustain or increase revenue or reduce/avoid cost. Increasing revenue and avoiding cost are top level measures of business value. Things like increase market share, customer satisfaction, quality, and compliance with regulations lead to these top level business value outcomes.   Why Should Business Analysts Be Concerned About Value? Business value isn’t just the realm of project sponsors. Customers expect more and the environment is changing quickly. To stay competitive, we need to produce more value with the same resources. If we do, we’ll not just stay relevant, but also prosper. We need to take more ownership in driving business value.   Focus on Business Value It all starts with a mindset shift. We need to realize that outcomes are more important than outputs. We should also understand that we’re here to create products that solve problems, not just participate on projects. Observe what you’re doing and ask yourself “Will what I’m doing right now generate more business value?” Can business objectives be traced back to what you’re doing? This mindset shift starts with having knowledge of the business. From there, you can apply concepts such as design thinking to ensure you understand customers and deliver the right solutions.   How Can We Add Value? Before you attempt to formulate a solution, you need to thoroughly understand the business problem. Failing to do so leads to wasted time and resources. Have a skeptical mindset when given a solution. You can apply tools such as root cause analysis, design thinking, contextual observation, and benchmarking to help focus on the right problem to solve. As change agents, we need to go the extra mile and help the organizations adopt the changes we implement. Involving stakeholders and end users early leads to more ownership, less resistance, and better adoption of the change.   Listen to the full episode to find out how to seek positive outcomes, why Agile is an ‘undo’ button, and what to do when you’re handed a solution to implement. http://traffic.libsyn.com/masteringbusinessanalysis/MBA122.mp3   Z Your Homework Brainstorm ideas about what it would take for your organization to adopt the change you’re currently working on. Are there transition requirements that you haven’t considered? What’s your sense from stakeholders about how people will receive the change? If you feel there will be resistance, what can you do to evangilize the benefits of the change or raise the issue to leaders?   Links mentioned in this episode: Alaeddin’s website LeanBA.me The BA Learning Program Learn.ba/mba Alaeddin Hallak, CBAP Senior Business Analyst Alaeddin is a multidisciplinary Senior Business Analyst with a relentless focus on delivering valuable business outcomes and eliminating waste. He has over 12 years’ experience in being a change agent in sectors such as IT, finance, and government. Alaeddin is on a mission to solve business problems with solutions that balance business value, UX, and technical feasibility. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA122: Driving Real Value Through Business Analysis appeared first on Mastering Business Analysis.

In this episode, Geoff Watts helps us to better understand the Product Owner role and takes us from good to great product ownership.  After listening to this episode, you'll understand: If someone can be both a Business Analyst and a Product Owner Why Product Owners must be DRIVEN How to go from good to great product ownership  Show Notes The Product Owner role is a difficult role to fulfill. There are deep responsibilities and doing the job well requires multiple different areas of skill and knowledge.   Is the Business Analyst a Product Owner? Product Owners require a certain amount of analysis to be successful. They are informed about their product, their customers, how the product will be used, and the business environment. They also need to pass that knowledge along to the people developing the product. Product Owners don’t necessarily need to do all of that themselves. Whether or not other members of the team (such as Business Analysts or developers) help them in analysis and understanding of the customers depends on the context. One key distinction between a Business Analyst and a Product Owner is that Product Owners have decision making authority. Business Analysts often help business representatives make the right decisions, but have no decision making authority themselves.   What Makes a Great Product Owner The best Product Owners are driven. They’re passionate about their product and the customers. As they encounter challenges, they need to put their heart into in and overcome obsticles. The acronym DRIVEN can also be used to describe the characteristics of a great Product Owner. D stands for Decisive. Product Owners need to make a lot of decisions and often those decisions need to be made with incomplete information. R stands for Ruthless. Being ruthless is about understanding what value means for your product and focusing on only things that add value. Great Product Owners are also ruthless about minimizing risk. I stands for Informed. Product Owners are naturally curious and will do a certain amount of research and analysis. This allows them to make good decisions even in times of uncertainty. V stands for versatile. They are versatile in their leadership style. This allows Product Owners to provide a sense of stability in times of anxiety when circumstances change. E stands for empowering. The best Product Owners lead from within rather from the front. They also include relevant parties in discussions and decision making. They delegate authority appropriately. N stands for Negotiable. Great Product Owners bring people together and work to understand all perspectives. They also trade off priorities with needed.   Listen to the full episode to understand how these characteristics are linked, what to do about analysis paralysis, which area Product Owners struggle with the most, and what you can do to address those struggles. http://traffic.libsyn.com/masteringbusinessanalysis/MBA121.mp3   Z Your Homework Practice mindfulness. Use some self-reflection and self-analysis. Reflect on your effectiveness and what’s making your job more difficult than it should be. Then focus on what’s in your area of control. Finally, ask yourself if you’re making any assumptions about your situation that may not be true.   Links mentioned in this episode: Geoff’s website Inspect and Adapt Geoff’s book, Product Mastery Geoff Watts Founder, Inspect & Adapt Ltd. Geoff Watts is the founder of Inspect & Adapt Ltd. and one of the most experienced and respected Scrum coaches in the world. Having started using Scrum at British Telecom, one of the first large-scale agile adoptions, he has since coached organisations large and small through their agile journeys. Goeff is also an inspirational speaker and author. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA121: Mastering Product Ownership appeared first on Mastering Business Analysis.

In this episode, Alan Klement shows us how Jobs to be Done can help you design better products and spur innovation. Jobs to be Done (JTBD) is a mixture of design thinking, lean startup, and agile to help you make great products that people will love.  After listening to this episode, you'll understand: What Customer Jobs (Jobs to be Done) are How to use JTBD to create better solutions for your customers Why using JTBD helps you to innovate and get better results  Show Notes Jobs to be Done (JTBD) is a mixture of design thinking, lean startup, and agile to help you make great products that people will love. One of the core concepts behind Customer Jobs (Jobs to be Done) is that competition is defined in the mind of the customer. To put it another way, the market itself is what defines competition.   The Customer Needs Paradigm Instead of traditional thinking by Product Owners, Analysts, Innovators, and others where we have a narrow view of what our products are, JTBD helps to expand our view. We usually focus on customer needs. In reality, customers think in terms of the transformation they want; the “new me”. Humans want to evolve. The idea of self-betterment drives us to buy and use new products. If we can better understand the job they need to be fulfilled (their Job to be Done), we can innovate and develop products will buy and use. We can also use those insights to change our strategies to retain existing customers and find new ones.   Here’s JTBD in action. Increasing milkshake sales using Jobs to be Done   Listen to the full episode to usderstand how to use JTBD to innovate and create products will love. http://traffic.libsyn.com/masteringbusinessanalysis/MBA120.mp3   Z Your Homework Talk to customers who no longer use your product to find out why they left. Do this even for internal customers who aren’t using solutions you’ve developed for them. The insights you gain can lead to changes that benefit others (or bring back lost customers).   Links mentioned in this episode: When Coffee and Kale Compete Alan’s JTBD website Alan Klement Principal at Customer Jobs Lab Alan Klement helps teams and individuals become great at making and selling products that people will buy. His own experience as a successful innovator and entrepreneur is what makes him effective at helping others. Alan is also the author of When Coffee and Kale Compete, a book about how using Jobs to be Done (Customer Jobs) can lead to better products and innovation. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA120: Jobs to be Done Theory appeared first on Mastering Business Analysis.

In this episode, we discuss the different types of items that may make up a product backlog. Hint: It’s more than just User Stories.  After listening to this episode, you'll understand: The difference between a Product Backlog and a Sprint Backlog How to differentiate between Epics, Features, and Stories The components of a good User Story What the other types of backlog items are  Show Notes I often see teams struggle with backlogs and managing the items within their Product Backlogs. There’s more than just User Stories in backlogs too. There could be Epics, Features, Technical Stories, Spikes, and Job Stories to name a few. What’s the difference between Epics, Features, and Stories? Size. Epics and Features are really just really big User Stories. Features are User Stories that are too big to fit into a Sprint. They should provide value from the customer perspective and describe the problem or need instead of the solution. Ideally, features should include acceptance criteria formed through a conversation. User Stories are thin slices of value described from the customer’s perspective. Stories should include acceptance criteria developed by the team through a conversation. The Three Cs of a User Story Card – Stories should be brief and should not contain all of the detail. Stories are a reminder of a conversation that will include discussion of the details. Conversation – More important than the template of a story is the conversation. Every team member should understand the story through a dialogue and be able to discuss details that may change the original story or acceptance criteria (if any is written prior to the conversation). Keeping stories small and without a lot of detail will lead to a richer, more meaningful conversation. Larger, more detailed artifacts lead to assumptions and a lack of a conversation. Confirmation – The story should include conditions of satisfaction to know the scope of the story and understand when the story is done. The acceptance criteria for a story could be refined into Gherkin format.   Beyond User Stories System User Story: A strong preference should be placed on creating user-centric stories. However, some teams may work on development that does not interact with end users. In these cases, the role of the user can be a system or device. Technical Stories: If a team needs to develop functionality needed to implement a number of other user stories or otherwise support the system, their story might not directly impact the end user. Examples include stories focused on non-functional support of the system, stories that address technical debt, or stores focusing on performing architectural work. These stories may use technical rather than user-centric language. The story should still express the ‘why’ (so that . . .) to ensure the motivation of the story is understood. Technical stories can be used when the scope of the work is contained within a single component/platform and there is no obvious external user or system consuming/benefiting from the result of the story. The format may be something similar to “Implement ____________ so that __________.”   Other Types of Stories Spikes: A quick and dirty implementation designed to be thrown away and used to gain knowledge. A common indicator that a spike should be used is when the team is unable to estimate a user story effectively. An effective approach is to word spikes as a question to be answered or an assumption to be validated so that you know whether or not you accomplished the goal of the spike. A spike can be written as “In order to <achieve some goal> <a system or persona> needs to <some action>” or other formats. Spikes should be timeboxed and include acceptance criteria where possible. Research: Broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate. This is often used when teams don’t know a potential solution. An effective approach is to word research as a question to be answered or an assumption to be validated. Research stories should be timeboxed and/or include conditions to be satisfied (when are you done?). Tracer Bullets: A very narrow implementation in production quality of an epic or large user story. Tracer bullets are often used when the user story is too large in estimation.   Listen to the full episode to understand the different types of backlog items and how to use them. http://traffic.libsyn.com/masteringbusinessanalysis/MBA119.mp3 Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA119: What’s in Your Backlog? appeared first on Mastering Business Analysis.

In this episode, Dr. Penny Pullan shares strategies for working on virtual project teams and helps us get the most out of virtual work.  After listening to this episode, you'll understand: The challenges virtual project teams face How we’re all leaders and need to work with teams Why starting with yourself leads to better work for virtual teams How to overcome challenges such as language barriers and time zone differences  Show Notes The best form of communication is face-to-face with a whiteboard or another visual tool. However, the reality is that many teams aren’t co-located. Virtual teams can have many challenges including culture difference, language barriers, time zones, and simply a lack of engagement and difficulty creating a shared understanding.   The Virtual Leadership Approach Virtual leadership is applicable for any team of people who want to get things done together and at least one person is remote from the others. Many traditional leadership approaches don’t work well with virtual teams; a different approach is needed. The concept of virtual leadership goes beyond people management. It’s an approach for working together and getting things done on a virtual team regardless of your role. We all need to get things done with and through other people. This approach is about working together to build a shared vision and leadership among the entire team. The goal is to develop a team that can share and flex leadership depending on the specific task or situation.   Get Engagement Whether your remote team member is on another floor or across the planet, one of the most common problems is the lack of engagement. On conference calls, people fail to focus on the conversation or multitask instead of engaging with others. Failing to call out and address this behavior only leads to more such behavior. To address this problem, start by setting team norms. This can be done when first forming the team and even at the start of each meeting. Norms can include agreeing on ways the team communicates. You may decide that as part of the meeting, you’ll do a quick round of polling every 10-15 minutes (or random intervals) by asking each person for input and having them say a word or two to ensure engagement and focus on the goal of the meeting.   Be a Better Virtual Leader At the core of virtual leadership is the self. You need to know yourself; your strengths, weaknesses, and preferences. This allows you to understand your current skills and where you need to grow (e.g., organizational skills and technology) to get better at virtual leadership. The next stage is looking at working with others and how they work with you. To be successful, you need to understand the people you’re working with along with their skills, preferences, and mindset. Outside of knowing yourself and others, you’ll need to know how to use the technology that enables virtual communication. You’ll also need to be able to work within meetings and between meetings. After you’ve sharpened those skills, you can begin to deal with the challenges of virtual teams such as time zone differences, language barriers, cultural differences, generational differences, and other issues. Penny’s Virtual Leadership Model To be an authentic virtual leader, start with yourself. Be present, work to build trust, and plan appropriately to engage virtual team members. Listen to the full episode to understand how to be an effective virtual leader and overcome some of the challenges associated with virtual teams. http://traffic.libsyn.com/masteringbusinessanalysis/MBA118.mp3   Z Your Homework Prepare for virtual meetings by understanding yourself and others and build your skills to be effective in a virtual environment. During meetings, be present and engage with others. At the end of your virtual meeting, spend a few minutes to get input from the team as to what went well during the meeting and what can be improved. Then take action and discuss progress at the beginning of the next meeting.   Links mentioned in this episode: Penny’s website MakingProjectsWork.co.uk The BA Summit Penny’s book Virtual Leadership (Use code VLF20 for 20% discount) Use code VLF20 for 20% discount Dr. Penny Pullan Dr. Penny Pullan is a consultant, mentor, speaker and author. Penny works with people in multinational organizations who are struggling with complex projects; those with ambiguous requirements, disengaged stakeholders, and geographically disbursed teams. Her latest book is Virtual Leadership: Practical Strategies for Getting the Most Out of Virtual Teams and Virtual Work. Penny also runs an annual virtual conference for Business Analysts. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me mot

In this episode, Jared Wiese shares an approach for focusing on value to help you not just elicit requirements, but to get requirements right.  After listening to this episode, you'll understand: How to decompose requirements into smaller, valuable chunks Why simply asking customers questions about what they want is the wrong approach How to map value using the BML approach The three magic words to help you focus on delivering value  Show Notes As project professionals, we often help clearly articulate the requirements to develop and deliver a solution. However, getting requirements right can be challenging. Sometimes the requirements don’t address what the customer truly needs. Your requirements may be exactly what the customer asked for yet not solve the real problem. Getting requirements right helps us to solve the right problem with the right solution while focusing on real value.   The Challenge with Getting Requirements Right There’s frequently a misconception that we need to come to a requirements elicitation meeting with exactly the right questions to ask. That approach actually slows things down and prevents you from finding the true need. Asking too many questions and being forced into a checklist of questions can derail the conversation from leading to a better understanding of the context and the underlying business problem to be solved. Instead, start with a better question; What is the real business objective or goal we’re trying to achieve?   In Order To . . . Starting with the goal (the big ‘Why’) allows you to drill down and understand the context and the scope of what you’re trying to achieve. Asking why an initiative is important to get to the ‘in order to’ statement helps you decompose a problem further and discover the right questions to ask. It allows you to drive out the value and focus on the right things.   Business Modeling Language Using Business Modeling Language (BML) or a similar approach such as story mapping, you can visually decompose larger items into more detail and discover the full scope. BML helps you model the business process or unction and discover what it takes to achieve the goal. Asking “In order to do X, what do we need to do?” allows you to flesh out the details of the project and focus only on that which gets you closer to the overall goal.   By collaborating together and focusing on the ‘Why”, you can better manage scope, focus on value, and deliver better business outcomes. Listen to the full episode to hear all of Jared’s advice on how to get requirements right. http://traffic.libsyn.com/masteringbusinessanalysis/MBA117.mp3   Z Your Homework Try using the “in order to” clause to gain clarity, decompose requirements, and focus on value.   Links mentioned in this episode: Jared’s article: How to Get Business Analysis Requirements Right Jared Wiese IT Business Analyst | Career Coach Jared Wiese is an IT Business Analyst, Career Coach, and Life Strategist. His passion is improvement and he looks for ways to simplify and improve life for others. Jared is speaker and an active contributer to the Business Analysis community through his LinkedIn articles. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA117: Getting Requirements Right appeared first on Mastering Business Analysis.

In this episode, Paula Bell shares her tips and advice to break through the bureaucracy and red tape that holds many organizations back.  After listening to this episode, you'll understand: How bureaucracy can slow down your progress Why networking and stakeholder management is critical Approaches to navigate office politics How to NOT lose your integrity  Show Notes Office politics can slow progress and even make it impossible to run a successful project. The bureaucracy affects more than morale; it slows progress and makes it harder to get work done. Understanding office politics and developing a strategy for managing stakeholders will help you to have greater influence and get more done.   Listen to the full episode to hear all of Paula’s tips on successfully navigating office politics. http://traffic.libsyn.com/masteringbusinessanalysis/MBA115.mp3   Z Your Homework Work to understand your company’s culture and how decisions are made. This allows you to better understand people’s motivation and adapt your approach to get things done.   Links mentioned in this episode: Paula’s website paulaabell.com Paula’s past episode on Systems Thinking Paula’s past episode on Collaboration Paula Bell Paula A. Bell Consulting, LLC Paula Bell is a Business Analyst, consultant, mentor, author, and speaker known for providing guidance to aspiring business analysts. She’s held just about every role in a RACI matrix including business analyst, technical writer, project manager, developer, test lead, and product owner. Paula is a frequent speaker at industry conferences and writes articles on BA and project related topics. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA115: Political Martial Arts – Navigating Office Politics appeared first on Mastering Business Analysis.

In this episode, David Olson discusses the evolution of the Business Analyst role and its true value proposition.  After listening to this episode, you'll understand: How the definition and perception of the BA role has evolved Why the Business Analyst field requires multiple roles The real value that BAs bring to organizations How Agile changes the value proposition for the BA role  Show Notes A common perception of the Business Analyst role is that they are responsible for documenting requirements and nothing else. That perception leads to limitations and challenges with showing the true value of the role. In reality, business analysis involves much more than requirements. Some of the biggest value a Business Analyst can provide happens before the requirements stage and even before the project starts. There is tremendous value in helping the organization understand the current situation better and identify the real problems and opportunities they face. This leads to a better understanding of options, which could be addressed through projects or other approaches. The real value in business analysis is in helping the organization make the right decisions.   Evolution of the BA Role We’ve seen an evolution in the Business Analyst role and the way it’s defined by the International Institute for Business Analysis and the UK Chartered Institute for IT. That evolution has gone from a requirements focus to a focus on needs and recommending solutions. There are some potential threats to that evolution from organizational perspectives and the description of the role by other professional organizations which focus on requirements and in-project work. The progress in the evolution is headed in the right direction, but still has a way to go.   The Multiple Roles of the BA With the evolution of the BA role, the focus on out-of-project work, and the rise of Business Architects, there is a need for different types of Business Analysts. Similar to the healthcare field, there should be one overarching definition that encompasses the full value delivered and individuals who specialize in a specific area of value delivery. This can include in-project BAs who focus on requirements and viable solutions, Business Architects, and Strategic Analysts who focus on overall organizational strategy outside of projects. All of these roles have a core set of skills and purpose that tie them together, but the specialties allow each role to focus on and go deep in a specific area.   The Business Analyst Value Proposition Through analysis work at any level, whether inside a project or outside of a project across the organization, BAs can make information consumable and help their organization make the right decisions. We become a trusted advisor, present information and options, and advise decision makers on making the right choices. That can include decision option identification, examination of alternatives, facilitating the decision-making process, and facilitating the implementation on those decisions. This requires BAs to be proactive in identifying solutions and recommending options and alternatives. In the book, Smart Choices, the author recommends using Proact decision making method. The Proact method includes: Define the decisions Specify your objectives Identify Alternatives Understand the consequences Understand the trade-offs between the options Clarify what you’re uncertain about Understand the risk tolerance level Consider the link decisions Supporting this process is where Business Analysts can add value. By structuring this information in an understandable way and presenting it clearly to decision-makers with recommendations will allow you to influence your organization to make informed choices, leading to better outcomes.   Listen to the full episode to hear David’s advice on how to shift the perception of your role and how Agile changes this advice. http://traffic.libsyn.com/masteringbusinessanalysis/MBA114.mp3   Z Your Homework Change the way you approach your job. Focus less on the change aspect and focus more on the decision-making aspect. Bring some of that approach (the way you frame questions and how you present information and recommendations) to your daily work.   Links mentioned in this episode: BAWiki.com Website David Olson, CBAP Creator of BAWiki.com David Olson is a Senior Business Analyst with experience in defining, enhancing, and supporting applications and business processes primarily in the areas of Sales, Marketing, Web, Data, and Regulatory areas. Outside of his work, he also researches and write articles and reference materials for the BAwiki.com web site. Google+LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to brin

In this episode, Sinikka Waugh shares a problem solving approach to take you through incovering the right problem, identifying the right solution, and putting the right plan into action.  After listening to this episode, you'll understand: Why problem solving is a critical skill How to uncover the right problem and find the right solution What you can do to put your plan into action  Show Notes Problem solving is a vital skill, regardless of your role or level in the organization. Without an effective problem solving approach, you will likely treat the symptoms instead of the underlying cause and have little positive impact. A problem is anything preventing you from going where you want to be next. This can be at an individual, team, or organizational level. The Right Stuff problem solving approach involved identifying the right problem, uncovering the right solution, and creating an action plan to enable that solution.   The Right Problem When beginning any problem solving, bring others in to get diversity of thought. Once you include others, start with the Five Whys technique by asking ‘why’ five times. The focus should be on why the problem exists. For each answer to the Five Whys, ask ‘why’ five more times. For each of those, you can ask ‘why’ five more times. From that rapid list of many causes, patterns and commonalities will likely emerge. Focus on the items that you can solve, want to solve, and should solve. Those common themes are the right problem to solve.   The Right Solution Once you identify the right problem to solve, brainstorm to identify possible solutions. Go for quantity at first without filtering of judgment. After you have a list of solutions, you can narrow down the list to those that are feasible and vote on the top solutions to explore. For each feasible solution, gather information and find the solution with the best BODI. The acronym BODI stands for Benefits, Obstacles, Data, and Instinct.   The Best BODI To discover the solution with the best BODI, make a chart for each potential solution to list the benefits, obstacles, data, and instinct information. Benefits: What are the benefits of this solution? Obstacles: What are the obstacles associated with this solution? What could potentially prevent it from being successful? Data: What data do we have about this solution? Do we have data that makes sense to us? Instinct: Do we believe this is a right solution for us right now? Complete the benefits, obstacles, and data for each solution, and then see what your instinct tells you about each option. Is it a right solution for now? You want to find the solution with the best benefits, fewest obstacles, and that your instincts tell you that this is a good choice.   The Right Action Plan To be successful in any action, you need to know what, why, and how. The previous steps of identifying the right problem and solution as well as uncovering the benefits tells you the what and why. The well thought out ‘why’ also helps get the right people involved once you take action. Additionally, you’ve already discovered risks when you identified obstacles, so you can work to address those risks. Now that you have the what, why, and associated risks, you can focus on the how – executing your plan. You can also use the data you identified earlier to help drive the action plan. See the links section for introductory worksheets and materials from Sinikka to help you solve problems. Listen to the full episode to understand how to implement Sinikka’s problem solving approach. http://traffic.libsyn.com/masteringbusinessanalysis/MBA113.mp3   Z Your Homework Include others in your problem solving approach. Include others in the process and time box the approach to finding the right solution to the right problem.   Links mentioned in this episode: Sinikka’s website Your Clear Next Step Introduction to Problem Solving More worksheets from Sinikka Problems Worksheet Solution Worksheet See me at the Wisconsin Business Analyst Development Day in May in May 2017 Sinikka Waugh Your Clear Next Step Sinikka Waugh is a recognized leader in understanding people and in adapting tools, techniques, and processes to meet the demands of the situation at hand. As a project manager, business analyst, facilitator, trainer, and coach, Sinikka is known for consistently helping teams find innovative ways to solve problems and get things done. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA113: Problem Solving – The RIGHT Stuff appeared first on Mastering Business Analysis.

In this episode, Caleb Carroll helps us deliver better business value through a User Centered Design approach.      After listening to this episode, you'll understand: The difference between UX, UI, and CX Why user centered design is critical to your success Tools you can use to take a user centered design approach  Show Notes A user-centered design is focused on who users are, how they think, and what they’re trying to do. This episode focuses on how user centered design techniques can enhance your Business Analysis skills set. Focusing on the user increases value delivered, faster solutions, and greater productivity. Caleb discusses the importance of a user centered design approach and the tools and techniques you can use to make sure you’re building valuable solutions for your customers.   Listen to the full episode to hear all of Caleb’s advice and tools recommendations for using a User Centered Design approach. http://traffic.libsyn.com/masteringbusinessanalysis/MBA112.mp3   Z Your Homework Shift your mindset to focus on who are you ceating a solution for, what they need, and how are you going to make their lives easier. Get close to your customers and use observation to get information you need to find the right solution to their needs.   Caleb Carroll User Experience Design Lead Caleb Carroll is a User Experience Designer, technology lover, whiteboard enthusiast, and professional question-asker. He is a Certified Usability Analyst through Human Factors International and has a Graduate Certificate in Human Computer Interaction from Iowa State University. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA112: User Centered Design appeared first on Mastering Business Analysis.

Design Thinking is business analysis done the right way. In this episode, we’ll explore the tools of Design Thinking and how this approach helps ensure you build valuable solutions.    After listening to this episode, you'll understand: What you can do about shelfware and wicked problems How to use common techniques to understand the real problem Why a human centered approach helps you find the right solution The mindset shift needed to adopt a Design Thinking approach  Show Notes Design Thinking is good business analysis done the right way. It helps ensure that we build the right things; solutions that will be valuable to our customers. You can use Design Thinking to solve wicked problems. Wicked problems are complex problems for which the right solution isn’t immediately clear. The real problem is shelfware; creating a solution that’s what the customer asked for but isn’t what they really need and therefore goes unused. We’re often given a solution to implement and fail to explore whether or not it’s the right solution. Without innovation and a human centered focus, we’ll find it more and more difficult to surprise and delight our customers or provide significant business value. The Three Lenses To find the sight solutions for our customers, we need to look at solutions through three lenses. Those lenses are Business Value, Customer Experience, and Technical Feasibility. Is it valuable to the business and customers? Focusing on business value (the ‘Why’) helps to develop solutions that maximize value. That value can be in the form of income, cost reduction, risk reduction, or anything else important to your customer. Is it a great customer experience? Without a positive customer experience, we’ll create shelfware or lose customers, which results in less business value. Is it feasible? If the proposed solution isn’t technically feasible, you can’t build it (or at least it would take too long or be too expensive). Consider whether or not your organization has the technical skills, architecture, personnel, and skills needed to build and maintain the solution. You need all three lenses to create a valuable solution that customers will love. Design Thinking Process Design Thinking is more of a mindset than a process. While there are many tools, techniques, and approaches to Design Thinking and we’ll explore the approach used by the Stanford Design School. The Stanford approach applies five modes in an iterative process to break things down into the Problem Space and the Solution Space. The five modes are: Empathize Define Ideate Prototype Test   The Problem Space Use the Empathize Mode to gain a deeper understanding of the customer. This helps us to better understand pain points and what customers would find valuable. Here, we can use tools such as Five Whys, Personas, Empathy Maps, interviews, Observation, and Customer Journeys. In the Define Mode, we define the problem to clarify scope. Using the outputs from the Empathize Mode, you can define a problem statement or hypothesis. This allows the team to focus on solving the right problem.   The Solution Space In the Ideate Mode, you come up with many potential ideas focusing first on quantity and then focusing on quality. We use divergent thinking to find many possible solutions and then convergent thinking to eliminate, combine, and otherwise reduce the number of potential solutions (essentially brainstorming). When you move into the Prototype Mode, you build something that customers can react to and provide feedback. Start with the simplest thing possible such as paper prototypes and then move to move robust prototypes. In the Test Mode, you provide the prototypes to customers and get their feedback. That feedback can then be used to adapt, come up with new ideas, or even modify your hypothesis. These modes occur in an iterative cycle, not linear steps.   Listen to the full episode to learn about the mindset shift necessary to be successful and the techniques you can use in Design Thinking. http://traffic.libsyn.com/masteringbusinessanalysis/MBA111.mp3   (function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//forms.aweber.com/form/17/161433117.js"; fjs.parentNode.insertBefore(js, fjs); }(document, "script", "aweber-wjs-fz0nvygls")); Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA111: Design Thinking IS Good Business Analysis appeared first on Mastering Business Analysis.

In this episode, Scott Stribrny shares four techniques to help you identify and address ambiguous requirements and create a common understanding.  After listening to this episode, you'll understand: The impact ambiguous requirements can have on your project How to identify and address ambiguity How to get started implementing techniques to reduce ambiguity  Show Notes Ambiguous or unclear requirements lead to confusion and waste and result in failed projects. Luckily, there are a few simple approaches for identifying and fixing ambiguous requirements. To discover ambiguity in project requirements, we can use a set of four heuristics. Search Subjective Terms Memorization Technique Mary Had A Little Lamb Technique Ambiguity Poll Technique   Search Subjective Terms One of the easiest ways to identify ambiguous requirements is to search for subjective terms. Subjective terms are words that are not specific and can mean different things to different people. Words and phrases such as fast, easy, user friendly, and state of the art are all subjective. How fast is fast? What’s easy for one person may be difficult to another. Start by creating a checklist of subjective terms by brainstorming and then scan your requirements for those terms. When you find a subjective term, change it to something move specific and testable. For example, “fast” may be changed to “a response time of 3 seconds or less”.   Memorization Technique With the memorization technique, you read or otherwise briefly share the requirement with stakeholders and then have them recall the requirement from memory. Often, stakeholders will leave out or replace words or phrases when they recall the requirement. Missing or replaced portions of the requirement often indicate ambiguity. This is because the stakeholder’s mind is working to find meaning in what they heard and they omit or add to the requirement to fill in gaps.   Mary Had a Little Lamb Technique The written word is a terrible way of conveying information. People can read the same words with different inflection and interpret the meaning differently. With the Mary Had a Little Lamb technique, you read the requirement out loud stressing different words or phrases to uncover areas that can be interpreted differently. For example, saying “MARY had a little lamb” implies that it was Mary’s lamb and not Cathy’s or Ann’s lamb. “Mary HAD a little lamb” implies that Mary had a lamb in the past, but no longer has one.   Ambiguity Poll Technique The ambiguity poll technique helps you to identify misunderstandings be having stakeholders size the requirement using a common metric. Differences in the sizing among stakeholders possible indicates that there is not a shared understanding about the requirement. This leads to a conversation about why people voted or sized it the way they did to uncover any misunderstandings. This approach is very similar to story sizing used by many agile teams. Wide differences in story points frequently means that there are differences in understanding about the user story and more clarification is needed.   Listen to the full episode to find out more ways to reduce the ambiguity in your requirements. http://traffic.libsyn.com/masteringbusinessanalysis/MBA110.mp3   Z Your Homework Pick one of the techniques to reduce ambiguity discussed in this episode and apply it to your requirements. You can do this on your own or for even more impact, do it together with a co-worker. That will give both of you practice in applying the technique.   Links mentioned in this episode: Group Atlantic website: Group Atlantic Scott’s presentation on Managing Ambiguity Scott’s prior episode – Step Up to Leadership Scott Stribrny President, Group Atlantic, Inc Scott is a senior advisor to Fortune 500 CXOs, and program and project managers worldwide on the effectiveness, rewards, and risks of their high-tech programs and policies. Currently advising on agile organizations, high-performance teams, techniques for effective product requirement definition and risk management, as well as adapting modern software development techniques to fit specific business needs. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA110: Managing Ambiguous Requirements appeared first on Mastering Business Analysis.

In this episode, Greg Kulander and Charlene Ceci help us get back to basics and establish a strong foundation for your business analysis skills and techniques.    After listening to this episode, you'll understand: Why it’s important to go back to basics – even for experienced professionals The who, what, when, where, why and how of the project Basic (yet critical) techniques for obtaining requirements How to tailor your review process to ensure approval  Show Notes A good process can help an organization create and sustain good requirements. A requirements tool can help a team be more efficient. However, we often focus too much on the process and tools and not enough on the fundamentals of business analysis. Foundational practices in business analysis come down to three areas; asking good questions, eliciting requirements, and gaining approval. These three components not only make up foundational competencies for the role, they also provide a base upon which to build to much higher levels.   Asking Good Questions Asking good questions helps you to discover the real problem your customer is trying to solve. Think of the five Ws and one H you likely learned in school. Questions beginning with who, what, where, when, why, and how help you to explore the problem context. Example questions include: Who is the solution being developed for? Who are we creating the requirements for (who is the team consuming requirements)? What business problem are you trying to solve? Make sure that there’s alignment and agreement within the team as to the problem being addressed. What’s the motivation for trying to solve this problem? When does the solution need to be completed? When does the new system need to be available ((this helps you to understand non-functional requirements such as system uptime)? Why is this project being requested and why is it important? Why is one solution favored over another? What are the factors against which we’re judging the solution? These questions help you to understand trade-offs and priorities. How is the solution going to be used? This question helps you to understand expected benefits. How do we judge the success of the solution (success criteria)? The good questions mentioned above can help you to discover the right problem to solve, understand priorities, and identify the right solution.   Eliciting Requirements Once we have an understanding of the right questions to ask, we can prepare to elicit requirements. Three core requirements elicitation approaches are interviewing, job shadowing, and facilitation. When preparing to interview, you need to understand who to interview. Consider all parties impacted by the problem you’re trying to solve and the different types of users of the proposed solution. Be mindful of the time of the people you’re interviewing and get buy-in from their manager. Job shadowing allows you to see how users interact with the system or deal with the problem you’re trying to solve. It gives you the opportunity to connect with the person performing the job. It also helps you understand much more quickly the process, approach, and problems faced by the user. During job shadowing, you will likely be asking questions throughout the process. Be sure to ask the person you’re shadowing why they do things in a certain way that deviates from process manuals or the way you understand the process to work. Perform job shadowing in a respectful way. Make it clear that you’re trying to understand the process and any challenges in completing the process so that you can help create a solution that meets their needs. Be sensitive to the fact that shadowing takes time away from their job or at least slows them down. To be successful at facilitation, you need to be able to think on your feet. The biggest challenge is keeping the group on track and working toward the goal. Using tools such as a parking lot and ensuring everyone’s voice is heard helps make the session valuable.   Gaining Approval Once you have the information from your elicitation, you need to find a way to package and deliver it to your stakeholders. Templates can help you organize information about the requirements into a consistent format. This makes it easier for stakeholders to review and use the information. Templates can also serve as a reminder of anything you may have missed and provide a stricture for reviewing requirements with stakeholders. In most cases (especially in waterfall environments), you’ll need to get stakeholder approval of requirements to move forward. Key to success in this area is knowing your stakeholders and ensuring that you’ve identified everyone who may be impacted by the project and the proposed solution. Requirements reviews and walk-throughs help facilitate a discussion about the requirements to create a shared understanding and agreement. Acting as an advocate for your stakeholders will make it easier to gain approval. Have a plan for c

In this episode, Amanda Tygart and Jenny Swan help you to find the minimum viable product and use it to identify work that you should deliver first.    After listening to this episode, you'll understand: How to use personas to help with prioritization How to slice work into valuable chunks What minimum viable product (MVP) really means How to identify the MVP for your project What to do after you deliver the MVP  Show Notes When everything is important, nothing is important. If we elicit a long list of wants or a requirements backlog, how can we know where to start? The approach that Amanda and Jenny share will help you to find the first slice you should take to get feedback and ensure you’re building the right solution.   Start with a Goal To help you prioritize, start with the goal. If you don’t have clarity about the goal, it’s hard to discover the right priorities. When a stakeholder starts talking about a solution to implement as a goal, you’re clearly going down the wrong track.   Use Personas Once everyone has clarity as to the goal, it’s important to understand who the end users are. There are likely different types of users with different needs. Understanding your customers should be done before you discuss potential solutions. One way to get clarity on your customer needs is to create personas for each of your customer types. Personas are avatars for your customers and help you better understand needs, wants, and constraints. They also help you focus on a specific person (albeit a fictional person) instead of a vague notion of a customer group.   Observation Another powerful yet underutilized tool to help understand your customers is observation. You can observe customers interacting with your system or working through the problem you’re trying to solve for them. This helps you gain empathy and better understand their needs. Using personas and observation helps you filter the list of wants from stakeholders. It puts a fact based framework around what’s important to your customers.   The MVP The minimum viable product (MVP), may be different things depending on your context and situation. Minimum means that we’re looking for the simplest thing we can do to get feedback and learn. Viability is about sustainability and scalability. The MVP doesn’t necessarily need to be scalable, but you need to consider the viability within your context and what you’re trying to learn. Be intentional about viability. When working toward the MVP, you can start with a low fidelity prototype such as a paper prototype. Starting with the simplest form allows you to learn and adjust without wasting time potentially building a high fidelity prototype of the wrong thing.   Brainstorm to Extract the MVP To help you identify the MVP, use brainstorming techniques to generate a lot of ideas without judgment. Once you have all your ideas (or wants), look at it through different lenses such as location or customer segment. These lenses help you filter the ideas to what applies to a limited area of focus; something that you can build and on which you can get feedback. Story mapping can also be used as a form of brainstorming to generate ideas and find a slice through the journey that will create an opportunity to learn and adapt.   After the MVP Sometimes, you’re done after delivering the MVP. More often, you’ll iterate and build on that MVP to create additional capabilities (minimum marketable features). It’s important to get feedback and observe how customers are using your MVP and subsequent releases so that you can adapt your strategy going forward. We often treat backlogs as a to do list. Instead, think of it as a list of options and consider the diminishing returns as you get to lower value items in your backlog.   Listen to the full episode to understand how to use the MVP and personas to prioritize your project. http://traffic.libsyn.com/masteringbusinessanalysis/MBA108.mp3   Z Your Homework Go through the project goals with the team to gain clarity. Also, remember that you can always build personas; even in the middle of a project. Use the tactic of observation throughout your project to watch what users are doing and how people go about solving a problem. This helps you reevaluate your assumptions and assess future work.   Links mentioned in this episode: Link to Amanda and Jenny’s presentation at Agile 2016 Amanda Tygart Process Engineer-Agile Coach Amanda is a Business Analyst by heart. She’s passionate about Agile and the BA role within Agile. Amanda loves to teach and spread the gospel about the benefits of Agile and how it can improve programs and domains. TwitterLinkedIn Jenny Swan Agile Coach Jenny is a Business Analyst turned Agile Coach. At Agile 2016, Jenny and Amanda gave a presentation entitled “Everything is important RIGHT NOW! How do I determine a Minimum Viable Product?” TwitterLinkedIn Thank you for liste

In this episode, Richard Dolman helps us take backlog refinement from an underutilized meeting that doesn’t get the respect it deserves to a powerful forum for collaborative discovery.  After listening to this episode, you'll understand: The pitfalls of not refining your backlog regularly What is needed to make a refinement session successful What should happing during refinement How incomplete user stories can actually help a team  Show Notes Backlog refinement meetings can be a great opportunity for teams to ensure near term priorities are understood and ready for the team to work on. Unfortunately, many teams rush through this activity, leading to misunderstandings and acting like the backlog is a simple to do list. Backlog refinement is the act of the team reviewing the items in the backlog and discussing the detail to get clarity as to priorities and plan their work. It’s an opportunity for the team to come together and collaboratively discover what they’re being asked to do. Refinement includes elaborating on the backlog items for further clarity, decomposing large items into smaller pieces, doing lightweight functional design, elaborating on acceptance criteria, and even some sizing. The goal is to have near term, high priority backlog items that are small enough and understood by the team to begin working on in the next iteration. What defines a user story or backlog item as “ready” is up to the team. That Definition of Ready should be clearly understood and agreed upon by the entire team.   Prerequisites to a Successful Refinement Session Start with a vision. A vision that’s understood and visible helps the team to focus on achieving that goal and allows them to question anything that may be taking them away from that goal. Next, a roadmap should be used so that the team understands the progression and what they’re working towards with each iteration or release. The roadmap also gives the team context so they know where they are in the product delivery cycle and if any architectural runway needs to be build out.   Making Your Refinement Sessions Better Once a vision and roadmap is in place, the team can address how they see their ability to deliver the work and uncover opportunities to provide value. The team should feel confident that they understand the work that’s coming, how it ties to the vision, why it’s important, and how they’ll approach the work. The techniques and approach teams can use during backlog refinement can range from simply talking about the backlog item to creating visualizations and models to better understand the work. Teams may also compare what they need to do to the architecture to better determine if the need architecture is in place. Similarly, team members should uncover and discuss any dependencies. The refinement session can include writing new stories, slicing large backlog items into smaller stories, elaborating on backlog items to get clarity on the detail, and asking questions about and negotiating acceptance criteria. All of these activities and conversations drive confidence that when the team is ready to pick up one of the backlog items, they’ve exposed the critical aspects of the story and the work is understood.   Go DEEP While good user stories follow the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable), the product backlog should be DEEP. DEEP is an acronym standing for Detailed appropriately, Emergent, Estimable, and Prioritized. Emergent refers to the fact that new information and feedback can come in at any time that may affect what’s in the backlog as well as its priorities. This means that not everything will be known upfront and we need to get comfortable with letting some of the details emerge as part of the refinement process.   Don’t treat your backlog like a vague to do list. Make sure it’s an interactive session where team members can collaborate and create a shared understanding, which will have an impact on not only what the team products, but the quality and speed as well. Listen to the full episode to hear all of Richard’s tips on getting more value out of a backlog refinement session. http://traffic.libsyn.com/masteringbusinessanalysis/MBA107.mp3   Z Your Homework Use visualization as much as possible. This includes having a visual roadmap, making the architecture visible, and using techniques such as story mapping, empathy maps, wireframes, and other approaches. Bring those visualizations in to your refinement session to help create a shared understanding. Secondly, don’t follow the same pattern for every refinement session. Consider what you need to know in each refinement meeting and adapt your approach to meet that need. Finally, look at the patterns in your team during refinement sessions and see the downstream impacts. If the team experiences unfinished backlog items or other impacts, it may be an indication that you’re not going de

In this episode, Scott Killen tells us how to quickly elicit requirements from a large, diverse group of people with very little preparation using an approach he calls a Rapid Requirements Gathering meeting.      After listening to this episode, you'll understand: Why Rapid Requirements Gathering (RRG) meetings are so powerful How to facilitate an RRG meeting The pros and cons of using an RRG meeting How to get started using this approach for yourself  Show Notes Want to quickly elicit requirements from a large, diverse group of people with very little preparation? A Rapid Requirements Gathering meeting can help you do just that. It’s a mixture of high level rigid structure, organized chaos, and some fun. The Rapid Requirements Gathering meeting is structured as a set of ten time-boxed activities. Each activity is highly interactive and collaborative, leading to great outcomes. As a result, you’ll be able to quickly develop a categorized, prioritized, and actionable list of requirements from a group of 10 to 75 stakeholders. You’ll need a room with smooth walls, a few different colors of 3×5 yellow sticky notes, sharpie markers, and a rubber band.   The activities during the Rapid Requirements Gathering meeting are: Introduction and review: Introduce all participants and review the meeting goal. It’s helpful to explain the meeting format and give examples of requirements to demonstrate the kind of information you hope to get from the meeting. Enumerate items: Attendees silently brainstorm requirements for a fixed period of time using the sticky notes and sharpie markers. Review items: After randomizing the sticky notes from each attendee to preserve anonymity, read each requirement out loud and stick it on the wall. As you read each requirement, new requirements may come up and should be added. Associate items: Attendees group like requirements together into affinity groups. If new items are identified, they can be added. Categorize items: Create a meaningful label or title for each affinity group. Rationalize items: Combine or remove duplicate requirements and add, rewrite, or re-categorize individual requirements as needed. Prioritize items by category: Teams of attendees collaborate to rank order the requirements in each affinity group. Discuss results: Discuss the highest priority items for additional detail and clarity. Rank overall importance: Use dot voting to identify highest priority requirements across all categories. Final Review: Summarize the meeting results and discuss next steps. You will likely need to follow up with stakeholders to get more detail on some items. After the meeting, collect all of the sticky notes for later use.   Listen to the full episode to understand how to facilitate a rapid Requirements Gathering meeting, hear the pros and cons of using this approach, and to find out what to do with the rubber band. http://traffic.libsyn.com/masteringbusinessanalysis/MBA106.mp3   Z Your Homework Try using a Rapid Requirements Gathering meeting with a small group of people using Scott’s instructions (see links below). It’s much easier to start with a small group to gain confidence with using RRG meetings.   Links mentioned in this episode: Rapid Requirements Gathering Meeting Facilitation Guide Scott Killen Agile Practice Leader at Paypal Scott Killen is a founder and previous President of Agile Austin as well as the Agile Practice Leader for PayPal. He is a Certified Scrum Master and Certified Scrum Practitioner through the Scrum Alliance. He’s a Certified Project Management Professional (PMP) and a Certified SAFe consultant. Scott also instructed IT Project Management and Agile Project Leadership at Austin Community College. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA106: Rapid Requirements Gathering appeared first on Mastering Business Analysis.

In this episode, ten thought leaders in the field if business analysis and project management share the best advice they ever received. Happy New Year! To start the year off right, I’ve brought together some of the top leaders in the world of business analysis to share the best advice they ever received.   Kupe Kupersmith | President, B2T Training Be comfortable with who you are and be who you are. You can look at other people to see if there are qualities you want to take on but you’re never going to be that other person you are who you are just be you.     Richard Larson | Founder and President of Watermark Learning Do what you love and what you’re good at and success will follow.     Elizabeth Larson | CEO of Watermark Learning Whenever possible, spend time in your stakeholder’s area using their systems and doing what they do. This not only helps build trust, it also gives you the knowledge to identify problems and make solution recommendations.   David Mantica | President, ASPE-Training David shared two pieces of advice that he received at different points in his career. You’re going things at work that you want to do and things that you don’t want to do. Focus on the things you don’t want to do and complete those first. They are usually the most important. You’re a leader. People watch you. Be cognizant of that.   Roxanne Miller | President, Requirements Quest Get some good books, read them, and apply the lessons from those books (Roxanne recommends Software Requirements by Karl Weigers). Also, get a mentor.     Paula Bell | Paula A. Bell Consulting, LLC Be true to yourself and be authentic. Don’t let your circumstances define who you are rather overcome them to define where you’re going.     Cheryl Lee | Co-author of the book Effective PM and BA Role Collaboration You can talk to people about the value you provide to the organization, but the best way you can prove your value is to show them.     Hans Eckman | Eckman Guides An ecosystem is greater than the sum of its parts. Take a step back and look at the organization holistically to see if there are larger patterns or influences we need to take into account for our solution.     Adrian Reed | Principal Consultant at Blackmetric Business Solutions Adrian shared three pieces of advice he received: Embrace uncertainty. It’s okay not to know yet. Network Be authentic and be yourself.   Angela Wick | Founder and CEO of BA-Squared, LLC Your job is to add value every single day. Ask yourself three questions: At the beginning of the day ask “how will I add value today?” In the middle of the day ask “How am I adding value by doing this?” At the end of the day ask “Did I add value today?”   I hope you’ve found something in this advice that can help you in 2017. Of course, it will only have an impact if you take action. Make 2017 your year. Listen to the full episode to hear the best advice these ten thought leaders ever received (as well as my own). http://traffic.libsyn.com/masteringbusinessanalysis/MBA105.mp3   Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA105: The Best Advice I Ever Received appeared first on Mastering Business Analysis.

In this episode, I’ll share my predictions for 2017 and what they mean to you. Based on what’s been happening in the industry, I’ve peered into my crystal ball and have four predictions that will impact Business Analysts, Project Managers, and other project professionals. There are four industry trends that will shape your role in 2017. Those trends are: Technology shifts The focus on products over projects The continued use of Agile & lean The evolving role of the Business Analyst   Prediction #1: Technology Changes Will Shape Your Role There will be a greater push toward machine learning, the cloud, and DevOps. You’ll need to understand at least at a high level what these tools and associated practices are in order to be able to advise your organization on potential solutions. The other technology trend for 2017 is the Internet of Things (IoT). What this really means is that devices will have more sensors which provide more data. That leads us to greater usage of big data tools and practices. Project professional who understand big data concepts and can mine data for business insights will be in high demand.   Prediction #2: There Will Be a Shift from Projects to Products The shift in focus toward products is really a focus on value. Businesses need better results from investments and they’ll need project professionals who can lead them to better business outcomes. This is more than just selecting the right projects. It’s focusing on features and capabilities that will be valuable to customers in a continuous flow and adapting along the way. This means less project requirements in favor of features and capabilities with requirements evolving over time. The approach of big design upfront (creating all requirements in the beginning) will be used less and we’ll deliver in smaller phases or increments, adapting along the way based on customer feedback. With the focus on products, the skill (and role) of Product Management will be in greater demand.   Prediction #3: There Will Be a Continued Push Toward Agile and Lean Practices Organizations that have not yet adopted Agile and lean practices will begin experimenting with those practices. That’s because there is more pressure in the market to “be agile” and provide what customers perceive as faster and better delivery. Many organizations will continue to struggle with Agile implementations and will adopt a hybrid approach in 2017. Some that say they are fully Agile will be agile in name only, adopting some of the practices without the needed shift in mindset. With this shift, project professionals will need to adopt light-weight practices and create less documentation. The focus will be on outcomes over outputs. As a result, highly collaborative approaches such as visual modeling and user stories will be used to reduce documentation. Many organizations will also struggle to understand where the BA fits in an Agile environment. Through that challenge, I think we’ll see the real value of the Business Analyst; value managers. Organizations will also struggle with colocation versus a geographically diverse workforce. As a result, companies will adopt more tools for virtual collaboration. People who understand how to make the best use of those tools will be better off.   Prediction #4: The BA Role Will Evolve Because of the trends mentioned earlier, technology shifts, focusing on products, and the emphasis on Agile, the Business Analyst role will evolve in 2017. While business analysis will be wildly popular in 2017, we’ll see less roles with the title of “Business Analyst”. There will be more combined Project Manager/Business Analyst roles in 2017 as organizations struggle to figure out where both roles fit in Agile. More BAs will move into Product Owner or Project Manager roles and new specialized roles will emerge. To be successful, Business Analysts will need to focus on value and look at initiatives through three lenses of business value, technical feasibility, and user experience. The shift in focus also means that there will be an increase in the use of Design Thinking and Lean Startup approaches. With much of the evolution in the BA role, practitioners who want to be successful will need to focus their training and development of soft skills. Facilitation, communication, collaboration, and the ability to influence will be critical. The biggest soft skill area that I see in 2017 is emotional intelligence (EI or EQ). This is the ability to understand your own emotions and those of others to adapt your behaviors. A higher EQ leads to better relationships and a greater ability to influence and collaborate.   Listen to the full episode to hear the full details of these four predictions including what will happen to the BA role with the emergence of new certifications. http://traffic.libsyn.com/masteringbusinessanalysis/MBA104.mp3   Thank you for listening to the program To get more valuable content to enhance yo

Happy holidays! In this episode, we hear the tale of Mr. Finch as he tries to sabotage the project, read in the style of the popular children’s author, Dr. Seuss.   Every stakeholder at Acme liked the project a lot . . . But Mr. Finch, who was from Finance, did not Mr. Finch hated projects; he thought they were all messes No one knows why for sure, but I have a few guesses It could be the impact they had on his group. His system was complex; people left him out of the loop. But probably the most likely reason of all, Was that his vision was just a little too small. Benefiting his department was Finch’s singular goal. He didn’t consider the value to Acme as a whole. Whatever the reason, as the project progressed, Mr. Finch was planning something no one would have guessed. For next week, old Finch knew, would be implementation. And that scared Mr. Finch; experienced in this situation. It would arrive with cheering and all would look great. Until complaints start coming and the reports will be late. First would come emails; asking for more data Then the errors and bugs will start coming; it won’t be tested in beta. “My precious ledger will be broken!” Finch said shaking his fist. “No one understands; my needs will be missed.” Then delays and more changes; always such a mess. Working late hours, more gray hair from the stress. The more Finch thought, the more he began to worry. He must put a stop to the project, and do it in a hurry. “Why, I’ve been at Acme for 15 years now.” “I must stop this project from coming! But how?” As he schemed and plotted during that day’s JAD session, He saw the BA and thought “Ah . . . I’ll teach him a lesson!” He would meet with the BA, in the spirit of cooperation. Any then destroy the documents – the output of elicitation. For without the documents, the project will surely fail. With no changes to his process, Mr. Finch would prevail! Clearing his throat, Mr. Finch asked for a meeting. And later in his office, met the BA with a warm smile and greeting. As the two discussed the project, the BA asked some great questions. They drew on the whiteboard, Mr. Finch even offered suggestions. “What harm could it do?” thought old Finch with a sneer. The documents will go missing; I won’t shed a tear. Without requirements and specs, no one will know what to do. The project will be lost; no one has a clue. That very night old Finch put his plan into action. Deleting files from the repository while laughing with satisfaction. Away to find hard copies he flew like a flash. He shredded them all and emptied the trash. That old Finch was so cunning and mean, To ensure there was no trace, he even wiped the whiteboards clean. He hid Post-Its and markers to each cabinet he flew. He locked them all away – a place only Finch knew. From hard drives and thumb drives to notebooks and ink, Finch removed all project records, then went out for a drink. As he sat in the bar, sipping his cold ale, He laughed to himself; for he’d made the project fail. “When launch day comes, there will be no more cheering.” “No more changes – what I had most been fearing.” “I’ll stop every project from this moment on.” “Documents are the key, and the BA’s just a pawn.” “He writes the documents that tell others what to do.” “A note taker, really; he doesn’t have a clue.” That night as Mr. Finch placed pillow to head, He chuckled once more, for he had nothing to dread. He dreamed wonderful, awful dreams of a place without change. Nothing unfamiliar, awkward, or strange. As the planned implementation date drew ever near, Old Finch whistled happily; he had nothing to fear. When project launch day had finally arrived, Finch pretended to be concerned, an emotion contrived. He arrived in the office will before dawn, So he could witness the mayhem his plotting had spawn. As time counted down with each single tick, He grew confident in his plan, no more changes will stick. “Too bad for the BA!” Finch was happily humming. “I’ve finally done it – stopped the project from coming!” The sponsor is likely discovering now, That his project has failed and the BA disavow. I’ll hear yelling and questions and strong accusation. Future projects will be questioned – it’ll be a vacation. He thought to himself, “That will be something to hear.” So he tilted his head and put his hand to his ear. And he did hear a sound coming down the hall. But it wasn’t quite what Finch expected at all. It was the sound of cheering and dashboards were green. Finch sat there puzzling, “What could it all mean?” “It came without a BRD! It came without specs!” “It came without documents, bugs, and stress!” His own team was cheer

In this episode, Rich Mironov will help us to better understand the role of Product Manager, how it differs from Product Owner, and what we can do to make sure we build a solution that drives success for our organization.  After listening to this episode, you'll understand: What product management is How a Product Manager differs from Product Owner How you can support product management activities  Show Notes A Product Manager is the person who has one foot in the market side and one foot in the engineering side. They make sure we not only build things right, but build the right things that drive success for the company. The measure of success for a product manager isn’t that we ship stuff on time, it’s delivering things that drive customer joy, market advancement, and value in the minds of our customers.   Product Owner vs Product Manager PO as defined by Scrum – inward facing portion of product management. Direction is given at a higher level. In essence, Product Owners implement choices, decisions, and strategies that someone else has made by breaking them down at the team level for execution. Good Product Owners are focused on goals and value and get out from behind their desks to better understand customers and markets. They’re not just taking direction. The challenge is that many products can’t be delivered by just one team. This assumes that the teams are properly structured with the right skills to deliver their portion. It also assumes that the solutions developed by multiple teams will somehow come together for a cohesive, valuable solution. Another challenge is that these individual teams often focus on output versus outcomes. Instead of focusing on delivering stories, teams need to focus on delivering positive business outcomes and value.   Measuring Business Value Often, business value is expressed either as a vague guess of future revenue, cost savings, or hours saved. There’s a huge margin of error in these value estimations. Additionally, the expression of value in terms of time saved is meaningless unless we understand what can be done with that saved time. If that free time does not translate into a reduction in staff or reduced hiring needs, perhaps the people can now focus on income producing work. Otherwise, there is no real value in the time savings. Bringing along a User Experience (UX) designer and engineer to speak with the customer also helps to bring out different perspectives and often results in better outcomes.   How Can We Help? Often, Product Managers give us a solution to implement. Instead, we’d like to get a problem to solve with the full context so that we can find an appropriate solution. As project professionals, we can help by walking them a step back to discover the underlying business problem and help them find the appropriate solution out of multiple options. “We’ll get better results if as a team we wrestle with the why and what before the how.” Creating a collaborative environment with diversity of thought centered on finding the best solution will yield greater results than a single Product Manager telling engineers what solution to build.   Listen to the full episode to hear all of Rich’s tips and advice for building the right solution. http://traffic.libsyn.com/masteringbusinessanalysis/MBA102.mp3   Z Your Homework Get out from behind your desk and talk to your customers. Get firsthand information on what their pain points are and identify what would be valuable to them.   Links mentioned in this episode: Rich’s website Mironov.com   Rich Mironov CEO, Mironov Consulting Rich Mironov is an author, speaker, and innovator. Rich coaches product executives, product management teams and agile development organizations. He also parachutes into software companies as interim VP of Products to fix company-level product, market, engineering, and revenue issues. Rich is also the author of The Art of Product 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. . The post MBA102: Product Management – Build the Right Thing appeared first on Mastering Business Analysis.

In this episode, Chris Sims shares four techniques to split your user stories to make them smaller, more manageable, and to help draw out details.  After listening to this episode, you'll understand: The problems big user stories can cause How big your user stories should be Why splitting stories helps create a shared understanding How just four splitting techniques apply to almost all stories  Show Notes User stories that are too big are a common problem. Big user stories make it difficult for the team to complete the story within the iteration and they often make impediments less visible. How big should a user story be? It depends. Near-term user stories at the top of your backlog should be small enough to be completed within a day or two. Items further down on your backlog can be larger and less refined. The farther out a story is, the bigger it can be because you don’t want to over invest in stories that may change. This is the power of doing just enough just in time. To get near-term stories into our state that’s ready for the team to execute upon, the team should meet weekly to review and refine the backlog. This refinement includes splitting stories to make sure they are small enough and adding detail around the acceptance criteria. Splitting stories not only creates smaller stories, it also generates more detail about the user story through a conversation of how that story changes when split. While there are dozens of ways to split user stories, knowing how to use just a handful of approaches will help you in most situations. Chris Sims recommends four approaches to splitting stories: Split by conjunctions and connector words By analyzing generic words Using acceptance criteria Through timeline analysis   Splitting Conjunctions and Connector Words Within the narrative portion of the user story (most commonly the “As a . . . I want . . . So that” portion), look for conjunctions and connector words such as and, or, but, with, etc. You can often split the story at those connector words and have two smaller stories. For example, the user story: “As an online banking customer, I want to be able to view my account and make updates so that my account has the correct information” can be split into “As an online banking customer I want to be able to view my account information so that I can verify information is correct” and “As an online banking customer I want to be able to make updates to my account information to correct any erroneous information”   Look For Generic Words Another way to split user stories is to elaborate on generic words used in the narrative portion. Generic words are terms that are very general and broad. You can identify generic words by asking yourself “What kinds of those are there?” Example: “As a user of the system, I want to be able to maintain my account details . . . “ For the above statement we can ask “what different types of users of the system are there?’ There may be users with administrative access, users with regular access, logging users, users who are not logged in, etc. You can create a separate user story for each of these user types. This not only makes user story smaller, it also helps you to have a more detailed discussion about the specific needs of a user. The word “maintain” is also a generic word. There may be many different actions as part of maintaining an account including updating name, updating e-mail address, updating mailing address, adding upgrades users, and even deleting the account. This approach allows you to incrementally build a solution that addresses different needs.   Use Acceptance Criteria Chris’ third way of splitting user stories is by acceptance criteria. Acceptance criteria are the pass fail tests that specify the scope of the story and tell you when it’s done. If the user story has four acceptance criteria, teams will often split it by breaking it into identical user stories each with only a few of the acceptance criteria. Chris’ approach is a bit different. Chris recommends looking at the acceptance criteria to determine if each criterion can be reformatted into a separate story. The acceptance criteria becomes the middle of a user story narrative and then you can identify who would benefit from that story and what their goal would be. That creates a complete, smaller user story.   Timeline Analysis for Splitting Stories The fourth wave splitting user stories is best for capabilities that involve user interaction. The approach is known as timeline analysis or use case analysis. With this approach you identify the steps that a user must go through to complete a process associated with the user story. Each step in that process may then become its own user story. This approach may allow you to validate and test with users as you deliver small pieces of functionality to ensure the solution meets their needs and make any needed adjustments.   Listen to the full episode f

In this episode, eight thought leaders in the business analysis field share their biggest mistake and what they learned from it. “Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.” – Otto Von Bismarck The above quote is the idea behind today’s episode. I’ve brought together eight leaders in the world of business analysis to share their biggest mistakes. The goal is twofold; first, to help you learn from the mistakes of others so that you don’t make the same mistake and secondly, to help you to realize that most mistakes aren’t fatal – you can make a big mistake and still have a successful career. The key is learning from those mistakes.   Richard Larson | Founder and President of Watermark Learning Richard shares the story of how his career was sidetracked from his true calling. What Richard learned: Your career is almost never a straight line. It can take many twists and turns. It may even seem like you’re moving in the wrong direction. Just remember that you often pick up new ideas, skills, and knowledge through all those twists that you can apply later in your career.   Elizabeth Larson | CEO of Watermark Learning Elizabeth tells us about how failing to follow some good advice limited her effectiveness. What Elizabeth learned: You’re more than just a translator or liaison. To be successful, you need to spend time to understand your stakeholders and develop trust and credibility.   Roxanne Miller | President, Requirements Quest Roxanne tells a story of how a missed requirement led to huge negative consequences for one organization. What Roxanne learned: Ask the right questions. Often, we’re given a solution to implement and don’t look outside the parameters we’re given. ‘What if’ can be a powerful way to start a thought provoking conversation. Developing an understanding of your industry and looking at things from the customer’s point of view helps you ask the right questions and address assumptions.   Cheryl Lee | Co-author of the book Effective PM and BA Role Collaboration Cheryl tells us how having overconfidence in your subject matter expertise can lead to problems. What Cheryl learned: Beware of the curse of knowledge. It’s great to develop subject matter expertise, but when you use your knowledge exclusively to develop requirements or solutions, you’re likely to miss something. Take a collaborative approach and avoid working in silos.   Paula Bell | Paula A. Bell Consulting, LLC Paula explains how the fear of sharing bad news can lead to a lack of trust. What Paula learned: Be transparent and don’t avoid sharing bad news. Being open and honest about problems lets us do something to resolve the issue sooner and it also leads to developing greater trust.   David Mantica | President, ASPE-Training David tells a story of how overconfidence in one solution caused him to miss out on a great opportunity. What David learned: Don’t get stuck in the weeds. Make sure you pick your head up once in a while and see what’s going on around you. Don’t get caught up in your own hubris; check your ego. You can love what you do and still be open to other people’s ideas.   Bob Prentiss | Bob the BA Bob shares two mistakes; one personal and one professional that helped shape who he is today. What Bob learned: Don’t avoid crucial conversations; the longer you wait, the harder it is to have those difficult discussions. The regret you’ll have is often harder to live with than facing what you need to do. Also, don’t let your ego get you in trouble. Understand that everyone plays a role in the success of the project. We all need to be open and collaborate to achieve success.   Kupe Kupersmith | President, B2T Training Kupe shares a story about how he almost lost his job because he didn’t consider the human side. What Kupe learned: Don’t forget the human side of things. Your solutions may be perfectly logical, but if we forget the human side, we’ll meet resistance. Many of us get tripped up when we don’t successfully navigate political waters and take personalities into account. Be aware of the human side of change.   There are some common themes in what these industry leaders have learned. Act with openness, transparency, and collaboration Check your ego at the door Understand that the human side of change is just as important as the technology. I hope you’ve learned something from this episode so you don’t make the same mistakes. Listen to the full episode to hear the biggest mistakes made by these eight thought leaders (as well as my own biggest mistake). http://traffic.libsyn.com/masteringbusinessanalysis/MBA100.mp3 Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable conte

In this episode, David Bland shares an exercise from LeanUX for gaining clarity in times of uncertainty and developing a deep understanding of customer needs.    After listening to this episode, you'll understand: Why the commonly used Build-Measure-Learn loop is backwards How to find the right thing to build in order to learn Why the three lenses of feasibility, viability, and desirability are critical How to run an assumptions mapping exercise to gain a deeper understanding and focus on the right thing  Show Notes Assumptions Mapping is a LeanUX exercise that leads to valuable conversations within your team and enables them to focus on what really matters. It allows you to gain clarity and find the right path forward, even in times of uncertainty. Through Assumptions Mapping, teams will develop a deep understanding of customer needs and the risks associated with finding a solution to address those needs.   The Build, Measure, Learn Loop is Backwards It’s easy to start with building something, which is why most teams start there. The problem is that sometimes we build just to build. It’s something we do to meet a deadline and you’re held accountable to meet dates. Building something and expecting to learn afterwards is often just a dream. Instead, start with Learn and work your way backwards. What do you need to learn about the market, the customer, or the problem? After you understand what you need to learn, figure out how you would measure to learn. Finally, determine what (if anything) you need to build to measure and learn. Starting with Learn is much more impactful for the team and helps focus them on building the right thing.   Prioritizing Experiments Many teams get excited about experimenting and Assumptions Mapping helps teams to prioritize and run the right experiments. Assumptions Mapping looks at the problem through three lenses; desirability, viability, and feasibility.   The Desirable lens focuses on the customer to understand if the solution is wanted by the customer. Use the Viable lens to focus internally to understand if this is something we should do from a cost structure, business model, and strategy standpoint. The feasibility lens looks at whether or not we can do it (set up as a team to build it, have the hardware and infrastructure, etc.). All three lenses are critical to understanding what to solution build.   Is it Desirable? To identify assumptions around desirability, you can ask a number of questions to generate a discussion around the assumptions we’re making about the customer’s wants. With an assumptions mapping exercise, those assumptions are written on sticky notes and later plotted on a four-quadrant map. Example questions include: Who is the target customer? What problem are they trying to solve? How do they solve the problem today? If the customer can’t solve it, why can’t they solve it? What is the outcome the customer wants to achieve?   Is it Viable? To understand the assumptions we’re making about viability, we follow a similar process around questions related to how the solution related to our business strategy. Example questions to identify viability assumptions include: What’s our acquisition channel? How will customers come back to use our solution again? How will customers refer us to other customers? Do we understand our competitors? How do we generate our revenue?   Is it Feasible? Feasibility assumptions relate to whether or not we are set up to create this solution. This includes technical feasibility, ongoing support, expertise needed, resources, etc. Example questions to identify feasibility assumptions include: What are the biggest technical and engineering issues? What are the legal and regulatory risks? Are there internal policy or governance hurdles you need to overcome? Do you have leadership support? Where does your funding come from? Why is your team uniquely positioned to do this and do it well?   Mapping the Assumptions Once you’ve identified the assumptions in each area (tip: use different color sticky notes for each and another color for those you come up with on your own), map your assumptions. Plot the sticky notes on a two-by-two matrix of important vs. unimportant and known vs. unknown. When plotting assumptions on this map, the distance along each important/known line is relative to the next. This exercise not only creates a map helping the team to understand what items are the most unknown and important, it also generates a great conversation and creates a shared understanding. For identifying experiments, focus first on the top left quadrant; the unknown and important items.   Run an Experiment There are many different kinds of experiments. When you identify an assumption you want to run an experiment against, work to make it more testable by getting very specific. From there, design an experiment that will allow you to test your assumption. Depending on the type of assumption,

In this episode, David Mantica talks to us about influence and discusses how professionals can successfully navigate any organization to move projects to execution. He also shares several approaches and techniques to improve your ability to influence.  After listening to this episode, you'll understand: Why influence is a key skill for any project professional How to build trust within your organization Why knowing yourself and emotional intelligence are vital to your ability to influence  Show Notes The ability to influence is both an art and a science. The art side of influence lies in the need to know when to adjust or pivot in your approach. The science ties into emotional intelligence (EQ) because you need to understand yourself first and the biases that can affect influence. Influence is built upon other skills such as the ability to deal with conflict, facilitation, and change management. Without the foundation of EQ and other skills, your ability to influence will be severely limited.   Influence vs. Manipulation The difference between influence and manipulation is in the underlying reason for making a change. Where influence crosses over t manipulation is when you try to influence people to do things for your own self-interest. From a power base standpoint, influencers come from a referent power base. It requires you to have the effort, energy, and charisma to take people from one point to the next step in where you want them to go. Trust is what separates the influencers from manipulators. Building trust that what you’re doing is for the good of the organization and its customers will allow you to be more successful in driving positive change. Being able to properly articulate why you want to make a change is key to building trust and gaining support.   The Science of Influence When you are trying to influence without authority, you need to start with emotional intelligence. This leads to self-awareness, which allows you to self-manage (awareness of your hot buttons and the ability to control yourself). From self-awareness, you can develop situational awareness. This helps you to understand what’s happening in your environment and how you should respond and manage those situations. Understanding biases is part of situational awareness because it allows us to better understand the behaviors of others. One common bias is the endowment effect. This is the belief that what you own (including ideas and beliefs) are more valuable than those of others. Social proof is another common cognitive bias in which our perception is colored by popularity (or lack thereof). Understanding cognitive biases allow you to look at the behavior of other people through that lens and approach the situation differently.   The Art of Influence The art of influence starts with understanding what it means to be likable. It’s much easier to influence someone if they know, like, and trust you. Likability starts with eye contact, a smile, and asking questions to get to know the other person. It’s about making them feel comfortable and connecting on a human level. Active listening also contributes to likability and developing trust. From there, focus on your execution and delivery. Showing that you can drive a process forward and create transparency builds a foundation to influence better. Coming to the table with potential solutions instead of just problems will help build trust and influence. It shows that you’ve looked at all sides of a problem and have considered actions to take.   Listen to the full episode to hear more tips on improving your influencing skills. http://traffic.libsyn.com/masteringbusinessanalysis/MBA098.mp3   Z Your Homework Know yourself: Reflect to better understand your strengths and weaknesses and your hot buttons to develop better self-awareness. Accept Others: Work on getting comfortable with who people are and their strengths/weaknesses. Be open to new ideas and opinions. Offer solutions: Think through problems and offer solutions without the need for your solution to be accepted. These three actions will help you become a trusted advisor and influence positive change. Links mentioned in this episode: ASPE Training Wall Street Journal article on Likability David’s previous episode: The T-Shaped BA David Mantica President, ASPE-SDLC David Mantica has more than 20 years of experience in B2B continuing education. He has participated in and supported the work of numerous certifying bodies including the Scrum Alliance, PMI, IIBA, TrueSecure, and CompTIA. David also is a regular speaker at IIBA and PMI chapters. 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 and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week . The post MBA098:

In this episode, author and consultant Cheryl Lee helps us to improve the collaboration and partnership between Business Analysts and Project Managers.  After listening to this episode, you'll understand: Why there’s often tension between the Business Analyst and Project Manager What steps you can take to build a better PM/BA partnership How to become an advocate for Business Analysis Why understanding the value of each perspective is important, even for those with combined roles and in Agile environments  Show Notes There’s often tension between the Business Analyst and the Project Manager. The Project Manager wants everything delivered on time and on budget while the Business Analyst wants to ensure the project scope is covered with appropriate quality. This tension can lead to missed opportunities to collaborate and form a strong partnership between the PM and BA which would benefit the project and the organization. With Project Managers more focused on the project and Business Analysts more focused on the product, how can we find a common ground to form a powerful partnership?   Building Better Partnerships The first thing we need to do to build a better partnership between the Business Analyst and Project Manager is to understand the value that each role contributes to the project. To take it a step beyond the role, work to see the value in project management and business analysis. Even in Agile where the titles of Business Analyst and Project Manager might not exist, thinking about the skills, activities, and perspective of each of the roles will be important. Looking at the value of the outcomes produced by both perspectives helps those with a combined PM/BA role and those without a PM or BA title to understand the importance of each area. Once you understand the value of each perspective, identify the integration points; those areas that are shared between business analysis and project management. Areas such as risk management and stakeholder management are common areas shared by both perspectives.   Advocating the BA Role As the Project Manager role is more standardized and often better understood, the issue of not understanding the value is usually in the area of business analysis. Misunderstandings such as this can lead to undervaluing the Business Analyst. Misunderstandings about the BA role are no one’s fault; it’s simply a fact. Business Analysis hasn’t been around quite as long as project management and many people are not clear on how the BA adds value. To address this, Business analysts need to become advocated for the role. One way to become an advocate for the BA role is to start a community of practice to share knowledge and elevate skills. These sessions may draw in non-BAs to learn more as well, helping to create transparency as to what a BA does and change perceptions.   Don’t Short Change Your Role Business Analysts are often asked why it takes so long to get requirements. We’re sometimes pressured to reduce the amount of time it takes to elicit and document the requirements. Giving in to this pressure by arbitrarily reducing the amount of time you truly need to elicit quality requirements can lead to missed or poor requirements and have negative impacts to the project. One way to address this is to discuss lessons learned on similar projects in which timelines were reduced and requirements quality suffered. Another approach is to write down all of the analysis activities that it will take to deliver the requirements for your project with sufficient quality and meeting the needs of stakeholders. Make sure to consider not only the activity itself (such as a requirements workshop), but also any preparation activities and trailing activities needed. Use the list to get a bottom-up estimation of the time needed and discuss the activities with the Project Manager and the team. This will lead to a better understanding of what you do, why those activities are needed, and why you need the time to do things properly. Listing activities needed by both the BA and the PM can also help to identify integration points and areas in which the BA and PM should work together.   Listen to the full episode to hear more of Cheryl’s advice on improving the BA/PM partnership. http://traffic.libsyn.com/masteringbusinessanalysis/MBA097.mp3   Z Your Homework Make time for business analysis. Create a to-do list for analysis activities needed to achieve the desired outcomes and share it with the Project Manager. Having a conversation about the needed analysis activities and their value leads to greater transparency and can help identify opportunities to partner on some activities.   Links mentioned in this episode: Cheryl’s book, Effective PM and BA Role Collaboration Previous episode with Cheryl’s co-author, Ori Schibi Cheryl Lee Cheryl Lee is a certified Professional in Business Analysis (PMI-PBA), Project Management Professional (PMP)

In this episode, David Bieg, PMI’s Business Analysis & Requirements Program Manager, tells us about PMI’s latest initiative; the development of a foundational standard in Business Analysis. PMI’s goal with this new standard is to provide a definitive body of knowledge for people performing business analysis on projects, programs, and portfolios.  After listening to this episode, you'll understand: Why the Project Management Institute is focused on Business Analysis How the Standard for Business Analysis differs from the Practitioner’s Guide How to apply the information in the Standard for Business Analysis to your work  Show Notes The Project Management Institute (PMI) has developed a foundational standard in Business Analysis. With this new standard, PMI hopes to provide a definitive body of knowledge for people performing business analysis on projects, programs, and portfolios.   The Standard vs. the Practice Guide The Standard for Business Analysis differs from the Business Analysis Practice Guide in that the foundational standard defines the “what is” of business analysis and its alignment to project, program, and portfolio management. It defines business analysis through identification of the process, tasks, inputs, and outputs of analysis activities. The Business Analysis Practice Guide briefly describes the “how to” and puts business analysis in the proper context. It primarily focuses on being a usable reference on how to perform business analysis on projects and programs. The Business Analysis Practice Guide will complement the Standard for Business Analysis by allowing practitioners to better understand how and when to use a technique or execute a specific process.   Drivers Behind the Development of the Standard The first driver behind the creation of the Standard for Business Analysis was the success of the Business Analysis Practitioner’s Guide. The overwhelmingly positive response from the community led to further development of business analysis initiatives. The BA Practice Guide validated the appetite for business analysis related guides and standards. The second driver was that PMI’s business analysis community expressed an interest in the development of a standard to support the PMI-PBA certification.   Focusing on Business Analysis While PMI has been addressing requirements since the beginning of the institute, there has been more emphasis on requirements and analysis activities in the last few years due to market research showing a growing need for quality requirements and the positive outcomes that can result from business analysis. Additionally, poor requirements and related factors have been a leading cause of project failures. As such, business analysis is a critical competency for project, program, and portfolio management. By focusing on business analysis, the PMI hopes to increase project success rates through increasing the skills of those performing business analysis activities.   What to Expect from the Standard for Business Analysis The Standard for Business Analysis is for anyone who performs business analysis activities, regardless of their job title or a specific lifecycle (waterfall, Agile, Lean, etc.). The profession will be defined by six knowledge areas and 35 processes. It will also include tailoring tables to explain how perform each process an adaptive and predictive setting so that you can adjust your approach based on the lifecycle approach. Knowledge areas go from the initial needs assessment through the solution and solution evaluation process. The Standard for Business Analysis will also establish a common language for project, program, and portfolio professionals (including Business Analysts).   Next Steps for the Standard The Standard for Business Analysis is going into the subject matter expert review phase in the fourth quarter of 2016 to get feedback from industry experts. It will then go through the public exposure draft review process in the first and second quarter, 2017. The public exposure review will provide the opportunity to for you to give feedback and comments to the development team for further consideration. The document will go through an adjudication process and rounds of edits at each phase before final publication in the fourth quarter of 2017. Listen to the full episode to hear more about PMI’s Standard for Business Analysis. http://traffic.libsyn.com/masteringbusinessanalysis/MBA096.mp3   Z Your Homework Get a copy of the Business Analysis Practice Guide, find a new technique, and use that new technique in your work. The more you learn about and apply new techniques, the more tools you’ll have in support of your analysis activities.   Links mentioned in this episode: The Project Management Institute PMI’s Business Analysis Practice Guide David Bieg Bieg & Associates, Inc. Dave Bieg has over 30 years of experience in business and inform

In this episode, Jason Little helps us to understand how to use Lean Change Management to create change that sticks.  After listening to this episode, you'll understand: Why most change efforts fail The elements of Lean Change Management that lead to successful organizational change How to use experiments and adapt your change approach Why canvases are a powerful tool in creating change  Show Notes Lean Change Management was developed by Jason in an effort to help organizations get unstuck. It’s a mixture of ideas from lean startup, change management, and agile that all build on each other. The major difference between Lean Change Management and other change approaches is in the stance that’s taken. Many change approaches are linear whereas Lean Change Management is an iterative, contextualized approach. The problem with linear change approaches is that people don’t progress through the stages at the same rates or intensities. People’s reaction to change is unpredictable and rigid, linear change models often fail as a result.   Jiggle the System As a change agent, you look for windows of opportunity to “jiggle” the system to get it unstuck. Part of the Lean Change Management approach is to become aware enough to identify those opportunities. One way to jiggle the system is to look at small pieces of the change and plot them against people’s motivation and ability to do it. If people aren’t motivated to make a change or aren’t able to make a change, it’s unlikely that the change effort will be successful. Determine how you can make the change easier for people. When designing experiments, always consider that there’s motivation, ability, system blockers, and other things going on that will lead to difficulties in making the change.   Experiment Your Way to Change Start with insights about the change. Insights can come from anywhere; watercooler conversations, change readiness surveys, observations, and more. Based on those insights, come up with options to get the organization closer to the future state. Of those options, plot them against cost and value to identify higher value, lower cost options to start. Create experiments based on the selected options. Remember that an experiment is a hypothesis and should identify the expected outcome and ways to measure the result. Experiments are really learning opportunities that allow you to adapt your approach. Wit experiments, you’ll need to prepare for them, run the experiment, and review the results. Those results may lead to additional insights and the cycle continues. While the process seems linear, the process is constant – even multiple times per day if needed. Lean Change often succeeds because to the co-creation aspect. The people that have to live with the consequence of the change have a hand in creating the change approach. Listen to the full episode for all of Jason’s advice on using canvases and making change stick. http://traffic.libsyn.com/masteringbusinessanalysis/MBA095.mp3   Z Your Homework Don’t get overwhelmed with a change initiative. Find ways to help people in the organization connect to other people who are having success with a change through small wins, sharing stories, and community building. Look at how social change happens and try to apply those same techniques in your organization by connecting people and having them share stories.   Links mentioned in this episode: Jason’s website LeanChange.org   Jason Little Jason Little is the author of Lean Change Management and an international speaker who has spoken all over the world from Canada, the US, Finland, Germany, Australia, Belgium and more. Jason has been helping organizations implement Agile practices since 2007 as a Scrum Master, Product Owner, Internal and External Coach. 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 MBA095: Lean Change Management appeared first on Mastering Business Analysis.

In this episode, Peter Leftrov helps us to understand the five Perspectives in the BABOK and how they can help you choose which tools, techniques, and tasks you should use given the specific context of your project.  After listening to this episode, you'll understand: Why the five perspectives were selected for version 3 of the BABOK® Guide How the five perspectives help you understand the context of your specific project How understanding the perspective will help you identify the tasks and techniques needed for your project  Show Notes One of the new additions to version 3 of The Business Analysis Body of Knowledge® (BABOK® Guide) is the section on perspectives. These perspectives help us to focus on the techniques and tasks applicable to the context of a specific initiative. Perspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of the initiative. Many initiatives will involve one or more perspectives. The five Perspectives in the BABOK® Guide are: The Agile Perspective The Business Intelligence Perspective The Information Technology Perspective The Business Architecture Perspective The Business Process Management Perspective   Understanding the context of your project or initiative and which perspectives apply will help you narrow down the tasks and techniques to use, which allows you to focus more on better business outcomes. Listen to the full episode to hear all of Peter’s tips and advice about Business Analysis perspectives. http://traffic.libsyn.com/masteringbusinessanalysis/MBA094.mp3 .   Z Your Homework Don’t worry so much about templates and techniques. Instead, focus on your tasks and the value of what you’re doing. With your analysis work, you’re guiding the organization in a positive direction when you focus on value.   Links mentioned in this episode: Peter’s Website BAConsulting.eu Peter Leftrov CBAP, Senior Business Analyst Peter Leftrov, CBAP is a Business Analyst with extensive international expertise in stakeholder management, business process management and data integration, business intelligence and business process management. He’s also the co-founder of IIBA’s Bulgaria and Austria chapters. LinkedIn IIBA®, BABOK® Guide, and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis.     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 MBA094: Perspectives in Business Analysis appeared first on Mastering Business Analysis.

In this episode, Paula Bell talks to us about risk, and urges us to look beyond typical in-project risks such as time, scope, and budget and adopt a systems thinking approach to risk by identifying organizational risks that may come up as a result of your project.  After listening to this episode, you'll understand: Why it’s important to look beyond in-project risks How your project solution can lead to increased risk across the organization How to address different types of risk Who you need to involve to help address organizational risk  Show Notes Managing risk is everyone’s responsibility. Often we have a narrow focus of risk, thinking only about risk to our project and the scope, time, and budget. We need to see the bigger picture and take a systems thinking approach to risk by considering the organizational risk that our solution may create. If you don’t take organizational risk into consideration, you can create solutions that could potentially put your organization in a bad situation from a litigation, financial, and reputation standpoint.   Types of Risk There are many different types of risk you should consider when thinking about potential solutions to addressing stakeholder needs. Some common types of risk are: Operational Risk: This is risk associated with the process and can include breakdowns in internal procedures as well as interactions between people and systems. Consider the impacts your project may have on the processes and procedures that govern operations. Financial Risk: This is an umbrella risk covering many related risks such as financing, financial transactions, and loans that put the company at risk of default. Credit risk is the risk that a consumer might default on a debt and may also be considered here. Financial risks may result is a disruption of cash flow or increased costs. Compliance Risk: This is the risk of legal sanctions. Failing to comply with regulations may result in financial losses and can have a great impact across your organization. Reputational Risk: This is essentially the risk of damage to your brand. Consider how your project’s solution and its upstream and downstream impacts will be perceived by customers and those outside your organization. An increase in other types of risk (operational, financial, compliance, etc.) can increase reputational risk.   Getting Started If you’re new to risk management, start with a few of the most common types of risk and go deep. Think about the impacts your project and other organizational changes will have from a risk standpoint. Bring in experts from Legal, Compliance, Information Security, and other areas to provide input as to the risk associated with the change. It’s beneficial to bring in representatives from Legal, Compliance, and Risk at the beginning of a project to understand potential impacts and involve them throughout the project; especially at the solution development phase. Help representatives to better understand potential risk by providing an overview of the project at the beginning. This helps them to include the appropriate subject matter experts in the project.   What to Do About Risks Once a risk is discovered, take action to address the risk. You can work to mitigate, avoid, or transfer the risk, or even accept the risk if the likelihood and impact is small enough. Your partners in Legal, Compliance, and Risk can help you establish appropriate controls to address the risk. This may include new procedures, exception reporting, or changes to requirements. If you choose to accept a risk, document it and why you accepted the risk as well as the names of those who approved the acceptance of the risk.   Think outside the iron triangle of scope, time, and budget to identify and address risks resulting from your change effort. Listen to the full episode to hear all of Paula’s advice on having a holistic approach to risk. http://traffic.libsyn.com/masteringbusinessanalysis/MBA093.mp3   Z Your Homework 1) Look beyond the surface and go deeper. As you are working on your project, ask why. Ask “At this step, what could go wrong?” and if there is a risk, determine how you will address the risk. 2) Identify who your stakeholders are in your Compliance area, your Legal area, and your Risk area. If your organization doesn’t have teams for these areas, find out who has knowledge in those areas so that you can involve them and not put your organization at risk.   Links mentioned in this episode: Paula’s website paulaabell.com Paula’s episode on Systems Thinking Paula’s episode on Collaboration Paula Bell Paula A. Bell Consulting, LLC Paula Bell is a Business Analyst, consultant, mentor, author, and speaker known for providing guidance to aspiring business analysts. She’s held just about every role in a RACI matrix including business analyst, technical writer, project manager, developer, test lead, and product owner. Paula is a frequent speaker a

In this episode, Roxanne Miller shares her approach to discovering non-functional requirements, which will help reduce the risk of missing requirements.  After listening to this episode, you'll understand: The six activities you can use to reduce the risk of missing non-functional requirements Why missing non-functional requirements can cost an organization millions How to start building a requirements repository to accelerate requirements discovery  Show Notes The consequences of missing non-functional requirements can include the inability for users to access a system, allowing the wrong people to access confidential information, and can cost organizations millions of dollars. Non-functional requirements (NFRs) describe the attributes of the system such as scalability, maintainability, usability, and security. It’s a type of requirement that specifies the operation of a system rather than functionality. To ensure that you discover all of the needed non-functional requirements, Roxanne recommends six activities to reduce the risk of missed non-functional requirements.   Use a defined classification A classification will help stakeholders and the development teams build a consistent language for discussing non-functional needs. Using a classification for your requirements types helps you identify high level types of non-functional requirements that may apply to your project. The classifications you and your organization uses will depend of the type of products and services you offer. Example categories include: Security: How well the system is protected against attempts to access information from internal and external sources. Availability: How dependable the system is (e.g., up time). Reliability: How well the software can consistently perform its function without failure. Survivability: How well the system continues to function and recovers after a system failure. Usability: How easily a user is able to learn and operate the system.   Use a pre-defined list of elicitation questions Having a list of pre-defined elicitation questions can increase the productivity of the team. It also helps reduce the time it takes to discover the system requirements and avoid missing requirements. You can tie your list of elicitation questions to one of the categories mentioned above for further clarity and organization.   Use a structure to ask good questions Roxanne created the Requirements Framework, which is based on the Zachman Framework developed by John Zachman. It’s tailored for use in eliciting requirements from the perspective of two key roles: requirement suppliers and requirement receivers. For each of the two roles, ask questions based on what, who, why, when, where, and how. This helps you to identify: What data or materials are needed? Who needs the data? Why is the data needed? When will the data be used? Where will the data and materials be used? How will the data be used?   Engage the right stakeholders Using a stakeholder profiling technique can help you identify not only who should be involved in requirements elicitation, but also when they should be engaged and expectations from that stakeholder.   Use Invented Wheels Don’t reinvent the wheel. Leverage elicitation questions and non-functional requirements from previous projects so you don’t need to start from scratch. Reuse and modify non-functional requirements for previous projects or other systems to fit your project and your needs. Use State-of-the-Art Tools When possible, use an automated tool to identify software requirements to work faster and more efficiently. There are several software tools available that maintain a repository of questions and sample requirements you can use on your project. They often will help you identify where you may have missing requirements.   Listen to the full episode to understand the consequences of missed non-functional requirements and how to develop a repository of elicitation questions and NFR examples. http://traffic.libsyn.com/masteringbusinessanalysis/MBA092.mp3   Z Your Homework Find other Business Analysts or requirements producers and start comparing notes on eliciting requirements. You can then compile and share your predefined list of questions as well as examples of non-functional requirements. This will allow you to start building a repository of non-functional requirements and elicitation questions to accelerate requirements discovery.   Links mentioned in this episode: Requirements Quest Website Roxanne’s on-demand training Roxanne’s book, The Quest for Software Requirements Roxanne’s Previous Interview (Episode 2) Roxanne Miller President, Requirements Quest Roxanne Miller is a self-proclaimed Requirements Super Freak and author of he book, The Quest for Software Requirements. She has been involved in the Information Technology industry since 1984 and founded Requirements Quest® in 2001. She has been consulting on r

In this episode, Elizabeth Larson helps us along the path going from order taker to trusted advisor and helps us to avoid some of the common pitfalls.  After listening to this episode, you'll understand: Why new Business Analysts are often seen as order takers How to build trust within your organization The three components of the Influencing Formula The right questions to ask to be seen as a trusted advisor Common pitfalls to avoid on your way to becoming a trusted advisor  Show Notes We don’t want to be seen as order takers. We want to be seen and sought out as trusted advisors. For beginning Business Analysts, it’s common to be viewed as an order taker. Without the skills and experience it’s difficult to do otherwise. We need to quickly build our capabilities and realize that our role is to help the organization and provide recommendations. Your role is not necessarily to make decisions but to advise the customer so that they can make the right decisions. Trusted advisors define the business need and recommend solutions that provide value to the organization. Order takers have a difficult time with this because they are often given a solution to implement, which they accept and implement. When given a solution, a trusted advisor will stop and ensure that we’ve defined the business problem we’re trying to solve or business opportunity we’re trying to seize. They can then explore the current state and determine if the proposed solution is the best option.   The Influencing Formula To go from order taker to trusted advisor, we need to build trust. We can start by building credibility, doing our homework, and truly understanding the current state in the organization and business environment. You can also build trust by meeting your customers and end users where they work and actually performing some of the tasks that they do. This gives you a better understanding of how they use the current systems and what their pain points are. The most difficult part of going from order taker to trusted advisor is having the courage to speak up. And recommend the right thing to the organization. People may not like hearing what you have to say and we need to have the courage to state our case anyway. Another key to becoming a trusted advisor is influence. You need to be able to advise your organization and influence them to make the right decisions. Trust, courage, and influence are all interrelated.   Questioning Like an Advisor Order takers usually ask questions related to the features and functionality of the solution. While those types of questions are important, we need to understand the big picture first. Ask ‘why’ in a way that builds trust. When provided with a solution to implement, ask questions to get a better understanding of the underlying problem or opportunity that the solution will address. Also ask questions to understand how your project fits into the overall business objectives. Asking the right questions helps you to identify the business need and pain points associated with the current process. All of this allows you to advise the organization on the right solution.   Pitfalls Along the Path Along your journey from order taker to trusted advisors, there are some pitfall you need to avoid. Don’t mistake your role as advisor for a decision maker. Your role is to advise and influence, but it’s up to stakeholders and sponsors to make the final decision. Don’t be offended or take it personally if people don’t accept or follow our advice. Figure out a good time to reflect on why they didn’t go with your recommendation and determine if you should change your recommendation, try again, or drop it.   Listen to the full episode for more of Elizabeth’s advice on the right questions to ask and pitfalls to avoid on your way to becoming a trusted advisor. http://traffic.libsyn.com/masteringbusinessanalysis/MBA091.mp3   Z Your Homework When you’re provided with a solution to implement, practice asking the right kind of questions to better understand the intent of the solution and the current environment. Take the time to gather the facts and statistics about the current state so that you’ll be better prepared for conversations and make appropriate recommendations. Finally, don’t ask leading questions. Leading questions limit conversations and present a solution. Eliminate the phrase ‘have you thought about’. That phrase breaks trust.   Links mentioned in this episode: Watermark Learning Elizabeth’s books and publications Elizabeth Larson CEO of Watermark Learning Elizabeth is the CEO of Watermark Learning and has over 30 years of experience in business analysis, project management, and influencing skills. Elizabeth’s speaking history includes keynotes and presentations on five continents. Elizabeth has co-authored four books, including the acclaimed CBAP Certification Study Guide and has been cited in CIO Magazine and PM Network, PMI’s monthly publicatio

In this episode, Richard Larson helps us explore version 3 of the BABOK® Guide to understand how it can help you and your career.  After listening to this episode, you'll understand: What changes have been made to version 3 of the BABOK® Guide How to use the BABOK® Guide depending on where you are in your career How to get the most out of the BABOK®  Show Notes The Business Analysis Body of Knowledge® (BABOK® Guide) represents the evolution of the Business Analyst profession. It creates better awareness in the industry and aligns the language and practice of business analysis. The BABOK® Guide has gone through several iterations over the years. The latest version, v3.0, is a huge leap forward. Version 3.0 is almost double the size of the previous version. It includes new guidelines added roughly 16 new for a total of 50 techniques. Version 3.0 also adds five different perspectives that give a focus on different specialties within business analysis. The BA Core Concept Model is also new to version 3.0 of the BABOK® Guide. An important component of the Core Concept Model is value. It reminds us of why we do our work . . . to add value to the organization. This acts as a beacon so we can ask ourselves “Is what I’m doing now (or is this deliverable) adding value?”   Using the BABOK® Guide You can (and should) use the BABOK® Guide differently depending on where you are in your career. For practitioners new to business analysis, start by exploring the business analysis techniques. That will allow you to get perspective on what techniques you can use in different situations. From there, you can begin using some of the techniques and get some practice. Later in your career, it can help you not only in understanding some key concepts, but also if you’re looking to earn a certification, the information is essential. If you’re managing business analysts, you can use the generally accepted practices in the BABOK® Guide to mature your team. Regardless of where you are in your career, the introductory chapters of the BABOK® Guide can really help you focus on some essential ideas. The introductory chapters include key concepts and the Core Concept Model. From there, you can pick and choose the sections to explore. Read about tasks or technique as they come up in your work.   Listen to the full episode to hear all of Richard’s tips and advice about using the BABOK® Guide and certifications. http://traffic.libsyn.com/masteringbusinessanalysis/MBA090.mp3   Z Your Homework Get a copy of the BABOK® Guide and read it, focusing on value. Doing so will help you understand the value you provide in your role and shifts you toward becoming a value manager.   Links mentioned in this episode: Rich’s Website Watermark Learning Watermark Learning’s Resources IIBA’s Website for the BABOK Richard Larson Founder and President of Watermark Learning Richard Larson is Co-Principal, Founder, and President of Watermark Learning. He has over 30 years of experience in business, project management, business analysis, training,and mentoring. He has presented numerous workshops, seminars, and training classes since 1985 to over 10,000 participants on five continents. TwitterLinkedIn IIBA®, BABOK® Guide, and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis.     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 MBA090: BABOK 3.0 with Richard Larson appeared first on Mastering Business Analysis.

In this episode, we’ll take a look at the 12 principles of the Agile Manifesto and see what they mean in the context of Business Analysis.  After listening to this episode, you'll understand: How to apply each of the 12 principles of the Agile Manifesto to Business Analysis The mindset shift we need to make to be successful in agile environments What you can do to adopt agile practices, even in waterfall environments  Show Notes The principles behind the Agile Manifesto help align mindsets and behaviors to help people shift their thinking. Below are some thoughts on how these principles may be applied in Business Analysis. I encourage you to review the values and principles of the Agile Manifesto for yourself and consider how they can be applied in your context.   Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. BAs need to focus on customer priorities and their satisfaction. We can help the team to achieve fast and continuous delivery of software by breaking large requirements down into smaller, valuable chunks that can be delivered in small increments. If you’re working in a waterfall environment, perhaps you can break your project into small phases to deliver valuable pieces sooner. If you consider the time value of money, getting working software into the hands of your customer quickly allows them to start seeing some results while waiting for additional functionality and potentially start seeing income sooner. Prioritization also comes into play here. We need to understand what capabilities are most valuable to our customers and prioritize the highest value items first, or at least work to understand how to properly prioritize based on things like value, time criticality, risk, cost or effort required, and other factors.   Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. As Business Analysts, we need to be transparent about our work products and be open to feedback. Frequent, short feedback loops (ideally based on working software, prototypes, or some other representation of the product) help us to get the critical input from customers that we need to adjust and ensure we deliver exactly what the customer needs and expects. Get as close to the customer as you can and give them a way to interact with what you’re building. Use observation, interviews, and other techniques to get feedback and adjust your plans accordingly.   Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequent delivery of working software helps with the rapid feedback loops I just mentioned and potentially allows your customers or your organization to begin realizing benefits sooner. Business Analysts can enable frequent software delivery by breaking requirements into small, valuable chunks as mentioned earlier. We can also use strong communication skills, lightweight prototypes, and visual modeling approaches to quickly create a shared understanding.   Business people and developers must work together daily throughout the project. Here’s where our communication and facilitation skills really come in to play. Often, business people and software developers have difficulty communicating. Use your skills to bring these two groups together and facilitate a conversation, creating a shared understanding. Foster and promote a collaborative environment in which business people and developers can co-create a valuable solution.   Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. This is similar to the last principle in that we need to create a collaborative, open environment. In addition, whenever possible, we need to find motivated people with the right skills for the project team. Through stakeholder analysis and sharing a compelling vision of the project, you can help motivate the right people and influence others to support you. You’ll also need to understand any roadblocks that the team is facing and work with others to remove the impediment.   The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Most Business Analysts should know and practice this one already. Always use the highest bandwidth form of communication available. Email is great for moving files and calendar appointments, but it’s terrible for communicating. You lose all tone and nuances associated with other forms of communication. Not to mention that some people don’t check their email very often. Instant messaging is a little better, but you still lose 50-80% of communication through that channel. Using the telephone at least allows you to convey information through verbal cues such as tone, volume, and pace. Video allows you to use non-verbal cues an

In this episode, Lora McCoy shows us how to run an effective and engaging requirements workshop; a great way to elicit a majority of the requirements for your project all at once.  After listening to this episode, you'll understand: How to keep workshop attendees engaged and focused on the business needs The 5 parts of a requirements workshop What you need to do before, during, and after your workshop to make it successful  Show Notes Requirements elicitation workshops are a great way to discover requirements. They’re a key tool you can use to quickly elicit a majority of the requirements on your project. Unfortunately, many workshops don’t get the anticipated value. A well run requirements workshop is engaging, valuable, and maybe even fun. To run such a workshop, you’ll need to do a few key things before, during, and after the workshop. Effective requirements workshops are made up of five phases: Planning Opening Execution Closing Follow up   Planning The planning phase is where most of the work takes place and is critical for a successful workshop. During planning, you’ll manage not only the meeting logistics such as date and location, you’ll also need to make sure the right people are invited. Start by defining the purpose of the meeting. Understanding the scope and having a clear purpose will allow you to perform a stakeholder analysis to determine who should attend the workshop. You should also determine the vision and agenda. Given the purpose you identify, what is your vision for the workshop? The vision will lead to agenda items to drive the workshop toward the goal. You’ll want to include the purpose, vision, and expectations in the meeting invitation so people can prepare to work towards that vision.   Opening At the start of the requirements workshop, clearly articulate the purpose, vision, and agenda. Of course, you’ll also want to have people introduce themselves, which can be done in a boring or fun way. The opening sets the tone for the workshop and helps start the requirements workshop off right.   Execution During the execution phase, you will facilitate the workshop and keep attendees focused on the purpose and vision. You may want to have both a facilitator and scribe as doing both can be difficult. Having stakeholders in the room while eliciting and documenting requirements in real time allows for rapid feedback loops so you can make adjustments and ensure correct requirements. While executing the workshop, include a lot of activities to keep people moving around and engaged. Making use of visuals also helps with gaining clarity among all stakeholders. Think about what type of visuals might be appropriate for the situation. In most cases, you don’t need to create visuals beforehand. It’s powerful to create visuals with others in the workshop. Visuals may include mind maps, process flows, or other diagrams that create a shared understanding and allow you to discover requirements along the way. You may be able to get attendees to come to the whiteboard and create these visuals with you. Before long, you may have a room full of highly engaged stakeholders at the board all solving the problem together.   Closing The closing phase is at the end of the workshop and allows you to discuss what was accomplished, what remains to be done, and what the next steps are. You’ll want to thank everyone for attending and clearly share what will happen next.   Follow Up The follow up portion of the workshop may occur a day or two afterwards and includes tasks such as distributing action items, notes, or pictures or scheduling additional meetings.   Listen to the full episode to hear how to get the most out of requirements elicitation workshops – even in Agile environments. http://traffic.libsyn.com/masteringbusinessanalysis/MBA088.mp3 Z Your Homework Go to the Board In your next workshop or meeting, get up out of your seat and use the whiteboard or flip charts. Not only does this create a shared understanding, it also keeps attendees engaged. They can even pick up a marker and co-create the solution.   Links mentioned in this episode: Connect with Lora via email Lora McCoy Founder and Principal Consultant at LMc3 Consulting Lora McCoy is a Certified Business Analysis Professional with over 18 years of experience performing Business Analysis skill set activities as well as Quality Assurance, Project Management, and more. She is dedicated to both the profession and those who perform the skill set for the profession. She currently serves as the President for the Oklahoma City Chapter of the IIBA where she applies that passion to the local membership in the form of mentorship and knowledge sharing. You can contact Lora at [email protected] FacebookTwitterLinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you c

In this episode, Kupe Kupersmith warns us that we may be replaced by robots, or if not by robots, how technology makes it possible to outsource your role and what you can do about it.  After listening to this episode, you'll understand: How technology is changing the way we work Why some tasks or even your entire role can be automated or outsourced How technology can expand your career opportunities How to become a more valuable member of your organization  Show Notes Can a Business Analyst be replaced by a robot? Machines are now able to solve problems and interact with humans. Technology may get to the point where computers can take what a stakeholder says, scan through an incredible amount of data, and come up with a solution far faster than humans. Until then, we need to have the ability to be that resource and have the knowledge to solve problems. There are tasks we do today that machines can do. IBM’s Watson was able to interact with people to the point that the users didn’t know they were interacting with a machine. Watson was able to assist and answer questions from graduate students. Robots are now able to read emotions and learn the way individuals react emotionally. Kiosks in banks and restaurants are quickly replacing people.   It’s Not Just Robots Other advances in technology make it possible to communicate effectively even if you’re not co-located. This allows organizations to hire the best people regardless of location. In effect, this means that the Business Analyst can be outsourced. Candidates vying for the same position no longer need to be in the same location as the company. While this means greater competition, it also means greater opportunity. You can look outside your travel radius for careers with great organizations.   Don’t Just Survive, Thrive For our own career survival, we need to get better at using remote communication tools and understand how to work with a geographically dispersed team. Technology is removing the barrier of the need for face-to-face communication and we need to be able to adapt. Work at being effective with remote technology, keeping people engaged, and connective at a personal level even when in another location. In the virtual level, we don’t have the same opportunities for accidental hallway conversations to build relationships. We need to be intentional about interacting with others and connect on a personal level. Make it a priority to connect and develop relationships. Often we are heads down and don’t focus on people. We even email and send instant messages to people in the same building instead of getting up and talking to them. Work is done through people and relationship power is the most effective means of getting things done. When you build strong relationships, you can use your network to influence and gain knowledge that you can’t get by yourself.   Do What Machines Can’t Do Focus on developing skills that a machine can’t do. We need to think and work at a higher level. Technology removed the need for face-to-face communication. You now need to focus on how you can add value to your organization. If robots can solve problems, we need to get better at understanding what the right problems to solve are. Approaches such as Design Thinking allow you to understand the problem. Elevate your thinking and work to understand what’s happening in the environment and organization to understand the pain points and opportunities (think SWOT analysis). If you’re a note taker, a robot can take your job in a heartbeat. We need to think at a higher level and get beyond a solution to implement. Move in the direction of pulling back to understand the problem you’re intending to solve and whether or not it’s the right problem on which you need to focus. Listen to the full episode to get all of Kupe’s advice on becoming more valuable and understanding the benefits of technology. http://traffic.libsyn.com/masteringbusinessanalysis/MBA087.mp3   Z Your Homework Facilitating Decision Making Think of your company’s initiatives as a set of decisions to be made and facilitate that decision making. Decisions are: What problem should we go after? What are some solution options? What features should we start with? What should we prioritize? Who needs to be involved? This helps you get to the point of just enough analysis. That’s because facilitating decision making helps is understand what work needs to be done (and what shouldn’t be done) and helps you get decisions quickly and move on.   Links mentioned in this episode: B2T Training BA Times Article Your Next Business Analyst Will Be A Robot Kupe Kupersmith President, B2T Training Kupe is the President of B2T Training and has about 20 years of experience in the business analysis profession. He’s served as the lead Business Analyst and Project Manager on projects in the energy, television, sports management and marketing industries. Kupe is a trained improv actor, a

In this episode, Mary Connor shows us the power of DocOps; an approach to delivering documentation as lean and as fast as possible.  After listening to this episode, you'll understand: What DocOps is and how it differs from DevOps Three principles behind DocOps How DocOps can address documentation bottlenecks Why DocOps helps you create higher quality documents faster  Show Notes The DocOps approach allows you to be as lean and as fast as possible. It’s basic survival for today’s lean agile environment and puts those who create content in line with the way we develop code. DocOps includes three key principles: Collaborative Authoring: Requires a fast, collaborative environment tied into a process for continuous updates. Aggregation from Multiple Sources: Instead of content maintained in different places and in silos, everything comes together in one place Customer Integration: Includes a mechanism for customers to provide feedback related to the content. This allows you to quickly update and deploy changes.   Why DocOps? Software releases are getting faster and faster and the drive toward adaptability is becoming more critical. DocOps is about automating absolutely everything outside of the creative, judgment driven part of content creation that only a human being can do. This frees you up to take on more or to focus more on the critical pieces that require your expertise. Automating some of the steps also leads to less mistakes. DocOps is also critical for accelerating common bottlenecks such as legal reviews and translation of content. Through collaborative authoring and developing in small iterations, you reduce the amount of content to be addressed all at once. From there, a majority of reviews will only be on the minor changes as you iterate and the review process flow can be automated.   Steps Toward DocOps Start by finding out what tools already exist in your organization. The IT department may already have some of the tools you can use to implement DocOps. Some tools, while not specifically developed for DocOps, can be leveraged for use. Additionally, some of the software engineers may be knowledgeable in DevOps and related approaches and may have ideas on how to automate some of the documentation processes. Try first working with what you have instead of looking for and purchasing new tools.   DocOps Isn’t Just for Agile The underlying principles of DocOps are applicable in any environment, not just agile. Collaborative authoring of documents, breaking down silos, and rapid customer feedback are powerful approaches in any environment. They’re also approaches you can use for your requirements documentation. Imagine documenting requirements and allowing your stakeholders to see the changes immediately while allowing them to provide feedback. They can also contribute to the creation of requirements because of the shared environment. DocOps can lead to better accuracy of documentation as well as faster generation and better responsiveness to change.   Listen to the full episode to hear all of Mary’s advice on how to apply DocOps to your work. http://traffic.libsyn.com/masteringbusinessanalysis/MBA086.mp3   Z Your Homework If you have a process to produce customer facing documentation, find a way to automate it. You want the focus to be on the content creation, not on babysitting the process. Start with simple approaches to automation such as batch files, scripts, and a scheduler to pull the document together and move it into a production environment where it’s available to the customer.   Links mentioned in this episode: Mary’s Website Cleverhamster.com Mary’s Presentation from Keep Austin Agile 2016 Win a ticket to BA World Chicago 2016 Get 25% off training from ASPE Mary Connor Lead Technical Content Developer at Caringo Since bailing on her PhD in English and a life grading papers 20 years ago, Mary has been designing technical documentation in high-tech, focusing on Agile documentation since 2008. Currently the lone writer for Caringo, Mary has created developer documentation for cloud-based API services at Telogis and several generations of web service products at Advanced Solutions. She is all about building authoring environments that free Agile teams to write and diagram information as easily as they code. LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes. 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 MBA086: DocOps – Keep Your Documentation Agile appeared first on Mastering Business Analysis.

In this episode, Candase Hokanson helps to understand how to use visual models to not only create a shared understanding, but also to identify user stories and prioritize your backlog.  After listening to this episode, you'll understand: How to use models to create a shared understanding, even with teams that aren’t co-located The five recommended models to use for your next project How to use models to identify user stories and prioritize your backlog Why models are great at identifying missing requirements  Show Notes A visual model is a visual representation of a more complex concept. We use models because they’re easy to change and collaborate on. Visual models create a shared understanding and they can also help you build and prioritize your backlog. Typically, you’ll use 3-5 models in a project to discover requirements. You don’t need to do all of the models upfront. You can (and should) build models iteratively and incrementally, but models aren’t just for agile projects. The five models Candase recommends cover project objectives, project features, the systems, the people, and the data.   RECOMMENDED MODELS Business Objectives Model: This model helps us to understand why are we doing this project. It helps us get to the root cause and address the right thing. Additionally, the Business Objectives Model helps with backlog prioritization. Feature Tree: This model lists the project features organized in a tree format similar to a fishbone diagram. Feature Trees help you see what’s missing and creates a clear hierarchy. For further clarity, you can color code feature into phases or sprints. Ecosystem Map: This model is similar to a context diagram. It shows what systems and teams are involved and can be used to identify dependencies. Process Flow: This model maps out the process and can be decomposed into many levels. Level 1 shows the high level end-to-end process in 5-9 steps. Breaking each step down from there is the Level 2 process flow where we see more of the detail. The Level 2 process flow is the source of most of our user stories because each process flow step becomes one or more user stories. Early on, you can develop the Level 1 process flow. At Level 1, you may identify epics and features for the product backlog. Over time, you can break down each step in the Level 1 flow into a Level 2 or 3 process flow just in time and identify related user stories. Business Data Diagram: This model grounds your project from the data side. It’s more about how the customer thinks of data and includes data elements such as customer account, addresses, orders, etc. You can continue to add data as you find it in the system. The Business Data Diagram can help you identify the business rules or acceptance criteria for your user stories. It can also help you to identify missing user stories. You can use the other models to help prioritize the epics, features, and user stories in your backlog so you can identify which you should decompose and deliver first.   TRACEABILITY Using these models creates traceability. Your user stories tie back to steps in your process and include acceptance criteria derived from the Business Data Diagram. Those process steps tie back to features in your feature tree, which trace to business objectives.   Listen to the full episode for more advice on what models to use and how models can help you identify missing requirements. http://traffic.libsyn.com/masteringbusinessanalysis/MBA085.mp3   Z Your Homework Look at your project to understand where visual models can help and figure out which one you want to use. If it’s a customer facing process, a process flow is often an easy way to understand the steps and identfity user stories associated with those steps. If your project doesn’t have a customer facing component, the Business Objectives model is a great way to understand the objectives and business need and can help with backlog prioritization.   Links mentioned in this episode: Sielevel website seilevel.com Candase’s presentation from Keep Austin Agile Whitepaper on Visual Models from Candase Business Analyst World Chicago – Win a free ticket! Candase Hokanson Senior Product Manager at Seilevel Candase is a PMI-Agile Certified Practitioner who trains and coaches Product Owners, Scrum Masters and Business Analysts on agile approaches as well as championing products in those roles for clients. She works with teams to unite every team member around the common end goal of delivered business value to save up to millions of dollars in development costs for features that won’t be used or don’t contribute to the anticipated business value. 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 br

In this episode, Scott Ambler helps us to understand the power of using models and how to use models in an agile environment.  After listening to this episode, you'll understand: Why you should use models in agile What models to use in a given context How to keep models lightweight The link between models and Test Driven Development  Show Notes Written documentation is the least effective form of communication to create a shared understanding. We create models to understand, to collaborate, and to work through and explore a design or architecture. Ideally, you want to co-create models with the team and stakeholders. Be sure to keep your modeling as lightweight and collaborative as possible. Do just enough modeling and defer commitment until the last responsible moment. This allows you to focus on what you know now and what needs to be done now. Later, you will know more and will be able to ask better questions, which will allow you to dive deeper into other areas of the model and iterate. How much modeling is just enough? “Just enough” is in the eye of the beholder. It really depends on the context and the situation. Do enough modeling to get everyone on the same page and understand what to do next. Models will evolve over time. Some may disappear if they are no longer needed, some may grow and become more detailed, and some new models may appear.   Common Agile Models Any model can be done in an agile manner. Ideally, you would work together collaboratively and do just enough modeling to answer the questions you need answered right now. As an example, if you’re building a website, you might use User Stories, use cases, personas, user interface models, prototypes, data models, and network diagrams. The models you choose to create will depend on your situation and context. Choosing the right model for the purpose comes from experience. Having many models in your toolkit allows you to be effective in a variety of contexts. For business application development projects, there are a few commonly used models including User Stories, User Story maps, UI / sketches, business process models (including flowcharts or activity diagrams), and lightweight data models. Yes; user stories can be considered models. A model is an abstraction and a user story represents something more complex.   Test Driven Development Models can be used as a step towards Test Driven Development (TDD). TDD in its simplest form is a process of developing software in which you write tests first, run the test (which should fail), write just enough code for the test to pass, and then refactor the code. Modeling is good at thinking things through and understanding, but they’re not very good at providing detail. On the other hand, tests are very good at providing detail, but are bad for high level thinking. Use each for their strength. Use models to create a higher level understanding and then use tests to fill in the detail. Modeling first helps everyone to get alignment on the big picture, which can prevent rework after testing.   Listen to the full episode to hear all of Scott’s advice on agile modeling including how models scale and fit in at the enterprise level. http://traffic.libsyn.com/masteringbusinessanalysis/MBA084.mp3   Z Your Homework Build agile modeling rooms. Create a room or space where you can model and collaborate. This can mean having whiteboards, painting walls with whiteboard paint, using flip charts, etc. This allows you to work through problems and collaborate on solutions.   Links mentioned in this episode: Scott’s website ScottAmbler.com Disciplined Agile Delivery website Agile Modeling website Win a ticket to BA World Chicago Scott Ambler Senior Consulting Partner of Scott Ambler + Associates Scott works with organizations around the world to help them to improve their software processes. He provides training, coaching, and mentoring in disciplined agile and lean strategies at both the project and organizational level. Scott is the founder of the Agile Modeling, Agile Data, Disciplined Agile, and Enterprise Unified Process methodologies. He is the (co-)author of several books, including Disciplined Agile Delivery, Refactoring Databases, Agile Modeling, Agile Database Techniques, and The Enterprise Unified Process. 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 MBA084: Agile Modeling with Scott Ambler appeared first on Mastering Business Analysis.

In this episode, we’ll explore the BA Core Concept Model and Julian Sammy will help us to understand how the model can help you and your organization.  After listening to this episode, you'll understand: What the BA Core Concept Model (BACCM) is How to use the BACCM to see the big picture How the BACCM can help you understand stakeholder motivations  Show Notes Business Analysis Core Concept Model™ is a conceptual framework comprised of six core concepts critical to the business analysis profession. Understanding how each core concept relates to the other five core concepts will help you to see the system as a whole, know what questions to ask, and understand stakeholder motivations. The six core concepts are: Change: Transforming from one state to another. Your goal is to prevent harmful change and promote potentially beneficial change. Need: Something of potential value to an organization. A need might not be actionable until it becomes a requirement. A requirement is a usable representation of a need. Solution: A solution might exist but not be identified or implemented. A design is a usable representation of a solution. Stakeholders: Someone who has a relationship with the change or any of the other core concepts. They can be involved at many different levels. A good practice is to think about stakeholders in relation to value. The triangle of Value, Change, and Stakeholder allows you to integrate loss aversion and prospect theory to better understand stakeholder motivation. Value: Value is a much deeper concept than most people think. It goes beyond money. Isolate and explore what you mean by “value” and what the money will be used for. Context: The background and environment in which you’re functioning. The context influences the other concept items. Listen to the full episode to understand how to use the BA Core Concept Model. http://traffic.libsyn.com/masteringbusinessanalysis/MBA083.mp3 The Business Analysis Core Concept Model is a trademark of the International Institute for Business Analysis.   Z Your Homework Ask what value actually means. Is it something tangible or intangible? Understanding what value means to your stakeholders will help you understand their motivations and deliver on expectations.   Links mentioned in this episode: Julian’s website Change.Fail Julian Sammy Co-Founder, Thinky Person Julian Sammy is a thought leader in the business analysis community and has written and spoken extensively on business analysis and business value through keynote presentations, webinars, consultations, articles, blogs, and books. Julian was the Head of Research and Innovation for the IIBA and a major contributor in the development of the Business Analysis Core Concept Model — a work central to business analysis and the BABOK® Guide. 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 MBA083: The BA Core Concept Model appeared first on Mastering Business Analysis.

In this episode, we’ll explore how to address bottlenecks and optimize the system using the Theory of Constraints.  After listening to this episode, you'll understand: Why local optimization doesn’t work How to identify bottlenecks How to apply the Five Focusing Steps to address bottlenecks Why hiring more people may not be the answer  Show Notes The Theory of Constraints is an approach to improving organizational performance created by Dr. Eli Goldratt and is explained in his book, The Goal. The thought behind Theory of Constraints is that in every organizational system, there is one constraint that limits the flow of value. It explains why local optimization doesn’t help and that we need to use systems thinking. Similar to the weakest link in a chain, improvements to the rest of the chain don’t make it stronger. Only by improving that weakest link can we improve the strength of the chain. In addition to some tools and practices, the Theory of Constraints uses what Dr. Goldratt refers to as the Five Focusing Steps for optimizing systems. This approach allows you to address constraints is the simplest way possible.   Step 0: Define the Goal Each system has a goal. What is it you want to achieve and how will you know when you’ve reached the goal? To determine the goal, need to understand who uses the output of the System and what’s valuable to them. After you understand that, find metrics to measure the throughput, or amount of value produced by the system. Understanding the goal is often the most difficult step in the process. Finding the right goal and the right metrics to measure progress toward that goal will be critical to your success. Step 1: Identify the Bottleneck Each system has one constraint that determines the throughput of the entire system. The constraint can be a person, a team, a physical machine, one organizational rule, or anything else that limits the speed at which value flows through the system. The constraint is often called a bottleneck. At its core, the Theory of Constraints provides an approach to finding the bottleneck and taking action to improve throughput of the system as a whole. As mentioned earlier, making improvements anywhere but the bottleneck will not improve the throughput of the system and it can even have a negative effect. How do you recognize a bottleneck? If the bottleneck is a person, team, department, or piece of equipment, work piles up in front of them and people downstream of the bottleneck are idle some of the time. To help identify the bottleneck, you can use tools like flow charts, swim lane diagrams, root cause analysis, Pareto charts, or queuing models. Remember that a system can only have one constraint at a time. It’s important to understand that being a bottleneck doesn’t mean a person or team is bad at what they do or that they’re doing anything wrong. Being the bottleneck is neither good nor bad; it’s just a fact of the system. There’s always one constraint. Now that we’ve identified the bottleneck, what can we do to improve throughput?   Step 2: Exploit the Bottleneck The first way to try to address the bottleneck is to “exploit” it. Exploiting the bottleneck isn’t what it sounds like. “Exploiting” means that we’re ensuring that the bottleneck isn’t distracted by non-throughput producing work. If you think about it, the flow of value through the system is determined by a single constraint. Therefore, any work done by the bottleneck that doesn’t contribute toward the goal is waste and results in less throughput. You can exploit the bottleneck by ensuring that the bottleneck always works on the highest priority, highest value work that contributes to the goal. You can also: Make sure the bottleneck works on only one thing at a time. We want to get to done; stop starting and start finishing. Remove any non-throughput producing work from the bottleneck. Shield the bottleneck from interruptions and quickly remove impediments, but don’t shield them from important information like customer input and feedback. Make sure that the bottleneck is never idle or waiting for information, equipment, or materials. This type of waste reduces the value producing work that the bottleneck can do. You may want to use techniques such as brainstorming to identify possible experiments you can try to exploit the bottleneck and improve the system. After you implement the exploit experiment, measure the impact to see if it made a positive change. Make sure you only change one thing at a time. If you make multiple changes, you can’t tell if some changes had a positive effect and some had a negative effect. After each change, you’ll also want to go back to the beginning to make sure the goal hasn’t changed. You’ll also need to make sure that the bottleneck hasn’t moved. Through your improvements, it’s quite possible that the original constraint is no longer the system constraint. You may have improved the bottleneck to a point where they’re n

In this episode, David Hussman walks us through creating a user story map and helps us to understand how to use story maps effectively.  After listening to this episode, you'll understand: Why story maps are a powerful tool How to create a user story map What to do with the story map How to avoid building solutions people don’t want  Show Notes A narrative is more powerful than the written form. Applying user stories can be a powerful approach for creating a shared understanding and gaining customer empathy. But user stories aren’t just a pile of things to do. There’s an underlying structure that helps you see the big picture from the customer’s point of view. By organizing the story cards into a map, we can better understand the customer journey and identify small slices of value to deliver. User Story Maps are an arrangement in which story cards from left to right follows people’s interaction with the system and top to bottom to decompose that interaction. User story maps are a metaphor for a customer journey. That means you’re taking people somewhere instead of just getting things done.   Building a User Story Map A map is simply a collection of information with orientation. Start your story map by understanding who you’re going to impact. This is different from identifying the users because that mindset boxes you in and limits your thinking. Once you identify who you’re talking about, find out more about them in the context of your project. Work to understand what their goals are. Next, identify a starting point. If no one has any idea where to start, maybe you shouldn’t start. It might be a good idea to start with an area that’s ambiguous, where you have something to learn, or with something that’s really valuable to that person. Once you have your starting point, begin with an obvious example. This is basically a simple use case or scenario. Follow the obvious example with a complex one and then an example somewhere in between. Discussing a range of examples helps you to discover the range of issues that the person may face. At this point, walk a day in the life of this person. Get people to stop writing stories and promote storytelling. As you start to understand what the person does first and next using the obvious example, begin building out your story map left to right with cards on a wall or an electronic system. Add variations and details top to bottom in your map. Then identify other users and scenarios and add more detail top to bottom. Build your map as a grid and you’ll begin to see paths through the map. You’ve created a set of experiences that flow left to right and a decomposition top to bottom. You can now find paths to go through, choose one journey. Build a prototype or solution, and learn so we can adjust future development. We want to create opportunities for Minimum Viable Learning.   Here’s a summary of David’s story mapping steps: Identify who you’re talking about Identify their goals Find an obvious example and begin mapping the experience left to right; include decomposition of items top to bottom Explore the map Looking at more complex examples Exploring what happens if someone else does it (another user) Exploring what happens if something goes wrong As you find variations, continue to build your map out top to bottom Identify a customer journey through the map, build something, get feedback, and adapt future journeys   Maps produce a visualization and create a segmentation to narrow your choices while retaining the big picture. This allows you to produce small pieces, get feedback, and apply what you’ve learned. Listen to the full episode to hear all of David’s tips and advice for effectively using story maps. http://traffic.libsyn.com/masteringbusinessanalysis/MBA081.mp3   Z Your Homework When you decide to take on a user story or requirement, understand how you’ll measure the impact, not just how you’ll get it done. Stories need to include analytics. That helps you build less of the wrong thing by measuring the impact.   Links mentioned in this episode: DevJam website Story Mapping tool Cardboard Products Over Progress David Hussman Founder, DevJam Studios As founder of DevJam Studios, David leads a team of producers, makers and coaches working in small and large companies around the world. His DevJammers focus on using agile methods to help people and companies improve their product learning through faster deliver cycles and responsive engineering. Along with coaching, David speaks and teaches at a wide variety of global conferences and companies. He has also contributed to several books “Managing Agile Projects” and “Agile in the Large”. 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

In this episode, Faye Thompson helps us to solve problems by thinking like freaks and takes us from scribe to trusted adviser.  After listening to this episode, you'll understand: Why good business analysts think like freaks How to dig deeper when someone provides an answer What to do when you’re handed a solution to implement How to go from scribe to trusted adviser  Show Notes Great business analysts think differently. They don’t take the first answer at face value. They dig deeper to find the root cause, break down a problem into small pieces, and find multiple potential solution options. They then guide the team to finding the best solution among the possible options.   Thinking Framework I encourage you to think like a child; examine every problem in the simplest form. Don’t overlook possibilities because they seem obvious or too simple. Be relentlessly curious and wildly unbiased. Step back and allow yourself to brainstorm and consider all possibilities without constraints. Later, you can narrow down the solutions for feasibility and appropriateness. It’s common for us to ask a question and stop right there. We don’t dig deeper to get to the root cause. Using 5 whys or Ishikawa (fishbone) diagrams can help you find the root cause and come up with an action plan Often, there may be multiple root causes. A great BA will help develop options and help the team select actions that will have the greatest positive impact.   What’s freaky about it? The freaky part of thinking is being dissatisfied with the first answer you get. We should be asking a lot of questions and digging deeper. Don’t stop at the first answer we come to. This allows you to find connections and causes others may have missed. Great BAs aren’t scribes or note takers. Scribes don’t think like freaks. Businesses are looking for change agents who can recognize opportunities for positive change, present solution opportunities, and guide the organization to selecting the right actions and help implement those solutions. Great BAs solve the right problem with the right solution among multiple possible options. We’re able to see work that may need to be done before other work and see things that shouldn’t be done at all.   The Problem with Solutions Often we may be handed a solution to implement. When handed a solution, we need to dig deeper and ask questions about the problem the organization is trying to solve. We need to ask the tough questions to determine whether or not the solution is solving the right problem the right way. Digging deeper also allows us to use systems thinking to understand the impacts the solution may have on the rest of the system. When examining a solution, ignore boundaries and false constraints. These limit possibilities. Take a step back and make sure team is not adhering to false constraints, is focusing on the right problem, and everyone understands the business value of the solution   The Challenge of Being a Freak It can be difficult to stand up and show the organization that they’re not doing the right thing or that the solution doesn’t solve the right problem. It’s challenging to slow things down to make sure your team is doing the right thing to achieve the business value. As Great (freaky) Business Analysts, we need to step up, think differently, and dig deeper to be the guardians of business value.   Listen to the full episode to hear all of Faye’s advice on thinking differently and becoming a trusted adviser. http://traffic.libsyn.com/masteringbusinessanalysis/MBA080.mp3   Your Homework Learn to say “I don’t know enough yet”. While we want to move projects forward quickly, get comfortable with the need to go back and investigate more to ensure you have a solid understanding of the problem you’re solving and the intended value. Adopt a servant leadership mindset and put the team’s and organization’s needs first.   Links mentioned in this episode: BA World Chicago (use promo code AB-DS and save money)   Faye Thompson Sr. Agile Consultant, CareWorks Tech Faye is a senior agile consultant with more than eighteen years of project delivery experience. Focusing on agile methodologies and continuous improvement, she has had a positive impact in the financial services, healthcare, advertising, and automotive industries. She enjoys serving on the board of directors for the Central Ohio Agile Association and is a frequent speaker at industry conferences. 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 MBA080: Think Like a Freak appeared first on Mastering Business Analysis.

In this episode, Paula Bell shares her thoughts on effective collaboration; why it’s important and the eight factors for building a collaborative environment.  After listening to this episode, you'll understand: How collaboration differs from teamwork Eight factors that help teams to collaborate What you can do to collaborate better How to measure the collaboration in your team  Show Notes Collaboration is working together to realize shared goals. This is different than teamwork where individuals on the team can be focused on different goals. Many people use the word collaboration a lot, but aren’t effective at it. To be effective at collaboration, you need to understand the other people, know each other’s strengths, personalities, areas of opportunity, and capitalize on that knowledge for the good of the group. Collaboration isn’t a dictatorship. It requires interpersonal and relationship building as well as a clear understanding of the shared goal.   Collaboration Under Pressure It can be challenging to effectively collaborate under the pressure of deadlines. It’s worth taking the time to get to know one another and do some team building. The investment in team building will pay off in better collaboration and productivity. Team building and developing relationships doesn’t have to take a lot on time or effort. Simply meeting for coffee once in a while can help you better understand each other and build bonds that will improve your working relationship. Relationship is iterative and incremental. You will likely need to continue to build relationships throughout the project.   Barriers to Effective Collaboration You may be faced with some challenges when trying to collaborate with others. Perhaps some people in the group just don’t want to collaborate at all. Some may prefer just to be told what to do instead of working together on the solution. This is where relationship building and truly understanding each other helps. It will help you to understand the other person and why they interact the way they do. Another barrier may be that people don’t really understand what collaboration is or don’t have a clear understanding of the goal. Making sure the goal is understood and achieved is everyone’s responsibility.   Eight Factors for Effective Collaboration An article in the Harvard Business Review highlighted eight factors that lead to successful collaboration. Investing in signature relationship practices: Encourage collaborative behavior through processes and environments such as open floor plans. Modeling collaborative behavior: Executives demonstrate the collaborative behaviors they’d like to see in their teams. Creating a “gift culture”: Mentoring and coaching become part of the organization’s DNA. Ensuring the requisite skills: Provide training and skillset development Supporting a strong sense of community: Create an environment and opportunities for people to come together as a community. Assigning team leaders that are both task and relationship oriented: Both a task and relationship focus are needed for team leads to build collaborative teams. Building on heritage relationships: Work with teams of people who already know each other is effective in creating a collaborative environment. Understanding role clarity and task ambiguity: Make sure there’s a clear understanding of what everyone’s role is. You can help create a collaborative culture by modeling collaborative behavior yourself. Helping the team by sharing knowledge and helping each other to get better at what they do is another great way to encourage positive collaboration. Effective collaboration leads to better customer satisfaction, employee satisfaction, delivery speed, and quality.   Listen to the full episode to get more tips on effective collaboration and how to measure it. http://traffic.libsyn.com/masteringbusinessanalysis/MBA079.mp3   Z Your Homework Start building relationships. Whether it’s a coffee break, lunch, or a walk around the building with someone, take time to learn about the people on your team. Building relationships creates a better understanding and increases collaboration.   Links mentioned in this episode: Paula’s Website: paulaabell.com HBR article on building collaborative teams Paula Bell 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. 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 MBA079: Effective Collaboration appeared first on Mastering Business Anal

In this episode, C. Todd Lombardo shares his approach to Design Sprints, a one-week exercise to discover and test the right solution.  After listening to this episode, you'll understand: How design sprints can help your team discover the right solution The five parts of a design sprint What makes these sprints so powerful How to get started  Show Notes A Design Sprint is a mixture of the design process, the scientific method, and agile philosophy. It’s a process that walks you through problem solving using elements of these three approaches to gain clarity. The design process involves being empathic and having a human centered focus to solve problems. The scientific method is rigorous and experimental, allowing you to test a hypothesis. When combined with agile philosophy and its fast feedback loops, you can test a solution and understand the results over the course of five days.   The Five Steps Typically, a design sprint takes five days with one day allocated to each of five phases. Day 1: Understand – Unpack and understand the problem, the context, and the user journey. By the end of this step, you will have a clear problem statement. Day 2: Diverge – This is the ideation/brainstorming phase which allows you to identify options for solving the problem. Go for quantity, not quality in this phase. Day 3: Selection – During this phase, you will review the solution options from the Diverge phase to rank and decide on a solution to test. Day 4: Prototype – During this phase, you will build out a solution in one day. This is your minimum viable concept; something that can be tested and not necessarily something you would put into production. The prototype can be high or low fidelity. Day 5: Test – During the Test phase, you get your prototype into the hands of people who would actually use a working solution to get their feedback. Your goal is to develop a better understanding of your customers and possible solutions to the problem. Note that you spend three days just focusing on the problem and potential solutions. Identifying the right problem and solutions to test your hypothesis is critical. When you build and test a solution, you might not get the answer you’re expecting. Think of the Design Sprint as a way to test a hypothesis and learn something from your customers without creating a lot of waste.   When to use Design Sprints You can use a Design Sprint when you need to gain clarity about something or when there’s ambiguity. Design Sprints are great when there are questions that need answering. It allows you to find out if you’re right or wrong before spending too much time on what could be the wrong solution. So often, we’re handed a solution instead of a problem to solve. The Understand phase allows you to make sure you’re identifying assumptions and solving the right problem for the right customer.   Listen to the full episode to find out how to use design sprints to discover the right solution. http://traffic.libsyn.com/masteringbusinessanalysis/MBA078.mp3   Z Your Homework Use assumption storming. Write down all of the assumptions you’re making about a project. Stepping back and looking at all of your assumptions may allow you to jump to a better solution.   Links mentioned in this episode: C. Todd’s Website: http://ctodd.com/ Fresh Tilled Soil website Design Sprint book on publisher site and on Amazon C. Todd Lombrdo Chief Design Strategist at Fresh Tilled Soil C. Todd Lombardo is an author, designer, scientist, speaker, and a Design Strategist. He is a co-author of the book, Design Sprint. C. Todd focuses on building and mentoring teams in areas of user experience design, data visualization, and product strategy. He also serves on the adjunct faculty at Madrid’s IE Business School where he teaches courses in design, innovation, and data visualization. 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 MBA078: Design Sprints appeared first on Mastering Business Analysis.

In this episode, Kevin Brennan shares his views on what the future holds for business analysis and what you can do to prepare for that future.  After listening to this episode, you'll understand: The effect agile has had on the BA role How Business Architecture fits with BA skills What to do to prepare for future changes to the BA role  Show Notes What does the future hold for the business analysis profession? There are a lot of changes taking place in the industry right now. A big shift is transition to agile. Some business analysts, project managers, and other project professionals may be concerned with the move towards an agile delivery model and wonder how they fit in this new world. A lot of those concerns are based on the belief that the tasks you’re doing today are who you are and what you do instead of thinking about whether this type of skill is needed and valuable whether you’re using waterfall of agile. There is still a place for business analysis in agile. Perhaps what you’re analyzing may be somewhat different. Analyzing how business processes work and how the organization generates value will be critical to your ability to be successful. Part of your role might be focusing on what the business is doing and working with the development team to figure out how the systems support and respond to what the business does. There could also be a division in the role between people who are pure systems analysts who are experts on the commercial systems and those who are business analysts focusing more on the business side with process improvements and helping the business adapt to changes.     The Impact of Business Architecture With the increasing complexity of today’s business environment, there is an increasing need for a business focused architecture. People performing business architecture activities look at how the business operates and figures out how all of the pieces work together to achieve a positive result. They’ll look at business processes and organizational capabilities and work to understand how to realize benefits and cost savings by seeing the enterprise as a whole. We’ll likely see some business analysts moving up the enterprise chain and getting into the business architecture space.   The Shift from Project to Product There is a shift in the industry to move from a project focus to a product focus. This means that we need to see the bigger picture and expand beyond being an in-project resource. We will need to be able to develop roadmaps and take a longer term view. We’ll also need to integrate ideas and needs from different sides of the business. The project will become more of a delivery vehicle. With this shift, we see more people transitioning to product owner or product manager role. Product roles fundamentally do business analysis work and map closely to what BAs do (with a few exceptions).   Listen to the full episode to hear all of Kevin’s advice on what you can do to prepare for future changes in business analysis. http://traffic.libsyn.com/masteringbusinessanalysis/MBA077.mp3   Z Your Homework Make sure you have some kind of benefits realization map or objectives that you periodically tie back to. This allows you to see if what you’re doing links back to the original goal to make sure you’re doing the right things. Links mentioned in this episode: Change Fail Podcast: Change.Fail Kevin Brennan, CBAP Kevin Brennan is an association executive and business transformation architect, and works as an independent consultant based in Toronto, Canada. He has been a leader in the business analysis community for over a decade, as a member of IIBA’s board and executive team and shepherding the BABOK Guide through three major releases. Kevin has led organizations through strategic and business unit planning and execution, played a leadership role in enterprise change, developed and launched multiple products for a global audience, and managed a product portfolio through the entire product lifecycle. 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 MBA077: Preparing for the Future of Business Analysis appeared first on Mastering Business Analysis.

In this episode, Product Management expert Roman Pichler discusses the importance of a product strategy and how the vision, strategy, roadmap, and backlog all fit together.  After listening to this episode, you'll understand: The difference between a Product Manager and a Product Owner How to develop a product strategy How the strategy, roadmap, and backlog all fit together Why a roadmap is so critical and how to overcome some challenges with roadmaps  Show Notes Having a solid product strategy allows you to deliver the right product the right way. The strategy is the path or approach you choose to realize the vision.   How the vision, strategy, roadmap, and backlog fit together The vision is the overarching aspirational goal; the positive change that the product should achieve in the world. It should be big, bold, ambitious, and inspirational. The vision provides grounding and a sense of purpose. The product strategy will speak to the problem the product should address or the expected benefit, identify the customer, and describes how the product stands out. A roadmap takes the high level strategy and provides more detail. It shows how product will likely evolve as well as the goals and benefits you’re likely to achieve. Backlogs add the necessary detail about design and capabilities. You should be able to tie backlog items to the roadmap, which delivers on the strategy, which is aligned to the vision. The vision is the big ‘Why’. Strategy also speaks to the ‘Why’ and also the ‘What’ and ‘Who’. The backlog provides more detail on the ‘What’. The product strategy bridges the gap between user stories and the vision.   Don’t lose sight Often product owners and teams are so down in the details of user stories, they lose sight of the big picture. Having a clear product strategy gives you a reference point to tie back to and ensure you’re still aligning to the vision and product goals. Minimize the risk of creating the wrong product with techniques such as producing the minimum viable product (MVP), using prototypes, observing and interviewing customers, and other approaches for getting rapid feedback. What you learn from this validation will allow you to adjust your approach or pivot on your strategy.   Roadmaps Roadmaps are planning artifacts and like many planning artifacts, they become of little value when they’re outdated. A roadmap must be revisited and updated as we learn more from customer feedback. At a minimum, a roadmap should be reviewed and updated at least quarterly. It’s a high level strategic plan, ideally showing rough timeframes and talk about the benefits that the releases or product versions provide and the goals those releases will help you meet. The roadmap lets you see the high level path ahead for 12 to 18 months to help people understand where the product is going and allows people to plan accordingly. However, everyone must realize that the plan will be updated; it’s simply a list of options. The near-term details are in the backlog.   Listen to the full episode to hear all of Roman’s tips on developing a product strategy to make sure we build the right product to deliver value. http://traffic.libsyn.com/masteringbusinessanalysis/MBA076.mp3   Z Your Homework The single most important action you can take to make sure your requirements, backlog, and roadmap are aligned to user needs is to talk with your customers. Talking with customers gives you insights into what your customer needs are, how they use your product, and features that they don’t use. Use these insights to adapt your roadmap and requirements.   Links mentioned in this episode: Roman’s website Pichler Consulting Roman’s books Roman Pichler Pichler Consulting Roman Pichler is a leading agile product management and Scrum expert. Roman is the author of several books including “Agile Product Management with Scrum“ and his latest book, “Strategize“. Roman is an active contributor to the London product management community and a regular speaker at international conferences. Roman was named one of the 20 most influential agile people in April 2012. TwitterGoogle+LinkedIn Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes. 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 MBA076: Product Strategy appeared first on Mastering Business Analysis.