General Engineering Projects

From Wikiversity
Jump to: navigation, search


This is an overview of General Engineering Project instructor/student interactions and grading. The actual projects are here.

Engineers are hidden from the public like precious jewelry whether working on military projects or commercial projects. Sometimes the engineering work is kept secret. Documentation is unique to the company and exists only for internal purposes.

This is a wiki. It is being used to capture engineering project documentation and provide a method for grading it. The transparency and public domain nature of this documentation is unique. These are the goals of this engineering project documentation:

  • Both the exact same failure or success can be repeated from reading the project documentation
  • Others can jump in, find a starting point and push the project forward
  • Existing documentation serves to set starting point expectations
  • Trust wikiversity to continuously develop and polish documentation
  • Instructors can see past task evolution, time and materials consumed for planning purposes
  • Clear enough that multiple instructors grade it consistently
  • Attractive enough that casual browsers find it useful
  • Start with the [|CDIO syllabus].

This project is expected to take decades. But a starting point has been established.

This document focuses on an over view of the grading system. For documented projects, forms and samples go the projects themselves!


Better Competition Documentation[edit]

Some student engineering competitions have a documentation requirement, but it is evident that no best practice has evolved after looking through these documents. Most of these documents are only published once a year and only the previous years documents are available on line. Thus no knowledge base evolves. Filling this gap are DIY sites which are all tutorials, not engineering project documentation.


The term "Design" is used here to generally describe the gateway between freshman engineers and materials/tools. The D of CDIO] is much more specific/narrow definition.

Freshmen are first inspired by the outside world of things. Limiting the times they walk through the gateway (to hands on experiences), cripples them. Bloating "Design" to the point that they can only walk through the gateway once will just turn freshmen off to engineering.

Let the project context, it's history, the materials on hand, the talents and abilities, the enthusiasms and conversations, narratives and presentations, and success experiences guide the definition of design in the moment. But have a design gateway. Require your electronic signature, your physical signature or the act of moving a design document from user space to wikiversity article space to be the gateway.

"Design" in the form of a physical drawing, a schematic, a list of materials, input and output .. has to be balanced with the overwhelming need for "Hands On." The goal is to transition students from "Hands On" to "Design". Name the gateway "design."

Exactly when the hands on experiences occur is ancillary, incidental and should not impact a students grade. Hands on experiences only exist to provide a reason for meeting as a team, creating tasks and documenting something. Student feelings have to be matured (don't wait for seduction), their source of inspiration has to change (frustration as inspiration), their definitions of engineering success (documenting what doesn't work) need to change. Hands on experiences are expensive.

The focus on design is not a marginalization implementation or operation. The bulk of engineering is in implementation and operation.

Not DIY Tutorials[edit]

Most of the world expects tutorials with steps that lead to success. Engineering projects can result in tutorials, but tutorials are not engineering documentation. Documenting what hasn't worked is more difficult, and ultimately more important to a successful project involving many engineers. Engineers document failure.

So what is engineering project documentation if not DIY tutorials? Engineering is a creative process that involves an objective that has never been tried before, a guess at what to do, clear descriptions of dead ends and failure, proposed next steps and an occasional tutorial celebrating a success. In this format, projects are open ended, never ending and more driven by a sense of art than science and business. Projects are driven more by inspiration than requirements. The goal is to capture a knowledge base of attempts (failures) rather than successes (tutorials).

Scientific Method Kills Engineering[edit]

The scientific method is a close cousin when focusing on replication and reverse engineering. But otherwise, it cripples freshman engineering students if referenced.

Asking for a hypothesis creates a competitive, idea ownership, territory grabbing conversations. Most of the silent people don't feel qualified to even talk ... and these are the most careful, thoughtful and respectful students. The best potential engineers say nothing. Slackers and cave dwellers are created rather than teams of engineers working together.

Try encouraging questions. Admit not knowing yourself. Begin suffering the conversations that trail after "But you are our teacher." Students have been taught that questions are a sign of "not doing your own work." Questions are a sign of weakness. Admitting no knowledge looses respect. Engineering is everyone on the edge of the unknown, asking questions, harvesting the collective mind, working as a team. Reputation is enhanced by facilitating conversations, not owning solutions.

Asking for procedures causes students to try and visualize 20 steps before doing something the first time, or forces students to write after the fact. Visualizing procedures beforehand leads to feelings of inadequacy. Writing after the fact focuses on success, not failure and most detail is lost.

Demand that students write what they are going to do, before they do it. Ask that they write while doing and then stop and reflect, analyze and figure out the next steps (RANT). This is done in a notebook. It will be chaotic, random and full of wrong turns, blind alleys and frustration. The weekly report written electronically in a student wikiversity user space is a summary of this chaos.

