Engineering Projects/Model boat/Howard Community College/fall2011/501 Boating

The goal of this form is to provide a standard project format that practicing engineers can use to compare project documentation with while assessing these projects. It is called the "Team Done Form" because it should be filled out by the end of the project. Starting with this format helps make the done process much easier.

Projects are never "done" or "finished." But time runs out. Classes end. So this form has nothing to do with project success. This "Done" form can simply state "Nothing was done." If the section below does not fit your project, delete everything but still leave in the section header.

Electronic Sections Expected

Problem Statement

Put the last negotiated problem statement with the instructor or client of the project here.

Team Members

Teddy Hanson

Andrew Cyles Satya

Summary

Put an overall, one paragraph summary here with links to the team weekly reports.

Poster

Put a graphic in wikimedia, include the graphic here or link to it here. The graphic should be suitable for creating a traditional project poster.

Story

Tell a story of the project. Describe how split up, what the obstacles were, what testing was done, what informal decisions were made, what assumptions were made, what the results were. This is a longer version of the summary with links to all the details collected associated with the project. These links could be to software, links to videos, links to project pages with pictures, etc. Think of the story as a summary of the team weekly reports on one long page rather than a short paragraph like the summary.

Decision List

List all formal decisions made with links to their documentation such as a decision tree or decision matrix.

Material List

Figuring out what to purchase, what to build, what everything costs is a huge part of engineering. Typically there is a list of materials in stock, materials that are ordered, materials that should be ordered next time there is money, materials that have not been fully justified. These issues are part of healthy management of the engineering lab but are associated with a particular college. The detail needs to be published in this "Done" form. However in the project root, just a list of materials is necessary.

Software List

Installing and learning different software packages is part of most engineering project just like the materials list.

Time

Time estimates and actual time consumed measurements helps justify salaries (grades). The only way to gain respect for estimated project time and costs is to practice.

Tutorials

Most projects consist of making instructions to jump start the next team, shrink the learning of tools and software to the minimum, advice on where to purchase materials, how to assemble, etc. Tutorials modified or created are described here with links.

Next Steps

If this is not filled out, the next team may have to repeat each of your steps just to figure out what the next step is. It is best to write this immediately at the end of the project while creating the summary, poster, presentation, and story.

Subjective Critera

While reading these sections, practicing engineers are building up the following impressions about the document. So the following categories are more subjective:

Repeatablitly

Is there enough detail to repeat the work?

Clarity

Is there enough detail that the questions provoked focus on the next step rather than clearing up fog? Is there enough detail that alternative conclusions can be flirted with? Is there enough transparency that finished and unfinished boundaries can be seen?

Integrity

Proving something doesn't exist or doesn't work usually requires exhaustion. Simply saying "it can not be done" is like challenging a pro basketball player (engineer) to one-on-one basketball (find a solution). It does not inspire respect. All the different ways respect is created can be found throughout the wikibook General Engineering Introduction.