Team Project Requirements

As much as possible, the course schedule has been designed so that we will study various analysis techniques before you need them for your project. In addition, in-class activities and individual assignments will provide additional practice. The needs of each team and project vary, however, so this isn't guaranteed for all.

Important! I am here for you and your team to consult! Please do not hesitate -- I want these to be successful projects for you and your clients.

Project deliverables are designed to fulfill several purposes:

• To provide checkpoints where teams reflect on how the project is going.
• To gather feedback from your client as needed.
• To keep me informed about your progress, and allow me to give feedback.
• To keep you and your team on schedule.

Read all the problem descriptions, and pick out 4 that you would be interested in working on. Among other things, your decision may be based on the type of problem, the setting, and how feasible you think the project is. Email your list of 4 interesting problems to me by Wednesday, 9/19/12, 12:00 noon. Based on these lists, and my own judgment about the projects' feasibility and appropriateness, I'll select several descriptions, and post them on the website by the end of the day. Your individual grade for the problem definition is independent of whether your definition is a candidate for the projects.

Forming Project Teams
Thursday, 9/20/12
Before class on Thursday, 9/20/12, read the candidate problems from which you'll choose projects. In class, I'll post the descriptions around the classroom. People interested in a particular problem will meet by the description, and discuss skills and schedules (VERY important!). We'll repeat the process a couple of times, giving people a chance to look at 2 or 3 problems. Final project teams should have 3 or 4 people, in them, and team members' schedules should allow for meetings.

Progress Reports
Each team will submit two brief progress reports during the course of their project. The purpose of the reports is to tell me about your accomplishments, plans, and any questions or concerns your group has. Reports should be about 1 page.
Important! The reports are intended to help us track the course of your project. If your team encounters any problems, do not wait until your next progress report to consult me!

Each report should include:

• what you have accomplished since the last report (or beginning of project, for the first report),
• what you plan to do in the next 2-3 weeks,
• whether you are on schedule, or if not, how far behind you are and what you will do to catch up, and
• any questions or concerns you have.

1. Tuesday, 10/23/12 along with your Draft  Models 1
2. Tuesday, 11/13/12, along with your Draft  Models 2

Information Gathering Plan
Due Thursday, 10/4/12, 10% of grade. Please follow the submission guidelines when you submit your assignment on the course Sakai site.
This is a brief (approximately 5-7 pages) description of

• the information your team needs to gather during the course of your project.
• from what sources (e.g., people, artifacts) you expect to gather this information.
• the methods you'll use to gather and organize the information.

1. Problem definition (required). This may be revised from the original definition (in consultation with me) as a result of your preliminary investigations.
2. What information you need to gather, and why it is important. This may include information about existing processes or information, the expected users, the environment of the new system, any constraints on your design, standards or "best practices" that may be pertinent, products or equipment, etc.
3. Where you will seek the information. This may include people (known, or known only by job title), vendors, other places with similar situations, research literature or trade journals, the site itself, etc.
4. How you will get the information. This may include types of interviews or observations, artifacts you want to collect, searching through indexes or on the Web, etc.
5. How you plan to record and organize the information. This may include the models that you think will be useful, notes or sketches, and so on.
6. Your schedule for gathering and organizing information, including which team members are responsible for which tasks.
7. Your team organizational structure: who is reponsible for project/team management, document management, meeting management team communications, client contact.
8. Your team communication structure: expectations for attending and preparing for meetings, establishing and meeting deadlines, providing feedback, requesting revisions, expressing criticism, concerns, and praise.

Note: The more specific and detailed your plan is, the easier your project will be. I understand that your plans may change as you proceed, and learn more about what you need to learn, but this report will help you get organized, and give me an opportunity to make suggestions.

Grading: 55 points total

• completeness of plan - 25 points
• appropriateness of plan - 15 points
• clarity of presentation - 15 points

Draft  Models 1
Due Tuesday 10/23/12 (not graded).
The contextual inquiry/design approach suggests a variety of models that may be used to describe particular aspects of a system and its context. You will have an opportunity to work with each of these models in individual assignments, and will be creating models for your team projects. Models are created as you conduct contextual inquiry interviews with individual users or other system stakeholders. As multiple interviews are conducted, these individual models are "integrated" into summary models that represent the input from multiple people.

