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.
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
28 Design Principles for a Knowledge Management Community
|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|