About half a year ago I began my foray into the jungles of data as a Data Lurp and wrote a small piece on why this role is effective and valuable in building a data strategy. Despite the effectiveness of this role, I have not seen much, if anything, written on taking a tactical approach parallel to a strategic approach when building a data strategy. Now that some time has passed, and I’ve returned from the jungle for a small reprieve, I’d like to pass along some of my observations.
— Recon After-Action Report —
The most significant finding was that a Data Lurp needs to have very strong personal skills. I found that technical skills, while important, are clearly secondary. Corporate culture, while changing, is still in a phase where IT is viewed as something that is driven by the business and a utility. Something the Data Lurp (as well as IT) has to overcome. In my over 20 years in IT I’ve witnessed three distinct phases of IT; I believe we are moving into a fourth:
1. IT simply supports the business. In this outdated early model, IT framework and solutions are defined and provided by IT.
2. IT is driven by the business. In this also outdated model (still prevalent), business units make demands of IT and IT fulfills those demands as best it can.
3. IT as a consumer commodity. In this current model, not only business units but individuals make demands of IT. This model reflects the consumer demand for easy to use technology (IPads, smartphones, etc) being pushed into a corporate environment.
4. IT participates with the business at all phases of decision making. In this evolving model, IT is asked to participate with the business in making decisions from the beginning.
The most effective Data Lurps are those who are able to help the culture evolve to the fourth model of IT. As this model is not yet present in most corporate cultures, the Data Lurp has the responsibility of helping the business recognize the value of having IT when making decisions. Data Lurps, as junior data scientists, often can create insights with the cooperation of the business units, thereby, in sense, helping the business to see the inherent value of IT.
Like their military counterparts, Data Lurps need to create strong relationships with allies in the field, turn enemies into allies and convince them all of IT’s worth in decision making. The view that IT as only a cost center breaks in the fourth model of IT’s evolution.
The IT sophistication of many business units surprised me as a Data Lurp. I never assumed any of my business counterparts were nothing but intelligent, but I did not expect to find so many IT savvy users. In many areas people were actually hired because of their IT skills. It is a sad statement about IT when someone with Access Database skills is hired by marketing because IT is not fulfilling their requirements. This is a repercussion of the aforementioned models 2 and 3 when IT is ill-equipped or ill-staffed to meet demands. The result of this, in my case, was a surprising if not alarming number of ad-hoc processes and Access databases. Duplication and miscommunication thrives in this environment. It is a fairly easy process to conglomerate these disassociated databases into SQL and provide a uniform view of the data using SSIS however, that leads to my next finding.
Any hint or suggestion that a tool is going to be replaced or taken away leads to a firestorm response of a vitriol not seen since biblical times. Users are not unaware of the value of data, they prize it likely more than the IT people who promise to house it, back it up and make it easily available. If a lack of trust between the business and IT exists, then this minefield must be recognized as such and crossed with the utmost caution. The resistance can be overcome by providing new solutions BEFORE any removal or hint of it. This may be cryptic so let me give a real world example:
The users of a particular department had long used an Access database for reporting sales data, despite all of the sales data actually being in their ERP system (SAP). They would run queries in Access, print them, make them into PowerPoints and then present them in meetings. The solution to making this data available to more than just their department and standardizing it was simple. We created a PowerBI dashboard report that mimicked there current reporting but used Odata from the SAP system instead of their Access database. Once they became familiar with this tool and were no longer using Access, we simply archived and removed this duplicate data. We never took their original source of data away until we noticed that a couple months had passed and no one had used it. You need to provide a better solution BEFORE removing an existing solution. While this may seem obvious and sophomoric, I observed reporting solutions being drop-replaced most often.
Finally, and the most disturbing discovery of all, is that there are fiefdoms of data in your environment guarded by the most ardent of believers. These individuals view their data as a prop and a stay of their careers. They may also view this data as something no one else would interpret correctly and therefore, no one else should see it. This is a difficult position for the Data Lurp. Stumbling on this camp of ardent zealots the Data Lurp may recognize the significant corporate value of this data, but should be wary to offend. The only course, in this regard, is not a technical response; the response is to inform management, directors or above of the secrecy and isolation within their department and ask that they deal with the issue. In my case, nothing came of it, the data is still fiercely guarded and all involved are overly wary of making any offence. Improvement in a situation like this will take time before said guarded and valued data is shared.
Simply put, the Data Lurp in the field needs to be an ambassador and proponent for IT starting to take a seat at the decision making table, a cautious enhancer of processes and an identifier of fiefdoms zealously isolating valuable data.