Demystifying “Use Cases” [Marketplace #8]

Hey friends, 

The Nexus Pro community manager, Eric Larsen, posed a compelling prompt to our 600-member community:

“Many of us agree that “Use Cases” are the building blocks of a Smart Building. However, I haven’t heard a single, significant, concise definition. How can that be if they’re so important?!”

This term—Use Cases—gets thrown around so much in webinars and conferences and Nexus Pro member gatherings that it might be losing its value. 

But don’t let the repetition lull you to sleep… Developing use cases is an irreplaceable step in your smart buildings program. 

Unfortunately, I’ve seen firsthand that not everyone agrees with that statement—or at least they don’t act like they do. There are buyers out there buying technology without defining use cases. There are vendors out there demo’ing their tech without grounding their demo in use cases.   

So why should the marketplace care about use cases? Let’s count the ways: 

• Buyers can communicate to their leadership exactly how the technology will move the needle  
• Buyers can avoid procuring technology that won’t get used 
• Buyers can avoid procuring technology that doesn’t actually improve the business 
• Buyers can avoid procuring technology that doesn’t actually improve a human’s workflow
• Vendors can determine if a buyer is serious and strategic by asking for use cases 

All of these problems hold the industry back… and they’re all so avoidable. Use cases can be designed with very little cost. 

In terms of the smart building technology buying process, developing use cases literally defines what you need from your vendors and internal stakeholders. It defines who will use the technology, which capabilities and features the product needs to have, and what that product needs to integrate with. 

In this sense, defining a use case is a thinking tool that sets the stage for many of the decisions you’ll make throughout the rest of the buying journey.

So what does this look like in practice? The following is an adapted summary of the answers from the Nexus Pro community, led by Eric Larsen, Drew DePriest, and Pete Swanson. 

The full definition of a Use Case for smart building technology:

• Use Case ID: Unique identifier with a short summary 
• (WHY) Business Outcome: 

              - Result of improved workflow

               - KPI that will be used to quantify and measure the improvement

• (WHO) Stakeholder / Actor / Persona: End-user whose workflow is improved 
• (WHAT) Improved Workflow: How the workflow is improved
• (Optional) User Journey:

               - As a [stakeholder],

              - I want to [improved workflow]

              - So I can [business outcome]

• New Workflow: Series of steps to be completed to ensure the business outcome is achieved

EXAMPLE 1: 

• Use Case ID: FDD-1—Automatically identify HVAC system inefficiencies.
• Business Outcome: Correcting building system inefficiencies to lower utility cost, increasing NOI

                    - KPI: Cumulative annualized avoided energy costs compared to baseline year

• Stakeholder / Actor / Persona: Energy Manager
• Improved Workflow: Automatic detection of HVAC performance outliers
• User Journey:

                 - As an energy manager,

                 - I want to automatically detect HVAC performance outliers

                 - So I can reduce energy consumption and utility cost.

• New Workflow: 

1. Analytics software (FDD or similar) analyzes HVAC operational data that’s produced by the Building Automation System (BAS).
2. Energy manager logs into the software once per week. 
3. Software alerts specific conditions to energy manager.
4. Energy manager investigates, determines the root cause of the issue, prioritizes, and creates business case for repairs/upgrades.
5. CFO approves business case.
6. Energy manager submits a work order in the CMMS to the FM team. 
7. FM team implements upgrade.
8. Terminator: The energy manager reviews T+90 days operational data, confirms efficiency improvement, and quantifies avoided energy costs.

To summarize, let’s now think through what information the buyer has gained by doing this exercise: 

1. We’ll need to get the CFO on board with (1) our KPI that measures success and (2) the ROI required to spend money on each individual issue that the software identifies. 
2. The BAS is vital, and we’ll need to get data out of it to enable this use case. 
3. The energy manager is the primary user, so their job will be transformed to integrate this tech into their day/week/year and performance reviews. 
4. The energy manager could cover more square footage of the portfolio if the software helps with the investigation, determines the root cause, prioritizes, and calculates expected energy/carbon savings.

And there’s more, but we’ll stop there. 

Does this exercise resonate with you? Do you want help with this exercise? Reach out and let us know.

See you next week,  

—James and the Nexus Labs team

PS: Pro members can check out the full chatroom conversation here. It’s got another example, which defines a use case for DAS technology. Thanks to Eric Larsen, Drew DePriest, and Pete Swanson for your insights. 

P.P.S. Our Marketplace Demo Hub is designed to provide standardized demos that are grounded in use cases that each vendor is enabling. As a buyer, each demo will have the same look and feel for you. Check it out and let us know what you think.