Writing a blog about my experiences as a systems engineer? The truth is that the everyday working life that has accompanied me for years is nowhere to be found in the literature, and no one talks about it apart from the generally known descriptions. The knowledge, skills, and methods to get through the working week, month, or year didn’t come with a university master’s degree, to be honest. Of course, as an engineer, you need to know your field and be able to lead a development team or a customer project with your knowledge. But how often do unforeseeable events occur that require a good decision to determine the success or failure of the project goals.
Need an example? I remember one of my first projects in Asia. A meteorological radar system was to be delivered. The customer was a highly respected weather authority with an academic network, whose name I can’t mention here, but it doesn’t matter. What is important is that I quickly realized that we by mistake had overlooked huge developments in the requirements catalogue when we received the order. Six-figure developments – ouch.
Untypical skills lead to success
I quickly realized that what I needed most of all were customer service skills and a clever mind to find solutions. Out with the Matlab scripts and the collection of formulas for solving inhomogeneous differential equations, and in with the negotiation tricks! I quickly realized that I needed a combination of customer-facing skills and a sophisticated approach to problem-solving. So, I invited them to a project meeting. It is important to know not only the issues to be discussed but also the people sitting in front of you. I soon found out that a senior university professor was there. That’s how we came up with the title “Technical Coordination Meeting”. The draft was presented. I spent three days explaining in detail to the client the whole concept of the system they were going to get. I regularly referred to contract items and critical aspects of the requirements catalogue that the customer was generally aware of. Together we “understood” that the contract items were “in conflict” and therefore adjustments had to be made. This opened up a whole new playing field! Trust in the company’s expertise, the product, and the project partners was built up over the first two days. For example, we found out that the customer had the highest requirements for the functional safety of the machines regarding the risk to employees. We were able to completely eliminate a previous five-figure installation package and also a complex in-field directional pattern measurement of an 8.5m parabolic reflector, which was incredibly difficult to calibrate under the influence of environmental disturbances.
In particular, this project taught me the following relationship, which has stayed with me for years.
Result = Quality * Acceptance
A good result always depends on the quality of the product and the customer’s acceptance of the delivered solution. While many project engineers focus on quality parameters, customer acceptance can also be considered for the project result. Ask yourself the question: “What is the customer most interested in?” and try to meet that acceptance. The best quality product will not produce a result without customer acceptance – for real. I still remember a customer acceptance test (SAT) in South Korea. Whereas in Western SATs, I am used to the customer accepting and checking key functional parameters, in Korea it is customary not only to check the entire tender specification but also to provide evidence of the test point in the form of a photograph, measurement, report, or functional test. I was amused when an 11.8-meter white radome was delivered, and I had to provide proof while we all looked at the radome. What meant weeks of extra work for me to produce supporting documentation was, in fact, nothing more than a customer’s assurance to his superiors, as was customary in the country. It was considered good and thorough work to have evidence. When I realized this need, I met it and achieved acceptance with well-prepared reports that the auditor could pass on to his superior. It is in the nature of acceptance testing that there are always points of contention as to whether a specification point has been met or should be tested differently. However, thanks to an exceptionally well-prepared acceptance catalogue with pictures, explanations, and references, we were on the same wavelength at the table and were able to complete even critical acceptance tests within the planned time. So the celebration on Friday evening, after a glorious acceptance test, with consortium partners and colleagues, felt really good.
I promise you that this blog will contain as much real-life project experience as it does systems engineering content. It’s easy to publish successes, but in the real world, projects fail and project goals are missed. It takes special skills in leadership, negotiation, and an incredible sensitivity in dealing with the customer. It is not uncommon to reach the limits of one’s pride, ego, and patience, but those who persevere are rewarded. Do you want to be awarded? Do you want to explore what goes on behind the negotiating table of really big projects?
Stay tuned on this blog and you will find out.