CS 486 - Senior Design

Weekly Task Report Guidelines

The weekly task report is an important project management tool. In the context of this course, it serves several purposes. Specifically it:

Forces teams to actively manage their projects rather than just blundering through by feel. This ultimately avoids incomplete projects and last minute flurries of mediocre work when teams discover they have slipped the schedule.

• Provides a record of who did what on the project
• Provides a mechanism for exposing problems with team dynamics; invites discussion on how to repair them.
• Provides me with a mechanism for monitoring teamwork and individual performance.

The format of the task report is relatively straightforward, reflecting its purpose of marking the passage of the team along their project timeline. The task report should be headed by team name, the week which the task report forecasts, plus the date of the team meeting at which the report is delivered to me.

Here are a couple of sample templates that you can use to create yourself a task report template: MS-Word version (including field descriptions) HTML version (including sample contents)

In terms of content, a weekly task report has three major sections:

Tasks for last week.

A copy of the "current tasks" list from last week, but now each task should be annotated with an "outcome summary", that is, whether the task got completed, who reviewed the results (e.g., in a team meeting), and an assessment of how well the task was done (just a qualitative scale of excellent-good-average-needs work-unacceptable will do). This means that teams will need to meet BEFORE our Wednesday meetings and review the tasks and outcomes to write up this summary.

Actual task for current (immediately upcoming) week.

A list of specific tasks to be completed in the coming week. Each task should have a well-defined deliverable. For instance, if the task is to "learn about Java Beans", it should provide a deliverable like "give oral report to team" or "build small prototype". The point is that each task should have some tangible outcome so that I and other team members can assess to what extent it got done. Each tasks should state who is doing it; if multiple persons are working on it, the task should reflect the percentages of effort that the each person should contribute to get it done. Finally, the tasks listed here should indicate a clear correspondence to the more abstract tasks presented in the overall project timeline. For instance, if the detailed task is to "create and validate entity-relation diagrams", one might expect an annotation that indicates that this is a part of the overall project task called "design and construct an archival database", which appears as a three week task in the project schedule.
This task list should be compactly listed as a simple single-level (don't group by person or task type, etc) tabular form. Just a list of specific tasks, no more.

Tasks in near future

This is just a listing of tasks you see looming on the horizon. Don't put the whole rest of your project here. Focus on tasks specifically related to (i.e., follow-ons) the tasks for the current week. The idea is to give an impression of the flow and make explicit your prioritization. This way, a person can look at the current tasks and say "yeah, these are important because I see that they are needed to support upcoming work". Again, doesn't have to be exhaustive. Just show me that you have an idea of where you're going with this, what your priorities are, that you're not haphazardly hacking on things. In short, one would expect to see these tasks appear as "current tasks" in a subsequent weekly task report.

As far as prose goes, the emphasis here is on efficiency and clarity. You don't need to describe the tasks in question in exhaustive detail --- if I have questions I can ask. But do provide at least a clear one-sentence description of task. I expect that the task report should be a one-page document, unless it's a particularly busy week.