top of page
Writer's pictureJacinth Paul
Nov 4, 20227 min read

Central Knowledge Repository for Decentralized and Asynchronous Communication in Web3 Projects


Central Knowledge Repository for Decentralized and Asynchronous Communication in Web3 Projects
Source - Freepik

Executive Summary


A Central Knowledge Repository (CKR) or a Wiki is the first step in enabling decentralized decision making and asynchronous communication (async) work effectively in web3 projects. While addressing the challenges of having different time zones, geographically distributed team members and work dependencies, its more important to have project knowledge centralized as a single source of project status and truth. Having knowledge centralized can also significantly reduce the ramp-up time for new joiners, improve quality of deliverables, and ensure project continuity. Acquiring, transferring, and maintaining project knowledge is critical to project performance which the Central Knowledge Repository detailed here precisely focusses on. Various information to be included in such repositories are detailed along with associated benefits and some of the risks involved. This repository shall be handy to the team members, managers and other stakeholders interested in the project and its progress.


Problem Statement


Any web3 project team members should be able to effectively and autonomously carry out the activities and tasks allocated to them, to create the deliverables and artifacts, once the sprint backlog or activity list is agreed upon. However, there are downtimes in project work during the execution phase related to various factors[i] like communication issues, delayed decision making, lack of sufficient training, dependencies on few resources, lack of connection between systems and processes, lack of alignment between product, engineering, or design etc. which can affect the overall project in multiple ways.


Some of the real-time cases are mentioned below:

  • Few team members work in opposite time zone and cannot join all the meetings

  • Unable to find details on how the previous developers performed certain activities.

  • To meet a critical milestone few new resources are added and need a ramp up

  • As a transition checklist, for a team member or a project manager to go through.

  • An external reviewer/project team member need to understand the development process

  • Project is dependent on critical resources who are unavailable for a crucial activity.

Solution: A Central Knowledge Repository (CKR) or a Wiki


A Central Knowledge Repository (CKR) or a Wiki is a comprehensive and descriptive work area set up in Notion or Confluence or any suitable location accessible to all project team members. This repository needs to guide the team members throughout all the activities and tasks required to meet the project objectives. Based on empirical research it should contain all information necessary for a project team member with a basic working knowledge to perform work and enhance asynchronous communication in a cross functional team setting. The CKR is an attempt to make the project work truly decentralized by making all the knowledge and project status available for decision making at individual and team levels.


From the details of the latest product status, work instructions, key decisions, key file locations, tools and environment used to available work instructions, process flow, lessons learnt, project management information, stakeholders, metrics and dashboard links, and all relevant information along with any deviations or open items which need to be highlighted shall be made available in a consolidated manner. The objective of creating and maintaining a CKR is to help the project team to complete all the activities in the execution phase of the project life cycle with minimum guidance and support for asynchronous communication. The CKR is in line with lean and agile software development practices in trying to eliminate wastes along with amplifying the learning and optimizing the whole process for effective async working.


Central Knowledge Repository: Indicative Sections


