Learning from a Project “Post-mortem”

The Project: Implementing a Learning Management System (LMS)

One way to learn best practices and avoid mistakes within a future project is to review the results and activities from a project that has been completed in the past. For this assignment and in utilizing the process called project post-mortem, I recall a task that I wanted to soon forget. Breathing life back into this buried project in an effort to extract a valuable lesson for future projects, is a task my company was given to handle, which was to customize and populate a LMS with student and staff information, upload course deliverables for immediate access, and ensure tracking was accomplished when students were logged in. One of my first assignments was to PM/develop, and populate courseware to the Meridian Learning Management System which was a software interface that was meant to install on a local network that would track students according to degree plan, capture student information, and follow student progress from registration to completion. The project deliverables needed to include:

• Customize the Meridian LMS software to look and feel our corporate image/style
• Upload all instructional modules into the LMS
• Incorporate a web interface / login for staff and students
• Adjust permission levels for all administrators, instructors, and students
• Track all personnel when logged into LMS

I was the PM with the responsibility to plan, organize, and coordinate the project to ensure it was working and tracking properly. Mistake #1 (of several), I did not accomplish a statement of work (SOW), without doing a SOW and talking to key personnel such as the IT department (who would be able to determine early in the project that the servers were not going to be able to handle the Meridian LMS due to security issues and permission constraints, but without seeking out these key players or doing an SOW which maybe raising issues under the risks category - this task was dead in the water before even starting). I believe now a SOW would have given us an idea of this potential risk or at least have addressed all the key players that would have been involved.

There were several contributions to this projects failure. A critical aspect was to not include all key players in which the task needed its support. In this case the IT department is one of the most important departments to include in the planning process. A project could be planned based on current technologies, but the organization’s technological infrastructure may not be able to handle the planned technologies. As Portny, Mantel, Meredith, Shafer, Sutton, and Kramer, (2008), state “New technologies and materials become available or new requirements and needs become apparent during a project; any of these can lead to changed projects” (pg. 346). This information became a real turning point for our project. We utilized a new technology that our IT department was unable to support. We were all extremely unclear on how the IT department could stop us in our tracks, but this “scope creep” could have been prevented if the right people were involved or consulted. We had not thought of the IT department during this project, but later recognized they can be an important part of the team. Communication is definitely a critical component for keeping everyone on target and reducing the possibility of failure. Portny et al., (2008) noted a project goes through several phases. They include: conceive, define, start, perform, and close. In this case because we were deficient in these phases and our project failed.

Greer (2010) noted it is important to be clear about the project concept to get the support from key people in your organization. We were overeager and overconfident that this was going to be a smooth and rather ‘easy’ project that we failed to consult with the key players that in turn would advise and help us with this project. If we were to have developed a SOW or a Project Charter (Portny, et al., 2008) that formally launched and acknowledged the existence of the project it may have saved three months of development time, man power, funds, and resources. By the time the project was at the stage that several fixes could be implemented to accommodate and be successful, the stakeholders stripped the task from us [the contractor] and requested to implement a different interface that could accomplish a similar task without the use of Meridian LMS on the local area network. The stakeholders were displeased with the project direction and progression so our project was abandoned, we were stripped from the task and lost all the funds that were granted, along with a break in relationship as we were viewed as incompetent therefore lost out on future contracts.

Some positives  

The process was an eye opener for the organization. There were some very real lessons learned from this failure and that is how imperative the initial planning, incorporating the right people to support the project, scheduling, and defining the project scope, these aspects would have made a significant difference in the outcome of this failed project. Portny, et al., (2008) lead us to insights when they discuss the three basic responsibilities of project management which are:

• Planning • Organizing • Controlling

These attributes in conjunction are the keys to a success project plan. By specifying results to be achieved, determining schedules, estimating resources required, organizing includes defining people’s roles and responsibilities, reconfirming people’s expected performance, monitoring actions and results, addressing problems encountered, and sharing information with interested people (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008) success will be achieved. Our team lacked knowledge on how to make this project a success from the very start in the future involving critical key players and understanding the political nature of any project will be first on the list. Our team thankfully recovered from this but it did take time, as we proceeded very cautiously and cover ourselves more now.

References:

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

Portny, S., Mantel, S., Meredith, J., Shafer, S., Sutton, M., & Kramer, B. (2008). Project Management planning, scheduling and controlling projects. Hoboken. NJ:John Wiley and Sons, Inc.