Design Principles for Collaboration and Knowledge Sharing

Earlier in the year I was thinking about how best to establish a knowledge management community for a team of Enterprise Architects. The tool of choice was Microsoft SharePoint. I started by laying out a set of design principles that I felt were appropriate for the community design to adopt. This proved to be a very powerful and compelling technique and allowed many of the design decisions to be taken simply and collectively by exploring the sensibility and applicability of each principle.

The Knowledge Manager’s Handbook: A Step-by-Step Guide to Embedding Effective Knowledge Management in your Organization

Not all principles will apply in all scenarios, but those below will provide a useful starting point / thinking frame should you be presented with a similar problem. They should (of course) also be supplemented with SharePoint design best practices.

Collaboration and Knowledge Management

Collaboration and Knowledge Management

28 Design Principles for a Knowledge Management Community

Name Description Rationale Implication
1 Open by default Access to content is ‘open by default’ Supports crowdsourcing, contribution and re-use outside of team Some restrictions are needed for some areas. There needs to be health warnings for open content that is not fully mature. Protectively marked content should not be stored where this would contravene security policies
2 Agile and Lean by Design Build for simplicity, use Agile techniques to build sophistication driven by identified need

 

Development, maintenance and all other processes are Agile by default

Simpler to manage, quicker to provide a minimum viable product

Start with a limited set of well-defined features and have a process and plan for expansion

Actions should be collated in a backlog and progressed using defined Sprints with clear Sprint objectives and ownership

3 Team based Knowledge Management There is no single knowledge manager. Knowledge Management is ‘collective’ This makes it scalable and ensures group participation Everyone must understand and support the site’s structure and purpose
4 Peer reviewed content Formally published content is peer reviewed and socially rated The team votes on quality and therefore has collective ownership of quality and its maintenance There is a mechanism for peer review and content ranking. There is a quality gate for formal publication
5 Self-contained The site should eventually represent a team toolkit Centralisation of important content saves time We tolerate some degree of duplication of content with other sources.

This will be managed by referring to the sources and adding web-link libraries, or using a wiki tool to build an index.

6 Active lifecycle management Content is curated, weeded, developed, combined An inactive dump of content will soon age and will have limited value A content lifecycle management process and approach is needed
7 Variable Maturity and Quality We need to be able to harvest perfect and imperfect content and recognise variable quality and maturity of content Good enough is pragmatic, aiming for perfection too early will stifle knowledge sharing We need a mechanism and process to recognise various maturity and quality levels
8 Content is easy to find Content is easy to find through intuitive design, good structure, naming conventions and content categorisation and search We cannot have time being wasted through illogical or complex design Well-structured folders defined and setup.

Tagging, search optimisation functionality in place.

Categorisation of new content should be done by both uploader and curator.

Right level of design put into the taxonomy upfront

9 Need for control increases with asset maturity Controls on mature content are higher than those on immature content Change management, content removal etc. must be more carefully applied to mature content to prevent loss Process for ratings and meta-data in place

Content maturity and importance is baked into the lifecycle management and communication processes

10 Trusted Associates Trusted Associates must be able to operate as part of the extended team Architecture may be developed outside of the direct area of the EA team and we need to be able support that and assist with content and delivery quality Some ‘associates’ will operate as de-facto members of the team

Where possible leverage the power of Enterprise Social Networks to help source content

11 Delivery Centric Delivery methodologies and content is central to the design objective Delivery quality and repeatability are key to driving scale and efficiency A central area of focus for this site must clearly be on delivery methodology and artefacts
12 Sales Centric A bid engine is created Speed, quality and consistency of bid responses needs to be actively managed Case studies, USPs, win themes etc. should be collected, centralised and actively managed. This should work for both internal and external customers
13 Innovation Centric Content and crowd-sourcing should be used to improve innovation and ideation Differentiating thought-leadership is essential to growth, both in size and in capability An innovation process needs to be defined and executed as part of the lifecycle
14 One tool As far as possible SharePoint should be used for knowledge sharing Knowledge spread across different systems is confusing and harder to manage Content needs to be centralised from other knowledge management/content repositories.

