ID Project Post-Mortem

I was recently involved in a project at work for release of a new software system to employees. This project was unusual from the beginning and fraught with problems.  In this blog, I’ll review the project and discuss some of the lessons learned and how this could be addressed/corrected in the future.

This project involved introducing a new timekeeping software to our organization. We were moving from an entirely paper-based processing system to an online tracking system for exempt and non-exempt employees. The project is being rolled out as a pilot to a smaller group of employees with a release to all employees within two months of the project date. So, let the project autopsy begin:

Let me preface this by saying that our team was not involved in any initial meetings with the vendor, vendor selection, or review of the software. The focus on this project was that we were the training deliverers, and they’d let us know when they needed training – very much a hands-off approach (despite our pleas to be involved earlier.)

As I said, our team was not involved in the selection of the vendor, or the review of the product. This very much affected our project deliverables. The internal client relied on the software vendor to offer their ideas of training. Of course, the vendors preferred training approach would be that the vendor provide the training. Failing that option, the vendor suggested training methods that had been used by other clients. Again, we weren’t involved in this stage.

The training deliverables and schedules were developed by the vendor and the stakeholders. Our team was brought in about 3 weeks prior to pilot group training. We were tasked with making training materials to distribute during class, and provide the initial training to the pilot group. After the pilot training, all future roll-out training would be performed by the project stakeholders (not trainers).

Of course, the biggest issues with this project revolves around the lack of involvement in the planning phase and the training deliverables. Throughout the entire process, our team was running in place trying to get materials produced with a ticking clock next to us.

What would I do differently?

  1. I would have requested earlier involvement in the process, preferably as the product was being reviewed to gain better understanding.
  2. Ideally, our department should have been involved in the creation of the training plan and schedule.
  3. I would prefer to have an opportunity to do some kind of needs assessment and tailor materials to that, rather than be handed a product developed by someone else.
  4. Our group should be involved in future training, so we can continue to improve the process.

I hope that everyone in our group has learned an important lesson about the process. This definitely was a project where the stakeholders defined the project and the project scope.  Of course, memories fade after a while. Hopefully, we won’t have to re-educate team members in the project development phase in the future.  

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s