Introduction #

The Capstone Design Project is the pinnacle team project course in Engineering at ANU. The Capstone is an authentic technical-based project experience, both in preparing students to have the autonomy they require to be professionals in their field and giving students the experiences and skills, they need to be attractive to a variety of graduate jobs.

This course is designed to mimic an industry design problem as closely as practical in a university setting. Students select projects and are given a broad problem statement. From the problem statement, the students are responsible for developing the full set of requirements, key performance indicators, and milestones to guide the design deliverables. The students then proceed through a systems design process including conceptual design, sub-system requirements, and quantitative trade-off analyses, using the full range of systems engineering, engineering science and professional skills developed during the degree course. The course emphasises teamwork (both team leadership and membership), communication skills (formal and informal, written, and oral), team and personal management and a professional approach to engineering design.

Students will complete the course over two consecutive semesters. A new intake will begin the course each semester. Therefore, the two semesters will be referred to as the initial and concluding semesters.

Course description
Mode of Delivery In person, and autonomous group work
Prerequisites You must enrol in this course over two consecutive semesters.
To enrol in this course, you must have completed ENGN3300 and at least 18 units of ENGN3000/4000 courses.
Incompatible Courses ENGN4221
Course Convener Dr Zena Assaad
Email
Linked.In Dr Zena Assaad
Office Room: Birch Building (#35): B2.44
Student Consultation Book a meeting via email.
Course email
Tutors Details about your tutors can be found in Wattle.

Value in Capstone #

In Capstone, you should only be doing activities that help you to deliver value.

The Capstone Design Project aims to deliver real value to all stakeholders: the project hosts, other identified stakeholders, the project team, and other associated teams. We define “value” as the complementary development of your project outcomes and governance of the project, at a systems level as shown in Figure 1. There is no prescribed outcome for projects, and each project will have different goals and challenges.

Determining value in a Capstone Projects
Determining value in a Capstone Project

Many Eyes Process: Feedback in Capstone Design Project #

The Many Eyes Process encourages active participation throughout the evaluation process.

Capstone uses a 360-degree feedback process incorporating the opinions of ‘many eyes’. The Many Eyes Process is informed by four key stakeholder perspectives: self-evaluation, a ‘shadow’ or peer perspective, a tutor perspective, and a project host perspective. This feedback across multidimensional criteria gives the student team a better picture of how the project is tracking, as opposed to a single source of feedback which can be focused on the specific interest of the reviewer. This process was developed to ensure that even though they are working on different projects and are producing a different set of deliverables, we can consistently assess every team and individual student. The Many Eyes Process provides feedback throughout the Action Learning Cycle.

Capstone includes four project audit weeks which are spaced throughout the year. Audits provide qualitative and quantitative feedback organised by the stakeholder group, allowing your team to judge how the project is progressing and how to improve. Acting on this feedback will help you to deliver value to the project host.

Plan-Act-Reflect #

The Many Eyes Process comprises three stages:

  1. Collection of feedback through Project Reviews from students (self-evaluation), ‘shadow’ or peers, tutors, and project hosts.
  2. Reflection and Action on the feedback performed by the team.
  3. Careful consideration of data from all sources to award the progress indicator.

The pattern of project audits and tutor meetings aims to promote an Action Learning Cycle, where tutorials are designed to help groups go through a process of Planning, Acting, Collecting Feedback on actions, and Reflecting, as seen in Figure 2.

Action Learning Cycle in Capstone Design Project (image adapted from [The University of Sheffield](https://www.sheffield.ac.uk/lets/strategy/resources/evaluate/action-inquiry-igure)
Action Learning Cycle in Capstone Design Project

Project Audits: Inputs and Outputs #

The Audit process takes the Project Work as input and, through a team-led quality control process, provides valuable formative feedback on the groups project. The inputs and outputs of this process are shown in Figure 4.

The Project Reviews are made up of a quantitative evaluation of project quality, as well as constructive and actionable feedback because of careful and considered interaction with the work. Each are used differently from here: the feedback is used by the team to improve their project, and by the examiners as input to evaluate the quality of work.

Block diagram of the Many Eyes Process
Block diagram of the Many Eyes Process

Project audits: Marking Process #

The Many Eyes Process is used as input into the final determination of a progress indicator for each stage. This process generates inputs but is then considered individually by the examiners on a case-by-case basis, involving the review of comments, relative performance and -if necessary- a convener report. The stages can be seen in Figure 5.

Consideration from all sources
Consideration from all sources

See the Assessment Guide for a full run-down of the marking process used in Capstone Project.

Key course Information #

Project selection, team formation & key events #

Projects in this course come from industry, research, and community partners. You can also ‘launch’ your own idea for a project, provided the convener approves it before Project Selection night.

Project selection will take place during the first week of your initial semester. The process for choosing projects and forming teams is:

  1. Projects and project agreements will be listed on Wattle during O-week, with time for students to review before the Project Selection night.
  2. To select your project, you must attend Project Selection night and ‘interview’ potential project hosts. Project hosts will interview you too!
  3. On Project Selection Night, we suggest you partner with a friend, buddy, or classmate.
  4. After Project Selection Night and following successful completion of the course induction quiz, you and your ‘buddy’ will complete a Project Preference form (in Wattle), including tutorial availability. Preferences must be completed by midday Friday of week 1. Project hosts will also indicate preferences to the teaching team.
  5. After Project Selection night, project preferences will be used to form teams of 4-6 students through mutual agreement with the host, convener, and accounting for tutorial availability.
  6. Project offers will be made via Wattle on Friday afternoon of week 1 and must be accepted by the start of week 2. You will remain a member of this team and tutorial throughout the course.
  7. Student project agreements will be issued to students on Wednesday of week 2. These will be sent to your student email address. For more information on project agreements see Capstone Program Student Agreements

Key events #

Please make sure you are available for the following events:

  • Thursday Week 1, 5-7 pm - Project Selection night (only in the initial semester) - attendance required to join a team (via online conference software)
  • Week 10 Initial Semester - Mid-project Presentations - attendance required to demonstrate your work so far. For more information see the Assessment guide.
  • Week 10 Concluding Semester- Project Showcase - attendance is required to present and pitch your work. For more information see the Assessment guide.

Class Schedule #

Students and tutors, please take note of the following weekly schedule. *Notes: Bold indicates Important Activities all students are expected to attend.

Weekly schedule initial semester
Initial Semester
Week
Tutorial Activity Assessment or Task
0 - Release Project Briefs and project agreements -
1 - Introductory Lecture
Project selection night
Project Selection
Course induction quiz
Project offers
2 - Project acceptance
Student Project Agreements issued
3 Team formation tutorial - -
4 Audit 1 tutorial - PA1: Audit reviews and Team member evaluation
Project Repository and landing page
Concept of Operations
Initial WHS Risk Assessments
5 Audit feedback Tutorial Module I part A Response to PA1 feedback
6 Tutorial Module I part B Student Project Agreement deadline
- - -
7 Tutorial - -
8 Tutorial -
9 Tutorial Module II part A -
10 - Presentation Event
Module II part B
Mid-Project Presentation
11 Audit 2 Tutorial - PA2: Audit reviews and Team member evaluation
Draft System Design Documentation
12 Audit feedback tutorial - Response to PA2 feedback
Exam
period
- - Mid-Project Reflection
Weekly schedule concluding semester
Concluding Semester
Week (Project week)
Tutorial Activity Assessment
1 (13) Tutorial - -
2 (14) Tutorial - -
3 (15) Tutorial Module III part A -
4 (16) Audit 3 tutorial Module III part B PA3: Audit reviews and Team member evaluation
Systems Design Documentation
5 (17) Audit feedback Tutorial - Response to PA3 feedback
6 (18) Tutorial - -
- - -
7 (19) Tutorial - -
8 (20) Tutorial - -
9 (21) Tutorial Module IV part A Showcase Poster
10 (22) - Project showcase event
Module IV part B
Project Showcase
11 (23) Audit 4 Tutorial - PA4: Audit reviews and Team member evaluation
Draft Handover
12 (24) - - Final Project Repository and documentation
Completed Handover
Final Team Review
Exam
period
- - Professional Portfolio

See ANU MyTimetable details class locations and times.

Learning activities #

Tutorials #

The tutorials are structured to simulate a team business meeting. We aim to have three teams in each tutorial, and tutors act as your ‘supervisors’. Each team will have equal time during the tutorial to present a summary of recent work and discuss progress with your tutor and shadows. A template for the summary can be found on Wattle. During tutorials you will take on an advisory role as a ‘shadow’ for another team. Tutorials are an opportunity to examine how another team operates and provide suggestions where possible.

Tutorial attendance:

  • We expect students to attend the weekly tutorials.
  • Attendance is not compulsory but strongly recommended as you develop your project with the guidance or the tutors and feedback from your peers.
  • Your assessment will reflect your contribution and attendance via the audit process.
  • Tutorials provide the opportunity to be a good Capstone citizen as a shadow team member.

Audit Tutorials #

Project audits are focused on the independent review of your team’s work as recorded in your project repository. They are not an audit of your tutorial presentation, but this is an opportunity to demonstrate your recent work to your reviewers. Each team has equal time to update the class, including tutors and possibly conveners and project hosts, on the progress of their project. Teams are free to decide how to use this time is used; however, we strongly recommend that your team provide a 5-minute project update (with slides or handouts), with the rest of the time for questions. Excellent teams will anticipate the questions and have ready access to their repository and supporting data.

Modules #

During Capstone you will participate in four modules to assist you in developing specific skills for your professional engineering practice. Completion of these modules will help deliver value to your project and build your professional skills.

Area experts will deliver the modules over 2 x two-hour workshops as specified in the weekly schedule and may require the completion of pre-activities or homework tasks. Modules available will change each semester. Further details can be found on Wattle.

Expected Workload #

Capstone involves independent group work, supported by tutorials in a professional development framework. Your team is autonomous regarding how your time is best spent delivering outcomes for the project. This includes a small amount of structured time and a large amount of independent group work. You should put approximately 120 hours of work into the course over a semester, equating to 240 hours of work over two semesters. If you are spending more or less time than this, you should discuss with your tutor how to manage your workload better.

We expect each team to determine the most effective use of their time in consultation with their project host. This should consider the commitments of team members beyond this course including other courses and assessment, employment, internships, and timelines within the project. Where possible, your teams should complete their hours within the teaching semesters. We do not provide teaching support during teaching breaks and between semesters. We advise you not to expect the teaching team or project hosts to be available during December or January.

Learning outcomes #

  1. Technical. Synthesise technical knowledge and approaches to generate solutions to an open-ended engineering problem.
  2. Problem Solving. Develop, analyse, and critically evaluate alternative options to justify and generate solutions in a real-world project.
  3. Research Apply research skills and methodologies to identify, collate, summarise, and critically evaluate relevant literature, data, and sources.
  4. Teamwork. Apply project management and organisational skills to produce time-sensitive deliverables in a multi-disciplinary team.
  5. Communication. Transmit design decisions and solutions using appropriate media to professional and lay audiences.
  6. Reflection. Demonstrate and reflect on research, leadership, and creativity as an individual and within a multi-disciplinary team.

Assessment processes #

The Assessment Guide describes the assessment in detail.

The learning outcomes align with the following assessment processes:

  • Project audits and reviews (70%, group and individual indicators)
  • Mid-Project Presentation (10%)
  • Professional reflections on your professional development (2 x 10% submissions)

The Audit activities are coordinated around a Many Eyes Process, which is designed to give you relevant and timely feedback and guidance on your project. Details about this process can be found in this Guide.

General expectations against grades #

The following table provides a guide to what quality of work we expect to see at each grade level:

Quality of work expected at each grade band
Grade Expectations
Fail Work which is incomplete or displays an inadequate understanding of the subject matter or an inadequate grasp of relevant skills. Poor attendance.
Pass Work of satisfactory quality, which displays an adequate understanding of most of the subject matter and a sufficient grasp of relevant skills. Meets or exceeds project host expectations.
Credit Work of good quality, which displays a good understanding of the subject matter and a sound grasp of relevant skills. Delivers value that meets the expectations of the project host or target market.
Distinction Work of superior quality, which demonstrates a thorough knowledge and understanding of the subject matter, proficiency in relevant skills, and analytical, design and implementation ability of a high order. Delivers value that exceeds the expectations of the project host or target market.
High Distinction Work of exceptional quality, which demonstrates comprehensive understanding of the subject matter, mastery of relevant skills, sophisticated or original analysis, design and implementation, and outstanding quality in clarity, precision, and presentation of work. Delivers systems-level value that significantly exceeds expectations.

There is no pre-set methodology that your team needs to follow in this project. Students may choose to use the ANU System Engineering approach (ASEP), V-model, spiral model or other systems engineering approach. However, it is expected that teams will research not only technical aspects of the project but will also research the systems engineering approach that they will use and be able to demonstrate how they have aligned with that approach. Your project host may like you to follow a particular approach and should consulted in this decision.

Course governance: Approval processes for project activities #

This section provides details on processes, and policies that apply to project within this course such as insurance, project agreements including intellectual property and confidential information, expenses and Work, travel, Health and Safety (WHS) considerations.

Insurance #

Insurance is required if you travel off-site to meet with project hosts.

If you plan to visit or work on a host site, you must fill out the Student Activity Approval Form.

Submit your completed forms to the course convener via email. The convener will arrange for the form to be signed and sent to the insurance office. You will be contacted by email once the form has been signed.

The following information will be required to complete the form:

Insurance data
Field Value
Student Name, Number and Phone Your details
Course ENGN4300
Period The project start and end dates or visit start and end date
Organisation providing supervisor The name of your project hosts’ company or business
Location of experience Address of the project host workplace
Work experience or research Project supervisor The name of your project host
Description of work experience The reason for your site visit or field work
Phone Number Your project host’s phone number

Capstone Program Student Agreements #

The ANU Student Project Agreement is a formal recognition of the relationship between the project host, the ANU, and the student team or for internal projects, the ANU and the student team. It sets out key aspects of the relationship including the details of the parties, the nature of the project, i.e., a description of the project to the undertaken, its timelines, outputs, and responsibilities/expectations of the different parties. Some examples of the responsibilities/expectations include confidential information, intellectual property, work health safety, insurances etc.

The agreement for project hosts external to the ANU contains two parts:

  • ST00 P01 Industry Project Agreement - the agreement between the host and the ANU
  • ST PG02 Student Group Project Agreement - the agreement between the students and the project host

For internal ANU projects (those undertaken internally with an ANU school or college) the ST PG05 Internal ANU Student Group Project Deed will be used. This is an agreement between the students and the ANU.

Information relating to the particulars of each project are indicated within the project descriptions available on the course Wattle site. Project agreements for proposed projects will also be made available on the Wattle site prior to project selection. Students should familiarise themselves with the agreements of the three documents and the specific terms of any projects of interest, particularly intellectual property and citizenship requirements prior to project selection.

Once students have accepted an offer to join a team, they will receive instructions on completing their required Student Project Agreement from the CECC Employability Team. Instructions will be sent to your university email address in week 2 of your initial semester. Agreements must be completed prior to census date in the first semester you are enrolled in the course or your enrolment in the course will cease.

It is important that you take the time to understand your rights and responsibilities with respect to any of the clauses within the Capstone Agreements. You should seek your own independent legal advice before signing. Free legal services are available from ANUSA. If you do NOT obtain independent legal advice, this is your choice; however, the delegate at ANU will not sign the Agreement without written acknowledgement that you have been advised to seek independent legal advice.

By default, students own their Intellectual Property, outlined in the Student intellectual property policy. The default position in the project agreement is consistent with the ANU Procedure.

Some hosts may wish students to assign the Project IP (that is any Intellectual Property that a Student creates in connection with their Project that is not required for examination or assessment) to the project host (section 5 in ST00 P01 and section 9 in ST PG02 - Option B, or section 2 in ST PG05 - Option B), and this will be identified within the project description on the course Wattle site.

Students should follow the following process:

  1. Before selecting a project, be aware of the clauses relating to the project specified within the agreement. A summary of these clauses is included with the project descriptions and the agreements will be available on the Wattle page.
  2. Seek your own independent legal advice before signing.
  3. Follow the instructions provided by the CECC Employability Team. These will be issued via email to your students address in week 2 of your initial semester.
  4. You will receive an email notifying you when the agreement has been signed by the college delegate.

Capstone Program Student Agreements should be finalised by census date (end of week 6) in your initial semester.

Public presentations & posters #

It is a requirement of the course that students present their work to the student cohort in the mid-project presentation and the public at the final semester showcase via the display of a poster describing their work and potentially presenting a project pitch. Summaries of successful projects may also be used by CECC Marketing to advertise our engineering courses to the public via the web or other media. This may present challenges for students subject to IP and/or confidentiality agreements. However, it is usually possible to present work in such a way as to not violate any such agreements. If you are concerned, please discuss this with the course convenor. In all cases, whether subject to IP agreements or not, students should seek approval from their project host and other relevant stakeholders before any public presentation of their work.

Work Health & Safety #

You must align with the WHS standards of the place that you are working, as well as the ANU’s own standards.

Hazards, small or large, exist in any work environment. Understanding these hazards is a key responsibility of your team. This is particularly relevant if you are undertaking work in a workshop. We do not support students working in ad-hoc spaces that are not appropriate for the task on or off campus, and students should seek advice if they are uncertain.

Teams should demonstrate proper risk management processes for all activities within their project repository including awareness of safe operating procedures (SOPs) and records of any inductions or training that may be required by the team.

Students are encouraged to become members of the Engineering technology Hub or ANU Makerspace and follow their inductions and SOPs.

Teams may apply to have access to project space in the Birch building for storage of projects and assembly and testing activities that do not require specialised equipment. Details of the application process can be found in the section on Project Space. Students should complete any fabrication activities within the Engineering Technology Hub or ANU MakerSpace.

Should students require use of the ANU Engineering Workshop or other laboratory facilities, they should consult with the course convener.

Relevant Policies #

All students should understand where relevant:

WHS Hazard and Risk Assessment #

Risk assessments for activities completed at the ANU
For activities on an ANU site (such as the Engineering Technology Hub, ANU MakerSpace or Engineering Workshop), teams are not required to seek approval for activities that have a current ANU risk assessment (for example, use of a 3D printer within the Technology Hub) for which they have been inducted.

If students are conducting a new activity, task or process, using new materials or operating equipment for which there is no risk assessment they should consult the course convener as approvals may be required.

Activities with a low residual risk can be approved by the Course Convener. Activities with a risk rating above low require consultation with your course convener and advice from the CECC WHS Team. Final approval will be conducted in line with the Risk Assessment (RA) “Approval required” sign-off process as outlined in the table below. Students should not complete any activities without approval.

RA Approval required
Residual Risk Level Authority required
Low Supervisor (Course Convener)
Medium Supervisor (Course Convener)
High School Director or College Dean
Extreme Chief Operating Officer

Teams are expected to review and update any riak assessments at regular intervals throughout the project. If there are any changes to the project activities or the environment in which the students will be completing these activities, updated risk assessments should be resubmitted to the course convener for approval.

The following documents should be used when conducting a risk assessment: ANU Appendix B - WHS hazard and Risk Assessment Template using the ANU Risk Assessment Matrix

Risk assessments for activities completed off-site
You must have insurance before travelling off-site to visit a project host or complete project activities. As part of that process, you must identify the reason for your site visit and depending on the nature of activities the convenor may require you to provide information related to site inductions and risk assessments for activities. Risk assessments using a project host template may be accepted or students may be required to complete a WHS hazard and risk assessment for the activities using the ANU templates.

Project Space #

Limited storage space and workspace for Group project teams is available on-campus in the Birch building. This space is shared with teams completing ENGN8170 Group Project and other courses. Use of the project space is subject to the following conditions:

  • Use of the Project Room is a privilege, not a right.
  • All team members should be inducted for access to the Engineering Technology Hub before applying for access to the Project Room.
  • Teams that use the space in an inappropriate manner will lose access.
  • Students must comply with the opening hours for the Birch building.
  • Students must vacate the room if it is booked for another class.
  • The Locker space may be used for storage. Construction, testing activities (check with the course convener) or fabrication activities should be conducted in more suitable locations such as the Engineering Technology Hub or ANU Makerspace.
  • At the end of a team’s enrolment in the course all items must be removed, or they will be disposed of.

Applications to use the space begin by ensure all group members are inducted to the Engineering Technology Hub and completing the Capstone Project Space Application Form.

Expenses #

How to deal with expenses you may incur

We do not expect students to pay for any costs associated with the course. In general, any significant project costs should be covered by the project host. However, there may be times when teams choose to cover minor costs for project items such as materials or consumables. To offset these costs, a limited number of Microgrants will be available to teams that comply with financial reporting requirements.

The Microgrant operates out of a limited pool. We will do our best to balance the circumstances of your project with the considerations of other teams.

The grant can be used for activities relating to:

  • hardware for prototyping or producing an artefact,
  • consumables directly relating to producing a product.

Microgrants will not be approved for materials and services not otherwise accessible on campus. If it is not clear how the expenses add directly value to the project, the team will not be eligible for a Microgrant.

Purchases of materials that may be considered hazardous must be discussed with the course convener.

Approval #

Pre-approval is required. To obtain approval for a Microgrant, send an email to the course convenor (and CC your tutor for endorsement) outlining:

  1. A short summary of the project needs for expenditure (in the email).
  2. An itemised list of proposed or incurred expenses (as an attachment for our records).
  3. A link to full financial records for your project (e.g., records from your repository).
  4. A link to materials demonstrating research into purchase options and justifying the decision (a link to your repository).

The convener will confirm funding approval (or otherwise) via return email.

Disbursements #

After approval of a Microgrant, funds can be accessed the following ways:

Purchase (Preferred)
For situations where the team is unable to cover the costs of the purchase in advance, the School can organise purchase.
  1. To initiate the purchase, please contact the convener to obtain instructions.
  2. Purchase order or online order information will be required for the purchase to be processed by the School administration team.
Reimbursement
For situations where the team has purchased items using their own funds
  1. To be reimbursed, one team member will need to submit a claim via the Finance Self-Service Portal. Please click “Reimbursement” > ’Create Reimbursement".
  2. When required to select the supervisor, select either Lucia Lu, U4726473 or May Than Kyaw, U5609033.
  3. Click on “Add Lines” and fill out the line details using format the MgrantENGN4300_First Name initial and Last NameUniID (e.g.: MgrantENGN43000_Msmith4625479).
  4. Combine all receipts (including email approval) into one PDF and click on “Add Tax Invoice/Receipt” to upload.
  5. Read and agree to the declaration.
  6. Click on “Submit”.
  7. Once confirmed, your reimbursement will be forwarded to the relevant School Admin to process the reimbursement.

A reimbursement takes 7-10 business days to complete. Please submit one application by each team with one of your team member’s Uni ID. The School Admin will require student’s current bank details held at ISIS.

Considerations #

If, for any reason, you are in a situation where your project and learning will be at risk because of funding limitations, please talk to the convener. We are also happy to talk to hosts directly about funding issues.

Travel #

If teams are travelling domestically (i.e., outside of the ACT) or internationally and need to be covered under ANU insurance, they must compete an ANU travel form. Please discuss any travel plans with the course convenor.

Course philosophy, notes, and comments #

This section discusses many of the philosophical underpinnings of this course.

Being a Shadow #

Are you a Shadow, Observer or Red-Teamer?

During the course, you will take on two key roles: ‘team member’ and ‘shadow’. You will give and receive feedback in this role. This is a form of 360-degree feedback and is commonplace in many industries today. The role of Shadow is designed to provide critical review and an alternative perspective to project teams. A shadow also experiences how another team operates and can reflect on how these insights can benefit their own team.

We find that students can sometimes find this role challenging. The radio program ‘Best Practice’ has a great description of the role of Shadow, and how it is used in industry. “Red-Teamers” are the modern equivalent of the “Office of the Devil’s Advocate”. Successful teams in leading companies and organisations are increasingly using Red-Teamers - these are people specifically brought into a project who critique decisions and by doing so extend the project team’s thinking. The perspectives of “Red-Teamers” are not always right, but they are always valid.

So, if you’re not an active shadow, maybe you’re letting yourself and your shadow team down!

Playing the devil’s advocate or Red Teaming is a good way to avoid the trap you can fall into when ‘grading your own homework’. Asking an outsider to go through your work with an unflinching critical eye, according to Bryce Hoffman, can make good plans great or perhaps even save you from a disaster. - ‘Best Practice’, Saturday 5 August 2017

Being a Systems Engineering Professional #

When undertaking a Capstone Design Project, you are also acting as an ambassador for ANU’s ability to train world-class, industry-ready professionals

Everything you do in your project must be professional - respecting the project host, your team, your peers, and yourself.

If you find yourselves doing something that does not appear to be a good use of time, or seems unnecessary, then STOP and REFLECT - do you really need what you are doing, have you missed something, can you use your time better?

The ‘Triple Bottom Line’ #

To deliver on your project, you should also consider a ‘Triple Bottom Line’.

  • do the best you can for your project host or their business,
  • be a humble learner, and learn as much professionally as you can,
  • demonstrate the quality and value of the work you’ve done and highlight the future work.

These three objectives are interlinked. Focusing on one to the exclusion of the others will lead to sub-optimal outcomes.

  • learning about teamwork, stakeholder engagement and applicable technology will lead to improved satisfaction of project host needs and, ultimately, better outcomes.
  • you will need to learn a great deal during the course to satisfy the needs of your project host. In doing so, you will be able to present a great story in your project audit, leading to great outcomes.
  • staying humble as a learner - you are presenting your work to domain experts. It is entirely professional to demonstrate you understand the limits of your work.

In Capstone, the focus is on ‘value’. If you are using language such as ‘marks’, ‘grades’, ‘scores’, or ‘points’, you are missing the point. Instead, focus on how your work will be ‘evaluated’ - the value you are generating for your host through the project outcomes and processes.

As a capstone course, the Capstone Design Project is designed for you to implement what you already know into a project, and independently learn what you need to know to complete the project. If you and your team are properly extending yourselves, you will find that there are gaps in your knowledge, from practical to technical, and this course is a great opportunity to fill those gaps.

There are great resources available for managing professional engineering projects:

And relevant standards can be accessed via the ANU Library:

  • ISO/IEC/IEEE 15288 - Systems and software engineering - System life cycle processes
  • ANSI/EIA 632 - Processes for engineering a system
  • ISO/IEC/IEEE 26702 - Systems engineering - Application and management of the systems engineering process
  • ISO/IEC/IEEE 29148 - Software and systems engineering - Life cycle processes - Requirements engineering
  • ISO/IEC/IEEE 16326 - Systems and software engineering - Life cycle processes - Project management

And the graduate competencies that you are demonstrating in the project:

When researching journals and industry standards for your project, remember many can be accessed via the ANU Library.

Other resources can be located on the course Wattle site.

Presenting your work #

Your professional responsibilities are on show here. Refer to the Engineers Australia Code of Ethics Section 1.3, and/or the Australian Computer Society Code of Professional Conduct Section 1.2.6.

Professionalism at Meetings #

The aim of the Tutor Meetings is for you and your team to develop and practice the ability to succinctly present work, and to then address comments and questions in a coherent manner. Tutorials are an opportunity to get feedback from your peers, tutors, mentors, and other stakeholders. They are also an opportunity for you to develop your ability to understand and critique the work of others, and to ask well-formed questions that improve your understanding.

With this context in mind, it is important for everyone in the room to:

  • Introduce project hosts and other stakeholders who are present.
  • Engage in the process - no mobile phones, laptops, et cetera.
  • Be respectful of others - particularly the team presenting and their project host.
  • While robust, frank, and open discussion is encouraged, it is not acceptable for people to abuse and attack each other. The point of robust interactions is to help improve approaches and outcomes.

Professionalism at Online Meetings #

Some guidelines for making online meetings smoother and more productive:

  • Nominate a meeting facilitator to run the meeting, invite people to speak and monitor the chat.
  • Use the hand-raise feature when you have a comment or question.
  • Use the mute button when you are not speaking. *Cschedule regular pauses to give others a chance to comment, ask questions or add to the chat.
  • Think about your background - make sure your surroundings or virtual background are appropriate. Background noise can be an issue. Try to find a quiet location and mute your microphone unless speaking.
  • Video on if possible and keep eye contact with the camera - it is always nicer for participants in a meeting to see each other. If you need to turn off your video, try uploading a profile picture.
  • Keep the chat respectful and appropriate.

Presentation tips #

  • Be honest and open - put your cards on the table. There are people around who know the truth.
  • Be enthusiastic about your work and proud of what you have achieved.
  • Act like a team. No backbiting or contradictions.
  • When pitching - everyone to be engaged in the presentation - we can learn a lot by looking at those who are not presenting!
  • Talk about what you have learned from both failure and success - technical and project perspectives.
  • Try to always have something concrete to show or demonstrate.
  • Remember that some people will have no idea what you are doing. Set the scene for the context for the system you are developing, what the project host’s business is and what they want you to do.

Repository tips #

  • Reviewers will use your Audit Landing Page to guide their review. Make it easy for them to find the work you want reviewed.
  • Make sure you refer to evidence and rationale for decisions made by your team. For example, meeting minutes, slack communications et cetera. Many teams will maintain a wiki as a kind of ’engineering logbook or ‘decision log’.
  • Point reviewers to exactly where they can find your work - don’t expect them to trawl through repositories looking for material to review - make sure you point them to work that addresses the evaluation criteria. Make use of directories and appropriate filenames to aid with this.
  • Make sure all reviewers have access rights to read your repositories.
  • If you have physical artefacts, you want reviewed, then make clear to the reviewer how they can inspect them - e.g., contact details to arrange an inspection. Include photos or videos of your artefacts in your repository (appropriately named).
  • It is up to you to decide how you present your work for review. If you don’t allow your reviewer to review your work properly and fairly, then you should not expect a good evaluation.

Conducting Project Audits #

Projects are reviewed by tutors, team shadows (peers) and the team itself using our Many Eyes Process.

This page provides some guidelines you might consider when conducting your audit.

Being a reviewer #

Make sure you are clear what the role of a shadow is

Your task as a reviewer is to explore the work completed by the team and to use what you find (or don’t find) within the repository and landing page to complete the Project Review.

We expect that conducting an Audit and submitting the Project Review would take approximately 1 hour, outside of the tutorial. A good process is to:

  • Familiarise yourself with the Audit marking criteria, and the Project Review form.
  • Review the work completed by the team and form an overall view as to its quality.

More specific tips: #

Look at the actual work done
It is important that you look for evidence of the actual work completed by the team. If you cannot find the actual work done, then contact the team so that they can improve their work.
Look through the repositories
Every team is expected to have put in place mechanisms to store and track the artefacts they produce during their project. The repositories should be well organised and incorporate version control - especially for software projects. If there is no repository, then provide feedback such as No evidence, Work is inaccessible. Check that version control is being used. A complete version history is a good way to understand the processes and progress of work undertaken by the team. If, for example, a team has just uploaded a bunch of work in recent days, then provide feedback such as Ad-hoc processes.
Look for evidence
If the team claims to have completed specific work, then you must check that they have actually done that work and that it is of real value. The Audit landing Page should refer you to this evidence (could be documentation, meeting minutes, prototypes, code etc.). For example, the inclusion of a project plan needs to be backed up with evidence that they are using the plan. If they are not using the plan, then it is of very little value.
Look for decision-making
Teams are expected to make, implement, and track decisions during their project. You should look for evidence of this during your review (documentation, meeting records etc.). It is very important that decisions are supported with evidence. For example, there should be evidence demonstrating the feasibility of any requirements specification or detailed project plan produced by a team. This may take the form of stakeholder consultation, experimentation, prototyping, evaluations, research, et cetera.
Work quality
You can use the notes sections of the Project Review to comment on the quality of the team’s work but be constructive and offer suggestions for improvement where applicable.

Coursework expectations, policies, and processes #

Absences & misadventure #

It is expected that you will attend all classes, but as senior students at ANU the responsibility is on you. You should address any absences for worthy reasons in a professional way; for example, notifying your team and tutor of absence so that your team can record this in the meeting minutes.

Late submissions and extensions #

Reasonable requests for extensions, special consideration and accessibility will be considered with courteous regard to the due dates. Students must use the ANU Assessment Extension Request application to apply for extensions. If you have any concerns, please talk to your team members, tutors, and convener (very) early. No leeway will be offered after due dates. Due dates are listed in the Assessment Guide.

Late submissions will not be accepted for the Audit processes; these must be submitted on time.

Submissions, feedback, and improvement #

Links to digital repositories and other submissions will be submitted through Wattle. Feedback on your submissions will be available through the Wattle Gradebook.

Feedback is widely a misunderstood concept in education. In systems theory, feedback is a systems process that drives behaviour (such as negative feedback in an electronics circuit) towards an objective, rather than being the outcome of a process.

In this course, there are many formal and informal processes to collect formative feedback to help you produce the best work you can. These include regular opportunities with your tutor for specific feedback before Project Reviews. Your peers, both in your team and otherwise, are a central part of this process.

Very little ‘summative’ feedback will be given with the return of assessment - take the ample opportunities you have in this course to get formative feedback before you submit.

Marking and assessment #

The work you do in this course should transcend the normal assessment processes; the value of the outcomes from your project should provide you with examples of experience, mentoring and an application of systems approaches to engineering problem solving that will help launch your career.

However, at this stage the norms of university processes and student expectations require us to give you a grade. To this end, the assessment processes are designed to evaluate and benchmark the work that you actually undertake on your project, to help you to plan, design and evaluate your own and each other’s work, and take on feedback in a constructive way for the improvement of your project and own professional development.

Project Audits are the main assessment activity in this course. Audits are undertaken in the stages of Audit, Review and Feedback. These are described in the relevant assessment item.

Resubmission of assessable works #

Groups may be required to resubmit work where the submission is deemed below acceptable quality or requires major revision. The course convener shall notify groups within one week of submission and negotiate a plan for resubmission. Work falling into ‘Unsalvageable’ and ‘Unacceptable’ will likely fall into this category.

Referencing requirements #

There are no specific referencing requirements. You should consult with your project host where referencing is required, and align with norms in the discipline you are working in.

Appropriate use of Generative AI tools #

Gen AI Tools are ALLOWED for some of the assessments in this course.

We encourage the use of AI as a tool. However, students should note that ANU systems engineering core courses, particularly the Capstone project, are designed to assess critical thinking skills and therefore students will not achieve a pass grade if they only rely only on the material that AI tools can generate. In other words, you must critically evaluate and carefully edit all your work.

The use of Generative AI Tools (e.g., ChatGPT) is permitted for assessments in Captone. For individual assessment (reflections), submissions must include a description of how the use of Generative AI tools were used (or not) in completing the assessment and the tools must be cited where appropriate as outlined in the assignment specification. General guidelines regarding appropriate citation and use can be found on the ANU library website (https://libguides.anu.edu.au/generative-ai).

When using Generative AI tools students should considering the following factors:

  • Privacy - in particular the possible misuse of personal or confidential information. No names, student ID’s or contact information. Do not upload any copyrighted materials such as images, text, code, designs, trademarks, patents etc unless you have consent. You should consult your project host before considering using AI tools.
  • Bias - AI models are trained on large text sets to create human-like responses however, these tools do not evaluate the correctness of the training materials and can be influenced by the bias of those that created the algorithms. This means that the responses incorporate the bias we see in society such as gender and racial bias.
  • Critical thinking - have you appropriately evaluated the responses generated by the AI tool? Have you verified the information provided? Have you synthesised this output with other research and your own knowledge and critical thinking? Do the responses make sense in the context of your project?
  • Professional and ethical responsibility - Are you demonstrating ethical conduct in your use of AI? Are you acknowledging the sources of your information and critically assessing the accuracy, reliability and authenticity of your work?

Grievances, issues, and complaints #

If you have a problem with the marks you receive, there is a process that you can follow to come to a resolution on the issue. It is worth remembering that the teaching team has a wealth of experience in professional practice and mentoring junior engineers, and their perspective on your work can be a shock to students who have not been challenged outside of the sandbox of academic practice.

If you would like to appeal your grade, this process must be initiated within two weeks of receiving your mark:

  1. Discuss the issue with your tutor.
  2. Your tutor will provide further comments, clarification and sage advice if needed.
  3. If the issue remains unresolved, you can:
    • ask the course convener to re-mark the assessment - this requires you to first submit in writing exactly what your concerns are and how the marking has missed some significant aspect of your work against the criteria. Not including this information will lead to the convener denying this request.
    • ask the course convener if you can resubmit (typically reserved for failed work) - this requires negotiation with the course convener.
  4. If you are unhappy with the course convener’s response, you can appeal to the Associate Director (Education), in consultation with the course convener as described by the appropriate policy.

Final Grades #

Final grades are subject to deliberations at School and College examiners meetings. We try hard to align the course grade expectations with the expectations of the examiners meetings to avoid scaling or grade shifting to meet University expectations.

Academic integrity #

All students must read and understand the ANU guidelines on Academic honesty & plagiarism.

Any sign of academic misconduct in any assessment task will be fully investigated in accordance with the ANU Academic Misconduct Rule 2021.

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, 2024, “Capstone Design Project Course Guide”, ANU, accessed <>, <https://eng.anu.edu.au/courses/engn4300/students/ENGN4300_Course_Guide_S1.pdf>

Document Information #

Document Information
This document ENGN4300 Course Guide [Download as PDF]
Format PDF preferred, also available as web page
Document type Information and Procedures
Purpose Overview of course requirements, governance and processes for students undertaking ENGN4300 Systems Design Project
Semester Semester 1, 2024
Audience Current Students
Contact
Version v2024.S1.01
Related Content ENGN4300 Assessment Guide [Website] [Download as PDF]

Change log #

2023.S1.01: 2022-11-21

  • Initial draft and restructure for Sem 1 2023.

2023.S1.02: 2023-02-14

  • Updated to account for new Capstone Agreement.

2023.S1.03: 2023-05-29

  • Update terminology from client to project host.

2024.S1.01: 2024-02-01

  • Changes and restructure for Sem 1 2024, including inclusion of expectations for use of generative AI tools and updates to procedures for Capstone Project Agreements, WHS risk assessment and reimbursements.

2024.S1.02: 2024-07-10

  • Updates to procedures for Capstone Project Agreements and processes for project space.
bars search times