Is PLM a Destination or a Journey?

Is PLM a Destination or a Journey?

Over the years there have been many celebrations when a PLM system finally hits the “Go Live” point.  Champagne is opened, backs are patted, and there can be a general feeling of satisfaction at releasing the product into the organization.  Oh, to be young and naive! I have, on occasion, described rolling out a new PLM system as being a bit like giving birth. It’s painful, messy, and quite expensive. Even though you are thrilled to have it you will spend countless sleepless nights trying to make it stop complaining.

While this may mean job security for the PLM consultant role, it raises the question, “Is there a better way?” Having talked to countless PLM customers over the years this can go two ways.

In the first, most common scenario, the functionality missing that makes it possible to achieve business value is planned into “Phase 2.” There is always a phase two!  Or three, or four, or they stopped counting because the next big release is going to “fix everything,” which simply restarts the cycle.

The second scenario is certainly more promising. A company will roll out very basic, out of the box functionality with a very limited scope, such as ECOs or document management, in a short time with a small budget. From there, they begin to gather requirements for improvements and analyze those requests according to the required resources and the importance to the business. Whatever is at the top of the list gets incorporated, and a secondary, smaller deployment happens between 2 and 6 weeks later. This continues until the system meets the business needs. Of course, the only constant in business is change, so this could certainly continue as long as a company is focused on continuous improvements.

Waterfall vs. Agile

Seasoned veterans of Enterprise software deployment already know that the two scenarios above represent the difference between Waterfall and Agile project management methodologies.  Waterfall projects have dominated the Project Management best practices according to the PMI (Project Management Institute) for a very long time, and with good reason. Many contracts are specifically written AFTER the requirements phase has been documented, and the client wants to know precisely what they are getting and when. 

The problem is, you simply don’t know what you don’t know. In the time it takes to deliver on the promised scope two things always becomes apparent. One, someone forgot something, which leads to the dreaded “scope creep” or “change orders” that cause the project to cost more money and take more time than originally planned. Secondly, the business changes.  Mergers and acquisitions take place, disruptive technology is introduced to the market, customer demand shifts, global macroeconomic conditions change, regulations are introduced that require compliance, new management enters the project, a newer version of the software is introduced, or a variety of other changes happen. The probability of change happening over the course of a waterfall project far outweighs the probability of conditions remaining the same. 

In the second scenario, commonly recognized as Agile Methodology, all of the same steps are followed. However, the Gather Requirements, Design, Develop, Test, and Deploy steps happen much more quickly. Where a traditional Waterfall project can easily take 2-3 years to reach the “Go Live” date, a typical agile cycle (called a “Sprint”) happens every 3-6 weeks, depending on the development team. An Agile team, along with their executive sponsor, begins with a Minimally Viable Product (MVP), and customizes the solution from there. 

What you Need for Iterative Deployment

Assuming a company decides to roll out their PLM using an Agile deployment methodology, the question needs to be asked, how easy is it to deploy the software, and does a deployment wipe out former customizations to the environment? Many traditional systems simply overwrite themselves every time a customization is made since the entire environment needs to be redeployed. Not only does this discourage the release of an MVP, but it forces changes to be “lumped” into service packs that are deployed as infrequently as possible. 

The Aras platform is different in that it is built for change. Customizations are easy to make, the platform is flexible and robust, and the client machines never need updating. A change cycle, or “Sprint” in Aras involves a basic Export, Test, and Import to the production environment without reinstalling any underlying software. In other words, there is no “redeployment” required.

One of Aras’ key differentiators is that upgrades to the latest software are included as part of the subscription. This ensures that customizations will not be wiped out as the platform moves to another version. Many PLM systems require massive internal effort around upgrade planning, execution, and data reassurance which makes all of the technical team unavailable to focus on continuous improvement. With Aras the Agile deployment team is free to build and deploy whatever the business needs on a platform designed to grow and scale without concerns of upcoming upgrades. 

Plays Well With Others

Another core requirement for iterative deployment is the ability to quickly and easily integrate with the incumbent data tools inside of the functional IT ecosystem. When a company plans to change those tools, a system with an open and transparent API will enable sustainable digital transformation without disrupting crucial functionality. Aras has openness and flexibility at our core, and we are very well regarded for working with other systems through Data Federation, on top of our open API, in order to complement, extend, and replace existing systems.

In Conclusion

To use an analogy, the waterfall method is like following a recipe and serving a meal without tasting it along the way. That might work at a restaurant with consistent, repeatable recipes but the average person will taste the pasta to see if it is done, add pepper to taste, and make decisions about the process that will change the outcome of a meal according to their best decisions in the moment.
  And finally, what good would it be to make a recipe only once?  Using the agile approach home chefs everywhere can learn from what worked and what didn’t, incorporate additional ingredients, alter the proportions, and eventually make the meal taste better each time with less effort. The next time you try a new recipe consider that you are working from lessons learned on a “previous sprint” to continually improve your dish and come one step closer to culinary perfection.