how to screw up bi project from day 1(may be how not to)?
TRANSCRIPT
BY: HA R I PR A SA DM S. B IT S P IL A N I .NO TE : N OT A C A SE STU DY,BU T A N EV EN T STU DY.
How to screw up BI project from Day1?
Day 1
Sales team meets customer and explains him that OBIEE can be used for anything from calculating the Sum to Displaying entire Data warehouse!(Wrong!)
Sales says, See here! We have a reporting tool for your data and we have guys who can work on it!
Day 2
Business Analyst/Source Data expert will meet customer team and ask for requirements.
The moment requirement is in his mail box he will forward it as it is to BI team without analyzing, asking if you have any questions, please revert back!
BI team, who is not aware of business will scratch their head and come up with irrelevant questions, as they know only tool not business.
You will always get irrelevant answers for irrelevant questions!
Day 3
Team will build a Space shuttle for customer requirement to build a chair.
BA will sign it for UAT without even testing!
Day 4
Customer will not do proper UAT nor BA team will try to persuade him to do so.
Code will sign off and will go to production.End User will complaint.Customer will escalate to fix within
overnight.
Day 5
BA will blame technical team, technical team will blame BA.
Finally both struggle and finish the fix overnight.
Questions! Is it a happy ending? Is it a pattern which is repeating in BI Projects? If so, what is the solution?
Solution
Put an experienced BI resource from the Day 1 of requirement gathering.
Eliminate confusions by removing layers in between business and BI implementation team.
Have an iterative UAT on every requirement stage .Make sure to have SOW clearly defining the terms
like “Change Requirement”, “Sign Off”, “Bug Fixes” for equal distribution of responsibilities.
In case BA is absolutely needed, have a cross training of Business and Technology between BA and Dev team.