Collaborative work in the age of CoViD-19

In a usual year, Engineering Mathematics students at the University of Bristol spend time each week working together in groups on Mathematical and Data Modelling (MDM) projects. These projects involve students using their knowledge of mathematics and data analysis to tackle real problems. In first year and second year, students work on case studies developed by the teaching staff. And then, in third year, the students get to tackle some real unsolved problems brought by external partners in industry.

Of course, 2020 has been far from a usual year. The CoViD-19 induced lockdown which came into force in March has required massive adaptation for everyone, with university students certainly no exception. I spoke to Sean Cummins, Jack Pottage and Will Mower – three students from one of the third year MDM (MDM3) groups – to find out about their experience with their last project and how their work was affected by the lockdown.

Tell us a little about the problem that you have been working on.

Sean: Our task was to investigate methods of ‘tilting’ the FTSE 100 index to track the level of palladium stock. Tilting refers to adjusting the weightings of constituent companies within an index in order to increase the exposure of the index to a given stock or security. Our research focussed on two key methods of tilting; the first was based on primary company research and market sectors to decide which stock prices would we expect to be most affected by the price of palladium stock. For example, it is expected that precious metal mining companies would be greatly affected by the price of palladium. The second method relied solely on correlation coefficients between company stock price and palladium price from historic data. Higher correlation coefficients indicate that, historically, these companies were affected more by the price of palladium. Increasing the exposure of an index or portfolio to a commodity such as palladium allows investors to enjoy the safety of spreading investment across a broad portfolio whilst capitalising on the successes of specific stocks and securities.


How does this problem compare to MDM problems you have worked on previously?

Will: Unlike most previous MDM projects, this one involved collecting all of our own data using stock and index information found online. This meant that we had to clean and organise the data ourselves before we could start testing tilting methods. There was also limited publicly available research in tilting for indirect exposure specifically.

Sean: This project in definitely forced me to learn the basic concepts behind financial markets. Some projects I have worked on have not required a particularly good working knowledge of the field, however, as we were attempting to simulate the FTSE 100 index it was extremely important to carry out thorough initial research.

In the middle of your work on this problem, you had the disruption of the CoViD-19 lockdown. What sorts of things did your group do to adapt to this?

Jack: The first thing we did is to remove 2020 from our dataset, as the markets were badly hit. In terms of working together when separate, we tended to upload our work to the main project more often, so all the contributions could be seen and edited more easily, without relying on anyone bringing something up in conversation.

Sean: Our group employed a number of methods to ensure the impact of the virus on the project was kept to a minimum. Firstly group meetings were carried out on zoom/ Skype which enabled members to screen share, making it easier to give progress updates. As well as this, group meetings were scheduled regularly and well in advance so that all members could be present. We also managed to gain access to an online collaborative tool for Jupyter. This software allowed group members to work simultaneously on code which limited the time spent explaining code changed to one another.

What sorts of tools did you use to keep working together effectively during the lockdown?

Will: We tried various different video conferencing services including Skype for business and Zoom if we needed to share our screen but also used the video call option on our Facebook messenger chat as it was the most convenient option for a short catch-up. We also used a tool called Deepnote which allows for real-time collaboration on jupyter notebooks. Finally, as we would have regardless of the lockdown, we used GitHub to share and manage code and data and Overleaf to collaboratively work on the report.

Screenshot 2020-09-13 at 11.52.53

What new things have you learned from doing MDM in lockdown?

Will: The importance of clear, open communication within the group was highlighted when it came to writing our report remotely. Usually, we would work together in person for a few days in the lead up to the deadline, discussing report structure and narrative as well as specific sentence syntax and other details. This not being possible made me realise how important it is to actively discuss things such and structure and narrative etc. (ideally) before the final draft is being written. This is particularly important when you aren’t able to meet up in person.

