Peer evaluations

For CSC301, we've been working on a browser-based family tree viewer in JavaScript. My team consists of 4 people, and so far I think the team has been getting along well. In terms of the amount/quality of work done however, there remains a lot of improvement. This was clear even before we had our first group meeting with Greg last Friday.

On Friday, the meeting started out with Greg asking if everyone was happy with the group so far. We all nodded our agreement, that in terms of working together, there were no huge problems. We were then asked whether we thought we had overrated ourselves during the self evaluations, which were filled out 2 days earlier, compared to what our peers (the other 3 in the team) rated us. Everybody thought that they may have overrated themselves for various reasons. Such reasons included 1) the fact that the individual rated everyone highly including her/himself, and that not everyone else may have rated at the same standards, and 2) the idea that you know exactly what you contributed and how much effort/time it took, whereas the others may only see the result, thereby not realizing just how much went into it.

Surprisingly, 3 out of 4 (including myself) underrated ourselves. The evaluation was done on a scale of 1 to 5 (5 being highest), and the differences between individual evaluations and average of peer evaluations were about 1/4 to 1/3 of a mark. Assuming that most people only used 3, 4, or 5 to rate the others (since everyone claimed to be happy with the group), even 1/4 of a mark is a significant difference. I'm wondering if there is any kind of trend among groups that underrated or overrated themselves. Does one signify the group working well, or is it just a reflection of personality?

The meeting ended with plans on how to improve. We agreed that one of the major problems was that everyone in the group was too busy. It turns out that everyone in the group except for me is dropping at least one course, and so the team as a whole will have more time. Another problem was in task division. One team member felt that he had no one to consult with about his part of the code, so we need to distribute some of his tasks. My proposal was to schedule each element so that we know when and how to cut corners, and to set more specific deadlines, rather than deciding at the last minute that one or more features cannot be implemented due to lack of time. I also proposed a group meeting for this coming Friday to discuss our code so far, so that everyone knows all parts of the code, and not just what they have been working on, which will help us to distribute tasks more evenly.