Challenges and Opportunities of a Group Project
One of the core modules for 2nd year Computer Science is Software Engineering. The module covers the different ways software is developed in the work place and the advantages/disadvantages of each method. It is assessed by an exam and a group project (at least, this was the case for this and previous years).
The group project is a key aspect of the module as it gives hands-on experience working as a team to produce a piece of software from a given brief. You learn team work, project management and software development skills which will all be really helpful after University.
Of course, a group project brings its challenges and can be one of the most complained about assessment methods there is. A group project means that you have to work in a team of people you’ve never met before to achieve something that you’re all proud of. This mirrors the workplace as you are very unlikely to get to pick your team when being placed on a project.
The main challenges that I experienced this year were:
- different levels of motivation and work ethic
- different levels of skills and specialities
- time and project management
The different levels of motivation and work ethic in team members is a problem that all group projects will encounter. Even if everyone in the team is super hardworking and motivated, there will still be a scale, it just might be slightly smaller.
These different levels are natural and understandable – some people will connect more with the project, some people are motivated by starting projects and some by finishing a project, some people only get motivated as deadlines approach and some people are motivated by seeing tasks getting completed.
The best way to deal with different motivational levels is to discuss with your team how each person works best, agree on an even break down of tasks into smaller chunks that look less daunting and set soft deadlines throughout the process of the project so there are more imminent deadlines for people to work towards than the main one. Hopefully, these will work to smooth the issues that these differing levels can have.
Different levels of work ethic is a much harder challenge to overcome. If a team member doesn’t want to put the work in, it’s difficult to know what to do. Giving them specific tasks and deadlines may help to motivate them. Talking to them about their contribution and seeing if there’s anything you can do to help can also go a long way to helping get them to put the same amount of work in as everyone else. They may not realise that they’re not pulling their weight or there may be other factors affecting their ability contribute as effectively. At the end of the day though, if a team member isn’t willing or able to contribute as much as you might expect, you have to cover the gap so talking to the rest of your team so that this extra workload is spread evenly is really important.
Different levels of skill and different specialities is a difficult challenge to deal with. If one or two members of the group are excellent at coding, or get a much faster start on the project, it can be tempting to leave everything to them or difficult for them to explain what else needs doing. The important thing here is communication. Make sure everyone is doing an even amount of work overall and that you’re not relying on 1 or 2 people to carry the group. But don’t stop someone working on an area that they’re really good at either. It might be the case that one person doesn’t work on the code at all but instead implements tests. Or that one person works hard at the beginning of the project and others step in to finish it off. The important thing to remember is that it’s a group project and everyone should be involved. Just because 1 person is really good at x, doesn’t mean they should also do y, or that another person can’t help them with x and learn how to do it. At the end of the day, the project is for people to learn, not for a group to make an amazing piece of software that will make millions in 10 weeks.
Time and project management is probably the most universal challenge of any group project, especially when you’re not as experienced as you could perhaps be. This problem can be exacerbated by having such a small time frame and everyone having different commitments outside the project. The best way to deal with this is create deadlines for each task that are before the actual deadlines to give people room to not be able to meet them, and to communicate with each other about how the project is progressing and how much time people have available to work on the project. An example of this was my team this year where a couple of people had lots of time at the beginning of the project but couldn’t commit as much near the end due to other coursework deadlines, to help with this other members of the group who had more time, alleviated the pressure on those team members near the end of the project.
Overall, I found this project really interesting and useful for future life although not without its challenges or frustrations. The key message I would give to others starting this module is to communicate with your team as much as possible and try to set early deadlines for each task to give you time to run over without too much stress. Being able to submit something at 11pm the night before a deadline is so much less stressful than trying to complete the work overnight as a team working in different locations!