Archive for February, 2010

T5-5 Expertise Directory with a Twist: “Getting Surprised with Each Other’s Talents”

February 17, 2010

In 2006, I designed and facilitated a KM planning workshop for a new cross-functional KM Team. Among my objectives were (1) to motivate individual team members and (2) to show them in a concrete way the advantages of an expertise directory. I introduced a module that generated so much energy and enthusiasm among the team members that I repeated this module in other KM workshops for other organizations.

This is how the process flows:

  1. Individual seatwork: Each team member is provided a 3′ x 4′ kraft paper (or Manila paper) and a black felt pen. The instruction is: “List down all your talents, both technical and non-technical.” A few members asked guidelines on how to identify their talents. My answers were: “In what tasks/skills do your colleagues often ask you for assistance?” “Recall 1-2 very successful task/projects you did; what talents did you use?”
  2. Public posting: After a team member is done, she/he posts her/his work on the wall.
  3. Comment/feedback on each other: After all team members’ work had been posted around the walls, each team member is given a red (or any colored) felt pen, goes around and reads everybody else’s work. Anyone can write comments on anyone else’s work, e.g. “you forgot to add skill XX.” “I didn’t know you are good at YY!” “Prove it!” “You are too shy to mention skill ZZ!” “You should have joined Project @@!” Approval of a skill can be conveyed simply by a red asterisk.
  4. Answer comments: A team member, if she/he wishes, can write her/his reaction to a comment using a blue (or another color) felt pen.
  5. Plenary discussion: The team sits down and the facilitator leads a group discussion on insights and learning from the content (output) and process, and how they each felt about the process. As facilitator, I conclude by proposing “Let us collect your outputs and use this as inputs to your internal KM Team Expertise Directory.”

My own insights and learning from this module are:

  • Team members often express surprise at knowing (and at previously not being aware of) many of each other’s talents. For example, they were very surprised that a medical doctor colleague had learned the skill of laying out bathroom tiles! KM is about harnessing talent, and it starts with recognizing it.
  • The module was able to reveal to them the value of an expertise directory, especially one that includes both technical and non technical skills. For example, a non-technical skill (or a skill that does not appear in the ordinary CV or resume) that is useful for the organization is the ability to act as emcee (from “MC” or master of ceremonies) in a ceremony, conference or public event.
  • The commenting process creates a space where KM Team members mutually acknowledge and affirm each other and their skills (this works well when the KM Team members know each other beforehand). It is a process that generates much interactive energy, team building and motivation.
  • The process supports openness about one’s abilities and gaps, at the same time that it reveals individual styles and preferences such as hesitance to publicly announce one’s talents, and personal boundaries in self-disclosure. Such hesitance is acknowledged and respected by the group instead of challenged.
  • All outputs taken together can reveal new systemic insights. In one organization, the CEO herself read the postings and then remarked “We have enough talent to put together a chorale and music band.”

What do YOU think? Tell us.

=>Back to main page of Apin Talisayon’s Weblog
=>Jump to Clickable Master Index

T2-5 Sensing of Client Issues during Contract Negotiation: Some Practical Tips for KM Consultants

February 7, 2010

