Eight to Late

Background

Many  IT projects are knowledge-based  – that is, their success depends on the effective creation, utilisation and transfer of knowledge .  Given this,  it is surprising that elements of knowledge management have not  been  properly integrated into mainstream IT project management.  For example: project managers recognise the need to document lessons learned and often do so, but these learnings are rarely integrated into organisational project knowledge. The current approach to knowledge management and learning on projects is  piecemeal at best – a sprinkling of lessons learned, a dash of knowledge transfer from consultants and some other random bits and pieces thrown in.  Clearly, a holistic view of knowledge and learning is needed: one which presents guidelines for knowledge management through the entire project lifecycle.  In a paper entitled,   Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice, published in the June 2007 issue of the Project Management Journal, Blaize Horner Reich presents a knowledge management framework based on the research literature. I present an annotated summary and review of the paper below.

Introduction

In the introduction Dr. Reich states, “One promising lens through which projects can be understood and potentially improved is to conceptualise them as arenas in which knowledge is generated and exploited, and learning is essential for success.” Projects, as temporary organisations, face similar challenges to permanent organisations with respect to managing knowledge and learning. However,  transience implies that the challenges are greater for projects.  The existing literature in knowledge management is  vast, and highly conceptual. On the other hand, project management research tends to have a more practical bent.  The author, recognising this difference,  focuses attention on papers that incorporate both project and knowledge management. This has the dual benefit of ensuring that a) the number of papers to be reviewed are manageable and  b) the research has a practical, project-oriented focus.

In the remainder of this post I focus on the practical results of the research, referring the reader to the original paper for more on the author’s research methodology.

The author notes that project managers lack a common understanding of what is meant by knowledge management in the context of projects.  She therefore begins with the following preliminary definition:

“Knowledge management in the context of projects is the application of principles and processes designed to make relevant knowledge available to the project team. Effective knowledge management facilitates the creation and integration of knowledge, minimises knowledge losses, and fills knowledge gaps throughout the duration of the project.”

I like this definition because it clarifies what good (or effective) knowledge management can do for a project.

Classification of knowledge

After defining what is meant by  knowledge management in  the context of projects, the author moves on to a classification of knowledge types that are important to IT projects.  She identifies the following four knowledge types:

Process knowledge: This refers to knowledge of project-related processes such as methodology, time frames, project organisation etc. This is important from the perspective of understanding different roles in the project and what is expected from them. A common understanding of processes also empowers team members to organise themselves in the best possible way to achieve the project objectives.

Domain knowledge: This refers to business, technical and product knowledge relevant to the project.  Typically this knowledge is collectively held by a large number of individuals (subject matter and technical experts). It is the job of the project manager to ensure that the individuals who hold this knowledge are identified and consulted at appropriate times.

Institutional knowledge: This includes all relevant knowledge of the organisation: its people, power structures and politics.  A project team needs to have a good awareness of these in order to get things done. This is particularly important for individuals who are drafted in to the project from outside the organisation.

Cultural knowledge: This refers to discipline-based cultures (as in IT, business, academic etc.) and national cultures. Obviously team members on interdisciplinary projects need to be aware of variations in work cultures between different disciplines. Further, project teams are often composed of people from different countries; hence the need for an awareness of  the norms of different national cultures.

Typically the need for the first two types of knowledge is well recognised and catered for.  The need for the latter two should not be underestimated, as many projects fail due to the lack of organisational support and /or breakdown in communication between project sub-teams located in different countries.

Knowledge-based risks

After presenting the above knowledge typology, the author moves on to a discussion of knowledge-based risks in project management. She identifies the following risks that relate to knowledge:

1. Lessons not learned: This is probably the most recognisable knowledge-based risk. Although many organisations inisist on proper documentation of lessons learned at the end of a project, few use this effectively on subsequent projects. Most often this happens because project teams (and management) are keen (or pressured) to get on with working on the project proper. Taking the time to read and reflect on documentation from past projects is viewed as a waste of time.

2. Flawed team selection: It is in the project manager’s interest to get the right people on the project team. Specifically, one needs people who have the required process, domain, institutional and cultural knowledge. Often, though, project managers have little or no control on team selection.  On the other hand, even if project managers have a say in team selection, it may be hard to identify the skills needed upfront. Sometimes it is also hard to find out how much exactly people do know – claiming knowledge is different from actually having it.

3. Volatility in the governance team: It is important that there be continuity in the stakeholders who sponsor and run the project. When a project sponsor leaves, he or she often takes with him the project’s raison d’etre from the organisational perspective. This includes things such as the business context,  organisational issues and risks that might affect the project etc. If the project manager is struck by a bus, there is potentially a loss of knowledge regarding the state of the project and what needs to be done to make progress. Research has shown that the loss of the project manager has a significant negative impact on the project (see this paper, for example).

