The data issues log

Season 1 Episode 6

In this episode, CJ Anderson begins at the beginning by talking about the data issues log.

She explains what it is, why it’s helpful, who’s usually responsible for it and why it’s not the same as a project issues log.

Subscribe

Law Firm Data Governance Podcast

• Do you want learn more about the podcast?
• Are you curious about what’s coming up in future seasons?
• Do you want to listen to the latest episode?

Answers to these questions and more can be found on the podcast page.

Episode Transcript

Welcome to the law firm Data Governance Podcast, the Data Governance Companion for law firm Leaders who want to know more about implementing and improving data governance. Each week I’ll share a new episode that talks about something to help you with your law firm’s data governance initiative.

This is Season 1, Episode 6, and in this episode of ‘Beginning at the beginning’, I’ll talk about the data issues log.

We’ll cover what it is, why it’s helpful.

Who’s usually responsible for it? And why it’s not the same as a project issues log.

Most people recognise the concept of an issues log from a project management perspective.

In that context, it’s a tool that contains a list of ongoing and closed issues relating to that specific project.

A project issues log might also contain things like user requests or remarks about known problems with whatever that project is delivering.

Usually things like software or new processes, new teams, that kind of stuff.

When we take the concept of a project issues log from a data governance perspective, it’s a log, or register of all the issues, challenges, problems, opportunities that negatively affect the data.

It’s a tool for your Data Governance Centre of Excellence to report and communicate everything that’s happening with data from a cross-functional perspective.

It looks a lot like a helpdesk support ticket.

You can log the issue, it gets an identifier, and then you can track it through to its resolution.

If we step back to the project management context for a moment, a project manager works to keep their project team at their best by managing challenges related to the people involved in the project.

For example, missing skills, people leaving the project or conflict resolution.

In data governance, while the resolution of each issue may be a project in itself, the data governance lead or member of the Data Governance Centre of Excellence team still has to manage stakeholder expectations.

They need to make sure that missing or departing skills and knowledge are replaced within the firms data governance framework groups.

They also have to track issues that directly affect the data objectives, the data schedule and the data quality.

Disruptions to data performance will also impact stakeholder expectations.

So in that regard, it’s very like a project.

A core component of setting up a data governance framework is capturing a list of data pain points or issues, challenges, whatever you want to call them, and developing mechanisms for prioritising and solving them.

This includes figuring out how decisions about these issues are going to get recorded and actioned.

Indeed, in the early days of your firm’s data governance programme, most people will have already expressed a laundry list of historical issues that are causing them personally a problem.

From their perspective, the issue has been discussed and discounted or wholly ignored for some time, and at worst they feel that previous attempts to solve the problem have failed.

This sets high expectations on your data governance centre of excellence to deliver solutions to these issues, these problems, these challenges.

This is where the stakeholder and expectation management part of the issues log comes in.

Issues logs aren’t just a way of tracking the progress.

Data governance leads can use logs to order and organise the current problems by type and severity.

This helps prioritise the problems associated with achieving the firm strategy or enabling achievement of that strategy.

And of course, once your data governance framework gets going, you’ll have lots of new issues being logged and prioritised and it’s not uncommon for this prioritisation to be a joint exercise to get the buy in and support of all the necessary stakeholders.

Based on the issues impact to the firm, you can categorise it as high, medium, or low.

After all, most law firms have a small pool of technical experts who will need to resolve nearly all of the issues on the data log.

You can’t have them working on everything all at once.

They need to be clear on what you expect them to do to solve these issues and to support the firm strategy.

We’ve talked about what the data issues log is and how it gets used, so let’s talk about the components of an issues log.

Remember, you can successfully manage issues by focusing on the types of information that support you to engage with stakeholders and to track progress.

Every firm does it differently.

Some use existing ticketing mechanisms, things like ServiceNow for example.

Some just create a simple list in Excel or SharePoint.

Some firms use Kanban boards.

It really doesn’t matter which tool you use as long as you can track progress.

If you were going to do this in a spreadsheet, you’d have to have a bunch of different columns.

So here are the kinds of information that I’ve seen captured in the columns of a data issues log.

You’ve got to start with the issue name. What do people understand it as? What kind of label is it going to have? This is a problem with X, or Y isn’t working.

In a lot of cases you can add another column for an issue number to give you a quick reference, but it’s not always necessary, it’s entirely up to you.

Issue type or issue category is quite useful if you define the categories of data issues that you’re likely to find.

You can track themes and assign them to the right people to resolve them.

For example, missing data stewards is an issue or connectivity between two systems is an issue, but you figure out what works for you.

Description is also a key field.

It can include the impact the problem may have on the firm or the data itself.

It can also include details of other projects and firm objectives which might be affected by the issue.

Another good column to have is resource.

This is where you can track issues related to human resources or equipment or materials in the project.

So which people do you need? Which consultancies? Which technologies? Which other materials? It’s always helpful to track who recorded the issue, who logged it, who reported it.

If you don’t know who logged it, you don’t know who to get back to.

And if you don’t know who to get back to, how can you confirm it’s been resolved? Are they happy with what the solution was? And again, track the reported date.

You should record the date when the issue was raised.

It’s always helpful to know how long a problem has been hanging around.

We talked about priority earlier, so don’t forget to have a column for priority and put a rating for every issue.

It doesn’t have to be complicated.

You can do high, medium, low, or large, medium, small or 123.

Base it on the issues, impact to the data strategy, to the firm strategy and to the objectives that you’ve set in your roadmap.

You also have to track who is actually going to solve the problem, so having a column called something like ‘assigned to’ the name of the person or team who’s responsible for getting that issue solved.

If it’s a person, they might not be liable for doing the issue resolving themselves, but they are responsible for tracking that issue and ensuring it’s handled based on its priority.

So it might be, for example, a team lead or a key representative of another team.

If they’ve got a deadline or deadlines are easily findable, you might also have a ‘target resolution date’, something like that, as a column.

‘Status’, is the penultimate column, the second last column you should have.

You want to understand where the progress of the issue resolution is.

You’re tracking it for reporting purposes and also for stakeholder management purposes.

You need to be able to have credible conversations about how things are getting on.

Progress could be indicated through labels like ‘open’, ‘implementing’ or ‘resolved’, or it might be more free text.

It depends how many issues you have and how quickly you want to be able to find things that you’re currently working on.

The last column, the final column, should always include a description of what that solution is, a brief description of what you’re implementing.

This helps with your data communications, but it also helps if a similar or the same problem comes up again later.

You can fast track your way to an answer because you already know what the solution is.

By maintaining a data issues log for the firm, stakeholders can raise and document problems and their solutions.

The Data Governance Centre of Excellence can make sure that these problems are investigated and resolved quickly and effectively using the fields that are in the log to help them manage stakeholder expectation and communicate change.

If you’ve got any questions about issues log or any other part of data governance, head over to IronCarrot.com.

Use the contact form to get in touch, and I’d love to include the answers to your questions in future episodes.

In the next episode, we’ll continue beginning at the beginning by answering the question “What is data lineage?”