Company-Wide Rollout: Forming a Knowledge Council
Knowledge Council Basics
Definition
Knowledge Council: A group of representatives from each of the departments or teams that are using Guru, who meet regularly to maintain Guru at the highest level and ensure it is serving the needs of each and every department.
How It's Formed
Approach 1: Top-Down
Management chooses a group of people who will be in charge of this.
Recommendation: Choose from representatives of different teams that are represented in Guru: e.g. one person from Sales, one from Support, etc.
Approach 2: Bottom-up
Council forms organically from the people who use Guru the most or are most passionate about it.
Recommendation: Borrow from KCS and do an organizational network analysis to find the people who answer questions; leverage them to create the council. If not all teams are represented, create a Slack channel or other such communication channel so that all team members can talk to the Council.
Example Council Responsibilities
Each council is different, with different perspectives and use cases represented, so the list of responsibilities is highly situational. Typical examples include:
Check on and take actions to maintain governance standards (Examples listed below)
Assigning knowledge domain owners and holding them accountable for items like Trust Scores, Adoption, Card Template creation
Going through the maintenance checklist:
Tag Manager: check for new/uncategorized Tags
Card Manager:
Check for Cards not on a Folder - decide if it makes sense to put them on one
Identify and support those who are not verifying their content in a timely manner
Verify your own Cards, perhaps in a sprint where everyone does it together as part of the regular meeting
Analytics
Review Searches Producing No Results and assign Authors to create content to fill these gaps
Review Most Popular Cards and advertise to the team (using Knowledge Alerts)
Post a Guru tip in Slack or recognize a high performer/Guru win
Any other governance guidelines you've set in place
Meeting regularly (ie monthly) to coordinate on Knowledge Management projects
Communicating with CSM for consultation on long-term projects
Governance Standards
It's useful to establish a clear set of Standards and expectations for how you want your Authors and Collection Owners to manage knowledge in Guru. Here are some examples of standards you can consider. The numbers in green are up for negotiation depending on your circumstance.
Examples:
Trust score no lower than 80% per collection
Average verification interval: quarterly or more frequently
User adoption: >90% Monthly Adoption
Cards that have been left unverified for 60 days will be archived
Cards with no views in the past 180 days will be archived
Consider a variety of filters to identify cards that should be archived. For example:
Less than 3 Views or Copies in the last year
Cards that have been created but were never verified
Content must be Verified by:
An Individual instead of a Group - We recommend starting with this approach. Useful for assigning responsibility over the knowledge to the Subject Matter Expert who created it. Ensures active participation/simple visibility since their name is visible on the card details.
A Group instead of an Individual - This is useful to prevent bottlenecks, where a single verifier may be out of the office. Also helps distribute the verification workload to a small group of SMEs. However, be careful that users don't think "someone else in the group will do it" and leave their knowledge sitting unverified too long.
Cards must have at least one tag, no more than four tags
No card to be created without being added to at least one Folder, if exceptions apply, spell those out
Set the expectation among users that Guru is everyone’s first place search for knowledge