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.

Assessment activities in Capstone Project
Task Submission Weight
Project Audits and Reviews x 4 Group, via Repository link on Wattle 70%
Mid-project Presentation Group, in person and via Repository link on Wattle 10%
Professional Reflection x 2 Individual, via Turnitin on Wattle 20%

Timelines #

Submission timelines for course assessment activities
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, 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).

Submission and feedback timelines for Project Audits
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 #

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 #

Each team must submit or update a valid link to their Audit Landing Page via Wattle. One submission per group is required.

  • 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.
  • 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.).

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.

Project Audit 1 requirements #

In addition to the initial creation of your repository and landing page, four audit 1 your team should prepare a Concept of Operations (ConOps).

Concept of Operations #

The Concept of Operations is used to explicitly state your objectives for the project. It is a standard part of the technical processes of systems engineering projects and will be used to define your project. It should contain appropriate information to define the program of work your team will undertake to complete the project.

The ConOps should help you establish your repository but is likely to be a standalone reference document. The document can contain links to parts of your repository that contain the full information. As a guide, it should contain a short statement sufficient to understand the nature of the work against the following areas:

  • The overall project vision, purpose, or objective (2-3 sentences)
  • what the project will achieve, i.e., the goal of the project (2-3 sentences)
  • The key stakeholders, what do they do, and how they interact (dot points, figure, or table)
  • Identification of resources, risks (project and activities), potential costs and who will bear them (tables)
    • This includes an indicative financial budget (table)
  • Technical and other constraints (for example, reliability, security, safety)
  • Completion of the Capstone Agreement (for any confidential information and Intellectual Property (IP) requirements)
  • The setup of tooling for project and team development, management of tasks, and a link to the project repository
  • Milestones for each Project Audit, including:
    • A set of goals and deliverables for each audit (2-3 sentences)
    • Contingencies, such as stretch or crash goals for the milestone (2-3 sentences)
    • An initial timeline for the project to reach the milestone (weekly table)
    • An initial work breakdown structure for the milestone (as designed)

It is highly recommended that you get sign-off for your ConOps from your project host, tutor, and all team members. Any variation to the ConOps during the year would normally require sign-off by these stakeholders. There is no template for this sign-off, but it should most likely resemble a ‘contract’-style arrangement with the names, signatures, and dates of these stakeholders.

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
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.
  • 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.
  • 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).
  • 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.

Progress indicators awarded at each Project Audit
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.

A summary of audit criteria and expectations
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
Showcase Not effective to highly effective 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?

Criterion for Project Outputs
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?

Criterion for Decision Making
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?

Criterion for Teamwork
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?

Criterion for Communication
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?

Criterion for Reflection
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

Showcase [not effective <-> highly effective] #

note: only considered for the poster and pitch in PA4

How is your project visualised and communicated at the Showcase?

Criterion for Showcase
Indicator Description
Baseline States the problem and scope, reports outcomes and results, shows how the project has delivered value, recognises stakeholders, visually coherent, uncluttered, presentation of prototypes or models (if appropriate)
Acceptable Builds a narrative, representative of work completed, articulates value for host, appeals to a broad audience, leads to opportunities for new audiences
Exemplary Involves physical and virtual representation of the project outcomes and resullts, enables further opportunities to engage with the project and broader stakeholders, clear and easy to follow, interpret and understand, encourages opportunities for new audiences

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:

Indicative weightings for Team Member Contribution
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 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 250-500 words for each of the two criteria for each team’s review (this means your total word count is greater than 250-500 words). 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:

Indicative weightings for Project Review
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 six 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:

Example individual grade calculation
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 (including the mid-project presentation) 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. They can be assumed to be technically minded people; however, you should not assume that either are technical experts in your area of have knowledge of your project. Be careful to avoid jargon.

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.

Aerial view of layout for poster showcase
Figure 1: Aerial view of layout for poster showcase

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.
  • 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.

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 #

For Competency Mapping #

For reflective Writing: #

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>

Document Information #

Document Information
This document ENGN4300 Assessment Guide [Download as PDF]
Format PDF preferred, also available as web page
Document type Information and Procedures
Purpose Overview of assessment processes for students undertaking ENGN4300 Systems Project
Semester Semester 1, 2024
Audience Current Students
Contact
Version 2024.S1.02 (See Change log)
Related Content ENGN4300 Course Guide [Website] [Download as PDF]

Change log #

2022.S1.01: 2022-11-30

  • Updates and restructure to account for new WHS risk assessment and capstone agreement processes. Add resources for the ConOps, temporarily remove reflections.

2022.S1.02: 2023-02-17

  • Updates for new reflections and resources.

2024.S1.01: 2024-02-14

  • Updates and reformatting for new semester
  • Updates to reflections and mid-project presentation

2024.S1.02: 2024-04-19

  • Updates to mid-project presentation
bars search times