Lessons Learned in Project Management

I originally wrote this post in 2015 after a particularly stressful project. It may be an oldie but it’s still good. Writing down Lessons Learned is an essential part to the end of a project. The best way to do it is to get the team together, and in a Sprint-like retrospective go over what went well and what didn’t during the project. The lessons should be from the team or company perspective, not place blame on an individual.

Let’s take a step back in time, to see what happened during this manufacturing execution system (MES) implementation.

Sorry for the hiatus but sometimes you have to get down into the trenches of project work. I recently gave a week of training on a new MES for a plant. Unfortunately, I wasn’t as prepared as I thought. After months of designing and developing the system with the end users I assumed it would be a good training of “this is how the system works”. Instead, it ended up similar to one of our Sprint demos.

Common questions:

“Could this be a dropdown instead of a textbox”?
“It would be really great to include these few other columns”
Or my favorite, “this won’t work for us at all” (before even starting the training).

Wow. Those are a lot of requests for being the end of a project. It’s a good thing we planned in buffer time to address any requests that may have come out of training.

Prioritize change requests with the end users in the following manner, “Is this feature essential to Go Live?”, “Can the task be done with the way the system is now?”, “Is it acceptable to implement this change post Go Live”?
Be realistic what changes can be implemented in the time from Training to Go Live. If a feature is essential to Go Live but there isn’t enough time to develop and test it before hand, a schedule change might need to be addressed.
By asking these questions and working with the end users to answer them, it helps to build by in to the system and expectations for User Acceptance testing.