Hey guys.
Thanks for the replies and describal of your pragmatic approaches. It is indeed possible, that we are "shooting sparrows with cannons" as a german saying says, but there are a couple of points to "defend" our position:
<UL TYPE=SQUARE>
<LI> Why QMS?:
We want the QMS to automatically result in a very good project management as well. We will use a QM Wiki that will show all processes.
Further, we want to extend it and use a usual Wiki as well, which is supposed to work as a real-time documentation platform (during the project).
This approach will work instead of Hectorīs bound copies of previous years (after project) and will eventually result in several design reports that work as a basis for the final one like "exFSAE" described it.
<LI> Waste of ressources/ "nice to have documentation but it takes alot of time to write it":
I have to do a mini-thesis (200 hours) anyway, so why not for this? Itīs a nice scientific work for somebody who doesnīt want to do part design, FEM and all that stuff.
I found an institute and a professor at my university who accepted this mini-thesis. Iīm quite sure that anything "smaller" than a QMS (and 200 hours) would not have been accepted/ supported.
Besides, a lot of team members including me joined the team in order to do things that we will encounter in our future jobs as well. So itīs a personal interest, too.
<LI> "telling the people how to make the car"
Much of the processes that we are writing and analyzing right now, consider non-technical stuff. In my oppinion this doesnīt affect the speed of decisions on events for example, nor how to design the car.
Instead it gives new team members the possibility, to look up "best practices" - how financial/ insurance/... things have been done in the past.
The goal is something like a "manual" for the team, not how to design and build the car.
<LI> "documentation would be nice, but..."
The QMS will inevitably lead us to better documentation and distribution of information that is necessary in a "company" with such a high staff turnover/ fluctuation like all FS teams have.
<LI> bureaucracy/ "if every thing is under control you are going to slow"
Iīm certain that it is much more likely that the QMS helps in doing things than it slows down: imagine a freshman running around not knowing what to do. Thatīs where the QM Wiki can help him.
IMO the other case, that the QMS will slow things down or avoid somebody to do something, is not as likely.
<LI> "just to say we work to DIN EN ISO 9001"
The 9001-certification is a "waste product" that would be nice to have. But we are implementing the QMS because we believe it will help us.
We will do a first audit when weīre done. Then we will see if we do another after the first one expires after 3 years.
<LI> "culture and details"/ "If you need to implement some fancy flavor of the month management/quality system to accomplish that so be it, but it just seems like a huge waste of resources."
We kept it simple and informal in the past. We donīt have juniors naming their parts "kennys final version for real", but still we are not as succesful as we would like to be.
It seems that we have to go further and dig deeper in order to get better.
<LI> "three biggest things are probably knowledge management, risk management, (motivation and) holding members accountable"
Could you tell me a nice generic name for what you mentioned?
(I can give you a hint - it starts with a "Q")
[/list]
I would be glad to learn about more of your ways to get your teams organized and running properly. the keywords are effectiveness and efficiency (Kick Off, setting the goals, doing things only once...).
This would help us to define the processes and the ways to measure the outcome of the process, so that the entire process-orientation really makes sense.
Thanks in advance,
Nick