Aerospace engineer Eric Becker explains the duties of a flight test engineer, and offers a few insights on dealing with operational risk, in this episode of The Engineering Commons.
Like most engineers, Carmen occasionally worries whether he’s made the proper decision at work.
Our guest’s advice to individuals not following the typical engineering career path is “if you want it, just do it.”
Eric can be reached via email: eric -=+ at +=- internal dot org.
Also, feel free to follow Eric on Twitter as @ericnbecker.
Carmen finishes up with an obscure reference to the movie Glengarry Glen Ross.
Thanks to DVIDSHUB for use of the photo titled “Helicopter Air Refueling Mission.” Opening music by John Trimble, and concluding theme by Paul Stevenson.
A project is defined by the PMI as “a temporary group activity designed to produce a unique product, service or result.”
Jeff wonders whether the company NeXT Computer would therefore have qualified as a project.
Project that do something for the very first time can become “science projects,” placing unlimited demands on time and money. (With apologies to scientists, who find ways to live within their time and cost constraints ;^)
Brian notes that engineers, when constructing complicated systems, rely heavily on solutions and technologies provided by vendors.
Adam and Brian feel that the skills set needed to be a strong technical expert are fairly independent of those needed to be a good project manager.
Carmen likes “take charge” project managers who quickly get down to business in meetings.
Jeff mentions President Kennedy’s 1961 proclamation that the United States would send a man to the moon as an example of a leader who didn’t necessarily have strong technical skills, but Brian notes that Wernher von Braun’s engineering expertise was needed to make the project a success.
A “strong matrix” organization allows project managers to easily pull resources from functional groups, while a “weak matrix” organization gives functional supervisors the authority to deny resources to project managers.
Project managers have to balance the constraints of time, money, scope, and quality, as represented by the Project Management Triangle.
A work breakdown structure decomposes a project into smaller tasks that can be carried out to ensure that the project is completed.
Jeff notes the need to break personal tasks into smaller sub-tasks, such as a “next action,” when working with the Getting Things Done (GTD) method of time management.
A lot of engineers first get introduced to working with a Gantt chart via the Microsoft Project software program.
The “critical path” defines the series of events that have to occur on schedule for the project to be completed on time.
With due credit to Donald Rumsfeld, Adam breaks risk into four categories: known knowns, known unknowns, unknown knowns, and unknown unknowns.
Risk management methods include acceptance, mitigation, avoidance, and transference.
Projects typically involve the five stages of initiation, planning, executing, monitoring and controlling, and closing.
In this episode, we consider how engineers deal with ambiguity, uncertainty, and risk.
Carmen would be willing to take a 50/50 shot at $1001 tomorrow over a certain $500 today. Most people are risk-averse when dealing with gains, and would take the sure money.
According to the article “The Five Neglects: Risks Gone Amiss,” (Berger, Brown, Kousky, and Zeckhauser, 2009) rational decision-making is a difficult process. It requires accurate estimations of probability, correct valuation of potential benefits, proper use of statistics, consideration of all available alternatives, and evaluation of external effects.
If you are interested in being a guest on The Engineering Commons podcast, please drop us a note; the email address is admin -=at=- theengineeringcommons.com.
Adam was a bit confused when he first encountered the term “CatEx,” which is short for “Categorical Exclusion.”
It is noted by Carmen that ambiguity in problem definition is sometimes a good thing, as it allows him flexibility in investigating possible solutions.
A 1993 article titled “Choice over Uncertainty and Ambiguity in Technical Problem Solving” (pdf) considers how engineers might change their problem-solving approach based on the relative levels of risk, uncertainty, and ambiguity.
In the previous episode titled “Value,” guest James Travelyan talked about engineers not feeling like they were being productive unless they were carrying out computations, or making design decisions.