Why You Should Embrace Tacit Project Knowledge

Tacit project knowledges is useful only if sharedAs Project Managers, so much of our time to manage project knowledge is focused on documenting explicit knowledge; that is, in capturing lessons learned and updating our organizations’ knowledge repositories. That’s the easy part; it’s process, after all.

In my previous article, This is What Managing Project Knowledge is All About”, I suggested that implicit or tacit knowledge is often more useful than explicit knowledge because it goes beyond just process. It brings wisdom and intuition and experience to the situation. Tacit knowledge truly relies upon utilizing the people aspects of project management.

In that same article I also noted that tacit knowledge is not easily codified, nor do most Project Managers even think to do so. Lessons learned tacitly are best shared through conversation or through hands-on demonstration, while the context of the situation is still fresh in everyone’s experience. I also suggested various forums for sharing tacit knowledge, such as: networking circles, online forums, focus groups, industry meetings, seminars and conferences, workshops, or interactive training.

Because tacit knowledge is knowledge that is within the individual and not easily expressed (“I don’t know why that worked – it just did”), it is imperative that an environment of trust is established so that project staff is open to share. Such an atmosphere engages staff to both share their project knowledge and to learn from others.

Here are some practical examples of tacit knowledge gained from my own experience as a Project Manager and the methods used to share that knowledge:

  • Work shadowing. I had read the project management books. I had participated in our firm’s project management trainings. I had served as the lead for several large project teams. My new promotion suggested that I was ready to manage a large, complex project.

    I arrived on my new project site and began to conduct the project initiation activities with my team. By the time I had been onsite for two weeks, I realized I was in over my head. I was book smart; I was trained in process; yet I was ill-equipped to take on this project.

    I did what any self-respecting newbie Project Manager would do. I called my Senior Vice President and asked for help. In his wisdom, rather than terminating me on the spot, he freed up a very experienced Project Manager and sent him to work with me for as long as required to allow me to manage on my own.

    For one full year I shadowed this experienced Project Manager, learning everything I could about managing large projects. On the day that he returned to his home office, he confidently assured me that I was ready. Not only was I ready, but thanks to his work-shadowing training, I delivered the project on time and under budget, with a very satisfied client.

    Books and training are important and provide explicit process knowledge. But how do you codify the tacit knowledge that I was able to attain through this incredible work-shadowing experience? The knowledge I gained, and that I have since been able to pass on to others, is not found in books or training or knowledge repositories.

  • Interactive training. When I am hired by IT providers or client organizations to train their project staff on the people aspects of project delivery, it is specifically because they are aware of my breadth of experience and tacit project knowledge which is best shared in interactive sessions. The training that I provide is based on real-world experience that would never be found in any sort of knowledge capture documentation or repository.

    For example, in the previous point I recounted my experience of work shadowing a very experienced senior Project Manager. I would study him in meetings, watching him listen patiently to a client’s question or ranting, pause for an interminably long (or so it seemed) period of time, and then answer calmly and confidently. He never interrupted. He allowed the person to state his or her case, all the while acknowledging, clarifying, confirming, and seeking to understand. It was active listening and responding at its finest.

    You won’t find that in a Lessons Learned Register.

    In my interactive training sessions with project staff, one of the activities that we work on is active listening. I am often amazed at how often IT staff interrupt others mid-sentence and assume they know what they were going to say or ask. This behavior is rude and creates frustration. As I work with staff to listen actively without interruption, ask clarifying questions, and pause (for a count of three) before answering, I’m equally amazed at the difference in their ability to interact with others.

    This is just one example – a minor one perhaps – but nevertheless a very important one. Other such behaviors I work with project staff on include political awareness, facilitation, seeking to understand, buy-in and consensus, negotiation, meeting etiquette, email etiquette, and others.

    Lessons learned in these areas are never documented explicitly. Most Project Managers expect that such behaviors are learned naturally over time (yet some of the staff most guilty of errant behavior in these areas are the Project Managers themselves). They can be, but in the meantime much damage can be inflicted on project relationships.

    Tacit project knowledge in areas such as these is best shared by seasoned Project Managers with project staff engaged in project delivery. Such interaction is much more effective than generic training from generic training companies.

  • Formal or informal conversations. In the article referenced earlier, I also gave an example whereby on several occasions, I predicted exactly how the client organization’s IT provider would react in certain situations. My clients were always astonished at the accuracy of my predictions. This was knowledge that I had internalized over years of experience was not easily explained. Nor could it be documented easily.

    As a result, the client staff became trusting of my counsel and knowledge borne of many years in the project delivery trenches. Knowing that at some point my contract with them would end, they began to meet with me formally and informally learn more about how I could predict their IT provider’s behavior.

    I taught them how to put themselves in their provider’s place whenever they requested something from them or challenged them in some way. I explained how profit-oriented organizations, protective of their reputations, viewed every request and challenge in context of recent situations. I showed them exactly how I was able to predict the provider’s responses.

    Shortly after we began these exchanges, I started to watch the client staff think through every significant interaction that they would have with their IT provider. I witnessed a de-escalation of tension and mistrust as they put themselves in their provider’s place.

    How would you incorporate that into a Lessons Learned Register?

  • Focus Groups. Have you ever encountered a project challenge that is not described in textbooks or system development methodologies? I certainly have.

    One of the methods that I have consistently employed in such situations is focus groups made up of staff from both the IT provider and client. Over the years, I have witnessed creative solutions to such situations as relocating an entire project team because of an act of terrorism, handling union discontent, appeasing confrontational advocacy groups, challenging a bloviating bureaucrat, and others.

    These are situations that cannot be shared explicitly in a Lessons Learned Register. However, the use of focus groups to handle these types of one-off situations serve as excellent examples to other projects when they have unique challenges.

  • Subject Matter Expertise. Several years ago, a firm I worked for was awarded a significant project in a business area with which we had limited experience. We immediately scoured the nation for an individual with domain knowledge and industry credibility. We brought him on site with our project team to work alongside us as our “translator”. He was especially critical during the requirements definition phase of the project.

    The project was ultimately very successful and, as a result, we were soon awarded eight more similar contracts in other jurisdictions. Without the specialized knowledge of this individual it is unlikely that we would have had that level of success.

    Whether the project team requires expertise in an industry, a government program, a specific methodology, a new technology, or any other specialized knowledge area, the most effective way to fast-track the team’s learning is to bring the subject matter expertise to them to provide deep knowledge sharing.

  • Networking. At one point in my career, I worked for a firm that required all its professionals to return to home office monthly for project updates. Each project would provide status, reports of wins, and descriptions of any project challenges. It was a great time of networking, sharing ideas, and brainstorming solutions to problems that projects we were facing. More was accomplished through the sharing of tacit project knowledge through this networking than could otherwise have been achieved.

    Similarly, the firm created special interest groups that were responsible for developing and publishing white papers, trainings, and/or seminars in areas of interest to the individuals and the firm. Again, this was made possible through networking, usually over teleconferencing or video conferencing, and always across many time zones. In this way, tacit knowledge was captured in the appropriate media and disseminated across the firm.

  • Communities of practice. I spent many years of my IT career in the development and implementation of large, complex, integrated computer systems to assist in the administration of the nation’s public assistance programs. To better understand the programs I was supporting, I joined the industry’s membership organization.

    The organization represented state and local health and human services agencies. It connected these agencies with national policymakers, IT providers, and a wide circle of stakeholders in the public sector. Within the organization were several communities of practice in which knowledge was shared liberally. Often there was clarification of existing policies and procedures, notification of upcoming legislation, discussion of best practices, and other such information. The entire membership benefited from the sharing of this knowledge.

These are but a few examples of effective ways in which tacit knowledge can be shared. Limiting lessons learned solely to explicit project knowledge repositories limits our ability to continue to improve as IT practitioners. We must embrace the sharing of tacit project knowledge as well.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.