Mastering Business Analysis

Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.

Show Notes

Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.

The Need to Iterate

Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”. There’s always more than one design solution for a software problem and seldom a single best solution.

The first design approach you come up with is unlikely to be the best option. A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.

The same holds true for requirements. It will take a few iterations to get it right. These are cyclical things that you have to plan in your project management approach. You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.

Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along. You have to build in that growth and include contingency buffers into your plans. The bigger the project, the more unknowns and ambiguity and the more likely it is to change.

Understanding Stakeholders and Customers

Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development. We shouldn’t care about features as much as you care about knowing what people need to do with the product. That’s the difference between the usage-centric approach and the product-centric approach.

That begins by understanding your stakeholders. Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project. To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point. Many times, the customer may ask for a solution, which may or may not be the right thing. To provide valuable solutions, we need to understand the underlying problem. If the solution they propose is the answer, what is the question?

Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.

YOUR HOMEWORK

Pick two areas you want to get better at and vow to spend some of your time on the project learning about those areas. Look for opportunities to apply that new learning on your project and perform in those areas better than you would have before your commitment to learn and develop your skill in that focus area.

Links Mentioned in this Episode

Karl’s Personal Website – KarlWiegers.com
ProcessImpact.com – Karl’s business and book information
Information on Karl’s book, Software Development Pearls

Karl Wiegers

Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.

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.

TrendingMBA065: The Value of Business Analysis

Popular Episodes
MBA155: Hiring BAs and PMs

MBA166: Mastering the Art of Feedback

MBA209: Visual Thinking

MBA169: Digital Business Analyst Competencies

MBA202: Business Value Analysis

MBA040: User Stories – Are You Ready?

The post MBA228: Software Development Pearls appeared first on Mastering Business Analysis.

Ian Reynolds discusses how to discover the right solutions for your customers and then deliver them quickly.

Show Notes

Many organizations, especially as people are trying to work in more Lean and Agile ways, work towards producing a minimum viable product (MVP) and move on after achieving it. These organizations aren’t thinking about the value that could be delivered after the MVP.

They believe that if they put a minimum viable products in our customer’s hands, they know whether or not it’s a great product. Instead, people need to be working towards a minimum viable business as opposed to the minimum viable product. You could put a great product out there, but if you haven’t designed it to solve for the customer’s ultimate needs by testing it and getting early feedback

and created a degree of stickiness in a business model that will help you retain and add clients, you have a problem.

You don’t necessarily have a business and you haven’t necessarily solved the problem. Over optimization towards what you believe to be a viable product is not necessarily that MvP. It’s a business model that’s going to have sustainability.

What’s Valuable to Customers

When you’re developing a product, the easiest person to fool is yourself. You may believe that you have a great product, but you need to test it to validate that belief. That could be as simple as using a survey to check the validity of your idea. Building a product (even a scaled-down version of a working product) is a very expensive way to test an idea.

If you build the product first and then try to go out in the market and then make the adjustments, you’re going to have to build it again.

Faster Delivery

There are two major inhibitors to speed to market. One is trying to do everything yourself. The desire to understand exactly how the product is built and have too much control over the process of building that product is not efficient.

When you’re building a product, it’s not reasonable to be so in the weeds that you’re concerned about using a specific technology or growing to an understanding of how everything works. When starting your business or starting your MVP, don’t try to have one person do everything. Have people that are specialized in their given fields and fractionally use their time.

The other big impact to speed to market is if you don’t have a needed skill set in house.  Training that skill and building competency can take a long time.  You don’t necessarily have to hire for it as that could be much more expensive than using an outside party.

Listen to the full episode to understand how to test and discover the right solution and how approaches such as DevOps can help accelerate both discovery and delivery.

YOUR HOMEWORK

First Tip: Look at what the biggest players in the market are doing in terms of their engineering culture and then figure out what is it that they’re doing efficiently that you can copy. Don’t try to invent things yourself or come up with a new process; figure out what they’re doing and just copy it.

Second Tip: Analyze the opportunity cost of doing something in-house versus using a third party by looking at what an outside party can do for you and what specialization they have. If they could solve the problem for you quickly, maybe they can do it much more cheaply.

IAN Reynolds

Ian is the Chief Solutions Architect at Zibtek and Head of Venture Partners at Golden Section Studios. In his role as Solutions Architect, Ian matches business needs to technical solutions that solves the customer’s problem.

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.