4. Lack of knowledge of role among the governance team: The project governance team (sponsor and project manager) are critical to the success of the project. Although organisations recognise and act on  the need to train project managers and equip them with the knowledge they need to do their jobs, few accord the same attention to project sponsors. As a result, many project managers find that they have to gently “educate” their sponsors regarding what needs to be done in order to move things ahead in difficult times.

5. Inadequate integration of different types of knowledge: This is a major risk on large projects which involve specialist knowledge from different domains. In this case it often happens that no one has the big picture, which includes all the parts that need to come together in order to make the project succeed. A common example of this – particularly on technology projects -is the so-called gap between IT and the business. Project managers can bridge the gap through effective project communication.

6. Incomplete knowledge transfer: Many IT projects are carried out with the help of external consultants who design and implement a solution, only to vanish into the sunset soon after. The need to transfer knowledge, though frequently identified and catered for early in the project, is all too often done in a half-baked way. Only when one turns to the documentation to figure out how something works (usually when its broken) does one identify that the documentation is incomplete. Quality assurance of vendor-supplied documentation is an important but oft-neglected facet of project handover.

7. Loss of team members: When a team member leaves, he or she takes with him a whole lot of irreplaceable knowledge regarding the project. Even if he or she has been diligent with documentation (and that’s a big IF), there are a whole host of things that simply can’t be documented. This is a particularly significant risk on projects that run over a long period.  For a project manager, the best way to handle this is to identify, proactively, the areas most vulnerable to this risk and to have a plan to deal with them.

8. Lack of a knowledge map: In complex projects, it is impossible for every person on the team to know everything pertaining to the project, even at a high-level.  It is therefore critical to have a knowledge map: i.e a document which keepst track of who knows what within the team.  Research studies have indicated that such knowledge maps (and the networks that result through interactions between team members)  are more effective than focussing on knowledge integration. Many of those surveyed by the author identified the lack of such a map to be a knowledge risk.

9. Loss between phases: Knowledge is lost between project phases because changes in team composition. Proper documentation is the standard way to address this issue. However, there is much that cannot be communicated through the written word. In my experience an hour long chat with an expert is way more useful than reading a document that he or she has written. Conversations, where one can go back and forth, discussing and clarifying the rationale behind certain decisions are the best way to transfer knowledge across phases. Unfortunately, it is frequently the case that the folks who have this knowledge are no longer available.

10. Failure to learn: This is perhaps the best known knowledge risk. Most everyone knows the importance of documenting lessons learned. Despite this, research shows that project post-mortems don’t happen as often as they should. The main reason for is time pressure and / or the lack of motivation to do these. Further, even when post-mortems do occur, it often happens that difficult or sensitive topics aren’t broached because it isn’t safe to do so. The importance of psychological safety in organisational learning is well-established, but few organisations make it truly safe for employees to speak out. Project environments are no exception.

The above catalogue of knowledge risks can be considered comprehensive, as it is based on an extensive literature review. The author has done an excellent job in distilling and incorporating this information into her model. In my opinion this is the most useful part of the paper.

Principles and practices

After discussing knowledge-based risks, the author proposes some principles and practices of knowledge management that are aimed at addressing these risks. I discuss these below:

Establish a learning environment: As mentioned towards the end of the previous section, the need for fostering a learning climate in organisations is well known. Many organisations now do this quite successfully. Creating a learning focus on projects is harder because of  the temporary nature of the project organisation. Based on survey responses, the author suggests five practices to foster learning in projects:

1. Engage the team when building the risk register. In my opinion, although this helps recognise risks instead of sweeping them under the proverbial rug it does not really contribute to fostering a learning environment.
2. Communicate that mistakes are a part of learning. This is important, the team should know that it is safe to own up to mistakes. This does indeed encourage learning – people learn from their mistakes and those of others providing they are made public in an acceptable way.
3. Reward behaviour that supports learning, not just results. Encourage experts and senior team members to pass on their knowledge and skills to others. One way to do this is to recognise and reward folks who spend time helping or teaching others.
4. Practice desired team behaviours on a daily basis. Make knowledge sharing, mentoring, helping others etc. a part of the team ethic by practising them on everyday issues. This is a slow process which is hard to implement in a time-bound project environment. One way is for the project manager to demonstrate these behaviours and thus serve as a role model for the rest of the team. Easy to say; hard to do.
5. Be honest and speak the truth: Be honest about issues that the team has to deal with. There’s nothing worse than a project manager glossing over potential difficulties that team members have to deal with. Further, be open about problems that you foresee. There are ethical considerations here though: for example, what do you do if you are privy to confidential information that affects the team. As with so many things in project management, this comes down to a judgement call.

