Successful MES or MOM implementations require a more nimble project management style than traditional project management. Managing in “sprints” is more effective for these long-term, high-risk projects.
By Luigi De Bernardini
Although recent years have seen a gradual proliferation of configurable products to create manufacturing execution systems (MES) or manufacturing operations management (MOM), a project based on these products always requires a significant amount of design and customization. This is because the main purpose of such a system is to support the business processes on which operations are based, bridging the gap between production and strategic management. Those processes are different from company to company and highly variable because of the company’s needs to adapt itself to evolving market demands.
An MES or MOM project typically takes a considerable length of time to implement, with significant costs and a high inherent risk, since it impacts operations and production capacity, especially during the implementation phase while users are learning to use the new system. Mitigating the risk and economic impact of these projects requires careful attention to project management and a well-defined process of software development lifecycle management (SDLC).
The agile approach promotes synergy between users and developers, who maintain a much closer relationship. This allows users to more easily evaluate any changes during the lifecycle of the project.
However, traditional approaches to project management can’t fully address the management of MES and MOM projects because of their variability. Rarely have I seen projects end with the same user requirements defined in the initial phase. Production operations and organizations often change several times during the implementation of the project.
To understand how traditional project management is not adequate to MES/MOM implementations, consider the steps invovled in a typical, monolithic project management process:
• General Specification
• User Requirement Specification (URS)
• Functional Requirements Specification (FRS)
• Detailed Design Specification (DDS)
• Build System
Between drafting the initial specifications and the time when the client starts to use what has been made, some time passes. This implies that any possible error of assessment in the initial stages has a heavy impact when it is detected—since it can affect a large number of features, as well as common components such as the structure of the database on which the system is based.
I often see that the user is unprepared to assess the impact that the adoption of an MES system will have on its organizational arrangements, therefore they thend to define the user requirements based on past experience. The simple adoption of the system, however, will lead to changes in the organization and the ranking of priorities. Features that were deemed indispensable lose importance and others that were not even considered become highly desirable.
Another approach to the management of the MES/MOM implementation project is the “agile” one. In this case the system is developed and implemented in small “sprints.” The agile approach promotes synergy between users and developers, who maintain a much closer relationship. This allows the user to more easily evaluate any changes during the lifecycle of the project. More importantly, the user begins to benefit from the system much quicker and this allows him not only to benefit and anticipate the return on investment, but to get used to the system more gradually and implement the organizational and procedural adjustments induced by the system. These organizational adjustments can be more easily considered in the “sprints”, thereby minimizing the impact on the cost and duration of the project.
The agile approach has some limitations, too. Its fragmentation can lead an organization to proceed without a clear vision of the objectives of the project, losing organic vision of what is made. Based on my experience, the best approach is an agile, non-standard approach, in which the first two phases of the SDLC traditional (General Specification and User Requirements Specifications) are preserved, followed by the implementation phase conducted in sprints.
This ensures that the project is addressed with an overall view of objectives, needs and expectations of the user that can provide a guideline throughout the implementation phase. In particular we organize the User Requirements Specifications into chapters corresponding to the modules, organized on the basis of shared priorities with the client that then will be realized through specific sprints. Each chapter contains the “as-is” processes mapping, the “to-be” mapping, and the description of the functional specification to achieve.
This allows the beginning of each sprint process to include an analysis of the URS specific to the sprint, considering if what has been achieved up to that point have affected the requirements in any way that would require some adaptation. Only then do we proceed to the drafting of functional specifications of the module along with the realization phases, test and implementation.
This approach has certainly positively influenced the projects where we’ve seen it adopted. It has allowed us to tackle the project with the proper overview, while mitigating the risk and impact related to changes emerging during construction. Statistically this has led to more timely projects, to a greater client engagement and ultimately to their greater satisfaction with the system. Ultimately, this kind of project improves the climate of mutual trust between system integrator and client, by creating a more flexible and relaxed collaborative environment.
About the Author
Luigi De Bernardini is chief executive officer at Autoware, a Certified Control System Integrators Association member based in Vicenza, Italy.
Powered by Facebook Comments