TrendingMBA073: Agile Requirements – What’s Different

More Popular Episodes
MBA013: Trust is the New Workplace Currency – Interview with Nan Russell

Lightning Cast: Order your Backlog

MBA015: Promise Theory for Team Cooperation – Interview with Mark Burgess

MBA055: The Agile BA – Interview with Ryland Leyton

MBA195: Example Mapping

MBA058: Reusable Discovery Testing

The post MBA227: The Minimum Viable Business appeared first on Mastering Business Analysis.

In this lightning cast, we explore the 5-step design process Elon Musk uses for SpaceX to innovate and get better results.

Show Notes

In a recent interview, Elon Musk shared the 5-step design process he uses at Space X to achieve better results. Below are the details of this design process.

Step 1: Make your requirements less dumb.

Make sure you start with high quality requirements and that you truly understand the ‘why’ behind each. Simply using requirements because someone told you that’s what they want makes your requirements dumb.

“It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough. Everyone’s wrong. No matter who you are, everyone’s wrong some of the time.”

Elon recommends that for whatever requirement or constraint you have, it should come with a name, not a department. That’s because if there’s a question of concern, you can’t ask a department. You have to ask a person. The person who’s asking for the requirement or highlighting the constraint must agree that they will take responsibility for that requirement.

If you fail to do this, you may run into the situation where some random person who’s no longer with the company came up with the requirement off the top of their head with no foundation in a real need. That’s a dumb requirement.

Step 2: Delete the part or process

Look critically at the process or piece you’re developing and try to remove pieces instead of always adding new things. Work to understand the value that’s added by each part or each step in the process and reduce or eliminate those that don’t add value.

“If you’re not occasionally adding things back in, you are not deleting enough. The bias tends to be very strongly towards ‘Let’s add this part or process step in case we need it’. But you can basically make in-case arguments for so many things.”

Step 3: Simplify or optimize the design

Optimizing should only be done after you make your requirements less dumb and try to delete the part of process. The most common mistake you can make is to optimize something that shouldn’t exist in the first place.

Step 4: Accelerate cycle time

We want to reduce the amount of time from when we start working on something to when we finish. The easiest way to do that is to focus on one thing at a time and eliminate task switching. With that focus, you can get things done more quickly . . . just make sure they’re the right things.

“You’re moving too slowly. Go faster, but don’t go faster until you work on the other three things first.”

Step 5: Automate

Once you’re confident you have the right requirements with the right ownership, removed unneeded steps, optimized the design, and done things quickly, you can automate the process. Don’t spend the time and effort to automate the wrong thing or automate too soon.

Using Elon Musk’s five-step design process may help you and your organization to innovate faster and focus on customer value.

Latest Episodes

MBA228: Software Development Pearls

MBA227: The Minimum Viable Business

MBALC: Elon Musk’s 5-Step Design Process

MBA226: The FOCCCUS Formula

MBA225: The Value of Business Models

MBA224: Corkscrew Thinking

MBA223: The Human Work Machine

MBA222: Testing Your Business Ideas

MBA221: Systems Thinking and Business Agility

MBA220: Thoughtless Design with Karl Wiegers

MBA219: How To Be an Agile Business Analyst

BA Toolbox – A3 Report

MBA218: Customer-Centric Transformation

Lightning Cast: Agile Planning

MBA217: Objectives and Key Results

Lightning Cast: POWER Start for Your Meetings

MBA216: Outcome Based Change

Lightning Cast: Resistance to Change

MBA215: The Challenges with Leading in Product Management

MBA214: The BA Success Path

MBA213: Applying Theory of Constraints

MBA212: Transforming Your Work with Modern Agile

MBA211: Adaptive Leadership

MBA210: Vital Communication

MBA209: Visual Thinking

MBA208: Facilitative Leadership

MBA207: Bad Behaviors in the Workplace

MBA206: Succeeding with Analytics

Lightning Cast: BA Goals Revisited

MBA205: Beyond Data Literacy

MBA204: Top Skills for 2020

MBA203: Career Insurance

Yes, Virginia, There Are BAs in Agile

Lightning Cast: Failure to Launch (a new product)

MBA202: Business Value Analysis

MBA201: Tips From an Accidental Product Owner

