Engineering Portfolio#

The engineering portfolio is a concise but detailed overview of your team and season. It is required for all awards and is a critical part of the judging process.

Portfolio Requirements#

Tip

A detailed list of the requirements is listed in section 9.3 of Game Manual Part 1

The engineering portfolio is a 15 page document consisting of standard A4 or letter sized pages and a minimum 10 point font. However, despite the small number of pages, there is a lot of information that needs to be packed into the document to meet the requirements for all awards.

Overall Tips#

  • Organize your portfolio clearly and carefully! Sections should be easy to follow and read, and have clear headings and explanations. Having your team number somewhere on the page is helpful for judges quickly reviewing portfolios.

  • Keep formatting and branding consistent, don’t vary your design a ton from one page to another. Similar layouts can help with reading the portfolio.

  • Make sure your text is readable! Color choices matter a lot, try to avoid similar color text on a background.

  • Do not exceed 15 pages total, 16 with the cover page.

  • Less is more: Judges are going to lose interest in large unbroken blocks of text.

  • Images, Images, Images: CAD Drawings and screenshots can be useful tools, but also have actual pictures of mechanisms and components. While renders can look impressive in covers, a lot of judges prefer actual CAD screenshots or pictures.

  • Make sure your team number is on the cover page of the portfolio.

  • Don’t over explain everything. You want to leave things for judges to ask questions about.

  • Remember that your portfolio isn’t just for judges to read, its a good tool to have in judging as a quick reference to present to judges.

Cover Page#

In addition to the 15 pages, you are allowed one cover page. This should contain your team number and any relevant logos, and should also include a picture of your robot and/or team.

Generally, the required information for an engineering portfolio can be split into one of 3 categories.

  • Robot Information

  • Team Information

  • Outreach/Nontechnical Information

Robot Information#

The season and robot overview is the core of your engineering portfolio. It contains an overview of your robot design, strategy, iterations, and shows off how your team has progressed so far throughout the season.

Robot#

Your portfolio must contain an overview of your robot and its components. However, the portfolio should go a step beyond just describing the components of your robot. Generally, teams split up their robot into 3-4 parts, putting a different mechanism on a new page. The page should have pictures and descriptions of the mechanism, but should also have iterations and explanations of how the team arrived at that version of the mechanism or why that system was chosen, as well as why previous iterations didn’t work and/or what was improved between iterations.

Tip

Get in the habit of taking photos of everything! Whether its a quick jig meant to test something or a full on prototype, you should have pictures to put in the portfolio as iterations.

As a quick reference, robot mechanism pages should contain the following:

  • Explanation of why that mechanism was needed

  • Explanation of what the mechanism is

  • Description of iterations the mechanism went through (and a quick few words on WHY it had to go through those iterations)

  • Math/equations/sensors used with that mechanism

  • Pictures and/or CAD screenshots of the mechanism

In addition to mechanism-specific pages, a page or two dedicated to a high level overview of your bot and sensors can be beneficial as a quick reference, especially in judging.

Season#

Your season overview is a higher level explanation of your robot design and how you have proceeded with the season. This doesn’t have to be completely separated from mechanism pages, but should still provide an explanation of your overall approach to the season as well as your approach to robot design in general. This section should aim to cover the following:

  • The team’s approach to game and strategy analysis

  • Overall approach to robot design (engineering design process, iteration, etc.)

  • Approach to problem solving and decision making

Having specific examples for these sections is generally recommended.

Team Information#

An engineering portfolio needs to cover more then just the team’s season and robot, it should cover details about the team itself. This doesn’t just mean a list of team members. Topics covered in this section should include:

  • Basic outline of team members and groups

  • Funding, sponsors, and expenses

  • Sustainability plans

Funding, Sponsors, and Expenses#

An important part of your team is where you get money from and how you spend your money. While perfectly precise numbers aren’t required, having an awareness of what your expenses are, and where you get money from can be useful information to have in a portfolio. The portfolio should definitely include a list of sponsors, but can also include other information like team dues and a rough breakdown of expenses.

Sustainability#

Sustainability is a very important part of an organization, and it is also a major part of judged awards. Sustainability doesn’t just mean funding, it includes plans for recruiting new students and mentors, maintaining and growing connections with the community, and securing new sponsors. It is important to have a sustainability plan or report, an outline of how the team plans to recruit new students, mentors, and sponsors, as well as the progress the team has made on that plan. Specifically pointing out new members, sponsors, and mentors that have joined is important, so judges can see the results your team has had.

Outreach/Nontechnical Information#

Outreach is the nontechnical aspect of your team, including connections with the general community, mentoring, and reaching out to the STEM Community. Due to how similar these things are, its tempting to combine them into one section, but there are distinctions that should be made between them.

Connections with the STEM Community#

Connections with the STEM community are important to document. These should include basic details like who the person or organization is, and what they do. However, the portfolio should also explain what the team learned from the connection and why it was meaningful. Having a specific and applicable reason for a STEM connection is important, as in recent years judges have started becoming more critical of large numbers of connections that do not benefit the team.

Tip

This should tie into your sustainability plan, as connections can often become mentors or sponsors.

Outreaches with the General Community#

Often teams will host events or outreaches with the intent of spreading the idea of FIRST® and recruiting new members to their team. Documenting this correctly is important for some awards. Generally, these sections should contain details about the event such as when it took place, what your team did, and how many people you reached.

Attention

Appendix F of Game Manual Part 1 contains very specific definitions of words like Mentored, Started, Reached, Ran, and more. Misuse of these words can be held against you in judging, so make sure you meet the definitions of terms if you use them.

When documenting how many people an event reached, it can be tempting to ask the organizers for an official head count and use that number. However, Game Manual Part 1 specifically details that simply being at an event does not count someone as being reached by the team, they have to interact with your team in some way. Keeping a rough count of how many people you interact with can help you keep track of accurate numbers. You may be questioned on how you know your numbers are accurate, so be ready to answer questions on how you kept track.

Working with Other Teams#

Mentoring, starting, and helping other teams is critical to the program itself as well as some awards. These interactions should be documented in the portfolio, as well as evidence that proves that you meet the definitions of Mentoring, Starting, and Assisting as outlined in Game Manual Part 1. In general, Mentoring requires regular, meaningful communication between you and a team, and Starting requires the new team agreeing that they were started by you.

Tip

An easy way to prove you met the definitions is to have screenshots of emails from mentors on the teams you helped stating that you Mentored, Started, or Assisted that team.