- Home
- /News Autoware
- /Solutions
- /Automation
- /Agile Project – How to Manage Change in Automation Project Scope

Agile Project – How to Manage Change in Automation Project Scope
Third (and last) installment on how the less conventional agile approach, and answer to reader’s questions on how to change project scope during and Agile Project. Luigi de Bernardini’s new blog on Automation World
This column is the third (and last) installment on how the less conventional agile approach can be crucial to manufacturing execution system (MES)/manufacturing operations management (MOM) project success for the end user and the system integrator. As I pointed out last month, when I wrote the first post on this topic, I did not expect to generate so much interest. Several commenters requested explanations and insights on how to create a cost estimate of projects that use this approach. Others wanted to know how you can manage the inevitable changes of scope that may occur during the various sprints. Last month I addressed the subject of how a cost estimate can be made. This month, I’ll explore the second point—management of change in project scope.
Changes in automation project scope are every project manager’s nightmare. They are bound to occur, but can easily lead—depending on how they are managed—to a radical reduction in margins or a compromised relationship with the client. Both cases are obviously harmful and show how important it is to carefully manage any changes in project scope. In the case of an MES project, the situation is even more complicated because the project involves the organization of production procedures that are constantly evolving. If you tackle a project of this kind in a monolithic way, meaning that you apply classic waterfall project management, you run the risk of either having to manage a large number of variants in development or reaching the end of the project with a system that no longer meets the user’s needs.
In this context, using the atypical agile approach provides a major advantage because development takes place in a progressive manner—sprint by sprint—within a context analyzed globally in the initial stage so as to ensure a coherent framework.
See more on the Automation World web site.