Engineering and technology learning projects

The words project and lab have too many different meanings. Project in this context means open ended. Students need unique tasks that are managed by instructors. Students have to recommend materials needed for the project. Instructors have no particular experience with the technologies and tasks required.

Lab in this context has the objective of replicating previous success. Materials are ordered beforehand. Instructors have done the lab over and over. All students do the same thing. Documentation consists of one boring step after the next with boxes to write numbers in. A group mind left over from the previous semester absorbs the new students whose only method of distinguishing themselves is to do the labs really fast.

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 to documenting failure with inspiration and joy.

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

Freshmen are first inspired by the outside world of things. Teaching "Design" should not cripple them by imposing a random business processes between the engineering experience and hands on experiences. Bloating "Design procedures" to the point where students are deprived of hands on experiences until the last weeks will 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 guide the design/hands-on oscillation. Have a design gateway that evolves as students mature away from the need for hands-on and into design. The gateway (a drawing, schematic, list of materials/vendors, etc.) should be justified by the project, not the course syllabus. Bring up the design/hand-on conversation in the context of project needs rather than individual maturity.

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 of implementation or operation. Design can occur within implementation or operation. CDIO can go on with C or inside D or inside I or O. The bulk of engineering is in implementation and operation.

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. Open ended projects are driven first inspiration, not requirements. Requirements are the discussions after inspiration and before perspiration. The goal is to capture a knowledge base of attempts (failures) rather than successes (tutorials).

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 conversation. 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 doesn't cause a loss of respect among engineers. 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 by owning solutions; not by claiming command because of prior experience.

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. Out of this chaos, progress that pushes a project forward has to mined.

Don't ask for conclusions or analysis. It causes panic attacks in 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 engineering analysis is vague on purpose. It could merely inspire next steps. It could expose a empirical pattern. It rarely traces back to already existing analysis.

The scientific method has morfed into 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.

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. Some can build presentations in real time. Others 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.

Suppose every project appears to be using an arduino. Don't create a scaffolding exercise in class involving every student that teaches them the arduino. Instead, seed the knowledge by demonstrating to a few that can understand it with the least work on your part. Then promote this few to spread this knowledge. Create a group competence within the classroom this way. There will always be some students that are slow. Identify them positively by figuring out what they are inspired to do rather than label them negatively by failing a group exercise.

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

Ideally, students know each other. They register together a semester early. They meet before class starts for the purpose of negotiating projects. They produce material lists a month early so materials will arrive before the first class meets.

If this is impossible, create projects yourself. Order enough materials for a starting point that involves some hands on experiences. Don't try to do the projects. Don't expect or even try to order all the material necessary.

Allow three weeks (or 12 hours class time) for students to get to know each other through one-day mini projects. Put a twist on each project/challenge. Make some competitive. Make some sign up .. Form teams randomly, then let them self select. Encourage them to think about what project they want to do the rest of the semester. Give them a list of starting points. Ask them to think about who they want to do the project with.

Students want to be told what to do. If ownership is left open ended, then the project task setting agenda will be get mired in opinion conflicts with no clear way to resolve them. Instructor has to be the boss, call the shots and ultimately determine weekly tasks.

The instructor has to publish the project (move out of user space) in wikiversity. Ideally students create/modify/improve a project document that instructor doesn't have to edit.

The concept of documentation improvement by forcing hand off of the project from one team to another team of students within the same section does cause conversations about engineering documentation style, clarity, usefulness. Have these conversations when they crop up. But forcing a change of individuals on teams isn't necessary to cause these conversations. Changing a few members of a team can cause the engineering documentation quality conversation. Forcing completion every four weeks in order to be able "to present at any time" can cause these conversations.

The following immature behaviors derail documentation improvement conversations:

• Find random starting points searching the internet rather than focusing on what has been done
• Don't absorb all previous work ... would rather start with re-inventing the wheel
• Try to please the instructors or their own ego rather than look for the next steps in the project goals and objectives

Opening up the possibility of changing projects due to "like/dislike" will cause at a minimum a scaffolding challenge. Asking students to climb the scaffolding quickly results in them wanting to start over. This has to be channeled into improving the scaffolding which isn't as sexy as working on the edge of the unknown.

Changing teams can also result in "ownership" issues. Previous team members, particularly those identified with the success of the past project will still try to own this success. Other students will respect this. Creating the ability to both find problems and still respect previous success is a mature behavior. Opening projects up to this dynamic should minimized in a first year experience.

Instead promote students with specific talents/gifts to "help/serve" other projects (see Promotion below, or Reduce Scaffolding above). Instead leave the most vested students on a project and move the least vested around to see if they stick to another project.

