Kanban In Volvo Prototype Development: A Practical Case Study

Prototype development sits between engineering design and industrial production. Ideas are still changing, parts may be one-off items, and testing can expose problems that send work back to an earlier stage. In that environment, a conventional project plan can quickly become outdated. Kanban offers a different way to coordinate work by making tasks visible, limiting unfinished activity and allowing teams to adjust priorities as evidence emerges.

Volvo’s use of visual planning in prototype development provides a useful example of how lean principles can support complex product work. The case is especially relevant to Australian manufacturers, engineering firms and technology suppliers, where specialist teams are often spread across Melbourne, Geelong, Adelaide, Brisbane and regional sites. The central lesson is that Kanban is not simply a board with coloured cards. It is a management system for controlling flow, exposing bottlenecks and improving decisions.

Why Prototype Work Needs A Different Operating Model

Prototype programmes are unlike repetitive production lines. A production process aims to repeat a stable sequence at a predictable rate. Prototype work aims to learn. Engineers may need to design a component, order an unusual material, build a trial part, test it, analyse the result and revise the design. Each activity can change the next one, so the original schedule has a limited shelf life.

This uncertainty creates several common problems. A team can begin too many engineering tasks at once, specialist equipment can become overloaded, and urgent requests can interrupt work already under way. A component may appear complete on a project tracker while waiting for inspection, software integration or a decision from another department. Kanban makes these hidden queues easier to see by representing work as a sequence of states rather than as a list of optimistic completion dates.

For Volvo, the value of this approach lies in coordinating design, prototype manufacture, testing and management review. A visual workflow can show whether work is waiting for a supplier, blocked by a technical question or ready for the next operation. That visibility supports a more realistic conversation about capacity. Instead of asking why every task is not finished, the team can ask where work is accumulating and what constraint is preventing movement.

How The Volvo Kanban Flow Was Organised

A Kanban system normally begins with a board that reflects the actual stages of work. In a prototype setting, those stages might include requested, clarified, designed, ready for fabrication, being built, awaiting test, under evaluation and completed. The exact labels matter less than their relationship to real work. If a column does not represent a meaningful handover or decision, it adds decoration rather than control.

Each work item carries information needed for a decision: the component or test involved, its responsible person, its priority, required date, dependencies and current blocker. The team can then see the difference between active work and waiting work. A card in “design” represents effort being performed; a card in “awaiting test” represents a queue that may require test-lab capacity. This distinction is important because queues are often treated as progress when they are actually delayed demand.

Work-in-progress limits are the main control mechanism. A limit on the design or fabrication stage prevents the team from starting another job simply because a new request has arrived. When the limit is reached, people must help complete existing work, remove a blocker or clarify requirements. This changes behaviour from “keep everyone busy” to “finish the most valuable work and protect flow”.

The approach also supports pull planning. Downstream capacity signals when it is ready to accept another item, rather than upstream staff pushing more work into an already crowded process. In a vehicle development environment, that can reduce the number of unfinished parts competing for the same machining, assembly or testing resources. It also gives project leaders a clearer view of whether a delay is caused by engineering complexity, material availability or a shared facility.

Connecting Visual Planning With Enterprise Systems

A physical board can be useful in a workshop, but prototype programmes often involve people in several locations and systems. Engineering change records may sit in a product lifecycle management platform, purchase orders in an enterprise resource planning system and test results in specialist software. A Kanban view becomes more powerful when it connects these sources without attempting to replace every system already in use.

The research presented through the Celean research site is relevant here because it examines digital visual planning, Kanban, enterprise systems and lean project management. The important design question is not whether every database should be copied onto a board. It is how a visual layer can present the information people need to make timely decisions while preserving the authoritative records in existing applications.

For example, a Kanban card might link to a controlled drawing, a purchase order or a test report. A change in the enterprise system could update the visual status, while a team member could record a blocker or priority decision in the planning tool. Clear ownership of data is essential. If a dashboard says that a part is ready but the approved drawing has not been released, the visual system creates false confidence rather than transparency.

Digital planning also makes work patterns measurable. Teams can examine lead time, queue time, blocked time, throughput and the age of unfinished items. These measures should be used to understand the system, not to rank individuals. A long lead time may indicate unstable requirements or a shortage of test equipment. Treating it as an individual performance failure would hide the underlying cause and encourage people to manipulate status information.

What The Case Reveals About Collaboration

Kanban changes meetings as much as it changes boards. A useful review begins with work that is closest to completion or has been blocked longest. Participants discuss what is needed to move those items forward, who owns the next action and whether the priority still makes sense. This is more focused than asking each person to deliver a general status report.