The previous blog post is about knowledge of what works during contract negotiations. Knowing what does not work (or what are the risks) is also useful knowledge. After going through scores of KM contract negotiations, some successful and the others unsuccessful, let me share with you some of my experiences on what does not (or what may not) work and what are potential risks in contract negotiation.

  • Find out who is the manager authorized to make scoping decisions? cost decisions? the final decision? At the start of the negotiation, ASK WHO are authorized to make the above decisions. (a) If no one in the organization is sure about the answers to the above questions (i.e. their contracting process is not yet standardized), you are in for a difficult and surprise-full negotiation process. (b) What is the INTERNAL POLITICS between them? You may be wasting your time while the managers perform their “power plays” during the negotiation process. If you are able to talk to the TOP EXECUTIVE or whoever will approve the contract, these risks can be better managed. KM projects not supported by the top executive are risky projects not worth going into. (c) If the manager who invited you to submit a proposal and the executive who will approve the contract are not the same person, find out if the latter is aware of the proposal invitation. If not, you can have a problem in your hands. Do not proceed any further until the latter not only knows about the invitation, but is also open and willing to consider your proposal.
  • A client is after a desirable outcome, but you can only guarantee to deliver a set of outputs which contributes towards (but does not assure) that outcome. If the client wants his desired outcome to be your contractual deliverable, then propose instead that you GUARRANTY ONLY THE DELIVERABLES but not his desired outcomes.
  • A client may keep asking details and more details about project methodology, or may want you to specify them in detail in your proposal. Beware: it is possible such a client may not be intending to award you the project or to hire you; he may be intending only to use your proposal to STEAL your methodology and do the project himself without you.
  • If the client is not very definite about what he wants, or if there are differences in understanding of deliverables among the managers in the client organization, or between you and the client, then the deliverables must be specified clearly, CONCRETELY and in fine DETAIL. Avoid general terms with unclear or varying referents, such as “KM system”, in the description of deliverables.
  • Do you have doubts about the way the client perceives and defines his problem? Is the client seemingly fixated in a solution, or seems to have jumped to the solution without being sure what the problem is? Do you sense a risk that the client underdefined or misdefined his problem? If this is the case, propose a two-phase project and commit only to the first DIAGNOSTIC PHASE, the purpose of which is to cleary define what is their problem.
  • There are instances when the success and appropriate scope of a project depends on a decision the client has YET TO MAKE. If so, do not accept this project; propose instead another project to assist the client make that decision.
  • There are instances when the outcome and appropriate scope of a project depends on factors or events that are outside the control of the client. If so, propose instead a RISK ASSESSMENT project, the output of which will be the basis of the client’s next actions.
  • If project tranches are predetermined in amount and paid in a foreign currency, while project expenses are incurred in your local currency, then you shoulder FOREX RISKS. Study the fluctuations of the exchange rate over the last few years. Is it going steadily up or down? Is it steady or does it wildly fluctuate? What is the worst-case scenario during the project duration? How much contingency fund shall you set aside to cover such scenarios? Add this contingency fund in the project cost. Or, propose that the project is denominated in your local currency.
  • There are projects whose scope is not easy to define or anticipate. There are clients who (from past experiences) have a tendency to stretch the scope of the deliverables or to change their authorized sign-off officer to someone who has a different or broader interpretation of deliverables. In these cases, the risk of “SCOPE CREEP” during project implementation is high. Some solutions are: propose to divide the project into smaller-scope shorter-duration phases whose deliverables are easier to define or anticipate, and define the deliverables in a clear, concrete, detailed and unambiguous manner.
  • In a training project, there are clients who will pay you for delivery of the training course, but who also wants to OWN THE DESIGN of the training course and its learning materials. If you are willing to sell your IPR (intellectual property rights) on the design and learning materials, then separate the pricing of the delivery from the pricing of the design. If you are not willing to sell your IPR, then either back off from the contract or incorporate a contractual provision that you retain ownership over all IPR. You can then offer a licensing agreement whereby the client can use your IPR and pay you a per use fee (difficult to monitor use frequency) or an annual fee (a simpler arrangement).
  • If the project is full or partial computerization of a business process which includes financial transactions which are vulnerable to CORRUPT PRACTICES, then suspect that there could be staff members within the organization who will resist or sabotage the project if they are in fact involved in corrupt practices. Project non-completion risk will be high. Perform your due diligence processes more thoroughly before committing yourself to this kind of project.
  • There are organizations whose administrative unit (or whichever unit is responsible for the contracting process) like to take their sweet time nit-picking the details of a contract, wasting much time as contract versions go back-and-forth between you and them. Ask your client what is the typical or average length of their contracting process. If it is unusually long, beware. Ask in advance what are the REQUIREMENTS of the administrative unit. Ask for a SAMPLE CONTRACT and study its terms and conditions. It happens often that the technical people involved in scoping negotiations are ignorant or unaware of the contract requirements from their own administrative unit.
  • Be sensitive to signs that there is FACTIONALISM among the managers. If one faction will engage or hire you, it can happen that the rival faction will not cooperate or support (or may even sabotage) the project.
  • A technically good project proposal may be turned down because its cost is deemed too high by the client. Avoid wasting your time by asking the client beforehand what is his approximate BUDGET for the project (some will tell you but other clients won’t).
  • Schedule of payments of tranches is often flexible and negotiable. The ideal PAYMENT SCHEDULE is one that will not leave your project cash flow negative at any time during the project. A client organization may have a policy of remitting the final tranche 30-90 days after the accounting unit receives the payment order or payment clearance from the unit that receives the final deliverable. If so, add the cost of money and administrative costs of advancing the amount for fulfiling your payables before the receipt of the last tranche.
  • Success of project implementation can depend on COOPERATION of some key staff members of a client. If they are informed about, and better if they are engaged during the project scoping and procedure formulation, then chances of project success is better. If key staff are engaged and interested, but do not have enough time to support the project, then project success can be enhanced by a contractual provision where the client must assign specific staff to devote specific hours per week to perform SPECIFIED TASKS in support of the project.

If you wish to add your own experiences of what does not work or what are the risks during KM contract negotiation, please use the “Leave a Comment” link below.

=>Back to main page of Apin Talisayon’s Weblog
=>Jump to Clickable Master Index