In any case, students will want to wrap the project in a context they control. It is hard to stop this from happening in a brand new project. Most projects attempted should be building on top of previous projects so that the context obviously has to be learned.

The goal is to get students to improve/add/push demos and documentation forward. This means the wikiversity documentation has to be the root of the project. Success in physical space should not be rewarded in the grading system. Success in physical space is an opportunity to document .. which is rewarded.

Success, competence and feelings of contributing to the well-being of the world should come from the documentation, presentations and demonstrations. Success feelings do not come from hands on experiences. Success in physical spaces is that of a temporary performance. Documentation success lives forever.

Create a set of unique/different projects for each team 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 materials. Attempt to line up a real world client beforehand for each project. If this is impossible institutionally, then use internet DIY projects as a starting point.

Engineers explore the unknown from a scaffolding of previous experiences. The goal is to know how to build upon this scaffolding. Most students have been taught they have no scaffolding and perpetually need to be educated. This creates a double bind in their mind:

• Can not do project because know nothing
• Can not learn anything without experience
• Can only gain experience through doing projects
• Can not learn without a teacher
• Can not gain experience without demonstration
• But there is no teacher, no existing project demo
• Therefore I will fail

Maturity is working within this double blind. Instructors can speed up this maturation process with these snippets or sound bytes:

1. learn the minimum, learn just what you need to know
2. find starting point
3. leverage the group mind .. teach learn build
4. value your ignorance
5. expect to be bored as an engineer .. leverage this down time by learning on your own

The brightest students have learned how to derail everything by bringing up this double blind. They can play dumb/incompetent through the first and second, plead ignorance on the third, but students generally have not "valued their ignorance." The fifth visualizes what results from maturing through this double bind.

Don't have students do long introductions. Instead start with this Ethical Code.

Then form small teams randomly of three or four to talk about the Ethical Code and give them a little project to do in class. Next class form different random teams and repeat. But have them work over the first weekend and present next class as a team. Then form new teams that do a project for the rest of the week and next weekend. Third week starts with presentations and then negotiation of final teams and the projects they will hopefully do for the reset of the year. By this time, students ideally will self select into teams of three or four, choose a project from a list and then approach the instructor.

The instructor should have a variety of projects 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 .. in order to be eligible 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

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. And a bonus should be given when the talents of a student are needed in another project and the student moves to another team for this reason.

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 and a new project has to be created. Sometimes materials are ordered for another group of students that continue the project next semester.

With this in mind, it is good to have planned boundaries upon which team documentation captures the individual student's weekly work. A good boundary is four weeks for a class that meets four hours per week.

Students mature during these conversations about reforming teams. Make sure the conversations happen.

Students will only experience success when they can present ... when they can say look at what I did. This has to be coupled to documentation. Only allow Presentations from project documentation. The tension of a presentation exposes a student's character or personality. Mature behavior needs to be promoted. Here are some signs of mature behavior:

• Working independently rather than being told what to do
• Design first rather than let materials at hand determine design
• Error on the side of narrowing task focus, rather than broadening, starting all over, changing the agenda.
• Find work rather than excuses to stop
• Troubleshoot rather than list problems/frustrations and ask for something new

Typically instructors are trained to focus on the behavior that needs to be changed and let the mature students do what they want. The idea here is to promote the mature students.

Identify strengths as soon as possible. Then give these people tasks that are outside of their normal team. For example, someone figures out how to test if an arduino is working. Send this student to spread this skill into the group mind by jump starting other teams using the arduino. Don't give it a name. Promote by giving them more visible, respectable tasks. Something as silly as "Go listen to Nancy .. she learns best by talking" is a form of promotion if it is something you as an instructor, would have to do. The best promotion is letting them choose teammates when it becomes necessary to re-form teams.

Promotion does not have to be graded. The respect created is enough to motivate more mature behavior.

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. Optimal class size is around 16.

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 gateway 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. But only let students with a very good attendance record take things home. 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.

Introduction to engineering students need a junk pile to get started. But the goal is to design first and then find material that fits the design. So a transition has to occur. This maturation can not happen unless the junk pile is only sufficient to force identification of material that needs to be acquired. This creates the opportunity to order materials and starts the materials double bind because someone has to answer this question: "what do I do while waiting?"

All engineering students need to experience this double blind because of the immature need for "hands-on" experiences.

• Can not do project with out materials, tools, space.
• Without materials, tools, space, cannot design.
• Can not order materials, tools, space without a design.
• Project will not get done.

Students cope with this by

