As I have stated before content is always a challenge so I really appreciate reader suggestions. I can't believe I didn't think of this one myself given that I am a big fan of the AMC show but many thanks to Alex Dye at Masterlock for the idea. As you can guess from the title we are talking about the undead, projects that never seem to end. I have noticed that there is a tendency in the Product Lifecycle Management space and I suspect in most complex enterprise software implementation projects for them to linger and extend and just continue stumbling along. This obviously draws parallels with the undead zombies on Walking Dead that require a shot to the head to go down. As we saw in the next to last episode this season even breaking necks or knife wounds to the gut don't seem to be enough. You have to be emphatic when you put down a zombie and you have to be emphatic when you end a project or they will in fact eat your brain or maybe your company. This article will review best practices on how you structure and manage PLM projects so you and your company can avoid becoming zombie bait.
The biggest problem I have observed with both zombies and some PLM projects is that they both don't know that they are dead. The zombies don't know they are dead because they have no brain and really the PLM project issues are similar. Typically zombie PLM projects suffer from poor definition or a lack of deliberate closure. I recently read a nice article at Tech Republic titled "10 things you should do near the end of a project". Among the things discussed were validating deliverables analyzing actual vs. planned and getting project sign off. These are all great suggestions but unfortunately if you haven't done the work up front they might be difficult to accomplish. One of the keys to ensuring that your project doesn't go undead on you is to identify key milestones and metrics up front. If you haven't established the criteria for closure at the beginning it can be difficult to get signoff at the end.
At Zero Wait-State we have started to become very deliberate about closing projects with our clients but what I am learning is that while having project signoff procedures in place is very important they don't work very well if you don't build the criteria for sign off into the upfront documentation. Clients are very leery about saying something is finished if there is any ambiguity about what being finished means. The only way to eliminate this ambiguity is to be very clear about what the deliverables are and how they are validated. Defining the process for validation and the expected criteria for this validation are really the only way you can ensure your project doesn't keep popping back up and devouring your efficiency. In your typical project this is pretty straightforward but in PLM land it can get pretty fuzzy. Clients have a tendency to make adjustments along the way as they gain better understanding of what PLM can do for them. Their security models become more intricate and their workflows become more extensive. It is critical that these aspects of the project are locked down up front or you will find yourself running through a swamp running out of ammunition about to be devoured by hungry clients /zombies. You can't always count on strange hooded women with swords to emerge and rescue you (Walking Dead Finale Reference).
The key is to do the work up front. Answer the questions as to why you are implementing PLM and what are the objectives of the project. Define the metrics and the tasks in specific language and be intentional about how these milestones and deliverables will be validated. The closure process should be clear and understood by all parties and should be used throughout the project not just at the end. Both parties should review each milestone and evaluate the success of the project throughout to ensure that it goes well. By being intentional and proactive you can avoid walking the earth mindlessly adding attributes and product classes. With all this talk about zombies and the walking dead I guess post-mortem meetings take on a new meaning.
[Edit: Repost from 2012]
