Skip to main content

Business Analysis with a Continuous Improvement Mindset

Here we go again, another long requirements session. The discussion has drifted into a discussion about a future release. Not even sure we have the right people in the room.

How awesome would it be to start a requirements session and stay on track with everyone speaking the same language. Sounds great, right!

In this article, we’ll cover how one Continuous Improvement lens can be used with Business Analysis, starting with planning…


Getting to the root cause of what needs to happen, or the true business need, can be easier and perhaps a little more fun if we use the 5 Whys tool. The 5 Whys is used in a Continuous Improvement model and a sub-technique of the Root Cause Analysis technique (published by IIBA in the BABOK® Guide version 3.0 section 10.40). By asking the question “Why” (five is a good rule of thumb, although you can ask as many ‘Whys’ as you think appropriate) to peel away the layers of symptoms which can lead to the root cause of a problem.

Here’s an example for your enjoyment: the story goes that a few years ago, the National Parks Service executives wrestled with a problem. The stone exterior of the Lincoln Memorial was deteriorating and showing significant signs of wear. They considered replacing the stone or painting over regularly, but these solutions were very expensive. So instead, they called the maintenance crew and asked the first of 5 – ‘Why?’

Executives: Why is the stone deteriorating?

Maintenance crew: we use high-power sprayers to wash the memorial every two weeks.

Sometimes in our requirement sessions, that’s where we stop. We think we know why the business is asking for a particular feature or function. The discussion could have been over if the executives solved the problem at this level by canceling the washings. However, they realized this would bring complaints from the tourists, who expected a clean memorial.

Executives (2nd ‘Why’): Why are we doing high-powered washings every two weeks?

Maintenance crew: to remove the bird droppings.

Executives (3rd ‘Why’): Why are there so many birds?

Maintenance crew: theyfeed on the spiders.

Executives (4th ‘Why’): Why are there so many spiders?

Maintenance crew: billions of insects visit the memorial at night – The spiders come for the buffet.

Executives (5th ‘Why’): Why are there so many insects?

Maintenance crew: The insects are attracted by the high-powered spotlights we shine on the memorial.

Executives: What can we do about the lights so there won’t be so many bugs?

Maintenance crew: turn the lights on later in the evenings and off earlier in the mornings.

This, as it turned out, was a brilliant idea! The lights were typically turned on two hours before sunset and turned off two hours after sunrise.

By waiting until 30 minutes after sunset to turn the lights on and turning them off 30 minutes before sunrise, they were able save significant money on electricity and also reduce the amount of bugs by 90%.
The executives were happy. The maintenance crew was happy, and most importantly, the tourists were happy. On the downside, the insects, assuming that the Lincoln Memorial was closed for business, decided to relocate and spent their evenings with George Washington and Thomas Jefferson, whose memorials turned on their lights earlier in the evening.

In addition to understanding the root cause of a problem, here are a couple of other ‘tools’ you may want to consider when you are in the planning phase of your project or initiative:

  • Identify your stakeholders – ensure you have the right people at the table, i.e. those who will have input into the work and/or those who will be impacted by the work.
  • Solid communication is critical to ensure success
  • Key learnings – from past projects
  • Business analysis plan – track work activities
  • Process map – “as–is” to “future state” definition
  • Proposed metrics – how will you measure the success of your project


Reviews are a great way to “test” or evaluate your business analysis plan, as well as any other work product (BABOK® Guide section 10.37). After planning, ask stakeholders (Architects, Project Managers, other Business Analysts) to review your plan. Checklists are often helpful to provide your reviewers guidelines so they can make the most efficient use of their time.

For example, you may separate the following activities so everyone is not reviewing everything:


  • Grammar and spelling
  • Formatting
  • Duplicate requirements
  • Glossary
  • Content – maybe even divide up the sections


One of the more structured approaches to eliciting requirements is Workshops (another Continuous Improvement tool and published in the BABOK® Guide section 10.50). The most important step of a workshop is the preparation, making sure the objectives, expected outcomes, and agenda are defined; and, the right stakeholders are included, available, and clear on their roles (e.g. sponsor, facilitator, scribe, timekeeper).

Another tool that helps align stakeholders is a kickoff meeting. The kickoff is a great time to inform all stakeholders of the approach, communicate roles and responsibilities, align on the schedule, ensure there are no conflicts, and set the ground rules.

Here are a few examples of ground rules to share at a kickoff:

  • Be on time and prepared
  • Everyone must participate
  • Keep an open mind
  • Speak up when the process isn’t working effectively
  • Ensure only one conversation at a time (e.g. use Parking Lots)


Consider having an After Action Review (AAR) or Lessons Learned session for your projects (BABOK® Guide section 10.27). Depending on whether your project is Waterfall or Agile, the timing of your reviews may vary.

Here are a couple suggestions:

  • Waterfall – project completion or after each phase
  • Agile – after each iteration

Regardless of your methodology, the best practice suggests having a feedback loop so you can course correct as you go.

Typically it’s best to focus on the process and not the people. With that approach, we ask the following questions during our AAR:

  • What was supposed to happen?
  • What actually happened?
  • Why did it happen / not happen?
  • What are we going to do next time?
  • Who can learn from our experience?

5 Why’s Reference:
PDCA Reference:

About the Authors

bburkeBetty Burke, Director, Continuous Improvement
Betty has 25+ years leading teams in the areas of business analysis, information systems, quality, process and change management. She has been with US Cellular for 6 years, leading a team of technical business analysts for 5 ½ years and most recently accepting a Director position to lead Continuous Improvement for the organization. Prior to that, Betty worked for Motorola for 9 years where she led a team of system architects, process / quality and test engineers. Betty is a Certified Six Sigma Green Belt and worked as a Process Consultant for 3 years. Prior to that, she led development, data security and test teams at Cincinnati Bell for 12 years. Betty holds a Masters in Organizational Management and a B.S. in Computer Science.

afitzgeraldAmie Fitzgerald, Manager of Business Analysis
Amie has 12+ years of experience with technical projects, of which 10+ years have been spent in business analysis. She has been a Business Analyst with US Cellular for 8 years, most recently promoted to Manager of Business Analysis. Throughout her career, Amie has had a passion for looking at ways to continuously improve business analysis processes. Amie earned her Certified Business Analysis Professional certificate in May 2016. Amie holds a Master of Science in Software Engineering with a focus in Project Management, and a Bachelor of Science in Information Systems with a focus in Web Development.