Enterprise Knowledge CEO Zach Wahl speaks with Sierra Woods, Public Servant in the Canadian Government.

In this conversation, Zach and Sierra discuss how to facilitate and “design” KM conversations to ask the right questions and reach the “a-ha” moment, developing durable skills in a hybrid work environment, what KM can do to help organizations thrive during periods of turbulent change, and what Sierra is looking forward to at Knowledge Summit Dublin.

For more information on Knowledge Summit Dublin, check it out here!

If you would like to be a guest on Knowledge Cast, contact Enterprise Knowledge for more information.

The post Knowledge Cast – Sierra Woods at Canadian Heritage appeared first on Enterprise Knowledge.

“I am most excited to hear from our speakers on how human-centered design techniques can be applied at the cross-section of Knowledge and Information Management to harness the power of context.” – Taylor Paschal

All are welcome to attend a portion or all of the event from 10:00 AM-6:00 PM ET for free, virtually, by registering at Richmond World IA Day. In addition to the Conference Program below, further details may be found on LinkedIn.  

The post Taylor Paschal to Facilitate World IA Day 2024 Richmond appeared first on Enterprise Knowledge.

No matter whether you are a consultant, an individual contributor, or a manager of a technical team, we all find ourselves explaining what an ontology is, how it will benefit an organization, and the best ways to get started. While this blog focuses on tips and examples for explaining ontologies, I’ve found these tips helpful for any conversation explaining semantic concepts.

Set Intentions and Outline the Big Picture

Every successful presentation or productive conversation begins with setting and recognizing intentions. Understanding both your own, and your audience’s intentions will help you to tailor your message and ensure understanding.

As a presenter, what outcomes am I looking for from this discussion?

As an audience member, what are they looking to learn, understand, apply, or receive? 

There are many reasons why ontologists and other semantic SMEs need to explain ontology, including interviewing for a new role or job, pitching new project ideas, getting funding for new tools, and growing their teams. In each of these situations, the audience may need to understand the essentials of ontologies to varying degrees, and it is the role of the presenter to ensure that the audience’s specific level of understanding is reached.

For example, I’ve been working on a project recently that sought to solicit funding for ontology management tooling to support federated data access and governance across a large organization. The project lead needed a strong case to present to leadership to elicit support and funding. In this case, their WHY is not just needing tooling, but needing tooling to support critical business processes (federated contributions to the ontology) in an approachable way, thus embedding governance directly within the daily workflow. 

A common mistake is diving too quickly into the weeds, without first framing the discussion for your audience. For many of them, a lot of the topics you will touch on may be new to them, or still mainly theoretical in nature. It’s your responsibility as the presenter to do your best to ensure they can take a theoretical concept from your presentation and apply it to their work or their projects. There are a few questions that I always ask myself to help craft the big picture:

1.  What do you need out of this conversation?

Are you looking for alignment on terminology? Resources for a new project? Sharing best practices? A detailed modeling conversation? Funding for an ontology management tool? 

2.  Who is your audience?

Are you presenting to Data Scientists? Ontologists? Executives? What is their background and what level of understanding do they walk in with?

3.  What do they need to know in order for you to achieve your goals or to answer your question?

Our project lead above was looking for funding for new ontology management tooling and in order to elicit support, they would need to explain the need, the business value, and likely some technical concepts like RDF, OWL, or SHACL to describe what the tooling is ultimately for. Depending on the audience, the amount of explanation in each area may vary. 

Drive Interaction and Engagement

Now that you’ve set intentions and outlined the big picture, it is important to keep this vision in mind throughout the conversation. There are specific actions you can take within a conversation that help to achieve this goal.

Use examples, anecdotes, and visuals

Never underestimate the importance of being able to tie conceptual conversations to practical, day-in-the-life examples. If you are trying to gain alignment across an enterprise on the importance of using ontologies for data standardization, for example, remind your audience of real life examples of messy, duplicative, or hard to find data. Show them how having a single definition of a data element across all departments will add value in reporting across functions, as will having a 360 degree view of your customers, data, or technologies. For example, if you have multiple systems that produce or consume customer data, the same attribute may have many names depending on the system. An ontology can help to standardize this data across systems by creating a single definition and common, human-readable name for Customer Phone Number.

Anecdotal, real-life examples are critical for ensuring your audience walks away with a practical understanding of how your presentation applies to them.

Co-create and make your audience part of the conversation

In addition to anecdotes and visuals, guide your audience through hands-on activities that apply the complex concepts of ontology design, tooling, or governance. This not only helps them better understand, but also gives them a sense of ownership in the final outcome – they’ve had a hand in reaching the goal. For ontology design, this might be a quick demo of an initial design, live prototyping of a feature that will help them complete a task better in the future, or an activity to collaboratively define personas and user stories. 