MBA200: Take Action! The Best Advice from Over 200 Episodes

MBA199: The Future of the BA Profession

MBA198: DevOps – What it Means for BAs

MBA197: Making Change Fun

MBA196: Customer Journey Treasure Hunting

MBA195: Example Mapping

MBA194: Start Your Project Off Right

MBA193: About Your Career

Lightning Cast: Story Estimation – What’s the Point?

Lightning Cast: Requirements Rot

MBA192: The Blight of Product Debt

Lightning Cast: The Power to Get Things Done

MBA191: Use Cases in Agile

Lightning Cast: AI – Can you be replaced by a machine?

MBA190: Business Data Analytics

Lightning Cast: You Are a Facilitator

MBA189: Adventures in Product Ownership

Lightning Cast: Simplified Value Stream Mapping

MBA188: The Four Ps of Product Ownership

Lightning Cast: Product Debt

MBA187: Transitioning to a Scrum Master Role

Lightning Cast: Business Agility

MBA186: Exploring Product Ownership

Lightning Cast: Don’t Throw it Over the Wall

MBA185: Business Analysis in Agile

Lightning Cast: Non-Functional Requirements in Agile

MBA184: Discover What Customers Want with JTBD

Lightning Cast: We Are the Business

MBA183: The BA Role on a Scrum Team

MBA182: BA in the Service Industry

Lightning Cast: Death, Taxes, and Missed Requirements

MBA181: The Three BA Archetypes

MBA180: Socratic Questioning

Lightning Cast: BA Performance Goals

MBA179: The Power of Prototyping

MBA178: Career Options for BAs

MBA177: Product Backlog Refinement

MBA176: Predictions for 2019

Lightning Cast: A Visit From the Business Analyst

MBA175: Product Management is the New Business Analysis – Part 2

MBA174: Product Management is the New Business Analysis

MBA173: Avoiding the Build Trap

MBA172: Decide Smarter Faster with Kupe Kupersmith

MBA171: Your Questions Answered – Listener Mailbag

MBA170: Persuasion – Get Buy-In for Your Ideas

Lightning Cast: Big Design Up Front

MBA169: Digital Business Analyst Competencies

MBA168: Exploring the BA Career Path

MBA167: The Power of Storytelling

MBA166: Mastering the Art of Feedback

Special Message

MBA165: Remembering Jerry Weinberg

Lightning Cast: Think as a Customer

MBA164: The Agile Analysis Certification

MBA163: Lean Six Sigma – What You Should Know

Lightning Cast: Moving to a BA Role

MBA162: The Business Analyst Role and its Real Value

MBA161: Evolution of the BA Role

Lightning Cast: Dude’s Law

MBA160: The Art of Better Business Requirements

Lightning Cast: Business Agility

MBA159: Experiment Driven Development

MBA158: Agile Requirements

MBA157: The Importance of Good Data Analysis

Lightning Cast: Symptoms of Success

MBA156: The Power of Mentoring

MBA155: Hiring BAs and PMs

MBA154: Change Leadership

Lightning Cast: BA on a Scrum Team

MBA153: Trends in Business Analysis

Lightning Cast: Powerful Questions

MBA152: Finding the Right Project

Lightning Cast: Order your Backlog

MBA151: Your Consulting Practice – with Karl Wiegers

Lightning Cast: Which Communications Channel Should You Use?

MBA150: A High Five for Business Analysts

Lightning Cast: Common Issues Facing Business Analysts Today

MBA149: The Power of EQ

Lightning Cast: The Business Alchemist

MBA148: 7 Keys to Succeeding with Agile

Lightning Cast: Trust – The One Thing that Changes Everything

MBA147: The Business Agility Manifesto

MBA146: The Full Stack Business Analyst

MBA145: Predictions for 2018

Lightning Cast: Confessions of a Recovering Perfectionist

MBA144: The 12 Days of the Project

Lightning Cast: Stepping Up to Product Ownership

MBA143: Imposter Syndrome – Banishing Your Inner Critic

Lightning Cast: Root Cause Analysis

Lightning Cast: Using Competency Models

MBA142: Lean Startup for the Enterprise

MBA141: Digital Transformation – What is Means for BAs

MBA140: Improve Influence with NLP

Lightning Cast: Better Communication Using the DiSC Model

MBA139: Thin Slicing Problem Analysis

