Eight to Late

Sensemaking and Analytics for Organizations

The effect of organizational culture on knowledge transfer in projectized organisations

with 9 comments

The knowledge gained during the implementation of a project is often lost after the project is completed. This loss carries a huge cost as future project teams have to rediscover lost knowledge, or reinvent the proverbial wheel.  Although learnings are often (or should I say “sometimes”?)  documented in project post-mortems or lessons learnt documents, these are rarely, if ever, read by project teams down the line.  Management and transfer of knowledge involves complex processes which, in turn, depend on several factors that vary from organisation to organisation. One such factor is organisational culture.  A recent paper entitled, Knowledge Transfer in Project Based Organizations: An Organization Culture Perspective, published in the Project Management Journal investigates obstacles to knowledge transfer in project-based organisations, with particular emphasis on the role of organisational culture. I summarise and review the paper below.

The authors begin by a brief overview of what is meant by knowledge and how it is created. They distinguish between data (unprocessed facts), information (meaningful aggregations of data) and knowledge (information that is processed and filtered on the basis of an individual’s perception, skills and experience). Knowledge involves  assimilation by the human mind whereas data and information do not. The authors also draw a distinction between explicit and tacit knowledge, i.e. that which is documented and that which is undocumented, often existing only in people’s minds.  According to the SECI model proposed by Nonaka and Takeuchi,  new knowledge is created by an interaction between tacit and explicit knowledge through the processes of Socialisation, Externalisation, Combination and Internalisation. Other researchers claim that explicit knowledge is an extension of tacit knowledge to a new level, whereby it is “consciously known” and hence can be transferred to others.

The authors then move on to discussing how knowledge is transferred. Their discussion is based mainly on a paper by Nissen and Snider (see abstract), which describes three views of project-related knowledge transfer:

  1. As solution – wherein knowledge is transferred on the job – i.e. when working on projects. In this perspective, managers facilitate knowledge flow by ensuring selection of appropriate technologies  and motivating individuals to use them.
  2. As experience – wherein knowledge is transferred by capturing experiences (by documentation, for example) for future reference. Here the emphasis is on flow of knowledge across time. An example of this is when knowledge is transferred from one project team to another.
  3. As socially created -wherein knowledge is created (not transferred!) through interpersonal interactions (discussions, arguments and other informal communications). The challenges associated with this form of knowledge transfer are primarily in fostering an organisational culture that encourages informal communication. Although this may be considered outside the ambit of a project manager’s responsibilities, a project manager can  help by fostering a communication-friendly culture within the project team.

The authors then point out that project management has grown beyond its traditional role of planning, controlling and monitoring projects to a more strategic role of resource optimisations and inter-departmental collaboration – which ultimately ends up providing better customer service.  I’m not sure why they throw this point in, as it seems like a side issue to the main focus of the paper. Perhaps it is to emphasise that effective knowledge transfer processes become more critical as project management takes on a more strategic role in organisations.

Project teams are often required to find and assimilate knowledge that exists in organisational memory. The authors suggest that this task is easier in functional organisations than in projectised ones, because in the former, knowledge is organised and stored by department (and hence, presumably, easy to find).  I beg to differ: In my experience the task can be just as hard in functionally structured organisations.  This is true for most of the other knowledge transfer obstacles they mention, such as: volume of documentation, no time to document etc. etc. My point: knowledge management problems listed by the authors aren’t unique to project-based organisations.

Next the paper looks at the classification of project-related knowledge. Here the authors follow the work of Conroy and Soltan, who suggested that all project-related knowledge falls into one of the following: an organisation knowledge base, a project management knowledge base and a project-specific knowledge base; each being developed (or augmented) during the implementation of projects. Since projects are the only means via which knowledge bases are enhanced, it is important that project learnings are captured effectively.

Having discussed the need to capture project knowledge and the importance of project-specific knowledge, the authors move on to a discussion of obstacles to knowledge transfer in projectised organisations. They identify the following road blocks to knowledge transfer:

  1. Project constraints leave little time and resources for effective documentation of knowledge.
  2. The existence of significant social and cultural barriers to knowledge transfer. These are things such as: lack of openness, no tolerance of failure, blame culture etc.
  3. Lack of motivation (or incentives) to undertake project reviews. This is the well known wiifm factor.
  4. Lack of leadership that accords enough importance to developing the organisation’s knowledge base.

The authors contend that these issues boil down to inadequacies in organisational culture. Stated another way: the transfer of intrinsic knowledge (which exists in people’s minds) can occur only in an organisational culture that supports it.  This definitely rings true, and I don’t think any project manager would argue with it. I would add that the aforementioned obstacles are alive and well in all organisations – not just project-based ones.

Having established that a supportive organisational culture is critical to knowledge transfer, the authors move on to  discussing the cultural variables that promote knowledge transfer. In particular, they discuss models by West and Schneider.

West proposes the following two dimensions of organisational culture:

  1. Flexibility versus control: this measures the degree of organisational control. Specifically, flexible organisations tend to have flat hierarchies, decentralised decision making as opposed to controlled organisations which have rigid (and often deep) hierarchies and centralised decision making.
  2. Internal versus external orientation: this measures the degree to which the organisation is affected by its cultural environment. Although organisations are situated in a greater cultural context, the extent to which they are affected by it can vary.

As compared to control-based organisations, flexible organisations are characterised by flat hierarchies and decentralised decision making.  The authors mention that rigid structures and hierarchies promote efficiency, though often at the expense of innovation and collaboration.   In my experience in control-based organisations, the emphasis on efficiency and control often leads to an overemphasis on process, which is ultimately what reduces any possibility  of collaboration and innovation.

In contrast to West, Schneider proposes the following dimensions of organisational culture:

  1. Possibility versus actuality: this relates to what the organisation focuses on – potentialities or facts.
  2. Personal versus impersonal: this relates to how decisions are made in the organisation – process driven (i.e. by logic) or based on feelings, beliefs, ideals (i.e. all those “warm and fuzzy” notions).

These axes divide the universe of organisations into  four core cultures:

  1.  Control: a process driven culture which values certainty and predictability above all.
  2.  Competence: a culture that values excellence (in services or products). These organisations aim to have unique or best of breed products and services.
  3.  Collaboration: this culture emphasises close connections with customers and collaborative working towards developing products or solutions. This is essentially the  opposite of a competence culture.
  4. Cultivation: this  culture emphasises openness, autonomy, ideals and ideas. These organisations tend to be innovative. This is essentially the opposite of a control culture.

It is intuitively clear that the above dimensions of organisational culture will have varying effects on the efficacy of knowledge transfer. The authors, however, do not delve into these. So their coverage of models of organisational culture, as interesting as it is,  seemed a little pointless in the context of the paper.

Next the authors point out that since project teams consist of individuals drawn from various professions, one needs to consider the effect of professional culture as well. This is an interesting point, which complicates matters because different professional  cultures approach communication in different ways – the example of IT and business cultures being a particularly stark case in point.

Finally, the authors end with a very general discussion of how knowledge transfer can be promoted in projectised organisations. They suggest that managers should:

  1. Recognise different levels at which knowledge is generated – i.e. individual, group and organisational.
  2. Appreciate the role of organisational culture in promoting or hindering knowledge transfer between these levels.  They suggest the primary barriers to knowledge transfer are cultural rather than technical (See this article by Suzanne Koudsi, for an interesting case study).
  3. Understand the role that management plays  in fostering a culture that facilitates knowledge transfer. This is particularly true for project managers who have to deal with many different cultures (organisational, departmental and project team) simultaneously. Awareness of cultural differences can help managers find the cause of obstacles to knowledge transfer.
  4. Appreciate the challenges involved in transforming organisational culture.
  5. And finally, since projects are the coalface at which knowledge is generated, practitioners must understand the issues that need to be addressed to facilitate gathering and preserving of relevant knowledge generated during project implementation. Some examples of these include communication modes between team members, what worked well in the project, what can be improved and how it might be improved,  etc.

Having covered a lot of ground (somewhat skimpily, in my opinion), the authors conclude the paper with three very general statements:

  1. Effective knowledge transfer can occur only if the organisational culture is open to accepting new knowledge transfer activities. Managers must therefore prepare the culture to accept, adopt and implement these activities.
  2. In addition to knowledge transfer, knowledge management is also about fostering an organisational culture that encourages the creation, sharing and utilisation of knowledge.
  3. Project managers have to merge myriad organisational, departmental and professional cultures into an effective project culture that promotes knowledge management.

Although project managers may appreciate these points (and I suspect many do), there’s little they can do about changing an organisation’s cultural mindset. All they can do is ensure that they establish a culture that fosters knowledge transfer within their  own projects (point 3 above). Some ways to do this include: encourage collaboration between team members, establish a no-blame environment etc.

In conclusion, the paper was reasonably interesting but somewhat hard to read because it was thin on detail, and occasionally veered from topic to topic without proper transition or introduction. I suspect this is because the authors assumed their readership would consist entirely of academics with a strong grounding in project management theory. This is a pity because the paper, if better written, could have been of considerable interest to practising project managers. So I end this review with a plea to  journal paper authors: when writing your paper, please remember that project management isn’t just an academic discipline.


Ajmal, M. M. and Koskinen, K.U., Knowledge Transfer in Project-Based Organizations: An Organizational Culture PerspectiveProject Management Journal, 39 (1), 7-15. (2008).

