How to Manage Change in Automation Project Scope

Feb. 17, 2015
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.

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.

Sponsored Recommendations

Wireless Data Acquisition System Case Studies

Wireless data acquisition systems are vital elements of connected factories, collecting data that allows operators to remotely access and visualize equipment and process information...

Strategizing for sustainable success in material handling and packaging

Download our visual factory brochure to explore how, together, we can fully optimize your industrial operations for ongoing success in material handling and packaging. As your...

A closer look at modern design considerations for food and beverage

With new and changing safety and hygiene regulations at top of mind, its easy to understand how other crucial aspects of machine design can get pushed aside. Our whitepaper explores...

Fueling the Future of Commercial EV Charging Infrastructure

Miguel Gudino, an Associate Application Engineer at RS, addresses various EV charging challenges and opportunities, ranging from charging station design strategies to the advanced...