UCOVI Stage 1: Understand
Business Strategy & People Management: ★★★★★ Technical Work: ★★☆☆☆ Analytical/Scientific: ★★★☆☆
Business Strategy & People Management: ★★★★★
Technical Work: ★★☆☆☆
Analytical/Scientific: ★★★☆☆
The essence of Understand in the UCOVI methodology is to research, script, screencast and shoot "The Good, The Bad and The Ugly" for your business data and data-governing IT systems as they are now. Whether you have more bad/ugly than good or not doesn't matter. You need to know what your best databases and cleanest data are to decide what you are going to centre your data-driven future around, you need to know what's bad and/or missing to know what to replace or enrich, and you need to document all and any data processes and reports in your business to know what is being duplicated and pick the winner.
This stage is all about fact-finding, supplier evaluation, data quality gap analysis and business understanding. While you conduct a thorough and patient audit of everything that touches your company data, also put together a representative focus group of business users at all levels of seniority in a wide range of key departments to get their versions of how insights from data could benefit their roles. Use this to take the temperature of how satisfied and literate the business is with data, and figure out which analytics projects to prioritise and identify quick wins.
What do we want to find out with our data?
In which databases are our business-critical data assets stored and which team supports them?
What is the nature of our relationships and service contracts with suppliers and external parties supporting our data and databases?
What reports are currently distributed regularly and do they duplicate each other?
Analytics and reporting teams, DBAs and/or database support desks, data-enthused business stakeholders. Start with and prioritise experts/users of the biggest, most important and obvious business data assets (sales data, marketing and product logs), but think imaginatively and make time for less expected sources of important business data or "unconsidered trifles". Does your HR team collect staff training logs? If so, do these contribute to important internal metrics such as compliance, security or staff engagement? If this is true, consider whether they collect the data in an unweildy, error-prone and unfit-for-analysis Excel spreadsheet, and what value there may be in designing a more technically accomplished system for them.
Whether you're a data executive scoping out an analytics project or a data leader planning the data transformation strategy for your company, the springboard for success is the same – a broad and precise awareness of the people, teams, data and IT systems that you are upstream and downstream of.
To do this well you will need a level of comfort interpreting process flow diagrams, technical documents and database-schema representations in SQL Server Management Studio or equivalents. But what's most important is understanding the key databases first and having the right having conversations in the right order.
Many managers greet their new recruits in data teams with a Master Data Sources spreadsheet cataloguing all 26 databases known to exist in the warehouse or across the IT stack, accompanied by 30-minute intro chats with three or four stakeholders from the business to try and cover all and any use for data across departments. This approach is well intentioned but unrealistic. It leaves new data analysts overwhelmed by the insights they are expected to deliver and the stack they will be working from.
An analyst's understanding should start with detail on the organisation or project's three most important datasets. This will differ across industries but often the three top databases will likely include the CRM (Salesforce/Dynamics/in-house built SQL database and web app), the product fulfilment system with user activity logs or transactions data, and the comms or marketing system (Marketo/HubSpot/MailChimp/equivalents). Once the intricacies, limitations, and data size/quality of these are appreciated, the smaller data-producing add-ons to them (if any) and the reports that emanate from them within the business can be much better understood and evaluated. As a data analyst or manager, you should begin your time on a project or in a new organisation by having info-gathering and collaborative conversations with the teams or suppliers that govern these key databases. Then do your own investigation into the data following from what they say (sense checking your own findings with them), and only after that engage with the business side for reporting requirements or new functionality ideas. Your conversations with business stakeholders will be much better for acquired knowledge of the important data.
Finally, never underestimate the importance of testing. Process documentation and what experienced and respected experts say can be crystallised in your mind (and often contradicted) by what you find for yourself about an application's data by making a test profile to mimick common user actions and seeing what logs they produce.
Learning the key tables of a data warehouse, understanding the pain points of business stakeholders with existing reports and dashboards.
Communication skills, Visio flow diagrams, Lucid charts, database diagrams and STAR schemas, exploratory data analysis. Top-level conceptional understanding of established and emerging data storage methods and structures (SQL Server/MySQL/Oracle/PostgreSQL databases, NoSQL, graph databases, document databases, JSON data, production databases and warehousing, data lakes, FTPs, folder structures).