Happy families are all alike; every unhappy family is unhappy in its own way.
— By Leo Tolstoy
This famous saying should have been known to most of you who have read Leo’s novels. In IT world we would say successful projects may have the same key factor whilst the failed ones may be due to various reasons. It is widely aware that IT projects especially BI projects are with pretty low success rate (approximately up to 30% per some investigation). If we go into the reasons for failures occurred in different industries, we can find some, such as (not limited to):
More cost and longer system development cycle over than expected. Some companies want to invest in building up a complete BI system from scratch with limited budget. It need to be realized that it usually take couple of years to develop a BI system so better to deem it as a long-term plan.
Bad data appears among transaction systems. Most likely this is a common issue in most companies from the completed BI projects in decades. A number of time and effort will have to be taken to solve data problem like lack of MDM data, pertaining multiple copies of data, incomplete data set etc.
Select inappropriate type of BI software. In current market there are great number of tools are available to select, so CIO and other decision makers have to evaluate some keys – cost, reusability, vendor service level. In a case where the company have purchased a license with much money, then they may don’t have extra budget for the system implementation resulting in the risk for the investment.
Dependency, dependency! You may see there are some typical roles like project manager, data architect, BA (Business Analyst), ETL developer and Report developer etc, each of them is responsible for different work stream. However, different role need to work closely with others from upstream to downstream as they are sharing the same copy of data flow. One’s work tend to affect or rely on other’s work. For example, without the data loaded by ETL team, report build team can not start up with their development and test work.
So far we know that BI project delivery is with challenge from project beginning till end. What if the BI implementation work was done by onshore & offshore team together? The answer is that the approach outsourcing BI work to multiple shore teams is doable and practical.
I’ve been involving in an Oracle BI project team to drive off-shore design, development and testing effort. During the release phase, we have been meeting challenges and I thought over on it to summarize some tips that may help for similar projects.
- Understand business requirement as a whole team. The basic requirement for the client is like: what kind of business question need to be answered? What’s the KPI measure? How to gather and integrate data from transaction and form dashboard? How is the data element in current Siebel or Oracle EBS system? Onsite BAs have many meetings with client users in different department but offshore team does not have such kind of chance. This will increase the business understanding GAP between teams. The suggestion for it is to hold knowledge sharing across teams and keep most key members in the same page.
- Prioritize the work and take dependency into consideration. If each team sit together and review what kind of work items the team will have, there should be a long list. Even though, each team lead please spends some time to prioritize the work list by taking dependency into account. From the experience, there are tons of things relying on Siebel data model configuration, the BI team should work with Siebel app team to identify the GAP and reduce dependency. If a task is most valuable to client and easier to work out, that’s one of the top items.
- Build out lineage field mapping across teams. In the real work each team might be focus on their own stream while don’t have a clear picture in other parts. As addressed above, each team is actually binding to an intangible rope. Creating a shared field mapping is good way to make sure each one has clear idea on how his part is connecting to upstream or downstream parts. The sample format can be like:
- Adequate unit testing and integration testing. Testing work should be emphasized at project management level thus each member will have good awareness in delivery quality. We would suggest to setup dedicate tester role when BDE doing proposal to client. This is good practice from quality management perspective. The dedicate tester or developers can create test case with BA at the beginning. With these cleaned-up documents, the developers can perform unit test after code completes and test team can do validation on design such as ETL mapping, Data warehouse Model and Reporting field formula. Of course, client team will have to preview the report and validate the presented data to see if it meets their BI system goal.
I admit there are much more tips can be raised to ensure a BI project to be more successful in client expectation, efficiency, cost and quality. I listed out these points in this post because it is a lesson learnt from the tenure I have undergone.
