The BI development lifecycle

Behind every functional dashboard, crisp report and modern interface is a development process. Your credit union participates in the data development lifecycle every single day, regardless of whether it’s considered a formal process. We’re going to talk extensively about the BI development lifecycle, how it may look today at your CU, and the best practices you can implement to get the most value and longevity from your data requests.

Request/requirements gathering

The first stage is typically the most obvious and yet most neglected. Business users need data around a given topic to be able to make informed decisions and will engage an analyst to procure the data. Many credit unions have a process that can include a ticketing platform, with established SLAs, escalation flags, and more; but many credit unions still rely upon a message, e-mail or a knock on the office door.

In both cases, you and your analyst may be likely to overlook both the importance of this step and getting it right. While some data requests can be cut and dry, we would caution you against treating them as such. The lack of specificity in this step can create a “RE: RE: RE: RE: RE: Your Data Extract” exchange with multiple points of clarification before a clean data file or robust dashboard can be delivered.

Best practices here can be initiated by either the business user or the data user! If you are the data expert, urge your business team to help you answer the following questions:

• Who is going to be utilizing this data and how will they be consuming it?
• At what frequency will this data be needed?
• What strategic goal does this contribute to?

If you are the business user, here are some questions you can ask to drive better results from your request:

• Do we have any existing data resources that address a similar problem?
• Do we have access to the data sources needed to address our questions?
• How can we drive data accuracy from the source systems involved?

The chief recommendation here would be to grab 15 minutes with your counterpart to discuss the request or an hour for project level engagements. E-mails and tickets often fail to grasp the nuance of any given request. Allow the data expert to ask lots of questions before heading to the query.

Querying, modeling & visualization

The second stage of any data request is typically owned by a data expert at your CU. This can involve landing data sources, querying existing tables, modeling and often visualizing the data in a report or dashboard that can be used on an ongoing basis. The variety of platforms can change how the work is completed, but below are a few platform-agnostic best practices.

1. Use relative date parameters whenever possible – Fixed date parameters such as “01/01/2024 – 12/31/2024” are often simpler to code but introduce fragility to query and will create a constant stream of maintenance work to keep queries running.
2. Move business logic “upstream” whenever possible – Departments often share specific logic filters that affect their reports. By moving that logic into relevant views or tables, you save your user time that would be spent filtering reports themselves (Ex. Your collection team does not collect on 1^st lien mortgages; filter them from the results “upstream”).
3. Avoid “Ugly Ducklings” when designing visuals – Visuals should enhance your users’ ability to “see” the data. If your visuals are too complex or abstract, you reduce their effectiveness. Stick to the “Ten Second Rule:” If your visual takes more than 10 seconds to understand, it is not a good visual. Choose a different graph type, or reduce the data being shown to tell an obvious story.

If you’re a business user, you can contribute to this step by being clear in the Requirements Gathering stage about exactly what you are looking for and what data you may want included or excluded. Be willing to share your vision and cooperate with the data user to build something robust while staying feasible.

Testing/user acceptance

The third stage of the BI Development Lifecycle is Testing or User Acceptance. This stage varies in complexity based on the data request in question. If the request is a one-time CSV report, the testing period could be a simple as “Thanks for sending!” so we’ll look at a more complex data artifact, such as a strategic dashboard.

If you are the data expert, we recommend the following steps to ensure you are getting relevant feedback in a timely manner:

1. Communicate directly with the testing group – You may often be working with a specific user, but the dashboard will be used by an entire department. Identify a test group with the help of the relevant managers and communicate directly with them about the dashboard’s availability and upgrades as they happen.
2. Give a specific timeframe – If you do not specify a feedback time frame you’ll be getting “I just noticed…” e-mails months after the development is done. Coordinate with the relevant managers to understand what a reasonable turnaround time is. Recommend a week at a time for each feedback period.
3. Watch utilization closely – Most platforms have pre-built mechanisms for tracking utilization. Review utilization to understand if your data artifact is being adopted. If it is not, this may indicate that the data does not meet the needs of the team. Review the requirements from Stage 1 and connect with the original requesters to understand if the report or dashboard fails to answer the original questions.

Adoption & maintenance

The final stage of any BI Development Lifecycle is the ongoing adoption and maintenance phase. At this point, users of the artifact should be steadily using the report or dashboard and getting value from it! This stage is often the defining differentiation between credit unions with a BI team and credit unions with a BI strategy. Upon publishing new reports, your data team should be taking the following steps to maintain relevancy and usability.

1. Opt for role-based permissions – Limiting access is critical for a healthy data governance plan, but granting access on a request basis becomes a tedious time-suck for all teams. Opt instead for role-based permissions to streamline easy and appropriate access.
2. Plan for retirement – The most overlooked step in a healthy BI Development Lifecycle is a retirement cycle. If your data team only ever builds but does not retire, your CU will end up with an unsustainable volume of data artifacts that can only be addressed by increasing FTE. Set up annual or semi-annual review periods to look at under-utilized dashboards; if a report cannot be justified, it either needs to be road-mapped for an upgrade or for retirement.

Whether your credit union has a formalized process around BI Development, or is just getting started, use the best practices here to move your CU forward using data. Connect with a Trellance advisor for more content around planning and succeeding with business intelligence!