Every year, the Ignition Community Conference (ICC) brings together Ignition experts to share practical knowledge, explore innovative applications, and discuss emerging technologies. Just as importantly, ICC gives integrators an opportunity to share lessons learned and reflect on the development and project management practices that help automation projects succeed.
At this year’s conference, DMC’s Elizabeth Reed, Director of SCADA and MES, joined Cassy Gardner of E Tech Group and Ryan Crownover of Vertech for the CSIA panel “Avoiding Million-Dollar Mistakes in Automation Projects.” Drawing from real-world integration experience, the panelists discussed common project failure points and the practices teams can use to identify risks before they become expensive problems.
The discussion covered everything from defining the right business outcomes and engaging key stakeholders to selecting a project management approach and planning for a system’s long-term lifecycle. Here are some of the key takeaways.
1. Defining Success Before Choosing the Solution
A technically successful project is not necessarily a successful project. There are plenty of examples of systems that met documented requirements but ultimately failed to deliver the value users expected because the requirements were not aligned with the project’s business objectives.
Before defining features or selecting technologies, teams should align on the problem they are trying to solve and what a successful outcome looks like. That might mean increasing production, improving access to operational data, reducing downtime, or meeting an aggressive schedule. Establishing that “North Star” gives engineers and project stakeholders a framework for making technical decisions and prioritizing requirements throughout the project.
“One of the earliest red flags in the design phase is a disconnect between the technical requirements and the business justification. Engineers can get excited about the technical solution, but ultimately, project success needs to tie back to business value.”
– Elizabeth Reed
The same principle applies to individual requirements. Rather than defining exactly how a feature should work, requirements should capture the intent and desired outcome whenever possible. This leaves integrators room to identify the best technical solution while keeping development tied to the original business need.
2. Getting the Right Stakeholders Involved Early
Even well-defined requirements can fall short if the right people are not involved in creating them. One of the panel’s examples involved a project that reached a 90% FAT review before the integration team learned about Jo, a longtime employee at the client’s facility who understood its operations and how users actually needed the system to work. Had Jo been involved earlier, much of the system could have been designed differently.
The lesson is simple: find your “Jo” early. Involve the operators and subject matter experts who understand the day-to-day process, along with stakeholders from engineering, operations, IT, and other impacted groups. Their input can uncover requirements and constraints before they turn into expensive changes later in development.
3. Picking the Right Project Management Approach
One of the most important decisions at the start of an Ignition project is choosing the right project management approach. Both Agile and Waterfall have their place, and the panel discussion uncovered that the right choice typically depends on the nature of the project, the level of uncertainty involved, and how prepared the customer is to participate in the development process.
Waterfall works well when requirements are clear, and the work follows a predictable sequence. If completing one step is unlikely to change how you approach the next, a structured, sequential plan can be effective. This is often the case for traditional PLC and controls work.
Agile, on the other hand, is useful when what you learn during development may change what you build next. For software-heavy Ignition applications, iterative development allows teams to prioritize functionality, gather feedback, and adjust as they go. However, Agile requires active customer participation and a long-term roadmap to avoid development decisions that create problems later.
“Ignition is built on top of the control layer, where PLC projects often follow a Waterfall approach because of the nature of the work. We use Agile a lot at DMC, but it isn’t the right fit for every customer or every project. It’s important to consider the specific application, what you’re trying to accomplish, and whether Agile or Waterfall is the better approach.”
– Elizabeth Reed
4. Plan for the Future, Even When Working Iteratively
Agile development does not mean developing without a plan. Even when functionality is built incrementally, the panelists emphasized the importance of understanding the long-term roadmap. Otherwise, an early decision about one feature can make a future feature significantly more difficult or expensive to implement.
Think of the roadmap as a picture of where the system is headed rather than a rigid specification. The details can change as requirements evolve, but communicating future goals gives developers the context they need to make architectural decisions that support future growth and minimize rework.
That long-term thinking is particularly important with Ignition because the platform makes it possible to build a wide variety of custom applications. The fact that something can be built in Ignition does not necessarily mean it should be. Consider complexity, maintainability, risk, and total cost of ownership rather than focusing only on whether a particular implementation is technically possible.
5. Involve a System Integrator Before Decisions Become Expensive
Many automation decisions become more expensive to change as a project progresses. The CSIA panelists shared examples ranging from usable infrastructure being removed before an automation plan was established to technology decisions that constrained what customers could economically implement later.
“We often see customers build proofs of concept or even production deployments before bringing in an integration partner to help scale the system. By that point, there can already be technical debt that adds to the total cost of ownership. Involving a system integrator early can help establish a solid foundation and avoid those costs down the road.”
– Elizabeth Reed
Involving an experienced system integrator early gives clients an opportunity to evaluate requirements, architecture, technology choices, and risks before those decisions become costly to reverse. Front-end engineering and design, or FEED, studies can also help teams document requirements, understand stakeholders and business outcomes, compare technical options, and establish a clearer plan before implementation begins.
Conclusion: Million-Dollar Mistakes Usually Start Small
Avoiding costly automation mistakes starts long before development begins. Clearly defining business outcomes, involving the right stakeholders, selecting an appropriate project management approach, and planning for the full system lifecycle can help teams identify risks while they are still inexpensive to address.
As the panel demonstrated, major project overruns are not always the result of one catastrophic decision. They can come from a series of smaller choices that accumulate over the course of a project. Maintaining clear priorities, documenting decisions, and evaluating their budget and lifecycle impacts along the way can help prevent those smaller choices from becoming million-dollar problems.
Have an upcoming Ignition project? DMC can help you start on the right foot.
