Что не надо делать при управлении знаниями

Не делать свою систему управления знаниями

Во-первых, есть много систем, которые подходят под хранение знаний, например wiki.
Во-вторых, пока будете делать систему управления знаниями, переругаетесь по поводу ее функционала и интерфейса. Когда система будет готова, выяснится что часть людей не хочет ей пользоваться из того принципа, что их требования не были учтены.
В-третьих, пока ее будут разрабатывать, само желание что-то где-то хранить может угаснуть.

Не предопределять структуру, в которую знания укладываются

Нет ничего хуже чем видеть красивое, но полупустое дерево каталогов.
Каждый участник должен иметь максимально простой способ скинуть знания в общий котел. Как их структурировать — разберетесь по ходу наполнения.
Теги рулят, но тут тоже нужно без фанатизма — они имеют плоскую структуру и в какой-то момент начнут конкурировать между собой за внимание пользователя.
Лучше начните с хорошего поиска по контенту.

Не вводить ограничения по доступу на изменения

Ну разве что можно ввести историю изменений.
Таким образом снимается вопрос «а разрешит ли мне система сделать то-то?» — порой сам такой вопрос уже останавливает человека.
Также это позволяет исправлять ошибки в чужой информации.
Не бойтесь, что все участники имеют полные и равные права. Вандалов у вас в компании нет, согласитесь?

Не запрещать выкладывать книги и копипастить интернет

Насчет книг — вопрос копирайтов. Тут можно подойти без фанатизма — база знаний локальная, поэтому правообладатели к вам не придут. Наверняка вы храните книги у себя на харде, так что можно сделать это и в общей базе знаний.

Копипастить статьи из интернета хорошо и полезно. Вы приносите новую информацию — это хорошо. Вы ее выставляете на всеобщее обозрение и предоставляете возможность обсудить ее значимость друг с другом — это полезно.
Возможность каждому участнику вносить изменения может привести к качественной переработке найденного в инете материала. Или его удалению, если вы закопипастили фигню.
Также полезно копипастить что-то из проектной докции, если вы считаете, что это будет хорошим примером. Хотя бы для вас.

Не делать ввод информации обязаловкой

Это очевидно — начнется или выкладка всякого псевдополезного мусора, или поиск причин чтобы ничего не выкладывать. Каждое из этих действий приведет к тому, что базой перестанут пользоваться.
В коллективе аналитиков основной элемент информации — совет. Вот пара вариантов:

• Один аналитик говорит про предметку на своем проекте, другой говорит что у него есть в архивах нечто как раз по этой теме и советует это использовать, ищет и передает первому.
• Один аналитик спрашивает, а нет ли примеров, скажем, схемы взаимодействия участников со стороны заказчика и исполнителя. Ему может ответить аналитик, ПМ или еще кто-то, дать совет и пример.

Вся информация, которая передается от одного человека к другому в этих примерах, является идеальным контентом для базы знаний.

Не считать, что все накопленные знания очевидны

А также не слушать умников, которые говорят, что все накопленные знания очевидны.
Знания становятся очевидными сразу после того, как вы их прочитали — это их свойство.

Не слушать тех, кто сокрушается, что текст на английском

Таких не берут в космонавты.

Не забывать про накопленные знания

Есть такая проблема — кинул текст в базу знаний, и с глаз долой, из сердца вон.
Чтобы про базу не забывали, можно вспоминать про нее на подходящих совещаниях — например, когда на скраме обсуждается как реализовать функцию, отобразить что-то в интерфейсе. При этом можно сообщать, что это уже описано / еще не описано в системе знаний. Если скачать что что-то еще не описано в базе — это галочка тому, кто будет составлять описание, чтобы скопипастить его потом в базу.