In my opinion “soft” skills such as the ability to listen are hardly ever mentioned as a success factor for data warehousing and BI projects. Part of the problem with BI is the broken telephone effect and to a lesser extent, the technical skills of the developers. Too much time is spent implementing the wrong things because we do not “hear” our clients.
Listening to your client’s requirements is not only about you keeping quiet and letting your client talk. The key to understanding what your client really means is by providing feedback in the form of questions or repeating what you think you heard. Every few minutes ask a question such as, “so the real problem is that the existing report is missing the variance calculations”? This type of question can save you from starting from scratch and duplicating existing work instead of enhancing existing reports. Another type of question to help me rank requirements is typically, “so this brings in 20% of our revenue”? This question has the added advantage of making your client think through the importance of the requirement.I often use my variation of Cunningham’s Law. The law states, “the best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.” I often purposely ask the wrong question to allow the client to correct me and in the process explain their domain in more detail giving me more information to diagnose the problem. When clients become aware that you literally know nothing about their work, they start from scratch, this is when you often find out where, who captures the data, the problem with the data, and who is supposed to use the reports. Having the word “intelligence” in your job title can work against you. Users assume you must know “obvious” things like the fact that Paul from the contracting company sends them a spreadsheet with the names of the latest products every month. These products are different from the ones in the database and every month a user has to manually match entries in the spreadsheet. This is different from the first problem statement which may have been as simple as, “this report gives us the wrong information”.
Not listening and not asking questions will always result in you not creating the solution the user is expecting. Some mistakes can be costly in technical debt and may include:
- Creating fact tables with incorrect grain
- Duplicate reports and analytics
- Excluding important dimensions from your data warehouse
- Prioritising non-critical data marts
Most business users find talk of data warehouses, data, big data intimidating and confusing (even though many will not admit it). This is to expected because it is not their core job. As a BI developer you need to be able to get them to talk about their core function then design a solution to support these functions. After all the talking and listening it is important to model what you think you heard the client say in a way that you both understand and agree on. See this post on Visualising Client Reporting Specifications for a suggestion on how to model user requirements for both technical and non-technical people.How do you get the real requirements from your users?