The method also creates a shared language across disciplines. A design engineer, buyer, prototype technician and test specialist may use different professional terms, but they can all discuss a card that is waiting for a drawing, a part or a test result. That common view reduces the risk of local optimisation, where each department appears productive while the overall prototype remains unfinished.

Supplier relationships are particularly important in automotive development. A prototype part may involve a specialist foundry, fabricator, electronics supplier or software contractor. If the external dependency is visible, the team can distinguish a supplier delay from an internal engineering delay and act earlier. This does not remove commercial or technical risk, yet it prevents a critical request from disappearing inside an email chain.

The lesson translates well to Australia, where supply chains may span Sydney, Melbourne, Adelaide and overseas factories, with long freight distances between metropolitan and regional operations. A team in Geelong or western Melbourne may need to coordinate with a niche supplier in South Australia or Queensland, and a missed dispatch can consume several working days. Visualising the dependency helps planners account for freight, customs, local public holidays and limited specialist capacity rather than assuming every supplier behaves like a nearby production cell.

Adapting The Method To Australian Conditions

Australian organisations should avoid copying a Scandinavian or European implementation without considering local operating conditions. The domestic automotive market is smaller than Europe’s, while many products and components are imported. Right-hand-drive requirements, Australian Design Rules, certification work and low-volume variants can create extra engineering activity even when the global vehicle architecture is shared.

A Kanban system can accommodate these realities by separating standard work from local obligations. A prototype item might need a compliance check, a local road test or validation for heat, dust and road conditions before it can proceed. In places such as central Queensland or Western Australia, environmental conditions and travel distances may affect test planning. The board should show those activities as real work, not as invisible administration that sits outside the engineering schedule.

Communication style matters as well. Australian teams often value direct, practical conversations and may use informal language in the workshop or during an “arvo” planning session. That informality can support fast problem-solving, but it should not replace clear records. A short note such as “waiting on the revised bracket” is useful only if the responsible person, expected date and next escalation are also visible.

The same principle applies to dispersed operations. A supplier near Port Melbourne, an engineering office in Melbourne’s inner suburbs and a testing site outside the city may work to different rhythms. Shift handovers, time spent travelling and contractor availability can all affect flow. Kanban does not make those constraints disappear; it makes them discussable, allowing the team to plan around them instead of treating every delay as an unexpected exception.

Measuring Improvement Without Losing The Purpose

The strongest performance measures for prototype Kanban concern flow and learning. Lead time shows how long an item takes from commitment to completion. Cycle time focuses on the period when the team is actively working on it. Work-in-progress reveals how much unfinished demand the system is carrying, while throughput indicates how many items reach a defined completion point in a given period.

Blocked-time analysis can be particularly valuable. If many items wait for design approval, the issue may be unclear decision rights. If work accumulates before testing, the organisation may need more test capacity or better booking rules. If procurement dominates the lead time, standard materials, supplier agreements or earlier technical clarification may help. Each pattern suggests a different response, which is why a single delivery percentage rarely explains enough.

Quality measures must sit alongside speed. A prototype that moves quickly but requires repeated rework has not produced a genuine improvement. Useful indicators can include first-pass acceptance, the number of engineering changes after release, test failures caused by incomplete requirements and the proportion of urgent work that interrupts planned items. These measures connect visual management with product-development outcomes.

The review cycle should remain experimental. Teams can change a work-in-progress limit, alter a workflow state or introduce a clearer definition of ready, then observe the effect. This is consistent with lean thinking: improvement comes from making the process visible, forming a practical hypothesis and checking what happens. The board is therefore a control surface for the development system, not a monument to a fixed process.

Volvo’s example shows why this distinction matters. Kanban does not remove uncertainty from prototype development, and it cannot guarantee that a design will pass its first test. It can reveal uncertainty sooner, prevent excessive parallel work and make responsibility for the next decision clearer. Those benefits are valuable when engineering, manufacturing and suppliers must coordinate under changing requirements.

For Australian readers, the broader message is practical. A small workshop in Dandenong, an advanced manufacturer in Adelaide or a mining-equipment design team in Perth can use the same principles, provided the workflow reflects its actual work. The method should account for supplier geography, regulatory checks, climate-related testing, imported components and the realities of a smaller local market.

What the reader should remember is that Kanban succeeds when it controls flow rather than merely displaying tasks. In prototype development, a visible queue, a sensible work-in-progress limit and an honest record of blockers can turn scattered activity into coordinated learning. The board is only the visible part; the real improvement comes from using it to make better decisions about what starts, what stops and what must move next.