The information available in the Central Knowledge Repository shall be adequate for a team member to perform an activity communicating asynchronously and autonomously. The sections provide details necessary to carry out the activities and wherever possible refer to the primary project documents and status reports, work instructions, training material, etc. The details shall not be duplicated from primary project documents but rather just provide a reference in most cases, unless necessary to provide a clear picture. The CKR captures all the required details at one place so that it provides a complete context, linkages between activities and process flow. The Knowledge artifacts and details captured needs to be self-explanatory.

  1. Inception & Project Section: This section contains an overview of the project, the objectives, business case, level of activities and the approach followed in the project. Links to project roadmap, training materials, block diagrams, project success criteria, inputs and related details to be mentioned to give an overall understanding of the activities involved.

  2. Requirements Section: High level activity details should be captured on what the project does and does not include. The more details included in this section, the better the product to avoid any confusion from project team members and stakeholders. Reference to the product backlog, release backlog, priorities etc. shall be provided.

  3. Reference documents/Templates: All the input documents required to perform the activities shall be listed in this section, which includes the applicable PRD documents, supporting materials, Templates, Checklists like the DoD and DoR, Traceability tables and all other project documents, standards, regulations, guidelines, customer documents etc. which are referred in the project.

  4. PMO Information: The high-level project management related information which the team needs to be aware while carrying out the activities shall be captured. The applicable Status Reports, Project Metrics, Basis of Estimates, Project Schedule, Milestones list, Assumptions and constraints, Baselines and all associated cadence details etc. followed in the project.

  5. Project Activities: This section contains an exhaustive list of all activities to be carried out. Each of the activity to be listed sequentially along with a brief description of activity and steps to be followed, process flow diagram, samples of relevant previous artifacts for reference by providing sufficient and complete information for any team member to perform the activity autonomously.

  6. Supporting information available, the paths to the activity description, training material etc. with exact sections to be referred shall be mentioned. Wherever available, reference to activity attributes shall be provided to completely understand the work requirements along with their context and impact on other activities and overall project. Details on where to find information of applicable change requests, change log and status details need to be included for reference. References to the work instructions for all the tools, user manuals, installation guidelines, etc. need to be provided along with any project specific custom settings and configurations.

  7. Quality Assurance: An overview of the quality assurance and quality control measures applicable to the project need to be mentioned. Jira links to details on open defects with severity and priority needs to be available. Any additional project specific guidelines shall be captured along with any deviations from organization quality standards. Details of Quality metrics and how they are calculated in the project shall be provided. Involvement of specialist quality members and external auditors, the associated process and cadence details shall be captured. In web3 project smart contract audit process requirements and readiness reviews need to be highlighted.

  8. Communication: Details of the sprint or program reports, stakeholder distribution lists, stakeholder matrix, key circulars and mails ensuring continuity and decisions taken, location of the MOMs and relevant details like the frequency and the format shall be captured. Project team directory with all the email ids and contact numbers to be included in this section.

  9. Risk Management: All the knows issues, listed risks along with any contingency measures shall be captured. Location of the risk register if available, details of previous risk assessments during meeting or audits related information need to be provided.

  10. Stakeholder Maps: The team structure, point of contact details, RACI if available shall be included for ease of reference. Key responsible personnel details for dependent activities need to be highlighted and captured.

  11. Lessons Learnt: A quick reference to all the previous lessons learnt along with location of lessons learnt knowledge base to be included. Details of the issues, comments and corrective actions taken will be provided. Location of RCAs, Review checklists, Process improvement recommendations etc. shall be captured.

  12. Open Items & Deviations: This section includes reference to all previous open problem reports and issue logs which are not yet resolved. It also includes items like acceptable, deferred and closed issue items. Any deviations from standard practices shall be exclusively captured.

  13. Appendix - Obsolete Items List: All the details which go obsolete, will be removed from the above sections but still be captured for later reference as a separate appendix. This will be helpful to have a record of the project history.

Note: Wherever possible only the location of the primary artifacts would be provided. Depending on the size and complexity of the project or necessity, additional sections can be added.


Business Benefits and Beneficiaries


The Central Knowledge Repository would be handy to team members for decentralized decision making and asynchronous communication which is common in web3 projects. It serves as a reference to project team members a single source of truth and status. the CKR also provides other secondary benefits like for cross trainings and for new members as the ramp up time can be reduced significantly by effectively capturing all the necessary information. It minimizes the project wait times and dependencies.


This Central Knowledge Repository can be used in cross functional training where team members can acquire skills and get familiar with all the activities involved in the project. Succession planning, Knowledge transfer and autonomous working are other key objectives which can be met with the CKR. The Central Knowledge Repository enhances business continuity which can be beneficial to the team and the project manager as they execute the project work.


Conclusion


Having the primary objective of the Central Knowledge Repository in mind, which is, providing all the information necessary for decentralized decision making and enabling any web3 project team members to perform the project activities in async with minimum guidance, autonomously, only relevant details need to be captured. The risk of making an endless or lengthy documents or sections will be counterproductive and needs to be avoided.


As a best practice, the Central Knowledge Repository shall be updated continuously throughout the project lifecycle as a live project artefact. In addition, every team member who joins in or moves out of the team can ensures the document is up to date with all the new learnings, gaps, and applicable changes. Make the CKR an entirely standalone document which consists all the required and only the required details for the project team to perform activities autonomously with asynchronous communication and enabling decentralized decision making.


Reference list

23 views0 comments

Related Posts

See All

Comments

Subscribe to PSHQ

Thanks for submitting!

Topics

bottom of page