3rd Symposium on Space Educational Activities, September 16-18, 2019, Leicester, United Kingdom
Evaluation of Preliminary Design Review (PDR)
formats in student space projects.
E. Menting, T. Britting, L. Pepermans
Delft Aerospace Rocket Engineering (DARE)
In any engineering project, the Preliminary Design Review
(PDR) is a major milestone. The design is presented to non-
project members who provide feedback. This feedback is used by
the team to incorporate in the detailed design. The review can be
done using written documentation and/or an oral presentation.
Student space projects often have a tight timeline which imposes
constraints on the PDR process. Depending on this timeline and
the availability of team members and reviewers, the PDR can be
done in several ways. Variations can be made in: level of detail in
documentation beforehand, the time between sending
documentation and PDR, the format of the feedback and the
implementation of the feedback.
The article originates from the widely varying PDR formats the
authors experienced in different student space projects. Within
Delft Aerospace Rocket Engineering (DARE) a PDR was held on
both the Stratos III and Stratos IV student-built sounding
rockets. Furthermore, a PDR on the Supersonic Parachute
Experiment Aboard REXUS (SPEAR) mission was held both
within DARE internally and within the REXUS/BEXUS
In the article, the pros and cons of the various formats are
discussed together with their applications. As cases, the
REXUS/BEXUS and DARE PDR formats are compared to each
other and the ESCC standard.
Keywords— Preliminary Design Review, PDR, student project,
DARE, REXUS, ECSS.
During the Supersonic Parachute Experiment Aboard REXUS
(SPEAR) project, the team experienced a different format of
the Preliminary design review (PDR) in the REXUS/BEXUS
program than it was used to within DARE. The different setups
also resulted in different feedback. This led the team to wonder
if these formats can be altered and combined in a way to tailor
to a student project’s needs. This paper explains key aspects of
both reviews and evaluates some of their pros and cons.
The process of a review in space projects is also streamlined by
the ECSS guidelines. The paper will provide a short summary
of the process presented in ECSS and what the advantages of
this method can be for student space projects.
DARE is a student rocketry society with approximately 150
members. These members work in multiple teams and
projects. R&D teams have around 10-15 members whilst
flagship projects like Stratos have around 60 members,
distributed over different technical and non-technical sub
The design cycles in DARE consist of a conceptual,
preliminary and detailed design. The conceptual design phase
is mostly only reviewed within the team itself, where during
the PDR all members of DARE and, on occasion, external
reviewers from the Technical University of Delft or
companies are invited.
The design is shown during a presentation in which the design
trade-offs and choices are explained. After each section, a
question and discussion round is started in which the
reviewers can question and explore the design. The reviewers’
experience with similar (sub-)systems leads to
recommendations for the design which is one of the key points
during this review process.
Main characteristics of a DARE PDR are:
• No or limited documentation is sent beforehand.
• If documentation is sent, this is only done shortly before
the PDR (one to two days).
• Low number of external reviewers is present.
• The presentation on the design and design choices is
relatively long and can last up to two hours for a
• The feedback from the reviewers is not structured in
• There is little to no time for the reviewers to let the
design sink in and generate questions or comments.
• There is much freedom to dive into different discussions
and reviewers can bring up new ideas or solutions to the
problems of the team. There is room to discuss this
• Reviewers usually have many questions on the design
after the presentation, as it does not fully cover all the
• The level of detail of the design in a PDR is not pre-
determined, thus varies often. Sometimes the design is
still more in the conceptual design phase.
The DARE PDR’s as they were, were long and somewhat
ineffective. As the reviewers did not have proper
documentation or time to read the provided documentation,
questions were often not relevant or very broad. This led to the
presenter spending the majority of the PDR time on explaining
the mission and the conceptual design and less time on the
design issues. This was made worse by the observation that
many members had different opinions on what the preliminary
design needed to contain.
Based upon the REXUS selection workshop and the REXUS
PDR, a first improvement to the DARE PDRs were made.
• Documentation is sent out at least one week beforehand.
• The PDR starts with an overview of the mission.
• The PDR contains a 30-minute presentation on the final
preliminary design broken up in clear subsystems.
• Discussions and questions are done per subsystem.
• More in-depth content discussion than usual DARE
reviews were possible.
• Reviewers can give written feedback on documentation
if they aren’t able to come to the PDR.
The modification of the DARE PDR format led to a better
structure and noticeably better results for both the SPEAR
Within the REXUS/BEXUS program Cycle 12, the SPEAR
team had its PDR in February 2019. Within the REXUS
program, the student team hands in an updated version of their
Student Experiment Documentation (SED) two weeks before
the review. The SED contains the full preliminary design and
progress up to that point. The PDR is held with the student
team and a panel from the REXUS/BEXUS program
containing multiple members of the different organising
parties and different specialties. During the PDR, the student
team gives a short presentation of 20 minutes to summarise
the design and any design changes that were made between
the SED and the PDR. After this, the panel gives their
feedback on the design and the documentation in an hour
during which the team makes notes. This means the review is
relatively one-sided, in the presentation from the team towards
the panel and vice versa for the feedback. Minutes of the
feedback, including feedback on the SED, is sent to the team a
few weeks after the design review.
In the same week as the PDR, a Q&A session with all student
teams of that cycle and the REXUS panel is organised. Here
issues with the design or controversial points can be discussed
in more detail where also alternative solutions can be
Main characteristics of the REXUS PDR:
• The documentation (SED) is provided two weeks prior to
• High paced student project means content can actually
change significantly in those two weeks.
• PDR itself is somewhat one-sided.
• Review and comments are more in-depth as elaborate
documentation is read and studied beforehand.
• Q&A session with the panel allows for more in-depth
discussions and is a much-needed supplement to the
• Elaborate minutes, including action points, are sent after
the review, enabling the team to ensure the feedback was
• The content of the feedback on the written
documentation is different compared to DARE’s. It goes
into the design much deeper and also focuses on details,
not solely on the basic working principle. Aside this it
also includes feedback on the quality of documentation
The European Cooperation for Space Standardization created
an extensive set of guidelines meant to improve consistency
and facilitate design efforts within the European space sector.
The published standards on design reviews are discussed in the
following section, which is based on ECSS-M-ST-10-01C
‘Organization and conduct of reviews’ .
The overall purpose of a review is to examine or evaluate the
current status of the project in which the problems faced
throughout the design process are discussed. Reviews often act
as a moment of reflection.
The ECSS identifies three different steps during the review
• ‘Review initiation’
• ‘Review data package preparation and distribution’
allows the review participants, REXUS, to familiarize
with the to be reviewed documents.
• ‘Review of the documentation’ includes a kick-off
presentation during which RID-forms (Review Item
Discrepancy) are used. The issues, remarks and questions
from the RID-forms are afterwards addressed during
meetings between both parties. The review team, SPEAR,
is then expected to compile all results and conclusions
that arose from the review.
• ‘Review findings and conclusion’ covers the examination
whether the objectives of the review were met.
ECSS-M-ST-10-01C includes a list of requirements that serve
as guidelines to a productive review for both the review team
and review participants. The general requirements serve mainly
to ma ke sure that constructive feedback is exchanged and that
any issues are correctly addressed.
The four following roles should be filled during a review:
• The review authority approves the review procedures,
examines review reports, makes the recommendations
and decides whether or not the review objectives have
• The customer ensures that the review can be held by
providing the necessary means, such as a data
management system for the review data.
• The supplier’s role is to provide all logistics,
documentation, data and RIDs for the review.
• The review team leader mainly manages the review
teams’ activities and approves the RIDs.
• The review team reviews the documents and subsequently
provides feedback using the RID-forms.
The chronological order of a review should be as following:
• A prerequisite key point serves as a check that the review
• The kick-off meeting introduced the to be reviewed
documents and product
• During the coordination meeting, the documents are
reviewed, and all RID-forms are released.
• In a collocation meeting, the RIDs are discussed,
following with action points that should be undertaken.
• After the review team close-out meeting, the results from
the previous meeting should be summarized
• Finally, the review authority meeting confirms the
outcome of the review and creates a review authority
The final steps of a review include the follow-up of action
points and processing of the feedback received through the
V. COMPARISON OF PDR FORMATS
When comparing the three PDR styles; Old DARE, New
DARE, and REXUS, one can see that where the Old DARE
style allowed for too much discussion, the REXUS format
however does not allow for interaction during the PDR. The
latter is solved by the introduction of a Q&A session during
the REXUS training week. This however, is not feasible in
most student projects as there are often insufficient external
For most student space projects, it is unfeasible to follow the
cycle proposed by ECSS as this takes place in a much longer
time span. A much larger part of the ECSS process takes place
on paper, with meetings to coordinate the process. In a student
project it is still recommended that the one PDR moment stays
central in the review process. However, some advantages are
identified, of which the RID-forms is the most significant one,
allowing for structured written feedback.
Both the REXUS and the ECSS formats include
documentation to be sent out before the PDR. However, in the
REXUS PDR format this means that the team should not
change the design or documentation for this period. Given the
short time span of a student space project, two weeks is quite
long in a high paced student project. The use of RID-forms
creates a compromise where the documentation is sent out 2
weeks before the PDR, but the team can still updates the
design in this period.
For student space projects, the team proposes the following set
up that is efficient and thorough but still allows for
implementation into student projects.
• T-3w – Reviewers are identified and asked. Important is
to ensure a broad scope and experience of the review
• T-2w – Documentation is sent to reviewers
• T-1w – Final call for RID forms
• T-0 – Presented PDR
• T+1w – Send out minutes of PDR
• T+2w – Final feedback on minutes
• R+3w – PDR phase finished
The PDR itself should be set up such that the following topics
• Overview of mission and concepts to ensure all
reviewers are on the same page
• Overview of the RID forms that are not solved or
addressed with explanation
• Preliminary design overview of the system and
• Preliminary design of the system interfaces
• Overview of risks
• Overview of budget
• Question round organised per topic
Even though this set up requires a total of six weeks, it
provides the team with two feedback moments. As the first one
is written, it allows for the team to tackle these before the
presented PDR. When the points mentioned above are followed
the presented PDR gives a complete and total overview of the
project. By adding an introduction talk on the mission and the
conceptual design, the team can ensure the review board is on
the same page and that a more efficient PDR can be held.
The inclusion of the RID-forms allows the team to start
addressing issues in the two weeks prior to the presented PDR.
This removes the downside identified in the REXUS PDR
By sending the minutes to the reviewers, the team can ensure
that the written down feedback is as the review board intended
Most importantly, the Preliminary Design Review should be
planned as a review phase, not a review moment. This setup
also allows for a good processing of the received feedback
instead of having to directly continue with the next design
Student teams should never underestimate the usefulness of
design reviews during their space project if done well. This is
maybe even more important for the PDR than for any other
review. Given the three different styles of design reviews, the
team proposes a combination of the ECSS and the REXUS
review. This allows for more discussion during the PDR, alike
the DARE model.
 European Space Agency for the members of ECSS. (2008) ECSS-M-ST-
10-01C Organisation and conduct of review, retrieved from