A new project management system approach
the 'know-how" based project management system
Project management today must operate in a complex, constraining and unstable environment . As a result, project managers are confronted with various problems with respect to coordinating and integrating vast human and non-human resources . Their main concern is not only the meeting of technical performance goals, but also the impact of political, environmental and economic factors related to their projects . Therefore, project managers need multi-disciplinary “know-how” such as:
• management skills
• technical skills
• economic and financial knowledge
• social and communication skills
• legal and political knowledge 
“Know-how” is defined here as knowledge or skill gained through experience for a particular work activity.
In foreign projects (e.g., in the Middle East), project managers also need to understand local customs, laws and conditions, as well as possess skills to communicate with clients whose social, cultural, religious and political values may be quite alien to them .
No existing project management system can be effective in providing the project manager with all the types of know-how. This is because the functions of systems today are quantitative planning, scheduling and monitoring in which the main objectives are project performance measurement and cost/schedule integration with Work Breakdown Structure (WBS) .
The purpose of this article is to present a new project management system approach, the “Know-how based project management system”, which can effectively provide a project manager with the required know-how.
The first half of this article describes the approach taken in the development of the system, in which new tools, “know-how base” and “meta-WBS”, are presented. The second half explains system application to risk management in the various stages of project execution.
Know-how Based Project Management System
Three functions are proposed for the “Know-how Based Project Management System.” An analysis is made to determine key characteristics that should be considered in developing the new system. These functions and characteristics are shown in columns 1 and 2 of Table 1, respectively.
Development of a New Project Management System Approach
|Proposed functions||Key characteristics of the functions||Tools proposed||New system|
|To provide action know-how||To treat vague & non-quantitative know-how||Know-how base||“Know-how Based Project Management System”|
|To use for many projects||Meta-WBS|
|To provide know-how in advance||To connect project schedule charts|
|To co-exist with existing systems||Good interface with other systems|
To begin with, the project manager must be provided with action know-how. Existing project management systems identify deviations from a plan. However, they only inform the project manager that corrective action must be taken — they do not suggest what corrective action should be taken .
The action know-how necessary for project management is usually based on vague and non-quantitative information. New tools should be developed that can treat vague and non-quantitative information as well as quantitative information.
Every project is unique. Therefore, it is important to determine the common characteristics of various projects, and to develop a management system adaptable to many types of projects. In other words, action know-how should be applicable not to one project, but to many projects.
The next step is to provide a project manager with action know-how in advance so that there is adequate time to take action. Existing project control and monitoring techniques gather project data and present project status reports. This information, however, usually arrives too late for the project manager to take corrective action. In existing systems, there is a time lag ranging from one to three weeks from the time data is acquired to the time it is put in usable form.
In order to provide action know-how in advance, know-how should be connected to the project schedule chart.
Finally, the new system must be adaptable to the various existing systems. Implementation of the new system should be achieved by gradually changing existing systems. This is important, because a great number of project management systems are used world-wide. Therefore, an interface capability with other systems should be developed.
To realize the key characteristics for the functions presented above, new tools are presented here, i.e., “Know-how base” and “Meta-WBS”. These are then synthesized into a new system, called a “Know-how based project management system.” The relationships of these tools and system to the functions and characteristics are shown in Table 1.
The know-how base is composed of many pieces of vague, non-quantitative information, which are expressed in natural language sentences. On the other hand, quantitative data, such as cost, time and quantities, are stored according to the definite data structure of existing data base systems.
Common information retrieval systems are used for many kinds of information (e.g., vender lists, standard contracts and specifications), which are also expressed in natural language. Special emphasis is placed here on a project manager's action know-how. The know-how base incorporates a project manager's personal knowledge and skill, as well as applicable segments from the project procedure manual.
Figure 1 Relationships Among Meta-WBS, WBS, and Schedule Chart
A new concept, meta-WBS, is presented to obtain the last three key characteristics of the functions in Table 1. Meta-WBS is defined as a multi-dimensional matrix whose axes are project activity, equipment or building, organization, and contract type, as shown in Figure 1. The simplest is a two-dimensional matrix whose rows and columns represent equipment or building and project activity, respectively.
Each element of any WBS, the smallest being a work package, can be mapped onto the meta-WBS, as shown in Figure 1. A WBS is a “family tree” subdivision of the activities needed to achieve the final objective. A different “family tree” is prepared for each project . Therefore, through the meta-WBS, know-how can be shared in many WBSs, i.e., many projects.
Figure 1 also shows that a project schedule chart, like the Project Evaluation and Review Technique (PERT), can be easily connected to meta-WBS. This is the key characteristic for the second function (providing know-how in advance) listed in Table 1.
The meta-WBS plays a central role in providing a good interface with other project management systems. This is because today's project management systems are based on WBS , which can be easily related to meta-WBS.
The “Know-how Based Project Management System” consists of the know-how base, meta-WBS and input/output control as shown in Figure 2. The WBSs or schedule charts for various projects can easily be attached to the system, as stated previously. Through meta-WBS, various kinds of information in the know-how base can be applied to various projects.
Application of the System
Risk Management For Project Execution Stage
As an application of the know-how based project management system, this section presents a risk management computer system for the execution of large construction projects. The system is especially useful for projects undertaken in developing countries.
Dramatic changes in the economic balance worldwide since the early 1970s have spawned many large construction projects in developing countries, especially in the Middle East. In the process of carrying out these projects, a great number of “risks” have been known to recur. “Risks” are defined as undesirable events such as problems and accidents which cause project delay, cost overruns or deficiencies in technical performance. Such risks are primarily due to dramatic escalation in the size and scope of projects, as well as the contractors’ lack of experience in these countries.
Risk management for construction projects covers the following wide range of fields:
• risk management for the pre-proposal stage
• risk management for the proposal preparation stage
• risk management for the execution stage.
Figure 2 Structure of Know-how Based Project Management System
In the pre-proposal stage, one of the most important problems is risk peculiar to a country    , while estimating contingencies in deciding a bid is the main problem in the proposal preparation stage    . In spite of the many arguments presented with regard to the first two stages, there have been few reports which treat the project execution stage.
In the project execution stage, efforts should be focused on isolating risks and preventing them. However, this is very difficult for the average project manager because there are a wide variety and large volume of know-how that are beyond his own ability, especially in large projects. This is the reason why the new system is required. This risk management computer system is now being used at Hitachi, Ltd. It provides the project manager with advance warning of risks as well as suggesting countermeasures.
Outline Of The Application2
The know-how base is a collection of many types of information concerning risks, experienced or foreseen, acquired through questionnaires from many project managers.
There are a vast number of risks involved in construction projects. Their occurrence mechanisms seem to differ case by case. Therefore, it is very difficult to make a general risk model, but it must be made in order to collect risk know-how and to store it in the know-how base. The model presented in Figure 3 has been successfully employed for several hundreds of risks.
The center box of Figure 3 is risks, defined previously as undesirable events which cause project delay, cost overruns or deficiencies in technical performance. The model presents the risk to risk consequent relationship. This means that when no countermeasure is taken for a risk, other risks may happen in the future. Some sample risks are delay in customs clearance, difficulty in obtaining work permits, rearrangement of shipping, and shortage of local currency.
Risk causes have been classified into three groups, contractual defects, management or operational errors, and environmental factors. Examples of environmental factors are weather conditions, poor harbor facilities, labor availability, and changes in laws. Risk countermeasures occur in two forms: pre-risk countermeasures and post-risk countermeasures. Examples of countermeasures will be described later in this article.
Figure 3 Risk Occurrence Model
The Meta-WBS used here is the simplest structure (i.e., a two-dimensional matrix), having rows and columns representing equipment or building and project activity, respectively.
Some sample activities are project engineering, detailed design, procurement/manufacturing, transportation, construction, installation, and commissioning and start-up. These activities have been divided hierarchically into several items, so that the number of total activities is approximately 100. For example, installation has been divided into storage at site, preparation for temporary facilities, carrying, welding, assembling and piping, adjustments, and cleanup.
For equipment or building, a vast number of items such as boiler, turbine, generator, and control room, are listed hierarchically.
Total system structure
An outline of the total system structure is shown in Figure 4. A large amount of risk and risk countermeasure know-how, experienced or foreseen, is gathered by questionnaires from project managers and other participants. The information is then checked by a group of four or five project managers and systems analysts, and finally, it is stored in the know-how base. The project managers of various projects can obtain information on risks and their countermeasures corresponding to their WBS very easily by using portable data terminals (Time Sharing System terminals) connected to their telephones. Site managers can also obtain information at the sites by using a satellite hookup.
Figure 4 Outline of the Total Know-how Based Risk Management System
The lower layer in the large box in Figure 5 shows how an individual project is treated by the meta-WBS. In the upper layer, both risk and countermeasure areas are described on the same meta-WBS by framing their corresponding areas on it. By superimposing these two layers, both risks and countermeasures connected with the work package in question are clarified. For example, the possible risk in work package W11 is R1. The pre-risk countermeasure for risk R1 is CM1, which should have been realized in work packages W1 and W3, which occur prior to W11.
The primary advantage of this method is that a wide variety of risks and their countermeasures know-how can be stored in the know-how base, independent of the work packages for a particular project.
Input and output patterns
Six types of risk know-how extraction, in other words input/output for the risk management computer system, are listed below:
1. When a project work package is the input data, the system output is risk know-how.
2. When a risk cause is the input data, the output is risk know-how.
3. When a risk is the input data, the output is other possible risks caused by that risk.
4. When a risk is the input data, the output is both the causes of that risk and other possible risks resulting from these causes.
5. When a risk is the input data, the output is the risk countermeasures for that risk, as well as the project work packages for which the risk countermeasures should be applied.
6. When a project work package is the input data, the output is the pre-risk countermeasures that should be performed for that work package.
Figure 5 Relationships Among the Know-how Base, Meta-WBS, and Schedule Chart in the Know-how Based Risk Management System
By using type 1, a project manager can obtain the risk alarm corresponding to his input work package before it starts. Type 2 gives possible risks resulting from the input risk cause, which is useful when the project will be carried out under unstable conditions. Type 3 provides possible consequent risks of the input risk, which will occur if no countermeasures are taken. From type 4, a project manager can get a wide range of information on possible risks, because it provides risk alarms in respect to risks that may result from the same causes of input risk. Type 5 provides risk countermeasures corresponding to the input risk. A project manager can use type 6 as a project procedure check list, because it gives him pre-risk countermeasures as check items for his input work package.
Examples of use
Examples of systems uses are shown in Figure 6. A project manager can obtain any combination of the six types in a know-how extraction pattern.
First, when a project manager inputs the work package, “Confirmation of contract terms,” into his data terminal, the output is a risk alarm corresponding to this work package. This is know-how extraction, type 1. Among the alarmed risks, if he wants to know the possible consequent risks of “Owner's request for additional work,” he obtains the possible risk alarm, “Delay in engineering approval,” immediately. This know-how extraction, type 3, means that if he takes no countermeasures to the former risk, the latter risk may occur. If he then wants to be informed of countermeasures for the former risk, he can also get them at once. This is know-how extraction. type 5. One example is, “Proposal of joint study with owner.” Moreover, he can get the causes of the former risk, one of which is, “Difference in social customs,” as well as other possible risks resulting from the causes, which are, “Owner's request of site change,” and, “Owner's request for too massive training material,” which are type 4.
Figure 6 Examples of How to Use the System
An example of know-how extraction, type 2, is also shown in Figure 6; the input is the risk cause, “Severe climate condition,” and one of the outputs is the risk, “Cracking of reinforced concrete tanks.” The last example is know-how extraction, type 6. When the project manager inputs the work package, “Packing,” he obtains the risk countermeasures, one of which is, “To put the same color on every packing sorted by site,” as well as the risk which may happen if the countermeasure is not taken, i.e., “May be delivered to the wrong site.”
The project manager then can give instructions to personnel after careful consideration of this information. This greatly contributes to reducing project cost. Combining this system to other project management systems such as schedule control, cost control, and so on, will bring about more effective results.
Summary and Conclusions
Effective project management requires the ability to respond to unstable conditions and to quickly take corrective action in advance. To develop this ability, acquisition of multi-disciplinary know-how is necessary .
For this purpose, this article proposed a new approach, the development of a know-how based project management system.
First, three essential system functions have been presented. These were: to provide action know-how; to provide the know-how in advance; and to provide compatibility with existing systems. Next, to satisfy these functions, new tools, “know-how base” and “meta-WBS,” were devised and integrated into the new system.
As an application of this new approach, a risk management system for project execution, now being used at Hitachi, Ltd., was demonstrated. A great number of risks that actually happened during many projects and risks which can be foreseen, as well as their respective countermeasures, have been stored in the system. This provides a project manager with a wide range of know-how on risks which may occur during the course of his project, as well as the countermeasures to overcome these risks.
The philosophy in developing the risk management system is that risk know-how transfer among project managers is essential to improving risk management in the project execution stage. This is because no project manager has adequate experience in all areas but, at the same time, the same kinds of risks occur in different types of projects.
1. Bunn, D.W. & Mustafaoglu, M.M. Forecasting Political Risk, Management Science, 1978, 24.
2. Campbell, D.W. Risk Analysis, The 14th Proceedings of the National Meeting of the American Association of Cost Engineers, San Francisco, California, 1970.
3. Carrier, K.C. Contingency, Project Management Quarterly, 1978, 9.
4. Eldin, H.K. and Avots, I. Guidelines for Successful Management of Projects in the Middle East: The Client Point of View, Proceedings of the Project Management Institute Seminar/Symposium, Los Angeles, California, 1978.
5. Gurran, M. A Scientific Approach to Bidding: Range Estimating, Constructor, 1975.
6. Haner, F.T. Rating Investment Risks Abroad, Business Horizons, 1979.
7. Hollenbach, F.A. “The Organization and Controls of Project Management, Proceedings of the Project Management Institute Seminar/Symposium, Chicago, Illinois, 1977.
8. Lucas, J.J. & Durbin, P.L. Automation in Project Management Yesterday, Today, and Tomorrow, Proceedings of the Project Management Institute Seminar/Symposium, Atlanta, Georgia, 1979.
9. Morris, P.W.G. The Use and Management of Project Control Systems in the 80's. Project Management Quarterly, 1980, 11, 25-28.
10. National Aeronautics and Space Administration, Handbook for Preparation of Work Breakdown Structure, NHB 5610.1, 1975.
11. Rummel, R.J. & Heenan, D.A. How Multinationals Analyze Political Risk, Harvard Business Review, 1978.
12. Souder, W.E. Project Management: Past, Present, and Future — An Editorial Summary, Institute of Electrical and Electronics Engineers, Transactions on Engineering Management, 1979, Vol. EM-26.
13. Stobaugh, R.B. How to Analyze Foreign Investment Climates, Harvard Business Review, 1969.
14. Stuckenbruck, L.C. The Educational Path to Project Management, Proceedings of the Project Management Institute Seminar/Symposium, Chicago, Illinois, 1977.
15. Stuckenbruck, L.C. The Implementation of Project Management: The Professional's Handbook, Reading, Massachusetts: Addison-Wesley Publishing Company, 1981.
16. Traylor, R.C., Stinson. R.C., Madsen, J.L., Bell, R.S. & Brown K.R., Project Management Under Uncertainty, 1978 Proceedings of the Project Management Institute Seminar/Symposium, Los Angeles, California, 1978.
1The authors would like to express their appreciation to Dr. Takeo Miura and Hirokazu Ihara of the Systems Development Laboratory, Hitachi, Ltd., for giving them the opportunity to pursue this research.
2An earlier version of this part, entitled “Development of Risk Alarm System for Big Construction Projects,” was presented at the 1979 Project Management Institute Seminar/Symposium, Atlanta, Georgia, 1979.