Supreme Court Justice Potter Stewart famously said about obscenity, "I know it when I see it". This often seems to be the case with many credit union decision makers when asked to define Business Intelligence (BI) requirements.
Consider this common scenario: an innovative credit union executive champions the BI concept. The executive points out all the flaws in organization’s current reporting and analytics. Then, showing examples of how BI is revolutionizing performance in other industries, secures budget dollars for a BI initiative.
The BI project is kicked off with great expectations. The first step is to define requirements for improved reporting and analytics. Analysts fan out into the business units to gather requirements only to find that the producers and users of current reporting and analytics are hard-pressed to define solid requirements. The project stalls because the expected “demand” does not materialize. The “wins” resulting from the project are fewer than predicted and the entire effort is judged to be a disappointment.
Was the promise of BI false? Not really. The problem was the way the project was managed.
Credit unions undertaking such projects need to understand a unique characteristic of Business Intelligence: users know they need improved reporting and analytics but often have a difficult time defining what they want.
To avoid the requirements “trap”, credit unions need to consider these three best BI project management practices.
#1 - Avoid the “Big Bang”
Trying to “do it all at once” is simply too risky. Most credit unions are new to BI. Breaking the big project into smaller pieces is a better strategy to maximize organizational knowledge about BI.
Choose an area generally acknowledged to be a “pain point” and is relatively well-understood in terms of what needs to be done. Creating a first project that properly balances these two criteria will allow the credit union not only take on a less difficult requirements challenge. It will also increase the chance of achieving a “win” that will support further funding.
#2 – All the Data
Once a “right-sized” project is defined, it is critical that as much source system data be made available as possible. The usual mechanism for this is extracting source data and loading it into an Operational Data Store (ODS) that is easily accessed by the BI system. The typical process simply replicates the source system tables in the ODS environment.
Providing as much source data as possible in the ODS at the outset of the project creates a foundation for the rest of the requirements process. It reduces the risk that re-work will be necessary to bring more data into the ODS later in the project.
While bringing in “all the data” can seem like a large expectation, the project “chunking” strategy described in practice #1 will help to keep the volume of data to a manageable amount.
#3 - Prototype Power
Even with a smaller project, gathering adequate requirements can still be a problem. To support users in this process, experienced BI project managers build in multiple iterations of requirements gathering. For example, rather than trying to define the perfect report, users should be encouraged to start by defining a minimal set of requirements.
As quickly as possible, these requirements are translated into a rough report to be reviewed by the users. With a tangible artifact to evaluate, they are encouraged to specify corrections and enhancements that serve as input to the next version of the report. This practice is “I Know It When I See It” in action.
This iterative process continues until the project manager negotiates a “good enough” decision with users and sponsors to ensure project timelines and budget are not exceeded.
Such prototyping is supported by practice #2. The probability that previously undiscovered reporting requirements can be quickly prototyped is increased because most, if not all, source data is available.
. . .
It seems illogical that important BI initiatives should so often start out with a lack of clear requirements. Yet, experienced professionals know how to manage this unique characteristic using these three best practices to decrease risk and thereby increase the probability of project success.