“What is not on paper has not been said.”
AnonymousLet's talk about customer requirements.
Sometimes I find myself in a social situation where I don’t know a bunch of folks. After introductions, one of the first questions is: “What do you do?” I try to gage the level of interest and most of the time my answer is pretty simple: “I work as an engineer.”
That seems to satisfy most and we can move on to safe topics like: “Where do you live?” Or, “Can you believe the commute yesterday?” Or, because I live in California, “When is it going to rain?”
But once in a while, I meet someone who is genuinely interested in hearing what I do. She doesn’t have to be an engineer or someone who works in R&D, just someone who is not just making small talk but is having a “real” conversation. So we get to talk a bit of shop. How did we work ourselves into our current positions? What we like about it, what we don’t like about it, etc.
The most fascinating thing to me is that no matter the profession and no matter the level of responsibility, it always boils down to the fact that the most common thing that makes every job challenging is getting requirements from your customer. From the chef who gets requests to customize the standard menu items, to an engineer who is asked to build a data acquisition system or a writer asked to submit an article, we have all encountered a situation where, even though we know how to do our jobs, we can’t really do it, to the complete satisfaction of our customers, until we get a few parameters defined.
I am sure there is a whole branch of psychology (with a cool Greek or Latin title) devoted to the science of working with others to define exactly what is it that THEY want. Requirementology? Maybe.
What I would like to do is share some of my experiences and talk about what I learned in the last 25 years.
When I first started working, I worked in Quality Assurance for a chip manufacturer. I was part of a group that pulled random lots to make sure we met our specifications. Because it was manufacturing, everything that we did had a rigorously documented procedure associated with it. Everyone knew exactly what they had to do and how to do it. That is not to say that the job was boring, there was always something going on: QA isn’t finished but we NEED to ship the product. Or, my favorite, we failed enough lots that we need to either figure out if something changed in our manufacturing or maybe our testing processes and pull more lots – oh, and by the way, we NEED to ship yesterday.
When I got the job of working on wind tunnel tests as an Instrumentation Engineer, I faced a different challenge. I was given a task of designing data acquisition system (DAS) schemes for different experiments conducted in the wind tunnels. I was responsible for selecting the sensors, installing them, wiring them up to conditioning equipment, digitizing the signals, and making sure that the conversions to engineering units were done correctly. Sure, there were some challenges due to the number of sensors involved and the harsh environments that the sensors had to operate in but, all-in-all, pretty straight forward stuff.
After I read through the high level test proposal for my first assignment, I thought that my biggest challenge was going to be to make sure that we apply the correct filter correction to the dynamic data. I was wrong. My biggest challenge turned out to be understanding how many channels we needed and where the strain gages needed to be applied. The researcher I was working with kept changing her predictions on where the stress concentrations might be and how many gages he would need to capture the phenomenon she was trying to measure. The problem was that unless that got defined, I couldn’t start any designs at all. I thought this was normal and just continued to check in with the researcher making sure we stayed engaged, thinking that the researcher will slip the schedule appropriately.
About a week before the start of the test, I was asked to present my design so my group could allocate resources to build my DAS for the test. I thought it was a misunderstanding, because since I hadn’t received a full set of requirements, I hadn’t even started the design. Obviously, the test schedule was going to slip, right? WRONG. Then followed a VERY exciting time for me. I got to meet ALL of my supervisors (even the ones I didn’t know were my supervisors) and have discussions about my role and responsibilities in the organization.
It turned out that this was not an isolated incident and that our (service) organization, many years ago, developed a “Standard Test Development Procedure” to resolve this issue. The “STDP” spelled out in detail the milestones that the researches and the rest of the test team were expected to meet, a timetable laid out requirements for submittals, reviews, designs, and implementation.
Regretfully, no one had ever mentioned the manual to me (be sure to read my next blog titled “To Mentor, or Not to Mentor a Young Engineer – Is That Even a Real Question?”). Of course there was also a process to submit changes if need be, but everyone knew that the submitted changes were just an excuse to slip the schedule.
Here is a funny thing: Even though it was understood that the researcher’s job includes giving me the requirements, it was a widely established practice that my job was to “get the requirements.” It sounds like there is no conflict, the researcher “gives,” and I “get” – but in practice the researcher hesitates and makes his decisions at the last possible moment, taking into consideration all the bits of new information that he is getting.
Do we need to re-run the Computer Fluid Dynamics simulation to give a clue to the location of the vortexes? Did the Shake Test indicate the modes to stay away from and thus reduce the RPM envelop? Is there a need for more torsion gages, or will just the bending gages be good enough for safety of flight monitoring? What are the limits for safety of flight? So while he hesitates, I needed to guide him to make decisions that were most appropriate based on the most current information, using the threat of slipping the schedule as the “heavy.”
Some of my colleagues liked to play “hard ball.” They would march into the researcher’s office and say that unless they got the final requirements on such and such a date, they would request a change to the schedule. This could have been disastrous for any program because of the budget and tunnel availability issues. You miss your window of testing opportunity, next window is 2 years from now, sorry, pal.
I did it a little differently. I liked to start talking to the researcher as soon as the project got assigned to me to find out the objectives of the test and any special concerns that the researcher might have. I learned a lot about aerodynamics and I learned a lot about the pressures that the researchers were experiencing themselves. Some came from academia and were so theoretical that when it came to making a simple decision about placing a strain gage somewhere they couldn’t make up their mind. Others were extremely self-confident, but lacked the understanding of how their support organizations functioned and the delays associated with design, outside ordering, and manufacturing. Slowly we all came to trust each other and establish a working system to exchange information in a back and forth manner to always keep ahead of the deadlines.
It was going real well, until an opportunity opened up and I left the organization to test my skills elsewhere.
Years later, I returned to the wind tunnels, but now in the role of the Project Manager, representing the research organization. And funny enough, I got a visit from a young engineer who gave me a copy of “STDP” and told me she was going to slip the test unless I submitted requirements the next Monday.
I didn’t bother telling her I knew exactly how she felt, but we had a long talk and I explained to her what I was waiting on to make my final decisions. However, certain portions of our system had enough definition to enable her to begin preliminary design and start ordering material. All ended well, with the talk of schedule slip forgotten.
After she left, I thought about how much has changed in the last 20 years. The technology was unrecognizable, the new DAS was an amazing modularized tool that could be as complex as necessary and still be simple to configure. The speeds, signal-to-noise ratios, and error tolerances were many times better in the new systems than the systems I configured when I started working. Ordering and manufacturing process were streamlined and much more efficient. And, yet, the ability to do a job well still depended on interaction between organizations and a clear exchange of information. And to my mind both mostly depended on the personalities involved and not on the rigorous step-by-step manual. No matter how much I wanted to make it a purely “technical” issue, it was clear to me that it’s a “people” issue.
I am not suggesting that if you find yourself in a job that requires you to work with a customer, it is your responsibility to go to work and try to be friends with every customer you work with. But I think it is always important to keep in mind that in many cases, your customers are themselves customers to some other stakeholder: sponsoring government organizations, company’s lead dynamics expert, universities, etc.
It is always better to take the time and establish a working relationship and an understanding of what all the concerns are, so you know why it might be a challenge to get requirements and exactly what aspects of the requirements might change. Help the people you are working with solidify their requirements. Sometimes that is not only the best way to get requirements, it’s the only way to get something down on paper.