Engaging your audience isn’t limited solely to the initial conversation, but is also relevant when following up after the conversation. Re-engaging your audience after the initial conversation might include sending updates after a tool has been acquired, inviting them to demos or to participate in design, and sending memos about the outcome of the ontology after it’s been “realized.” 

Pause often and check in on your audience

Last, but definitely not least, build in time to pause and give your audience time to digest, to ask questions, or to repeat back to you, in their own words, what they have come to understand from your conversation. Remember an audience member’s intention and background when answering their questions (i.e., try to think about what they need to know rather than what they are specifically asking). When formulating your response to an audience member’s question, think about the following prompts before jumping into the details:

Why might they be asking this question? 

How does it relate to their goals? 

What do they need to know from my answer to achieve their needs?

Remembering both your own, and your audience’s intentions from beginning to end will ensure a more productive conversation built on solid understanding.

Following these tips have helped me to have productive conversations with non-technical audiences about very complex topics related to ontologies and knowledge graphs. For more tips, or for help presenting the business case of knowledge graphs, tooling, and more, reach out to us and learn more.

The post How to Explain Ontologies to Any Audience appeared first on Enterprise Knowledge.

Too many organizations think of gamification as a single and complete solution to overarching change management. They assume that gamification techniques and activities can drastically change mindsets and behaviors overnight simply because they are fun and competitive. Programs that start this way typically fail. Instead, we at EK approach gamification differently. We treat gamification as the use of design and insights from games to help develop knowledge and foster ability of (KM) behaviors and processes. Further, we continuously encourage our clients to consider gamification from the perspective of the end user. The focus isn’t just on the competitions themselves, but on human-centricity and the various behaviors that can be incrementally encouraged and rewarded over time. By balancing competition with collaboration, we can place appropriate emphasis on features that genuinely capture end users’ unique motivations.

Recently, EK developed a three-part pilot series to help a client’s Help Desk team successfully create user-centric documentation. Realizing that our recommended process for documentation was vastly different from the process currently being used by the Help Desk, we leveraged gamification techniques to help support and encourage the adoption and sustainment of the new documentation process. Help Desk team members were involved from the very beginning of the process and frequently provided feedback, which prevented us from “self-hugging” (designing for yourself instead of your end user) and creating a gamification program that didn’t resonate with the intended users.

Our initial series of work contained:

• A list of the most challenging and frequent incidents facing the Help Desk;
• A pilot that worked to ensure that all individuals were aware of the new documentation process; and
• A final pilot where team members could “compete” against each other, leveraging the newly understood documentation process to develop incident resolutions that would bring immediate value to the team.

Additionally, all throughout these pilots we incorporated classic games, such as Ninja, Cowboy, Bear and Back-to-Back Drawing, with a KM spin to sustain high-levels of engagement and to energize the group.  

Sound like fun? The following is how EK recommends an organization begin to implement gamification techniques to support a change management effort:

• Be Agile: Start small. We do not recommend applying a blanketed gamification effort to an entire strategy implementation, especially if it is the first time an organization is incorporating gamification. Instead, we recommend that organizations identify either a single process or behavior to target, such as tacit knowledge sharing. Then organizations should collaborate with users to develop a proof of concept (PoC) or minimum viable product (MVP). Further, organizations should validate and test the PoC or MVP. Do not be afraid to rework, retest, or completely start fresh. Since gamification is highly dependent on the user’s acceptance of a product, it is imperative that organizations be patient and agile when developing and implementing gamification techniques and plans.
• Understand Your User: Identifying and understanding a user’s motivations, frustrations, and goals is critical to achieving meaningful gamification that garners acceptance and is capable of generating value for end users. More often than not, users will only engage in gamification if it satisfies a combination of their internal and external motivations.  Therefore, utilizing design thinking principles, such as User Personas and Journey Maps, will help to ensure that each game is being designed for the users and not the creator.
• Know Your User’s Environment: This is where organizations consistently miss the mark. Instead of integrating gamification into their current systems or processes, organizations spend thousands of dollars building an additional gamified platform, believing that an elaborate platform will be enough to entice users. Sadly, this approach is often only capable of producing initial buzz because employees feel overwhelmed and experience technology overload shortly after the launch. For this reason, EK works to specifically develop gamification roadmaps that are designed for employees’ most frequent environments, such as SharePoint or ServiceNow. For instance, if users typically work in SharePoint, we recommend building a dashboard or gamified page within SharePoint. This method makes it easier for an employee to adopt a new process because it does not require significant changes to their day-to-day activities.
• Play to Your User’s Learning Style: Lastly, and most importantly, one must play to the end user’s learning style, especially when utilizing gamification to increase adoption for a new process or to enhance organizational learning and development. If an end user is more analytical, then try to incorporate points and badges. If an end user is more “big picture,” leverage a narrative or “story” approach. This is why EK recommends that  organizations begin their gamification thought process with user personas because they help to identify trends, themes, and end users’ specific learning styles.

