Waterfall vs Agile for PLM Implementations – do’s and don’ts

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?


Original Publication by:

Momentum PLM and written by Lionel Grealou


Share this:

A profile picture for Lionel Grealou

Lionel Grealou

17th September

Insight Featured

Latest Jobs

Architect, Windchill PLM

West Chester, PA, USA Competitive Permanent

Posted on behalf of

Johnson & Johnson

About the job Job DescriptionJohnson & Johnson Technology (JJT), the Enterprise Technology group supporting all business functions under Johnson & Johnson is currently recruiting for an Architect,...

PLM Analyst

Manhattan Beach, CA, USA Competitive Permanent

Posted on behalf of

Fisker

About the job Description: Company Overview Fisker Inc. is a design led pioneering mobility technology company researching, developing and producing next generation electrically power...

Application Consultant - Data Management Solutions

Quakertown, PA, USA Competitive Permanent

Posted on behalf of

Synergis Engineering Design Solutions

About the job Synergis Technologies, the region’s leader in data management, engineering, architectural, civil and manufacturing design solutions is searching for an engineering professional who is...

Looking for people to join your team?

Advertise your role with Momentum PLM. Get Started 

Looking to become a contributor?

Submit an article to Momentum PLM.  Get Involved 

Our Contributors

See the minds behind Momentum PLM.  Learn More 

Meet the Vendors

Read up on the latest vendor updates  Learn More 

Get the latest PLM updates in your inbox

Subscribe to our newsletter

Email Address

*

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

By submitting your email address and any other personal information on the website, you consent to it being collected, held, used and disclosed in accordance with our Privacy Policy.

*