BI Project Success

• By Graham Tracey, James Riha
• 02/01/09

There is no one-size-fits-all strategy for business intelligence project management. Instead, smart BI project managers will exploit any number of approaches during a single project lifecycle.

MANAGING BUSINESS INTELLIGENCE (BI) projects in higher education is a formidable responsibility that challenges even the most experienced technical project managers. Data source dependencies, uncertain data quality, changing information requirements, and urgency for actionable information are but a few examples among the multitude of challenges. What's more, the many kinds of BI projects, ranging from strategic to operational, add to the complexities. And then, of course, there are the various technologies and skill sets involved in these projects-- ERP integration, data warehouse design, OLAP cube design and system performance, data modeling, governance, predictive analytics-- which compound the challenges. The bottom line is that, currently, there simply is no one-size-fits-all approach to BI project management. Instead, BI project managers must learn how to choose from among the traditional waterfall models, to the more adaptive rapid prototyping methodologies, as well as other project management methodologies and tactics that fit the organizational culture, match the current skill sets of the BI staff, and are appropriate for the project size and scope. More importantly, they will probably need to move back and forth among various approaches during the project lifecycle-- say, across project planning, execution, monitoring, scope control, completion, and postproject maintenance and enhancements.

What's more, BI project managers often struggle with a variety of enterprise organizational issues that chronically inhibit success. Some of these issues are technical; many are not. Always at the core are the cultural and people challenges. While not unique to BI projects, issues of culture and people do seem to be particularly problematic due to the variety of individuals who necessarily are involved. Certainly, business analysts, end users, technologists, and decision-makers all must have a voice in these projects if they are going to be successful. Yet, with these diverse roles and those who hold them, the challenges are many. Struggles with a changing way of doing business, unclear project roles and responsibilities, lack of agreement on key decisions, finger-pointing over findings-- all of these challenges can lead to an unpredictable project outcome.

Oklahoma City Community College faced many of these challenges as administrators and technologists there embarked upon a journey into enterprise business intelligence. In little over a year, however, the college has gone from a mostly manual and ad hoc reporting system, to the development and deployment of a data warehouse and online analytical reporting system delivered through an internal portal the college calls the Institutional Intelligence (I2) portal. Importantly, to reach this milestone, the college laid out several focused projects, each designed to move the institution farther along the BI continuum. Along the way, both project manager and project team members faced hurdles, but they adjusted and learned to focus on outcomes and results instead of rules and hierarchical roles. Here's how they did it.

Develop a Vision

First, OCCC spent time formulating a vision for a BI program that would be ongoing and would contribute to developing a "culture of evidence." This overall "umbrella" program, I2, served as the framework from which all BI projects would stem. The program called for improved information quality, reduced manual information compilation and distribution, and decision-making through data. Specific goals and objectives were developed that were then used as guidance for subsequent projects. Laying this framework helped in discussions of priority with institutional leadership, and led to a clear roadmap of projects as the program progressed.

Self-Organizing Teams

OCCC's project leaders abandoned the traditional higher education team approach that involves a committee of people from across the organization with an unclear stake in the outcome of such an initiative. Instead, to form the core I2 project team, they built a cross-functional team of only seven professionals from across the organization: two from information technology, three from institutional research, and two who represented key stakeholders. Collectively, the team had an intricate knowledge of the goals, data challenges, and information needs of the end users. Given that neither the project managers nor project team members would be released from their everyday roles and responsibilities, the team needed to become "self-organizing." In other words, team members needed to assign tasks to each other, coordinate and review each other's work artifacts, collaborate on project activities, make project-related decisions (together), and take on another team member's tasks when necessary.

While the project managers still had a role in guiding the team, instead of being "task masters" it was more important for the project managers to run interference on behalf of the team, when issues were difficult to resolve or political in nature. Both the team setup and approach were new to OCCC, and as one might expect, the changes were not without glitches at the start. Over time, however, the structure resulted in increased ownership and trust among the teammates.

The I2 team has since evolved to have a high degree of credibility within the institution, and it conducts regular meetings with representatives from across each of the business units to communicate project status, gain feedback on work products, and gather input on future BI initiatives.

Rapid Prototyping

One common mistake many project managers make is that they wait until the project is nearly complete before unveiling it to stakeholders. This is particularly problematic for enterprise BI projects, as managing data and information across the enterprise is more difficult and takes more effort, coordination, and resources than delivering silo shadow systems and point solutions. OCCC combated this by employing a system of rapid prototyping so that the working product could be reviewed and modified over time throughout the project, and not simply at the end. This technique helped to prevent projects from slipping or falling out of scope, as it provided more time to make changes based on user feedback. Certainly, there were setbacks, but rationalizing redundant data and inconsistent business rules in public at the end of the project would absolutely prove embarrassing, and rapid prototyping was one way to minimize the chances of building the wrong solution.

Get the End User Involved

A prerequisite for the rapid prototyping approach is the participation of intended end users on critical project activities. BI projects require much more involvement by end users than do most other projects. Traditionally, stakeholders participate in requirements-gathering interviews, project reviews, and user-acceptance testing. Other than that, the technical developers do all the development work with no involvement from the users. But, besides creating an "us versus them" atmosphere, this limited degree of involvement forces enterprise BI developers to make assumptions that often lead to unsatisfactory results. This is bad enough on projects with well-defined scopes and deliverables, but on ill-defined enterprise BI projects, where scopes and deliverables are often a moving target, it can be catastrophic. Just think of how many times we hear that business intelligence projects are late, over budget, too costly, too complicated, and that the deliverables don't meet end users' expectations and are not utilized.

At OCCC, throughout the life of each BI project, the core project team regularly involved stakeholders from across the institution. From the start, key end users who might be impacted by the project deliverables were identified from each area of the college. Approximately 15 to 20 people formed this larger BI review team and were briefed regularly on the project status. When critical enterprise issues needed to be resolved, this review team served as a fount of business knowledge and a sounding board for the core project team. Most importantly, though, the review team members were provided with structured walkthroughs and access to the evolving prototypes, to allow them to provide direct feedback and validate the data they were seeing. This not only helped to improve the quality of the final deliverable, but also increased the ownership stake of the actual end users themselves.

Plan-- and Be Nimble

In the end, a healthy and sustainable BI initiative (i.e., data warehouse, data marts, cubes, reports, dashboards, etc.) doesn't just happen; it requires careful planning from the outset. Yet, most importantly, it is how projects are defined and managed that will have a significant impact on the initiative's overall success. Specifically, successful BI project management is about flexibility, skill in interweaving methodologies, and actively engaging stakeholders. Attempting to use a single methodology simply will not work. The traditional linear "waterfall" and "big bang" methodologies, with their rigid order and highly structured teams, are just not agile enough or fast enough to meet the evolving information needs of today's decision-makers. OCCC recognized the need to be more nimble as an organization, in order to maximize its investment in enterprise business intelligence.

Clearly, an approach that incorporates a focused, self-organizing team; rapid prototyping of work products; and a high degree of end user participation throughout, will likely yield more rapid results for your institution while at the same time, increase ownership and trust in the output.