By Jason Wood, Senior Consultant at Navigator
We hear about it all too often with IT transformation projects that involve Business Intelligence (BI) and Analytics. End users often don’t get what they expected and hoped for as far as visibility and access to data when they finally see the end product. What they heard in promised capabilities and envisioned in requirements gathering discussions does not line up with the reality of the final solution. Does this sound familiar to your organization? If so, then it may be time to re-visit your strategy for gathering BI and analytics requirements.
The success of IT projects often relies heavily on accurate and precise requirements. Requirements ultimately determine the functionality of the IT solution and where resources are spent to improve business processes and performance. While often similar in approach, the process for gathering requirements can vary across different projects and solutions. Specifically, we’ve found that business intelligence and data analytics solutions often require different requirements processes to obtain an optimal solution.
A Different Approach to Requirements
Large IT transformation projects often start by leveraging the capabilities of currently owned packaged software or with a goal of standardizing business processes into those commonly supported by market leading COTS solutions with some additional custom or bolt-on functionality. This is more common with ERP and other applications that support daily business operations.
When it comes to BI and analytics, requirements gathering is much more of an open book and welcomes creativity and subjectivity. Stated differently, it’s generally important for organizations to adopt best practices in their business operations. However, the information and insight needed to effectively and efficiently manage and grow is usually unique to each organization. Sure, there will be common information and reporting needed by all organizations, but having the information to take advantage of opportunities to differentiate and grow require skilled BI requirements and design. Adding to the challenge is that no two source system footprints look the same and a BI platform is generally comprised by many tools rather than a common single ERP or CRM system. For this reason, BI requirements gathering should be treated differently from traditional software application development. BI requirements should be gathered from a tool agnostic perspective, leveraging existing BI platform capabilities and approaches where possible, but not limited to what is delivered or what a specific tool is capable of.
Give The Users What They Really Need
Today’s BI and data analytics tools are very flexible and easily allow customization to form the solution to the needs of the business, instead of forming the needs of the business to a specific tool. Most BI and analytic requirements can be satisfied by more than one solution design approach. This allows the business to choose the solution design approach that best fits the business based on requirements, budget, resources, or other critical decision factors. Gone are the days of traditional data warehousing where a specific BI methodology was subscribed to and all requirements and design needed to fit that approach. When requirements are gathered around the business need and not a specific tool or technical methodology, the likelihood of the business to adopt and embrace the end product will increase immensely. Many organizations struggle to get buy-in from their stakeholders on enterprise BI initiatives and it often starts with approach and requirements. The BI team can often be prescriptive with requirements trying to steer them towards existing approaches and tools instead of conducting in-depth interviews and listening to what the actual information needs are for the business. Further, often BI projects launch without much of a requirements components at all, instead focusing on recreating existing reporting capabilities in a more modern technology. It’s critical that BI initiatives unlock new capabilities. They should focus on meeting today’s needs in a more efficient manner and providing self-service capabilities to answer tomorrow’s questions.
Break the Barrier Between Business and IT
At Navigator, we emphasize that requirements should continue to iterate and refine even after development starts. Most of the time, stakeholders do not know how to fully leverage the capabilities of a BI platform until they actually start seeing prototypes, which is why it is critical to keep the end users involved throughout the entire process. Projects tend to end up more costly and less successful when the BI team documents requirements up front and keeps stakeholders in the dark on what the end product will look like until it is too late. Developing rapid prototypes of the solution throughout the development process can go a long way in getting business buy in for the new BI solution. Involving stakeholders throughout the design and development process allows them to feel responsibility and accountability to see the project succeed. This will not only improve the chances of a successful project, but it will also improve governance by planting the seed for or extending a business intelligence competency center comprised of business users that will continue to support BI growth within the organization. However, getting this type of buy-in can be a challenge without the right approach and resources to effectively communicate between the business users and IT and help foster that relationship.
To successfully put this approach to BI requirements into action, it is critical to have the right resources to execute the methodology. It is a common mistake on projects that involve BI, reporting, and/or analytics to place either a business analyst without BI experience or a BI developer into the role of gathering analytic requirements. The right skill set for this role is somebody that understands business outcomes while also having the technical understanding of all phases of developing a BI solution including data, data relationships, and BI platform capabilities. This resource doesn’t have to know how to develop the end to end BI solution, but should be able to competently speak to each phase of development and understand how to architect a solution that best meets the needs of the business. These skills are in addition to the standard business analyst soft skills such as communication and facilitation. In total, these are the skills that make up a BI business analyst (BIBA).
This allows the BIBA to propose solution options, provide design recommendations, and explain challenges or limitations during the requirements gathering process. They also assist with effective communication between the business and IT throughout the entire development process. Leveraging a quality BIBA with these skills is crucial to building a solution that meets or exceeds the needs of the business, has business buy in and ultimately helps to ensure a successful project.
This Is The Navigator Way
Whether your project involves traditional enterprise data warehousing, big data, or visual analytics, BI requirements should always be treated with a different focus and methodology than traditional software application development requirements. We pride ourselves on understanding your information needs and communicating what’s possible in modern BI platforms before recommending and designing a solution. At Navigator, we leverage experienced BIBAs on our BI projects, with the skills outlined earlier, to continuously work with stakeholders, unlock the full capabilities of your BI platform, gain buy in, and work to exceed your expectations of the BI solution. This approach to BI requirements has been the major reason for our many successful BI projects, and we are excited to continue to practice this methodology for future clients that are facing similar challenges.