• Doing nothing and justifying this behavior by claiming the lack of materials
• Breaking something and waiting replacement
• Trivializing design process and ordering wrong materials
• Destroying inventory of glue, batteries, wood
• Damaging equipment ... dulling sharp edges, violating safety regulations, etc.
• Mix broken, working, used, unknown in the same box

Instructors have to watch for and respond to these behaviors by:

• Chanting, engineers work with no money, duct tape, bubble gum, coat hangers, WD-40, cardboard, glue gun, needle and thread, paper, .. etc.
• Why did it break? Why aren't you trying to fix it? How are you testing working/failure? What was the failure mode?
• How does the design match the requirements? Where did this measurement come from? How did you count? What suppliers did you compare?
• Throttle access to consumables
• Have lab aids that protect equipment and enforce safe behavior
• Keep a stash of new/known that is given out only to certain students that have exhibited mature behavior

Ultimately this is handled by an Engineering Lab Policy Manual.

An engineering seminar is where all engineers on campus gather once a week in a big auditorium. The goals of the engineering seminar are:

• cohort building activities
• presentation opportunities (see presentations below)
• speakers from the community

The presentations have the following benefits:

• Decreased focus on mechanical, electrical, chemical, civil because students can see that all projects involve lots of different engineering disciplines
• See a variety of project activities (testing, marketing, coding, building, writing)
• Learn something: Build one's personal scaffolding

Outside of the seminar, students are encouraged to build their social network. Social networks are built by encouraging and rewarding students that participate in SWE, NSBE, AIAA, IEEE and other student chapters of engineering societies. Social networks are built by encouraging and rewarding students that participate in hacker space and museum activities, go on tours, find internships, etc.

The 400 points are typically split up into:

• 200 Attendance
• 200 Social Network Building

The social networking points are built up by reporting on what happened to the class (not seminar) in a short presentation.

Assignments are unique to the college, scaffolding, projects and mandates of institutions transferring to and/or upper division class prerequisites.

Instructors grade weekly individual memos 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 words, pictures and videos that can be cut and pasted onto the projects page.

The goals of individual weekly memos are:

• documenting projects as one works on them
• reward constant, sustained, reasonable amount of work each week rather than burst at end of semester
• focus on individual work, team documentation rather than looking over another's shoulder doing nothing
• create an opportunity for the discussion "Is this good enough to get into the team documentation?"

Grading individual weekly memos outside of class is fun. It sets the stage for conversations with in the classroom for the entire week. The grading rubric is form/task/push.

Ideally students write their weekly memos in their own user space. The instructor creates a "section" or "course" page in their own user space that points to the individual student's weekly memos. The instructor gives feed back on the student's weekly memo and encourages students to look at this part of each other's feedback. This is pure fun from an instructors point of view. It sets the stage for the discussions in class in the team context.

Class time prioritizes team meetings, presentations and wiki documentation. Actual work on projects should only occur if there is time left. Instructors should also work at pushing projects forward in class. Students that begin idle, non-engineering talk should be focused first by example and then by re-tasking if they can not always find something to push a project forward.

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. 10 points maximum for form.

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.

Graphics grading starts off counting the number of arrows connecting descriptions to the drawings. Repeated drawing of the same thing reduces the count. Only differences increase the count. Notebook drawings should never be a substitute for drawing with software.

Doing The normal way students write is "Going to Do, Doing, Rant." This is called project writing. Statistics 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.

Triplets are graded by counting rants and then multiplying by three. Initiate notebook grading at any time. But leave it the responsibility of students to get their notebook graded. If students don't get their notebook graded, they loose form points only, not drawing or triplet project points.

If nothing is done, no notebook points are awarded. If a student completes one triplet, it is 13 points. This can be done in class. If notebooks are required for entrance into the classroom, then it is easy for students to get 16 points a week. 15 weeks *16 = 240 points. So for basically participating the entire semester, this point category can be maxed out.

The better students are going to max out their notebook points well before the end of the course. It is expected that the notebook will continue to be used, even though it is not graded.

Any project should willing, able and want to present at any time.

Presentations longer than 5 minutes should be penalized.

Presentations should be practiced in the classrooms. Instructors may even give the presentation.

Presentations should not be limited to the specific project working on, but could be project proposals or engineering experiences encountered out in the community.

Presentation opportunities are not limited to the engineering seminar and projects day but to presentations around campus during engineering week, during celebrations such as Ada Lovelace Day, World Toilet Day, π Day, etc. Unique presentations to internal organizations such as buildings and grounds or the college board of directors may be rewarded. External presentations to organizations in the form of papers at engineering conferences, project customers, etc. can also be rewarded.

Rubric: These are something an instructor can capture that aren't subjective:

