Created on 2017-12-19 10:45
Published on 2017-12-19 12:46
Every organization makes something. It might be a physical product, or a service, or an experience. Do you what you make? If you make just one thing, this is easy, but if you produce variants, then you need a common way to measure them together in equivalent units (EQUs). For example, if you weight the value of large/complex and small/simple things to medium/average units, then you can express all your varied products in medium/average units.
Large functions can be measured with EQUs. For example, manufacturing EQUs can count final assemblies and possibly sub-systems. Engineering EQUs can count designs on a common scale. Sales could be measured on orders, scaled by size and so on.
This is number 6 in a series of articles about applying continuous improvement processes to measure and improve the performance of product development projects.
All of the previous articles show what we can do with Hours, EQUs, and Costs. Here, we will go one step further and compare additional dimensions to analyze productivity boosters, challenge cost-savings myths, and balance resources more effectively. The following are true stories.
During a visit to Shanghai, my good friend and engineering director, Xu, complained about losing employees. He had a great process to hire engineers from university and train & develop them for hands-on work. But after a couple years, many engineers did not get expected salary increases and left to work for our competitors.
So I asked Xu, how much is experience worth? We agreed it was very valuable, but we needed a clear price to get management’s attention. His Black Belts were brought in to analyze the value of experience. We developed a scale to combine the experience level of team members and the time they spent on each project to calculate Project Average Experience values. We plotted this against the Hours per EQU (productivity) on each project. The chart below shows some stunning results.
The correlation was 83%, so the blue line accurately represents the data. It shows we spent 28,000 hours per EQU with 3 years of Program Average Experience, but with 6 years, we spent 10,000 Hours per EQU. That’s a 180% improvement on Productivity for just 3 additional years of team experience.
Next, we examined the cost of Experience. The chart shows that 3 years cost 175 RMB per hour and 6 years cost about 220 RMB. That’s a cost increase of just 26% with a 68% correlation.
We showed a productivity improvement of 180% for a cost increase of 26%. This was a big opportunity for a technical center with over 600 Engineers. Management saw the value and took actions including: salary increases; hiring experienced engineers instead of new graduates; improving career development paths; and increased management engagement with employees. They went on to become one of the Top Employers in China.
Anyone can calculate the difference between two labor rates and claim a cost reduction, but when you ask them how it affects output, they get really quiet.
We formed a joint-venture in India to do engineering work, expecting costs to go down dramatically. Management was relentless about adding resources there to justify the investment. There were issues with the efficiency and effectiveness of sharing work this way, but no one could express them in financial terms. Management's response was, "Don't you understand the cost savings? We have to do this!"
On the other side, our JV partner was running this as a business and they wanted to increase profits. They did everything possible to increase billable hours and contain costs without considering productivity. In fact, productivity was an enemy because it reduced billable hours! The JV hired engineers directly from university and never gave them a salary increase. This kept costs and experience low. Experienced, productive people left for better jobs and were replaced with new university graduates. Does this sound familiar? It was so bad that 2 or even 3 engineers would share an slow, cheap CAD workstation and this really slowed them down (more billable hours). Every day, they needed to send large CAD files back and forth to the USA, but they saved money by using slow internet connections (more billable hours). Additionally, the engineers never saw their physical products, never watched a test or visited a plant.
We compared the % of low-cost country hours per project with the Labor Cost per EQU and found no correlation in 7 years of data! There was no data to show off-shoring was saving money. In the chart below, Excel automatically draws a trend line, but the R2 value is 0, meaning there is no correlation between offshore % and Labor Cost/EQU. No evidence of savings.
Also, we didn’t see a big reduction in overall labor rate. The trend line is misleading because R2 is only 22%. There was a heavy reliance on on-site coordinators with rates similar to the USA. This added non-productive hours at high rates.
Management responded with a sliding scale to pay more for more experienced employees. This may have helped, but the incentive was still there to increase billable hours with no regard for Productivity. Teams still complained about communication issues and re-work. We ended up buying out our JV partner and running the operation with an experienced Engineering Director who took an expat assignment in India. Only then, did we start to see 'savings'.
The problems above were not caused by the abilities or motivations of Indian people. I have been there 30 times in 25 years and I have good friends there. They are very intelligent, well educated, highly motivated and a joy to work with. The problems were in the process and management owns the process (Thank you, Deming). Work can be shared across countries effectively and efficiently, but it requires lots of planning, cooperation, monitoring, adjustments, and some relocations.
Workload increased dramatically in Europe and we needed to hire 400 Engineers. At the same time, workload decreased in North America and we need to reduce by 200 Engineers. This would be very expensive and productivity would suffer with new engineers.
A long-term analysis of workload in EQUs showed both situations existed only in FY 10 and would return to ‘normal’ the following year. EU went from 21 EQUs in FY09 to 68 in FY10 to 30 in FY11. NA went from 36 in FY08 to 20 in FY10, but back up to 30 in FY11.
In the end, we shifted work from EU to NA, moved a few people from NA to EU and increased Engineers in lndia. This avoided the high cost of hiring, then firing 400 Engineers in EU. It also boosted our headcount in India per our long term plan. We turned the crisis into a win-win-win!
Measuring engineering productivity opens up new possibilities for making better strategic decisions. This is one more reason to start the process in your organization.
Please connect with me if you'd like more information at: firstname.lastname@example.org
Go to the top of the page to Share, Comment, or Like if you found this interesting.
This is part of a series of articles about applying continuous improvement processes to measure and improve the performance of product development projects. Here is the complete list in recommended reading order.
Copyright 2018 Richard Crayne