For some of you this may be the first time that you have attempted to perform any software engineering activities in a team. Team work brings its own challenges in addition to the technical challenges of producing the working end-product. Some degree of project management will be necessary to complete this project successfully, i.e. on time and to a good standard of quality. Project management can also help to minimise some of the people issues which cause stress in team-working, for example, dealing with personality clashes, unfair distribution of work, illness, clash of priorities, laziness etc. You should consider the techniques discussed in SEM232 - An Introduction to Project Management to help you to manage this project. You may decide how little or how much project management you apply to this project, bearing in mind the risk of failure and the personal stress caused by working in chaos and by panic as the deadline approaches. As a minimum your attention is drawn to the list of documentation required as part of the assessment process.

You should consider the following issues:

The project manager in this project is responsible for monitoring progress and coordinating the work. The wider roles of the project manager like estimating and planning, putting the tools in place, reporting and liaising, managing change, managing quality and managing risk also need to be considered but you may want to divide responsibilities among the team members.

If you attempt to plan the project and to monitor progress against the plan the team will have an improved chance of meeting the deadline date. The stages of planning are: identify all of the work (work breakdown), estimate, define dependencies between activities, allocate activities to members of the team, prepare statements of work. You may have difficulty in coming up with a detailed plan at an early stage but preparing an outline plan will be better than nothing. The work can then be broken down into more detailed activities as you become more familiar with the software environment (this follows the standard approach of the work breakdown structure). Statements of work should be prepared for each activity undertaken by each team member. This will briefly describe the work to be done e.g. test the sound recording module, deliverables, estimated start and finish dates, actual start and finish dates (when the work is complete) and the team member responsible. The document should be signed by the team member allocated the task to show that they have accepted the responsibility to complete this work (a contract between the team member and the rest of the team). The team member may also use the statement of work to record any comments about the activity on completion of the work.

Estimating may have to be a broad division of the time available in the first instance, but remember to update your estimates based on experience as the project progresses. The component method of estimating is useful when there is little experience or historical data on which to base estimates.

The project manager should check on progress of activities on a re.g.ular basis, probably weekly, and discuss with the team what action needs to be taken to deal with any problems which seem to jeopardise the ability of the team to complete the project successfully on time. Consideration can also be given in the meeting to outstanding statements of work, issuing of new statements of work and comments on completed statements of work. Records must be kept of the team meetings, including date of meeting, a list of attendees with signatures, issues discussed, actions agreed.

To improve the quality of the end product you may want to use the review and inspection techniques discussed in SEM232. You can use these techniques to improve the quality of any deliverable, for example, code, test plans, specifications, the project plan.

Your project is likely to suffer from instances when deliverables must change after the team member believes work is complete e.g. when errors are found. Appointing someone responsible for maintaining records of completed deliverables and recording and coordinating the knock-on effects of change is good practice (a configuration custodian in SEM232 terms).

You may identify some specific risks for your team in completing this project which you may want to attempt to manage e.g. a particular weakness in mathematical expertise in the team, manage the risk by asking more questions in tutorials on this topic. However, your major project risk will be in failing to meet the deadline date. You are strongly urged to add significant contingency times to your project plan to reduce this risk. The work will take longer and be more problematic than you initially estimate and unexpected events will occur e.g. machine unavailable, flu.

Weekly team meetings are one way that the project team can keep in touch. Other methods include email, written reports and informal chats. All of the documentation produced during the project should be maintained in an orderly way in a Project File. When the project is complete, at the final team meeting you may find it helpful to review how you felt the project went and record any particular comments, issues and lessons learnt.

The minimum project management documentation required as part of the assessment process is a Project File containing: statements of work for all activities, records of team meetings, a log of recorded changes to deliverables, comments from the team on completion of the exercise.

Programming in Teams

Each team should elect a team leader as soon as possible. The team leader's job is to coordinate the work. He should know who is doing what, what stage each is at, and ensure as far as possible that the team is working together in a coordinated way. He should also maintain a team diary in which members of the team record their progress and sign off pieces of work when complete.