Documenting is not only about having a log of what you have done and how, it is a teaching tool and helps you understand ideas and issues better. Do not overuse it, plans and reports can make you lose touch with your project, but it can and will help you organize your project better and more efficiently.

Also, it is key to understand that documentation shall have a purpose for its existence. Documenting for the sake of documenting makes no sense whatsoever, you would rather be working on the project. Make sure the documents you create help you and review if they had a positive impact or not.

</aside>

There are hundreds of ways to document your project’s progress, decisions and plans. In this section, I’ll give you a version of how this looks like, but depending on the size of your project, this might be too much or too little, so let’s split it into sizes. Also, there is no perfect solution, as each project has its nuances, but this will give you a starting point for what it usually looks like.

Documenting your project

Name	Time	Team Size	Existing Equivalent
Small Project	1 to 5 days. (6h/day), 30h	1 to 6 people	Edventures Hackathon (🌍)
Small Project spread over time	3 to 5 weeks (4h/week), 20h	3 to 6 people	TechProjects (🇪🇸) 1st Project
Medium Project	3 to 5 weeks. (6h/day), 180h	3 to 6 people	Engineering Design Workshop (🇺🇸)
Large Project with small Team	1 to 6 months (4h/week), 80h	3 to 6 people	HoPE (🇮🇹) Project
Large Project	1 to 6 months (4h/week), 80h	+7 people	University Club (e.g. Make it to break it)
Huge Project	4 to 12 months (+7h/week), 300 to 700h	+14 people	University Club (e.g. Solar Car)

Small Project

Existing Equivalent: Edventures Hackathon (🌍)

</aside>

For a project like a 3-day hackathon project, you really want to minimize the time you spend documenting, as time is a premium you really should spend working on the real thing. About 95% of your time should go to prototype building and the other 5% should be documenting, but this is still an important part of the process. That 5% should encompass:

Taking Photos of what you are doing. Every time you manufacture, test, present something, you should take a quick photo or video. This is the quickest and most efficient way of documenting your project.

Write down a bullet points of your goals and sketches of the design. What should your project do? How does it look like? Who is this for?
If have the time: Small presentation. 5 slides maximum, concise, only bullet points and lots of pictures. This should take you maximum 15min. If it takes longer, you are overthinking it and losing time.

After the hackathon/project, document everything in a blog or post. Use something like instructables, GitHub or hackaday and show what you have done, how and why. Explain decisions and how to build your project from scratch (plus anything you would change).

Small Project spread over time

Existing Equivalent: TechProjects (🇪🇸) 1st Project

</aside>

The length of this project is similar to a regular Tiny Project, however, it is spread over time instead of condensed. Because of this, it makes little sense to crazy time on documentation. Limit yourself at answering the following at the end of each day: What should I do next day? Keep a todo list to quickly remember what you need to do to better use your time on what matters.

The main issue with spreading work over such a long amount of time is that we tend to take some time to start working, what could cut our productive time considerably. You need to be efficient and shorten the amount of lost time at the beginning of working hours.

Do NOT do any long documents or major documentation of your work. You are basically doing a 3-day project but with the limitation of time being split. Focus on the same aspects as a Tiny Project: Photos, bullet points of goals and sketches of the design and small presentation at the end. That’s it.

Medium Project

Existing Equivalent: Engineering Design Workshop (🇺🇸)

</aside>

If your project lasts two to four weeks (EDW sized), there is more documentation you should include. First, I would advise to keep a log of meetings, decisions and overall direction of the project. It is worth it to sit down for fifteen minutes and write down with your team what exactly you are trying to do.

Teams have had widely different ways of doing this, some more detailed while some more simple, but most successful projects tend to keep some kind of log of what they are doing.

By the end of the project, you should have:

Log of meetings (could be bullet points, an AI Summary or even a bunch of papers)
List of Materials (commonly refered as BOM) - In EDW, this is an Excel sheet for requesting purchases.
Schematics, drawings, mockups, etc etc. Anything that shows everyone else what you are doing.

Credit: Furrari (EDW 2024); Elena, Vittorio, Talia, Gracie & Cooper

Optional but recommended: Document where you have written down the direction and goals of the project. Keep this updated as the project evolves and everyone should agree on what it says you are trying to do. There is no template for this, write down what is important to you.
Optional but recommended: Project log. A document where you explain what you have done everyday with all the decisions you made along the way.

Credit: Waforte (EDW 2024) and Julia Do

Credit: Waforte (EDW 2024) and Ari Jiang

Documenting your project

Small Project

Small Project spread over time

Medium Project

Large Sized Project in Time with small team