By Heather Smith,  Consultant

As companies try to do more with less, Lean is still growing in popularity. The Japanese manufacturing philosophy from Toyota emphasizes cutting waste and boosting efficiency. Other industries often struggle to adapt Lean to their processes. This is because Lean was developed as a system to eliminate waste in automotive manufacturing in the 1960’s. Today, Lean is evolving into a management approach to improve operational effectiveness (Kovacheva, 2010). However, because Lean methods were developed in the manufacturing industry they often need to be adjusted to fit other processes—like business analysis. Put simply, “Lean business analysis is about doing the right thing at the right time and removing things that don’t add value” (Saboe, 2016).

It makes sense business analysis would use Lean to create efficiency and eliminate waste. The International Institute of Business Analysis (IIBA) – the organization responsible for defining the profession – calls business analysis “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders” (IIBA website). By definition, both Lean and business analysis involve examining and refining business behaviors and processes. In this article, I explore how Lean relates to business analysis in the technology sector.

Lean identifies several types of “muda” or waste (see the table below). The column on the left lists traditional/manufacturing definitions of waste. At a glance, none of these seem applicable to business analysis or software development – the column on the right shows how those wastes are defined in a software development context.

Source: Poppendieck & Poppendieck, 2007.

Overproduction/Partially Done Work

Overproduction and partially done work are equally wasteful. The simplest example of overproduction in a non-manufacturing environment is “gold-plating.” The Project Management Institute (PMI) is clear in its position that delivering more than what is explicitly defined in the scope statement is not good for any project. Exceeding customer expectations is great—but schedules and budgets are estimated based on planned work. There are ways to go above and beyond without doing extra work. This is where innovation and ingenuity are vital.

Partially done work is another aspect of waste in business analysis. Most often this is because we forge ahead with insufficient information (Gottesdiener, 2009). In software development there is always some degree of uncertainty – Lean business analysis means delivering only what is needed, when it is needed. Some organizations want to have all requirements up front. This is not the best approach. Requirements are specific, standalone statements and should be verified as they are developed (Gottesdiener, 2005). Another common problem occurs when business analysts rely too heavily on templates or tools out of habit or protocol. Work products should be developed on an as-needed basis. A Lean methodology prioritizes only the tasks that add value.

Inventory/Extra Features

Business analysts frequently encounter customers who want requirements documented in case they are needed later (“nice to have”/ “just in case”). Some customers want to document every possible permutation of user stories and requirements – even those they know they will likely never use. This can be difficult. Business analysts find and document the processes that add value. They also identify and eliminate those that don’t. Taking time to record everything leads to unused work and increases document management at both the project and enterprise levels.

One way to circumvent this is to create value stream maps. They provide a clear visualization of what is needed to perform business processes. They also enable the business analyst to demonstrate what requirements and use cases are truly necessary.

Extra Processing/Relearning

In some cases, waste occurs when there are too many people involved in creating or approving a product. Once I worked with a team that had a 29 step process for analyzing and approving minor changes to a software product. This quickly resulted in significant backlog and made tracking work difficult.

Another common problem occurs when requirements and related business analysis tasks are done in bulk. This “relearning” can lead to ongoing reviews of previous work. This happens because it is difficult for people to remember precisely what was agreed on and why. The best way to avoid this type of waste is to develop requirements and business analysis products as close to the deadline/consumption as possible (Gottesdiener, 2009). This type of waste is closely related to Overproduction/Partially Done Work and Inventory/Extra Features.

Transportation/Handovers

Depending on the number of people and teams involved in a technology project, there needs to be a strategy in place to avoid sending the same work products to different audiences for review. While it is certainly helpful to get feedback and to ensure shared understanding of outcomes, it is not beneficial to have multiple rounds of reviews with separate audiences. There are a couple of reasons for this—different groups may have different feedback/requests, the business analyst must then resolve the contradiction—meaning more meetings. This takes more time and increases costs.

Motion/Task Switching

Motion is closely related to transport in its potential to create waste and delay results. Unlike transport, motion is not necessarily physical. Too many review/approval cycles or email chains that involve several people and span several days do not add business value. I have a rule: if the team cannot reach a shared understanding in 3 emails, we need to have a meeting or a phone conversation.

Task switching in business analysis is typically caused by resource shortage. When organizations lack sufficient resources they often assign the same people to multiple projects. This is acceptable so long as there is careful coordination of tasks and deadlines. Task switching requires more attention to detail and work planning to ensure that one person’s workload does not have adverse downstream impacts (Gottesdiener, 2009).

Waiting/Delays

None of us accomplishes anything alone—we depend on others to complete key tasks. Inevitably, those people have competing deadlines and personal lives to contend with. It is impossible to completely eliminate waiting; however, it is absolutely possible to identify known scheduling conflicts and plan activities around them. For example, if you know in advance key teams or resources are unavailable, you can plan to work on other tasks or with other teams. “One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives.  There should be a consistent start and a consistent end.  Everything in between should be flexible” (Kupersmith, 2011). By breaking down tasks, you can deliver more quickly, proactively address resource constraints, and improve processes.

Defects

Of all wastes, defects require the least explanation. No one wants to create a faulty product. The sooner a defect is detected the more easily (and cheaply) it can be fixed. This suggests an approach where inspection prevents defects. Creating smaller user stories and packages of requirements on an as-needed basis and building mockups/draft prototypes makes it easier to avoid defects (Galen, 2013).

Conclusion

Ultimately, Lean business analysis means the ability to quickly and neatly decide which tools to apply, what deliverables matter, and to engage in activities that add value to your client, project, or organization. There is not a clear path – practicing Lean as a business analyst requires years of experience. It requires trial and error. What works well for one team or project, cannot necessarily guarantee later success.

IIBA defines specific business analysis tasks alongside specific techniques used to accomplish each task. While there is value in defining tasks and relating them to appropriate tools, this information should not be taken as prescriptive. Not all tasks add value to all projects. Seasoned business analysts are able to quickly assess the situation, client, or project needs and craft a suitable strategy. Less experienced analysts are more likely to simply accept process and templates without considering whether they add value or provide the most expedient return on investment. Templates and techniques are tools and business analysts who know how and when to apply those tools will create more value by doing only what is needed to get the job done.

There is no single solution.

Works Cited

Galen, R. (2013). 10 Indicators that you don’t understand agile requirements. Retrieved from: https://www.batimes.com/robert-galen/10-indicators-that-you-dont-understand-agile-requirements.html

Gottesdiener, E. (2009). The agile business analyst: Eyes for waste. Retrieved from: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/811/The-Agile-Business-Analyst-Eyes-for-Waste.aspx

Gottesdiener, E. (2005). The software requirements memory jogger: A pocket guide to help software and business teams develop and manage requirements. Goal/UPC.

Kovacheva, A. (2010). Challenges in Lean implementation: Successful transformation towards Lean enterprise. Retrieved from: http://pure.au.dk/portal-asb-student/files/9093/ak83188…pdf

Kupersmith, K. (2011). Why business analysis processes are a waste of time. https://www.batimes.com/kupe-kupersmith/why-business-analysis-processes-are-a-waste-of-time.html

Poppendieck, M. &Poppendieck, T. (2007). Implementing Lean software development: From concept to cash. Pearson Education, Boston.

Saboe, Dave (2016). MBA074: Lean ausiness analysis. http://masteringbusinessanalysis.com/mba074-lean-business-analysis/