Many knowledge management projects fail because they require people to do more things in their day to day. The implementation of any QA initiative requires basic knowledge of Change Management and process improvement.
Knowledge management is full of expensive corpses: documentary systems that no one uses, procedures that no one applies, intranets that only serve to teach in conferences and a long etcetera.
In this type of project (and in its cousins of quality management) there is a basic error: they fail because they require people to do more things in their day-to-day (fill in a form, encode a document, document a fact). They also fail because they do not take into account the first question that we all ask ourselves when faced with any initiative: "What does this give me?"
If the user response is "more work" the project will surely fail.
It is a mistake to think that this attitude can be counteracted with communication about the benefits of the new system, with training on how it is used or with incentives to participate.
Specialists will tell us that we are dealing here with a typical change management problem: “ How do I get people to do their jobs differently and / or to do more? "
It is understood that if we are promoting or "selling" in our organization the application of a procedure or system that affects a work process it is because previously we have asked ourselves the 2 magic questions:
- What are the key processes that add value to my organization? How can I improve them?
This implies that we have rethought, analyzed, rethought and simplified any process before proposing a procedure that affects it. It also means that we have selected some of all possible processes.
The fewer the better.
Non-return question 01: Is that so? Does the new procedure or system respond to a "reengineering" or prior analysis of the adequacy of the process?
- If the answer is "NO", what you are trying to implement will surely fail to involve more tasks than I already do. Return to the exit box. If the answer is "YES" (that is, we have rethought and simplified the process before developing and selling the system), we will only get it to be used if we have involved users, customers and final sufferers in that analysis. We advance two squares.
So we already have a simpler, more effective and theoretically more profitable key process for the organization. Now it's time to develop the system that supports or supports it to get a real advantage. Of course we will have asked more questions:
- What knowledge is necessary? What knowledge is generated? How can I manage it? How much will it cost me? Is it profitable?
Suppose we have answered all these questions and have decided (with the approval of the above) to go ahead. I shoot because it touches me. We fall into the well and find that the system fails.
Non-return question 02: have we involved end users (in sufficient numbers and with different profiles) throughout the solution design process (be it a procedure, be it a document management system, or any other knowledge)?
- If the answer is “NO”, the procedure will meet resistance that will not be overcome neither with training, nor with incentives, nor with threats. It will require “going backwards” and review it step by step with a selected group of users. This will slow down the project and increase its cost. Back ten boxes. If the answer is "YES" (that is, we have not only simplified the process with the help of those who apply it, but we have also had the final recipients of the system in its design) we will find a winning product in our hands. Advance to the Goose.
Do not forget that…
- Nobody likes to be told that their way of acting or working does not work or is wrong. Therefore, any change project must be based on external reasons (market needs, arrival of new technologies, etc.) so that people understand the need for a change. It is also not welcome that they tell you that you have to change several or many things you do That is why it is best to start only with those critical aspects of the process that need to be changed. The fewer the better. Once these changes have been internalized, we can go for others. It is essential that the change be sponsored by "those from above". But it is equally essential that it is not perceived as an imposition, but as a need based on very clear factors (profitability, customer needs, etc.) and well communicated.One of the fundamental premises for a system to work is that its users have participated from the beginning in the entire design and development process. No one knows more about something than who has to use it.
