Whether this is your very first Frontier Challenge or you’ve been through several before, the most valuable piece of advice remains the same: read the RFP carefully. It is the guiding document for the entire competition, containing everything your client – the Global Regeneration Society – is asking for.

Think of the RFP as both your map and your destination. Every instruction, requirement, and constraint outlined in it is what the judges will use to measure your team’s proposal. On the surface, it may seem straightforward: respond to the client’s needs. In practice, however, the RFP is deliberately ambitious. Some requests could challenge even seasoned researchers or engineers to deliver in full. That’s part of the design of the challenge — it forces you to be creative, resourceful, and collaborative under time pressure.

Your goal isn’t perfection. Instead, it’s about generating as many innovative, practical, and well-reasoned solutions as you can within the time you have. Success starts with knowing how to interpret the RFP effectively.

The RFP is usually organized into sections and sub-sections for different departments. While this makes it easier to navigate, don’t fall into the trap of thinking of these as isolated tasks. Each part connects with the others, creating a network of requirements that together define the client’s expectations. Viewing the RFP holistically will help you build a coherent, integrated proposal instead of a patchwork of ideas.

Teams often skim only the sections relevant to their department. Resist the urge. Everyone should understand how different requirements intersect, since one decision in your area could impact another.

Expect the RFP to be a few thousand words long. Set aside at least an hour at the start of the event to read it thoroughly. This may feel slow, but in real-world projects, companies invest significant time in requirements analysis because it saves time and errors later.

The phrasing of each RFP point matters. The verbs used tell you exactly what kind of response is expected.

Here are common examples:

• Show/Demonstrate: Provide a clear visual representation.
• Show how: Explain (visually or in writing) how a requirement is met.
• Describe: Summarize in text or images how your design satisfies a point.
• Detail: Go beyond description by including specific, lower-level information.
• Justify: Explain the reasoning behind a design choice.
• Specify: State the outcomes of decisions made.
• Indicate: Provide direction or approximate figures, without full precision.

Understanding these distinctions prevents wasted effort on giving too much (or too little) information.

Each RFP item includes a baseline — the minimum deliverables the Global Regeneration Society expects. These are the first things judges will check for, so ensure they’re covered before adding extra features.

Many RFP points require background steps before you can address them. These implicit steps are known as derived requirements.

For example: if the RFP states, “Provide adequate energy for your settlement,” you first need to calculate what “adequate” means by estimating consumption across all systems. Only then can you compare energy sources and decide on redundancy or backup options. Recognizing derived requirements helps transform vague points into actionable tasks.

Don’t rely on memory alone. Highlight important instructions, link related points, and add notes on potential challenges. Shared documents or collaborative tools can make this easier. Doing so helps you prioritize, especially when time is limited.

During the event, experienced volunteers and mentors will be available. They often have insider knowledge of how RFPs are written and can help demystify technical jargon. Asking questions early prevents wasted effort later.

It’s easy to drift into interesting but irrelevant research or to over-deliver on one point while ignoring another. Keep checking your work against the RFP’s wording and make sure the command words align with what you’re producing. Peer reviews within the team can also help catch deviations before they become major issues.

Heads of Department (HoDs) carry the main responsibility for requirements management. They must ensure that all RFP points — especially the minimum requirements — are addressed. It’s easy for leaders to get absorbed in specific details, but their real role is to oversee their department as a whole and prevent gaps.

Senior leadership (President, VP of Engineering, Systems Engineer) should step in when issues are missed, offering guidance without micromanaging.

Some RFP sections introduce unique, cross-disciplinary challenges that don’t fit neatly into one department. In these cases, forming temporary project groups can be effective. These groups bring together people from multiple departments to tackle a specialized requirement. Judges pay close attention to how teams handle these integrated tasks, and a dedicated group often produces stronger results.

A compliance matrix is essentially a tracking tool that lists RFP points and shows progress on each. Simple versions use color coding; complex ones track responsibility, research status, slide completion, and more.

When used consistently, compliance matrices (or similar task management systems) help teams avoid overlooking requirements and prioritize effectively. However, they only work if the entire team commits to updating them. If your team chooses to use one, weigh the setup time against the potential benefits.

The RFP is not just paperwork — it’s the backbone of the Frontier Challenge. Read it thoroughly, revisit it often, and treat it as your guiding compass. Teams that master the RFP don’t just meet expectations; they stand out by delivering coherent, well-justified, and innovative solutions that truly address the Global Regeneration Society’s vision.