Most apartment operators want to be more data driven in their decision-making processes, relying less on their “gut feel,” but few really know how to make this fundamental transition—in terms of both capability and culture.
In this context, business intelligence (BI) has become a growing area of interest to multifamily executives. As we’ve moved past the hype of “Big Data” and more to the realities of how much we can accomplish in our industry, I’ve seen that by mastering the “little data,” many more operators invest real dollars in BI initiatives. Unfortunately, my firm has also seen the road littered with BI projects that have failed—with hundreds of thousands, even millions, of dollars wasted on projects with disappointing results.
So what truly separates successful BI projects from mediocre ones (or, worse, from those that end up in the scrap bin)?
Who’s Driving the Bus?
Many BI projects look something like this: The IT team identifies all the data needed to deliver a BI platform, usually by creating a census of existing reports, and proceeds to build a data warehouse to store all the data. The team then builds reports, making sure all existing reports are re-created, and proceeds to develop an internal portal to deliver all this information.
This process may seem natural, since BI is so technology driven; however, my firm’s experience is that allowing BI to be driven predominantly by IT results in limited success at best and abject failure at worst. These IT-driven BI projects, for example, tend to share a number of dysfunctional results:
• BI feels more like a “black box” to operators than a transparent set of key metrics. Because the goal was largely to replicate existing reports (perhaps with some sense of culling less-used reports), the business side wasn’t particularly engaged in the process. They were consulted on what “data” to collect and on specific reports, but they weren’t really emotionally engaged and didn’t learn much along the way. IT knows how to build a data warehouse, so they did that without substantial business involvement. The new BI platform is announced with great fanfare (and training).
• Because of the lack of deep business or leadership involvement in the BI portal’s development, IT constantly has to push the business side to use it.
• While valuing IT’s effort, the business team typically laments that the BI platform “just doesn’t quite fit”:
- It doesn’t quite fit the workflow for operations, so Business chafes at the perceived interruption to their daily/weekly/monthly/quarterly workflow.
- Business often says they appreciate the data in the warehouse and reports, but that the system doesn’t include everything they need, so it feels like “just another (albeit more sophisticated) place we have to go for data.”
- The business team finds it hard to see a connection between the data and any actions they should take.
- Once the portal is built, Business is slowed by IT’s development cycles.
A natural reaction at this point is that IT becomes frustrated. Specifically:
• IT laments that the platform isn’t used as much as it should be.
• In response to the business side’s complaints that the system doesn’t really give them exactly what they need, IT replies (sometimes in exasperation), “We can do anything they want, if only they would tell us.” While that’s true, the challenge at this step is that subject matter experts are rarely able to articulate exactly what they need unless there’s a highly iterative process that lets them experiment with different solutions.
• This leads to the IT team complaining that Business keeps changing its mind, so they keep chasing the solution. While that’s a fair complaint, it’s also a natural and logical consequence of relying on a bottom-up approach to defining requirements rather than a top-down methodology to establishing the key drivers of business success and discovering the metrics that best fit those drivers.
Chasing the solution is merely a symptom; it’s the failure to bring the business associates through a journey to discover what drives their business—and, thus, learn what the true key metrics are—that’s the root cause of the problem.
Partners, Not Antagonists
When the business team leads the BI project and IT acts as a partner to enable the desired capabilities, the whole experience looks and feels very different (and has a much higher success rate):
• The methodology has a naturally collaborative feel to it.
• Metrics come from a top-down assessment of business drivers. My team is a big fan of David Parmenter’s approach, outlined in his 2015 book Key Performance Indicators: Developing, Implementing and Using Winning KPIs, to determining metrics in this way. Briefly, Parmenter explains:
- A cross-functional team brainstorms a list of success factors, usually with the assistance of an experienced facilitator. These success factors (SFs) are reviewed and duplicates removed.
- The SFs are then prioritized to number no more than six to eight “critical success factors” (CSFs).
- The CSFs are broken down into their “aspects.” For example, a CSF stated as “to maximize rental revenue growth” could be broken up into aspects of occupancy, new rent growth, renewal rent growth, minimizing turn time, and so on.
- Metrics are chosen for each aspect and “key indicators” identified.
- IT can then begin data modeling to collect and store the necessary data at the appropriate granularity.
• The BI platform is dashboard instead of report driven.
• By putting the CSFs and key indicators front and center, the natural result is a focus on actionability.
• This approach has a much stronger tendency to democratize the data by creating a cross-functional coalition of BI champions.
This approach also has a completely different look and feel from the bottom-up method:
• Because the business team was involved from the start, and they learned and experienced things in small steps, they have a much better understanding of, and appreciation for, the BI process.
• Since the BI interface was designed by the business users, they not only can adopt it more quickly, but they also can now constantly pull for more functionality. They see how the BI tools help them in one area and proactively request more metrics and more functionality in other areas. Because these are areas in which they feel pain, they will adopt the next version of tools quickly, thus creating a virtual cycle.
• BI ends up integrated with the business culture:
- Designed collaboratively with them, the new culture fits their workflow.
- Parmenter’s approach is by definition aligned with the BI team’s critical success factors.
- By highlighting key indicators, the process drives action.
- With the democratization of the data, analysts in different corners of the company can continually use the platform for their own ad hoc analyses. Those analyses that prove most valuable then become proof-of-concept tools that later can be made into full-production functionality by IT—with the benefit that the business team has already vetted the content and its presentation.
• IT gets the credit it’s due. The business team relies on the platform, so IT’s role in this methodology is appreciated rather than resisted.
If this resonates with you, you’re probably asking, “Then why are so many projects led the suboptimal way? And what can we do to make sure we get it right?” We’ll explore those questions in part two of this three-part series of articles, coming later this month.