Use of a central ‘knowledge hub’ needs to be part of our BAU DNA. All shareable content should be in SharePoint and this should be used on a daily basis, rather than mass harvesting at the end of projects.

15 Content ‘status’ is easily determined There is no guess work to understand the current status, quality and maturity level of stored content People need to quickly understand what they are re-using and what caveats / health warnings are placed on re-use of that content There needs to be a clear marking scheme and meta-data
16 Separation of original content Internal original content is clearly separated from external content If storing research / background content, this must not be confused with internal original content There should be clear folder structures and meta-data to prevent confusion of ‘research’ or ‘reference’ material with internal original material
17 Shallow learning curve The site will be usable with very little orientation A complex site with a steep learning curve is a barrier to use Clean and well-structured layout

Orientation session for new joiners / users

Simple training / intro pack for new joiners / associates etc. There should be a ‘how to get started’ section. There should be a ‘go to’ person or a ‘knowledge buddy’

18 Self-service Design for self-service use A self-service ‘kiosk’ will ensure people can speedily re-use content without placing onerous demands for support on the team Clean, well-structured design, open access, clearly marked content. Content should be self-describing and its status and caveats made clear
19 Easily accessible assets Diagrams should be stored separately (in addition to) being embedded in documents Visios and Powerpoint drawings are useful starting points for new projects and should be stored in addition to being embedded in other documents. There should be a centralised ‘diagram library’ for templates

There should be a diagram folder under each project to ensure these are easily found.

20 Clear Exemplars Exemplars are provided / developed to show ‘what good looks like’ Templates and guidance come to life when supplemented with exemplars We need a ‘best of’ section and peer review of exemplars
21 Extensibility Site is easily extensible and is not structurally brittle As we step through various maturity levels the structure will no doubt need to change and be re-factored No hard linking which would be brittle.

Bookmarking will break if content is moved. The basic skeleton needs to be fairly stable upfront

22 Consistent structures Folders (such as Project Folders) should have a defined set of sub-folders If there is complete freedom to create folders, there will be too many variants. A defined set of sub-folders and ‘best practices’ will help ensure consistency Use internal Delivery Assurance processes where appropriate. There should be the ability to ‘break the rules’, but we need some rules to break.
23 Well defined purpose This site is for a specific purpose – knowledge management and content development for the EA team. All tools should have a clearly articulated purpose and usage policy This site should not replace or attempt to recreate functionality already present in other strategic systems.
24 Clearly separated functionality There is clear separation of use and purpose between wikis and document libraries People will confuse what to use when. Proliferation of libraries and wikis will create maintenance problems and difficulties understanding the site’s structure Use the fewest possible components unless this would break another principle.
25 Low Maintenance The site is simple to maintain and requires little administration effort The purpose of the site is to be an enabler for knowledge capture and sharing. It should not become a ‘project in its own right’. There must be clear demonstration of rapid time to value. Time spent on admin should be tightly controlled.
26 Supplemented by smart resourcing Time and resources should proactively be used to tackle any outstanding actions on the site’s development (unless otherwise directed) All team members should be capable of driving forward the knowledge capital and should use any time between projects to improve the site and its content There should be a demonstrable and measurable contribution for any team member to these activities.
27 By architects, for architects Architectural design principles and best practices are used in the creation of the site design and its usage Creation and management of this site should be treated as an architecture product with a cogent methodology and defined outcome Architecture best-practices employed in building the site

Clear transition states identified

Design checked against principles for compliance

Design and usage complies with wider (corporate) policies and standards

Once baselined there is a change control process and (light weight) review board

28 Ease of access to repository Support multiple devices and ‘BYOD’ (Bring Your Own Device) The technology and its implementation should not stifle use of individually preferred tools and ways of working. Site functionality should be developed while maintaining support for mainstream browsers and devices

Further Reading on Knowledge Management and Collaboration