
I’ve been developing automation projects, from cradle to grave, for many years now, on lots of different platforms. Some of the platforms have been amazing (Siemens TIA Portal) and some have been… crap (Danfoss +1 Guide), but all of the platforms are lacking one thing… Project Workflow Management
A well defined workflow is the difference between a project that takes 100% of the allocated time and offers zero room for compound improvement, and a project that takes 100% of the projected / estimated time, but leaves plenty of room to reduce that percentage in the future.
By following a structured workflow, many different aspects of the project can be streamlined:
- Design / Wireframing of Project
- Development / Programming
- Testing
- Issue Tracking
- Deployment / Commissioning
- On-going support / issue management
All of this reduces the risk of errors, increases the visibility of issues and drives improvements in efficiency! This is a sliding scale too, the larger the project, the better this performs. The more people involved in development, the more effect Project Workflow Management has on the management of the project.
So where do you start?
My Workflow
Atlassian’s JIRA is the hub of my workflow. For those that don’t know what JIRA is, its essentially a digital Kanban board, with some additional features that enhance quality of use.
📝Note
If you don’t know what a Kanban board is, take a look here: https://www.atlassian.com/agile/kanban
My workflow consists of firstly obtaining the Final Design Spec from my client / team and systematically working through it, creating references in JIRA:

