Creating Joint Project Descriptions

Allen Klinger, © 2 June 2000

This task involves creating a title, list of authors or participants, and clear text. The focus of the material prepared for this activity could be a real need. Still it is about the work to be done to meet that problem and provide solutions.

Begin with individual statements. Work with these items together. Exchange individual drafts. Work jointly to write something that reflects the future efforts of all involved team participants.

Creating a common statement involves negotiation. Participants need to write something all can support. That agreed upon item has to indicate what those involved will do, usually things involving design or supportive activity.

The resulting text should be short: about one or two paragraphs, and clear. It should be free of jargon and avoid technical terms since it could be read by anyone outside the project, course, school or university.

This project description item has a limited purpose. It is just to describe what you plan to design or do to further something you envision. That is the project as you see it now. Remember the people involved will be working to achieve something. They have a common purpose. Likewise this effort extends over about two months. A joint project description task is to describe that activity to others.

The best starting stance is to remember that a project description describes the project, not its result.

Some initial drafts can seem more like a promise about a product to be built than a description of work on its design. To avoid that seek to define things to be done. Eliminate wording that implies that the accuracy of the project description depends on whether what the group will design is complete and works.

Many draft statements rely excessively on details about a product that the project is supposed to create. For example, often they indicate how a user interacts with a series of computer screens. Always keep in mind that the written project report is not to be documentation of how lines of code perform, nor is it to describe how a designed object is operated.

A project description statement is potentially the abstract or summary of a report about the overall endeavor. It is actually an early draft of an abstract.

The ultimate project report is not a user's manual. Neither is it solely documentation in the sense of a commented explanation of implementation steps.

Work can be presented in many ways. Words are more effective if they support and refer to visuals (report figures). In a figure headings (titles/subtitles) and labels are usually terse phrases that state some starting point about an idea. The text can explain these in detail. Note: a screenshot is not a figure. It is only a possible element or starting point for some visual communication. It is up to the report authors to create a stand-alone, clear, understandable image that has enough words and organization that its meaning is clear. That should be true even if the report is not read. This can occur when a busy individual only views the figure, attempting to understand a report's general subject.

2 June 00 Version http://www.cs.ucla.edu/~klinger/proj_statement.html