Don't ask for conclusions or analysis. It causes panic attacks is some students. Instead of going inside themselves and reflecting, they automatically look outside themselves for expectations, form, boundaries, detail level, error analysis and lots of other context that exists in other educational experiences. But they find nothing in engineering because (ideally) there is nothing.

The scientific method exists in engineering projects, but it has morfed into the GoingToDo, Doing, RANT triplets in an engineering notebook. The "triplets" typically occupy 1/3 of a page, take about 15 or 20 minutes to write and should be fun for the students and a minimal requirement (more design may be needed) before touching any materials.

Reduce Scaffolding[edit]

Scaffolding (teaching students something so they feel confident moving forward) was necessary in the pre-Internet world. Before the Internet, only a small minority of people had both access and talent to learn on their own. After the Internet, everyone has access. Information exists to enhance all talents. Students know this. They can guess your direction, mine the Internet and know more about the subject than you ... before the words finish coming out of your mouth. They can build presentations in real time. The students that can not do this need to be taught how.

Homogenizing students by regaling them with random detail is the worst thing one can do to prepare them to become engineers. Projects should put boundaries or context around the knowledge that is needed. A freshman course needs to explore this boundary rather than detail titillation which grows weaker every generation. So if every project appears to be using an arduino, then create a scaffolding exercise in class involving every student that teaches them the arduino. Or seed the knowledge by demonstrating to a few and let the knowledge spread through engineering conversations among the students.

Students should own the content of their first engineering class. Don't fill it up with scaffolding and then add a token engineering project at the end. This is bait and switch. It is cowardly. It does nothing to teach the joy of engineering. It would be better to going back to teaching drawing or Fortan as the first class.


There is a text associated with these projects in wikibooks. Quizzes exist that can be captured and put in a school LMS. The text book describes how handwritten, physical computation notebooks are to be written in and how they are graded. The first step in a project is learning how to write in an notebook before, during and after any engineering activity. Then projects can be documented.

Project Subject Negotiation[edit]

Projects have to be negotiated with students. They have to be given the opportunity to choose. Choosing for them, choosing before hand makes an engineering project seem like one long lab experiment; a boring step by step process with a mountain of expectations, no freedom and students trying to be successful rather than document failure. Don't apologize with these rationalizations of a hot dog launcher:

  • common bonding experience across engineering disciplines
  • reputation of the college is associated with these projects
  • have to purchase materials before the semester
  • you never get to choose the project subject in the real world

The joy of engineering is feeling the inspiration associated with solving problems. But freshmen associate inspiration with freedom to do what they want. The narrative of a freshman engineering class is to mature them, transition them. Telling them what to do cripples this attempt.

Ideally, students register a semester early for this class, are gathered together for the purpose of negotiating projects and then the work begins gathering materials before students show up for the first class. This is because it takes longer than three or four weeks to gather the material for most projects.

Alternatively, create a set of unique/different projects for each teams of 3 or 4 students before the class starts. Make the classes large enough (15 to 20) so there are 4 or 5 projects to choose from. If these projects are unique to each section, then a school with 5 sections could have 20 to 25 unique projects. Attempt to find a starting point for each and associated starting point materials. Attempt to line up a real world client beforehand for each project. If this is impossible institutionally, then start with replicating DIY projects found on the internet.

Team Stability Bonus[edit]

The best projects are where the same group of students stays together the entire semester and works on the same thing. A bonus should be given to groups that stay together.

In some classes, one third of the students drop or stop participating. Under performing groups and groups that have shrunk to one person need to be reassigned. Sometimes a project reaches a standstill where nothing more can be done. For example, open source facial recognition and 3D software lags (as of 2014) way behind COTs. In all these cases, the instructor will need to reassign teams.

What this means is that there has to be the opportunity to students to introduce themselves, for teams for the class period and try to accomplish something within an hour. Typically there are three weeks of mini projects where everyone is trying to select a project and team mates.

Project Selection[edit]

Students should try to select a project that they want to work on for the rest of the semester. The instructor should have a variety to select from. A good engineer should be able to contribute to any type of project. The best engineers are delighted when they can get a project they have no experience on. They get to learn something new! Most engineers select projects based upon how much they can:

  • contribute
  • learn that prepares them for a wider variety of projects in the future

Freshman make the mistake of selecting projects where they can:

  • repeat previous success
  • experience a certain technology

Teammate Selection[edit]

Ideally students self select into teams of three or four, choose a project from a list and then approach the instructor and are put on a team that stays together the rest of the semester. To facilitate this, instructors need to structure how students introduce themselves.


