Implementing business change powered by enterprise platforms is a journey of discovery and continuous improvement, directly linked to business maturity and priorities. This includes process re-engineering coupled with the deployment of PLM, ERP, MES, CRM and other IT platforms or integrations. Choosing between waterfall and agile delivery principles is always required when implementing tools and technologies that rely on software development, customization and interface deployment. Agile principles can be broken down into different sub-methodologies, from Kanban to Scrum, Extreme Programming, Lean Software Development, etc.—this post is neither about discussing these in detail, nor suggesting which one to favor in the context of PLM implementations.
In this post, we discuss how to choose between waterfall and agile project delivery approaches when implementing product lifecycle management (PLM) solutions, and what opportunities and threats these two approaches may offer based on the context.
There is nothing wrong with waterfall
Waterfall delivery principles reflect a more traditional approach; nevertheless, there is nothing wrong with this methodology and its principles are still valid. Typically, projects are broken down into phases based on scope and complexity (also cost, timeframe, commercial considerations, resource availability, etc.); each project phase can follow its own waterfall work breakdown structure: from initiate, design, build, test, validate, deploy to close following a handover period.
This approach requires robust planning and assumes that all necessary steps can be delivered sequentially in a given timeframe. Nevertheless, different activities can start in parallel: e.g. build activities can start early as they do not have to wait for the design to complete, though obviously the design must be completed and signed-off early enough prior to completing the build (stating the obvious). This assumes that the overlap between design and build activities is reasonably smaller than either activities—to avoid finding too late in the build that the design is inaccurate or incomplete. These principles assume that one step feeds the next one; deliverables must be sufficiently detailed to be signed-off, they become then subject to change control as the waterfall project advances.
Agile brings visibility and user-centricity
Agile applies naturally to software development, and equally to project management. It assumes that things are delivered iteratively in cycles (a.k.a. sprints); it differs in terms of engagement with customers / end-users. Greater collaboration requires more visibility and flexibility in prioritizing which requirements, storyboards or use cases get implemented first.
With greater collaboration, agile methodologies can hypothetically contribute to solutions that are more fit-for-purpose, using less formality, with less reliance on detailed planning and strict change control. Agile delivery relies on user stories to govern how much can be done in a given period or sprint. These user stories link to storyboards and use cases; they must deliver value by themselves and be continuously assessed in context of a robust acceptance criteria.
Cohn (2004) referred to the acronym INVEST to assess the viability of a user story in terms of being Independent, Negotiable, Valuable, Estimatable, Small, and Testable. Even if this speaks common sense, writing effective use cases and user stories requires levels of business process and PLM implementation experience. They typically follow a simple template which can be scripted as such:
As a (role) I can (capability), so that (receive benefit).
At a detailed level, it is also important to decompose them in user-centric function-based analysis to account for each basic CRUD data operations (Create, Read, Update and Delete), as often “the devil is in the detail”—and even more so with PLM.
Waterfall vs agile: a difficult choice for PLM?
Choosing between waterfall and agile methodologies for PLM requires a holistic understanding of a) the extended change (scope), b) the organizational context (operating culture and ability to adapt), and c) the ability of the implementation team to deliver (experience, credibility, trusted and trusting partner).
The following table illustrates opportunities and threats when choosing between waterfall and agile for PLM projects (non-exhaustive list).
| Approach | Opportunities | Threats | PLM context |
| Waterfall | Works well when detailed scope is understood early.Requires robust planning to reduce external risks.Must be based on clear commercial terms: e.g. fixed price contract with successive milestone-based payments. | Requires robust discovery activities to validate early all necessary assumptions.Required intense business involvement towards milestone sign-off.Lack of flexibility can increase the risk of failure. | Typically preferred for very technical projects, with containable business change (assuming robust initial discoveries).Recommended for fixed-price supplier contracts with prime system integrator. |
| Agile | Works well when flexibility is required, and when requirements are not clear.Welcomes changes based on iterative findings and acceptance.Assumes all delivery elements can be simplified into INVEST-able user stories.Allows for partial solution element roll-out. | Extended collaboration can become a burden as ‘blue sky thinking’ might blur strategic priorities.Solution might significantly deviate from the initial mandate or delivery timeframe.Contracting implementation partners might be commercially tricky without firm scope or deliverable timeframe. | Typically preferred when significant business process change or adaptation is expected.Recommended for time and material supplier contracts, especially if multiple vendors and suppliers are engaged. |
Delivery, engagement and commercial frameworks are always closely linked. Often, one of the same criteria is applied when choosing the relevant delivery methodology and the implementation supplier that comes with it, or brings more credibility in making it fit in the project context.
In the next part of this two-part post series, we will elaborate on the do’s and don’ts of waterfall vs agile approaches when delivering PLM solutions; is it advisable to take a hybrid approach, or change from one to the other approach? And what might be the implications with cloud and SaaS adoption?
Reference:
- Cohn M. (2004) User Stories Applied: For Agile Software Development, Addison-Wesley Professional.
This post was originally published on Momentum-PLM on 16 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
