How to Manage Change in Automation Project Scope

Changes in project scope are inevitable in most manufacturing execution system deployments. Here's how to get a grip on every automation project manager's nightmare.

Luigi De Bernardini, CEO of Autoware
Luigi De Bernardini, CEO of Autoware

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 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.

When you organize a project in this manner, the release of each sprint is a point of reflection and review. The client acquires a part of the overall functionality originally required and begins to use it right away within their organizational structure. As a natural consequence of this, he then acquires experience and develops information that leads to a reconsideration of the project specifications. Each sprint is followed by a period of discussion and critical re-evaluation of the initial specifications. These can be confirmed, amended for sprints yet to be implemented on the basis of experience or changed operating conditions, or modified for the sprint already released.

When changes relate to components already developed or even released, they must be handled using a traditional approach from a technical and economic point of view.

In the case where the requirements are modified for sprints not yet developed, an assessment is made of the changes’ impact on the system configuration, risk and necessary effort for development. The scope change is obviously tracked and managed on the quality control side, but often does not require an adjustment to the economic project cost since the necessary activity is simply an alternative to the expected one.

Immediately following this reflection phase, we proceed to develop the functional specifications of the next sprint, adapted to the updated requirements. This element of flexibility keeps the requirements always adhering to the end user's current needs as they evolve, minimizing the effect of changes on both the technical and financial management of the project.

Based on my personal experience, there have been dramatic differences in terms of technical/financial results between projects managed with this methodology vesus those managed using the traditional waterfall method.

Projects managed with agile methodology tend to evolve naturally and within a process of continuous improvement. Conversely, those managed using a monolithic/waterfall method often faced a period of stagnation at the end, where the relationship between the client and the system integrator became tense and required a rebuilding of mutual confidence.

As stated in my first agile post, the main purpose of an MES/MOM is to support business processes that support operations, bridging the gap between production and strategic management—which are different from company to company and highly variable depending on the need of the company itself to adapt to market evolution.

Only a project management approach that ensures both the flexibility to support the intrinsic variability of client requirements and the mutual economic protection of the parties involved can virtually guarantee the success of these kinds of projects. I personally believe that the unconventional agile approach is the only method able to do this for most projects.

Luigi De Bernardini is chief executive officer at Autoware, a Certified Control System Integrators Association member based in Vicenza, Italy. For more information about Autoware, visit the Autoware profile on the Industrial Automation Exchange.

More in OEE