This is Part 7 of a series written by guest writer Ricky Nietubicz on his experience on the Formula SAE team at the University of Delaware. FSAE is a competition where students design, build, and compete with small formula-style racing cars. Ricky was President of his FSAE club, and his team went to the Nationals in Detroit during the 2006-2007 season.
At this point I will digress from the previous chugging along, speaking specifically of the car and of the team, to address an extremely important back issue that always seems to be brushed aside: record keeping. Call it what you want, data gathering, research, whatever, but continuity and progress both hinge on the ability of the team to learn from what it has done to optimize what it will do. I have alluded to this several times in previous articles, but I have decided it is an issue that is important enough, and brushed aside enough, to deserve a full article. I think it fits nicely between the designing and building phases.
Every day, week, month and year that the team exists, decisions get made. You’ve already made some- steelframe or monocoque, one cylinder or four, whatever. There are reasons why certain courses of action are chosen over others, why certain designs are picked, why certain parts are selected. A major problem that plagued my team was that the reasons for the decisions we made were catalogued mostly in the memories of the team members. This meant that there was a constant exodus of knowledge from the team as members move on. Such a system is not conducive to a competitive, evolutionary car.
The solution is simple- store information and data. There are different methods for doing this, I would recommend a hybrid of two methods, which I call “parts justification” and “daily journals.” “Daily journals” seem pretty simple- write down what was done that day, every day, even if it is “nothing.” The “parts justification” method is a bit more tied to what is done, and will likely be the basis for the design and cost reports.
Daily journals sound simple- just write everything down, as you do it, at the end of the day, whatever. However, this relies on each member of the team, or several members of the team, to write down their own endeavors, and then have a person to sort through them, catalog them, and organize them, or to have someone present when all decisions are made to capture them and the reasons for them, no small order when many decisions are made out of the shop or discussed informally in sub-groups. A good way to get a summary of what goes on is to go through all major decisions at weekly team meetings, where they can be logged by the team’s secretary. Ideally, it is at these weekly meetings that all major decisions would be made as well.
The second method is a bit easier to enforce- whenever a part is designed or ordered, someone must either sign off on the design or sign off to pay for it. If this is centralized, it is easy to enforce a log of decisions. A simple requirement for the design being completed or a part being ordered is a justification of why it is needed, including alternatives that were considered and why this design or part was selected over the others. The person making sure that the justifications are present need not fully understand them, as it is not this individual’s job to decide whether the justification is good or bad, only that it is present.
Note that the reasons for the decisions are as important, if not moreso, than the decisions themselves. Over time, the parts may be shown to be either good, bad, or average, but it is important to see why certain things were continued, used or abandoned. This is not necessarily important immediately, but becomes important as old ideas that have been shown to be bad are reintroduced, to prevent having to go through the whole process over again.
The usefulness of detailed records in testing and tuning is immediately obvious to anyone who has ever worked in racing. Maintenance, damage and repair, parts failures and replacements should all be logged. This will help keep any car in service longer, something which I will address later.
Good records also ease transitions for officers. Each officer has a specific role to play, and it is much easier to follow in a predecessor’s footsteps when there is detailed information as to what they did, and you have this information in your hand and ready to go.
Meticulous records take time to keep, and should be overseen by the officers. If each group leader keeps detailed records about their group’s activities, and then passes them up to the appropriate officer, and each officer keeps records of their area of specialization, there is never a question of what was done or why something was done. You may think that you’ll remember everything, or that you’ll never need to refer back to these records, but it is far better to have them and not need them to need them and not have them.
One final note, keep the records in more than one place. Having them electronically is nice, but make sure they are either burned to CDs periodically or transferred to an external hard drive, as we lost years of records (granted, we didn’t have much, but it was something) when our old computer’s power supply decided to give up the ghost, and throw sparks everywhere, requiring the use of a fire extinguisher. Recovery prices were about $1,000/gig, not the sort of money we had, so we lost the information.
This is the time for the secretary of the group to shine. While “secretary” isn’t exactly what most people are thinking of doing when they join a racing team, it is one of, if not the single most important role, and if there isn’t a secretary doing it, everybody else has to pick up the slack. The secretary makes sure that everything all of this information is logically stored, and without that function, there is simply no way that the team can function smoothly. Other officers and group leaders will be fumbling for information, working at cross-purposes and duplicating efforts, or rehashing issues that should be dead. Walk into any office, in any field, and you’ll see that it’s the secretary that keeps the place running. FSAE is no different.
Have your say
Fields in bold are required. Email addresses are never published or distributed.
Some HTML code is allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>URIs must be fully qualified (eg: http://www.domainname.com) and all tags must be properly closed.
Line breaks and paragraphs are automatically converted.
Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.