Gamification is not going anywhere. While organizations are beginning to realize that gamification needs to be more than a combination of technology and rewards, most organizations struggle to identify how to evolve and merge their gamification efforts, especially with broader Change Management. Through EK’s expertise and passion, we have helped our clients deliver meaningful gamification to support the adoption and sustainment of their new Knowledge Management strategies and initiatives. Struggling to gain adoption of your organization’s latest changes? Think gamification might help? Contact us today for assistance.

The post Complement Your Change Management Efforts with Gamification appeared first on Enterprise Knowledge.

This approach leverages both top-down engagement (generally more human factors such as interviews, workshops, and focus groups) as well as bottom-up analyses (typically data driven aspects) in order to develop a taxonomy design that is intuitive and will be embraced by the average user, but is also representative of the organization and its contents, and flexible enough to adjust as the organization changes. Nearly two decades ago I coined the term “Business Taxonomy” to reflect that concept of a user-facing taxonomy. I find the term no less appropriate now as it was in 1998.

All taxonomists, as well as many consultants in the broader Knowledge and Information Management consulting arena, should be familiar with the data driven aspects of taxonomy design. Key inputs for analysis include:

• Existing Taxonomies – Most organizations possess existing taxonomies, whether they call them that or not. Even the structure of “organically grown” file shares can provide meaningful inputs on potential taxonomy terms and key metadata fields.
• Usage Analytics – A host of user analytics can be extremely valuable to the taxonomy design process, including most popular search terms, most popular content, and common navigation paths. Referral terms from public websites may provide another important input.
• Competitive or Collegial Taxonomy Designs – Given that many taxonomy designs are surfaced as navigation or facets for public findability, a myriad of existing taxonomies are readily available for those who know how to look for them, even if they aren’t published as such. Though these can be valuable, I generally offer the same warning I do with “off-the-shelf taxonomies.” There is a place for them to expedite industry standard taxonomy designs, however, this is not generally the starting point I recommend to an organization attempting to design a new Business Taxonomy, as it can lead to unnecessary entrenchment. In other words, organizations can get stuck attempting to adjust an existing taxonomy to their needs when it would’ve been more efficient and more effective to design their own starting from a white board.
• Content Analysis – A review of the actual content/information/products/people for which an organization is seeking to develop a taxonomy is another key aspect for analysis. The specific user needs and business cases will determine how deep such an analysis needs to go and how exhaustive it should be. We generally begin with a semi-random sampling of content and assess it based on existing tags, placement, usage, and a characterization of topic, type, and other TO-BE attributes.

Managing these data and analysis driven aspects of taxonomy design is only part of the puzzle. What many taxonomy design efforts lack is the human side of the design. This piece of the puzzle is just as important, if not more so.

At its core, what we’re discussing here is usability and findability. Taxonomies today are no longer just for librarians and information specialists. Based on the maturation of content and document management technology as well as an improved awareness in the industry as a whole, organizations are more often leveraging taxonomy to drive user-focused findability. In many cases, taxonomy is now driving the complete navigation of a site or system. Beyond faceted navigation or enhanced search results, an effective taxonomy can drive the design of an enterprise system, as it has done with the National Park Service’s Common Learning Portal.

That is where the art of taxonomy design comes into play. In order to design a usable and intuitive taxonomy that may be leveraged to drive the overall structure and findability of a site, we must engage with the actual end users.

Engaging directly with the end user can help to:

• Identify key attributes (metadata fields) and potential starter terms that reflect the natural language of the organization;
• Work through organizational misalignments to obtain consensus on attributes definitions and terms;
• Find terms that are critical to inclusion as well as those that need to be avoided;
• Pave the way for adoption of the new taxonomy by communicating it, helping everyone to understand its value, and giving stakeholders an opportunity to influence its design;
• Identify additional starting places for more bottom-up analyses;

I’ve written about our standard workshop practice, but that is just one of the many ways to engage with end users in a top-down approach:

• One-on-one Interviews – Typically most effective with stakeholders and senior leadership within an organization to identify critical inclusions/exclusions and understand overall project goals and user needs;
• Focus Groups – Centered around a particular function, geography, or product category in order to elaborate on an existing design; and
• Enterprise Workshops – Focused on breaking down organizational barriers to define and prioritize a broad set of Primary Attributes.
• User Workshops – Driving a cross-section of actual system contributors and/or end users to define attributes and terms natural to them.

Central to these top-down design approaches that engage directly with stakeholders and end users is the need for a strong facilitator.   The mission of the taxonomy design facilitator is to give voice to all contributors while helping to drive toward meaningful consensus and buy-in.

Effective taxonomy design facilitation and workshopping will provide you a truly usable design that reflects the needs of your users and your organization. It will also provide a constituency that is bought in to the new design and the value it can hold.

