How to bridge knowledge gaps and create common understanding
Emily McLean and Nanet Pagsanjan
Knowledge gaps are the disparity between a capability and its functionality and can look as simple as colleagues not knowing what to do, what a certain topic means, nor understand its importance. It can also look as dire as GIS teams not being able to perform core business functions, and organisations re-evaluating the value of GIS based on this lack of capability.
It’s safe to say that these knowledge gaps inevitably eats into an organisation’s productivity, knowledge-sharing, and collegiality.
And while GIS is an exciting industry because, by its very nature it intersects so many fields, it’s this diversity that creates or exacerbates knowledge gaps.
But where there are knowledge gaps, there are opportunities. That is, opportunities for robust conversation about meaningful change, and all at a faster rate of implementation.
At Onneer we like to take a wider capability approach when looking into knowledge gaps using our capability model: People, Process, Data and Platform because the knowledge gap is bigger than any one role—it’s also about enabling the ability to bridge the gap and doing so while understanding the why and the how.
Using these four pillars, we can identify the crux of the issue so we know where to focus our energy.
This article covers a four-step approach on how to take advantage of knowledge gaps through the implementation of models as a communication tool to engage users and create a level of common understanding across your organisation.
This will move you towards a solution of communicating, engaging, connecting with, and empowering your users to use the tools available confidently and effectively.
My suggested approach is to model (versus “muddle”) your way through.
Models allow us to describe real world phenomena as simple visualisations and in doing so, they provide accessibility, allow for differences in approaches across individuals within our organisations; facilitate the ability to communicate fast; and they break through language barriers that using words alone present.
Roger Tomlinson the father of GIS even wrote about this in Thinking about GIS. To paraphrase, he stated that GIS is too complicated for a single definition. That’s why it needs a model.
So here is our step-by-step approach for modelling your way through once you have identified a knowledge gap.
Step 1. Finding the knowledge to close the gap
The first step involves finding the knowledge to bridge the gap and documenting said knowledge.
This is where you research, and get the information in one place including the what, why, where, how and who.
Your research can start in the form of surveys, engagement, desktop research, to understand the current functionality being used, and the desired functionality. Your research should then shift to the understanding the knowledge that will boost your capability to include the desired functionality. Documenting this information is the second half of this step.
You’ll want to get ALL the information in once place on paper, electronically in a word document or whatever your process might be. Get it all in one place so it isn’t just in your head.
The value of this step is that following its completion, you should have usable documentation that provides the information and knowledge to use the additional functionalities identified as valuable for your organisation. And by going through the process of collating and researching the information, you will also have gained knowledge and understanding, in turn empowering you to become an authoritative voice on the topic.
And for those of you who’ve made the leap of closing your own knowledge gap, you have the added benefit of knowing which piece of information pushed you across the line and into understanding the topic.
This will be useful for the next step!
Step 2. Workshop that knowledge into something visual
This step can be tricky if you’ve not done it before and can be a bit overwhelming because simply, you’re just not sure where to start.
My recommendation is for you to approach this dilemma as you would making a GIS product, map or web app by asking: what’s the context of this information, what are we talking about, and who’s the audience we’re communicating with?
Once you have an answer to those questions, we can combine that information to ask one question: at what level or scale does this model need to communicate?
To answer this last question, you can refer to this model in Figure 1, which indicates three key options we can use and where they sit in relation to strategic focus and technological focus.
First is the conceptual model which is strategy driven and doesn’t give much if any focus to the specific technology being used. For this option, your model might be focused on how your organisation, or how a function of your organisation operates. A conceptual model I’ve used recently shows where core feature layers sit in terms of an organisations structure.
The second model is logical (Figure 2) which focuses on activity and might help you to indicate the logical flow of a process, or the logical decision-making pattern that supports a business process. a recent example is a model that shows the shift in workflow for Web Apps vs a web map in Field Maps.
Lastly, the technical model focuses on specific details or tools within a system and may break down the differences between two discrete tools, or maybe specific instructions. Another example being a model to outline the steps and key considerations on how to generate a feature layer view.
After considering the knowledge you’ve documented in the previous step in the context of scale using these three options, you might decide that you need more than one model. Sometimes, we need all three so that we can communicate the right information to the right people.
Once you have a list of models; the type of model you’re hoping to use, and the information that the model needs to communicate, let those creative juices flow. We recommend you follow the “lean or just enough” principle and aim for simplicity because the simplest models are often the best ones. And remember, it’s a first draft—it doesn’t need to be perfect.
If possible, try and keep this stage to yourself, or just one other person. The fewer people involved at this stage, the easier, and faster you can move on to Step 3.
Step 3. How do you know if it fits?
In GIS we LOVE things to be as the most correct as they can possibly be and it’s something that’s impossible to achieve because it’s a never-ending problem when you intersect science with art.
However, we’re not looking for the most correct. We’re looking for the best fit, the simplest way to make it make sense to your audience. This isn’t about providing the Holy Grail of GIS information; this is about setting a base line so that individuals are equipped to make changes, and do their jobs better.
Peer reviewing is an invaluable tool when it comes to models. We all look at things so differently, and you need to consider the different perspectives, perceptions and approaches that others will bring to your model.
At Onneer, we’ve got incredible diversity in our team full of individuals with a solid understanding of GIS, mixed with a breadth of experience in various roles in various industries and organisations.
I lean on them when I go through this process. Always.
This stage is where you ask your peers to review your work, followed by you re-working it, and this process continues until it makes sense to your intended audience.
As you start to show it to people and explain your model, two things will happen.
The first is that you’ll identify the key parts of your model that other people don’t relate to, or immediately understand.
The second is that you’ll start to fall into a rhythm of explaining your model. You’ll talk about it in a certain way, or use certain words, or use the same flow as you walk through it, and this will form the basis for your messaging, and how you package your model.
Step 4. Get it out there. Now.
This is often the hardest step, particularly in large organisations struggling with silos, but getting it out there and getting people seeing and understanding and using the model is the empowerment in action.
This is critically important.
Change management strategies and methods can be useful at this point because that knowledge will help you understand how change averse staff are, where they sit on the adoption curve and the barriers to entry.
Your early adopters who are the most up to date, with the most current information, will likely find these resources on their own, and start implementing the work.
But for those less inclined, you’ll refer them to the resources and soon, you’ll find staff doing the communicating themselves, passing this information between themselves, and empowering each other.
Not only will this start to close the knowledge gap, it will promote a common vocabulary to continue building knowledge on, and it opens a key pathway for communication moving forward, making it easier when the next knowledge gap is prioritised.