2. Organizing is using resources efficiently and effectively while executing the plan.
3. Controlling is determining how well the plan is being implemented.
4. Leading is motivating people to achieve the goals of a project.
KM makes an excellent candidate for project management, considering the track record of other information technology (IT) projects. Most projects fail for a variety of reasons, including:
§ Incremental expansion of scope
§ Lack of meaningful schedules
§ Miscommunications
§ Poor teaming
§ Poor understanding of requirements
§ Unrealistic estimates
§ Unrealistic plans
§ Vague definition of goals
Of course, the list is endless. The point is that KM projects are prime candidates for applying project management. Coupled with the results of the past and vagueness surrounding knowledge management, project management becomes even more imperative for project success.
Planning
Planning involves performing these critical steps:
§ Preparing a statement of work (SOW)
§ Developing a work breakdown structure (WBS)
§ Estimating time and costs
§ Preparing schedules
§ Performing risk management
Preparing a Statement of Work Also called a SOW, this document is a contract between the project manager building the KM system and its recipient, or customer.
From a KM perspective, the customer is often within the user community and the project team comes primarily from the IT organization.
Considering the vagueness surrounding KM, a SOW makes good sense and can preclude a host of misunderstandings surrounding the functionality of a KM system and responsibilities for performing specific tasks. A well-written, definitive SOW
provides a meaningful basis for planning a KM project. A typical SOW consists of the elements shown in Exhibit 1.
Exhibit 1. Elements of a Typical SOW
Element
Example
Introduction
The purpose and scope of the system
Constraints (schedule, budget, quality) The cost for developing and implementing the KM system and its date of completion
Responsibilities
Responsibilities for knowledge capture and
tool selection
Requirements
Customer providing subject matter experts
Deliverables
Repository, training, documentation
Signatures
Project manager, project champions,
customer’
s requirements
Developing a Work Breakdown Structure Also called a WBS, the work breakdown structure is a top-down, general-to-specific hierarchical listing of components of a KM system and their respective tasks to complete. An effective WBS reaches a level of detail that enables development of a meaningful schedule, makes valuable assessments of progress, and ensures completeness of the tasks. A heuristic is that the lowest level of tasks in a WBS cannot exceed 80 hours to complete, or the equivalent of two weeks of work for a full- time equivalent. A sample portion of a WBS is presented in Exhibit 2.
Exhibit 2. A Sample WBS
Estimating Time and Costs The real value of a definitive WBS is its use in estimating the time and costs for a KM project. It provides the level of granularity that allows for “rollups” to different levels of tracking and monitoring.
The estimating for time should involve the application of the three-point estimate.
This approach can reduce the dramatic influences of extreme optimism and pessimism that often accompany estimates. Hence, the three-point estimate reduces the tendency to exaggerate. The best approach for applying this estimating approach is having the individuals who perform the tasks do the estimating. The people assigned, however, are often not available, so the project manager must make the initial estimates. Regardless, the three variables for each task to consider are the: 1. Most pessimistic, which is the time required to complete a task under the worst conditions
2. Most optimistic, which is the time required to complete a task under ideal conditions
3. Most likely, which is the time required to complete a task under normal conditions
The three variables are plugged into a formula to derive the expected time: Expected Time = Most Pessimistic + 4(Most Likely) + Most Optimistic / 6
Example: 144 hours + 4(60 Hours) + 50 / 6 = 72.33 hours
The expected time is then adjusted by a percent to account for interruptions, absences, and other nonproductive times not related to performing the tasks: Example: 72.33 x 1.07 = 77.39 hours
After estimating, the estimator for each task translates the revised expected time into flow time to develop schedules. The time is normally divided into eight-hour units:
Example: 77.39/8 = 9.7 hours
With time estimates, the project manager can then calculate costs using the hours.
Often, a burdened rate is used for labor and indirect costs that may be added to the task.
Preparing Schedules The combination of the SOW, WBS, and estimates provides the basis for developing a meaningful, integrated schedule for the KM project. The SOW provides the mandatory dates; the WBS provides the listing of the tasks to perform; and the estimates provide the length of time to perform each task.
The schedule is first developed by identifying the dependencies, or logical sequence, among the tasks and then applying the flow times for each one. The eventual result is the calculation of four dates for each task:
1. Early start, which is the earliest time that a task can start 2. Early finish, which is the earliest time that a task can finish 3. Late start, which is the latest time that a task can start 4. Late finish, which is the latest time a task can finish
The above dates are important because they not only indicate the flexibility available for starting and completing tasks, called float, but, in toto, identify the critical path.
The critical path in the network diagram is the longest path, following from left to right, and does not allow for flexibility in the schedule. A slide in the critical path will, consequently, result in a slide in finishing the project on time. Exhibit 3 is part of a network diagram for a KM project.
Exhibit 3. Part of a Network Diagram for a KM Project
Performing Risk Management Because KM projects face many variables, risk management is absolutely essential. Like all projects, some risks have a higher probability of occurrence and a greater level of impact than others. The project manager who performs a risk management can increase the likelihood of project success by identifying the necessary measures that need to be established to respond to certain risks affecting cost, schedule, and quality. Here are some risks that many KM projects can face and that can impact cost, schedule, and quality:
§ Failure to obtain management buy-in
§ Failure to tie the KM system into the overall strategic direction of the company
§ Inability to get employees to share knowledge
§ Lack of detailed requirements
§ Lack of integration among development tools
Organizing
Having good plans is necessary but of little use without an infrastructure to execute them. A project infrastructure consists of many elements, such as a team organization, responsibility matrix, project manual, meetings, and software.
Team Organization Assembling a group of people and calling it a team are not enough. Structure is necessary to capture the energy and synergy created and to channel both in the right direction. Because KM is still in its infancy and requires the participation of many specialists, it is important to identify clear responsibilities and reporting relationships. A simple organization chart, such as the one shown in Exhibit 4, can help clarify responsibilities and reporting relationships.
Exhibit 4. A Simple Organization Chart
Responsibility Matrix The WBS and resource allocation provide the basis for constructing a responsibility matrix. The matrix is a chart that shows the relationship of the work to be done and the participants on the project. The advantages of the matrix are that it communicates responsibilities for performing specific tasks and identifies their levels of involvement. Project managers can elect to parse out the matrix, meaning that a person receives only that portion of the tasks he or she is responsible for completing, or it can be distributed in its entirety to everyone. Exhibit 5 is an example of a responsibility matrix.
Exhibit 5. Example of a Responsibility Matrix
Smith
Watson
Henricks
Garcia
2.3.1 Determine ways to
P
S
catalogue knowledge
2.3.2 Determine how to filter
P
S
S
knowledge for specific
requirements
2.3.3 Develop indexing schema
S
P
2.3.4 Identify linkages among
S
S
P
knowledge components
Legend: P = Primary; S = Secondary
Project Manual Everyone on a project needs access to certain data to complete it successfully. If the information is not readily available, participants consume time and energy finding it and, consequently, reduce their efficiency and effectiveness.
One way to ensure the availability of the necessary information is to create a project manual in electronic or hard copy form. Exhibit 6 is an outline of a typical project manual.
Exhibit 6. Outline of a Typical Project Manual
Introduction
About this manual
How to keep it current
Plan
Statement of work
Responsibilities
Schedules
Documentation standards
Narrative documentation
Flowcharting
Policies and procedures
Companywide policies and procedures
Project policies and procedures
Service support functions and responsibilities
Documentation
Reports
Forms
Contact lists
Glossary
Appendices
Meetings For a KM project, there are three basic types of meetings: checkpoint review, status review, and staff. Checkpoint review meetings are held at a major milestone point in the schedule, such as capturing knowledge from subject matter experts. The purpose is to determine how well the project progressed, what went and did not go well, and whether to proceed. Status review meetings are held regularly. The purpose is to collect and assess status on the performance of the project of cost, schedule, and quality basis, such as meeting a major milestone date in the schedule. The staff meeting, too, is held regularly with the project team and selected invitees. The purpose is to discuss issues and share information, such as technical challenges in building the KM system.