The epiphany of integration points is that they control product development and are the leverage points to improve the system. When timing of integration points slips, the project is in trouble.

—Dantar P. Oosterwal

Principle #4 – Build incrementally with fast, integrated learning cycles

In traditional, phase-gated development, investment costs begin immediately and accumulate until a Solution is delivered. Often, little to no actual value is provided before all of the committed Features are available or the program runs out of time or money. During development, it’s difficult to get any meaningful feedback, because the process just isn’t designed for it. What’s more, the development process itself isn’t set up or implemented to allow incremental capabilities to be evaluated by the customer. As a result, the risk remains in the program until the deadline, and even into deployment and after initial use.

No wonder the process is error-prone and problematic, often resulting in loss of trust with the customer. Attempting to adjust for this, both parties try even harder to define the requirements and select the best design up-front. They also typically implement even more rigorous phase gates. Each of these remedies, unfortunately, actually compounds the underlying problem. This is a systems-level problem in the development process: it must be addressed systemically.

Integration Points Create Knowledge from Uncertainty

Lean principles and practices approach the problem differently. Rather than pick a single requirements-and-design choice early on—assuming that it’s feasible and will provide fitness for purpose—a range of requirements and design options (Principle #3) are considered while building the solution incrementally in a series of short timeboxes. Each results in an increment of a working system that can be evaluated. Subsequent timeboxes build on the previous increments, and the solution evolves until it’s released. The knowledge gained from integration points is not solely to establish technical viability. Many integration points can also serve as minimum viable solutions or prototypes for testing the market, validating usability, and gaining objective customer feedback. Where necessary, these fast feedback points allow teams to pivot to an alternate course of action, one that should better serve the needs of the intended customers.

Integration Points Occur by Intent

The development process and the solution architecture are designed, in part, to focus on cadence-based integration points. Each point creates a ‘pull event’ that pulls the various solution elements into an integrated whole, even though it addresses only a portion of the system intent. Integration points pull the stakeholders together as well, creating a routine synchronization that helps assure that the evolving solution addresses the real and current business needs, as opposed to the assumptions established at the beginning. Each integration point delivers its value by converting uncertainty into knowledge:

• Knowledge of the technical feasibility of the current design choice
• Knowledge of the potential sustainability of the solution, based on objective measures (Principle #5)

Faster Learning through Faster Cycles

Integration points are an example of Shewhart’s plan-do-check-adjust cycle and are the mechanism for controlling the variability of solution development [3].

The more frequent the points, the faster the learning. In complex systems development, local integration points are used to assure that each system element or capability is meeting its responsibilities to contribute to the overall Solution Intent. These local points must then be integrated at the next higher system level. The larger the system, the more such integration levels exist. Solution designers recognize that the top-level, least-frequent integration point provides the only true measure of system progress, and they work to create these points as frequently as possible. All stakeholders understand that when the timing of integration points slips, the project is in trouble. But even then, this knowledge helps spark the necessary adjustments to scope, technical approach, cost, or the delivery timing needed to redirect the project to meet revised expectations.

Learn More

Last update: 10 February 2021