We hear lots of people these days talking about prototyping with Power BI. It sounds kind of cool. But what exactly is it? What are we trying to accomplish with it and how do we support the effort?

Prototyping can be defined as the process of sampling an idea by creating a functional mockup which can inform the solution scope and viability of an investment. In the world of Power BI, we can prototype in two main forms:

  • Strategic prototyping: Power BI efforts that inform blueprinting of IT-driven projects with a long-term vision. In other words, we can use Power BI to “sample” reports and actively perform requirement discovery on behalf of IT developers to get a better idea of what needs to be built as a production asset.
  • Tactical prototyping: Involves exploratory attempts to test a short-term solution, satisfying a request typically driven by a business owner and outside of IT development cycles.

The need for prototyping arises as users don’t always know what they want. When asked which data a report should contain, it is typical to hear users answer: “I don’t know” or “all the data.” Unfortunately, neither of these answers give enough guidance to walk on solid ground when developing production-ready reports. That is why we talk about requirement discovery instead of requirement gathering.

In a general sense, we prototype the report interface (friendliness and usability), the data model, and calculated business logic, as well as the data completeness and readiness. Structured prototyping sessions – as a phase of the development cycle – can be scheduled and actively managed to ensure the discovery process is moving forward.

During prototyping, we have tolerance for lack of complete adherence to best practices – given the prototype itself is not a production-ready asset. We also see a high amount of “throw-away” work where, iteratively, we fail quickly and cheaply to realize gain.

Companies I talk to are interested in the idea of prototyping, however, they often will ask: “Which team should lead the prototyping effort and how?”

In a recent blog post, I mentioned how IT departments should create what Gartner calls a “Mode 2” team to increase the success of Power BI deployments. This team has a narrow focus: short-term solutions and exploratory efforts. Sound a lot like prototyping? Yes! To efficiently discover requirements, companies need to build a team structure in which prototyping can take place.

 “Mode 2” teams can deliver the most value when:

  • They are a full-time, dedicated team which is separate from the Enterprise BI team. By designating a team to perform prototyping duties as a full-time job, this team is legitimized and can actively pursue short-term goals without any sense of guilt. In contrast, if you only add up the prototyping duties to a traditional IT team focused in long-term solutions (“Mode 1” team, as per Gartner), prototyping may suffer – bogged down by a need to switch focus from delivering value as quickly as possible, to applying all practices and procedures applicable to traditional IT development. Remember, we prototype because we don’t yet fully know the requirements, so those teams need a lot of flexibility.
  • There is a clear agreement about what is meant by “short-term solution.” With this agreement, it becomes easier to channel requests to either Mode 1 or Mode 2 teams. A large manufacturing company I consulted recently decided to define short-term solutions as any project that has an estimated development time frame of less than 3 weeks, including interviewing Subject Matter Experts (SME) and iterating.
  • Even with a short-term focus, they belong to the IT organization. Although many business Super Users also perform prototyping functions, their focus is not the same (business Super Users are those that can perform Power BI data prep, modeling and reporting independently).

    Both groups can be SMEs and technically savvy, however, business Super Users care about solving the problem whereas Mode 2 team members care about the approach to solving the problem. As an example, Mode 2 team members might ask “are we following good visualization practices?” or “Did we leverage any workable DAX pattern?” etc.

    Ultimately, the Mode 2 team is a conduit for work that can end up being adopted as Corporate BI, hence they are on the look-out for opportunities for extensibility, maintainability, and conformity to standards. However, given their focus is to “sample” solutions, they are normally willing to purposefully step away from recommended patterns to deliver value quickly while understanding the trade-offs.

    Notice that under this context, Mode 2 teams are in alignment with business Super Users, which are sometimes negatively referred to as Shadow IT. Given their shared interest, their organization can benefit from rewarding their collaboration over short-term solutions. This offloads the Mode 1 team from prototyping efforts, allowing them to collaborate with business leaders to work on long-term solutions.

  • There is an assigned Team Leader who can help prioritize. As with any team, a leader can help establish priorities. It is common to see business users get excited after a tactical prototype has been developed. This excitement often helps build a healthy queue of prototyping requests. Keep in mind that tactical prototypes are not yet solutions until a business Super User adopts them (and ownership is transferred – see below).
  • Finally – they must be structured to avoid solution ownership. This is a critical piece of the puzzle. Owning solutions signify they would also provide technical support and comply to service level agreements. That, again, would bog them down in a direction that decreases agility.

    Instead, they must constantly look to push prototypes to either business or IT adopters. When Mode 1 IT adopts the prototype, it transforms into a blueprint for development. When a business Super User adopts the prototype, it becomes a tactical solution.

    In this way, a structured process can squeeze the most value out of prototyping efforts to influence Corporate BI deployments, making them more accurate, or Self-Service BI deployments to deliver quick wins.

Given Power BI Mode 2 teams play such a central role in the ownership transfer process (their work ultimately gets adopted by other teams), they can also assume monitoring functions, helping to track usage and create adoption strategies. To be effective, they need access to Power BI audit logs to understand consumption and sharing patterns.

As you may expect, their continuous activity would deepen their expertise in Power BI. With this deep technical knowledge and focus on short-terms wins, this team becomes the center of Power BI evangelization.

If you are looking to learn more about Power BI, or want to address how to effectively take advantage of the tool for your organization, contact BlueGranite today!