Reviewing a Project in Hind Sight

“It's important for project managers and team members to take stock at the end of a project and develop a list of lessons learned so that they don't repeat their mistakes in the next project. Typically such reviews are called  post-project reviews or "post mortems’” (Greer, 2010, p. 42).

At the conclusion of any project, it’s helpful to collect the “lessons learned” (Greer, 2010). Lessons learned allow us to learn from our mistakes and perform better in future projects. A post mortem review allows all of the members of a project team to reflect and identify both what went well with a project and what didn’t go well. By capturing the collective experiences and views of the project team, the team members can use this knowledge to improve upon their project management skills the next time a project is undertaken.

Recently I applied the technique of conducting a post mortem review of a project that I, as an instructional designer, worked on recently. The project entailed working with a college faculty member to develop a new online course. This online course was unique in that we were going to implement a new feature in this course that would set it apart from the courses that we usually offered. The course design would be very innovative and open up new doors and opportunities for faculty teaching online courses by allowing individual faculty members who would be teaching the course to pick and choose elements of the course that they wanted to use – rather like a buffet, from which the faculty could pick and choose lessons, activities, and assessments to their liking. This mode of course design would allow faculty members to offer “themed” versions of the course. The design was established in a collaborative manner by me, the instructional designer, and the faculty member. The faculty member was excited about the new innovative course design. The project broke down, though, when it came time to discuss how the course would be implemented and deployed in the learning management system. The faculty member had in mind that the course would be implemented in a particular way, but I, as the instructional designer, informed her that her vision of how the course would be implemented in the learning management system was not practical from an ongoing maintenance perspective, and that it violated some important departmental policies. When I explained how we would have to implement the new course design in the LMS, she was very disappointed and unhappy with the plan. This disconnect between how the faculty member envisioned implementing the course in the LMS and how it would actually need to be implemented was so great that the faculty member withdrew her support for the innovative project altogether. Instead, a traditional course was developed that had none of the innovations we were intending.

In hindsight, it is clear to me that there should have been more discussion and planning in the early stages of the course design process, so that expectations of both the faculty member and the online course development department could be identified, addressed, and explored more fully. The faculty member, who was a key stakeholder in the project, had certain ideas and expectations in her mind that were not articulated, and she had made certain assumptions. Likewise, I as the instructional designer had made certain assumptions that had not been communicated to the faculty member earlier in the requirements gathering and design process. In the end, articulating and exploring our differences in vision may not have saved the innovative nature of the project, but it would have saved us time in that we would not have gone so far down the design and development phase before we realized there was a disconnect and our path would need to be changed. We ended up doing a lot of design and development work that was ultimately scrapped.

In my example of a project post mortem, inadequate communication of visions and unspoken assumptions were the weak links in the project process. In future projects, I would use those important “lessons learned” to prevent similar mistakes from occurring. I would be more specific and more thorough in documenting and describing all assumptions about a course design project, its design, development and implementation, particularly when the implementation was going to be something different than our normal process.

References

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.