Essential Thinking for BI Requirements

In a recent TDWI interview, Jonathan Geiger, executive VP of Intelligent Solutions Inc, discussed how to improve the process of requirements gathering for BI projects.  Several things immediately stood out from the interview as his suggestions were quite consistent with the methodology and technology at Kalido.

Here are three examples:

  • Listen when the business user is talking
  • A prototype is one method of capturing immediate needs while providing yet another avenue to discover additional requirements
  • Requirements change throughout the process

Let’s explore each of these recommendations in more detail.

Listen to the business

Understanding the problem is the first step in creating a solution – perhaps an old adage but it definitely holds true in BI implementations. Not only is this understanding a critical step in a successful implementation but it is also a cornerstone for productive customer relationships. So often, BI implementation teams take a data-centric approach to solving a problem; when in fact, the solution should be business-centric. IT organizations tend to focus more on how the data should be stored than how the data is to be consumed and in-turn acted upon. To Jonathan’s point, it also takes experience and a special skill set to maintain a proper dialog with the business.


Working prototypes not only materialize business requirements but they also measure the current level of understanding of the business problem by the design team. On top of that, the prototype gives the business an opportunity to validate rules and identify gaps. These prototypes are not perfect as there will be gaps – the key is to understand and verify as to why these gaps exist. Prototype architectures should also stay simple as they do not require extensive visualization or end-to-end processing – these are considered ‘build’ activities that are more related to delivery than to the solution itself.

Embrace change

Scope creep is a natural part of the process when creating a BI solution. Most conventional delivery teams tend to push back on change when in reality, managing the scope creep might be more effective in the long run. Everyone will be much happier in the end when you deliver true business value. As mentioned previously, leveraging a prototype brings the implementation team’s understanding to life – and the same for the business. With tangible aspects of the solution in-hand, the business can identify the necessary adjustments and any enhancements while the project is still in-flux. Think of building a house. If the first ‘iteration’ of the project focuses on the framing – it is much easier and cheaper to add a closet during this phase than after all the walls, trim work and windows are in-place. And the homeowner (in this case, the business) will be much happier in the end. Granted there will be additional cost but the overall cost of delivery is still much lower as changes are identified earlier in the process rather than later during final testing and deployment.

Putting it all together – the Kalido Approach

Our implementation methodology (called the Kalido Approach) is just as critical to creating cost-effective BI solutions as our technology. For starters, two-way communication with the business is paramount in the Approach. To facilitate the requirements conversation, all Kalido technology is built around the Business Information Model – a top-down modeling approach designed to capture business context, validation rules and requirements. Our business models are quite easy for any business professional to understand after a few minutes of explanation. The business model is both the conduit for communication and the basis for capturing a solution framework. The beauty of it all is that our business models don’t just capture the concepts as content. The same business model drives Kalido automation to create all the underlying physical database structures. The Business Information Model along with Kalido automation enables and empowers implementation teams to quickly prototype and build a fast and cost-effective solution. With minimal time required between concept and prototype, these teams can quickly iterate upon the solution and review the results in-person with the business.

After the first draft of the business model has been drafted and agreed upon, the Kalido Approach moves on to a sequence of time-boxed iterations or prototyping sessions. Each iteration encompasses the entire solution, not just a subset. The objective of each iteration is to concentrate on the key business rules and not get sidetracked over exceptions. At the end of each iteration, the implementation team meets with the business to review the prototype and discuss what progress has been made. This prototype confirms an understanding of the business problem by the implementation team and the subsequent solution. The business has an opportunity during these sessions to interject any changes or refinements that can easily be incorporated at this early stage. Typical Kalido implementations may run anywhere from three to five iterations during an implementation. These iterations remain fairly short in duration ranging from two to five weeks so the business remains engaged and is still enthusiastic over the solution. After the iteration phase and business sign-off, the implementation can proceed to the Build phase in the Kalido Approach where the solution is ‘productionized’ or hardened for the end-to-end processing and automation.

In summary, effective methodology and technology must embrace at least three of the key concepts from Jonathan Geiger’s interview. Kalido business modeling, methodology and technology facilitate effective solution designs through fast prototyping and delivery, comprehensive dialog with the business, and effective capture and management of design change.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply