Anyone who knows me knows that I tend to only think in terms of cars. I can remember the car someone pulled up in at a party four years ago, but will have no recollection of what their name was. Moreso, I view culture, politics and economics through a sort of automotive anthropologist lens. For example, darker colors are more popular in luxury car sales when an economic downturn has occurred and major shifts in industrial focus will be reflected in increased offerings of economy cars that can hold 4 to 5 people. I think you can see what the problem is here.
In any case, I came up with a cooking analogy (in no way automotive related) for a principal of data organization and I have to say, it’s actually pretty good! So, I am documenting it here.
Working with a team on a new Reliability Growth (RG) program, we realized our greatest challenge was going to be how to leverage all the data sources we had available. Usually, RG programs are data starved,but this was certainly not the case in this instance. Needless to say, the task became overwhelming very quickly. There was system test data in-house, sub-assembly test data, customer field data, field trial data, R&D test data, and then of course the data we would create in the RG test program.
The team quickly got to work cataloguing where all the data was coming from, trying to understand how to filter each set, integrating it, translating it into our metrics and then…. Each team member hashed out different strategies and dove into the challenges for each stage. Do we use R&D data that is in early sub-assy growth? Those designs are changing weekly, so how should we sort them? How do we define use cases for data sets that are from the field if we can’t find anyone who can tell us what was going on when it was in use?
I contributed a few points to some of these challenges based on how I have incorporated data in the past. However, I started to feel overwhelmed, it all felt wrong. The discussion seemed a bit, I don’t know, pointless? Why pointless, you might ask? Because it didn’t seem like it would ever reach a definitive “end.” I could envision our team exhausting ourselves right out of the gate with this task. There was an endless number of combinations of data that could be filtered in an endless number of ways. In other words, this data integration task was going to take as long as whatever infinity times infinity is and we were launching the product in just 26 months. Our RG program was already over schedule by infinity on our second day.
I thought to myself “This is like making dinner based on a strategy of maximizing usage of all the ingredients you can find in the kitchen”. What’s that going to taste like? Ok everyone here is the onion, mango, milk, coffee, garlic, oat, flour, green peas, carrots, butter, soy sauce and peanut butter stew I made. Sorry, it’s in a 5-gallon bucket that is the only way I could fit it all in.
If you want a specific outcome, where do you start? A recipe. The recipe then dictates the ingredients and how to integrate them. In this case, we were doing our RG data management backwards, and it was going to be 5 gallons of “No thanks, I had a big lunch so I’m just good with the water.” However, for us, this would mean the program leaders and engineers passing on any guidance from the RG team. Soon to be followed by a new program where RG isn’t even included.
So, I interrupted the team’s strategizing and made a big announcement. I said, “I have an analogy for how we should do this and no it’s got nothing to do with cars.” There was some disbelief.
“We’re doing it backwards”, I said, “I can see we all already look a little exhausted with this task, and we only just started. We need to flip this around. We are letting the data dictate what we are doing when we really need to start with what we want to get from RG in terms of output. The best outputs will change throughout the program, but those should always dictate what we do with the data.” Then I delivered my cooking analogy. “Don’t just use all the ingredients”, I said, “start with a recipe… developing a new test (dat aset) is akin to going to the store for ingredients we don’t have…”, on and on. I was really impressed with myself. Didn’t mention a car once, not even a food truck.
To some degree, this isn’t really that different from many of my other preachings on deciding what to do. Adam’s “I” word has always been “Intent.” Like I’ve said a million times, “Don’t ever take part in a program activity that you can’t explain the intent of.” In this case, we needed to keep the intent of RG in focus, “measurement and systematic improvement of a key parameter” at all times because there was so much being thrown at us.
Can you list any initiatives in your program that are being directed by the ingredients and not by what is really needed?
At your next team meeting, try doing a quick exercise and have your team list the intent of some top initiatives. Then evaluate them together. Are your activities serving these intents or are they driven by old habits, available inputs, or un-challenged constraints?
I’d love to hear of any experiences with this so feel free to reach out.
-Adam
Leave a Reply