top of page
NEW ROM LOGO_FINAL_ENGLISH_Artboard 1 copy 11.png

Challenges and Strengths - What to Do with Them?


Three people stand at a forked road with signs saying "KM Success" and "Strengths." The road is marked "STRENGTHS" and "CHALLENGES."

Knowledge management projects are inherently complex. They require changing work habits, but more importantly, they involve changing attitudes. Not everyone naturally wants to share knowledge, especially at the expense of other activities they engage in daily.


At the beginning of knowledge management activities and during implementation, we typically examine the organization's strengths and, challenges (strengths and weaknesses) to understand where we can expect difficulties. "Information is power" or "I don't have time for knowledge management because I'm overloaded" are concerns expressing challenges. Most challenges raised are not unique to the organization where they were observed. They are familiar across a wide range of different organizations, with each having its nuances and emphases. We assume that approximately 75% of challenges are similar, and only about 25% are unique to the specific organization (on average).


So, after identifying the challenges and strengths, the key question is, what next? What do we do with them?


Here is a four-tiered proposal for the recommended use of knowledge accumulated during the diagnosis of strengths and challenges:

  1. Choosing a solution at the "possible" level that doesn't conflict with strengths and challenges: Example: In a public organization, including educators afraid of computerization, we developed a very user-friendly and clean portal design-wise, even at the expense of functionality. In a high-tech organization, conversely, we sacrificed beauty and "space-taking" design and preferred to include more content, as people are intolerant of not finding content immediately. Another example: In a unit where users were overwhelmed by excess computing tools and therefore feared knowledge management as a whole, we set up a simpler solution, based on Office, to give the feeling that we didn't bring another new system.

  2. Grading the implementation of the solution according to strengths and challenges: Example: In an organization composed of factories that developed hidden and open competition over the years, we began with knowledge sharing within each factory (despite the main goal being inter-factory sharing). We accustomed users to sharing in general, and only in the second stage did we move to cross-sharing. Another example: In an organization that wanted to learn lessons, and we adapted a solution integrated into work processes (including documentation and lesson learning on the go), we encountered difficulty learning lessons stemming from a lack of logical inference skills (creative rather than engineering-oriented people). Therefore, we diluted the supporting templates do not include learning questions at all, and only after three months, after they became accustomed to the documentation function, we added learning questions.

  3. Implementation techniques adapted to different groups: Example: In several organizations, we implemented an implementation technique where implementation planning was done by each department manager separately using a standardized template with selection options. The manager provided their emphases, according to which a specific implementation plan was tailored to that group, addressing their challenges and integrating them into their work structure. The manager signed off on the plan. Implementation rates increased significantly because of its customization and the manager's commitment to who built it.

  4. Risk management as part of project management: Here are 2 examples of challenges and the appropriate risk management approach (presented in tabular form):


Avoiding

Avoiding

Risk

Challenge

Ongoing Monitoring by Reports

Creating positive competition and emphasizing success stories

Failure to start work during extreme rush hour Sharing responsibilities with managers in relation to other tasks

Emphasizing user benefits

Lack of Use of Knowledge

Work overload, lack of time, a priority order where knowledge management is not at the top

Adding resources for more setup support

Transfer of responsibility to the body that establishes a work plan with them

Analysis of Non-Cooperation Factors and Appropriate Conduct

Failure to cooperate at the time of establishment

Work overload, lack of time, a priority order where knowledge management is not at the top

An application that allows for maximum copying between technologies

Tiered solutions (not everything from day one)

Unnecessary cost

Complex and Changing Technological Infrastructure

We hope we've demonstrated how to make the management of strengths and challenges more practical.

Good luck!


 

Want to learn more about knowledge risk management?

Here are some articles you might find interesting:

Comentarios


bottom of page