Learn about NexusCon!
.png)
Welcome to our Case Study series, where we dive into case studies of real-life, large-scale deployments of smart building technologies.
I emphasize “real life” because this isn’t a marketing fluff story. We're here to share real lessons from leaders that have done the work to integrate smart building technology into their operations. I also emphasize “large scale” because we're not here to talk about pilot projects. We're here to talk about deeper commitments to changing how buildings are operated.
This first edition is the story of a 9-year effort at the University of Iowa to integrate fault detection and diagnostics, or FDD, into their maintenance operations. This storytelling is supported by our Partner Program.
This case study is not a recommendation or an endorsement of any product by The University of Iowa.
.png)
In the early 2010s, Don Guckert, who was the Associate VP at the University of Iowa, read a groundbreaking article about Microsoft's implementation of Fault Detection and Diagnostics software. He was so intrigued that he put together a team that made a trip out to Redmond, Washington to visit the Microsoft campus and see their FDD program in real life.
Eventually, he turned to Tom Moore and Katie Rossman to make it work back home. In the last 9 years, the University of Iowa has deployed FDD software across 47 buildings and 6.9 million square feet of higher education space. Their FDD program has been extremely impactful—driving 2,100 tasks to completion and $2.5 million per year in verified energy savings—while creating insights that all building owners can learn from.
This case study is designed to share that playbook. We’ll walk through what Iowa has learned and what others can take away from their experience.
Iowa’s FDD program began in 2014 and has gone through iterations as they’ve learned. They summarized the phases of the program as follows:
We interviewed the program’s key stakeholders, including:
These three experts shared several insights that we’ve packaged into a playbook for putting together an FDD program from scratch. If you’re buying or deploying FDD technology soon, you’ll love that Iowa shared their exact flowchart for driving action.
One of the reasons for Iowa’s success is leadership support. Leadership should encourage a culture that is not afraid of failure but sees it as an opportunity for growth. This mindset allows teams to experiment, take risks, and test the boundaries to find innovative solutions. It is crucial to recognize that failures are part of the learning process and that adjustments can be made along the way.
Leadership should be open to changing course if a better option or approach presents itself. This flexibility allows the team to adapt and optimize their strategies, even if it means investing additional time and resources. Innovation requires the ability to pivot and find the best path forward.
Leadership should prioritize innovation and progress over striving for perfection or sticking rigidly to initial plans. Recognize that innovation involves exploring new territory where things may not go according to plan. Supporting teams in their pursuit of innovation means allowing them the freedom to explore and evolve their approaches.
“And when we made this decision, we went out for RFP and the decision was we selected a different vendor. Is that a negative here? And it was just sort of like, that was just a year of learning and we need to pivot if it's the better option for us going forward. And it made that choice a lot easier for us to make that switch because so much time had been invested in that initial pilot.”
The FDD team needs to establish clear outcomes they seek to achieve through the software deployment. In Iowa’s case, they set out to find energy savings opportunities, prioritize maintenance tasks, and train HVAC technicians. These goals determine how the software should be integrated into existing operations.
With such a heavy focus on maintenance operations, they realized that this tool couldn’t be only dependent on use by an energy engineer.
“This needs to be something that maintenance does. Maintenance needs to have a really integral role in this tool. It needed to be part of our day-to-day lives and how we do maintenance.”
Integrating the software into maintenance workflows is crucial for successful implementation. Instead of treating it solely as an energy management tool, it should be incorporated into day-to-day maintenance practices. By integrating the software with Iowa’s computerized maintenance management software (CMMS) and making the resulting work orders resemble familiar maintenance tasks, the team facilitated better adoption and acceptance among maintenance staff.
“Our maintenance people don't speak tasks, they speak work orders. And so the more it looks like their day-to-day hot and cold call, the better it is, right? So if we can make that push of that FDD resolution look like a work order, then it's much easier for the organization to adopt it. And also, they get much better adoption when it's someone like Brad who's sending the work order out, who can go and get his hands dirty and fix the problem.
We treat these like any other work order. They do not get special treatment when it goes out to the front line. I just wanna say that, I should have said that earlier. So that also helps with the implementation too, because we have our customer expectations of when tickets are gonna be finished. So we are able to use that metric and see how successful we were being with these frontline folks. And we were dismal in the beginning, but over the last year, year and a half with we've really, really connected and you'll see it in the data.”
By ensuring that the software aligns with their existing workflows and speaks their language (work orders), the organization can enhance adoption and engagement. Having well-respected technicians involved in the process also contributes to greater buy-in.
“I've seen this energy-management-centric FDD programs work well at other organizations, but with the resources we had at Iowa, the funding sources we had at Iowa, the levers we had to pull to execute work, it just wasn't going to work if it was coming through as an energy project, just based on history at the university and the resources that we had at the time. It would be a much more successful program if it was run through our maintenance organization.”
This insight is key: When selecting a software platform or determining the program's structure, consider the organization's strengths, available resources, funding sources, and execution capabilities. Assess how the program can best leverage existing resources and funding mechanisms. Tailor the program to align with the organization's capabilities and constraints for a successful implementation.
One of the most insightful parts of this case study is how the Iowa team constructed their Analytic Response Group (ARG). Filling the following roles was key to their success.
Maintenance Super Users: The top technicians in the organization who have extensive knowledge and experience in maintenance work. They are responsible for utilizing the analytics platform and acting as the point of contact for any problems or issues identified. They are well-respected by their peers and play a crucial role in identifying and prioritizing maintenance tasks based on the data provided by the platform.
“Our campus is split in half by a river. So basically I said who's the best technician with the most respect on the west side and who's the technician with the most respect and knowledge on the right side of the river and that's how we came up with the two Maintenance Super Users.”
Controls Programmer: This role is responsible for handling the programming side of the analytics response. They ensure the necessary programming changes are made to optimize the control system’s performance. The Controls Programmer also assists in fieldwork and coordinates with the controls group to implement necessary programming changes.
IT Support: An IT professional plays a critical role in the ARG. They are responsible for maintaining the servers, establishing and monitoring connections, ensuring firewall security, and handling technical aspects related to the analytics platform. Along with the FDD vendor, IT support is essential for initial deployment and ongoing system maintenance.
Front Line Technicians: These are the technicians who work on the front lines of maintenance operations. The ARG aims to integrate them into the team and daily workflow. They are encouraged to use the platform as a tool to assist them in their work. They provide feedback on the platform's effectiveness and communicate any issues or areas for improvement back to the ARG team. The front-line technicians also seek guidance and advice from the ARG team when faced with challenges or complex situations.
It's worth noting that the ARG team members collaborate closely and work together to ensure the successful implementation and utilization of the analytics platform. Each role contributes to different aspects, such as technical expertise, programming, IT support, and frontline implementation, fostering a comprehensive and integrated approach to maintenance operations.
“We needed a flow chart so we can explain, both to ourselves and everyone else: what does it look like when a fault comes in... what are our duties?”
Here at Nexus Labs, we affectionately refer to Iowa’s ARG process as the Big Ass Flow Chart. It’s amazing in its detail and sophistication. Check it out…
To simplify, we’ve summarized the process for driving action with FDD as follows:
Step 1: Validate and confirm the diagnosis by evaluating the information provided by the software. Determine if the diagnostic is accurate and makes sense. Human expertise is necessary to verify the findings.
Step 2: Triage the fault to decide the responsibility of the trade involved. Experienced individuals with in-depth knowledge of the system identify the most likely cause of the issue and decide whether it requires further investigation or can be assigned to the maintenance team.
Step 3: Create a task or work order manually based on the diagnostic results. This step involves reviewing all the symptoms and recommended actions provided by the diagnostic software to ensure accuracy and relevance. The human input helps refine the work order instructions before sending them to the field.
Step 4: Assign someone to track the work order and provide support during implementation. This person is responsible for assigning the work to the appropriate trade, monitoring progress, and offering assistance if needed. They also ensure the resolution of the problem.
Step 5: Close the loop by conducting regular meetings to review completed tasks, cleared faults, and unresolved issues. These meetings involve area supervisors and provide an opportunity to discuss the progress and determine any further actions required.
Overall, this process combines the power of diagnostic software with human expertise to validate, prioritize, and address faults effectively, ensuring efficient maintenance and optimization of systems.
When you’re changing how buildings are operated, there will always be pushback. Implementing intelligent software to augment human workflows requires patience and effective change management strategies.
In Iowa’s case, the pushback was centered around the analytics software stealing technicians’ special magic. They were skeptical, saying “All this analysis that the software is doing, that's my magic. That's where I make my living and you're sort of automating it away.”
Helping our operations teams recognize the limitations of human capabilities: FDD can identify important issues and patterns that may go unnoticed by humans. Or at a minimum can save those humans time. It is essential to understand that these findings are not easily stumbled upon and require dedicated time and effort that may be better spent elsewhere.
Assure operations teammates that the software is not intended to make them look bad: Instead, it can enhance their job performance. Highlight that the software is a tool in their toolbox, alongside other resources, to help them accomplish their tasks more effectively.
Find an ‘aha moment’: Demonstrate the software to employees, engaging in conversations about its purpose and functionalities. This hands-on approach can foster enthusiasm and understanding, promoting acceptance and engagement with the technology. It’s especially effective to find an ‘aha moment’, an example of something that the FDD software found that will galvanize support for the program.
“Our software is telling us that you're not getting the heat that you need to get out of these coils.”
Iowa’s aha moment came when they opened up a new wet lab building. The FDD program identified hot water reheat coils that were manually closed. They then used that story to show the predictive power of hot and cold calls.
Celebrate successes: Involve employees in the positive outcomes resulting from the software's assistance. When it leads to energy savings or improvements in their work environment, highlight their contributions and how the software facilitated these achievements. This recognition encourages a sense of pride and ownership.
Communicate and showcase the success stories resulting from the use of the software. Highlight the positive impact it has had on operations, efficiency, and cost savings. Sharing these stories helps build confidence in the software and encourages further adoption and exploration of its capabilities.
In this case study, we emphasize the importance of integrating fault detection and diagnostics (FDD) with maintenance operations to maximize its value. It is crucial to allocate resources and build a team with super users who possess extensive expertise in HVAC and controls.
Defining the FDD operational process in fine detail is necessary to ensure accurate diagnosis and effective decision-making. Additionally, the case study highlights the significance of continuously improving the process and deepening the integration of the tool into operations workflows over time, enabling better fault resolution and building system optimization.
By combining these elements, organizations can leverage FDD to enhance maintenance operations and achieve optimal performance.
How'd you like this piece? Give us your feedback on this piece so we can improve! (15 second survey)
NEXUS LABS ACTION ITEMS (not a recommendation or endorsement from the University of Iowa):
If you’re developing or specifying or selecting an FDD product, we think there are a few key takeaways for you here.
First, even though the Iowa team had some resources and leadership support to self-perform the development of FDD rules, it’s not going to make sense for most organizations. In the end, it didn’t make sense for Iowa either. We believe that 99% of organizations shouldn’t be spending time on this.
As Katie said in our interview, it doesn’t make any sense for “people all over the United States to be writing the same economizer fault.” Or the world for that matter! For our industry to truly decarbonize and digitize operations, FDD products need to be created in a way that allows the crowdsourcing of analysis and diagnosis and prioritization methods. Unfortunately, most FDD products aren’t built that way.
This makes the product selection process vital. The less time the end user spends on writing rules or setting up analytics, the more time they can spend on driving action and producing results.
Our whitepaper on selecting FDD software explains this in more detail.
NEXUS LABS ACTION ITEMS (not a recommendation or endorsement from the University of Iowa):
If you’re developing or specifying or selecting an FDD product, we think there are a few key takeaways for you here.
First, even though the Iowa team had some resources and leadership support to self-perform the development of FDD rules, it’s not going to make sense for most organizations. In the end, it didn’t make sense for Iowa either. We believe that 99% of organizations shouldn’t be spending time on this.
As Katie said in our interview, it doesn’t make any sense for “people all over the United States to be writing the same economizer fault.” Or the world for that matter! For our industry to truly decarbonize and digitize operations, FDD products need to be created in a way that allows the crowdsourcing of analysis and diagnosis and prioritization methods. Unfortunately, most FDD products aren’t built that way.
This makes the product selection process vital. The less time the end user spends on writing rules or setting up analytics, the more time they can spend on driving action and producing results.
Our whitepaper on selecting FDD software explains this in more detail.
NEXUS LABS ACTION ITEMS (not a recommendation or endorsement from the University of Iowa):
If you’re developing or specifying or selecting an FDD product, we think there are a few key takeaways for you here.
First, even though the Iowa team had some resources and leadership support to self-perform the development of FDD rules, it’s not going to make sense for most organizations. In the end, it didn’t make sense for Iowa either. We believe that 99% of organizations shouldn’t be spending time on this.
As Katie said in our interview, it doesn’t make any sense for “people all over the United States to be writing the same economizer fault.” Or the world for that matter! For our industry to truly decarbonize and digitize operations, FDD products need to be created in a way that allows the crowdsourcing of analysis and diagnosis and prioritization methods. Unfortunately, most FDD products aren’t built that way.
This makes the product selection process vital. The less time the end user spends on writing rules or setting up analytics, the more time they can spend on driving action and producing results.
Our whitepaper on selecting FDD software explains this in more detail.
Welcome to our Case Study series, where we dive into case studies of real-life, large-scale deployments of smart building technologies.
I emphasize “real life” because this isn’t a marketing fluff story. We're here to share real lessons from leaders that have done the work to integrate smart building technology into their operations. I also emphasize “large scale” because we're not here to talk about pilot projects. We're here to talk about deeper commitments to changing how buildings are operated.
This first edition is the story of a 9-year effort at the University of Iowa to integrate fault detection and diagnostics, or FDD, into their maintenance operations. This storytelling is supported by our Partner Program.
This case study is not a recommendation or an endorsement of any product by The University of Iowa.
In the early 2010s, Don Guckert, who was the Associate VP at the University of Iowa, read a groundbreaking article about Microsoft's implementation of Fault Detection and Diagnostics software. He was so intrigued that he put together a team that made a trip out to Redmond, Washington to visit the Microsoft campus and see their FDD program in real life.
Eventually, he turned to Tom Moore and Katie Rossman to make it work back home. In the last 9 years, the University of Iowa has deployed FDD software across 47 buildings and 6.9 million square feet of higher education space. Their FDD program has been extremely impactful—driving 2,100 tasks to completion and $2.5 million per year in verified energy savings—while creating insights that all building owners can learn from.
This case study is designed to share that playbook. We’ll walk through what Iowa has learned and what others can take away from their experience.
Iowa’s FDD program began in 2014 and has gone through iterations as they’ve learned. They summarized the phases of the program as follows:
We interviewed the program’s key stakeholders, including:
These three experts shared several insights that we’ve packaged into a playbook for putting together an FDD program from scratch. If you’re buying or deploying FDD technology soon, you’ll love that Iowa shared their exact flowchart for driving action.
One of the reasons for Iowa’s success is leadership support. Leadership should encourage a culture that is not afraid of failure but sees it as an opportunity for growth. This mindset allows teams to experiment, take risks, and test the boundaries to find innovative solutions. It is crucial to recognize that failures are part of the learning process and that adjustments can be made along the way.
Leadership should be open to changing course if a better option or approach presents itself. This flexibility allows the team to adapt and optimize their strategies, even if it means investing additional time and resources. Innovation requires the ability to pivot and find the best path forward.
Leadership should prioritize innovation and progress over striving for perfection or sticking rigidly to initial plans. Recognize that innovation involves exploring new territory where things may not go according to plan. Supporting teams in their pursuit of innovation means allowing them the freedom to explore and evolve their approaches.
“And when we made this decision, we went out for RFP and the decision was we selected a different vendor. Is that a negative here? And it was just sort of like, that was just a year of learning and we need to pivot if it's the better option for us going forward. And it made that choice a lot easier for us to make that switch because so much time had been invested in that initial pilot.”
The FDD team needs to establish clear outcomes they seek to achieve through the software deployment. In Iowa’s case, they set out to find energy savings opportunities, prioritize maintenance tasks, and train HVAC technicians. These goals determine how the software should be integrated into existing operations.
With such a heavy focus on maintenance operations, they realized that this tool couldn’t be only dependent on use by an energy engineer.
“This needs to be something that maintenance does. Maintenance needs to have a really integral role in this tool. It needed to be part of our day-to-day lives and how we do maintenance.”
Integrating the software into maintenance workflows is crucial for successful implementation. Instead of treating it solely as an energy management tool, it should be incorporated into day-to-day maintenance practices. By integrating the software with Iowa’s computerized maintenance management software (CMMS) and making the resulting work orders resemble familiar maintenance tasks, the team facilitated better adoption and acceptance among maintenance staff.
“Our maintenance people don't speak tasks, they speak work orders. And so the more it looks like their day-to-day hot and cold call, the better it is, right? So if we can make that push of that FDD resolution look like a work order, then it's much easier for the organization to adopt it. And also, they get much better adoption when it's someone like Brad who's sending the work order out, who can go and get his hands dirty and fix the problem.
We treat these like any other work order. They do not get special treatment when it goes out to the front line. I just wanna say that, I should have said that earlier. So that also helps with the implementation too, because we have our customer expectations of when tickets are gonna be finished. So we are able to use that metric and see how successful we were being with these frontline folks. And we were dismal in the beginning, but over the last year, year and a half with we've really, really connected and you'll see it in the data.”
By ensuring that the software aligns with their existing workflows and speaks their language (work orders), the organization can enhance adoption and engagement. Having well-respected technicians involved in the process also contributes to greater buy-in.
“I've seen this energy-management-centric FDD programs work well at other organizations, but with the resources we had at Iowa, the funding sources we had at Iowa, the levers we had to pull to execute work, it just wasn't going to work if it was coming through as an energy project, just based on history at the university and the resources that we had at the time. It would be a much more successful program if it was run through our maintenance organization.”
This insight is key: When selecting a software platform or determining the program's structure, consider the organization's strengths, available resources, funding sources, and execution capabilities. Assess how the program can best leverage existing resources and funding mechanisms. Tailor the program to align with the organization's capabilities and constraints for a successful implementation.
One of the most insightful parts of this case study is how the Iowa team constructed their Analytic Response Group (ARG). Filling the following roles was key to their success.
Maintenance Super Users: The top technicians in the organization who have extensive knowledge and experience in maintenance work. They are responsible for utilizing the analytics platform and acting as the point of contact for any problems or issues identified. They are well-respected by their peers and play a crucial role in identifying and prioritizing maintenance tasks based on the data provided by the platform.
“Our campus is split in half by a river. So basically I said who's the best technician with the most respect on the west side and who's the technician with the most respect and knowledge on the right side of the river and that's how we came up with the two Maintenance Super Users.”
Controls Programmer: This role is responsible for handling the programming side of the analytics response. They ensure the necessary programming changes are made to optimize the control system’s performance. The Controls Programmer also assists in fieldwork and coordinates with the controls group to implement necessary programming changes.
IT Support: An IT professional plays a critical role in the ARG. They are responsible for maintaining the servers, establishing and monitoring connections, ensuring firewall security, and handling technical aspects related to the analytics platform. Along with the FDD vendor, IT support is essential for initial deployment and ongoing system maintenance.
Front Line Technicians: These are the technicians who work on the front lines of maintenance operations. The ARG aims to integrate them into the team and daily workflow. They are encouraged to use the platform as a tool to assist them in their work. They provide feedback on the platform's effectiveness and communicate any issues or areas for improvement back to the ARG team. The front-line technicians also seek guidance and advice from the ARG team when faced with challenges or complex situations.
It's worth noting that the ARG team members collaborate closely and work together to ensure the successful implementation and utilization of the analytics platform. Each role contributes to different aspects, such as technical expertise, programming, IT support, and frontline implementation, fostering a comprehensive and integrated approach to maintenance operations.
“We needed a flow chart so we can explain, both to ourselves and everyone else: what does it look like when a fault comes in... what are our duties?”
Here at Nexus Labs, we affectionately refer to Iowa’s ARG process as the Big Ass Flow Chart. It’s amazing in its detail and sophistication. Check it out…
To simplify, we’ve summarized the process for driving action with FDD as follows:
Step 1: Validate and confirm the diagnosis by evaluating the information provided by the software. Determine if the diagnostic is accurate and makes sense. Human expertise is necessary to verify the findings.
Step 2: Triage the fault to decide the responsibility of the trade involved. Experienced individuals with in-depth knowledge of the system identify the most likely cause of the issue and decide whether it requires further investigation or can be assigned to the maintenance team.
Step 3: Create a task or work order manually based on the diagnostic results. This step involves reviewing all the symptoms and recommended actions provided by the diagnostic software to ensure accuracy and relevance. The human input helps refine the work order instructions before sending them to the field.
Step 4: Assign someone to track the work order and provide support during implementation. This person is responsible for assigning the work to the appropriate trade, monitoring progress, and offering assistance if needed. They also ensure the resolution of the problem.
Step 5: Close the loop by conducting regular meetings to review completed tasks, cleared faults, and unresolved issues. These meetings involve area supervisors and provide an opportunity to discuss the progress and determine any further actions required.
Overall, this process combines the power of diagnostic software with human expertise to validate, prioritize, and address faults effectively, ensuring efficient maintenance and optimization of systems.
When you’re changing how buildings are operated, there will always be pushback. Implementing intelligent software to augment human workflows requires patience and effective change management strategies.
In Iowa’s case, the pushback was centered around the analytics software stealing technicians’ special magic. They were skeptical, saying “All this analysis that the software is doing, that's my magic. That's where I make my living and you're sort of automating it away.”
Helping our operations teams recognize the limitations of human capabilities: FDD can identify important issues and patterns that may go unnoticed by humans. Or at a minimum can save those humans time. It is essential to understand that these findings are not easily stumbled upon and require dedicated time and effort that may be better spent elsewhere.
Assure operations teammates that the software is not intended to make them look bad: Instead, it can enhance their job performance. Highlight that the software is a tool in their toolbox, alongside other resources, to help them accomplish their tasks more effectively.
Find an ‘aha moment’: Demonstrate the software to employees, engaging in conversations about its purpose and functionalities. This hands-on approach can foster enthusiasm and understanding, promoting acceptance and engagement with the technology. It’s especially effective to find an ‘aha moment’, an example of something that the FDD software found that will galvanize support for the program.
“Our software is telling us that you're not getting the heat that you need to get out of these coils.”
Iowa’s aha moment came when they opened up a new wet lab building. The FDD program identified hot water reheat coils that were manually closed. They then used that story to show the predictive power of hot and cold calls.
Celebrate successes: Involve employees in the positive outcomes resulting from the software's assistance. When it leads to energy savings or improvements in their work environment, highlight their contributions and how the software facilitated these achievements. This recognition encourages a sense of pride and ownership.
Communicate and showcase the success stories resulting from the use of the software. Highlight the positive impact it has had on operations, efficiency, and cost savings. Sharing these stories helps build confidence in the software and encourages further adoption and exploration of its capabilities.
In this case study, we emphasize the importance of integrating fault detection and diagnostics (FDD) with maintenance operations to maximize its value. It is crucial to allocate resources and build a team with super users who possess extensive expertise in HVAC and controls.
Defining the FDD operational process in fine detail is necessary to ensure accurate diagnosis and effective decision-making. Additionally, the case study highlights the significance of continuously improving the process and deepening the integration of the tool into operations workflows over time, enabling better fault resolution and building system optimization.
By combining these elements, organizations can leverage FDD to enhance maintenance operations and achieve optimal performance.
How'd you like this piece? Give us your feedback on this piece so we can improve! (15 second survey)
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.