How PoCs are helpful for well-accepted solutions
I am sure all of you must have come across the words Proof of Concept, and Prototyping, in BI context. You would have come across them quite early in a BI / DW Project, where the customer is testing technology waters, and how their business users would react. We all know that, this kind of stuff engages business users early on.
All of us have seen that a usual problem in BI / DW development is the disconnect between what the business users need and what the IT delivers. It is difficult to find fault with either of the teams, because Business users find it difficult to express or articulate their requirements, specially the look and feel of their needs, definition of their metrics, what kind of analyses they would like to have handy.
Our usual or traditional methodologies involve business users' engagement at the time of requirements gathering, and at the UAT (user acceptance testing) phases only. We also must have experienced business users' unhappiness at these approaches. The business users will have a variety of displeasures ranging from look & feel, arrangement of KPIs, Metrics, inappropriate drill-downs, not too familiar interfaces, difficult to use navigation, unusable delivery methods etc. This is because the IT folks will bring in all new terminologies at the UAT phase, like dimensions, slowly changing dimensions, fact tables, aggregates, drill throughs, dashboards, scorecards etc.
The moment the business users are unhappy, you can be assured that the BI / DW solution will be lightly used. This results in more complaints at IT folks, frequent change requests coming up. All these result in cost overruns, unsatisfied business users, no proper ROI on the IT investment, and data silos still get created for the business users to work with. Final result is that there is no data consistency. Business users may shrugoff with waste of money comments.
Well, I belive that there is a way out from these scenarios. It is easy to say that the business users should be involved all through the development. Then there are issues in this also. How often you heard, the IT folks complaining that the business users don't participate in these meetings. So we need to excite them to participate in the BI project all through. Well, all-through is something very difficult to achieve. SOmetimes, insitence on their continuous attendance, may result in their juniors attending the meetings. These guys may not have the complete context of the development, and may not contribute properly. Besides, additional people and their time will also impact the BI Budgeting. I don't think in these days of economic downturns, businesses can afford these.
Well, now can I say that PoC / Prototyping is the best foot forward. Well, you may think that I could have started with the advantages of PoC straight away. But giving some background always builds up the case. You all can use this argument for a PoC / Prototyping, if required.
PoC offers a best means to excite end users' interest. It showcases all functions and features, for the end users' to pick from. This would excite them participate whole-heartedly atleast in the PoC validation. This will make them have a dekko at the shape of things to come. They will also be familiar with some of the new names they are going to hear, and usa of them. Hence, care has to be taken to show all types of features and functions in the PoC itself, even if it is done on a small scale.
Now, let us try to understand whom and all we should involve in the PoC validation. Showcasing to the a small group of high end users will be good. But it may not be enough, as all the end users may not be high end users. So, a sample of heavy users, all across different levels of the organisation have to be involved for a better acceptance. This will make all the opposition to the new technology expressed right from the beginning, rather than expressed at the end, resulting in sub-optimal usage later. On the upside a successful PoC can generate more champions for the technology. Now coming to the downside of the Poc: We can atleast know that there is some opposition to the technology, some people are not very comfortable with the features offered. Even if the PoC is not accepted, then we wouldn't have burnt heavy bit of time and money on a technology which will anyways not get accepted well.
Now let us look at the ways and means of getting a PoC signed-off. Although a PoC doesn't reflect a final solution, but in the case of BI it does more or less represent a vertical slice of the whole solution. When we say vertical slice, it includes each and every layer on the components and will have a representation of all the features and components. Once, focus is put on the PoC development with understanding, there is every possibility that a PoC represents a full solution.
Sometimes, PoCs get accepted quickly, other times they don't. A well accepted PoC represents that a proper tool has been chosen right from the beginning, and it also matched the expectations from the business users. But if it doesn't get accepted, then we need to think that a problem is nipped in bud.
PoC also brings the business and IT folks together and all their ideas get exchanged. So, there will not be many ambiguities later.
Some of us expect that PoCs should be leveraged and should be able to cut the overall development time. Most of the times, we cannot re-use the PoC components. But if you look at the reduction in the overall timelines, it is mainly due to the reduction in requirements gathering time, and business users' visualisation portion. But this significantly reduces the rework efforts.
Let me try giving some suggestions on the PoC:
1. Tend to show the BI / Reporting tool, in full features and colours, rather than actual use for a particular user.
2. Keep handy the names of all the folks involved in the PoC, so that there is an immediate buy in from the business users.
3. For easier participation of the business users, we should encourage use of business terms.
4. For a proper acceptance, we should have something ready and working PoC, before even we get the business folks involved.
5. Show some current data for better involvement of the users. Showing old data may not interest them, or make them look for correct information from it.
6. Set their expectations from the beginning, that the PoC is not going to answer all of their queries. Also explain that increasing the scope of the PoC, is also going to delay things, but instead the users should be focussing on the features and functions, rather than coverage.
7. When the users begin to evaluate the PoC deeply, try to differentiate their suggestions into must do and wish to do. So that the wish to do doesn't take up more time, and doesn't figure as a priority stuff in the later phases.
