This article is part of our series on how to help students develop their collaborative superpowers and maximise the effectiveness of working in teams across a PBL project. To learn more about how we approach and teach collaboration, check out our collaboration roadmap.
Team conflict is a source of frustration for students and teachers alike within PBL projects. It can sour the interpersonal dynamics within a team and derail the team’s productivity. In extreme cases, teams might become entirely dysfunctional and must be re-formed to ensure students are motivated to work through the rest of the project.
It follows, therefore, that a key way to manage and prevent team conflict is to identify the tasks or stages of a project when it is likely to arise and to give students tools and structures to negotiate those tasks without conflict arising. And nowhere is the risk for conflict more prevalent than when a team must make a major decision that can alter the course of their project.
Significant and consequential team decisions typically occur at two points across a PBL unit; when students are choosing which problem to solve, and when students choose which solution idea they want to take into the prototyping phase. The decisions made at these points alter a team’s trajectory and focus across a project, and it is highly likely that conflict could arise where team members have differing views on the course their team should take.
The process is the problem
It is unrealistic to expect that every student will be in complete agreement on the best way to solve the problem they are exploring through a project, or that each student will unanimously agree on the single best idea (from the 20+ they might have suggested) to solve that problem. Of course, some students will be disappointed if their preferred option is not the one chosen, but this ordinarily is not enough for teams to disintegrate. When serious team conflict does arise, it is often because of the process which is used to make the decision, rather than the outcome of the decision itself.
Teams often make decisions by relying on the loudest or most dominant team member to drive the outcome. If there is more collaborative input, teams rely on crude methods like ‘majority rules’ to make pivotal decisions; in doing so, they deny the ‘minority’ student the chance to argue their case or have their opinion heard. When students feel like they have no say in what the team decides and aren’t being listened to, their level of buy-in plummets. This lack of procedural justice is typically what causes the disenfranchisement and frustration that leads to conflict.
What students need, therefore, when making these pivotal decisions is a structure that they can use to ensure the decision-making process is fair, transparent, and that each student has the chance to contribute. If this can be achieved, a team member is more likely to accept a team decision even if it is not the one they would have voted for. This is where the DACI decision-making model comes in.
What is the DACI decision-making model?
The DACI decision-making model is a framework to help teams structure group decision-making in a way that clarifies each student’s role in the decision-making process. There are four key roles within the model which make up the acronym ‘DACI’:
D = Driver. The one person responsible for corralling stakeholders, collating all the necessary information, and getting a decision made by the agreed time. This may or may not be the team leader for that task. However, they are not the ones who make the decision
A = Approver. The one person who makes the decision. They hold the casting vote
C = Contributors. They have knowledge or expertise that may influence the decision and provide input, but do not make the decision. They have a voice but not a vote
I = Informed. They are informed of the final decision but have neither a voice nor a vote
In a team, one student should play the role of the driver, one should play the role of the approver, and the remaining team members should play the roles of the contributors. Students can swap roles across the course of a project for different pivotal decisions.
No team member should play the role of the ‘informed’ person with no voice or vote – this person represents the teacher or someone external to the group who should be kept updated of their decision.
To ensure that the decision making process is effective and impartial, the driver is responsible for ensuring each of the below points has been covered and explained by the contributors so that the approver has enough information to base their decision on (and to justify their decision to the informed person/s):
Background – the reason(s) this decision is required
Supporting data – the research that has been done to inform this decision
Options considered – each option with a summary of pros and cons
Recommendations – opinions from the contributors
Outcome – a place to state which option the team ultimately goes with
Action items – a list of tasks or follow-ups related to the decision
Why this works
Helping students make decisions using this model does a few things. It gives everyone a structured role. It ensures that the approver (who has the casting vote but who does not actively campaign for their preferred solution) must make an impartial decision based on the evidence and the best strategy, using all available evidence. And by separating the role of the driver and the approver, and the approver and the contributors, it prevents the most active or loudest student from taking control of the decision. It also short-circuits potential stalemates caused by teams not being able to agree on the way forward. It allows for a quick decision to be made, but using a process that is fair and transparent, where everyone has had input into the decision. This is crucial in creating a decision-making process that is procedurally just and where each student can feel like they have contributed to the decision being made.
This approach also forces students to think critically about the decision, rather than relying on the individual preference and persuasiveness of the team leader. The independent (and theoretically impartial) approver can only decide on the basis of the evidence presented to him/her, which forces them to both park their own bias but also to ensure that they moderate the bias of the contributors in the arguments or suggestions that are being put forward. This process therefore not only facilitates more inclusive decisions; it promotes more carefully considered decisions as well.
What to be aware of
Though the DACI model works well, there are a few things to be aware of to ensure it operates as intended:
Ensure the contributors do not become the approvers. Students must stay within the confines of their role. A contributor can put their opinion to an approver, but they cannot attempt to control or overly influence an approver into making the decision that they want
Encourage the approver to play an active role. The approver does not need to passively choose from the options presented to them by the contributors. However, they should not take into account information which has not been presented to them – this would open the door to an abuse of process. That means that if an approver thinks some information is missing, or that an obvious option has not been put forward the contributors, they must suggest to the contributors that more information or consideration is required. Ultimately, the approver must ensure they have all the information they need to make an informed decision
Ensure the driver feels heard. The driver does not make the decision or actively present information to the approver, so there is some risk that the student playing this role might not feel like they have been able to put forward their own view. To prevent this, the driver should be permitted to work with the contributors early in the process to make suggestions about what they could consider and the options they could present to the approver
Disagree and commit
Of course, the DACI decision-making model only works if the rest of the team are prepared to accept the decision made by the approver, assuming it is properly made. This is where a ‘disagree and commit’ ethos should be instilled and reinforced across the project.
The ‘disagree and commit’ ethos means that teammates can disagree on the course of action the group is taking but they still commit wholeheartedly to the actions that will flow as a result. As mentioned above, it is rare that every person on a team be in complete agreement with a plan or idea. This should not be the goal. Instead, the goal should be that each team member agree to get on board with the decision or plan that has been made and implemented, rather than allowing resentment to lead to a student downing tools or instigating conflict.
Again, for this to occur, each student needs to feel heard and that they have had input into the decision-making process. They also need to understand the other students’ perspective of why they think an alternative approach is the best way forward. It is therefore the combination of this ethos and the DACI decision-making model that help teams work through large decisions without conflict, whilst this ethos alone can help teams navigate the smaller decisions which might not dramatically alter the course of a project but which students still hold strong views on.
In her article, Carla Willis spoke about a student who was upset by a difference in decision of what colour their prototype should be – this is a perfect example of a small decision which can nevertheless lead to conflict. The DACI decision-making model is too structured for these micro-decisions, so the ‘disagree and commit’ ethos – provided each student feels heard - can fill the gap. When used in tandem, they can significantly reduce conflict and enhance collaboration within teams.
Do you know an educator who would be interested in learning more about how to build collaborative skills in students? If so, please share this article with them!
If you are passionate about teaching collaboration and want to learn more, get in touch with us at firstname.lastname@example.org. We’re always happy to exchange ideas with our PBL community!