The first three weeks (4 hours in class a week) are critical. Students ideally experience some success/finish immediately. During this time students will begin to show their character. Some will want to be told what to do. Some will want to do what you ask their own way. Some will ignore the finish goals and let the materials at hand tell them what to do. Some will go through the motions and find excuses to stop. Some will rationalize all decisions by listing problems/frustrations that were avoided. Typically teachers are trained to focus on the bottom and let the top do what it wants. This process needs more form in an introduction to engineering class.

What is being attempted this semester (spring 2014) in some sections are these kinds of promotions:

  • Techs .. master some technology in the class room like 3D printing or soldering ... and all similar activity in all projects of that section flow through this student
  • Engineer ... can form boundaries around design, capture, name, compare and lead discussions leading to incremental design improvement while minimizing physical prototypes/building. They become identified with a project and do not risk being removed from the project at a four week cycle (which results in points).
  • Lead Engineer ... can create tasks for fellow students, keep track of who does what and keep a project moving forward at an even pace rather than a frenzy of activity at the end. Lead Engineers get to pick their team mates rather than suffer the random match making of the instructor.
  • Client ... work with the instructor (in addition to role as tech, engineering, lead engineer) on developing new projects.

Promotions can occur at any time. Normally the promotion lasts all semester. A finishing point for a project is created every three or four weeks during the semester when new teams are formed and finish or project grades are handed out. These boundaries also have the following benefits:

  • help recover from students dropping out
  • mitigate personality issues
  • serve diversity/freedom needs
  • limit the scope of materials compared to "any project at any time"
  • practice documentation hand off from one team of engineers to another
  • provide a reason for every student in the class to pay attention to every project at all times

Classroom Activities[edit]

Project grading has to be done continuously in a freshman class. This promotes continuous work on projects. Otherwise, nobody works until the last moment and the chances for personal interaction and conversations are greatly diminished. Most of face to face class time should be talking about projects, documenting projects, negotiating who is doing what for the team outside of class time.

The focus of face to face class time is on task negotiation, CDIO document names/outlines, notebook grading and presentations .. not working on projects. The instructor first meets with each project team quietly, sitting down, talking about who is doing what, finding sources of materials, and harmonizing expectations of the wikiversity documentation. Then the students finish the wikiversity documentation, stand up present to the entire class from the wikiversity documentation, not a power point. Optimal class size is around 16.

Materials and Tools[edit]

Students are going to want to build first. Slow down. This is not the first step. Gathering materials, touching things happens after design. It happens after Team meetings, individual tasks, and writing in a notebook.

Unfortunately student enthusiasm will overwhelm any speed bump between them and a hands on experience. Access to tools and materials has to be through a physical gateway. But this gate has to be tailored to the individual student. The context of the project and the "Hands On" starting point of the student will mix to form a gray scale. A universal and fair gateway will cripple a class. So this has to be a private thing between an instructor and each student or group of students.

Materials feel like presents. Giving students something to take home inspires them. Track these things with a sheet of paper students sign. Penalize them through the same system as the school library if not brought back on time.

Instructor Grading Cycle[edit]

The grading system should be set up so that a student that shows up to every class, participates in every group meeting, attempts to write in their notebook but contributes nothing gets a C. They should accept and attempt a personal task, offer praise to team mates and describe their own work in a transparent accountable way.

individual weekly report[edit]

Instructors grade weekly individual reports over the weekend at the beginning of the week. Instructors look for a narrative that describes what the assigned task was and what actually happened written from the "I" perspective. They look for links to CDIO documents that are in the instructors user space.

Wikiversity Weekly Report Grading Rubric[edit]

The grading rubric should reward form, communication and "pushing a project forward".

Form means using user space of the instructor and themselves appropriately, linking documents appropriately, using wiki mark up, uploading pictures to wiki commons and video to youtube.
Communication means filling out the Next Weeks Task, using discuss pages or the schools LMS regularly and making positive comments. Communication means writing from the "I" point of view in the weekly report, writing from the "We" point of view in the CDIO documents, maintaining transparency, putting stuff away, following safety rules, checking stuff in and out of inventory with the instructor, etc.

Wikiversity makes it easy to grade team communication by clicking on "Contributions" when on the students user page.

Push Push is the subjective part of project grading. Describing this as "Work" creates the expectation that "hard work" even though unsuccessful, will be rewarded. In fact engineers are rewarded for success that can result from a flash of inspiration or years of perspiration. Describing this as "project work" isn't focused enough. Push points can be associated with documentation and links to deliverables. Typically the deliverables start with pictures, videos, software, and drawings. Push points are not given for fruitless work such as driving to every hardware store in the area searching for a part.

Give students feedback on their weekly report discuss page. Encourage students to look at this part of each other's grades. This is pure fun from an instructors point of view. It sets the stage for the discussions in class in the team context.