Lightning Cast: The Many Uses of a SIPOC

MBA138: Building a Believable Business Case

Lightning Cast: Stay in Your Lane

MBA137: Challenges with User Stories – with Mike Cohn

MBA136: What the IIBA Can Do for You – Part2

MBA135: What the IIBA Can Do for You

Lightning Cast: Flip the Script in Your Job Search

MBA134: Distinguishing Yourself in Your Career

Lightning Cast: Brainstorming – You’re Doing It Wrong!

MBA133: What BAs Need to Know About Agile

Lightning Cast: Requirements Quality

MBA132: Next Generation Competencies

Lightning Cast: The Agile Business Analyst Mindset

MBA131: Interviewing for a Business Analyst Position

Lightning Cast: The Business Analyst Career Path

MBA130: Exploring Requirements with Jerry Weinberg

MBA129: Real Life Agile, UX, and Design Thinking

MBA128: Where Should the Business Analyst Reside?

MBA127: Guiding Principles for the Business Analyst – part 2

MBA126: Guiding Principles for the Business Analyst

MBA125: Become the Conscience of the Business

MBA124: Business Analyst in an Agile Environment

MBA123: The 21st Century Business Analyst

MBA122: Driving Real Value Through Business Analysis

MBA121: Mastering Product Ownership

MBA120: Jobs to be Done Theory

MBA119: What’s in Your Backlog?

MBA118: Virtual Leadership

MBA117: Getting Requirements Right

MBA116: Implementing Solutions vs Problem Solving

MBA115: Political Martial Arts – Navigating Office Politics

MBA114: Value Proposition of the BA Role

MBA113: Problem Solving – The RIGHT Stuff

MBA112: User Centered Design

MBA111: Design Thinking IS Good Business Analysis

MBA110: Managing Ambiguous Requirements

MBA109: Foundations in Business Analysis

MBA108: Prioritizing with the MVP

MBA107: Backlog Refinement – From Misunderstanding to Collaborative Discovery

MBA106: Rapid Requirements Gathering

MBA105: The Best Advice I Ever Received

MBA104: Predictions for 2017

MBA103: How Mr. Finch Stole the Project

MBA102: Product Management – Build the Right Thing

MBA101: Split Your Stories!

MBA100: My Biggest Mistake

MBA099: Assumptions Mapping

MBA098: The Art and Science of Influence

MBA097: Partnership Between the PM and BA

MBA096: The Standard for Business Analysis

MBA095: Lean Change Management

MBA094: Perspectives in Business Analysis

MBA093: Beyond Project Risk

MBA092: Reducing the Risk of Missing Non-Functional Requirements

MBA091: Going from Order Taker to Trusted Advisor

MBA090: BABOK 3.0 with Richard Larson

MBA089: Agile Manifesto – What it Means to Business Analysts

MBA088: Effective Requirements Workshops

MBA087: Replaced by a Robot – Interview with Kupe Kupersmith

MBA086: DocOps – Keep Your Documentation Agile

MBA085: From Models to Stories

MBA084: Agile Modeling with Scott Ambler

MBA083: The BA Core Concept Model

MBA082: Addressing Bottlenecks with Theory of Constraints

MBA081: User Story Mapping with David Hussman

MBA080: Think Like a Freak

MBA079: Effective Collaboration

MBA078: Design Sprints

MBA077: Preparing for the Future of Business Analysis

MBA076: Product Strategy

MBA075: Slices of Big Truths

MBA074: Lean Business Analysis

MBA073: Agile Requirements – What’s Different

MBA072: Improve Your Facilitation

MBA071: The Essence of Business Analysis

MBA070: Better BA and PM Collaboration

MBA069: Business Rules – What You Need to Know

MBA068: Realities of Being a Product Owner

MBA067: All About the PMI-PBA Certification

MBA066: Starting a BA Community of Practice

MBA065: The Value of Business Analysis

MBA064: Transitioning to a Product Owner Role

MBA063: Starting a Career in Business Analysis

MBA062: Peer Reviews for Better Requirements

MBA061: Overcoming Roadblocks to Success on Complex Projects

MBA060: Business Architecture and Business Analysis

MBA059: Problem Solving for Business Analysts

MBA058: Reusable Discovery Testing

MBA057: The 6 Stakeholders You’ll Meet in Project Hell

