Over the last few years, MES (manufacturing execution system) packages have appeared that provide the database framework and programming interfaces to collect, process and provide standardized information links between the production floor below and the ERP (enterprise resource planning) business system above. Even so called “configurable” packages usually require extensive custom coding since the built-in functional capabilities are usually insufficient to handle all but the simplest manufacturing processes and integration to current installed information systems. The reality is that MES installation projects are just as much about custom software development as they are about installation and configuration.
Traditional project management methods would require a very detailed project scope with exact details of the current system and proposed solution. It would be followed by functional and design specification documents that would provide additional details of the solution. Once all the proper documents have been developed and agreed upon by the integrator and customer, work would finally start on the actual code development.
As you can imagine, there is a lot of work that needs to be completed before a single line of actual code will be developed. Not only is there lots of work, there are assumptions that are always made at the outset, but invariably prove false and change during the project. The first assumption is that all of the information about the current system and proposed solution is complete. The second assumption is that the current system will remain the same throughout the project. If you begin the project with a rigid mindset that these assumptions are absolute, you will be doomed from the start. Projects that do not allow for some flexibility fail in virtually every case.
In conventional product software projects, there has been a growing movement away from waterfall- or cascade-type methodologies that begin by drawing up very detailed requirement and design documents before any coding is done. The problem with this approach is that much of that planning ends up being put aside, so the time spent compiling it was wasted. That is why many large companies and software development firms have moved more in the direction of “agile manifesto” based methodologies which focus on the immediate generation of finished code, with less documentation and built-in flexibility.
With the understanding and trust of the customer, the more flexible and responsive elements of agile software development methodologies can be used to manage the development of most MES projects. Documentation mandated by the waterfall methodology and in many cases still required by the customer is not eliminated, but becomes more dynamic.
The most common of all the agile methods is scrum (borrowing a term from rugby). In the beginning of a scrum-based project, the list of functionality is loosely defined by the project statement and limited discovery phase. Over the course of the project, additional functionality, problems with existing code, enhancements, and so on, are added to the functional backlog. In the scrum method, the coding process is broken into smaller iterations called sprints, usually lasting a week or two. The determination of which work will be completed in each sprint is based on both priority and the ability to write the code completely and test it in that iteration. Once all the work has been selected for that sprint, the sprint will start. During the sprint, the daily activity of the development team is tracked during a daily meeting of the team and product owner. The purpose is to determine what has been done, what will be done, and if there are any impediments to progress. This process will be repeated over and over until the project is completed.
The major benefit of this process is flexibility. The combination of these small iterations of development and the dynamic functional backlog is what gives the scrum method of software development its built-in flexibility.
As you can tell by now, the design and implementation of an MES system is not easy. It can almost be doomed to fail before it is started if not managed correctly. It is also important to point out that every project is different and will require more focus on certain aspects of the project management process and less on others. In order to manage projects effectively that will be more software developmental in nature, we must first determine what type of development environment is the most appropriate: the traditional waterfall method, flexible agile method, or most likely, somewhere in the middle.
The process of choosing the appropriate category for each project is just as important as the overall management of the project. For example, if there is a customer requirement to track and document all project changes and steps, then strict waterfall would be a good approach. On the other hand, if a customer is rather vague in functional requirements and requires less documentation, then it may make more sense to develop a good working prototype and work from that point, with maximum flexibility in mind. The majority of projects will likely be somewhere in the middle.
With the middle in mind, we have once again gone a step further and created four separate categories of project types. The four different categories are as follows:
3. Agile/waterfall, and
4. Pure agile
Each of these categories has different project management documentation, level of customer interaction, deliverable schedules, etc. Once we determine the category that will best fit the proposed project, we will follow the project outline within that category and start to put together the actual project plan, project support documents, implementation plan, and so on. The right choice is the first step to a successful project.