Before I begin, let me start by saying that if your institution is doing project-based learning (or PBL, as we call it in the ‘biz’), then you are already ahead of the pack. Most engineering education is still stuck in the lecture-and-lab paradigm and struggling to innovate in that space. Other educators have struggled to make projects engaging and meaningful, and have fallen back on prescriptive by-the-book ‘projects’. The challenges of teaching using projects are numerous but soluble. What is much harder to fix, in my opinion, is that today’s PBL does not reflect how engineering design actually works.
What is Project-Based Learning?
At its core, project-based learning leverages students’ intrinsic motivation to solve real-world problems as a vehicle for learning. The focus is on authenticity and context for the problem, usually involving actual stakeholders. Students are presented with a complex problem and asked to work for an extended period on developing a practical solution to the problem. The intention is for students to develop the ability to critically analyze and solve a problem just like they would in the “real world”. Learning should happen as a natural part of the problem-solving process, and assessment is managed through presentations and demonstrations of the solution. If all of this sounds fantastic to you, you’re not alone. PBL is the darling of modern engineering educators the world over.
So what’s the problem?
In a word? Limitations. There are simultaneously too many, and too few restrictions on PBL projects. Let’s start with the project definition. PBL encourages students to pursue a problem with personal significance and interest. If you follow this guideline too openly, students are likely to get lost trying to solve huge, systemic problems. That is especially problematic now as students are more and more engaged with global issues.
To combat overly audacious projects, educators often place rigid limitations on the scale and/or application of the project, which can unduly limit students’ creativity. At the other end of the project is the deliverable. On the one hand, student projects are often limited principally by time and minimum deliverable requirements. However, there are remarkably few of the kinds of actual limits that engineers face every day, such as space, heat, safety, or other regulatory limitations. We want students to be free and express creativity in problem-solving, but in practice, we provide neither freedom nor real problem-solving experience.
What’s the solution?
Systems-level thinking.
Okay, that probably needs more explanation. All of the issues mentioned above have to do with the fact that engineers don’t solve grand global challenges. They solve small, highly constrained problems that come together to create a system that solves those challenges. These are very different. Today’s PBL is so focussed on the narrative of solving grand challenges that we forget that’s not how challenges are solved.
Instead of setting a whole class of students loose on the same problem in groups of 3-5 people, we should be getting the whole class involved in creating a single solution. We need to maintain the microscopic team interactions within a small project group, while also fostering macroscopic interactions among multiple groups. Work as a macro group to define the solution, then break the work out into smaller chunks, which can be meaningfully solved by a small task team. That has the added value of imposing external requirements on each project group as a matter of course. The course coordinator doesn’t need to tell each group what they need to produce, or what size it has to be, or how hot it can get. These limitations will come from the larger context and the needs of other teams.
Is this practical?
On the one hand, course coordinators will have to put more effort into managing the top-level operation of the class. Performing project management at the top level will take up a much larger portion of the work. However, a lot of the minutia of assigning tasks and deliverables to individual teams will now shift to the students. All this is not to say that you can’t create a highly structured learning environment. The relationship between the “project manager” and the task groups can be as rigid or as flexible as you like.
Realistically this approach doesn’t even require any significant creativity in the structuring of the class. Simply run the class like you would an actual product team in an engineering company. This could mean agile, kanban, or any other management structure. It would also be possible to take a single project and stretch it across several years of a course or multiple courses. That would have the added benefit of introducing a need for good documentation and support for legacy solutions.
Will it be easy? No, probably not. Will it result in more capable engineering students? It should. Will it engage students? Certainly.
Okay, what now?
I realize that this kind of paradigm shift isn’t going to happen overnight. Step one is making student design groups work together to solve a larger problem. It doesn’t even have to be a novel problem. Make students design a car, or a word processor, or toothpaste. We are in an era where the design of everyday things has a massive impact on global scales. Once you have students solving a problem, remove as many barriers to collaboration as possible. That includes providing scaffolded solutions to well-established problems, and flexibility in tools and approaches to a problem. It’s not going to happen overnight, but real engineering companies are grappling with these sorts of projects every day, and it’s foolish to include them as “stakeholders” in PBL without preparing students to apply that problem-solving experience in a real context.