Like many KM initiatives, buy-in and communications are just as important as the actual design (of the taxonomy, or the system as a whole). Change management is critical to success, and developing a design/system that users actually want to use and feel as though they had a hand in creating is an important aspect of this change management.

As you begin your next taxonomy design effort, make sure the people leading it are experts in facilitation and communication as well as data analysis and taxonomy design. If you’re looking for a complete solution to your taxonomy design effort that covers both the art and science of taxonomy design, contact Enterprise Knowledge.   We will work with you from start to finish to give you the design that works for your organization and your users.

The post The Art of Taxonomy Design appeared first on Enterprise Knowledge.

Myth #4: Agile only works when people are co-located

I hear a lot of people tell me that they want to move to an Agile approach, but they can’t because their team is not co-located. This is one of the more frustrating misconceptions I hear. Too many organizations miss out on the benefits of Agile because of statements like this.

Is it true that Agile practices are best implemented in a co-located environment? Yes.

Does that mean you cannot gain benefits from Agile practices when your team is geographically disbursed? No.

The geographic divide creates challenges, but they can be addressed. The three biggest problems caused by geographic separation are:

• Communication
• Collaboration
• Planning

Communication is one of the most important factors to Agile success. Frequent discussions allow people to make quicker and more informed decisions. Geographically disbursed teams cannot interact as easily. My teams address this through technology. We select an instant message tool so that the team can quickly chat with one another. We use a video chat tool like Skype or Google Hangouts to simulate face to face communication. Finally, we use desktop sharing tools like join.me or Google Hangouts to “show” other team members what we are working on. The video helps with meetings to make sure that everyone is engaged and paying attention to what is being said.

The best Agile teams work closely together. Improved collaboration is mostly about coaching. It is important to get everyone on the team to think collaboration first. First, I find times and places to encourage the team to speak with one another. Typically I encourage quick meetings or fun events so that everyone is comfortable reaching out to one another. Second I look for opportunities to show team members where they would have more success or save time by collaborating with a teammate or the product owner. Regular, positive reminders help separated team members to think “collaboration first.”

Planning is harder when people are separated. Hallway conversations allow people to prepare for planning meetings and that doesn’t happen with geographically distributed teams. In-person dynamics make meetings run smoother because people can gauge other people’s reactions. To account for this, as part of scrum, I schedule a quick pre-planning meeting so that everyone on the team has a chance to understand the backlog and the product owner priorities before the formal sprint planning meeting. When people are remote, things run smoother when they are given that time to plan.

Geographic separation definitely makes Agile more difficult. However, don’t pass on the benefits of Agile delivery just because teams aren’t co-located. Geographically disbursed teams can still make use of Agile with a little extra work and effective use of technology.

The post Top 5 Agile Myths: Myth #4 Agile Only Works When People are Co-located appeared first on Enterprise Knowledge.

Myth #2: Agile teams are made up of only developers.

Many of my clients make the mistake of thinking that Agile teams are composed solely of developers.  The assumption is that everyone has to do development so everyone must be a developer.   Not only is this approach wrong, it actually slows down development.  The best way to plan your development team is to understand each individual’s function.  A good development team has everything and everyone they need to deliver a working piece of tested, documented, deployable software.

A development team needs to provide fully tested software.  Who better to be involved in producing properly tested software than a person with deep testing experience?  Development teams that have people with testing expertise prioritize tested software and deliver cleaner code.  Whenever possible I ask my clients to include a tester on the development team.  In addition to the obvious advantage of better tested software, the tester can become a liaison to the testing team when the software is formally tested.  This increases trust between the development team and the formal test team.  It also encourages more collaboration so that issues are resolved more quickly.

Larger development projects also require documentation and analysis throughout the project.  A development team that includes a strong systems analyst does a better job of interpreting user stories and documenting both the final design decisions and how the system works.  In my projects I also use the analyst as a person who can fill in the gaps of the project so that the developers can focus on building workable solutions.

The last requirement is the ability to create deployable software.  Including a team member who understands software and hardware architecture ensures that the product can be deployed and that it will stand up under duress.

As you put together your development team, remember that everyone on the team contributes to the success of the project.  It is important to select a diverse group of people to get the best product, but you also need to make sure you have people who can contribute to every sprint.  Add people with diverse backgrounds and encourage them to try new things.  Ask your analyst to help out with product configuration or simple coding in their spare time.  The architect can provide code or documentation and the tester can help with analysis of the stories.  Cross-training of this type often leads to unexpected efficiencies and discoveries.

Remember, don’t make the mistake of thinking more developers = more product.  A diverse development team improves the overall quality of what the team produces and speeds delivery.

The post Top 5 Agile Myths: Myth #2 Agile Teams are Made Up of Only Developers appeared first on Enterprise Knowledge.