Project Reviews

Project Reviews are used to assess the progress of each team. They are designed to provide a fair assessment of each team even though the work undertaken by each team can be very different.

There will be three project reviews each semester. Each review will comprise three activities totaling 25% of your final mark:

Figure 1 depicts an activity diagram that summarises the activities of teams, individual students and tutors during the Project Reviews.

Project Review Activities

Figure 1: Project Review Activities

Project Report [15%]

A snapshot of your group’s work and progress

Requirements
Provide reviewers with a summary of recent work. It should:
  • orientate the reviewer to the recent work
  • be short and to the point (3-4 pages)
  • include references to the artefacts you have produced including, as applicable, documentation, CAD models, source code, test data and prototypes.
  • be accessible to reviewers (including examiners, tutors and all observers), including access to repositories and physical artefacts
Refer to Indicative Progress below for the kind of progress we expect to see at each review.
Marking criteria
Marks for this assessment task are based on evaluations of the project work you have completed. There are no marks for the report itself - it’s purpose is to guide the reviewers through the work your team has completed.

Your work will be assessed against the following criteria:

  • Value - the value of your work to your client and, where applicable, other stakeholders
  • Professional Practice - evidence of deep technical knowledge and use of appropriate approaches to generate solutions
  • Problem solving - demonstrated critical evaluation and justification for the proposed solutions
  • Stakeholder engagement - your approach to developing and maintaining a strong relationship with key stakeholders, including your client and/or users
  • Teamwork - effective teamwork and associated processes
Assessment Process
Projects will be assessed using the Common Assessment Process (CAP).
Tag Reports will be completed for each project by:
  • your tutor
  • each member of your team (self evaluation)
  • each of your tutorial observers (your peers)
  • other TechLauncher participants if there are grounds to do so
Contribution Reports will be completed for your team by:
  • your tutor
  • each member of your team
  • other TechLauncher participants if there are grounds to do so
Submission
Project Reports are to be submtted via Wattle, by 0900 Monday on review weeks (ie. weeks 5, 8 and 11). One submission per group required.
Tag Reports and Contribution Reports produced by team members, observers and tutors are to be submitted via Wattle, by 1700 Friday on review weeks.
A printable version of the Tag Report can be found here
See also
Tips and suggestions
Indicative progress

Peer Evaluation [5%]

Assessing the quality of your Tag Reports

Requirements
As indicated above, tutorial observers will complete and submit Tag Reports on the work completed by the team they are observing. The aim of this ‘Peer Evaluation’ assessment is to evaluate the quality of these Tag Reports.
Marking criteria
Your Peer Evaluation mark will be based on:
  • the usefulness of the Tag Reports you submit for the review
  • the rationale you provide for the tags you select in the Tag Reports
  • clear evidence of having engaged faithfully in the review process
Assessment Process
The quality of your Tag Reports will be assessed by the course examiners.
The examiners will use automated tools, including AI, to help with their assessment.
Submission
There are no submissions required for this assessment item.

Project Pitch [5%]

A brief update pitch on your project

Requirements
Each team will deliver a 5-minute pitch for tutors, examiners, other teams, clients and invited guests. Each pitch will be followed by 5 minutes for questions.
Your pitch should cover the following:
  • What problem are you solving
  • How are you solving it
  • If applicable, a demo of the latest developments
  • If applicable, ask for the things you need to continue the project
Marking criteria
Your pitch will be assessed against the following criteria:
  • Content - the material covered in the pitch
  • Presentation - the quality of the delivery
  • Response to questions - quality and professionalism in answering questions
Assessment Process
Project Pitches will be assessed using our Common Assessment Process (CAP).
Tag Reports will be completed for each pitch by:
  • your tutor
  • each member of your team (self evaluation)
  • other attendees at the presentation
Submission
Tag Reports are to be submitted (by tutors) via Wattle, by 0900 Monday following review weeks ie. weeks 6, 9 and 12)
A printable version of the Tag Report can be found here
Location and Time
Project pitches will be run in sessions of 1 hour with 3 pitches. Sign ups will be available in Wattle in the week leading up to the pitches
While students must attend the session in which they are pitching, they are encouraged to attend other sessions to gain perspectives from a broader range of projects
Pitch times and locations can be found here.

Tips and suggestions

For preparing for your Project Review

Never do anything that does not add value
Everything you do in your project must add value for the client, your team, your peers and/or you.
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 TechLauncher ‘Triple Bottom Line’
In order to do well in project reviews, you should also consider a ‘Triple Bottom Line’
  • Do the best you can for your client or business
  • Work on learning as much professionally as you can
  • Get as good a mark as you can

