PLM Power #1 – Solution Simplicity

Keep-Calm-and-say-no-T-Shirts.png

Some years ago I had a PLM implementation client that wore a t-shirt to steering committee meetings that had the word “NO” written in big, bold letters across his chest. He understood the challenges of implementing powerful and flexible software for a constituency largely comprised of engineers.

The composition of the user base in PLM programs is both a blessing and a curse. Engineers are hardwired to make things better, to improve, to automate, to ask “if only.” This is great when we are doing unconstrained “visioning,” but is a real problem when it comes time to get things done on a schedule.

Initial deployments of PLM software should use standard leading-practice processes and out-of-the-box functionality. The software providers have spent the past fifteen-plus years building capability into their platforms. Complex workflows, process automations, input validation routines, system interfaces, and all forms of software customization should be avoided completely. Initial deployments should focus on foundational capabilities that can be enhanced over time.

I am not suggesting that there is no value in these enhancements, I am only saying that quickly laying a strong foundation must be the priority. If saying “no” is difficult, then say “not now” instead. Program cost is a big consideration in these decisions. Initial deployments tend to be large, overhead-intensive exercises. It is often better to push the development of “nice to have” features off on a support group that can build them at a lower cost (define nice-to-have as anything that requires development work).

Keep your initial deployment basic and foundational. If you are running a PLM implementation program, go get you several t-shirts that say “NO”.