by Ian Quest, QR_ director of consulting

Where there’s muck there’s brass

I was brought up in Yorkshire, where, amongst many other brilliant colloquialisms, I learned the phrase ‘where there’s muck there’s brass’. In other words, if you’re willing to do the unpleasant things others aren’t, you’ll do well.

For me, this phrase applies to many of the activities ensuring engineering programmes have complete, clean and current data to build on. A few apparently mundane and unglamorous activities, when done rigorously, hold the key to significantly accelerating and de-risking a programmes and unlocking the real potential of your engineers and creatives.

How are you measuring your data quality?

Without the hard and detailed facts about data quality, it’s easy to be optimistic about programme status. Add to this everyone’s desire to avoid being the one to cause a delay, and you find people keeping their heads down to see if someone else breaks first, further muddying perceptions with optimism and ‘greenwashing’. Given this, it shouldn’t be surprising that when a thorough audit of product and programme data is carried out, it reveals many ills. What is surprising is the level of issues normally found and the apparently mundane nature of many of them.

Typically, 20-30% of parts have errors at point of order

In a sample from across a number of both large and small automotive OEMs, we found that on average, at the planned ordering point for parts for prototypes or early vehicles, 20-30% of the parts have data errors or omissions, most of which will impact their on-time delivery.

To be clear, this isn’t that engineering work hasn’t been completed or there are unresolved technical issues. Instead, this is necessary product and programme data which is either absent or does not reflect the engineering and/or business intent. In a BoM of 2,000 parts, this means 400-600 parts with errors, many of which will result in late or non-available parts to build.

The secret weapon

Although the statistics vary by OEM and by programme - and of course there are good examples - the opportunity here is large. It is possible to reduce programme duration (or over-runs) by weeks and months and without vast expenditure. But whilst it sounds like a mundane, easy admin task, it requires commitment with focused and determined leadership, professional execution in both a technical and interpersonal sense and a structured and comprehensive methodology.

How do you know how thorough your data validation is?

One of the big challenges is that the real value in validation exercises is in the rigour that’s applied, not just the fact of ‘having done a check’. Spotting missing data is fairly easy, checking latest drawing revisions also not tricky, but confirming applicability, prototype strategy and finding overlooked items which don’t yet exist in the Bill of Materials are examples of the many things which require more rigour, more understanding and face to face conversations to properly verify. Beware of the tick box exercise: having few errors and finding few errors look very similar but have very different outcomes.

The Wholesale Clean-up

It would suit everyone if, like Hercules in the Augean stables, we could simply divert the river and cleanse the data wholesale. There’s often a sense that the data quality issue is so big that specific actions won’t really help and that a big system or process change is needed to fix it. It’s collectively convenient for us to think this way, absolving ourselves of the individual responsibility to nail down the details. This may be at the root of why the problem exists on such a scale.

Millions have been spent trying to fix this with the majority of the spend in two areas; system upgrades and administrative support. Both of these are ‘big’ solutions which, from a birds eye view, look appropriate for such a big and widespread issue.

In truth this problem, which exists in the detail, must be tackled in the detail to have any real and lasting impact. We have seen many different error types, each of which has multiple causes and only some of which are materially affected by a system update or change to someone’s R&Rs.

Building Solid Data Foundations

In order to tackle this issue, there are a few changes in mindset which need to take place and some re-directing of effort.

1. Understand and believe in the power of good data. Unless you believe it is important, you won’t convince anyone else. You need to experience what happens when you have good data vs bad. Try offering the best possible support to one function group and see how they fare versus the others. Do some detailed analysis on a selection of the parts which were late to build and map how better, more visible data might have changed your trajectory
2. Measure Data Quality and add it to page 1 of your dashboards. Very few organisations do this well and are left either drawing conclusions from information of unknown quality or simply not trusting the data and are left guessing. As an analogy, you need to know the cut, colour and clarity of your diamond, not just the carats.
3. Set your target level of data quality based on the true costs and benefits. Once you understand data quality and its consequences, set targets on quality and track it as you go, ensuring it remains at an acceptable (and trustable) level and applying increased efforts whenever it isn’t.
4. Simplify and automate. There are many tools and processes which will help make this process faster and more effective. Routines, automated comparisons, regular dip-checks and the ability to home in on the areas most likely to have issues will all make the process easier. Just beware dumbing it down too much. Once it’s a mindless routine, you risk the ‘impartial, intelligent eyeballs’ failing to catch the big non-routine mistakes.

Foundations for the future

Getting your data right is not just a significant opportunity for better programme performance, but a crucial foundation for the development of future processes, better reporting and improved collaboration.

I’ve been asked a few times recently how programmes can be managed in a more agile way; an important question with so many major technological challenges requiring solutions quickly. The full answer is a long one with a number of options and nuances, but one thing is absolutely sure: you will never be able to be agile if you don’t have up to date data you can trust.