These three objectives are interlinked. Focussing on one to the exclusion of the others does not give the best result even for the one that is the sole focus. For example:

  • Focussing on marks will not necessarily get you the marks because you may have neglected the needs of your client or business
  • Learning about teamwork, stakeholder engagement and applicable technology will lead to improved satisfaction of client needs and, ultimately, better marks
  • You will need to learn a great deal during the course to satisfy the needs of your client. In doing so, you will be able to present a great story in your project review, leading to great marks
  • Doing the best you can for your client or business may lead to good marks, but only if you follow the assessment scheme and submit work on time

Presenting your work :

  • Be honest and open - 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 look engaged. No Phones
  • Talk about what you have learned from both failure and success - technical and project perspectives.
  • Always have something concrete to show or demo
  • 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 client’s business is and what they want you to do
  • Reviewers will use your report 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 comms etc. 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 and google drives looking for material to review. Make sure you point them to work that addresses the evaluation criteria stated above. Make sure they 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 - eg. contact details to arrange an inspection.
  • It is really up to you to decide how you present your work for review. If your ‘report’ does not allow your reviewer to properly and fairly review your work, then you should not expect a good review

For preparing your evaluations

  • Printable versions of the CAP forms are available for taking hand-written notes during activities such as tutorials and pitches. These notes can then be used to help you complete the on-line Wattle forms by the applicable deadlines
  • use the Project Report submitted by the team as the basis of your review. You are required to review the artefects produced by the team and referenced in their report.
  • it is important that you get to know the team you are evaluating. This will help you provide a high quality and fair review of their work. Attending the team’s tutorials is an important part of getting to know the team and what they are doing.

Indicative Progress

Because every project will be on a different timeline, tutors will work with you during the tutor meetings to help you understand what your progress should look like. A really loose indication of timing is:

Single Semester Projects (eg. ENGN4221)

Project Review 1 (week 5)
  • clear idea of the project requirements and goals
  • met with the client, checked requirements, etc
  • initial prototypes, sketches, designs, processes, etc
  • team has a clear idea on how to provide value to the client
  • appropriate documentation as evidence of progress is up to date (covering Requirements analysis, Functional Behaviour analysis, Architectural synthesis and Validation & Verification)
Project Review 2 (week 8)
  • the design, idea, prototype, etc has been tested in the hands of the client
  • feedback from the client is now being built into a second iteration of the idea
  • team is moving towards thinking about hand-over and what will happen beyond the immediate project
  • appropriate documentation as evidence of progress is up to date and revised where necessary (covering Requirements analysis, Functional Behaviour analysis, Architectural synthesis and Validation & Verification)
Project Review 3 (week 11)
  • design/idea/process has been validated
  • team has prepared hand-over material for the next phase of the project
  • appropriate documentation as evidence of progress is up to date and revised where necessary (covering Requirements analysis, Functional Behaviour analysis, Architectural synthesis and Validation & Verification)

Two Semester Projects (eg. COMP projects)

Semester 1, Project Review 1 (week 5)
  • team established and cohesive. The use of brainstorming or ideation sessions early on has proven beneficial in terms of getting started and establishing mutual respect within a team
  • a strong relationship with client or market, and tutor
  • a good understanding of their client or market
  • an initial high level plan
Semester 1, Project Review 2 (week 8)
  • set of requirements
  • start-up projects will have explored their proposed business model using a tool such as the Businesses Model Canvas.
  • explored what is feasible by developing prototypes, identifying libraries, frameworks and other tools for later use, and/or undertaking appropriate research and experimentation
  • functional engineering environment including a repository, version control and configuration management, documentation standards, planning and issue tracking tools, and team communication mechanisms. Tools worth considering include gitlab.cecs.anu.edu.au, trello.com and slack.com.
Semester 1, Project Review 3 (week 11)
  • a Minimal Viable Product (MVP). This will involve the execution of appropriate planning, management, requirements engineering, architecture, design, review and testing activities
  • Start-up teams may have a product in the hands of users (perhaps a limited set of early adopters/testers)
  • Client projects may have delivered an initial version of their software to the customer. If this is not achieved now, it should be delivered early in the second semester of the project
Semester 2, Project Review 1 (week 5)
  • will have a functional product that is close to complete.
  • have followed and adapted their plan, and applied appropriate systems and software engineering practices
Semester 2, Project Review 2 (week 8)
  • will have deployed their product
  • supporting users
  • enhancing product
Semester 2, Project Review 3 (week 11)
  • finalise project
  • attention to the transition of their project to the client or the next stage of the project

Updated:  06 May 2017/ Responsible Officer:  Head of School/ Page Contact:  TechLauncher Course Webmaster