Establish and maintain knowledge levels: The first step here is to identify the skills and experience required on the project.  Projectised organisations generally have a process by which project requirements are matched to skill profiles of employees.  Generally, though, there are always knowledge gaps. These need to be filled through training, workshops joint tasks or whatever. On a related note, it is important that all team members have a base-level knowledge of the project and its business context.

Once knowledge levels are established, it is important to ensure that they are maintained. The author suggests the following practices to minimise knowledge loss:

1. Ensure key roles have a backup: I’ve discussed this at length in an earlier post.
2. Seek generalists: Generalists are team members who have a range of skills, and hence can contribute to the project on many different fronts. Furthermore, since they have a wide knowledge, they are able to see connections and (as much as I hate to the word) synergies between seemingly disparate areas. From personal experience I can vouch that a good generalist or two can make a huge  difference on  a project.
3. Ensure the core team remains together through the duration of the project: This can be hard to do on long projects. The author suggests using financial rewards and bonuses to entice team members to remain on the project. I would suggest supplementing rewards with people-first management techniques. If you run your project keeping people at the centre of focus, it is less likely that folks would want to leave.
4. Encourage knowledge diffusion through delegation: One way to spread knowledge around is to delegate work and responsibility downward and laterally through the project hierarchy. When people are made responsible for particular tasks, they’ll make it a priority to gain the knowledge required to perform them. However, delegation by itself isn’t enough. Project managers must also ensure that people have the time and means to access and assimilate the required skills. This is often conveniently forgotten.
5. Develop formal introduction procedures for new team members: A formal induction should be instituted for new team members. This should include project documentation which includes  project background, objectives,  relevant business context and technical information. New team members should also be introduced to “go-to” people for various issues and be assigned a buddy or guide.

Create channels for knowledge flow: An important, but under-appreciated function of a project manager is to establish communication channels for the flow of information and knowledge pertaining to the project.  In this connection, the context in which knowledge is created, shared and utilized is important. This was first pointed out by Nonaka and Konno in a paper published in 1998 where they introduced the concept of “Ba” – or “place” in which knowledge is created and disseminated .

There are a plethora of methods by which knowledge can be shared.  The project manager has to choose the most effective ones – i.e. those that are interactive / easy to access and use. The author makes the following suggestions based on responses from surveyed project managers:

1. Co-locate teams: This works well providing team members have their own private work spaces (see next point)
2. Use open-plan offices: This is a common practice, but one which I have to disagree with: the gain in proximity can be more than offset by the loss in productivity.
3. Publish project newsletters: In my experience these work well for disseminating knowledge about administrative stuff – schedules changes, new people introduction, training and rollout information – but they aren’t necessarily the best vehicle for conveying other types of  project knowledge.
4. Have daily huddle sessions where key issues are discussed: This works well for issues that need immediate attention, but not so well for other, less urgent (but possibly as important) ones.
5. Encourage informal communication: In my opinion this is the most effective, but hardest to achieve. Informal communication works best when team members are comfortable with and trust each other. This can only be achieved in an environment of openness, with no sneaky hidden agendas. Even so, it takes time to achieve the required level of trust and comfort.

Knowledge flows through communication channels. Remove obstacles to communication and you’re well on your way to facilitating the free flow of knowledge.

Develop Team Memory: The author identifies the team’s collective memory as one of its most important resources. At the start, various team members contribute suggestions based on their experiences and lessons learned from past projects. This has a major influence on how the project develops initially.  As  the project evolves, team members need to be kept abreast of what decisions have been made and, more importantly, the rationale behind the decisions. At the end of the project, learnings should be recorded in the (infamous?) lessons learned document. The most practical way to go about this to record noteworthy events (and their analyses) as they occur, instead of waiting for the project post-mortem.

Team memory initially consists of individual experiences. As the project evolves, the project manager has to ensure that the team  develops a  shared understanding, or common memory of the project.

Use a risk register: The author suggests placing the knowledge risks listed above in the risk register. These can then be analysed and prioritised based on the specific project environment. Although in risk management the focus is on external events, the author contends that “protecting key team members and their accumulated project knowledge is just as important as protecting the project from exogenous shocks.” I agree. Once the exposure to specific knowledge risks is known, one can put in place appropriate mitigation strategies.

Conclusion

Whew – that was a bit to go through! But the effort of reading the paper (and writing this review) was definitely worth it.  Why?  Well, viewing a project through the lens of knowledge management brings into focus knowledge-based risks that are sometimes overlooked. Further, the paper also offers  some practical advice – couched as principles and practices – to address these risks.   What’s really interesting, as readers have undoubtedly noticed, is that the risks described are generic in that they are common to most projects. Hence understanding these risks and the strategies to address them will enable practising project managers to deal with knowledge-based risks on all their projects.

References:

Reich, Blaize Horner., Managing Knowledge and Learning in IT Projects: A Conceptual Framework and Guidelines for Practice, Project Management Journal, 38 (2), 5-17. (2007).