Now if you’re lucky, your FDS will be clear, concise and full of easily referenceable elements for development. The above image shows an example of a Story (a “ticket” that acts as a container for smaller tickets, known as sub-issues). This Story, which is 90% complete, outlines the areas of control that still need developing for the DAF Control.
Looking back at Reference 1 above, JIRA connects me to my development environment, such as TIA Portal. Whilst JIRA is not writing anything for me, or offering any sort of automation of development, it gives me an anchor, a reference, a task to complete
This style of working may not appear like it’s worth it to begin with, when you have to factor in the time spent creating the stories, sub-issues, typing out the titles and references… but… consider the fact that you are reading the FDS anyway. You’re already attempting to retain this information… For a little bit of effort, you can put extremely valuable information about your project in a very easy place to work with.
I promise that the time spent is completely and utterly worth it.
The Workflow
When I approach an automation project, the workflow is the backbone of everything that follows. It all starts with the Final Design Specification (FDS). The FDS is where all of the understanding of the system is located, everything you need to develop the project should be located here. If it’s done right, it’ll break everything down into referenceable elements like interlocks, alarms, and timers.
Trust me, a well-written FDS makes life so much easier because you can work through it systematically instead of guessing what’s next, or having to waste time trying to work out what’s implied or interpreted. If the FDS isn’t clear, you’ll spend a lot of time just figuring out what’s expected, and that’s time better spent actually pushing the project forward.
Once I’ve got the FDS in hand, I’ll start mapping out the workflow in JIRA. This is where I break things down into smaller, manageable tasks. For example, I’ll have a story dedicated to something like “Pump Control,” and under that, sub-issues for programming interlocks, alarms, and other details.
These issues that are created are essentially checkboxes that allow me to keep a high level track of what elements of the project have been completed, or are currently in progress.
This might feel like extra effort at first, but the more organized you are, the smoother the whole project runs. Plus, if you’re working with a team, everyone stays on the same page, which means fewer headaches down the line! Everyone is able to use the same Kanban Board, update the same issues and work towards the projects’ completion.
The workflow really comes into its own during testing and deployment. When every task links back to a specific requirement, testing becomes a straightforward process rather than a last-minute rush. If something goes wrong or a bug has been found, an issue is created, what happened is recorded and the solution is also documented. This structured approach means testing is far more transparent, with any issues captured as they appear. By the time you’re ready to go live, you’ve got confidence that everything has been checked and is working as expected and reliably, with the failed issues to prove your competence and due diligence!
This is the best part though… This structured approach means you’ve got everything documented and organized for future updates or troubleshooting. Whether it’s six months or six years later, you’ll thank yourself for having a clear record of what’s been done and why. For me, that’s one of the biggest benefits of a good workflow, it’s not just about the here and now; it’s about making sure you’re set up for success long after the project is handed over!
📝Note
One thing you really want to consider when you’re planning your automation project is making sure you vouch for time to get through those preparatory tasks. Things like understanding your system, going through the alarm lists, or just reading up on the manuals. A lot of the time, these tasks aren’t included in the project time, and you’re expected to do them on the fly during development. But if you can carve out time for these upfront, it makes everything smoother later on. You’ll avoid trying to figure it all out while you’re deep into development and make the whole process more efficient.
One of the things I really appreciate about using Jira alongside the FDS is that it’s not just about creating issues and marking them as done. I don’t consider the FDS finished with just because I’ve created my issues in Jira, it’s far from finished with!
For me, the issues marked “in progress” or “done,” act as a way to cross-check against the FDS. For example, let’s say I start developing the logic for “Interlock 5”. I’ll search for Interlock 5 in the FDS, read what needs to be done in detail and start developing directly from the FDS. Once I’ve completed the control or interlock, I simply highlight it green in the FDS and then go back to Jira to mark it as complete. I might also add to Jira a small summary of what’s been changed / added, just for documentations sake!
The real power of this method is the implicit link I’m creating between Jira and the FDS. I make sure these two areas never get out of sync. If I see something marked as green in the FDS, I know it should also be marked as completed in Jira. If it’s not, I know there’s a disconnect, and I need to go back and check where things went wrong. This process really helps me stay on top of things and gives me a clear sense of control over the project’s progress.
Internal Linking
Jira has a really good feature that allows the linking of any issue to another issue, with the reason why they’re linked. It’s a simple but powerful feature that helps you keep track of how issues relate to one another.
Jira allows you to create sub-issues only one layer deep. So, you can’t have a story with sub-issues that themselves have sub-issues. This means that if you want to have some dependencies between issues, linking them is really the only way you can get sub-issues to be dependant on another sub-issue being completed first
One thing I leverage a lot in my workflow is making issues relative to each other when they fall under the same Asset. For example, I might have an issue to “P100 – create the pump set and data.” This would be the task where I need to drop in an instance of the function block that controls the asset and create an instance of the user-defined type (UDT) to hold its data. But I’d then have several other sub-issues related to this task, or even blocked by it.
For example, I can’t complete the alarming profile for these pumps until the pump data exists. That sub-issue would be marked as blocked by the creation of the pump and data sets.
Setting this up might take a little extra time, and I wouldn’t recommend it unless it’s necessary. But when you’ve got a team working on a project, it becomes incredibly useful. It helps you visualize what’s dependent on what without having to constantly dig through an FDS, schedules, or unorganized information. Especially if the documentation you’ve been given isn’t neatly formatted. This way of linking issues ensures you’re always clear about where you are and where you need to focus next.
Project Completion Insights
One of the key strengths of Jira, or really any workflow tool, is its ability to provide a visual guide of your progress. Most tools follow an agile approach, where you can track the status of issues as they move through different stages (open, in progress, done etc). You can easily see how many sub-issues are in progress, how many are complete, and what percentage of all subtasks in a story have been finished. This gives you a clear, at-a-glance understanding of how you’re progressing through a particular set of issues or a larger group of tasks.
While management may not always be as concerned with the specific details of software development, focusing more on meeting deadlines, it’s reassuring to know that you have a solid grip on your progress. Especially on long projects that span six to eighteen months, it’s helpful to be able to show that you’ve thoroughly reviewed everything, linked it back to the FDS, and now, as development continues, you’re watching the percentage of completion steadily rise.
This system has many benefits, especially when project managers or team members change during the course of a project. A new manager stepping in or a lead developer leaving midway through? No problem. The next person can pick up right where the previous one left off, with the same insights and structure available in Jira, without needing to dig through piles of documentation or rely on prior knowledge. I’ve been in the position where I had to pick up project work from someone who left, and there was absolutely no guidance on the status of the project, what had been done, or what still needed to be addressed. It can be overwhelming and confusing, but with a structured approach in Jira, that’s something you never have to worry about.
Getting Others Involved
The ability to raise issues directly with management and engage with them in the same platform where all other tasks are being tracked is also a strength of having a structured workflow. If I spot something in the FDS that doesn’t make sense, is unsafe, or I simply have concerns about, I can immediately raise an issue. I use something like a “clarification request” (a custom issue I’ve made), where I’ll point to the specific part of the document, assign it to management, and explain that I need clarification on what this means or what the potential implications are.
I’ll include all the supporting evidence or details that back up my concerns, and then submit it. The best part is, once I submit it, management is automatically notified via email or alert, and they can review the issue and provide a response. This direct line of communication through the platform ensures that nothing slips through the cracks and that concerns are addressed promptly, all while keeping everything centralized and transparent. It’s an incredibly efficient way to manage issues that require upper-level input without having to chase down approvals or feedback through separate communication channels.
Conclusions and Closing Statements
Using a workflow management system like Jira throughout the project is incredibly powerful. At the end of the project, I can look back at all the clarification requests and ensure everything has been closed off. Not only do I have a complete record of the development process, but I also have an auditable trail of all issues raised throughout the project. This includes concerns outside of development that could impact the final product.
What we’re really doing here is documenting as we go, but not in the sense of writing comments or explaining how the system works, but in capturing all the details that the final design spec may not fully address. Things like how interlocks and controls come together or what environments and groupings the issue falls under. By capturing this in Jira, we’re building on the FDS, allowing for smoother development and later phases.
An FDS is great, but once the development phase ends, it stops. With Jira, you keep all those valuable references even after development is complete, whether it’s for commissioning, addressing support requests from clients two years down the line, or recalling decisions made during development. Having that documented makes it so much easier to resolve future issues.
If you’re disciplined enough to record everything (decisions, changes, issues), it’ll make a huge difference in how you manage your workflow and track the progress of your projects. It’s all about creating that structured approach that allows for seamless continuity from development to support, keeping everything organized and accessible.
📝Note
Keep an eye out for more JIRA-related content and best practices coming soon in Engage & Excel. We’ll dive deeper into how to optimize your workflows, manage projects more effectively, and leverage JIRA to its full potential, whether you’re just getting started or looking to fine-tune your approach!
Do these articles help you in any way?
The internet is an excellent platform for sharing, and I’m happy to provide this information. However, sharing this content isn’t “free” on my end. If you feel that information you find here is valuable, please consider making a small donation. Your support truly makes a difference!
Make a one-time donation
Choose an amount
Or enter a custom amount
Your support is appreciated 🙂
DonateGet Involved In Do & Grow

Jumping on to the new Do & Grow platform is simple!
Click the button below to head over to the members page and sign up!
You can easily stop your membership by visiting your dashboard, which is accessible on any course page.
Over time, the menu system will be updated to provide easier access whilst the old system is removed!
Check Out Another Post
TIA Portal Basics – Re-Initialization & Safe Downloads
Differences between an offline and online project, due to modifications being made Making changes to a project is an everyday…