Documentation and Building Institutional Knowledge

Technical Technical Discussion
#1

Our team has made some strides in recent years, but we’ve historically struggled with something of a wax-wane pattern as institutional knowledge builds, and then departs with graduating students. This is particularly difficult as a largely student-run team.

So, I was wondering how successful teams retain their knowledge base from year to year, in the face of student churn.

We’ve made some efforts to this end over the past couple years - our programming is now written to a reasonably well-defined standard and works from a persistent codebase, for instance, and we’ve started a team wiki (though we’ve yet to really write that much for it) to try to document important technical knowledge. But we’d really like to hear what other teams do, so that we can copy some of their best-practices.

Team Frameworks for Knowledge/Learning and Succession
#2

I have been struggling to make this happen with our team for a while now too. I feel like slack needs a way to turn something into static content for it to work right now. We’ve completely gravitated to slack but now we need a way to make that content static and curate it over time.

#3

We have a good system in place for the business side, we’re still working on it from the engineering side.

On the business side, whenever we run an event, the student and mentor in charge fill out an Event Form. This requires them to keep track of all the details they went through in planning the event. This makes it much easier on whoever is running the event next year because they can look back on that form and have a to-do list right there. You can see a blank version of this form here: https://drive.google.com/file/d/0B42RcBZiQGjhMFBoSWRTWC1hQ3M/view?usp=sharing.
For marketing it’s just a matter of passing email templates and spreadsheets recording fundraising data from year to year by storing them all in OneDrive.

As far as the engineering side, we don’t have a well defined system in place. It basically comes down to having older students teach the younger students well and having the same mentors from year to year allowing them to carry on memories of past designs and knowledge of engineering. We started a blog this year, but it doesn’t have a lot of technical information on it. It was mostly so that someone who missed a day would be able to look at that before coming back and know generally what progress had been made.

#4

Team 3081 has been lucky enough to have relatively strong alumni support which has made up for our lack of documentation. Why go to a wiki when you can talk to a former student who was there? (Joking of course).

#5

I’m interested in what people have to say. We are a student-led team, and have been working to make a lot of changes in the past year. However I am afraid that these will only be temporary changes, once people graduate.

#6

Team 8 is in the same situation. Primarily student-run, and we’ve made fairly significant improvements over the past 2-3 years and the graduating senior class has been a large driving force behind many of them. Next year will be interesting because in addition to a loss of technical knowledge, the team will be losing strong leaders.

In my opinion an important mindset to keeping knowledge in the team is encouraging younger students to seek out and learn about what advances the team has made over the past year so they don’t repeat the same mistakes just to learn the same lessons. Ask older members what they would do differently, that sort of thing.

#7

On most teams, I think the answer is mentors or alumni who stay year to year, or that the information does get lost, unfortunately. On 2662 my history in FIRST makes up for the experience level of most of our students (majority only 1 - 2 years in FRC, most join as Sophomores or Juniors).

This is something I am planning to talk more in depth with our new student leadership when school lets out for the summer. Coming from a manufacturing background I want to explore some TPM/Lean principles (One Point Lessons, 5S, SOPs or Run Right books, etc.) and see how they can help cover some of the gap in knowledge we have with new students each year. I can see them being pretty helpful for basic items like the color coding we have adopted for different bolt sizes, but I’m not sure how useful it will be in documenting more in depth topics like drivetrain gearing and layout trade-offs.

A risk with any large documentation is that the difficulty in using it will make it go untouched. When I was a graduating student I wrote up a large handbook trying to encompass much of the institutional knowledge I had picked up from years of FRC and Chief Delphi that spanned close to 100 pages. No one ever used it; it had too much content to find specific information easily, and the content that was there was still too technical or in depth for someone unfamiliar to pick it up on only a quick read through. I think a system using mostly images/diagrams for simple topics and video recordings for topics that require more of a “lecture” would be more effective.

#8

I set up a team wiki, but as far as I know, I’m the only one that ever accesses it. :frowning: oh well, at least it’s a place I can go to refresh my own memory.