Get to know our process: Organize
This is the last part of a 3-part series. Check out the previous post, on Assess, the second step of our process.
After gathering and assessing your data sources, it’s time to organize. This is the point where you put in the effort to ensure you don’t have to do heavy lifts to gather and assess again. (To lean on the money metaphor we use on the site, this is when you decide how to spend and save, and hopefully get a piggy bank or an envelope system going that everyone can comfortably adopt.)
The important move here? Defining data governance policy and procedure.
First, we research current awareness and understanding
If you have a policy already in your team, we want to establish how well governance policy theory and practice match and elicit opportunities to bring them closer together. If you don’t have one, the answers to these questions become the outline of your policy.
We start with one on one conversations with each team member, going through the questions listed right on the Organize webpage. They are written for managers but we modify them for team members:
- Does everyone in your team (or, do you) understand what [information] is stored where? Can they (you) search easily? Do they (you) have awareness of what exists that they could search?
- What is your procedure for deleting data? What if some of the data you hold belong to another team or even an external party?
- When was the last time your policies were updated?
- Is your data governance policy aligned with Legal and Security?
We like to talk to everyone in the team individually just to remove the power dynamics that crop up in group conversation, especially with a manager present. There is no calling out. (We adhere to scientific human subject research privacy standards and anonymize/aggregate data analysis.)
Second, we document or update
We take a look at your existing governance policy and make editorial changes based on our findings, or we sketch the outline more clearly of a new one and provide suggestions to flesh it out. This is usually written, because key business operation documents tend to be in writing even if they are not directly consumed this way any longer.
Third, we generate a procedure
We take everything we’ve learned in the gather and assess phases, along with the conversations and the documentation in the previous steps, and elicit a procedure to ensure the abstract policy becomes a concrete procedure.
We support adoption primarily by packaging new information in a way that you and your team are most likely to ingest and refer to it. We have made:
- executive summary write ups with bullet points (dot points) or traffic light recommendations
- diagram drawing of a current process paired with a diagrammed modified process with new key actions inserted
- matrices
- checklists embedded into workflows
- short video guides
We are also comfortable directly designing, implementing, or modifying AI agents that support employees, or are happy to discuss coded scripts using APIs in conjuction with your engineering team.
As we’ve said before, you are very welcome to take this process and run it yourself. The more design and product teams with gathered, assessed, and organized data sources the better. If you do, please let us know how it goes. If you want an outside perspective to uncover blind spots or ask fresh questions, we are happy to run the process with you.
