A framework for defining control project requirements
02 December 2014
Ryan Hildebrandt, a self-employed UK-based controls engineer and project manager considers a six-point framework for defining requirements for a controls project helps save time and effort, while ensuring the project stays on track. He argues the importance of understanding control project requirements, tie them to business goals, and stay true to the design to improve project success.
Building a control system demands the complete understanding of the complex process and clear definitions of each project requirement. To streamline the process, it would be helpful for system integrators and plant managers to have a framework for defining project requirements.
A six-point framework can help to define controls project requirements and keep things on track. As part of my university degree, professors would assign projects for each course –projects presumably designed to prepare students for the real world. Projects were simple then… generally, they were days or weeks in duration, but certainly not years. Always well-defined, there was never any doubt about what had to be built.
In the real-world, however, building real projects for customers meant that each project was unique. As a system integrator, you are the expert. As a project engineer, plant manager, or the like, you are responsible for the factory. Building a control system for a complex process (of which there are few others like it in the world, and certainly none with your unique business needs) is no small feat. So how do you bring order to the chaos? How do you uncover the problem behind the problem?
As an integrator, I have worked on many different projects. Lots of disparate projects have meant many experiences analysing what went wrong, what went right, and what questions could have been asked at the start to ensure the problem was better defined. So how do you uncover the unstated problem?
I have created a framework to define requirements that streamline the process. My hope is that newcomers to the integration field will find this framework useful, and that seasoned pros will find it refreshing. If nothing else, it is another way to uncover requirements that will free up mental energy.
First, let's discuss what I mean by requirements. I have found it helpful to extend the traditional definition (‘the things that are needed’) to include additional information—namely, features or objectives that may be required, and features or objectives that definitely will not be required. Clarifying these other two elements leaves room for future design, but also introduces leeway for the designers to constrain how the system works to make the entire project less expensive and minimise risk. Let’s look at some examples.
1. Defining the immediate need – Start with the intent of the project. What is the driving force? Why does this project exist? If a new production line is required, the goal could be to increase capacity, to create a new product entirely, to provide flexibility over existing systems, and so forth. If an upgrade is needed, the intent may be to keep the functionality the same to save time retraining operations staff, or it could also be to fix nagging issues that were present before. Start with the basics here, and add as needed.
2. Defining things that may be required – This is not so much your nice-to-haves, but rather the requirements that depend on future design decisions (or future initiatives). Does your system have one case packer but a second one could possibly be added later (either as part of this project, or the next one in a few years)? This tells the designers to think about how the software could work in the future, and if there are any low-cost ways to prepare for this now. Do you need to enhance reporting and analytics capability? It may make sense for parts of this ‘future’ functionality to be designed and validated while the original project team is still in place, rather than trying to find ways to add it in later. Anything defined here ultimately could make your project more expensive in the short term, but if any of these requirements come to fruition later and the infrastructure is already somewhat in place, the long-term cost of the project goes down.
3. Defining things definitely not required – This can be either functionality not needed or deliverables not needed (because you already have these deliverables done, you will do them yourself, or you do not need them at all). Does the operator definitely not need control over a given operation (or have some devices that need to be manually operated)? Anything defined here ultimately reduces the up-front cost of the project. It is important to be relatively certain about this list. If anything defined here is later determined to be a necessity, the costs to add them could be significantly higher than to include them at the outset.
So how do you determine what is required, may be required, and is not required at all? It is helpful to have a framework for this too, so to uncover these requirements, I recommend thinking about similar systems. These could be similar systems in the same factory or elsewhere, but it is important to consider more than just the software delivered and to think about how the whole process will be conducted.
4. Looking at similar systems – Unless the entire plant (and business) is being built from scratch, there will be templates available to give an idea of what you need in your new production line. Unless the other line was installed recently, there are always lessons learned that can be applied to your project. What works there? What does not work? What features are used often and could be optimised? Which features are never used? How much of the other system can be reused, and what should not be reused.
5. Thinking about more than just software – Most integrators can provide much more than software, but what does the project need? Drawings, software licenses, server setup, and electrical cabinets are all needed eventually. Sometimes the factory can create these in-house, but sometimes factory support staff simply do not have the time or expertise for this design work. For integrators, these ‘extras’ can be effective ways to add value to the project. For plant managers, these value-adds contribute massively to project success rates.
6. The importance of timing – There is a world of difference (cost-wise) to an entire production line commissioned in one night and a production line commissioned over the course of two years. At one extreme, tons of excess staff (not only integration staff, but also electricians, mechanical support, operations, etc.) need to be on hand to ensure everything starts up as fast as possible, and this always means people will be standing around just in case they're needed – essentially unused resources that add cost but little value if the project is planned and executed correctly. At the other extreme, very spread out commissioning time frames mean staff have to be ramped in and out constantly (since they cannot work full-time on one project), and any smart integrator will have more staff on the project than really necessary as a contingency in case someone is sick, is needed for another project, and so forth. Timing changes everything. What about your project? Do you anticipate a slow rollout of features over time, a start-up of a brand new line over the course of a few weeks, or is this an upgrade with a tight timeline?
Whatever you decide, understanding your requirements, tying them with your business goals, and staying true to your design will ultimately drive success for you and your organization.
Most Viewed Articles...