Using a framework to define controls project requirements
This 6-point framework for defining requirements for a controls project helps save time and effort while ensuring the project stays on track. Understand control project requirements, tie them to business goals, and stay true to your 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 extremely helpful for system integrators and plant managers to have a framework for defining project requirements. Below see a 6-point framework to help 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. Design a bridge to hold a given load. Build a circuit. Write a piece of software. Solve for X. It was much like childhood days-assemble these Lego pieces to form a pirate ship. Projects were simple then. Generally, they were days or weeks in duration, but certainly not years. Everything was well-defined and there was never any doubt about what had to be built.
Entering the real world was truly a rude awakening. Building real projects for real customers meant each project was unique. No rubric. No grading sheet. No instructions. Only a vaguely defined issue where it's your job to find out exactly what the problem is. Each project presents the opportunity to either impress the client beyond its wildest dreams or become the client's nightmare. This depends, of course, on whether the right thing ends up getting built in the first place. A brilliant solution to the wrong problem is ultimately a terrible solution.
As a system integrator, you're the expert. As a project engineer, plant manager, or the like, you're 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've worked on many different projects for global clients of all sizes. Lots of disparate projects have meant many experiences analyzing 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?
A new framework below defines 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've found it helpful to extend the traditional definition ("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 minimize risk. Let's look at some examples.
1. Defining the immediate need
Start with the intent of the project. What's 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 don't 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's 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, for that matter) is being built from scratch, there are templates you can look at to get 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 doesn't work? What features are used often and could be optimized? Which features are never used? How much of the other system can be reused, and what shouldn't be reused (because it is broken, doesn't apply, etc.)?
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 don't 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's a world of difference (cost-wise) to an entire production line commissioned in one night and a production line commissioned over the course of 2 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 can't 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.
A concise requirements checklist that dives into the specific questions to ask to uncover requirements is available below along with other exclusive tools and systems.
Ryan Hildebrandt is a self-employed controls engineer and project manager based in the United Kingdom; he creates useful tools and guides for other control engineers. Edited by Joy Chang, digital project manager, Control Engineering, firstname.lastname@example.org
- Defining project requirements is a crucial step for building a control system.
- "Requirements" mean more than just the "things that are needed," as defined traditionally.
- This 6-point framework for defining requirements for a controls project helps save time and effort, while ensuring the project stays on track.
Could a fresh look at project management help your next controls, automation, or instrumentation project?
This online version of a December issue article has a link to a concise requirements checklist that dives into the specific questions to ask to uncover requirements along with other tools and systems.