In the early 2000s, when most projects were implemented using the Waterfall methodology, testing was a big part of project execution.
It was expected that you applied the complete set of tests to any new functionality or process: Positive scenarios are where you followed the functionality described to see if it works as expected, negative scenarios are where you enter invalid inputs or mimic unexpected behavior to see if the functionality still works as intended.
Testing was applied not only on application functionality but also on documentation - be it an operational procedure, a requirements document, or functional specifications.
The goal of testing documentation was to identify missing or incorrect scenarios at the initial stages of the project when problems are the cheapest to fix.
Waterfall had its shortcomings but today’s reality is that in most projects we are lucky if we get the chance to fully test something before it goes into production, let alone being given time to test documentation. Nowadays, testing is reactive and takes the shape of data remediation at later stages instead of being applied proactively, early in the project.
I see an opportunity to apply some of the testing methodologies in data governance and have a testing mindset when defining its processes. Having a testing mindset means to challenge, inquire, discover, uncover, and think about it from many different angles - all this with the good intention of finding errors before it is too late.
Below are four recommendations on using a testing mindset when creating and/or rolling out a data governance process:
1. Approach the new process methodically: if the process is already written, review the steps recommended, put yourself in people’s shoes, replicate the steps in the context of your work, think of all possible implications (upstream, lateral, downstream), and ask lots of questions. A good process should capture the end-to-end sequence of activities.
Some questions you can ask yourself are:
Am I clear about the new process? Do I understand it 100%?
What is the process trying to accomplish? Is this document capturing that clearly?
If I were to take these steps, would I be able to follow this process? If not, what do I need? If yes, is it easy to understand and complete?
The truth is, governance processes are not perfect, particularly in the beginning when they are first designed. They may be purely theoretical and require a few iterations to make them better and closer to the reality of your working environment.
2. Leverage your team’s critical thinking: if you have someone in the team with a strong testing or business analysis background who can review the process, leverage them. If you don’t, assess who in the team is more inclined to look at things critically or one with a tendency to challenge things. You need a person who is detail-oriented.
3. Do peer reviews: if your team is writing up the new process, have a peer review it. Or if you are just reviewing a process already written, have multiple people in the team take a look and share their feedback.
At this stage, this review will uncover some errors, missing or incorrect information enabling you to be proactive.
4. Have people from impacted areas provide feedback ahead of time?
Have a process review with the people who will be involved in the future process or who are affected by it. This is valuable feedback that will help you position the work to get buy-in on the new process. People always appreciate it when you are thoughtful about their work and give them an opportunity to provide feedback early.
Do they find the process easy to follow? Do they like it? If not, why?
How will you overcome objections when it will come to them executing on the process?
In many organizations, establishing data governance is new, its processes may be defined at a high level and some of them may have never been implemented. If you are in such a position, testing governance processes while still in this ‘paper’ phase could save you a lot of headaches down the road.
Applying these recommendations develops your team’s critical thinking and will result in a sound, functional governance process that is clear, practical, and captures realistic scenarios.
About the Author:
Georgia Motoc is a Director in the Canadian banking industry, with more than 20 years of experience. Most recently, she was managing a team within the Chief Data Office at Scotiabank, overseeing the CDO’s portfolio operations in Mexico, Chile, Colombia, Peru, and the Dominican Republic.
Her testing and business analysis background provides valuable perspectives on Data Governance and in general to any aspect of the business that relies on a structured approach.