I had a chance to chat with my friend and former colleague Bob Valascho, a product specialist for CHS until his retirement a couple of months ago. He had a distinguished and productive career with full service suppliers, original equipment makers and software organizations after military service. Bob travelled extensively around the world in his career, but lived all the while in Michigan.
Bob was occupying senior managerial positions, influencing the direction of product development long before it was my privilege to work with him. I wanted to take the opportunity to ask him a few things about his career now he can see it in retrospect, and invite him to contribute to the blog.
What systems engineering did for the design of electrical distribution systems was the theme that emerged. However, Bob was as usual very generous with his insight, and insightful with his usual generosity. Notes from that conversation follow. The questions are mine and mostly brief and in italics or paragraph/section headings, the answers come from Bob and are very interesting.
Thanks for the wisdom.
Bad Process + Bad Software = Awful Result
Bad Process + Good Software = Bad Result
Good Process + Bad Software = Bad Result
Good Process + Good Software = Now that is what he was talking about!
The hit or myth of automation in Electrical Design Software (EDS) – what makes for win or lose implementing new tools?
What differentiates hits from a miss? For technical software used in the design of electrical distribution systems the key factor seems to be how the organization adopting the software organizes itself. That may seem a curious thing to say, but let’s look at it right from the beginning.
When a company is looking for software to help them design electrical distribution systems for their products, or to put in products that they are helping an OEM design, two things have to be in place for them to get a significant improvement on how they do business now. First, when they see the software, they have to get this idea that a big step forward is possible. And of course second, when they come to use it and look to make that “wow factor” a new reality for themselves, it has to still be there and realizable.
So why do I make this distinction, because I have seen how companies looking for improvements see things, software demonstrations and the like, which gave people the impression that not just an evolution in their processes was possible by a refresh of their tools, specifically their software tools, but that a revolution was achievable. What it takes to get the benefit, if it is really there to be had, is patient and skillful implementation. That’s more difficult.
“What about the people that produce the software? How do they contribute to a hit or a miss?“
Basically I’ve seen mistakes come from two angles. First software companies, well not necessarily just companies, IT departments and individual people with programming expertise fall into this fault too. There is the error of presuming that you “get it” where nobody else has. That’s the mistake of assuming that you have seen a niche, or an opportunity that has been missed by the rest of the people active in this field in the world. And coming along with that mistake is going to be the assumption that you know best. So you would think from this first angle or mistake, that the remedy is to get yourself some people who will sponsor your activity to produce software to do good electrical distribution design.
But it might come as a surprise that I think the second mistake people make is to rely too much on the people who are purchasing. There’s actually quite a dangerous bias can come into the functionality because of the power of the main sponsor, and that can take it away from an area where it has the most general appeal, or have the most radical effects on what people are doing. So I’m saying it’s possible but difficult.
The software itself can turn out a little peculiar thanks to the customers with the deepest pockets and most funding. They are driving the market for your product, but it is the by no means certain that they are putting the best practices for the future into the software systems. They think they are putting the best practices for their future into those systems, and even then you can be wrong you know your company and not necessarily the whole industry.
I do believe that the best inspiration to succeed is going to come from a person, not from a group. And to say that probably implies to you that I’m talking about something people refer to these days as a visionary. In fact I was thinking of someone who contains elements of the visionary, but an individual displaying something, uhh something more pedantic. Someone who starts out looking at problems in engineering with this statement “there must be something better, and once we find it how do we get there?” What really is crucial is the second part, being aware right from the start of how to get to do something better. I suppose I’d call that being a practical visionary.
A rarity then?
Yes, I suppose I’m saying that there is a low probability of complete success – the sort that makes the executives of an adopting company take notice that they have a massive success on their hands - which seldom happens the way many people start out upgrading their technology. It is rare to find the combination I think you need to do the job really well. You need a leader with the practical skills and inclination to go forward and with enough immersion in the detail.
In my time in EDS however I have seen the progression from using so little automation to the adoption of new tools, particularly software tools, I have seen things which have been revolutionary. But it is my view that the take-up of new processes have been the most revolutionary things I have seen. Systems engineering as a process has helped enormously handle the different interactions of vehicles and also enabled engineers to go with the increasing complexity of vehicles and not be swamped. Systems engineering, the process and the discipline, that has been at the core of the revolutionary changes over the last twenty or twenty-five years in automotive, and in other transportation fields as well.
Revolutionary improvements can happen. But when you set out, set out being prepared to learn from the failures. Co-opt the lessons you learn straight away. Don’t think you will hit a home run. Define the steps, go in increments and be deterministic in your project.
Your retirement from a fairly small group of subject matter experts is going to be keenly felt. And in ways we can see now, and probably in some ways we cannot see now but will emerge over the next 2-3 years – what do you think of the perennial problem of companies & engineers keeping and retaining a corporate store of knowledge? Is it easier now with knowledge-based engineering tools, databases and automation of process?
Yes it is a problem, and it is a problem to which there is no easy answer. Perhaps at the start of my career of the problem was expressed as how can you promote people, or transfer them onto other projects and not have a detriment to quality. Latterly the debate focuses on the issue of off-shoring engineering, having people in lower labor cost geographies perform work remotely and trimming down, often very dramatically, the number of people in the higher cost locations. People have concentrated on what quality problems can arise as a result of that drift, and that certainly that’s the one problem that has been topical in the USA in the last 10 years.
What I think about this problem, from my perspective which is mostly a North American one of course ….. is that it is fundamentally a discussion about quality. Continuity of individuals makes it easier in this respect: those people retain an understanding of how to execute in their organization. Culturally people in the United States, and this is almost a stereotype, are said to have less discipline but paradoxically they have a reputation for more responsiveness and responsibility. I suppose the short way of expressing it is that an American is less likely to follow a process – is more individualistic rather than group-oriented. Japanese car makers, and again this is almost like a stereotype, seemed to do better at fostering from their cultural background and their organizational precepts a work environment where the daily, weekly, maybe even hourly emphasis is on the conditions that can lead to quality failings. But it’s pretty clear to me that the United States car makers have equaled anyone you care to mention from around the world in their quality improvements. So there are metrics which suggest obviously enough effort that has been put in over the last 10 years at the American car companies, although there are other current difficulties which are well documented, principally financial.
The Peter Principle.
I have seen situations where people get promoted away from the effectiveness. Technical managers become more managers rather than focusing on the technical aspects of the groups they supervise. And an organization’s reliance on quality comes through the discipline of individuals in processes, including managers. So the issue of rank and subordination looms fairly large. Quite often, what I have seen is that the way the company operates it is hard to get the message assertively from down the ranks that quality is wrong. If there is a good process in place, it is also important to have an effective execution of the process. A real life example: there is a design rule that the voltage to the headlamps on vehicles be limited to 11.8V. However , where this basic rule was not followed, the end result was early headlamp failure, which at the least, is annoying, to customers. If there is a process and it is a good one you must follow it.
Away from software what’s been the biggest influence on the path your career took?
I’ve already mention that Systems engineering in automotive has been to my mind the big advance in technology. The people I have worked with and myself have used it to drive the overall design of the products. I’m going to use that word ‘execution’ again, in the context that assembly plants became very active on the following up on build issues, so that design engineers cannot ignore the downstream effects of what they are doing.
What contrasts between Automotive and Aerospace sectors struck you as significant in Electrical Distribution Systems Design?
In aerospace applications of electronic and electrical distribution systems there is quite a difference in terms of the physical implementation which engineers design. You can see this being the complex multicores. Also the cost of parts is insignificant mostly, whereas purchasing concerns at automotive OEMs will fight almost to the death not to spend and extra 50 cents per car. Aerospace has its own complexity challenge, however it is true from what I have seen that there is a distinction between low-volume high cost and high costs low-volume between the two sectors. My experience also has been that there is a big difference in terms of the separation of signals inside the end product. In cars there are fewer critical systems, whereas in Aerospace the critical systems are not limited in number and you cannot avoid them being pretty much anything you do. Your packaging concerns for the electrical distribution in aerospace always have to take account of noisy signals and susceptibility of the system to interference.
Working with CHS in the last years of your career – what was a stand-out aspect of that technically speaking?
Working on CHS gave me a chance to see the realization of a software package scoped from design concept all the way through manufacturing. The reach across the life cycle of the products from front to back is a very attractive one for customers. One of the things I saw was that as you erode your ambition to cover the entire flow you can also lose sight of the fact that you are nibbling away at your effectiveness and contributing over all to getting less value from what you are doing to implement. So deployments I feel really need to be put in the hands of one key person, hmm, no – correction: one key smart person. That key smart person has to be ready, willing, able and available to intervene in all sorts of things. It is very important that the customer has a champion, a project manager call it what you will who is effective in lots of ways and flexible. Otherwise there is a danger of falling short of your ambitions.
Did you invent the generative flow?
That’s an example of an automation derived from the discipline of systems engineering. I would say that I’d played a role in completing the loop. There were plenty of conceptual designers doing work – and I took the paper process and the background for architectural studies and automated it. In the company I was working for I had to go and beg for funding, build up a consensus a group of people who trusted me and I trusted them, and share and develop a vision for what we were doing. So in this company I was working for we were putting together a team of user-definers for the software, and looking on what came to be known as the generative flow as a money maker in terms of saving money. We were not thinking of software development as something particularly revolutionary. In fact we started off with the presumption it was a research and development activity which we would fail at first. We expected it to fail and were prepared to pick up again and do things better second time. We were determined that we would stop and restructure what we were doing, in terms of the data model perhaps, or maybe the infrastructure and rewrite until the thing worked really well.
What has changed and what is the same for wiring/cable/harness engineers’ simulation tasks?
Being a wiring engineer and doing simulations for a lot of companies out there nothing has changed since the early 1980s. At that time the EMC/EMI rules relating to power train in automotive are little changed from how they are now. And I think it is revealing that simulation for voltage drop and surges is still largely done now using spreadsheet as a tool to analyze and simulate. In the last eight to ten years the prospect of using the design environment for analysis has become feasible. There is a good opportunity particularly for car companies in the next few years to really get things going now that the tools fit better in their process. There is generally a big benefit to converting to a more tool based FMEA process. This takes work to get it going, and I saw that OEMs were ready to put the effort towards this end because they could see the savings which will result.
Thanks very much Bob. I found it very interesting talking with you.