In the information technology (IT) profession, we are engaged in a rather intense battle for self respect. Much of the value that we deliver to organizations is done through projects, and yet it seems we cannot get project performance right. The quest for value from IT spending has historically been difficult to demonstrate. According to a recent Standish Group study, IT projects have a 66% failure rate –either missing targets or failing to deliver required business functionality. These failed IT projects are a major stumbling block to companies trying to innovate through new processes and services.

Other reports show that project success is improving, caused perhaps by increased use of project management methods and by controlling project size and scope. However, recent discussions with project managers have indicated that the goalposts are still moving. In interviews, senior project managers report that IT projects are getting more ambitious, more organizationally complex and more focused on time-to-market. Project managers need to spend more time at the boundaries of the project –with the governance team and external stakeholders –than ever before. While traditional project management methods are gaining some ground, there is still a need for new perspectives.

Other reasons to support a knowledge approach are found in academic research. Three recent studies have shown statistically that managing knowledge (in addition to managing tasks and budgets) can add to the probability of success.

*A survey of team members and stakeholders of 69 software development projects found that expertise coordination improved performance by 25% over the contribution of traditional project management.

Another study tracked the progress of 38 virtual project teams. It found that project success was strongly influenced by the level of the team members’knowledge of each others’expertise (i.e. their knowledge directory) and their ability to harness it to achieve project goals.

A recent study of 133 projects reported that the level of knowledge integration within the team was more important to project success than a pre-existing good relationship between business and IT.

These are early indications that managing knowledge matters to project success. Each of these research reports adds a bit to the puzzle. Although many people, when thinking about knowledge in projects, focus on "lessons learned", there are many more areas within a project where a focus on knowledge can pay off.

KNOWLEDGE "TRAPS"

Overall, research suggests that two kinds of knowledge are important within a project knowledge of the project process (i.e. project structure, methodology and status) and knowledge of the project domain (i.e. the industry, organization, business process, and technology).

A major result of harnessing and mining knowledge within a project team should be an increased level of innovation, both in the product and in the methodology. With high levels of project process knowledge, one can imagine self organizing groups of team members, fluidly modifying tasks and times to achieve a highly effective result. With high levels of integrated project domain knowledge and a focus on learning, one could expect breakthroughs in difficult technical problem areas and a very original result. Team members would not only contribute more, but should learn more, individually and collectively, thus leading to future success.

The paragraph above should alert the reader to one issue in the application of knowledge practices the weakening of reliance on command and control. Project managers may or may not embrace these concepts, because it could be seen to lessen their influence. However, we believe that the stronger the team is, in terms of taking responsibility for outcomes and methods for the project, the better the result will be. In a knowledge-focused environment, the project manager facilitates, but does not totally control the project.

Many accomplished project managers know intuitively about the knowledge traps detailed in this article. However, there is little mention of knowledge in the PMI Book of Knowledge, and junior project managers will need to learn and apply new ideas through trial and error. Therefore, our goal is to spark debate and influence practice within those learning and influencing the craft of project management.

We have reviewed over 40 research articles which have investigated knowledge practices within a project context and have developed a model to show where the application of knowledge might affect IT project success. Figure 1 contains a simplified model of an IT project, with Inputs, Processes, and Outputs shown. Within the project, there is a Governance process and four typical project phases -Plan, Design, Build, and Implement. Superimposed on this model are the ten "traps"identified in the research literature. Each of these “traps”represents a time in the project where knowledge might be unavailable, lost, or simply not created. Each will be discussed below. After this discussion, more general knowledge guidelines for project managers are presented.

此主题相关图片如下：

--------------------------------------------------------------------------------

Project Inputs

There are three knowledge issues to consider at the beginning of a project ;lessons learned, team selection, and timing the entry and exit of team members.

1. Lessons Learned are as important at the beginning of a project as they are at the end. Project teams contain individuals from many different organizations and units. They may or may not have attempted a project similar to the one being commenced. Without access to lessons learned from comparable projects, the team will have lost an important opportunity for a quick and informed start.

2. Team selection is important since the project manager will want all relevant knowledge areas included in the team or available to the team when needed. Problems arise when the project manager cannot select his/her team or when the knowledge profiles of team members are not available during the selection process.

3. Timing the entry and exit of team members is the third knowledge trap. Research has shown that members added to a team after the mid-point of a task rarely change the team’s direction, so care has to be taken to have key knowledge inputs available early. Even more important to team functioning, the loss of key team members will result in knowledge gaps within the project.

Project Governance

Project governance includes the roles of executive sponsor, project champion, project manager, and project steering committee. From a knowledge perspective, two issues are identified –volatility and role understanding.

4. Volatility in the Governance Team is the fourth knowledge trap. After a project begins and the governance structures are put in place, there is a gradual knowledge building process among the key stakeholders. When members of the governance team change, there is the distinct possibility of a knowledge loss which may cause targets to be missed. A change in project manager is the most important volatility, but the trap refers to any member of the governance structure who controls or influences project resources and direction.

5. Lack of role knowledge among the governance team is a common knowledge problem. When senior executives take on project sponsor or champion roles, they do so because the outcome of the project is important to them personally and to the organization. Unfortunately, there is often no training given for these roles. A first-time project sponsor may not know when to support the project and when to tighten up the reins; or whether project problems are serious or temporal. Gaps in project governance knowledge endanger the success of projects.

Project Processes - Plan, Design, Build and Implement

There are five "knowledge traps"within the main body of an IT project. Two variations of knowledge trap six have been identified in the Plan phase. Within a project which is building a custom application, knowledge integration between users and analysts is critical. Within a project which is implementing packaged software, knowledge transfer from vendor or consultant to the internal project members is critical. In both of these cases, there are often activities in the project plan for these knowledge-related tasks to take place, but no objective way to measure how effective they were. Mistakes or omissions in this phase result in rework and add to the expense of a project.

Within the Design and Build phases of an IT project, there are a multitude of interrelated decisions to be made. The more difficult the domain problems are, the more important it is that team members know "who knows what", so that design and build problems are addressed by the best knowledge source in an efficient manner. Team members need a knowledge "directory"which includes both the knowledge within the team itself and knowledge available to the team.

Because team composition changes from phase to phase in IT projects, knowledge loss between phases, knowledge trap number 8, is particularly important. There is a significant risk that the knowledge generated by one phase will be inadequately transmitted to the next phase. Traditional methods of documentation, such as models, state diagrams, and use cases, rarely capture the "why"of design choices. As the next team interprets these artifacts, they may introduce errors into the project or slow it down trying to understand the meaning of previous decisions.

Across all phases in the project, there is the need for project participants to have an understanding of the project structure and process, and where they and others fit in. They need to know what the status of the project is, where problems are occurring, and what is planned. With this knowledge, they can work in self organizing units, making adjustments to tasks and timelines as information becomes available. Without “where are we?” knowledge, team members can waste time on low priority tasks and fail to coordinate with others whose work depends on theirs. They may also escalate minor schedule and scope problems to an overworked project manager, causing bottlenecks and an inward focus.

Project Outputs