Introduction to “Projects”

Doing a project means achieving some goal, assigned or proposed, whose result is unknown, with an agreed budget, and a specified completion date or deadline. Long projects are organized in phases (e.g. I, II, final) with progress reports to be presented after each phase.

Apart from performance, meeting the deadline is very important, so planning is essential. A time chart is a useful tool. Your chart should allow enough time for each expected job, and margins should be available for unexpected but necessary modifications.

All specifications as detailed in a project should be satisfied to avoid “disqualifications”.

Once completed, the project presentation should be carefully prepared. Since it is through this presentation that the world see what you did to be convinced or not it was worthwhile the required budget and time. Peer evaluation is a very effective tool that we’ll use on the team web pages.

Once completed, the project documentation or product manual is what remains of what you did, since without it nobody else would be able to use your product, or to modify it to do something useful. This is especially critical when millions were invested in a project that worked, but useless since the documentation was missing. Project documentation contains the main three parts: background or introduction, descriptions of design/building/improvement process (including detailed sketches, drawings, pictures), and analysis/testing of the product (including graphs, tables, numbers).

The project documentation should be based upon an engineer logbook, a personal notebook with consecutively numbered pages. No erasers should be used, instead just cross out undesired notes. The logbook with dates is the best evidence in patent or authorship disputes.