Jack: In previous projects, sometimes the final few days before hand-in could be a period of crunch, where we would spend days as a group finalising. In this project, we essentially wrote-up everything we did as went along, so the finalising process was a simpler matter of editing, cutting, and rearranging what was already there, which was a significantly less stressful process, although we were still over the page limit come the due date.

What is your biggest recommendation to anybody doing group work remotely?

Jack: Having regularly scheduled meetings as a bare minimum means that even in times when the group is feeling a little less motivated, at least some discussion has been had, and agreement reached as to what to do next. For us, this was enforced through meetings with the course supervisors every week, though we tried to do more on our own most weeks.

Sean: I would highly recommend organising meetings specifically for updating members on your progress as well as meetings specifically for talking about model development. These can be part of the same meeting but I think that allocating time for each is extremely important so that all members are up to date before talking about developments.

I would also urge groups to have a look at what different softwares are available to help with specific aspects of remote working. Finding the collaborative Jupyter software (Deepnote) was extremely helpful in ensuring the coding progress did not take a back seat.

What is your favourite thing about MDM in general?

Will: The variety of the possible projects and the fact that they usually involve the consideration of many different aspects of a problem makes it more interesting to work on. In MDM3, the projects coming from real companies with real problems that need solving also makes the work exciting and outcome much more tangible.

Jack: The freedom to interpret the problems and not have a rigidly defined scope. In general, problems are vague, with a few specific questions as guidance as to what approaches could be undertaken, but the marks don’t come from answering any specific question, such as in an exam, but from the quality of the overall work.

And your least favourite thing?

Will: The fact that your work/grade can be influenced by group members who put in differing levels of effort into the project. This can work both ways though and is somewhat representative of working in a team at a real job. This also becomes less of an issue as you progress through uni.

Jack: Sometimes the variability of problems means that one time you can be given a problem with a clear path to follow, and the next you have such a difficult problem that actually answering the basic questions in the problem are beyond the scope. This isn’t too big a problem, as the supervisors are aware of how the project is unfolding and have influence over the final mark, and the marking criteria are generalised in such a way that answering the question is not necessary if you investigate something related.

Sean: The week or so before the deadline where all the technical work is done and it’s all down to writing the report and refining it until it’s perfect. This process seems to drag on and I’m always glad to have it done!

What do you wish you had known when you started doing MDM projects?

Will: That MDM isn’t about always getting the best solution to a problem, but instead more about understanding how your proposed solution fits into the landscape of existing solutions and what can be learned from your efforts.

Jack: I wish that I had been a little better at teamwork. I would normally have an idea of what I wanted to do, and I would either try to make that the project, often not leaving much work for the others, or I would work on it separate from the group, leading to a sometimes disjointed report where sections didn’t necessarily fit into a cohesive narrative. Getting better at letting other people have ideas and fitting my ideas into the team’s has greatly improved later projects.

Sean: I wish I had known the importance of taking a good amount of time to understand the primary aim of the project and the motivation behind it before jumping straight into technical works. Taking a week or so to really research the state of the art, read any relevant literature and also build a mental picture of how you want your project to fit into all of that will definitely make it easier for you to decide on how detailed you want each aspect of the project to be. Having this framework in your head before you begin will also help you create a clear narrative when it comes to report writing.

Anything else you would want to pass on to a student doing an MDM project for the first time?

Will: Don’t be afraid to critique your models and methods – knowing why they’re not the best, and where improvements could be made is really important. Start writing the report once you start developing models and getting results – try not to leave it until the last day!

Jack: There is always a temptation to specialise in the thing you are good at, which isn’t necessarily a bad thing for a group project, but can leave you with skill gaps, which could cause difficulties especially in the individual final year project. I always tried to do programming and simulation work, and would try to leave research and theory work to others, but as I was already reasonably proficient in those areas, I didn’t grow my skills as much as if I had taken up different areas of work in each project.

Sean: Don’t panic when you realise you haven’t solved your problem with a definitive answer, try and view your work as a stepping stone for the next person or group build from!