Page 123 -

112 MANAGING KNOWLEDGE WORK AND INNOVATION

Relating to the first criterion, where those involved in projects approach the
tasks mechanistically (Knights and Wilmott, 1997) – each project member work-
ing independently on a set of clearly defined tasks or processes with which he/she
is familiar using his/her existing knowledge – then there is no real project-level
learning. We defined this as a multi-disciplinary mode of working in the previ-
ous chapter. Individuals may learn through this process but there is no collective
level of learning and so there is no project-level knowledge to exploit. We will
discuss this issue a little further below. Suffice to say now, where projects are
approached in this kind of mechanistic way, the level of creativity that is actually
fostered is likely to be negligible. It is like a group of students being given a proj-
ect assignment, but instead of working together they divide up the assignment
and each does a little piece and then they add the pieces together. Individuals
may have learnt from their small piece of the assignment but they will not have
learnt from each other or created any collective level of knowledge. You can also
see that approached like this, knowledge boundaries are not confronted, even
though they may well exist.
Relating to the second criterion, project team members typically only seek
out knowledge beyond the confines of their project when they are experienc-
ing a problem that they cannot solve with their existing knowledge. As long as
things go ‘more or less to plan’ there is typically no attempt to learn from others.
The supply of knowledge on intranets therefore often goes unused because the
corresponding demand for this knowledge does not exist. The lack of demand
for knowledge is particularly acute at certain points in the project life cycle, for
example, when deadlines are approaching. So while milestones and review points
are potentially opportunities for reflection regarding process, in reality many
project only focus on deliverables at these points.
Given this common problem of failing to seek out prior knowledge that
may be helpful in relation to avoiding previous mistakes that have been made,
intermediaries can play a very useful role. For example, programme managers
can operate as important intermediaries – they over-see several projects and, so,
can identify how knowledge created on one project might be useful to another
project, even when the other project does not recognize that it could usefully
use prior knowledge.
Intermediaries can, thus, act as the bridge for exploiting knowledge arising
from a project across an organization. However, they are more likely to con-
nect people personally rather than connect people to documents. It is not that
the project team members lack the tacit knowledge or the ‘absorptive capacity’
(Cohen and Levinthal, 1990) to make use of explicit knowledge, but rather that
the explicit knowledge is typically simply of the wrong type to be useful. This
is because the documents that exist tend to focus very much on what has been
achieved by a project team (we can call this product knowledge) rather than
how this has been achieved and/or why it either worked or did not work (i.e.
process knowledge). Yet product knowledge concerns the specific objectives of a
project (what we do/did) and is unlikely to be helpful in other contexts precisely
because project objectives tend to be unique. What might be more useful is

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