Last month we discussed how to properly define the goals, scope, budget and schedule for a machine reconfiguration or recontrol project. If you missed it, you can read it here.
After presenting your well-defined project scope and business case to your leadership team, your project got approved. Congrats! Now the project needs to be executed.
Here, we share with you some tips for success in the design phase of your project from our experts: Seth Donnelly, PMP and Todd Dye, Director of Operations.
Start with another walkthrough and a kickoff meeting
The design phase of your machine reconfiguration or recontrol project is the most critical, as the things that happen during the design process set the tone for the rest of the project.
Start with a kickoff meeting, including all of the project stakeholders – operators, engineers, designers, end users, the group that funded the project – the goal is to make sure everyone is getting what they need out of the project and everyone is on the same page. Review the scope of what was proposed and then verify with the client, making corrections as needed. Walkthrough again to review the equipment, space constraints, etc. It’s key to get consensus and agreement on deliverables and requirements at this time.
“Get everyone to agree to the functional requirements spec ahead of time,” Seth says.
“You want to avoid a situation where you’re adding requirements during Factory Acceptance Testing, which is a common mistake.”
With a reconfiguration or recontrol project, it can be easy to miss details, especially if the existing system isn’t well documented.
“With a recontrol project, before you can ask an integrator to replace what you have, make sure you can tell them exactly what you have to begin with,” Todd says. “During design, you want to define what’s not well documented about the project in the context of controls. Often, a lot of people who were involved in the original design of the controls are gone. Then you are battling missing documentation and brain drain.”
For example, in the case of IO, let’s say we have a 1000 IO points, but in the PLC program, there’s only 600 used; it’s obvious that the other 400 aren’t needed. If it’s the other way around and the IO is in the code but not in the drawing, that’s a bigger problem.
“Gather all of the info and compare it to what you see in the program. If there’s something extra or missing in the code, you need to get operators involved,” Todd says.
Use templates and document everything
Even if you know your integrator well and think the kickoff phase can be a breeze, it’s important to keep it formal. A template can help to ensure you’re covering all questions and assumptions.
“It’s often surprising how much you can cover and how many unknowns can come up during the kickoff,” Seth says. “We have templates to start from to cover the different projects. They cover a lot of the commercial and the technical items. Technical like software and hardware – what’s changing, not changing, what’s included and not. These will include all of the assumptions we’re making.
We have some templates on the design documents. HMI screens – how they change color, how they may change. Those seem to be the questions that come up at the end.”
As you review the original proposal and assumptions made by the integrator, and as the right questions are asked, thorough documentation is critical. You want to make sure you document functional requirements, scope changes, assumptions, corrections and test requirements.
“The more detailed a Functional Requirements Spec document is, the better. A lot of times we try to quantify what we’re changing. A lot of times we may not have a ton of detail, but the more examples we can put in, that helps spark the conversations with the clients,” Seth says.
Changes are inevitable
Even with a well-defined scope, changes can come out during the design phase. Drawings may be outdated, drawing packages incomplete, new requirements come out of conversations during the kickoff meetings. It happens.
“When things change from our original assumptions, we’ll assess what the impact would be to the cost, schedule and risk. That’s always a moving target as you go through the project. Change is inevitable,” Seth says.
But it’s no reason to get nervous, either. Changes can often mean a change in cost, but not always. And even if there is an additional cost, having it come up during the design phase is the best case scenario, as the cost to make a change during the design phase is much less than when a change is needed at the end of a project. This is why it’s so important to take the time at the beginning and think everything through.
“Often, machine reconfiguration or recontrol projects have a short installation window, so you want to eliminate those changes at the end. Identify those issues up front when time is on your side,” Todd says.
“We may be able to address a change where it won’t impact the cost but maybe the schedule or risk,” Seth says. “Having the level of detail on the impact of the change can help getting the additional cost approved. For example, the cost may increase slightly, but if we can finish the project early, you may be able to have an easier time getting approval.”
On to development
Before you can begin development on your machine reconfiguration or recontrol project, the following should have happened:
- A review of the original proposed scope and assumptions made by your integrator
- A walkthrough to review the equipment, space constraints, etc. again together
- A kickoff meeting to review and update requirements
- All design packages and drawings of existing equipment are reviewed to look for changes that may need to be made.
- Your review and signoff on functional requirements specifications and testing requirements.
We’ll cover development in our next blog post. Stay tuned!
