In my previous post, I discussed the outline of utilizing mini-marts to the organization while also building towards a robust and sustainable framework on which to build additional value in the future. I want to come back and revisit this in slightly more depth, as I have had a chance to employ these techniques through a couple of different positions over the last couple years, and there have been some definite opportunities for learning along the way.
First off, let’s revisit the overall outline, as it has been found that we can find ways to engage even earlier with our business users, and allow them to outline or outright define the solution with just some gentle guidance along the way.
First up, we engage in reconnaissance with the business unit. This stage is a pre-engagement phase where we speak with individual users, managers, and others from in and informally associated to our target department. We attempt to gain some insight into the pain points that we may be able to address. In most cases, this will be something that everyone has become aware of, but no one yet knows how to solve, or has the time to devote to building solutions.
From this recon phase, we can build out a wire frame. A basic representation of the capabilities of our BI solution. Within the Microsoft BI Stack. We can generally find that the department in question will have more than one Excel report they are compiling utilizing manual compilation and some system extract, either scheduled or ad-hoc. This sort of basic excel report can form an excellent foundation for the building of a wireframe.
Once this wireframe is complete, we can begin the engagement with the target department. The wireframe acts as a central talking point to the discussion and helps solidify the idea in our user’s minds of the direction we can go. A majority of the time, the users may not even be aware, as you and I are, of the changes made to what our capabilities are in delivering business intelligence over the last decade. The advances in the platform, capability, and delivery are our purview, and as such, we should be helping to guide our users towards seeing the best value on the investment in ourselves, and in the data platform.
Once we have a go ahead, we can begin work. We will take the ideas from our users, and the wireframe discussions, and develop a proof-of-concept. Consider this to be a first draft of the MVP. This proof of concept can be built from stage one extract. We are not aiming for performance, translated values, or complete usability. The idea with the proof is that it can be developed in an incredibly short turn around times. We build the source extract, move data into our warehouse in a flat format, and build a basic concept dashboard or BI product from this flat extract. Functions will be there, and some basic layout, but we know this will be the first draft only.
With the proof of concept in hand, we then re-engage with our users, forming the core of the focus group for the ongoing design and development of the dashboard product. We give access to a limited number of people in the user group and allow them to interact with the product. They are instructed only to provide as much feedback as possible. We begin the pre-validation of our source extract at this stage, and we work with our users to enhance and clarify the design vision. This is the first half of the first cycle. From here, we begin the real work involved in developing a mini-mart and a BI product for the users.
With our fresh feedback in hand, relevant to the product, and based on real usage, we begin the work of putting together the mini-mart. Stage 2 ETL is design and completed, deployed in a segmented development zone. This isolated zone in our warehouse development environment is the core of our new mini-mart. It may include elements or dimensions even from other areas, that we have previously developed, or it may be in isolation, depending on the context of the business.
We can build our MVP once we have completed stage 2 ETL, or we can dive right into the final stage 3 ETL build, which should be relatively rapid if we have been building for future scope all along. (Further on scoping in future articles) Ideally with our stage 3 ETL complete, validation feedback in hand from our focus group working with the proof of concept dashboard, all the pieces are falling into place to develop the MVP with as little pain as possible. The wireframe, to proof to MVP cycle, is complete.
With the MVP launched, we move then onto the full sized focus group, engaging further with our users, showing the fruits of their labours and feedback, and showing them a product they feel not only happy to use, but a part of creating. As has been discussed previously, we are always aiming above buy-in on our projects, and the goal is to have the business users feel ownership of the product. This ownership comes from early and ongoing engagement, and from feeling that they have been heard and understood through every phase of development.
The addition of the proof of concept phase over the last year has been a great boon in my works in developing BI value rapidly for my organizations, and for increasing uptake and ownership within the business group to the BI products developed. Ultimately, if I have developed something they will use and will make their ability to consume and work with data easier and less painful for the business, I have achieved some measure of success in my role.
Until next time, Cheers!
SQLDoch
No comments:
Post a Comment