• startup ... use presentation stored in cloud that is linked to wikiversity pages
• short ... between 5 and 10 minutes
• team work ... everyone speak in turn, obvious planning of who talks about what, when and in which order, introduction of team members
• no distractions ... no fancy graphics, colors, video or jokes that detract from a focus on the project
• demonstration ... backup video at a minimum

These are subjective items that an audience could be asked .. through clickers, cell phone texting or smart phone apps

• Audience awareness

1. repeating something already presented
2. too much detail
3. trying to educate rather than set expectations
4. memorable sound bites

• Speaking

1. mispronouncing words
2. reading slides
3. reading script
4. speaking to the slides

• Questions

1. question solicitation obvious and ugly
2. completely covered everything
3. didn't understand enough to ask question
4. numerous conversation starting points offered

• Flow

1. Interrupting each other to correct, clarify, re-tell in better words
2. Too staged
3. Uneven transitions from one speaker to the next
4. Passed quickly, never boring

• Enthusiasm

1. Can not remember anything that was just presented
2. I learned something
3. Very interesting
4. I want on this project

• Opinions

1. Repeating point of view with no justification
2. Random opinion, I can think of something else
3. Justified, harmonized within the team
4. Opinions turned into numbers

• Numbers

1. Numbers subjective to interpetation
2. Numbers made independent of personality
3. Number collection method very clear
4. Numbers statistically analyzed

Presentations in the seminar and on projects day should have the rubric applied. Presentations should be a reward for good work. Not every team or every person should expect the opportunity to present. If two 100 point presentations are give and 5-10 point presentations are allowed in class, then it should be easy for most students to obtain the maximum of 200 presentation points.

Good attendance, participation and support of those on the team, along with minimal weekly memos, minimal notebook work and no project push should result in a C.

Project grading is what separates B and A students. If students max out all other point categories, they can get a B without pushing a project forward ever.

Every individual on a team gets the same project grade. However, this project grade is a percentage of their weekly push points. If the team gets a project grade of 100%, each individual's weekly push points are added to their project grade which has a maximum of 400 points. If the team gets 50%, then half of the individual's weekly push points are added to the project grade.

The teams project percentage grade starts off with checking to see if all the push point information makes into the project documentation. Here is the negative rubric. To see the positive, look at the syllabus.

• Table of contents bloated, more than one level, doesn't contain next steps, a 5 minute presentation
• Sequence of formal presentations and dates made lost
• Not all push point work found in weekly memos made it into the team documentation
• Time or Dated material such as week 1, week 2, week 3 context leaks into the weekly memo
• Places such as my house, this college is mentioned
• People's names, pictures, appear in the documentation
• Bloated paragraphs have to be shrunk to a sound bye within a collapse template.
• I and We statements have to be edited out
• No integration within the previous documents structure/narrative, just tacked onto the end
• No integration with other team mates work, different individuals merely dump into the project documentation
• Not making use of gallery tags to show lots of pictures
• Not selectively deleting pictures, just dumping everything taken into the documentation
• Not giving pictures labels (descriptions) that encourage readers to click on the pictures and make them bigger
• Broken links, links to documents that are private, not public
• Screen shots have to be edited by instructor to remove company logos
• Forcing the instructor to spend more than 10 minutes editing what the team has done
• Creating fill that originates from logical thought and an outline rather than push points

Engineering projects are never finished. It is wrong to assume that projects start, go through some process and are finished, then documented. Documentation has to happen continuously. Presentations have to be done with only a 2 minute notice.

There are always unrealistic expectations. Part of engineering is breaking the unknown into starting points and doable chunks. Hopefully it pushes the project forward. One may be merely documenting what is impossible. Expectations are constantly being renegotiated during tasking. Unknown requirements creep into the tasking and then make their way into the problem statement through the back door.

The point is that success is not "finishing" a project. Success is presenting. Success is presenting something new, wonderful, world changing, world improving at a moments notice. Get noticed. Get a job. Get in front of the public and wow them.

CDIO is described in the wikibook associated with this course. 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:

• PROBLEM ... client, customer, expectations, short paragraph
• CONCEIVE ... answer questions why, where, what, scope, scale, customer, price, cost, materials, requirements
• DESIGN ... paper, computer, simulation, drawing, planned assembly, testing, modeling
• IMPLEMENT ... physical world, doing stuff, getting to work
• OPERATE ... keeping it working, selling, servicing, support, manuals, life cycle, shipping
• DEMO ... video of demo, presentation of the project at it's current state, list of materials needed to demo
• NEXT STEPS ... what would engineers would do if more time/material/money were put into the project which is never finished

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