Weekly Team Meetings[edit]

Class time prioritizes team meetings, presentations and wiki documentation. Actual work on projects should only occur if there is time left.

Students have been trained to think "Teams" working on projects do everything together. They will automatically try to negotiate meeting times outside of class where they all get together. Invariably this kind of team work involves one person working, and everyone else watching. Students don't understand that most of the time, engineers are working by themselves. Meetings occur when there is a very clear need.

This is why at first, individual tasks should be negotiated with the instructor. Meetings are with an instructor and are where tasks and CDIO document outlines are negotiated.

Ideally there is an engineering lab open for working on projects outside of class time. If there isn't such a lab, then focus on projects that can be done at home within the resources of the individual student.

Weekly Notebook Grading[edit]

Grade notebooks in class once a week.

The rubric is to give points for following the format, drawings and GoingToDo, Doing, Rant triplets.

Again, the grade is open ended so grading has to be done by points.

Write the rubric, (form, drawing, project) on even pages, total the number, record in your gradebook, date and sign.

Form is if they are writing in the notebook in the correct format. This is a chance to converse with the student about their notebook organization.
Drawing has to be rewarded independently. A GoingToDo triplet has to set up the drawing. The drawing has to be isometric or othographic and have arrows pointing to features describing functions. It has to have a name and number.
Doing The normal way students write is "Going to Do, Doing, Rant." This is called project writing. Statics show that students produce on average about 3 triplets per hour. A page is usually about 3 triplets and represents an hours worth of work. These are the issues to look out for when grading doing triplets:
If one triplet covers an entire page, counsel student to break into smaller triplets.
If each of the three is one line, then student is punishing themselves in order to get points. This is not engineering. Don't give them any points.
If they seem to be working hard, but not writing much, tell them to write while they are working, not after the fact.
If the writing is too polished, if there is no chaos, if they are only describing successes and not the fog of failure, frustration, etc. then they are using the notebook as a reporting tool and are not going to learn engineering.
If the triplets are repetitive, trivial, obvious or common sense then don't give them any points.

Initiate notebook grading at any time. But leave it the responsibility of students to get their notebook graded. It is not your responsibility.

If students don't get their notebook graded, they loose form points only, not drawing or triplet project points.

Presentation Grading[edit]

Encourage weekly presentations during the smaller break out sections. Give more points when they are presenting in front of a larger audience.

Make sure students know that the easiest points are from presentations.

Increase points if

  • use CDIO pages
  • presentation is short
  • provoke discussions with other students (not the instructor)
  • demonstrations of something new
  • turn audience opinions into fact
  • anticipate questions with obviously prepared answers

Team members have to be present and participate in the presentation to get the points.

Teams can present at any time during the week. Sign up by writing your team name on the white board. Teams that don't sign up, don't present.

Can make only one presentation in class per week about a project.

Finishing Project CDIO document[edit]

Projects should always have a definition of finish. Unrealistic expectations at the beginning of the project should be renegotiated during the week. Project documentation should be written to that final definition of finish. Weekly students negotiate individual activities with instructor and team mates. They work on the project, writing in their notebooks, collecting data, creating electronic drawings/schematics, pictures of assembly, video of testing, etc. Ideally students create the finished project documentation by copying their weekly reports into a common page and changing the english from "I" to "We".

Project pages[edit]

Project pages should be dominated by an accumulated history of all work on the project (even by other teams from past semesters). This is the outline:


The first and the last are the most interesting. The details of what happened are usually found in the middle.

Project Cycle[edit]

Projects go through this cycle: students make their preferences known to instructors, instructors announce teams, and one or more CDIO documents are created during 4 weeks of work.

Ideally students stay on the same project, with the same team mates for the entire the semester. This reduces the "new" learning that is needed. This adds 25 points per person on the new team.

Each week, tasks should be negotiated within the team and then presented to the instructor. Tasks normally are individual. Tasks requiring more than one person, that are dependent upon other tasks being completed, or are dependent upon the arrival of materials are going to attract attention by the instructor.

Task negotiation results in points that can be lost if the instructor discovers someone standing around while the rest of the team is working.

After the tasks are performed, tasks get push points that are awarded upon documentation in personal weekly documentation. If the task is shared, then the push points are shared.

Push points are duplicated to become team points. The team then allocates these points among team members at the end of the semester with approval of the instructor.

Other Graded Events[edit]

Other points come from Scaffolding exercises ... learning about engineering, introductions to various technologies, club/seminar/cohort participation. Helping other project teams out should result in some points. For example, suppose something really labor intensive like playing a video game and recording scores, or massive gluing of spaghetti for a bridge is needed by a project. Then the team would negotiate with the instructor how to give others in the class points for momentarily helping out another team.