IPD CBB Reuse Development Strategy
Original

ZenTao Content
2025-11-11 09:00:00
3
Summary : This article introduces the Common Building Blocks (CBB) strategy within the Integrated Product Development (IPD) framework, designed to address operational inefficiencies such as component redundancy and high R&D costs through standardized, reusable modules. By establishing a unified platform and repository, CBB helps enterprises streamline development processes, reduce procurement expenses, and accelerate time-to-market. Its implementation involves systematic requirements planning, standardized development protocols, dual-review quality assurance, and continuous iteration mechanisms. This approach transforms R&D from isolated project-based efforts into sustainable, compounding organizational assets, as evidenced by IBM's successful component consolidation initiative.
ZenTao: 15 years of dedication to building open source project management software
Download Now

Does your organization face challenges such as warehouses stocked with dozens of functionally similar circuit boards, persistently high procurement costs, and frequent errors during production line changeovers? Such pervasive redundancies not only delay time-to-market but also drain corporate resources through excessive R&D expenditures. Integrated Product Development (IPD) offers a proven solution to these repetitive development investments: Common Building Blocks (CBB). IPD emphasizes platform-based asynchronous development and reuse strategies, with the core objective of promoting the sharing of mature modules across different projects and product lines, thereby fundamentally addressing redundant development.

1. Understanding CBB

CBB, or Common Building Blocks, serves as the core enabler for platform-based development within the IPD framework. Essentially, an enterprise first establishes a universal technical platform. Based on prior project and product experience, reusable foundational modules are developed on this platform. These modules are then combined like building blocks according to specific product requirements. For instance, in telecommunication equipment platform development, teams typically create universal signal processing modules and power management modules. These components undergo multiple rounds of testing and verification, ensuring stable performance and standardized interfaces. When developing different types of equipment—whether wide-coverage macro base stations or indoor micro base stations—teams need not redesign core modules. Instead, they utilize existing CBBs and make localized functional adjustments for specific scenarios. The essence of the CBB model lies in transforming one-time development into multiple reuses, thereby reducing R&D costs.


Based on scope and structure, CBB can be categorized into three levels:

  • CBB Modules: The most fundamental reuse units, such as shared components, single units, or systems. CBB Platforms: Integrated platforms formed by combining multiple CBB modules.
  • CBB Repository: A resource library where CBB modules and platforms are hierarchically organized for efficient retrieval and invocation.
  • Consequently, by building product development upon verified and mature CBBs, teams can more effectively control costs, ensure quality, and maintain project progress.

2. Implementing CBB

There are generally two approaches to implementing CBB: first, accumulating reusable CBB modules through multiple prior projects or products; second, proactively developing CBB through product or technology roadmap planning. Regardless of the approach, the following four core steps must be followed:

2.1 Requirements Planning: Defining Priorities

The core objective of this phase is to identify common requirements across all product lines. For example, charging management modules needed for mobile phones, tablets, and laptops; sensor data acquisition modules required for smartwatches and fitness trackers; or signal amplification modules used across different router models. These recurring demands represent the primary sources for CBB.


If mature or easily adaptable modules already exist from previous projects or product lines, enterprises should standardize these common modules into CBBs. These standardized components are then stored in a unified module repository with clearly documented technical parameters, interface standards, test reports, and other relevant information to facilitate future reuse.


For new projects, teams should first consult the module repository. If suitable CBBs are available, they can be directly utilized or slightly modified to meet specific requirements. New module development should be initiated only when no existing CBB adequately addresses the project needs. Similar to standard IPD practices, CBB requirements planning requires collaboration between the Integrated Portfolio Management Team (IPMT) and the Portfolio Management Team (PMT). These teams jointly determine CBB development priorities based on market demands and product line planning, ensuring strategic allocation of resources to high-value CBBs.

2.2 Standardized Development: Ensuring Reusability

During the development process, the Technology Development Team (TDT) must strictly adhere to enterprise-wide standards. These requirements include ensuring interface compatibility with existing product platforms, conducting comprehensive testing covering extreme temperatures, vibration, and electromagnetic compatibility scenarios, and following specified documentation formats and version naming conventions. The primary objective of these standardized requirements is to guarantee that CBBs can be seamlessly reused across different projects and teams.

2.3 Review and Repository Inclusion: Dual Quality Assurance

Similar to the IPD product development process, CBB development requires both decision and technical reviews:

  • Technical Review: Conducted by senior technical teams, focusing on CBB performance, compatibility, and stability.
  • Business Review: Involving procurement, production, and marketing teams to evaluate cost efficiency, procurement cost reduction potential, and alignment with customer requirements.

2.4 Reuse and Iteration: Continuous Optimization

During subsequent utilization of CBBs, any issues and improvement suggestions must be systematically documented. The TDT team regularly consolidates this feedback and conducts version iterations, thereby establishing a closed-loop process of "reuse-feedback-iteration" to ensure CBBs continuously evolve to meet business needs.


The practical value of CBB is clearly demonstrated by benchmark enterprises that have implemented IPD. For instance, when IBM adopted IPD, it faced significant proliferation of PC components: 14 types of chassis, 15 types of motherboards, and over 20 types of hard drives. Different project teams designed their own components, resulting in sluggish supply chain response. Through CBB implementation, IBM successfully streamlined its components to 4 chassis types, 4 motherboard types, and 6 hard drive types. This consolidation not only reduced procurement costs but also significantly improved inventory turnover efficiency.


Whether examining IBM's experience or other enterprises' practices, the CBB strategy effectively transforms organizations from pursuing short-term deliverables to accumulating long-term assets. This approach ensures that each module development paves the way for subsequent projects, enabling every R&D investment to generate compound returns.

Write a Comment
Comment will be posted after it is reviewed.