Automation Project Lifecycle
Corso Systems has completed a lot of projects over the years. We have gone through a number of iterations of our project lifecycle and learned plenty along the way. As we have grown as a company, it is important now (more than ever) to utilize standard operating procedures for the work we do—including how we approach projects. This post will give you a high level overview of our project lifecycle, the steps to completion, and the information we need along the way for a successful project.
While this post covers the phases of a project, it doesn’t discuss the specific milestones we call out—as these can vary project by project. Usually there will be some level of oversight and agreement before we move from one phase to another in an official capacity, with the understanding that many of the phases will overlap based on the nature of the projects.
We Utilize a Standard 6-Step Process for Our Projects:
1. Discovery
Discovery is the first step on every project. Even if we have worked together before, a new project will involve new operational requirements, might involve new personnel, equipment, or facilities, and may even involve new technology.
Regardless, discovery starts with the 5 W’s we all know from grade school:
Who is involved
What are we looking to accomplish
Why are we doing it
Where is the project
When does it need to be completed
Who is usually covered as part of initial outreach and sales. We introduce our team, our capabilities, and our track record, you introduce your team, the key stakeholders, subject matter experts, and operators who will be using the system.
What determines the overall scope of work. This can include everything from requirements gathering, process documentation, working with your team to understand your process, your needs, and defines in detail what we are going to build. The What portion of discovery helps everyone set expectations for the project, timelines, and responsibilities. What encompasses not only what are we building, it also describes what technology stacks and methodologies we will be using to build the project.
Why brings the team together. When we can define the motivation for the project everyone can have buy-in and understanding of the project as a whole, what it will accomplish, and how putting in the effort will benefit everyone involved. The Why of a project is important to keep in mind along the way, and can help foster communication and understanding when complicated portions of implementation and testing are being worked through.
Where is pretty self explanatory.
When is maybe the hardest one to nail down. Usually it needs to be done yesterday. Usually we are the last ones to touch a system, especially if it is a new facility or production line, and we need to understand how everyone’s timelines and schedules impact ours. Many times we cannot complete our projects until everyone else has completed their tasks, either because we need equipment to be installed and operational, or we need information from various parties to complete our development. This is where it is important to understand in detail what we are doing and why we are doing it so we can be on the ball to complete our work as quickly as possible to help make up any schedule delays along the way.
Deliverables from this phase will be a scope of work, project schedule, and a project plan.
2. Design
While it is usually a separate phase of a project, Design begins during discovery. As part of the discovery process various assumptions will be made in the scope of work, including what technology will be used for the project.
We will generally put together a high level design of the system during discovery as part of the scope of work. The Design portion of the project is used to flesh out the details of the higher level overview and is used to build out our project management tools to keep everyone on task and up to date throughout the project.
Design usually involves meetings between all of the parties involved where we ask questions, get information, and agree upon the overall architecture for the system. This allows us to layout the optimal implementation given all of the potential constraints on the system, and find optimizations where possible. This can include using off the shelf libraries, templates and user defined datatypes, and how we will structure the various integrations between databases, software systems, and hardware integrations.
The completion of the design phase results in a set of deliverables. This is similar to the scope of work, with a lot more detail. We then break this design up into tasks to be set up in our project management system to track overall progress and provide a central repository for any questions we might have along the way. This gives everyone a complete understanding of what needs to be done, who is going to do what, how and when it is being developed, and provides a backstop for any discussions or changes that need to happen along the way.
The Design phase is the most important phase of any project. Leveraging our experience to make good decisions here allows us to build powerful tools in a short amount of time without having to do a lot of re-work along the way.
The deliverables from the Design phase will be a detailed project specification, system architecture, list of devices, tags, software/API integrations, etc., as well as things like databases we will be connecting to. We will include database schemas, security hierarchies, certificate requirements, and hardware/software bills of material. Basically everything we need to build the project in its entirety.
3. Development
Development may overlap with design in cases where we need to give the team something to interact with while doing the design. This can include mockups, proofs of concept, or even code that might become part of the final implementation. If we are doing any hardware or software purchasing that will take place during this phase so we have the licensing we need in place, and we will do whatever configuration of said hardware and software we need to do development.
In most instances however, development begins once we have a completed design in hand.
Development is usually the longest portion of any project as it requires the bulk of the effort.
In many instances development will take place on a separate system so we do not impact production and can do a lot of testing along the way. When we move into the next phase we will “cutover” the development system to production, either moving it to the facility or integrating it with an existing system for testing.
Development is tracked using our project management tools, questions are asked along the way, and we keep everyone up to speed with regular status meetings. This allows us to iterate through the project, updating the look and feel of operator interfaces along the way, incorporate any new information or tools as they are implemented by the client’s technology teams such as IT, and validate the system is operating as expected from a design perspective.
We do not like to be surprised when it comes time for the testing/deployment phase so development and testing are closely coupled throughout the project.
The deliverables from this phase will be a project implementation ready for testing along with basic documentation for system operation.
4. Testing/Deployment
During development we will continuously test our code to ensure it works, however on most projects we aren’t able to test with the actual equipment or software tools until it is operational in the field. Once we are able to test and are close to complete with development.
This phase involves moving our project resources to the production environment, validating communication between devices, systems, and IT infrastructure, and is the first time we will be able to see the system in action as a whole.
We like to break up testing and deployment into technically separate activities even though they will likely be completed at or near the same time.
Testing is where we commission the system and validate I/O on hardware, data flow on software, and do standard checkout procedures before we move into full operation. For example this would be verifying all of the valves in a system open and close, pumps turn on and spin the correct direction, and all of the instrumentation reads correctly before we try to run the process in full. It is also where we validate we are populating databases with the correct values at the correct times, API calls work as expected, and all of our system wide communications are in order.
As we test the system we consider it commissioned and begin to validate full operation. This moves into the deployment portion of this phase.
During deployment we move from testing individual data points and I/O into testing operational systems within the overall process, and then move from individual systems to the process as a whole. Depending on the project this can take on many forms, however it usually involves running through the process from the beginning, fixing any items we need to along the way, validating the fixes, and continuing through the process until the entire process is deployed.
This approach allows us to streamline the implementation of a project and doesn’t require a separate phase after this to fully roll out the system as we have tested everything along the way.
Deliverables from this phase will be a completed project backup of any software and configurations we are using, project documentation and operation manuals, and an updated specification similar to the design specification for future stewardship of the system.
5. Training
On most projects we act as operators through the testing/deployment phase. We will be the ones running the system as we test things, making modifications along the way and finalizing the overall workflow of everything the actual operators will use.
Once we have fully deployed the system and finalized the graphics and interactions we will build out the final version of our documentation including operation/maintenance manuals, walkthroughs of how to use the system, and even video recordings of the system in operation to give operations staff the clearest possible picture of how to use the system we have developed.
Training is commonly an afterthought in this industry with people saying things like “it is so intuitive to use you don’t need training!” While we strive to build the simplest and most easy to use systems possible it is beneficial for the people using it to be trained. They need to understand how to use the system, get familiar with it, and operate under ever increasing pressure to get more done in shorter amounts of time. We would love to program everything to require a simple press of a button, however the real world sometimes has other ideas and may require operators to think on their feet to handle an unforeseen process requirement.
Consistent and well led training helps them understand all of the options available to them in those moments, and things like making the documentation available in the HMI exactly when and where they need it can be a huge help on large scale projects.
We pride ourselves on providing industry leading training, leaning on the members of our team with backgrounds in education to build training materials with the right amount of repetition and clarity.
Deliverables from this phase will be a fully up to date manual and implementation specification for the system updating the material from step 4 with any questions or clarifications we made during training.
6. Maintenance and Support
After the operators take ownership of the system and begin to run it themselves we move into maintenance and support mode. This is where the fun really begins!
Given our extensive design and testing efforts maintenance and support is usually fairly routine, so we build in some time in each project to account for this during warranty periods. In the automation world once you have deployed a system it should do the same thing every time. However many times systems will be used for things they were not intended to do in the first place and we need to make an adjustment to something after it has been deployed.
For projects to get done in any reasonable amount of time it is usually impossible to cover EVERY single possible scenario a system could run into. We might also run into edge cases where the system has gotten into a state that reveals a bug in the code and we need to get back in and fix it. In most cases these edge cases are things like “well I know we SAID we would never need to pump from the storage tank back into the mixing vessel, BUT…” which requires some additional code to be written, tested, and deployed.
This phase can also be pretty mundane where we need to go in and apply software patches, or reset passwords periodically. Assuming we are doing our job correctly this phase also become the kick-off point to go back to phase 1 and start the discovery process on a new scope of work.
Deliverables from this phase are typically notes and emails regarding any work that was completed, bugs that were found, etc. Anything that needs to be updated in the project specification will be adjusted as needed for future maintenance of the system.
Wrapping Up
Our goal with every project is to have a successful implementation with all of the relevant information for anyone who steps in after us (including Corso Systems in the future) to understand how the system was architected, be able to support and maintain it, and understand what is reusable on future projects for the same client.
As you know if you have worked on many projects once you haven’t looked at something for a number of months or years it can take a while to get your bearings when you get back into the project. Knowing this, and having experienced calls a couple years down the road for one of those “I know we said we would NEVER need to do XYZ, but now we need to do XYZ” scenarios having clear, detailed, and standardized documentation is the easiest way to get up to speed on a project.
This is one of the many ways Corso Systems works to be the change we want to see in the world, build projects as if they were our own to maintain and support, and take full ownership and responsibility for the work we produce.
A job worth doing is worth doing well, and you better write down what you did so you can learn from what you did well before!
