Page 122 -

PROJECT-BASED ORGANIZATIONS AND KNOWLEDGE WORK 111

Standardization: While some teams see their project as unique other projects
are seen as standard. Knowledge transfer is also restricted in these situations.
Thus, in a construction company, many projects are repeat projects, such as
warehouses where design routines are well established. These routines may work
well when a project fi ts the normal template. However, where a project is differ-
ent in some way, then this standard procedure becomes an inhibitor rather than
a facilitator of the successful accomplishment of the project. Moreover, where
new knowledge has been created in the context of these projects that do not fi t
the standard routines there is a reluctance to try and share this learning precisely
because the particular project was deemed to be different and unique and so not
relevant to the ongoing ‘standard’ projects, even though in reality most projects
deemed ‘standard’ face unique circumstances so that this sharing of responses to
the non-standard could be very useful.
Ability to capture and access ‘softer’ lessons: Project members also often fi nd it
diffi cult to capture and share what has been learnt about the process of actually
doing the work; this is often referred to as ‘softer learning’. For example, imagine
a project has experienced problems dealing with an external consultant because
they failed to specify their requirements clearly. Most projects do not attempt to
capture and share the lessons that they have learnt about this process although
they may capture what was actually achieved (or not) by the consultant.

Project reviews and milestones: Even where project reviews are part of the methodol-
ogy, they are often not done systematically or with any real emphasis on learning.
One reason why end-of-project reviews are often not very effective is because there
is often a time lag between the completion of the project and the fi nal review meet-
ing, by which time people have moved on to other projects and so are not really
interested in spending time refl ecting on what was learnt in the previous project.
Lack of awareness that knowledge transfer is needed: Generally, people seek out
knowledge only when they recognize they have a problem. For example, a software
project may go wrong because it is implemented with insuffi cient testing. How-
ever, if those involved in the project are not aware of the importance of testing,
they are not going to seek out knowledge about how much testing to do!

We can condense these issues and identify three important criteria in relation to
successful knowledge exploitation from projects. First, there must be some knowl-
edge actually created at the project-team level. Second, the team must be knowl-
edgeable enough to realize that there is indeed knowledge that exists beyond the
confines of the project that could be useful to help to improve progress on their
project. Finally, the knowledge that exists in documents that have attempted to
capture ‘lessons learnt’ must actually be useful to others. Importantly, in the con-
text of exploiting knowledge from projects, these criteria are often not satisfied –
there is limited project-level learning, there is a lack of awareness that there is
knowledge available that could be helpful and the knowledge that is captured is
often not the most useful for other projects to learn from.

6/5/09 7:02:20 AM
9780230_522015_06_cha05.indd 111 6/5/09 7:02:20 AM
9780230_522015_06_cha05.indd 111