Oops! (Learn from My KM Mistakes)
Oops! #1. Keep KM assessments SHORT BUT MEATY
My first KM audit consisted of several forms that took three batches of middle-level managers one whole afternoon per batch to fill up (it was a very large organization of more than three thousand employees). It worked because the organization is a vertical one: all I needed was an order from the CEO and everybody just obeyed. My next client was an Asia-wide regional company whose value proposition was driven mainly by a dominant layer of expert technical and professional staff. This group strongly objected to answering several forms and wasting one-half of their valuable day answering questionnaires! I ended up designing a one-page (legal size) questionnaire they can answer in less than 30 minutes. I also changed the frightening term “KM audit” to a milder, broader and less technical “capability assessment.” After a few more clients, our assessments at CCLFI.Philippines had become leaner and meaner, or SHORT BUT MEATY.
Oops! #2. A KM champion is COUNTERPRODUCTIVE in an organization divided by factionalism
I was a believer in looking for an internal KM champion. I also believe that KM cannot and should not be “consultant-driven.” It worked very well for us until one day when we had a client organization beset with deep factionalism. We sat down with one of the vice-presidents who appear to be the leading informal KM advocate and offered that he take on the role of THE KM champion. He refused because he said it won’t work. He explained that whatever he espouses will tend to be rejected or perhaps even sabotaged by the other faction!
Oops! #3. Don’t promise a “KM SYSTEM”
The high-sounding term “KM System” is a good marketing ploy but it can lead to an implementation nightmare. Because the meaning and scope of “KM System” is vague to most clients, they will tend to interpret it as broadly as they want. The result is “scope creep“: the scope of project deliverables gets wider and wider in the mind of the client. My lesson is this: don’t use the term “KM System” at all, but if the client asks for it, then define your deliverables and their specifications very clearly, concretely and operationally.
Oops! #4. Ownership can be DOUBLE-EDGED
It works often to have a KM program “owned” and driven by one of the managers: he or she has a formally designated and clear responsibility over the program. In one of my clients, the program owner (an Asian) invited me to comment on his KM program. I did, very candidly and directly. Apparently, he took it personally and after that, he did not hire me anymore. Lesson: the process of giving feedback can be more important (especially to Asians) than the content of the feedback.
Oops! #5. Documentation can STIFLE innovation
Business processes, if not documented, can lead to arbitrary changes (e.g. when a new boss comes in), long learning curve for new employees, obscure parallel pathways (e.g. invented by corrupt managers for their personal benefit), confusion (customers take circuitous routes), etc. Documentation is definitely a plus. For organizations aiming for ISO certification, documentation is a must. However, documentation can “rigidify” a process, e.g. process improvements and innovations have to go through bureaucratic approvals by a distant authority. One of our solutions is to help a client develop and learn to evolve a “Learning-Oriented Systems Manual.”
Oops! #6. Redefining the business model is a TOP-LEVEL decision
We had a client, a subsidiary company, which hired us for a strategic planning exercise. One of the results of the exercise was a recommendation, with good reasons, from the subsidiary to their mother company, that their business model be redefined. It was disapproved by headquarters, which did not share the proposition from the subsidiary that a different business assumption can be better. Our lesson: redefining a business model is a strategic decision that properly belongs to top executives at the highest levels.
Oops! #7. A client who is an IPR grabber
A global development institution wanted us to provide them with an online e-learning package in basic KM. We had earlier developed this for another client. There is a big “fly in the ointment”: they will own the IPR (intellectual property rights) and we will not be allowed to sell the same service to other clients for X years thereafter. We asked them to remove the offending contractual provision. We said we are like a restaurant selling only the food, but we are not selling them our kitchen and recipes! And certainly, we want to continue selling food to other clients. They refused. So we said, how about we give you the service pro-bono (for free) and we don’t sign any contract? Their counterproposal was still essentially “IPR grabby” and so we terminated the negotiations.
Oops! #8. CoP portal before community building
We helped a loose network of NGOs set up their CoP portal, with the help of Phase 1 money from a donor development institution. Phase 2 money was for community building, but the money never came. As a result we set up a portal nobody hardly ever uses! When our next similar project came, we learned from our mistake: we started with community building first. We looked for enthusiastic network members, invited them to form a portal design group and then asked them how we should design the portal: what information do they need most, what functionalities do they need, what name do they give the portal, who will volunteer to help update content, etc. It worked better!
Oops! #9. Client wants QUICK results
A client is interested in training for Team Learning. Based on a prior experience with another client, we submitted a proposal for several two-hour sessions stretched over several months. The client wanted only one workshop session for one or two days. We explained to the HR director of the client organization that Team Learning skills require several sustained interventions. We said that our objective is to ensure effectiveness. In the end, we had to break off the negotiations because there was no meeting of minds.
Oops! #10. Client is focused SOLELY on technical deliverables
A foreign consulting organization, our prospective client, won a big computerization project for a big government agency that is well-known to be graft-ridden and colluding with some private interests. The client approached us for KM and change management specifically to (a) clarify the range of user needs and requirements, and (b) facilitate organization-wide acceptance of the IT system. During the negotiation it became clear to us that the client is too much focused on technical deliverables. The deliverables, as they specified, are feasible. However, we explained that there are risks (e.g. some people may sabotage or delay project components) that need to be addressed, otherwise we will convert a graft-ridden organization into an IT-enabled graft-ridden one. There was an understandable hesitance to address unknown or unclear non-technical issues, and to keep to known and clear technical issues. In the end, we decided to pull out of the negotiation because the likelihood of being part of a failed or questionable project is high, and we do not want to deviate from our CCLFI policy of “being part of a client’s success.”
Oops! #11. A government procurement office seems to be waiting for a BRIBE?
A government agency approached us for designing, setting up and training staff for a nationwide computerized M&E system. After our technical proposal was discussed and basically approved by the agency, it has to pass through the Procurement Office of the Ministry to which the agency belongs. Months pass without any action from the Procurement Office. We decided not to personally follow-up the paper work and just wait. The client agency, which was getting impatient with their own Procurement Office, called for a meeting. New requirements were made during the meeting, which we subsequently satisfied. More months passed and almost a year had gone. On the meantime some senior consultants have become unavailable or have pulled out because they cannot continue to commit to a project which is uncertain if and when it will start. In the end, we wrote the government agency that we are no longer interested in waiting and we are formally withdrawing our proposal.
In fairness to all concerned, “waiting for a bribe” is only our guess. We are not absolutely sure. The only thing we can be sure is that processing of this project contract is too much delayed.
Oops! #12. An “OLD BOY NETWORK”?
We participated in a bidding for a regional KM project. I was very pleased with our proposal, which described a multi-level learning, CoP and IT-enabled processes. After submitting our bid, a friend who knows the client warned us that this organization is run by a manager is part of an “old boy network.” The bidding was declared a “failure” and a re-bidding process was opened. We then discovered that a new rule was adopted which in effect disqualified our organization. I emailed a complaint to the Bidding Committee. It was useless. Of course, we did not or could not participate in the second round of bidding.
One year later, I saw a document describing the KM project of the same regional agency. It looked very much like what we had in our proposal. I really felt very bad, but I since I cannot be absolutely certain what really happened, I had no choice but to accept what happened and learn from it.
Oops! #13. Foreign exchange RISK
CCLFI won a project funded by a bilateral development donor agency. The project was not denominated in Philippine pesos, but in a foreign currency — the currency of the donor country. During the October 2008 -January 2009 global financial crisis, foreign exchange rates were very unsteady. As a result, CCLFI lost almost PhP 0.4 million. We asked the donor agency for help, but to no avail.
Oops! #14. STEALING our project design?
A multinational insurance company wanted CCLFI to give their employee association officers a workshop. We submitted a proposal. The HR executive wanted more details about our workshop design. So we detailed the workshop design and re-submitted the proposal. We never heard back from them, despite calls and emails. The CCLFI Managing Director and I suspected that we gave too much information in our workshop design that the company may have felt they can do the workshop themselves and do it without our assistance. We had our suspicions, but of course we were not 100% certain.
Oops! #15. Computerizing an UNDOCUMENTED/non-formalized business process
We won a KM project through a bidding process that disallowed communicating with the client organization. We had to prepare our proposal based only on the tender documents made available by the bilateral donor agency. Part of the project is training in computerizing a selected business process. We assumed — wrongly — that the client organization’s business processes were all documented and formalized. Consequently, we had to devote extra time (and extra cost to CCLFI) in teaching the client business process improvement/simplification and process documentation including drawing work flow charts, document flow diagrams, formalizing decision protocols and data flow diagrams. Only then can we proceed to the computerization stage.
Oops! #16. WHOSE SIDE should we take?
We won a KM project for a development donor agency. One of the project components is a workshop with best-practitioner leaders in community-based resource management. We learned much from this workshop: the “view from the grassroots”, the qualities of successful community leaders, and the differences between how the grassroots leaders and the donor agency view the projects. The last learning gave us some trouble. We took the side of the leaders when they decided at the end of the workshop to craft a Manifesto that they requested CCLFI to bring to the donor agency. The Manifesto called for changes in agency policies. After the project was over, I personally requested a meeting with the Board chairperson and gave him the Manifesto with my own explanation. To make the long story short, the Board chairperson and the agency director rejected the Manifesto. I felt bad; we all felt bad. Was it a mistake on our part that we took sides? Personally, as a matter of principle, I will do it again: I will take the side of the community. But this means that I should never sign a project contract where I will have to choose between a donor agency’s policies and what beneficiary communities feel about those policies.
Have you experienced other lessons and mistakes from your KM practice? Please share it for the benefit of other readers. Use the Reply box below and let us have more Oops!.
Check also the page “Tips for KM Consultants #1: During Contract Negotiation”.