Prototyping with OBI
I’ve always felt that traditional approaches to developing BI content left much to be desired. Going through a traditional requirements approach with users to determine what reports should do, then spending a significant amount of time documenting them, only to finally show them to users after development and find out they aren’t happy with the result is something that I suspect most of you have encountered. I believe a better way to come to a solution that makes users happy is by starting right away with a Prototype. In this article I’ll discuss the generals of prototyping, and specifically how OBI is well suited to this approach.
What is Prototyping?
First off, what do I mean when I say Prototyping? How is it different than say a Pilot or a Proof-of-Concept? Well, I’m not going to answer the latter as I misuse these terms all the time and honestly it’s not that important. Nor am I going to cite a formal definition from some book.
What I am referring to is really more of a process/approach than a piece of software. I think there are a few key attributes on what I think a prototype is with respect to OBI:
- It is used to determine specific reporting requirements, techniques, and designs
- It is used instead of a traditional Requirements and Design approach
- You can begin prototyping almost immediately on your project
- It covers RPD, Reports and Dashboards
- It is throw-away
Let me briefly describe a prototyping experience I recently had with a customer on a large custom OBI project. My main OBI developer on the team and I went to a customer site with the knowledge of 8 reports that they mocked up in wireframes. The OBI developer set up a prototype on his notebook, and proceeded to build out a sample data set and then an OBI Prototype. As we went through the reports and began to discuss what the customer really wanted, we were able to push them towards much more of a BI solution. Instead of 8 self-contained reports, we were able to jointly craft a multi paged BI structure while working with the customer to determine exactly how the reports work and what the overall user experience would be. I was able to get at the root of what they were trying to accomplish with this system.
As it turned out, we increased the number of reports substantially, but due to the fact that we had been working on them for so long, I knew we could still complete them in the same amount of time. In the end we delivered a solution that was far better than what the customer had initially envisioned. And we did so knowing very well that all of the functionality could be accurately delivered in OBI as the customer had expected.
How Does Prototyping Work?
Let’s get into how you actually go about running a Prototyping effort before discussing the benefits and why you should do it.
Start with whatever input you have from your business customer, whether it’s an Excel mock-up, Wireframes, a PPT, a whiteboard diagram, or even an existing report in a legacy BI system. If you have none of these (pretty rare), you can still continue – it’s just a bit more difficult to get going.
Next, open up MS Access and start making some tables and put some data in them. Start thinking along the lines of your main entities and how they might fit into a Star Schema model. I prefer Access for a variety of reasons, but primarily because the product is everywhere, is lightweight, allows for easy table design and data entry, can do some data manipulation, and is SQL based. Others prefer Excel, but to me Access is far faster to use and debug. I wouldn’t bother too much with a more powerful database server – they are too much effort to make changes to tables and edit data. You simply can’t match Access’s speed for all of the changes you are going to make, and trust me you will be making a lot of them. Plan on this being a highly dynamic process where the tables you start with barely resemble the final tables.
When you think you have some of the base data in Access, then map it to OBI. Don’t go crazy here – get the basics going that you think you need to start producing something. Then move on to Answers and even dashboards and start building some reports. Your initial goal is to get something back to the end users as soon as possible – you want a straw-man to show them.
Once you have something to review with them, you’ll get into a repeatable cycle until you’ve fleshed out nearly everything you need:
- Show users what you’ve done and how the reports/dashboards work during an interactive session. Get their immediate feedback. If they suggest a different way, then make note of it, and tell them you’ll get back to them with the next version of the prototype. You might be able to make the change in front of their eyes for them.
- Go off and work on what you discussed – do what you have to do in order to make the adjustments they asked for. In some cases you may wish to present multiple options for their decision. Clearly lay out the pros and cons of each, and actually show them how it works and the limitations. If you have an idea that they haven’t thought about, work on it and present it as an option.
- Document your decisions in a lightweight Requirements and Design document. Any global decisions made are well suited for such a document.
- Go back to #1 and repeat until done.
Ideally you can have these workshops every day or two. They can be relatively short, say 1 hour or so, allowing you to be respectful of their time. While doing this for a fixed number of weeks, say 4, keep in mind the following:
- The reason this technique is effective is that it allows users to see what they are getting immediately, and they are actively involved with deciding how it will work in the tool; it’s not all up to you so you don’t take the heat for it. Visual feedback facilitates expectation setting.
- One thing you must convey to the customer, regardless of their level of familiarity with OBI: This is a tool, and you’ll have to see how well what you asked for can be done. Even if you are a super expert, you need to “see how well it works”. If OBI can’t do it, just say “the tool doesn’t do that, but here is another way – is this ok?”
- As you are getting into the weeds with the customer on what their dashboards and reports should look like, take time to discuss with them the real business purpose of the report. You may find that one report becomes three, or three reports become one. Ask “What are we really trying to show here?”, and then come up with an option for them. The difference between a Report Developer and a BI Consultant is the BI Consultant thinks about other and better ways to solve the customer’s problems as opposed to implementing to a spec.
- Think about ways to enhance the overall experience and dashboarding environment. Most likely the customer is expecting Just a Bunch of Reports (JBOR). Use this opportunity to show them drill downs and navigations from summary to detail actually look and feel. Sprinkle in some exception based BI or conditional formatting.
- Along the way a dashboard structure may unfold. Make sure to prototype this as well and fully discuss it. Ask about plans 2 years from now to make sure you don’t box yourself in with a short-sighted Dashboard structure.
- Make sure someone is driving the prototype, even making small changes to it in front of their eyes, while someone else keeps track of notes and decisions. It is also useful to have someone else driving the conversation if possible.
- Don’t over-do it with the prototype; everything doesn’t have to be perfect and fully features. Constant re-adjustment of the Access tables, their data and the RPD model is a given. If you need to do something 10 times then just do it once to show the users, then document where else it should be done. Shortcuts are essential.
- Nail down names for reports and fields and document them.
At some point near the end, when everyone feels like you’ve captured all of their needs, you can start to solidify the design, particularly the RPD and the Data Model. If you’ve done the prototype efficiently, you will have taken a lot of shortcuts that you’ll need to discuss or complete the full design for.
You will also make sure up front that the users know that this effort is timeboxed and cannot go on forever. For this reason I prefer to keep the prototype on a developer’s notebook and not on a shared server; if users have access to it they will never stop asking for changes and tweeks. Furthermore, it’s simply faster to develop on a notebook than a shared server somewhere. Keeping things lightweight for the prototyping process is essential; accept no slow-downs!
Why Do It?
There are several key reasons why Prototyping has a distinct advantage over a more traditional approach.
One of the biggest problems with traditional, strict report layout requirements is that you will bump into unforeseen problems when you get to development. I don’t know how many times a user asks for a specific format or UI feature, and during the requirements and design phase the fact that it can’t be done like that is overlooked. I have seen it happen on nearly every non-prototyped project so far, and I’ve been a part of quite a few. No matter how amazing you are with any tool, there will be solutions which you simply are unprepared for or overlooked. With a more traditional approach, it happens rather late in the project when you find out that you can’t deliver a signed-off feature in the manner in which you said you could. This leads to a disconnect between users and the project team, and the project team will lose the argument. Prototyping’s main focus is to eliminate this surprise to end users by addressing it up front from the very beginning.
Along the way you have the option of improving what the customer asked for by showing them different solutions and having in depth discussions with them. A rigid requirements approach has little opportunity for improvement, as there is nothing to look at from a holistic perspective. I cannot stress this enough – seeing the solution develop allows for a much better big-picture view of the solution, thereby allowing users to also focus on the overall structure and user experience as opposed to only the details of a report.
Customer Stake in Design
Instead of simply throwing a wireframe over to IT to work on, by bring this users into the discussion and working side-by-side with them to solve problems, they are more active in the outcome. The users feel as if the outcome is more of their work than a design document would be, as they were there crafting how things should work. For IT or the consultant, this also means every part of the solution is jointly owned and not just your responsibility that you screwed up. In other words, if something is less than optimal, they can’t blame you for it – they were part of the decision making process from the beginning. (Sorry for the cynical view, but it is a reality that consultants and IT face all the time.)
Waiting until report build time to determine that a feature can’t be done or a report actually requires a whole new set of tables is a disaster on a BI project. Prototyping early on allows the development team to substantially increase their confidence that they can deliver a specific report format. If they cannot, they will know at the beginning of the project as opposed to the end.
Additionally, UAT no longer becomes a surprise to the users; they are getting exactly what they knew they were getting because you showed them (and proved to yourself) that it can be done.
Better BI Designs
As I mentioned earlier, I believe your outcomes will be better with a Prototype approach that by rigorously focusing on writing detailed report specs. The system has the ability to come alive for the users very early on. They’ll be able to see what they wanted, plus even get the juices flowing on even better designs. Think of it of getting them to UI 2.0 right away instead of being stuck on UI 1.0.
Work out Difficult Metrics and Config
Although I think Prototyping is mostly about the UI and Reports, there are times when a prototype can help you determine a complex metric definition. Sometimes metric calculations simply are not known and need to be tried out first to confirm the cases and logic is correct. Additionally a particularly complex piece of RPD config may be needed; with a Prototype you have some time to work on the solution and try it out.
Yes faster. Instead of spending weeks or months writing down what you are going to do, and then ultimately finding that some of it didn’t work as expected, you can start of building the reports right away. All of those weeks of prototyping are effectively like a trial development cycle. When it comes time to actually develop the real reports and dashboards, the development team will have already built them once before – this will allow your developers to go much faster through the final solution than ever before. In fact if they forget a specific technique, they can always refer back to the prototype.
Ultimately, detailed report specs I think are a waste of effort. Writing down every sort, filter, column format, etc. just isn’t as compelling or useful as doing it. Reports will change over time; will the team go back and update report design specs? Probably not. I have seen customers that spend more time documenting the report than actually working on it; I feel like this is a massive waste of effort. Ask yourself this: do power users do extensive documentation when building a report? Why not?
Why Not Just Make the Prototype the Final Production Solution?
Most likely your prototype behind the scenes is a pure mess. If you’ve done it right, you’ve taken a lot of shortcuts, cheated quite a bit, and most certainly ended up with a different folder structure than before. You will have all sorts of junk reports, prompts and pages littered throughout your WebCatalog. Your RPD will likewise have many shortcuts that you’ve made – perhaps you needed 5 metrics but you cheated and used the same one with 5 different names. In reality, the RPD stands a better chance of becoming production config than the UI does, but I won’t go so far as to say you can use it. If you are lucky you might be able to. I think it really would be the holy grail to simply “swap out the physical layer” in the RPD and suddenly your development is done, but I don’t think this is realistic.
Prototyping, much like the Agile Methodology, focuses on getting things in front of customers as soon as possible. With this in mind, they both are designed to adapt to change – in fact that is the reason they both exist. Far from shying away from change, a good prototyping process can actually increase the amount of changes to your UI solution. But not all change is bad; as I’ve seen happen before change can lead you down a better path that anyone had intended at the beginning. Furthermore it allows the team to focus on the outcomes as opposed to writing about what the outcomes should be. Finally I believe it engages the customer to a greater extent and minimizes any user expectation discrepancies.
Let’s apply part of our BI craft to how we build BI systems: A large part of BI is about effective communication via appropriate visual representation. I submit to you that we follow what we preach during a project; visual communication tools such as a stop light or a colored trend indicator (the prototype) is far more effective than a large list report full of text and numbers (spec documents).
Let me know how your prototyping experiences go!