Written by K

April 12, 2008 at 5:19 pm

9 Responses

Subscribe to comments with RSS.

  1. Again – an excellent review, in my opinion.
    As a doctoral student in the exact subject, a PMO in a governmental organisation, and as a very active PMI volunteer, I agree with your critics.
    Yet, even after reading this article and your review a question remains: What would be, in your opinion, a right approach recruiting top managerial level twoards an organisational effort to move the basic obstacles and capture projects effective knowledge in large organizations?

    Tomer Keidar, PMP


    Tomer Keidar

    April 27, 2008 at 7:21 am

  2. Tomer,

    Thanks for your comments.

    You’re right – the article does not suggest concrete steps to removing obstacles to knowledge transfer. I suspect this is because it is difficult to offer specific advice on such an issue without a knowledge of the organisation in question. Having said that, there are a few things top management can do (some of which I have already mentioned in my review):

    1. Establish a no-blame culture. This is really the key – if people are to be open about their project experiences, they must feel assured that there are no adverse consequences of openness.

    2. Allot enough time and resources for project post-mortems and documentation. There should be a rule, strictly enforced, that a project isn’t over until the lessons learnt docco is in. Ideally the postmortem should be facilitated by an experienced facilitator who is not involved with the project.

    3. Insist and enforce on documentation during implementation. This is hard to do – and doesn’t get done unless enforced. So, enforce it!

    4. Establish easy to reference project archives – with special reference to documentation of failures and what could have been done to avoid them (this is related to points 1 and 2 above).

    These are just a few of the points that come to mind. Again, these are really issues of organisational culture (as the paper authors point out) and, hence, can only be changed by concerted efforts from the top.

    I’m really interested to know what you think, especially with your background in project management practice and theory.

    Good luck with your work!





    April 27, 2008 at 8:25 am

  3. There is an important point I have seen, and I would like to share; In a lot of cases it is not a lack of knowledge that harms the organization but the lack of will to use it. A key question in my opinion is how to enforce knowledge consuming, and I explain: once you have that effective knowledge captured, and even announced that it is there, what will definitely make project managers come and get it.
    I think I have a clue, and it concerns the way doctoral students, start their thesis project.



    Tomer Keidar

    April 27, 2008 at 3:05 pm

  4. Tomer,

    Excellent point!

    In my opinion, using knowledge bases cannot be enforced. It has to be inculcated by educating and motivating potential end-users of the information. That is:

    1. Potential users of the information need to be educated about the value of using project archives and related knowledge bases.

    2. If education is done correctly and the knowledge base actually delivers on what’s promised (i.e. useful information and knowledge), motivation will automatically follow.

    I’m intrigued by your comment about doctoral students, and would be very interested to know what you think.





    April 27, 2008 at 8:44 pm

  5. Well, as we all know, in the initiation phase the proposed project manager should learn as much as he can about the project, the product, the environment, past experience, and so forth.
    Nevertheless, from my experience this stage does not get the truth recognition it deserves.

    When I started my doctoral studies, quickly have I learned that my own experience has little to do with the initial learning phase I should go through. My professor than told me in other words that all I know is not so relevant when I am coming to do an empirical research.
    This was the point when I recognised that learning, in the academy, means becoming an expert on all past knowledge concerning the specific field you are talking about. Your own experience is only a fragment in the overall picture.
    Only when I started reading articles, have I learned how little have I known before.

    Now I ask myself, does this revelation is relevant to the initiation phase in projects?


    Tomer Keidar

    April 28, 2008 at 7:19 am

  6. Good point. I believe there are two important issues here:

    1. Self awareness of one’s deficiencies – i.e. as you point out, ” Your own experience is only a fragment of the picture.” Such self awareness leads to motivation to learn, as you have found in your own work.

    2. Actually filling in the gaps in one’s knowledge. This is where education comes in – i.e. being informed about knowledge bases and how to access them.





    April 28, 2008 at 8:56 am

  7. […] to project management. In earlier posts, I have commented on effective knowledge capture and the role of organisational culture on effective knowledge transfer in projectised organisations. Many of the considerations highlighted in those posts apply to NPD […]


  8. Re the early, knowledge acquisition stages of a project – have a look at what is being done now in the use of knowledge management plans during the start-up project phases. These are documents, required by management as part of due diligence, which define the learning actions and accountabilities for the project, as well as the knowledge capture systems and processes which will be applied. KM plans deliver a much-needed degree of rigour to project-based KM in the early stages.


    Nick Milton

    June 19, 2009 at 5:51 pm

  9. Nick,

    Thanks for your comments. Would you be able to direct me to some research and/or practical references on this?

    Thanks in advance.





    June 19, 2009 at 8:03 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: