The lean approach brings a purpose-led, value-oriented mindset that necessitates a shared vision among all project stakeholders.

Business analysts should start every project by defining the business requirements that explain the vision and value proposition of the product. Business requirements should clearly answer why customers need that specific product.

Business analysts should interview target customers at the beginning of the project and validate that the defined business  requirements  can  resolve articulated customer needs.

Clear definition of business requirements at the beginning of the project steers every stakeholder in the same strategic direction. This mitigates the risk of scope creep due to potential change requests (CRs), which result in waste  due  to rework.

Depending on the size of the project, business requirements can be defined in different types of product scope documents:

1. Business-Case Document

In large-scale projects (usually called Type-A projects) that have enterprise-level impact, business requirements should be documented on a business-case document. The business-case document should include: -Business requirements: to clarify why the new product is needed

-Scope: to define and prioritize product features that will satisfy specific goals and problems of target customers

-Context: to analyze which other products and systems the product will work in integration with

-Cost vs. benefit analysis: to better understand the feasibility of the new product. The feasibility of a new product should be analyzed based on the defined scope, because a feasible product may become infeasible depending on the selected features.

-Risks: to identify and mitigate possible negative consequences of releasing the new product.

 

2. Vision and Scope Document

For medium-and small-scale projects (usually called Type-B projects), business requirements should be documented on a vision and scope document. This document should include features of the proposed product that will be delivered in each release and provide context information that shows the high-level integration of the product with other products and systems.

3.  SOW (Statement of Work) Document

For enhancement/modification requests (usually called Type-C projects) on existing products that usually last less than one month, there is no need for a business-case or vision and scope document. A clear explanation of the business need in a one-page SOW document is just enough to describe the scope of work. These requests are better fulfilled by a more agile approach without too much documentation.

 

Rippling Effect

On any scope document, business requirements should be defined in specific, purpose-led, achievable, and crystal clear statements.

A clear definition of business requirements at the start of the project is very important, because at later stages of the project, the functional, nonfunctional, and technical requirements, and the business rules of the product should be defined consistent with the business requirements. Wrong definition of business requirements will have an adverse rippling effect on all of these low-level requirements and business rules. This will result in waste due to a high number of CRs and defects.

 

Paradox of Choice

Having many features is not an indicator of elegance or quality in lean product development.

On the contrary, as psychologist Barry Schwartz describes it in his book Paradox of Choice: Why More Is Less, choice overload creates decision-making paralysis, anxiety, and stress rather than bringing more satisfaction to customers.

 

A lean approach, delivering “maximum value” with “just enough” features, is the ultimate goal. Having a formal prioritization process is one  of  the preconditions for applying this approach.

Without a prioritization process, business units feel free to request any product feature as if the project has unlimited resources. The features requested by business units should be  prioritized according to two  main criteria: -business value and,

-implementation difficulty.

Business value depends on the alignment of a feature to business requirements and customer needs. The items with high business value and low implementation difficulty should be rated as  high priority, while  the ones with low  business value and high implementation difficulty should be rated as low priority.

 

The rest of the features should be labeled as medium priority and prioritized according to their expected frequency of use. Medium priority features can be relabeled as high priority if they have high frequency of use. Otherwise, they move to the low priority quadrant.

 

Time to Market

 

When time to market is critical for the product, the project should be classified as a “fast-track” one. In these time-sensitive, fast-track projects, business analysts and managers should convince business units to focus on “must-have” features rather than “nice-to-have” features and try to generate “fair-value” outcomes in an iterative way.

80/20 Rule

Regardless of time-to-market constraints, business units are always eager to expand the scope of products by adding nice-to-have features. However, in our experience the majority of users only use a minority of the product features. This is big source of scope-level waste.

When business units insist on nice-to-have, low-priority features, business analysts and project managers should remind them of the famous phrase in Voltaire’s poem “La Begueule”: “perfect is the enemy of good.” The phrase suggests that insisting on perfection often results in no improvement at all.

 

Benchmarking and Reverse Engineering

Business units also have a tendency to enlarge the product scope  by benchmarking competitors’ products and requesting all of their features.

Although benchmarking competitors’ products is a fast way of determining product features, it is not appreciated at every phase of lean product development.

In a lean approach, project stakeholders should be looking at “what problems of my target customers should my product solve” instead of “what my competitors are doing.”

After product features are defined, benchmarking can then be used to fasten later phases of product development by exploring how competitors implement similar features without reinventing the wheel.

It should also be remembered that even the best competitors don’t always do the right things. Thus benchmarking can also result in copying competitors’ mistakes. In one of BA-Works projects, our team was responsible for benchmarking the customer interaction channels of a global hotel chain with its competitors. During the study our team noticed that the majority of competitors

 

had common right things and common wrong things on their customer- interaction channels (web, call center, mobile, and social media). This was a result of a copy-and-paste approach. Although copying competitors is a fast way, companies should first focus on finding ways to differentiate themselves in providing the best customer experience.

 

Core Version of a Product

The lean approach suggests the following flow in PDLC:

-Deploy the first release with a core version of the product, and get customer feedback as early as possible.

-At each following iteration, use previous customer feedback to refine the product by adding, updating, and even dropping features.

-Iterate until the product satisfies business requirements and customer needs.

The core version of a product should have a minimum set of features that can solve the main problem of target customers. Popular terms such as MVP (minimum viable product) and MMF (minimum marketable features) are used to define this core version of the product.

For instance, the core version of a golf car should at least have an engine, tires, steering wheel, brakes, seats, and a utility box. At the first release, even these limited core features may fulfill the basic customer need of transportation on a new golf field. The decision to add which nice-to-have features, such as cup holders, ice boxes, heated windshields, and sound systems, can be made later according to customer feedback on the core version of the car.

High-priority features on scope documents are the best candidates for the core version of the product. Medium-and low-priority features can be added to later releases according to customer feedback on the core version.

The priority of features may change based on customer feedback. A feature that was initially considered low-priority may later become a high-priority one. Similarly, a product feature that was initially considered a high-priority one may become obsolete if it doesn’t deliver the desired value to customers.

For the CEC mobile application project, BA-Works’ business analysts assessed

 

the request from the marketing business unit. They marked this request as a Type-A project that had enterprise-level impact on sales channels. They were shocked when they saw that the marketing business unit planned to release the product only two months later.

Since it was a Type-A project, the analysts worked with the marketing business unit to prepare a business-case. The details of business-case document were as follows:

Context

Our business analysts analyzed which existing systems such as: -ERP (Enterprise Resource Planning), -CRM (Customer Relationship Management), – CMS (Content Management System) -Dealer Management System the mobile application needed to be integrated with to deliver the proposed features.

Cost vs. Benefit Analysis

According to the cost benefit analysis, the mobile application project had a positive NPV (net present value). It would payback in less than three years. This payback period was acceptable for the marketing business unit.

The project team also assessed the risks and defined the mitigation strategy.