This document provides an overview of a presentation by Todd Fahlberg and Madison Jaronski on taking a thoughtful approach to KM technology. It discusses assessing the current people, processes, culture and technologies that make up a KM ecosystem. It emphasizes understanding business drivers, putting KM in terms of results, using an iterative approach, and active communication. It outlines a 4 phase approach to selecting KM technology: 1) Gathering requirements and defining personas, 2) Leveraging data driven evaluations like demonstrations and proofs of concept, 3) Combining quantitative and qualitative data for decisions, 4) Crafting an implementation strategy for success and adoption. Key aspects discussed include change management, communications, training, and governance.
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
Give the People What They Want: An Approach to Thoughtful KM Technology
1. GIVE THE PEOPLE WHAT THEY WANT:
A THOUGHTFUL APPROACH TO KM TECHNOLOGY
Midwest KM Symposium 2020
By: Todd Fahlberg and Madison Jaronski
May 19, 2020
2. @EKCONSULTING
MADISON JARONSKITODD FAHLBERG
KM Technical Consultant Senior KM Analyst
Areas of expertise:
KM Technical Strategy &
Implementation, Enterprise Search,
and Semantic Technologies
Areas of expertise:
KM Strategy, User-Centric Design,
and Gamification
3. EK AT A GLANCE
60%
40%
STABLE CLIENT BASE
50+ EXPERT CONSULTANTS
CommercialFederal
7 AREAS OF FOCUS
▪ KNOWLEDGE MANAGEMENT STRATEGY & DESIGN
▪ TAXONOMY & ONTOLOGY DESIGN
▪ CONTENT & BRAND STRATEGY
▪ TECHNOLOGY SOLUTIONS
▪ AGILE TRANSFORMATION
▪ CHANGE MANAGEMENT
▪ KNOWLEDGE GRAPHS, SEMANTIC MODELING, AND ARTIFICIAL
INTELLIGENCE 25+ COUNTRIES
GLOBAL REACH
WITH CLIENTS IN
BASED IN DC
4. KNOWLEDGE MANAGEMENT
INVOLVES THE PEOPLE,
PROCESS, CULTURE, AND
ENABLING TECHNOLOGIES
NECESSARY TO CAPTURE,
MANAGE, SHARE, AND FIND
INFORMATION.
5. DECONSTRUCTING KM
PEOPLE
• Flow of knowledge
through the
organization.
• Knowledge holders
and knowledge
consumers.
• Understanding of state
and disposition of
experts.
PROCESS
• Existence and
consistency of
processes.
• Awareness of and
adherence to
processes.
• Quality of processes.
CONTENT
• State and location of
content.
• Consistency of
structure and
architecture.
• Dynamism of content.
• Understanding of
usage (analytics).
CULTURE
• Senior support and
comprehension.
• Willingness to share,
collaborate, and
support.
TECHNOLOGY
• Maturity of “KM
Platform” or ”KM
Ecosystem”.
• Integration with and
between systems.
• Usability and user-
centricity.
@EKCONSULTING
6. KM ECOSYSTEM - LOGICAL ARCHITECTURE
Content Management System
Used to author, organize, manage, and publish content on a web interfaceCentralized UI
Repository Layer
Web Content
Management
Enterprise
Search
Learning
Management
Analytics Layer
Taxonomy
Management
Document
Management
Instant
Messaging
Findability Layer
Ontology
Management
Collaboration Layer
Content Creation Layer
Document
Sharing
Annotation /
Feedback
Chat Bot
Team
Workspaces
Reporting Usage Metrics Content Metrics
Governance Layer Workflows Records Schedule Access Controls Information Audit
WYSIWYG Editor Digital Asset Editing
Alerts /
Notifications
Recommendations
APIs
Displayed below are the layers needed for a best in class Knowledge
Management and Information Management Ecosystem.
Knowledge
Graph
Customer
Relationship
Management
Digital Asset
Management
Component
Content
Management
Metadata Layer Auto-Tagging / Auto-Classification Auto-Categorization
@EKCONSULTING
7. Why KM Technology Efforts Fail
▪ Missing Vision
▪ Mistaken Faith in Capabilities
▪ Lack of End User Engagement
▪ Too Much Theory, Not Enough Business
▪ Excessive Complexity
▪ Insufficient Understanding of Current Technology
Ecosystem
▪ Lack of Sustainment / Governance
WHY WE NEED TO BE THOUGHTFUL
@EKCONSULTING
8. BE DELIBERATE WITH KM
ASSESS PROGRESS
AND ADJUST
UNDERSTAND
THE BUSINESS
DRIVERS
PUT KM IN TERMS
OF RESULTS
LEVERAGE AN
ITERATIVE
APPROACH
ACTIVE COMMUNICATION
AND DIALOGUE
@EKCONSULTING
10. Because of a Knowledge Graph…
Recommendation Engine
Use Cases
TOP-DOWN ANALYSIS
• Human-driven, facilitated workshops, focus groups, and
interviews with end-users, initiative stakeholders, and
administrators of the potential technology solution.
• This approach is designed to create buy-in and achieve
alignment for the enterprise components of the solutions,
while ensuring all stakeholders are appropriately
represented and “heard.”
BOTTOM-UP ANALYSIS
• Deep analysis of individual documents/data, document/data sets,
and existing applicable repositories or systems.
• This approach is designed to ensure initiative stakeholders
possess a firm understanding of the existing technology
ecosystem as well as the content (data or documents) that will be
ingested by the potential solution.
@EKCONSULTING
11. DEFINING REQUIREMENTS
FUNCTIONAL REQUIREMENTS:
-------
Identifying what a technology should do,
or challenge it should solve, is a critical
first step to take when defining
requirements.
Functional requirements
are postured to not only validate the
strength of a technology but to also
measure non-technical users’ ability to
understand and utilize a platform with
minimal training.
-------
Examples:
• Live editing (collaboration)
• Report generation
TECHNICAL REQUIREMENTS:
-------
Understanding how a technology should
perform is just as important as functional
requirements to ensure the solution
meets user needs and limits disruption to
the organization’s ecosystem.
Technical requirements are complex in
nature as they are unlike functional
requirements because they cannot easily
be demonstrated to normal users.
-------
Examples:
• Hosting location (on-prem or cloud)
• Programming language
EXPLORATORY REQUIREMENTS:
-------
Selecting technology using present-time
requirements leaves the possibility open
for a selection to be made based off
reactionary decision making.
Exploratory requirements provide insight
to a solution’s community, the vendor’s
business model, and requirements that
may not naturally be defined as functional
or technical.
-------
Examples:
• Pricing Model (cost per user)
• Sustainability (support, scalability)
@EKCONSULTING
12. PERSONAS & USER STORIES
PERSONAS:
Put a face and a name to the users we are
working with and designing a vision for.
Talking about personas as real people helps us
better understand their goals, frustrations, and
their motivations.
As a <role of the user>, I want <desired feature> so that <the why/end-goal>.
USER STORY:
Short, simple description of a business need or function requirement written from the perspective of the end user.
Helps deliver the highest value early in development by focusing on incremental user needs and facilitating
communication and collaboration.
@EKCONSULTING
14. EVALUATION PROCESS OVERVIEW
Various activities exist to validate solutions against Functional, Technical, and Exploratory requirements.
The most effective methods include solution demonstrations and proof of concepts (PoC).
@EKCONSULTING
DEVELOP VENDOR
RATING RUBRIC
Define Participants for
Demo and PoCs
CONDUCT VENDOR
DEMONSTRATIONS
Prepare vendors for
demonstrations
SUB-TASKS
TASKS
PERFORM PROOF OF
CONCEPTS
ORGANIZE FINDINGS
Complete Demo Rating
Rubric
Complete PoC Rating
Rubric
Analysis & Research
Vendor Demonstrations
Demo Rating Sheets
PoC Rating Sheets
Requirements Evaluation
15. VENDOR GRADING RUBRIC
A Vendor Grading Rubric provides
those that are validating requirements
a centralized location to capture their
feedback.
The rubric is leveraged during
demonstrations and interactions with
the vendor or solution to compare and
contrast findings.
@EKCONSULTING
16. PROOF OF CONCEPT RUBRICVENDOR DEMONSTRATIONS RUBRIC
Objective
Transform demonstratable requirements into an easily
consumable list of instructions to inform the context of each
session.
Best Practices
§ Remove sales-talk from the meeting
§ Prep the vendor in advance
§ Develop and align the vendor demonstration script with the
vendor demonstration rubric being utilized by the audience
Sample Validation Criteria
§ Ability to Meet Requirements
§ Meets Requirement and Appears User-Friendly
§ Meets Requirement
§ Meets Requirement After Development Work
§ Does Not Meet Requirement
Objective
Provide a contextualized environment that enables end-users to
test and validate a solution against requirements.
Best Practices
§ Ensure PoC environment and requirements are aligned and
meet communicated expectations
§ Test in advance of asking others to conduct validation
Sample Validation Criteria
§ Platform User Friendly Evaluation
§ This Requirement Was Easy To Validate
§ I Had Trouble Validating This Requirement
§ I Experienced Extreme Difficulty Validating This
Requirement
§ Not Applicable
“Things that are easy to use should be easy to explain” @EKCONSULTING
18. QUANTITATIVE VS QUALITATIVE
@EKCONSULTING
QUANTITATE DATA is defined as the value of data in
the form of counts or numbers where each data-set
has a unique numerical value associated with it.
Examples:
• Vendor Demonstration Results
• Proof of Concept Rubric Results
QUALITATIVE DATA is defined as the data that
approximates and characterizes and can be
observed and recorded.
Examples:
• Interview, Focus Group, and Workshop
Anecdotes
• Observational Analysis Notes
• Personas & User Stories
Simultaneously leveraging qualitative and quantitative data can
help you uncover both ‘the what’ and ‘the why.’
19. MOSCOW PRIORITIZATION APPROACH
MoSCoW Approach
§ Must Have: Critical to the business process /
solution / end-user(s). If not, the KM Technology is
considered a failure.
§ Should Have: Important, but not crucial for the KM
Technology. Considered top “nice-to-haves.”
§ Could Have: Desirable, but not necessary for the
KM Technology. Considered low “nice-to-haves.”
§ Won’t Have: Least critical or even not aligned with
the KM Technology goals and overarching strategy.
Absolutely necessary for
success.
Wouldn’t be helpful. Lets
not do it.
Nice to have, but can
wait.
Necessary, but not
immediately.
MUST SHOULD
WON’TCOULD
@EKCONSULTING
20. 3D VALUE PRIORITIZATION
Business Value vs. Technical Complexity
vs. Foundational Value
§ Business Value: Likelihood of increasing
revenue and/or productivity. Degree to which
aligned with Brand.
§ Technical Complexity: Cost, time, and effort.
Ability to integrate with existing systems.
Performance, scalability, and productivity.
§ Foundation Value: Likelihood of increasing
operational efficiency and collaboration. Degree
to which aligned with organization goals.
@EKCONSULTING
21. 4D VALUE PRIORITIZATION
Business Value vs. Technical Complexity vs. Foundational Value
vs. Employee Value
§ Employee Value: Likelihood of increasing engagement as a result of increased
relevant functionality and content as well as accessibility.
@EKCONSULTING
22. KEY CONSIDERATIONS
FOR KM TECHNOLOGY
PROCUREMENT
▪ Confirm & Validate technology and security requirements
▪ Prioritize the needs of the end-users
▪ Consider cost over 3-5 years versus initial purchase price
@EKCONSULTING
25. BUILDING A CHANGE PLAN
ADDRESS
FEAR / CONCERNS
• During change, people most
fear what they are going to
lose.
• What are professionals afraid
of losing?
• How can we tell them “we hear
this is important to you?”
CREATE ENERGY &
DEMO
• Why KM will make people’s
lives easier everyday.
• Who can get this message
across and how will they get
this message across?
• Where and when can we
demo?
PRIORITIZE
TRANSITION SUPPORT
• Too much effort dedicated to
creating the “new thing.” Too
little effort given to transitioning.
• This is where/why 70% of
change management initiatives
fail.
DOUBLE LOOP
LEARNING
• We need a mode of receiving
feedback and reporting out
what we did with the feedback.
When building a Change Management Plan to
support the implementation, adoption, and
continuous training of your KM technology, it is
important to consider these four components.
Your Change Plan should also be designed to:
Align with the strategic goals of the organization.
Define measurable goals that can be tracked over time.
Engage business users from the outset and maintain
their engagement at every stage.
@EKCONSULTING
26. COMMUNICATIONS AND TRAINING PLAN
C-SUITE EXECUTIVES &
EXECUTIVE SPONSOR BUSINESS OWNER
TECH LEAD END-USERS
IDENTIFY KEY
STAKEHOLDERS & USERS
COMMUNICATIONS TRAINING
@EKCONSULTING
The truth is, no major technology investment is a
turnkey solution. Planning, communication, and
commitment are essential to organization-wide
adoption.
Components of Communications Plan:
• Identification of Key Stakeholders and Users
• Identification of KM Tool Champions
• Document Key Information & Draft
Supporting Communications
• Initial Announcements
• Major Implementation Milestones
• Training Schedules
• Requests for Feedback
• Build a Timeline / Map Communications
• Incentivize / Double Feedback Loop
Prior to implementation, create a training plan that
anticipates the needs and reactions of system
users.
Components of a Training Plan:
• Identify all users and define each of their
unique learning needs
• Review/Identify a training budget
• Design the training to include:
• Business rationale
• Explanation of how their
participation/role will make themselves
and the organization successful
• Take a blended approach (classroom
and on-the-job training)
• Opportunities for feedback
• “Test-drive” the training to “power-users” / KM
Tool Champion Team
• Deploy training
• Provide informal and formal continuous
learning opportunities
27. WE’LL BE ANSWERING QUESTIONS NOW
Q A&
THANKS FOR LISTENING
Q & A SESSION