How to stop using technical debt to solve data problems with data governance

Data as technical debt is a problem?

What is technical debt?

Technical debt is the list of activities (and the implied costs associated with remediating them) that project managers descope from an IT project. It is a term that was initially used to refer to software development, but the concept has been expanded to include all kinds of software, hardware and data issues.?

Why do activities get descoped from projects?

Activities tend to be descoped for expediency – allowing project managers to meet the time and budget targets the firm wants to hold them to due to cutting requirements from the deliverable. There is usually little consideration given to the broader business implications of making these decisions through a project or software lens.?

Sometimes that is deliberately done – we know this will be problematic for the rest of the firm, but it keeps our functional project on track.?

Sometimes it is accidentally done – we don't understand data management and standards, so we didn't think about the consequences until after we'd pushed ahead.?

The consequence for data issues.

The inclusion of data issues as technical debts is problematic because the solution to the problem belongs to the business owners of the data and not to the technology teams that own the technical debt list. But by making data issues technical debt, the usual consequence is that they are never addressed or adequately resolved.?

Specific examples of data debt that I've seen in law firms include:?

• Fields descoped from forms because the function that 'owned' the software didn't need them, meaning downstream teams had to capture the information by asking lawyers directly.?
• They were capping data migrations at three years of data when downstream reporting systems needed seven years to meet client and partner requests.?
• Data entry forms with no data quality rules, so much of the captured data was useless and needed hours of manual effort (asking people for the correct data) to fix.?

Impact on the rest of the firm?

Wasting lawyers time?

While it is tempting to descope questions your team doesn't need from your project, you need to consider the consequences. Nothing is more frustrating to a lawyer than having their time 'wasted' on admin processes when they have billable client work, especially if multiple teams repeatedly ask them the same question.?

Poor data quality?

Repeated requests for the same data impact data quality as lawyers will eventually stop providing or updating the data, which is captured in the siloed spreadsheets and separate databases by all of the teams which ask them.??

Staff turnover in Business Services will mean that the reasons and rationales behind these silos will get lost in history, and they can end up abandoned. But silos not being updated doesn't mean that the user who remembers them will stop using those spreadsheets – they'll keep working from stale (old) data.?

Increase in manual processes?

For the downstream systems that don't get the data they need to fulfil essential business processes, the impact is on resourcing. Teams must add extra headcounts to manually capture and input the data they used to receive automatically. At worst, entire activity streams must be redesigned to accommodate a more manual working method.?

Poor quality reporting and analytics?

All of these, of course, impact the Firms reporting and analytics. The ability to slice and dice the firm's data in the myriad of ways needed for financial reporting, headcount management, business development, client relationship management and everything else is all dependent on having high-quality data.??

The more data capture processes you add, especially when they involve manual inputting (including rekeying data extracted from another system), the lower your data quality becomes.?

So what's the solution?

Treat data as a firmwide asset?

Create a data governance framework to increase data literacy and create a forum for meaningful conversations between subject matter experts (SMEs). It's harder for people to justify that their poor-quality data or confusing data transformations are the correct approaches when dealing with their peers.??

A data governance framework sets the stage for reducing confusion and managing costs.??

Make data part of your project?

It's easier for a team that uses a siloed system to justify its position to an audience that doesn't understand its decisions' cross-functional implications. In law firms, this happens so frequently in system replacement projects that they are the root cause of most data quality and data process problems in a law firm. The Project Management Office (PMO) must ensure that project proposals address data sourcing, management, and process changes.?

Most Data Governance Centres of Excellence (CoE) have defined a new project team role - "project data steward". This role profile will include the key responsibilities and activities within the project and within the Data Governance Framework groups.

Include data owners in your project board?

Steering Committees are seen (rightly) as the senior stakeholders on a project. These committees usually include representatives from the Partnership and the Directors of Business Services.??

These people think at 35,000 feet – and that's ok, but there needs to be a way for them to get the SME worm on the ground input to help guide their decisions. That's why having cross-functional representation for every impacted system and process in your project board is so important.??

The Data Governance CoE will know who the SMEs (data owners and data stewards) are and help guide the

Communicate transparently?

There comes a point in every project where hard decisions must be made. In my experience, the drivers are usually cost and time – so the Project Manager proposes what can be done to meet the budget and time.??

But the broader consequences are only sometimes transparently communicated to the Partners on the Steering Committee. There is a need for Project Managers to be more open about the effects of project decisions on systems and teams outside the immediate project groups.??

For example: "yes, we can bring this project in on time and within budget, but that team over there will have to increase headcount and start manually capturing data until we can do Phase 2."?

In my experience, Partners are often prepared to prioritise high-quality data to meet the firm's needs over reducing cost and time – but only when they understand the full impacts of the decision they are being asked to take.?

Push data debt to your Data Governance Issues Log?

As part of setting up your data governance framework, you will have to set up a mechanism for those groups to log, prioritise and solve the firm's data issues. Project Teams can be encouraged to use this mechanism as an additional escalation path or fast-track for data challenges in project meetings.??

Access to suitable SMEs who are used to working together to solve problems can get a project over a hurdle without it being a massive problem on the project RAID log or a blocker to project progress.?

Summing up and next steps?

Final advice?

The mismanagement of data, whether deliberately through project decisions or inadvertently through lack of stakeholder engagement, creates a problem (a debt) for a firm. But this is not a technical debt.??

With your PMO and Data Governance CoE working harmoniously, the best of both worlds can be leveraged to minimise and mitigate 'data debt successfully'. With the bonus that your technical teams will be happy as they don't have data as a technical debt they can't resolve.?

How to get help

Please book a call if you would like to talk about how #datagovernance can help you manage #dataissues differently.??