This is the third installment of a series of articles I am writing about Project Management in FSAE. You can find the list of articles here.

This article will focus on Quality, Risk Management, and capturing Lessons Learned. These things are rather abstract concepts as they stand alone, so hopefully we can wrap them up into a nice package by the end by talking about them together. Controlling quality, anticipating risk, and learning from our experiences satisfies the “Monitor and Control” and “Close” project management process tasks that we discussed in the first article.

Definitions

There are two similar definitions of risk that we should examine. The PMI has a more project management centered definition of risk, while ISO is more of a process or design centered definition of risk. However, both are important, so it’s worth mentioning.

The ISO 31000 (2009) / ISO Guide 73:2002 definition of risk is the “effect of uncertainty on objectives”.

In this definition, uncertainties include events (which may or may not happen) and uncertainties caused by ambiguity or a lack of information. It also includes both negative and positive impacts on objectives.

The PMI definition of risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, or quality.”

This is a nice segue into Quality, which is “the standard of something as measured against other things of a similar kind; the degree of excellence of something”

...which is a great definition that, in many words, says almost nothing at all.

Instead, we can take all of these definitions above and rework it into a core concept that we can focus on in this article:

A risk is an uncertain event that can have either a positive or negative effect on the project; risk should be anticipated and controlled for to maintain project quality.

Core Concepts of Quality Management

Quality is a relatively abstract concept as it stands alone so I’m not going to elaborate much on it. To make it less abstract, we should discuss things that will generate results that have Quality qualities (ugh). See how it can get messy? Let’s delve into three discrete concepts for a more useful discussion:

Standardization of Processes

Risk Management

Continuous Improvement

Standardization of Processes

One way to improve the quality of your project is to create specific standards. These can manifest as a part numbering scheme for your CAD models and drawings, a team wiki, or even as far as email templates for contacting sponsors. A standardization of these aspects of your project allows your team to become more organized and be more professional.

Part numbering standards are probably the easiest way to improve quality of your manufacturing processes. Provided a whole CAD model of the prototype is present (hint: it should be), a tree of part numbers is fairly easy to generate. In fact, SAE already has organized this for you in Appendix S-3. This online article (although it’s clearly trying to sell you something) has good guidelines on part numbering systems.

This begs the question: why should we introduce a part numbering system? For one, it’s much easier to track part “SU-09203-AA” in a spreadsheet or file database than “Mirror2018 Front Upright Clevis Spacer 3.sldw” or even the dreaded “Part1.sldrw” especially if, like the aforementioned titles, they leave a lot to be desired. Not only are numbers more brief, but if the numbers actually mean something, they can be directly used in the Cost Report. This is one way to improve the quality of submission if drawings are included in the report and directly leads to more points at competition, which is one of your team’s bottom lines.

Document Management

Document management is being danced around here but must be explicitly addressed. What is the point of creating a standard if you cannot organize it? For many teams, a simple folder organization on a team computer (or if you want to be REALLY old-fashioned, a file cabinet) may be sufficient. If the team wants cloud storage or remote access, it can be done through Google Drive, Dropbox, Wiki, or otherwise. If a team is looking for specific software, you can create Gantt charts and folder hierarchies in Microsoft SharePoint to use it as a central hub for your team. Since there are thousands of document management systems on the internet, do some research to find one that fits your team. Regardless of platform, the folder hierarchy should be built at the beginning of the project and a student should be assigned to monitor and maintain it. The folders should be accessible to the whole team and the process to upload those documents should also be defined.

Processes and procedures are a little more challenging to document and require more legwork from the team. Tasks that are done in a discrete process every time (thinking of composites layups, meeting room requests, engine build and rebuild, how to make a purchase order, brakes bleeding, etc) should have procedures and documentation to support it. Initially developing these procedures can be a tremendous amount of work, but to standardize this process and write it down for not only the current team but future as well will pay off in the long run. The ISO has great resources for where to get started in your procedures: https://www.iso-9001-checklist.co.uk/free-iso-downloads.htm.

Risk Management

Why do we even care about risk? I’ll apply my personal philosophy here (which might be occasionally anxiety driven vs rational thought):

If you make mountains out of mole hills, you’ll rarely encounter mountains.

The figure to the left is called the “Severity Pyramid”, which illustrates the frequency of errors and shows “Heinrich’s Law”, a reported frequency of workplace incidents/accidents in research from H. Heinrich’s book “Industrial Accident Prevention: A Scientific Approach”. We can use this pyramid to discuss types of errors in an FSAE environment. This ratio in particular is highly debated, but for the purpose of discussion, we can use it here.