MBA056: Design Thinking for Better Business Analysis

MBA055: The Agile BA – Interview with Ryland Leyton

MBA054: Strategy and its Role in Business Analysis

MBA053: Use Cases and Beyond – with Ivar Jacobson

MBA052: Portfolio Management & The Agile Extension

MBA051: A Visit From the Business Analyst

MBA050: The T-Shaped Business Analyst

MBA049: The First Line of Defense Against a Security Breach

MBA048: Finding the Minimum Viable Product

MBA047: The DNA of a Great Agile Business Analyst

MBA046: The Product Owner / Business Analyst Relationship

MBA045: The Agile BA – Myths and Misconceptions

MBA044: Business Process Automation

MBA043: Abuser Stories – Think Like a Bad Guy

MBA042: Stop Using User Stories – Interview with Jim Benson

MBA041: What’s the Second Best User Story?

MBA040: User Stories – Are You Ready?

MBA039: The Big Deal with Big Data

MBA038: Use Cases, CX, and UX: Putting it all together

MBA037: The Key to Better Collaboration

MBA036: Psychology of Leadership – Interview with Cillín Hearns

MBA035: Active Listening – The Most Important Skill

MBA034: Use Case 2.0 – Interview with Ian Spence

MBA033: Landing and Succeeding in Your First BA Role – Interview with Alex Papworth

MBA032: Systems Thinking – Interview with Paula Bell

MBA031: UX – Are you Experienced? Interview with Neil Turner

MBA030: Myths and Patterns of Organizational Change – Interview with Linda Rising

MBA029: Business Process Improvement – Keep it Simple – Interview with Brian Hunt

MBA028: Talking Techie and Presenting Complex Ideas with Melissa Marshall

MBA027: Elicit User Requirements with Legos – Interview with Ellen Grove

MBA026: Guarding Against Scope Creep

MBA025: Don’t Just Make Software, Make an Impact – Interview with Gojko Adzic

MBA024: Lead with the Power of a Jedi – Interview with Heather Mylan-Mains

MBA023: Using Behavior Driven Development for Better User Stories – Interview with Jeffrey Davidson

MBA022: How to Know Where to Focus Your Efforts – Interview with Chris Matts

MBA021: Is the Business Analyst Role Just Overhead? Interview with John Sextro

MBA020: The Value of Certifications – Interview with David Mantica

MBA019: Why Start with Why? Interview with Stephen Shedletzky

MBA018: Step Up to Leadership with the Five-Rule Framework – Interview with Scott Stribrny

MBA017: Does Your Communications Engine Need a Tune-Up? Interview with David Barrett

MBA016: User Story Mapping with Jeff Patton

MBA015: Promise Theory for Team Cooperation – Interview with Mark Burgess

MBA014: The Future of Business Analysis – Interview with David Mantica

MBA013: Trust is the New Workplace Currency – Interview with Nan Russell

MBA012: Beyond Requirements – Interview with Kent McDonald

MBA011: Make Your Waterfall Projects More Agile

MBA010: Make Virtual Meetings More Effective – Interview with Angela Wick

MBA009: Exploring the 7 Product Dimensions for Better Requirements Discovery – Interview with Mary Gorman

MBA008: How to Discover Product Requirements – Interview with Ellen Gottesdiener

MBA007: How to be a Badass Business Analyst – Interview with Bob Prentiss

MBA006: The Business Analyst Career Path – Interview with David DeWitt

MBA005: Interview with Len Lagestee – How can a BA deliver value to an Agile Team?

MBA004: Defeat the Meeting Super Villians

MBA003: How can introverts work well on agile teams – Interview with Ken Howard

MBA002: How to Elicit Non-Functional Requirements – Interview with Roxanne Miller

MBA001: Introduction to the Mastering Business Analysis Podcast

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 MBALC: Elon Musk’s 5-Step Design Process appeared first on Mastering Business Analysis.

The Theory of Constraints is an approach to improving organizational performance by accelerating delivery. Author Clarke Ching shares his FOCCCUS Formula to address the system's bottleneck.

The post MBA226: The FOCCCUS Formula appeared first on Mastering Business Analysis.

David Mantica helps us understand business models and helps us understand how to find new opportunities to create greater value.

The post MBA225: The Value of Business Models appeared first on Mastering Business Analysis.