Differing natures of the projects

Considering the second research question is focussed primarily on how the different elements of the project impact the learning, it is worth here comparing the structure of the two projects, before then focusing on what impact these structures had. In this section, I will first focus on the aims of the two projects, which were laid out in quite different ways. I will then consider how the structure of the projects was designed to meet those aims, and how effectively it did so. This I hope will provide a suitable backdrop for relating the different learning

outcomes each student experienced.

The differences between the projects became evident as soon as the project syllabi (Appendix A.1 and A.6) were available. The Water Management project is laid out in terms of project outcomes, and learning and teaching objectives. The former laid out the three target outcomes: “produce a management plan for a local river”, “make a catchment conceptualisation map”, and “deliver an event for primary school students based upon water management”. These are followed by a series of learning objectives that are primarily factual/conceptual/foundational (Anderson et al., 2001; Fink, 2013) and a series of teaching objectives that are primarily

procedural/application (Anderson et al., 2001; Fink, 2013) in nature. This is then followed by a breakdown of the weeks of the Challenge, with broad categories such as “Analyse weather pattern data and conservation” or “abiotic factors”.

The Computer Science project brief likewise suggests an outcome-students analyse data to identify themes which can then be used to do one of two things: sell the intelligence (to

investor or customers) or sell the solution (to a problem found through the analysis). There is also a section titled “things to consider” that includes prompting questions related not only to the technical skills, but also to the underlying philosophy of such a project. This project too comes with a timetable, though it is more of a schedule of deadlines than a list of topics to be covered. The difference may come down to the source of the briefs; in the case of the Water Management project, an instructor from the UTC was the primary course designer. In the case of the

Computer Science project, two external employers worked to design a project within the Industrial Cadets framework.

The differences present in the structure of the project briefs were largely mirrored in the structure of the courses themselves. The Water Management project featured individual sessions aimed at allowing students to meet each of the learning objectives, e.g., the learning objective “Learn a range of biotic and abiotic sampling and analysis techniques” was designed to be met through the activities on the 28th of March and the 18th of April (Easter holidays were responsible for the break between these dates). The dates designated for biotic and then abiotic sampling were swapped due to personnel availability, but the lesson structure and outcomes remained the same. Because each student was responsible for completing each of the activities, there was relatively little flexibility in what tasks the students accomplished and when. On the 21st of March, the weather data tables were all compiled during the time dedicated to compiling, for example. Except for the final session where the students were planning and running activities for the primary school children, they had relatively little direct input into the tasks for each day, with the majority of time structured for either direct instruction or developing prescribed skills.

The Computer Science project was much less structured in terms of what was being accomplished on which date. While specific dates were set by which students needed to submit interim and final reports, it was left to each group to determine how long each individual task would take them. From the project brief, it might appear as if the expectation had been for students to spend several weeks planning and a single week coding, but input from industry mentors meant that few students stuck to this suggestion. It was indeed merely a suggestion, as both the mentors and the instructor encouraged the students to adapt the project to their needs. For Hannah and Jane’s team, this meant creating the presentation and the product

simultaneously, as there were enough people to have group members dedicated to each role. It was also more difficult to prescribe a certain number of sessions to each element of the final

project as the end product in the CS project was in many ways more open-ended than the Water Management project.

The CS project did have some limitations that the Water Management project did not, however, primarily in terms of practical limitations based on the software the students had access to. Aside from the difficulty of teaching still relatively novice programmers a new language and expecting them to be able to successfully implement it in a completely new sort of program, students also found that they had little idea how to check their work and make corrections in this new language. As Hannah put it, “it’s just silly stuff like that that anyone could really miss kind of thing if you don’t do this as an actual job” (H.18.05.15 lns 159-160). This was also true of being able to manipulate the program to present the data in alternate formats. While there were plenty of options regarding how to present the networks, students had to make a choice from that list, as developing new features was well beyond their abilities. The company that produced the software spent months developing and testing the combos feature that Hannah was so proud of mastering, for example. While the CS students had fewer restrictions on their time than the Water Management students did, there were restrictions on them nonetheless.