At this point in the semester, we will have completed our coverage of a variety of models, but your submission is not limited to these. A team is not expected to include instances all of the models we discussed in class. Instead, you are expected to select a few models (2-3) that are most critical for the success of your project. While your data collection may not be complete by this date, you should have begun developing the selected models, and these drafts will be turned in for feedback from me.

Include a brief narrative for each model that provides the following information.

• How you gathered information for the model and incorporated it into the design.
• Whether this is a model of the current or the proposed system.
• At what stage you consider this model to be (e.g., draft or final).
• What you can observe or learn from the model and how it contributes to the project (e.g., understanding of the problem or environment, ideas for design, etc.).

Draft  Models 2
Due Tuesday, 11/13/12 (not graded).
This deliverable has the same components as Draft Models 1.

• A progress report
• A selection of draft models that are critical for the success of your project. These may include revised versions of models you submitted earlier.
• A brief narrative for each model.

Presentation to Class
Tuesday 11/27/12, Thursday 11/29/12, Tuesday 12/4/12.
Each team will present the project results to the class. Your team may designate one or two members to present, or you may decide to have each member give a part of the presentation. Other members of the class will provide feedback to help the team identify areas that need clarification, consider different perspectives, and otherwise prepare for presenting their proposal to the client.
Presentations must be polished and professional:

• Briefly describe the system environment.
• Explain how the system will work.
• Show how it solves the problem.
• Be clear and well-organized.
• Use appropriate visuals (slides, etc.)
• Talk to the audience, not to the screen or board. Don't just read from your notes. Posture, eye contact, and clear speech are all important.
• Don't get bogged down in unnecessary details.
• Don't go over your time limit (15 minutes).

• clarity of description
• overall organization
• polish (eye contact, speaking clearly, appropriate use of visuals, good handling of questions, etc.)

Final Specifications
Due Tuesday 12/11/12, 12:00 noon
The full specification of the project, is due at this time. This report documents your findings, recommendations, and justifications for the entire project. The sample outline will give you a general idea of what should be included, but you should use your judgment as to how best to present it. Most of the sections should be appropriate for presentation to the client, but I also ask you to reflect on your experiences and learning in an appendix.

The final specification are worth 25% of your course grade.

Team Evaluations
Due Tuesday 12/11/12, 12:00 noon
The Lessons Learned section of the final specifications will include an evaluation of your team as a whole. In addition, each team member will evaluate the contributions of all his/her team members; evaluations should be written and submitted  independently. Briefly describe how well and in what ways, each of the team members, including yourself, contributed to the success of the project. What are each person's strengths? What advice might you give to improve the person's performance? You can consider this as a type of job review, such as a manager or co-worker would do on a regular basis, at the conclusion of a special assignment, or in considering the person for promotion. Please submit your evaluation on the course Sakai site.

Summary: Timeline and Grading
Timeline
Tuesday, 9/18/12, problem definitions due.
Thursday, 9/20/12, choose teams.
Thursday 10/4/12, information gathering plans due.
Tuesday 10/23/12, draft  models 1 due.
Tuesday 11/13/12, draft models 2 due.
Tuesday 11/27/12, Thursday 11/29/12, Tuesday 12/4/12, team presentations.
Tuesday 12/11/12, 12:00 noon., final specifications and team evaluations due.

Grading
As a rule, the team members will receive the same grade for the project. In extraordinary circumstances, the members' evaluations of each other may affect an individual's grade slightly.
The project as a whole is worth 45% of your grade as follows:

• Information gathering plan - 10%
• Presentation to class/client - 10%
• Final specifications - 25%.

Criteria for evaluation of the final specifications include the clarity of the description of the current system, the quality of the design proposed in terms of its ability to improve the system's effectiveness for the client's organization, the clarity and completeness of the description of the proposed system, the feasibility of the implementation plan, and your reflections on your experience.