Knowledge Portals are some of the most exciting and promising emerging KM solutions. They create new capabilities to deliver a wide range of unstructured content, structured data, and connections to people and resources in the context of user’s work. Over the past year, my team has been working on one of EK’s largest implementation projects to date; we designed, built, and deployed a Knowledge Portal for a global investment firm to provide a 360-degree view into its operations and investment lifecycle.
At the project’s onset, I was presented with the opportunity to act as the KM Lead to help guide the team and our client in KM best practices and align the solution to business needs. My role later evolved to include SCRUM Project Owner responsibilities as well, working with multiple stakeholders to establish priorities for development and paving a path for our development team to release valuable iterations of our solution.
The journey of developing a Knowledge Portal has had its ups and downs. There were also many hidden dangers, latent mistakes, and sudden risks along the way. It could have been very easy to go down the wrong path and waste our team’s efforts and resources. In this blog, I will share 5 of the lessons I’ve collected over the past year in the implementation of a Knowledge Portal – hopefully these will serve you well in your own Knowledge Portal journey.
1. Pragmatism Over Idealism
When we first begin talking about Knowledge Portals with our stakeholders, you can see their eyes illuminate with thrust open doors of opportunities. Business leaders and their staff have so many needs and ideas that could potentially be addressed through a Knowledge Portal.
However, Knowledge Portals are highly complex solutions that incorporate multiple technologies and data from upstream systems that must all work in concert to achieve stakeholders’ needs and expectations. Throughout the development of the Knowledge Portal, we ran into a multitude of blockers, some outside our control, and many of which prevented us from achieving our initial priorities.
In the spirit of Agile, our team’s focus was to deliver value and results as early as possible, so we got creative. Features that were once fourth on our backlog rose to the top. If we had stayed the course and worked to remove immediate roadblocks, we may have delayed our releases by half a year. Showing early business value was critical to sustain engagement with our key stakeholders and maintain the project’s momentum. Our first release incorporated all of our underlying technologies, giving us a very solid foundation to release further functionality quicker in the future.
2. Content Quality and Governance Takes a Front Seat
A Knowledge Portal is a powerful tool to surface content and data that was previously “locked away” in information silos, guarded by bureaucracy and obscure procedures. We knew from the beginning that displaying accurate and reliable content and data would be a key to the Knowledge Portal’s success.
Throughout the development process, we found that some of the data was not ready to be displayed on the Portal. This slowed us down, but we worked with different data owners to help fix the erroneous data. To be fair, prior to the Portal, it was cumbersome for them to get a holistic view of their data, especially if it was spread across multiple repositories. The success of a Knowledge Portal is dependent on the quality, consistency, and accessibility of the underlying content and data. It is critical to plan for this, and to expect time and effort for cleanup and enhancements. To an extent, our development of the Knowledge Portal encouraged our client to find solutions to some of their data quality issues, as well as create new processes and guidance on data management. This process ensures that data is maintained and users perceive it as being reliable.
Expect issues with data and content quality. It will be helpful for you to know who data owners are and to have a protocol in place for raising and escalating issues when they occur. This is something I would recommend doing early on in the project – at the kickoff, or before, if possible. Later, incorporate data checks throughout the entire development lifecycle; use actual sample data in design wireframes, get previews of data during development, and dedicate time during testing to validate whether the incoming data meets user wants and expectations.
3. Technical Partnerships Are Key
Given the complexity of Knowledge Portals, it can be a humbling experience to tackle their enterprise development. It is difficult for any one person to have the depth of expertise in the range of knowledge domains it covers: UX, taxonomy and ontology, search, strategic business alignment, data management, content modeling, systems infrastructure and architecture, and many more.
A successful Knowledge Portal implementation requires a combination of design, business, and technology skills.. While I could focus on some of the definition and prioritization of use cases and features, my technical partners could focus on the nuts-and-bolts of how these features would come together. This being said, the idiom “it takes a village” really applies to the development of a Knowledge Portal. Being part of the EK Team was a real advantage because of the quick access to a depth of expertise in every necessary aspect to build a Knowledge Portal: UX designers, engineers and developers, data scientists, ontologists and taxonomists, technical analysts, and Agilists to support our work.
There were a few additional technical partnerships which were key to the Knowledge Portal’s success. Our relationship with infrastructure and security teams facilitated our adherence to internal standards and requirements that the Portal needed to meet. Although we are technology-agnostic, our partnership technology vendors facilitated our work as well.They aided in both maximizing the use of the features of each individual component of the Knowledge Portal and the expedited resolution of any unforeseen issue or question that our development team had.
Just as important as it was to bring data and content together in the Portal, we brought together disparate teams and individuals to make the Knowledge Portal a reality.
4. Early Technology Choices Are Critical
When we started the project, the organization lacked the full suite of technologies needed to implement the Knowledge Portal, so one of the first steps we took was defining and prioritizing business and technical requirements. We then took a close look at the leaders in each of the spaces to evaluate and choose the technologies that would satisfy these requirements.
Even though early iterations of the Knowledge Portal did not make full use of each of the technical solutions’ capabilities, smart choices early on future-proofed our Knowledge Portal. The technologies, coupled with our design approach (focused on solving business problems as opposed to delivering features), resulted in an easily extensible Knowledge Portal. As new requirements come up, we have been able to fulfill them without the need for further technology investments.
As we move forward, I am sure new requirements and priorities will surface that will necessitate the incorporation of the latest technologies; however, I am confident our experts will provide guidance to stakeholders on emergent technologies that can continue to extend the overall solution.
5. If You Build It… They May Not Come
Being a KM practitioner, I find the concept of Knowledge Portals thrilling. Most people in an organization will not share this sentiment, and it will lead to disappointment if your target users are not adopting and frequently using the solution you’ve been working on. I’ve found users mostly want to get on with their work, and changing habits is hard. Even if you are providing them with new capabilities for their teams, they may not have the additional attention and energy to embrace a new way of doing things. Deploying any new KM system requires a robust change management and communications strategy to drive adoption of tools and healthy KM practices.
For success on any initiative of this scale, change management and communications is critical. We worked together with our stakeholders and users to establish a virtuous cycle of feedback, where our development is now more responsive to users’ needs, while at the same time able to comprehensively communicate the value and expectations of the Knowledge Portal.
We assembled a cross-functional group of stakeholders to inform our design and refine our messaging and promotion around the Knowledge Portal. We also leveraged different data and knowledge management stakeholders to champion our cause and help articulate to their colleagues the value that the Knowledge Portal brought to their team work. Ultimately, we need to demonstrate how the Knowledge Portal is not only aligned to the overall organization’s strategic objectives, but how it will make each individual user’s life easier.
The development of a Knowledge Portal is quite the endeavor. It requires the effort of a multidisciplinary team to get all of its components working in harmony and aligned to tangible business objectives. If you are considering implementing a Knowledge Portal in your organization, please contact us! We have quite a few more lessons to share.