Both waterfall and agile are recognized delivery methodologies, which have their relevance when implementing PLM solutions. Choosing one or the other approach requires an understanding of a) the extended change, b) the organizational context, and c) the ability of the implementation team to deliver. In part 1, we discussed high-level opportunities and threats of each approach and key considerations when selecting and using these methodologies to implement PLM-related business change.
In part 2, we elaborate on the Do’s and Don’ts of waterfall vs agile approaches when delivering PLM solutions; we also discuss whether it is advisable to combine the two in a hybrid approach, or change from one to the other mid-way through an implementation project; also, it is interesting to note potential implications related to cloud and SaaS adoption.
PLM implementation methodologies: choose one
When applied to PLM implementations, waterfall delivery principles can help manage how the solution is sequentially developed, using robust planning and change control mechanisms, reducing scope creep and containing costs. This approach is relevant when working with suppliers delivering fixed-price projects on projects that require minimal customization or integration—assuming robust contractual terms and relevant supplier delivery experience.
Contrastingly, agile delivery principles allow for increased flexibility, more robust fact-finding, ongoing iterative adjustments and more “room for interaction”. PLM software is typically provided as part of a vanilla install-base, in bundled packages, on premise or in the cloud, with possible configuration, customization and integration capabilities. By nature, such implementation differs from full stack software development. It is essential to understand however what scope and project phase would benefit from more agility, how this would fit in the overall roadmap, while maintaining clear lines of responsibilities and robust stakeholder rules of engagement to maximize speed-to-value.
Waterfall vs agile: do’s and don’ts
PLM typically brings business requirement related challenges, couples with technical and business alignment challenges. The following table illustrates a number of recommendation points when selecting either waterfall or agile delivery methodologies, in context of PLM implementations.
| Approach | Do’s | Don’ts |
| Waterfall | 1. Create a robust plan and manage it tightly. 2. Allow for enough “discovery” time at the beginning of each phase. 3. Continuously mitigate risks and manage both technical and commercial assumptions. 4. Have a robust delivery framework and rigorously document decisions and deviations. 5. Maintain ongoing robust business governance. 6. Use change requests as a review mechanism of deviations—even if they have no delivery or commercial implications. | 1. Don’t jump over one delivery step, as they are sequential and must be treated as such when seeking business acceptance. 2. Don’t assume that the plan will never change (even if robust), or that business value will be realized independently. 3. Don’t refer to contractual terms each time something does not seem quite right. 4. Don’t implement solution elements which deviate from the initial intent or PLM tool ‘best practice’, without formal change acceptance. 5. Don’t use a very convoluted change process. |
| Agile | 1. Be open to new ideas and requirements. 2. Focus on breaking down use cases in manageable user stories per sprint. 3. Over-communicate about business change and support required. 4. Build strong business relationships. 5. Manage ‘long lead’ item dependencies with extra care. 6. Focus on business value delivery and tracking. 7. Align all delivery parties to follow the same methodology. | 1. Don’t assume that there is an infinite number of sprint available; don’t assume that content will simply get descoped from the back log not prioritized in a given timeframe. 2. Don’t loosely manage scope change. 3. Don’t assume Kanban is sufficient in delivering agile projects. 4. Don’t assume that using time-boxed iterations means it is “agile” and there no planning is required. 5. Don’t simply assume that agile is better because there are “IT deliverables”. |
Sometimes, implementation partners try to invent new delivery models to align with project findings over time:
- On the one hand, “wagile” methodologies were created to transition from agile into series of “waterfall iterations”.
- On the other hand, waterfall PLM projects sometimes convert to agile when suppliers face waterfall delivery issues; it can also link to poor planning abilities or failure to identify early technical difficulties on their part (e.g. due to poorly delivered data or process discoveries forcing the plan, when there is one, to continuously slip to the right).
There is nothing wrong in changing the delivery approach when things go wrong, when adjusting to recent findings or contextual changes. However, changing the delivery framework might also have commercial, scope, cost or timing implications; such change must therefore be implemented with caution, only when confirming that all involved parties proactively align on the new way-forward and express their respective commitment to make it happen. In any cases, this must be handled as part of a formal project change request.
Cloud and SaaS implications, if any?
Technically speaking, agile methodologies align with cloud: they are flexible and easily accessible—at least, that the theory as things might get more complex with looking into personalization and adaptation. Products and services are becoming more personalizable, why not PLM platforms then? There are no obvious reasons to favor waterfall vs agile for cloud-hosted or even SaaS PLM solution implementations: both approaches remain valid per opportunities and threats discussed in part 1 of this post. The question perhaps remains opened in context of multi-tenant SaaS solutions which assume limited implementation time required; they are still likely to require iterative learning and data migration (if any) as capabilities are added or removed.
What are your thoughts?
This post was originally published on Momentum-PLM on 17 September 2020.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