Non-consequential errors are the most common; they are minor things like forgetting to place a non-critical McMaster-Carr order, ordering the wrong bolt, misplacing a wrench, etc. In the grand scheme of things it would be hard to point to those and say “this is where it all went wrong!!” but they are the most common and add up.

Minor incidents/near misses are less common and more consequential: First aid incidents in shop, narrowly hitting a submission deadline (with probably the not-greatest quality of report), ordering incorrect components that are expensive, and others start to catch the eye of the team.

Major events rarely happen but are absolutely consequential. Whether it is a major injury in the shop, damage to shop equipment, missing a milestone, or late upload of document submissions, these events are discrete problems that can absolutely affect your team’s bottom line.

Serious events prevent a team’s success or their ability to reach their bottom line; they can be something like missing competition, totaling the car, or even something as serious injury of driver or death (which are both things that absolutely have happened in Formula Student). Therefore, accounting for all types of risk is of the utmost importance… personal safety and team success absolutely depend on it.

The process to managing risk is fairly simple:

Risk Identification Risk Analysis Risk Response Planning Risk Monitoring, Controlling, and Reporting

This can be done in a variety of ways. My personal favorite tool for risk management is a Failure Modes and Effects Analysis (FMEA). An FMEA is a spreadsheet tool that allows users to account for process or design risks and document controls for each. I use FMEA in my job often and it has tremendous value when done correctly.

The process to develop an FMEA is as follows:

Identify Scope of evaluation and failure mode Determine failure effect and its severity, probability of the failure mode, and likely hood of detection Discuss current controls and recommended actions Decide whether to mitigate, avoid, or accept the risk

FMEAs can be built for engineering systems, schedules, procedures, etc. They serve as a tool to point to when someone says “well what if xyz happens?” and helps design teams account for potential problems down the road. Here’s a pretty elementary example of an FMEA in a scenario where we are attempting to deliver a sandwich to a customer (yes, I was hungry when I built this):

The major features of an FMEA are present with severity, probability, and detection factors accounted for as well as a “Risk Priority Number” (RPN) assigned to each item. In general, the higher the RPN, the higher the risk. Current controls can be documented here and, if there is no control, recommended actions are explored. The benefit of FMEA is that no longer “it will be fine” would be an acceptable excuse for a concern – the documentation of a concern and WHY it will be fine will be done. Write it down!

FMEA is already used in FSAE. Teams that have attempted Electronic Throttle Control are aware of this. As such, there is already a template on fsaeonline.com for an FMEA spreadsheet.

I can hear it now: "But Emily, I don't want to know how to do FMEA for a sandwich and I'm not building an ETC system; how am I supposed to know how to start an FMEA for my chassis/brakes/powertrain/whatever system?"

Good news: Ford publishes a 286 page manual for their FMA processes. I bet you'd get more interviews at Ford for Design Release positions when that time comes if you used their processes and cited them on your resume... *wink*. Read about it here:

FMEA can be used for a variety of tasks in Formula Student. Here are some resources to get you started:

https://www.pmi.org/learning/library/fmea-approach-risk-based-scheduling-8188

https://www.yumpu.com/en/document/view/20973903/fmea-esf-formula-student-germany

Continuous Improvement

Continuous improvement is very important in the Formula Student world. After all, we participate in order to learn and become better engineers. To avoid the mistakes of yesteryear and improve the processes, designs, etc. of an FSAE team, things learned (both the easy and the hard way) should be documented. At the end of the project, reflect on the past year with “Lessons Learned” meetings. To capture Lessons Learned:

1. Document errors and potential risk-causing events. Include description of the Incident, the Effect, and Recommended Actions. Record it in your document management system. Write it down!

2. Make changes in a process, a design, or a state to avoid the risk in the future.

If one step of this process is done without the other, it’s ineffective. It’s that simple - nothing more has to be said on the matter.

In Conclusion

There is improved quality in standardization of processes and risk management. To address risk, do it:

Early – through use of tools like FMEA, you can preemptively spot problems

Continuously – do not wait to document and fix a problem that may affect next year’s team until the lessons learned meeting. Write it down!

Analytically and with priority– problem with aero vs problems with powertrain? You can’t drive without an engine but you can drive without wings.

With a define plan – define your risk management process and use it to build your plan for the coming year. Risk consideration should be used when planning deadlines!

With effective communication and education through Lessons Learned – you cannot rely on clan knowledge.

Write it down!

I invite any feedback in the comments.