MVP in BI projects

285353694_e7a3c39774_o

Nowadays in digital transformation fever where changes play out at increasing speed, it is essential to get quick answers on whether investments are going in the right direction or not.

In this context, the “minimun viable product” (MVP) raises to release a product that meets a sufficient specifications to provide value to the end user as soon as possible.

The benefits are obvious:

  • Match the expectations of users with the product delivered using a minimum investment
  • Learn from this “feedback” for the following product versions
  • Reduce or eliminate non-essential functions or at least those in which the cost / benefit ratio is not balanced

MVP, since coming from the startup world where product definition, customers and ROI are mostly uncertain, applies naturally in BI projects because the demand for information is highly dynamic: KPIs changes, analysis dimension changes, stakesholder changes, information delivery changes …. It would be easier to name what always remains: changes itself.

how-to-build-a-minimum-viable-product

Although these agile approaches are becoming more common, narrow the scope of the projects is one of the major problems in large companies, especially in public sector, and even more in Spain, the county where the expression “by the way…” fits better:

Absurd and common real situations against MVP:

  • “Well, by the way … could you create the whole data model covering all possible cases” when only a specific part of the scope is defined (taken to the extreme once I saw 100 fields in tables named type “GenericColumn1 … .100” just in case they are needed ….)
  • “Well, by the way… could you create that statistic report as I remember someone once asked me for it”.
  • And the great classic: “Make me a few more reports as I have to spend the whole budget, otherwise next year It would be reduced.” ??

Previous situations are “extreme” cases usually happening in those companies where “agile”, “digital disruption”, common sense ?, are still in progress to be implemented or are directly anchored to the past (and doomed to disaster)

Current situation (crisis) is setting a more logical criteria when defining the projects, howecer, MVP is not always easyly  understandable and correctly managed:

MVP

A very typical situation is the replacement of the old BI with a new one, having many types of users, and even customers with different needs on the same BI. In those cases Product Owner is critical because the backlog will be very wide and prioritizing the stories will not always be easy even with the help of some techniques. The key point here is to manage end customer expectations and arrange a group of early adopters to facilitate the iterative process of construction.

Some key questions you should ask when reviewing the functionality of your MVP:

  • Is this functionality key to continue the evolution of the project (map units)?
  • What is the frequency of use of this functionality?
  • How many and what kind of users is demanding this functionality?
  • Are we sure this functionality has a high value for the end user?
  • Which is the impact in case not this functionality is not included in the MVP?

And you, do you also suffer in silence the definition of your MVPs?

Anuncios

Un comentario en “MVP in BI projects

  1. Pingback: Has B.I. consultancy failed? | Agile Business Intelligence

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s