Productivity vs Throughput

Lionel Grealou Manufacturing, Operations Leave a Comment


Discussions about Engineering & Design (E&D) Return on Investment (RoI) among manufacturing industry executives often turn to engineering productivity. A far more important metric is perhaps engineering throughput combined with cycle time or number of iterations per cycle. 

Productivity is defined as output per unit of input (productivity = output / input).

Productivity focuses on quantity produced, created, or completed. It is a measure of productive capacity of a machine, factory, industry, company, a team or an individual. In agile terms, productivity might not be too meaningful as it makes little sense to measure the number of features per person or per team over time (other than in a context of people or team performance assessment). Productivity is about cost and is linked to efficiency, but is not the same. Efficiency measures the amount of work done, regardless of how much completed product there is – it’s process-oriented.

Throughput is the rate of production or the rate at which something can be processed (throughput = output / duration).

Throughput is a measure of comparative effectiveness of a process or an operation, e.g. a count of items completed per month. It represents the rate of output and therefore quantifies how fast products are developed. In agile terms (iterations), throughput is the number of features through the team over time. In Kanban terms, throughput is what matters over productivity. Unlike productivity, throughput ignores the amount of manpower the team expends to create that output. It simply quantifies the output and divides it by the project’s duration. Throughput is about cycle time (concept to release-to-production), measuring output per unit of time.  

Cycle time is the count of working days between work starting (‘ in progress‘) and completion (‘ done‘) and is shown per item over time (cycle time = output per cycle / throughput).

To be truly useful cycle time has to measure the time it takes for activities to really be completed against a unit of measure that matters for the business, e.g. a New Product Development / Introduction (NPDI). It is also very simple to measure, e.g. tracking when the work starts and when it ends. Typically, a piece of work starts when it is taken off the top of the queue and done when it is been released to production (and verified).

Manufacturing organizations can increase throughput on their Engineering projects in five ways:

  1. By increasing the number of hours in the standard work week: not particularly popular option and overtime can only be a temporary option.
  2. By increasing staffing level, providing added manpower: accessing global talents, providing bandwidth to leverage skills in the supply chain, etc.
  3. By outsourcing Essential Non Value-Add (ENVA) activities that consume project resources, thereby increasing engineering resource utilization: leading to cost reduction, and focusing on value-added activities and innovation, e.g. using an Offshore Dedicated Engineering Centre (ODEC) model.
  4. By improving productivity, improving the resource / process efficiency: working smarter, removing Non Value-Add (NVA) activities, leverage tools and technology to enable, which means executing tasks more efficiently and therefore expending less effort. Product Life-cycle Management (PLM) solutions enable required continuous improvements and changes in people, processes and technologies.
  5. By outsourcing deliverables and transferring risk and ownership: in the form of partial or full product development projects, providing further opportunities for open innovations and cost efficiency.

The first two rarely yield competitive advantage. That’s because nearly all manufacturing organizations pursue them (to survive), enabling them only to keep pace with the industry norm. Increasing staffing level potentially means taking on fewer projects, which can also be quite contentious and riddled with politics.

The last three are opportunities for differentiation and competitive advantage. Embarking on this journey of change might require wider business transformation. Most companies are reluctant to pursue these insidious root causes of low throughput. That’s because eliminating NVA tasks can be contentious and politically unpopular; nobody likes to hear that their job has ‘little‘ value-add or that they have to change. In addition, there is a (perhaps misleading?) perception that PLM implementations are complex, costly and do not always realize the expected benefits from their initial business case.

What are your thoughts?


This post was originally published on LinkedIn on 11 May 2015.