Introduction #
In the Capstone Design Project, you will practice an authentic project evaluation process.
The following table summarises the assessment activities in the Capstone Design Project.
Task | Submission | Weight |
---|---|---|
Project Audits and Reviews x 4 | Group, via Repository link on Wattle | 65% |
Mid-project Presentation | Group, in person and via Assignment link on Wattle | 10% |
Professional Reflection x 2 | Individual, via Turnitin on Wattle | 20% |
Project Showcase (Pitch and Poster) | Group, in person and via database on Wattle | 5% |
Timelines #
When | Semester | Description | Who |
---|---|---|---|
Week 1 | Initial | Project selection | individual ‘with buddy’ |
Week 2 | Initial | Project offers and acceptance | individual |
Week 4 | Initial | Project audit 1 (PA1) | project team (group) |
Week 10 | Initial | Mid-Project Presentation | project team (group) |
Week 11 | Initial | Project audit 2 (PA2) | project team (group) |
Week ‘13’ Friday 09:00 | Initial | Mid-Project Reflection due | individual |
Week 4 | Concluding | Project audit 3 (PA3) | project team (group) |
Week 9 Friday 17:00 | Concluding | Project Showcase Poster due | project team (group) |
Week 10 | Concluding | Project Showcase | project team (group) |
Week 11 | Concluding | Project audit 4 (PA4) | project team (group) |
Week 12 Fri 17:00 | Concluding | Final Team Review due | project team (group) |
Week ‘13’ Friday 09:00 | Concluding | Professional Reflection due | individual |
These timelines may be adjusted if ANU and health restrictions change. Where possible events will delivered in-person with a real-time online delivery via Zoom available only if required.
Project Audits (PA) #
Project Audits are used to evaluate the progress of each team.
Purpose #
Project Audits are designed to provide formative feedback to guide your group towards your team’s project goals whilst ensuring high-quality systems-level project governance. Project Audits are standard practice in many industries to evaluate the progress of a project.
Goal #
To enhance all project work through constructive, actionable feedback with critical and considered review.
Overview #
There are four Project Audit stages during the project:
- Audit 1 (Concept of Operations, Initial Project Management Plans, Repository and Landing page, initial Risk Assessments) - to set the agenda and scope for the project, outline project governance.
- Audit 2 and 3 (Mid-Project Audits) - to guide and evaluate progress, based on the project scope.
- Audit 4 (Final Project Audit) - to finalise and prepare for the next stage of the project.
The Project Audit contains three elements:
- Repository, work product and activities - the work done and governance of your project.
- Project Review - a self-reflection and a critique of your shadow team’s work against two criteria.
- Team member contribution - an evaluation of the relative contributions of your team
The Project Audit processes are awarded progress indicators (not grades) which can be used as evidence for your final grade prepared in your Final Team Review.
The Systems Engineering Body of Knowledge (SEBoK) (Part 3: SE and Management - Systems Engineering Management - Assessment and Control) provides a good overview of why Project Audits and Reviews improve the technical aspects of projects.
Audit cycle #
Each Audit Week will run through the same cycle. Audit weeks: Week 4 and 11 of each Semester (four audits over two Semesters).
When | Description | Who |
---|---|---|
Audit wk, Mon 09:00, | Landing page up to date | project team (group) |
Audit wk, Mon 09:00, | Project Review and submissions open | self, shadows, tutors, project hosts (individual) |
Audit wk tutorials | Open-format presentation of your progress | project team (group) |
Audit wk+1, Mon 09:00, | Project Review submissions closes | self, shadows, tutors, project hosts (individual) |
Audit wk+1, Mon 17:00, | Project Review feedback and indicator available | via Wattle |
Audit wk+1 tutorial | Audit review and TMC indicators available | via Wattle |
Audit wk+1 tutorial | Team’s plan acting on feedback (not required for PA4) |
project team (group) |
Audit Requirements #
Each project will be different. The scope, approach, deliverables for every aspect of the project should be negotiated with your project host and teaching team. At each Project Audit, you should present a ‘Landing Page’ within your repository. The Landing Page is a web page, file or other document that guides the reviewers through the team’s work. During tutorials in an audit week, you will provide a short presentation on the current state of your project work and governance. The audit review is not of this presentation, but the evidence of work done demonstrated within your repository against the specified criteria.
Project Repository #
Purpose The purpose of the repository is to store all your project documentation in one location in an organised and easy to navigate format.
What should it include? At a minimum, your repository should include:
Item | Purpose |
---|---|
Meeting minutes | Meeting minutes serve a few purposes, one of the main ones being evidence of decision making and allocation of tasks, roles & responsibilities. You can also optionally choose to use a decision log in addition to meeting minutes. |
Concept of Operations (ConOps) | The purpose of a ConOps is to explicitly state your objectives for the project. It is a living document updated over the duration of the project. Please ensure you are using version control when updating this document and storing all versions in your repository. |
Project timeline | The purpose of the timeline is to plan and monitor your deliverables over the duration of the project period. |
Status reports (weekly) | The purpose of the status report is to monitor your progress against your project timeline. |
Team structure | The purpose of outlining your team structure is to document the allocation of roles and responsibilities for each team member. |
WHS risk assessments (if required) | The purpose of WHS risk assessments is to ensure you are identifying and mitigating possible risks to your project. Risk assessments should be dynamically updated over time as your project progresses. |
Documentation of your project work | As required |
Note: because ass your projects will be very different, each repository will contain different information. These items are the minimum requirements for your repository. It is up to your team to decide what else you may or may not include in your repository.
Each team is free to make their own decisions regarding the tools they use and where they store and manage the artefacts they produce. However, in making these decisions, each team should:
- Consult with your project host
- Consider any information that may need to be kept confidential, who needs access to what, host’s existing enterprise repository, how access will be managed and who will cover any costs.
- Access
- In addition to any project host access requirements, your repository should be accessible by your shadows, tutor, and course convener.
- Transition arrangements
- At the end of the course, consider the needs of the next project team or your host. For example, you need to ensure that they will have access to, and control over, any tools you have used.
Many groups opt to use the ANU’s license of OneDrive as the default repository system.
Audit Landing Page #
Purpose The purpose of the landing page is to collate information about your project into one location in a manageable and easy to navigate format.
Your landing page should be openly accessible to the teaching team and your fellow classmates*.
We encourage you to use freely available tools for developing your landing. Some examples include Wix, WordPress and Notion.
Note: For teams with specific confidentiality requirements, the landing page should still be accessible to the teaching team and your fellow classmates. It is the documentation in your repository which will have restrictions to meet confidentiality requirements.
What should it include? Each team must submit or update a valid link to their Audit Landing Page via Wattle. One submission per group is required. At minimum, your landing page should include:
- A short summary of your project
- A list of your team members
- A link to your repository. If applicable, the landing page should provide instructions on how to gain access to the repositories and tools you are using (for example, how to get accounts, passwords et cetera.).
- A link to your Concept of Operations
- The Audit Landing Page should not contain any of your actual project work - this will already be stored in the tools and repositories you have been using.
Remember that an Audit is a look at your progress at a specific point in time and does not require you to do any additional project work just for the Audit. The landing page should be within your repository.
Concept of Operations #
Purpose The Concept of Operations (ConOps) is a key document for Project Audit 1 and the establishment of the goals of the project. It is not a technical document; rather, it is an outline of a proposed concept, and it provides a shared understanding of the what, why and how of an overall project. It is used to explicitly state your objectives for the project. It is a standard part of the technical processes of systems engineering projects. This document should be developed in close consultation with your project host and with some guidance from the tutors, is used to explicitly state your objectives for the semester. For the purposes of the Capstone project, the ConOps will be treated as the official definition your project. It should contain appropriate information to define the work your team intend to undertake to complete the project.
As you commence planning your project, you will probably contend with multiple information sources and will be working across several documents. To the best of your ability, you should try to develop the ConOps as a self-contained reference document. Where needed, the ConOps may include links to parts of your repository which contain additional detailed information, however, it should contain an essential level of detail allowing for it to be read as a standalone document.
It is highly recommended that you obtain a sign-off for your ConOps from your project host, tutor, and all team members. There is no template for sign-off, but it should most likely resemble a “contract” style arrangement with the names, signatures, and dates of all stakeholders. Note: As the project evolves throughout semester, it is quite likely that the ConOps may require some adjustments. It is very important that any changes be agreed with, and signed-off by, all stakeholders, so that the ConOps continues to remain a guiding reference throughout your project journey (and not just to PA1!).
The following resource may be useful when creating your ConOps:
- IEEE Std 1326-1998: IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document - available via the ANU library
What should it include? A starting template of a ConOps is available on Wattle. This can be used as a starting point for your ConOps, but you should adapt the template to be suitable for your project and your team.
Project Audit 1 requirements #
In addition to the initial creation of your repository and landing page, audit 1 should include at least the following essential information navigable from your landing page:
- all work done, up to date, accessible and navigabe within our project repository,
- the initial version of the ConOps
- templates for project governance (e.g., meeting minutes, decision logs ect.)
- an initial project management plan including:
- Project scope and deliverables
- Assumptions and constraints
- Stakeholder analysis
- a project schedule or timeline indicating dependencies (weekly table or gantt chart)
- a work breakdown structure for the milestones and deliverables (as outlined in the ConOps)
- a risk management plan. This should include project, technical and other risks (for example, reliability, security, safety)
- Resources and budget (if appropriate)
- Team structure
- Communication Plan
WHS Risk Assessment #
Note, WHS Risk Assessments are not a one-off task. Risk assessments should be reviewed and updated periodically throughout the duration of a project. Subsequent audits will serve as appropriate checkpoints review and revise your risk assessments.
Project Audit 2 requirements #
Audit 2 is mid-way through your project. You should be progressing the project and providing value to your project host. You should be able to report on the milestones you planned in the ConOps. Your review will be explicitly against the expectations set out in your ConOps. This audit is scheduled in close proximity to the Mid-project Presentation; however, they have different purposes and a different audience. The purpose of a presentation during the audit is to highlight your recent progress and project governance to your shadows and tutors. The mid-project Presentation is to a wider audience and its purpose is the demonstrate the value and purpose of your project and your planned solution. Audit 2 should include information navigable from your Landing Page:
- all work done, up to date, accessible and navigable within your repository.
- baseline systems engineering governance: a requirements analysis, functional analysis, and/or system architecture, and/or modelling as appropriate for your project.
- technical artefacts: initial prototypes or models, or drafts of project outputs.
- progress against criterion specified in the ConOps.
- any updated to the project management plan
- plan for achieving value in the remainder of the project.
- updates to WHS risk assessments if required.
Any updates to your ConOps should be undertaken with approval for your project host, tutor and team members between audits.
Project Audit 3 requirements #
Audit 3 is past the mid-point of your project. You should be achieving the milestones you planned in the ConOps. Your review will explicitly be against the expectations set out in your ConOps (and any approved changes). Audit 3 should include information navigable from your Landing Page:
- all work done, up to date, accessible and navigable within your repository.
- systems engineering governance: a requirements analysis, functional analysis, and/or system architecture as appropriate for your project. This should include evidence of how these have been iterated over time since your last audit.
- technical artefacts: prototypes, models, or progression of project outputs.
- progress against criterion specified in the ConOps.
- test and evaluation plan or appropriate method for measuring value achieved in the project.
- plan for project completion and handover.
- any updated to the project management plan
- updates to WHS risk assessments if required.
Any updates to your ConOps should be undertaken with approval for your project host, tutor and team members between audits.
Project Audit 4 Requirements #
Audit 4 is your opportunity to demonstrate your final deliverables. Your project should be wrapping up, but you may be permitted to explain why your project is not complete by the start of the audit due to project timelines. Your review will be explicitly against the expectations set out in your revised ConOps. In addition to the previous Audit requirements, Audit 4 should include information navigable from your landing page:
- all work done, up to date, accessible and navigable within your repository.
- project poster submission and team participation at the project showcase (see below).
- documentation of the outputs of the project e.g., testing, verification and validation, documentation of the final solution, design or recommendation,
- handover documentation back to the project host and/or to the next project team.
Audit Grading #
The awarding of a final group and individual grade will be negotiated over the course of the year. Project Audit activities feed into the Final Team Review, from which your final grade will be determined in considered congress with tutors and conveners. The information in this section describes the formal process for this evaluation.
Progress Indicators #
Projects will differ for each of the groups based on the project scope and the project host. Because each of the projects will be unique, not all projects will progress at the same rate or produce the same types of outputs. Projects will not be ‘punished’ or ‘promoted’ because of this difference in progress and outputs - instead, we will look at everything holistically and make the best judgements possible given the evidence we see. No grades will be awarded during the Project Audits, allowing time for the best teams to experiment, hopefully fail, and most importantly learn. Instead, an indication of progress will be given back to the team after each audit, based on the marking criteria.
The outcome of an audit will be based on the INCOSE guidance (modified to make sense in an educational setting) for milestones in the table below.
Indication | Description | Indicative grade band |
---|---|---|
Unsalvageable | Terminate or restructure the project | Fail |
Unacceptable | Do not proceed-continue this stage and repeat the review when ready | Fail-Pass |
Baseline - Acceptable with reservation | Proceed and respond to feedback items | Pass-Credit |
Acceptable without reservation | Proceed with the next stage of the project | Credit-Distinction |
Exemplary | Outstanding, systems-level activity | Distinction-HD |
When awarded, these indicators are not fixed in stone. Your team may have an unacceptable early review, and turn the project around, and still do well. Engineering projects are an iterative process that develop and improve over time. The initial stages of the project do not define the whole project. As a guide, the ratio of consideration for Project Audits is 1:2:2:3, but each circumstance will be different. These progress indicators will help to benchmark your final grade. Teams are expected to be fully autonomous in their benchmarking, so these indicators should provide one data point among others that you might be collecting.
Note: it is our experience that most teams naturally operate at or just above the ‘Baseline’ level. Work above this requires significant technical mastery coupled with extraordinary application of systems engineering, as described in the marking criteria below. It is hard work!
Audit Progress criteria #
Progress indicators for this assessment task will be determined using the Many Eyes Process. The audit criteria and the audits at which each criteria are applied are summarised in the table below.
Criteria | Range of expectations | Audits applied |
---|---|---|
Project Outputs | Superficial to substantial | All |
Decision Making | Disorganised to clearly traceable | All |
Teamwork | Non-functioning to peak performance | All |
Communication | Unclear to effective | All |
Reflection | Ignorant to transformative | 2 - 4 |
When evaluating a team against the following criteria, it is important to recognise that every team is different. This means that the factors considered under each criterion will differ. A description of expectations for each criterion against the indicator levels is outlined in the following sections. The audit process is designed to encourage teams to discuss and reach consensus as to what factors are appropriate at each stage of the project.
Project Outputs [superficial <-> substantial] #
How valuable are the team’s outputs to key stakeholders (which extend beyond your project host), given the level of effort and other resources available to the team?
Indicator | Description |
---|---|
Baseline | Minimum viable product (MVP)/proof of concept given to project hosts, tested by team and other internal stakeholders, benchmarked outputs against requirements, technically rigorous solutions |
Acceptable | Outputs endorsed by project host, prototypes or models, user testing, design validated against requirements, presentation back to the project host organisation, documented to best practise as per industry, domain, or sector |
Exemplary | System-level solutions, real-world user testing and validation, technically rigorous design, engaged in commercialisation, research papers accepted for publication, external funding, actively seeking external expert review, evolved solutions, conference presentation or industry competitions |
Decision Making [disorganised <-> clearly traceable] #
How effective are the team’s processes for making, implementing, evaluating, and learning from decisions?
Indicator | Description |
---|---|
Baseline | Recording decisions, maintaining a decision-log, coherent and accurate meeting minutes, transparent communications, centralised communication, document revisions, requirements meet INCOSE guide for writing requirements, maintaining a risk register, shared resource for reference material and research |
Acceptable | Broad stakeholder engagement, systematic version control, alignment with ISO/ANSI standards, industry-aligned processes, pro-active engagement with externals, utilising model-based systems engineering (MBSE), evidence-based decision making, risk influences decision making |
Exemplary | Inclusive decision-making processes, certification against standards, customised decision systems, seeking advisory boards and reference groups, traceable MBSE, comprehensive risk management (for uncertainty, decision making and project management) |
Teamwork [non-functioning <-> peak performance] #
How is the team working together to achieve project outcomes?
Indicator | Description |
---|---|
Baseline | Designated specialist roles, rotating functional roles, team position descriptions, managing differences, learning from failure, tracking progress against plans |
Acceptable | Engagement with mentors, embracing diverse skill sets, building opportunities for personal development, embracing lessons from failure, reducing uncertainty, building support teams around the project, actively managing project planning |
Exemplary | Evolutionary roles, engagement with experts from specialist fields, transcending disciplinary boundaries, supporting to develop new skills with other team members |
Communication [unclear <-> effective] #
How is the team communicating with, and managing the expectations of key stakeholders? How is the team communicating internally?
Indicator | Description |
---|---|
Baseline | Transparent, relevant, timely, professional, respectful, effective, using a systems vocabulary, navigable |
Acceptable | Systematic processes, facilitated communication between team and stakeholders, strategic communication to stakeholders, modelling of professional communication, active listening |
Exemplary | Building a shared vision, trust between all stakeholders, common mental models of practice, communicating and listening with outside audiences, empowering members to engage with new audiences |
Reflection [ignorant <-> transformative] #
note: not considered formally in PA1.
How is the team reviewing feedback and acting on it to improve their performance?
Indicator | Description |
---|---|
Baseline | Acting on feedback, respecting diverse viewpoints |
Acceptable | Establishing external benchmarking processes, deliberate seeking of mentoring, incorporating systematic reflection, benchmarking of project activities |
Exemplary | Constructing processes to gain external validation, additional review processes including external stakeholders, helping other teams to reflect and improve |
Project Audit: Team member contribution (TMC) weighting (individual) #
During the Project Review process, each team member will evaluate the relative contributions of each team member. Students will self-evaluate, but this self-evaluation will mute in the consideration of the weighting. Contributions will be awarded a weighting on a 5-point scale:
Label | Description | Indicative weighting |
---|---|---|
Absent | Absent from project work without notice | Case-by-case |
Well below expectations | Team member is not completing tasks | -5% |
Below expectations | Team member could be contributing more | -2% |
At expectations | Consistently contributing to the team | 0% |
Above expectations | Team member is doing more than was requested | +2% |
Well above expectations | Team member is significantly lifting the team | Case-by-case |
A TMC will be awarded for each Project Audit, and the result will be cumulative over the four Project Audits. TMCs will be awarded in consultation with your tutor and based on the reviews given through the TMC process. It is not common practice to award high numbers of positively cumulative TMCs primarily because great leaders should be enabling other members of their team and improving the quality of project work (not seeking individual advantage).
Many students rate their whole team “well above expectations”. This makes no difference to your TMC - what we are examining is the difference in the median reviews of team members. This just tells the teaching team that you don’t understand the purpose of this process (nor do you understand the concept of averages).
Note: No late submissions for TMCs are accepted. Failure to submit a TMC review will result in a -5% weighting as a penalty.
Project Audit: Review weighting (individual) #
At each Audit, each team member will be required to reflect on two criteria from your project work, and the same criteria of your shadow team’s project work. Criteria will be randomly allocated, and you will be notified which criteria you are responsible for via the Project Audit Review Topics on Wattle and at the start of the Audit Week through the Project Review form.
You will complete a Project Review form with a series of indicators, and a written component of 200-300 words for each criterion for each team’s review. This will involve meaningful investigation and critique into the work of the team. The reviews should add value to both teams. Completing the review is considered as service in your role as a member of the class. Your tutor will award a weighting based on a 5-point scale:
Label | Description | Indicative weighting |
---|---|---|
Nil submission | No submission by due date (late submissions not accepted) | -5% |
Below expectations | Feedback not actionable, specific, constructive, or accurate | between -2% and -5% |
At expectations | Feedback actionable, specific, constructive, and accurate | 0% |
Above expectations | Systematically driving behaviour through feedback | +2% or determined by case-by-case |
The Project Review weightings will be awarded for each review. It is not common to award high numbers of positively cumulative PR weightings, but there have been many extraordinary examples of students significantly improving the work of others through review.
Project Audit grade: Final Team Review component (group) #
The final grade for the group will be determined through an application prepared by the team, called the Final Team Review. Each team will provide an application detailing the team’s performance against each criterion submitted on the final day of your concluding semester.
- 3 pages (maximum) detailing performance against each of the five criteria with reference to indicators (unacceptable, baseline, acceptable or exemplary).
- 2 pages of specific supporting evidence.
- A coherent grade band recommendation based on the Progress Indicators.
This will be considered alongside the progress indicators for each of the audits and, of course, the project repository and deliverables. You should develop this application in deep consultation with your tutor over the whole year. If this process is done well, you will have a clear idea of your group’s grade ahead of submission. There is little value to the team by overstating or overshooting.
Determination of final audit grade #
Your final individual weighting will be calculated through the following formula:
your group's project audit grade (based on Team Review submission)
x (team member contribution (PA1+PA2+PA3+PA4) + project reviews (PA1+PA2+PA3+PA4))
For example, a team member might receive the following weightings during reviews:
Project Audit | Team Member Contribution | Project Review | Cumulative weighting |
---|---|---|---|
PA1 | At expectations; 0% | At expectations; 0% | 1 (100%) |
PA2 | Below expectations; -2% | Nil submission; -5% | 0.93 (93%) |
PA3 | Above expectations; 2% | At expectations; 0% | 0.95 (95%) |
PA4 | At expectations; 0% | At expectations; 0% | 0.95 (95%) |
Example #
Let us assume that the team has had progress indicators throughout the semester in line with “Baseline” and “Acceptable with reservation” progress indicators, and successfully argue a Credit-Distinction grade in the Team Review. The Project is awarded a 67.5%. Therefore, the individual grade would be calculated as:
Project grade (67.5%) x Individual Weighting (0.95) = 64.125%
Another team member with an Individual Weighting of 1.1 due to exemplary Project Reviews and TMC would be calculated as:
Project grade (67.5%) x Individual Weighting (1.1) = 74.25%
Mid-Project Presentation #
Engineers must be able to communicate complex and highly detailed work to new audiences in a short amount of time. In this communication we often need to strike a balance between providing enough detail about the technical concepts of our work without confusing and isolating the audience. The mid-project presentation is an opportunity to practice this skill.
By the mid-point of Capstone, your team should be developing a deep and broad understanding of your project. You should have clear insight into the purpose of your project and its value for your project host and other stakeholders. You should have a clear approach to delivering a solution or parts of the solution within the course time limits.
When preparing for you mid-project presentation, think of it as a pitch to a general team (which may or may not include engineers) convincing them to support your project to proceed. Not a marketing presentation but demonstrating your understanding of the problem your project is addressing and how you are addressing this problem.
Your presentation should outline the following:
- What is the problem? - What is the problem your project is solving? who are the stakeholders? What is the value proposition of the project?
- Why is it important? - Who will your project impact? How will it impact them?
- What is your solution and how did you decide on this solution?
- Why is this the right solution?
- How will you achieve this solution? What is the approach you will use? What are the key challenges you face and how will you mititgate these challenges?
Please note that internal teamwork, governance, detailed systems engineering documentation and detailed technical designs are more appropriate to present within audit 2. The mid-project presentation is not an audit.
Each team will be allocated 15 minutes for their presentation. This will be divided into 10 minutes of formal presentation by the team followed by 5 minutes of question time from the audience. Demonstrations of models or prototypes are encouraged; noting we understand many projects may not be at this stage just yet.
Your audience is the other engineers and professionals within the Capstone Engineering Firm. Your audience will consist of engineers and other professionals who are technically minded but may not be experts in your project’s field or familiar with its specifics. Therefore, you should avoid using jargon and refrain from delving too deeply into the technical aspects of your solution.
Presentations will be attended by your fellow students and the teaching team. Project hosts are not invited on this occasion, but teams are encouraged to present to their project hosts at a time that is convenient for them.
Grading #
Multiple members of the teaching team will grade your presentation. Your work will be assessed against the following criteria:
- Appropriateness for audience: poor <-> suitable 25%
- Demonstration of the value of the project: ambiguous <-> clear 50%
- Professionalism, approach, and attitude: ad-hoc <-> considered 25%
For more information about the Mid-project presentation including a detailed rubric see Wattle.
Showcase Poster and Pitch #
The Capstone Showcase is an exciting opportunity to showcase your teams’ achievements in week 10 of your concluding semester. At the Showcase, teams will present their work to an audience including project hosts, industry guests, academics, and other students. The top performing teams will also present a short pitch to the audience. The purpose of the poster is to clearly explain to a lay audience what your project is about. The poster will be set up on a pinboard as shown in Figure 1. You may bring props, prototypes, demonstrations, or other material to showcase your work, and will be given a table, shown below.
Poster specifications
- Your posters will be printed for you at A1 size on premium paper; however, your poster should be designed in such a way that it could be printed at A2 (smaller), A0 (larger) size or be viewed online.
- There is no template that you should follow. This is an opportunity to be creative with how you present your project visually.
- Posters should be submitted in PDF format on Wattle, the Friday before the Showcase. The file should be submitted as a pdf at A1 size max 250 MB. Save your file to its highest resolution, use CMYK colours and embed your fonts to ensure they are not altered during printing.
- All posters should include the names of team members.
- Any logos or recognition from your Project host (including their names) should be endorsed by your project host.
Poster recommendations
- Think of your poster as a ‘conversation starter’ - it does not have to contain every morsel of information about your project.
- Avoid bitmap formats such as JPG, PNG, TIFF, and prefer scalable artwork, such as SVG.
- Where bitmap formats are used, the resolution should be high enough for printing (above 150 dpi at A1 size).
- Avoid semi-transparent backgrounds - these might look great on the screen, but generally don’t print very well.
- Maximise your poster for readability - with a minimum viewing distance of 2 metres, choose easily readable fonts. We suggest using a readable sans-serif font such as Public Sans, Helvetica or Roboto, and setting your minimum font size at 24pt (yes, this is large and you won’t be able to fit your whole repository on your poster…) The ANU colour palette will keep it in theme.
- Some groups use a QR code to allow your audience to explore information later.
- Get feedback on your poster as you go - don’t save getting feedback until you’ve ‘finished’.
After the showcase, posters can be given to project hosts, or you might wish to take it home and hang it on your wall :) or you can donate it to the School of Engineering to inspire future Capstone students.
Posters from previous semesters can be accessed on Wattle.
Pitch Specifications
- Your pitch should be a maximum of three minutes in length.
- Your pitch can be given by one or more members of your team.
- Your pitch should clearly articulate the problem which your project aims to solve, the outcomes and results you have achieved and how these have delivered value to your project host and other stakeholders.
- The audience for your pitch will be diverse in their technical knowledge and experience.
- During a short pitch, it is not always advisable to use slides.
Depending on the size of the cohort, it may not be possible for all teams to pitch at the showcase event. For large cohorts, the teaching team will select the best pitches from those demonstrated during the tutorials the week prior to the showcase event.
Grading #
Please see Wattle for details on the grading of the pitch and poster.
Professional Reflections (PR) #
The Professional Reflections are independent activities that complement your ongoing professional engineering development.
As a professional Engineer you will be required to reflect on your skills and experiences to demonstrate your ability throughout your career. For example, when responding to selection criteria for a job application, seeking promotion or when applying for chartered status as a practicing engineer.
For your individual assessment in the Capstone Design Project, you will submit a professional reflection at the end of each semester (two submissions). The first reflection will focus on your contribution and approach to the project during your initial semester; demonstrating your technical and/or professional skills and considering the potential for further skill development relating to your attainment of the Engineering Stage 1 Competency Standard for professional engineers during the Capstone project.
The second will reflect on the growth and development of your technical and professional skills through the Capstone project; how your approach to meeting challenges has changed through your degree and what that has taught you about your capacity to grow and improve as you prepare for graduation and the beginning of your professional career.
To assist with this process students are required to keep an Engineering logbook throughout Capstone, demonstrating their day-to-day work, host interactions, resources accessed, hours worked, ideas generated and personal reflections on how previous courses and extracurricular activities have assisted with the project. For more information see the section on keeping an engineering logbook.
Mid-Project Reflection (MPR) #
Purpose #
To reflect on your personal contribution to and approach to your project and consider how this experience maps to the attainment of the Engineers Australia Stage 1 Competency Standard for Professional Engineers.
Goal #
To help you achieve the best outcome for yourself, your team, and your project host. To identify your personal strengths and opportunities to address gaps in your competency during the completion of your project.
Requirements #
The mid-project reflection will be a written professional reflection of 1500-2000 words (2-3 pages) and 2 pages of evidence.
Please see Wattle for more details and a marking rubric.
End of Project Reflection (EPR) #
Purpose #
To reflect on your technical and professional skills acquired via your required engineering courses, work experience, electives, and any extracurricular activities (such as internships, societies, and student teams) and how these have grown or developed through your Capstone project. How has your approach to meeting challenges changed through these experiences and what has this taught you about your capacity to grow and improve as you prepare for graduation and the beginning of your professional career.
Goal #
To consolidate your learning across your degree and to help you get your foot in the door to your next big opportunity!
Requirements #
Your professional reflection should build on your experience in this course and your project and other learning, from electives, majors, required courses and any extracurricular activities.
The professional portfolio will be a written professional reflection of 1500-2000 words (2-3 pages), and 2 pages of evidence.
Please see Wattle for more details and a marking rubric.
Engineering Logbook #
A logbook is a progressive and cumulative demonstration of work done over the course by an individual student. It can also be described as a ‘technical diary’. It is much more than a log of time spent including information such as thoughts, ideas, sketches, calculations, results, contacts, references and more. This includes both documenting failures and successes. The practice of keeping a logbook often used in industry and research, and usually serves as evidence for:
- a time log accounting for how the host “will be billed”
- a log of activities that were undertaken on the project
- a record of ideas during the project
- evidence of inventorship or origination of ideas
- a record of designs and innovation during the project
- a way to trace an idea through to realisation
Some organisations require engineers to keep a logbook. Many engineers keep a logbook as a personal preference. Regular entries into your logbook will allow you to track what you’re doing during the project and identify where you have used skills, tools, experience, and knowledge from other courses and/or extracurricular activities. Done well, this should be very useful when it comes to preparing your professional reflection and competency mapping.
Periodically through the year you will be asked to show your logbook to the teaching team. They will be able to offer you advice on the information you are recording and your professional development through the project.
Requirements #
Each student must keep an individual logbook. Entries should be made regularly (weekly at a minimum) and must be timestamped (day of the week, date and year). Students can choose to use a physical or digital logbook, but you should consider the advantages and disadvantages of each option before choosing.
Logbook Type | Advantages | Disadvantages |
---|---|---|
Physical (notebook) | Chronological Easy to add sketches, diagrams and calculations |
Can get lost Might need multiple across a project Might not have it with you |
Digital | Difficult to lose Easy to share |
Timestamps (tool dependant) Possibly difficult to add sketched, diagrams and calculations Might not have computer with you Easy to forge |
Resources #
For Engineering Logbooks #
OneNote - Engineering Notebook - How to use Microsoft OneNote to record a logbook
An investigation into the use and content of the engineer’s logbook - Available via the ANU library
For Competency Mapping #
- EA – Stage 1 Competency Standard for Professional Engineer
- EA – Stage 1 Competency Assessment Booklet
For reflective Writing: #
- Reflective Writing (ANU)
- Reflective Writing (UNSW)
- Reflective Writing (Deakin)
- Reflector’s toolkit (Edinburgh)
- Systems Engineering Core – How to reflect (available on Wattle)
Version Control #
Authorship & Citation #
This course is an evolution of semester long course, ENGN4221 Systems Engineering Project. The current course convener Dr Zena Assaad acknowledges the immense support from Dr. Chris Browne for his contribution to build up and set up a fantastic Capstone program.
The original Course Guide for ENGN4221 Systems Engineering Project and associated frameworks were designed by Dr Chris Browne over many years of teaching, and ideas from this design have been published in multiple sources. Parts of this text originate from A/Prof Shayne Flint, from when this course was a part of TechLauncher. I acknowledge the hundreds of students, dozens of tutors and number of colleagues and project hosts who have provided input into the design as it is today. The design of the course today would not be possible without the critical collaborations with A/Prof Shayne Flint and Dr Lynette Johns-Boast, who pioneered authentic project-based learning in the Research School of Computer Science for over a decade, and Prof Richard Baker who showed me a better way to learn. - Chris Browne
This acknowledgement cannot be removed from this guide without express permission from the Authors. If you do like ideas here, please cite the source:
Browne, C. Galvin, C, Simmons, J, 2020, “Capstone Design Project Assessment Guide”, ANU, accessed <date>, <https://eng.anu.edu.au/courses/engn4300/students/ENGN4300_Assessment_Guide.pdf>