Analytics Methodology & implementation

When dealing with Performance Management (PM), Data Warehousing (DW), or Business Intelligence (BI) in general, it is important to acknowledge that all three of them are everlasting journeys. It doesn't stop after deploying "a cube to a bunch of end-users or at least it shouldn't stop there.

Early stages of Business Intelligence (BI) and Performance Management (PM)

If you just started in Business Intelligence or Performance Management you most likely will deliver some cubes or reports to a maybe not yet completely defined group of business users. Maybe you even will publish some documentation or extra guidelines as well. Then questions start coming back to you concerning support the need for a small extension to the solution built or the need for a completely new cube or data model starts to grow. Maybe you need to bring in some external help. Possibly different solutions are being built at the same time. But how are you going to deal with that tsunami of changing needs, solutions, and projects? Especially if the teams that need to deliver the solution are mixed between internal and external resources, themselves also not necessarily always the same companies and individuals.
In the end, what is needed here is a repeatable method to deliver BI successfully; a PM or BI methodology, which defines what is done and how it should be done in a consistent, documented, and repeatable way.

But how should you kick off your methodology definition and implementation?

Evaluating the current approach

The first thing to do is to brace yourself and have a very critical look at the current way of working.
Start by making a detailed inventory of things you do when creating a BI or PM solution;

  • Which steps do you take and in which order?
  • Which deliverables do you produce?
  • Which roles are being catered for?
  • Which activities are executed?
  • Which technology is used when & why?
  • Which standards have been defined?

Based on this inventory, you need to pinpoint what works fine and what doesn't work and the reasons why.

  • What do you miss?
  • Who do you miss in terms of stakeholders?
  • What is the perception of the business users?
  • How are they involved?
  • How is communication on (progress of) projects being done?
  • How do you monitor the usage of the solution?
  • How are the requirements assembled, used, and verified at the project end?

Defining the "As Is" and "To Be" states

When we have a correct view of the "As Is" situation, next we need to define the preferred "To Be" situation. Where would we like to get and at which moment in time? From that, we can finally draw the deltas and define a realistic roadmap, split up into feasible parts.

Tailoring methodology to BI, DW, and PM

When we define a methodology we must tailor the roles, activities, and deliverables to BI, DW, or PM for that matter. We need to acknowledge that BI and PM for example require solution deliverables to be ready in 2- or 3-months resulting in equivalent iterations. We also need to make sure that the chosen method splits the work into feasible phases, which could look like the following:

  • Strategy & Planning: Scope of what needs to be defined, by when, by whom, by what?
  • Solution outline: Definition of the solution details that should be built (conceptual data model, report design ...)
  • Design: Design of the solution (logical data model, source-2-target mappings )
  • Build: Building the solution & technical testing
  • Test: Business testing and acceptation
  • Deliver: Deployment of the solution
  • Act: Follow up on the solution is accepted and used within the organization

Each of the phases should come with a corresponding milestone. Of course, you could use an established methodology such as element61's elementary methodology. But always make sure that you tailor the method to your organization and its specific situation.

Defining roles, activities, and deliverables

For each of the phases which are defined, a specific set of activities & deliverables need to be defined. Which activities need to be executed in the design phase for example and who will take ownership of the tasks or who needs to be informed? A RACI (Responsible, Accountable, must be Consulted, must be Informed) can help in describing the participation of the various roles in completing the tasks. For each activity also a reasonable estimate of time required should be given. All these different components should lead to a project plan that is well-considered and ready to be executed.

Consistency and reusability

For the sake of consistency and to focus on the essential bits it is advised to define reusable templates and corresponding guidelines for the required deliverables. Here a distinction needs to be made between general project deliverables such as an "issue log" and "risk log" and BI-specific deliverables, such as a data model. Another distinction could be that certain deliverables need to be delivered within each iteration, whereas other deliverables only need to be delivered once initially such as "naming conventions" for example. Together with the project plan, these deliverables and standards will guarantee that both internal & external people working on the solution use the same approach. In the end, for example, what you do not want is two project teams ending up with two different error-handling mechanisms that can't be integrated.

Setting priorities and defining the maturity model

After defining the phases, activities, deliverables, ownership, etc. it is time to set the right priorities. You will not move from your current way of working to your ideal scenarios overnight. In the end, it is still about delivering solutions to business users and the usage of a well-defined method is not an aim by itself. Therefore it is important to define a kind of maturity model in which the "As Is" & the "To Be" situations are situated at both ends of the spectrum in between several intermediate levels or milestones depending on the overall timeline. The first milestone should cater to the most important and/or urgent deliverables, templates or activities. Here it is important to understand the levels or milestones that need to be crossed and to grasp what that means in terms of time required to get there, people involved, process changes, technology, cost & benefits.

Conclusion

When taking on the journey of PM, DW, or BI, it is best practice to establish a repeatable method with all the essential ingredients for success.

This can only be achieved by properly tackling all the issues and relying on our well-defined methodology.

Contact Us for more information

element61 can guide you in defining and implementing the right approach to the method that is best tailored to your organization and your specific needs, starting from the work we already have done in building out our own BI, PM & DW methodology elementary.

Contact Us for more information on the creation of a BI methodology or with your specific request!