Good practice for statistical analysis in a business environment

(While I realise this isn’t strictly about statistics, it is about the dissemination of statistics in a business environment so I have assumed it is still within the topic range of CV)

A brief bit of background:

Our business environment (and I suspect other environments) have a support function who specialise in statistical analysis and research. We work closely with Business Intelligence and are commissioned by other departments to produce pieces of work. In effect, the data, analysis and conclusions don’t belong to us: we collect data, perform analysis and draw conclusions for the commissioner to use within their work.

What I want to do:

Currently, we run quite a laissez-faire approach. An individual from the support function is assigned when work is commissioned, data is collected (or extracted, if it exists, by Business Intelligence), analysed and the final set of conclusions are sent to the commissioner. This has been loosely justified on the basis that it is not the commissioner’s role to read through the analysis; it is our role as a support function to ensure we provide the right analysis for the questions/topics the commissioner wants to explore.

I want to invoke a little more structure on the approach to make

a) our analysis of a higher quality;

b) provide defensibility when our analysis may lead to bad decisions; and make

c) our analysis more transparent so we aren’t viewed as a ‘black box’ that takes data and spits out results.

My initial thoughts have been to:

  1. Produce a technical document with every piece of work that justifies the approach taken, the assumptions made, the issues found, the uncertainties that exist etc. While this won’t necessarily be read by everyone, it should be used as a means to explain to the commissioner the consequences of using the conclusions drawn. This transfers some of the risk to where it feels like it should belong: with the commissioner.

  2. Restrict all analysis to a package such as Stata, SPSS or R and require a full set of code to be produced alongside the technical document. All of us have a habit of using Microsoft Excel for some types of analysis (bad habit more than anything). However, Excel doesn’t promote easy reproducibility of analysis. This helps defend the support function when our analysis is questioned, creates transparency in our approach but also makes the role of (3) much easier:

  3. Assign a reviewer to every piece of work who must ‘countersign’ the work before it is sent to the commissioner. By countersigning, it distributes the integrity of the analysis across 2 people and encourages them to work together (2 heads are better than 1). This should improve the quality of analysis and also provide some defensibility.

Are there any other facets of good practice that can be applied in a business environment of this kind?


My advice in two words (TL;DR mode): reproducible research.

For more details – largely not to repeat myself – let me refer you to my relevant answers elsewhere on StackExchange. These answers represent my thoughts (and some experience) on the topics:

Final note (sorry, if you find it obvious): regardless of the type of your business environment (which is unclear, by the way), I would recommend to start from business side of things and create a data analysis architecture, which (as all IT-related) should be aligned with business architecture, including business processes, organizational units, culture and people. I hope that this is helpful.

UPDATE: In regards to creating a new or improving an existing data analysis architecture (also referred to as data architecture, in enterprise architecture terminology), I thought that these two sets of presentation slides might be useful as well: this and this.

Source : Link , Question Author : NickB2014 , Answer Author : Community

Leave a Comment