#PBL as Professional Development (Part 4 of 6)
The Implementation phase is the lengthiest portion of any project, where much of the action takes place. Our #PBL professional development is no exception.
During project implementation, all of the HQPBL principles are being practiced: intellectual challenge and accomplishment; authenticity; public product; collaboration; project management; reflection.
To manage the project development, each team develops a project plan, identifying roles, responsibilities, tasks, constraints and project timeline.
Once this infrastructure is determined, the teams develop solution(s) to their driving question. Required tasks typically include research, consultation with subject-matter experts, prototyping, and collaboration with others, sometimes outside of the team and/or outside of the school.
In order to monitor the robustness of solution development, peer reviews are scheduled on a periodic basis. Critical Friends protocols, such as The Charette provide a structured environment for others to offer constructive feedback to the team. These reviews serve as formative assessments and often lead to modifications to the solution development.
Reflection is another essential component of implementation that is conducted on a regular basis. Reflection can be done as frequently as daily, and at a minimum formal reflection should be done at each project milestone. Team members reflect on the project progress, their contributions, and the contributions of the other team members. The reflection process is also useful for the team to examine how well their solution is responding to the driving question. If needed, the team corrects their course.
Once a (draft) solution is completed, the project team presents it to the whole professional development group for critical review. Ideally, outside experts are also included in the review. The process is the same or similar as in prior peer reviews, a structured session where the audience provides formal feedback to the team.
Based on the audience feedback, each team revises their solution(s). In some cases, this requires a return to the design step, an alteration to the design. An example of this would be where a solution requires different resources than originally identified. The team would need to return to the design and modify accordingly.
As we can see, revision is a frequent and ongoing characteristic of the implementation phase. Implementation is highly iterative, and time must be built into the project schedule to allow for multiple revisions.
Next, we discuss testing our solutions!