Design Documentation Best Practices

[IKE]

I am curious what sort of design documentation practices teams have? I have observed a few threads about CAD sharing, and code sharing, and about solving problems.... I am curious if any teams feel they ahve a really great documentation process that they would like to share on CD.

IE documentation of scoring analysis, strategy derivation, functional decomposition, Prototype results, architecture development/solution, design calculations (motor & gearbox selection), detailed design, design changes (and change processes), component and subassembly tests, integration, system testing, system tuning, practice, design changes due to seeing competitors, design changes due to stuff breaking, strategic shifts mid comp season.....

The closest I have observed were some teams that kept build blogs, which is definitely a type of design documentation. What others are out there that teams use? Any success or best practices worth sharing?

[z_beeblebrox]

My team keeps Google Drive engineering journals, which work pretty well. The challenge with those is getting enough people to contribute to keep them up to date.

[Chak]

Originally Posted by z_beeblebrox

My team keeps Google Drive engineering journals, which work pretty well. The challenge with those is getting enough people to contribute to keep them up to date.

I think that's a challenge everywhere.
So how did your team overcome this challenge?

[z_beeblebrox]

Originally Posted by Chak

I think that's a challenge everywhere.
So how did your team overcome this challenge?

With limited success.

As you can see, relatively few people contributed entries to them.

[zachrobo1]

Team 1002 did a build notebook that had a large portion of our build time documented. It was our first season doing so, so it had varying degrees of completion from day-to-day. Overall, it was a good experience for the students.

You can check it out here:
https://docs.google.com/document/d/1...it?usp=sharing

[IKE]

Thank you all for sharing so far. One of the benefits of South East Michigan is that you can visit with teams and have lunch with friends that run/have run teams.
I had lunch the other day with two mentors that were the only technical mentors for a team for several years. While this was not the most competitive team, it often did very well, especially considering that there was a very high turn-over with their school, so they had a bit of "perpetual rookie syndrome" from the student perspective.
These mentors said a lot of their success was due to "standard work". IE, there are a set of chassis calculations they run for geartrain analysis that leads the design effort. There is a period of rule reading, and then strategic objective ranking, and several other exercises.
The benefit of the standard work was not allowing simple things to fall through the cracks or for the knowledge to fall to the side as "we always use 8 inch wheels..." and other best practices that turn into assumptions.

This "standard work" reminded me a lot of the influence and practices I read about in "The checklist manifesto". I originally read this book as I thought it would help me make better checklists for pit/match preparation. While reading it, I realized it has a lot of potential for utilizing a Design Checklist.
The team I worked with this year did not use such a list, and after starting build, we realized a very awkward problem. We were 1/2" short in several directions from having a good battery placement. We ultimately found a compromise, but had we used a checklist to verify placement of key components before starting build, we would ahve realized the issue, and just designed in the chassis the extra 1/2". This would have dropped the batter position about 4 inches lower, which would have been beneficial from a Center of Gravity perspective.

What items might a Chassis Standard Work Checklist include?