Friday, September 12, 2014

Learning from a Project - "Post-Mortem"

When I think of a project that I learned a great deal from, a specific one comes to mind. The project goals were reached in the end but the process was disastrous. In retrospect, there are a few components that could have been done differently to make the project a success. To provide some background, this project was created as part of a mandate from the Consumer Financial Protection Bureau (CFPB). As part of the mandate, our organization was required to create a process for logging customer concerns and complaints. All branch employees had to be trained with the new process and we had 120 days to do it. This meant that we had to outline the process, create a system, and train all employees in this short period of time.

To get all parties involved, there were two project teams created. One team was mostly comprised of the organization's upper management and project champions, with a few functional employees. The second project team was that of our internal training team which consisted of functional employees and two project champions from the other project team. Each project team had a different project manager.

One problem was that the smaller, internal training project team had to await instruction from the larger organizational project team before actions took place. This created a huge communication problem because the left hand didn't know what the right hand was doing. The project champions that were engaged in the larger team would come back and report the "next steps" to the smaller team which included important details and timelines. This process didn't leave our group with much time to execute, which left everyone in a panic of meeting the deadline.

The second problem was that the larger team wanted our group to create the training simultaneously with the policy and the system. This was difficult to do because we needed both to reference in the training. The training had to be revised multiple times as the larger team tried to nail down policy definitions, scenarios, and exclusions. In addition, systems had their share of glitches as we tried to capture screen shots of what the process looked like.

In the end, the project deadlines were met with only 24 hours to spare (no room for error). Looking back, we could not change the CFPB's deadline but the following would have made for a smoother project:

  • Include the Instructional Designer in all project teams and meetings. Obtaining any information firsthand can help the ID draft designs and get an idea of what the project team is envisioning. 

  • Communicate frequently. Time is of the essence for any project so when a project deadline is extremely tight like this one, it is crucial to share information as soon as it is received.

  • If at all possible, policies and systems should be created first. This will save time and resources when the training is created. This will also eliminate multiple attempts to create training that relies heavily on the two components being in place.

  • When faced with a project with stringent timelines, the IDs functional manager should be informed every step of the way. This will help the functional manager when scheduling other projects for the ID.

No comments:

Post a Comment