Last month, we discussed two different ways in which business intelligence (BI) projects are run in a typical multifamily housing operation. We described a bottom-up, report-driven, IT-led approach and compared it with a top-down, dashboard-driven, business-led approach. The latter clearly led to higher adoption, better business satisfaction, and more appreciation and respect for the effort and intellect of the IT team.
We also discussed the unfortunate fact that the majority of projects my team sees fall into the bottom-up category. This left us wondering why so many projects follow this suboptimal path.
With all the advantages business leaders can lend to IT projects, the obvious question that comes to mind is, why are so many BI projects technology-led? Most companies are led by smart executives who want to do the right thing, so why do so many choose an approach almost doomed to fail?
Culture Clash
The primary issue behind project failure in this situation is a fundamental culture gap between IT and business. The first, and perhaps biggest, challenge is that few businesspeople really understand and can “speak” IT. We’ve worked with many clients who have great operators and finance people but few (often no one) outside of IT who can talk technology. As a result, IT teams often experience frustration on large projects involving business operations.
This frustration has led to an unstated lack of trust among the IT team in the business side. Don’t get this point wrong—it’s not that IT doesn’t respect what the businesspeople do; it’s just that they don’t trust the business team to lead a project as complex and technology-oriented as BI.
Conversely, the IT folks (particularly the chief information officer, or CIO) honestly believe they know business. We’ve run into many CIOs who believe this. The reality is, however, that no matter how much the CIOs think they know about business, they simply can’t fully understand what the business process entails if they don’t engage the folks doing the business on a daily basis.
In defense of CIOs, the world is littered with projects that got out of control due to “scope creep”; and it’s generally the business side that causes said scope creep. When that happens, it’s rarely the business side that takes the blame—it’s IT; and CIOs can lose their jobs if the failure is big and occurs in a large program like BI. So we shouldn’t be surprised that CIOs exercise a certain degree of control to prevent BI projects from growing too large too quickly.
Putting the Software Before the Process
Another issue that can lead to a BI program’s failure is that software salespeople generally peddle software solutions: They get rewarded for making sales—and making them now. So issues like project governance and change management, particularly if they introduce two- to four-month–long pre-project plans in place of the software implementation, are almost never discussed.
Rather, salespeople push the capabilities of their software, and C-suite executives make the mistake of thinking said functionality will solve their problems. However, business intelligence entails solving, first and foremost, business problems, not technology problems. Sure, BI is technology-enabled; that’s a necessary—but insufficient¬—criterion for success. Yet, you’ll rarely hear that coming from any of the main software vendors in this space.
Perniciously, the fact that so many people implement BI with a bottom-up methodology led by the IT team becomes a reason in itself that it gets done this way. Since “everyone does it,” few are speaking up for the more successful approach—a top-down analysis of need led by the business team.
Blending Red and Blue
To ensure a BI program’s success, first and foremost, companies need to hire for analytic success.
If you think metaphorically of business associates as “blue” people and IT folks as “red” people, then what is clearly needed is more “purple” people—those who can span the boundary between the two. These people are out there, but they’re not always easy to find. Their current employers value them, so they aren’t often looking for new jobs.
To find purple people:
• At a minimum, bring in facilitators or consultants to fill the short-term need for purple people. People with experience in the Parmenter and Kimball methodologies (see below), for example, can help your business team members learn to be more articulate about their needs while simultaneously assisting your IT team in reducing the risks involved in executing a BI program. Consultants can sometimes force the provocative and constructive conversations that are hard to initiate without a third-party facilitator.
• Long term, search within your company for people who can span the boundary, and, when hiring new employees, make a conscious effort to recruit people with talents and skills in both business and IT.
Second, use the well-established approaches (such as the Parmenter approachto identifying critical success factors and key performance indicators, discussed in last month’s article, or the Kimball methodology for data modeling) to help the business associates state their needs and learn more how to “speak IT.” Implement a detailed approach that emphasizes short, small and accretive, iterative steps rather than a long and large “requirements determined up front” swing for the fences.
Finally, build on the collaborative approach by creating a “BI Center of Excellence.” This isn’t a new organization with a new head count and new bureaucracy; rather, it’s a loose coalition of BI stakeholders across the business units who are key expert users and IT support experts who work together to share best practices, define new metrics as they’re needed, and generally support the use and advancement of the BI platform.
Once the business needs are determined, trust your IT team to make the right technology decisions. With the right goal now in mind, they can analyze the vast array of BI offerings out there and use their assessment and negotiation skills to choose the best suite of products for the best terms.
Now that we understand the options we have for leading and governing a BI project, and we understand why so many BI projects are initiated suboptimally and what to do about it, the final thing we need to do before instituting a BI program is develop decision-making criteria for choosing the technology platform we want to use for our BI.
That will be the subject of the third, and last, part of this series of articles, coming next month.
