An Explication of the Viable System Model for Project Management. more

AN EXPLICATION OF THE VIABLE SYSTEM MODEL FOR PROJECT MANAGEMENT Dr. G.A. Britton, Senior Lecturer, School of Mechanical and Production Engineering, Nanyang Technological Institute, Nanyang Avenue, Singapore 2263, Ph. 660-4910, Fax: 264-1859, E-Mail: MGABRITTON@NTIVAX.Bitnet. J. Parker, Principal Development Consultant - Project Controls, MINENCO Pty. Limited, Melbourne, Victoria, Australia. ABSTRACT This paper describes how to model project management using the Viable System Model. It gives a general overview of the model and explains in detail how to model System 4, Systems 3-2-1, the interactions between Systems 3 & 4, and the interactions between management at different levels of recursion. Key Words: VSM, viable system model, project management, cybernetics. Britton/Parker 1 AN EXPLICATION OF THE VIABLE SYSTEM MODEL FOR PROJECT MANAGEMENT 1. INTRODUCTION Non-viable System Law: Anyone can make a decision given enough facts. A good manager can make a decision without enough facts. A perfect manager can operate in perfect ignorance. Beer (1966) has described the operational research method of modelling by which a scientific model is mapped onto a description of a managerial situation. Figure 0 is a modification of Beer’s diagram, and shows how the same method can be applied when using the VSM to model project management. In this case the scientific model is the version of the VSM described in “Heart of Enterprise” (Beer 1979), and expressed in cybernetic terms. The managerial situation is management of a project, or a set of projects, and is expressed in the language normally used in project management. The scientific situation is a class of situations involving project management. From this class of situations the best current practice in project management has been abstracted. The “Project Management VSM’ is an explicit version of the general VSM, expressed in project management terms, that applies specifically to situations involving management of projects. This paper describes a Project Management VSM. Our model can be used directly in the diagnosis and design of project management systems, instead of the general version, because it is specific and the terminological mapping has already been performed. Consequently the time and effort required for modelling is significantly reduced. In writing this paper we make the following assumptions about the reader. Firstly, we assume you are familiar with the VSM as described in “Heart of Enterprise” (Beer 1979). Secondly, we assume you are familiar with basic project management techniques such as Gantt charts, CPM, and PERT. Advanced project management concepts and techniques will be briefly defined and explained in the paper where appropriate: for further details about these refer to Harrison (1985) and Fleming (1988). Our presentation discusses in great detail two critical aspects of the VSM: obtaining focus in System 4 and performance measurement in System 3. System 4 focus is achieved by a Matrix of Accountabilities (defined later in the paper) that integrates the work to be performed, the organisation, and the resources. The discussion on performance measurement covers how to measure performance and the interpretation of the results. Throughout the paper we use a construction project (involving engineering, procurement, manufacturing and construction) as an example to illustrate the mapping, but the model is applicable to other types of turnkey projects. We begin by answering the question: “What is the viable system being managed during a project?” A project is not a viable system, but a “project organisation” may be. A “project organisation” is a group of people and/or organisations that are undertaking a project. There are two circumstances in which a project organisation can be modelled as a viable system. The first case is when a viable system, e.g. an engineering jobbing company, can be subdivided into project groups. The project groups are then viable systems. The second case is when a project is being undertaken to establish a viable system that did not exist before. The project organisation to do this can be considered the developmental stage of that viable system, and therefore a viable system; an example is the construction of a new manufacturing plant. These two criteria are quite restrictive and exclude many project organisations. For example, System 3* of any viable system undertakes improvement projects but the Britton/Parker 2 organisation to undertake these obviously cannot be modelled as a viable system. A viable system model of project management for a construction project is shown in Figure 1. The viable elements are engineering, manufacturing, construction, and commissioning. A critical feature of any viable system is the planning process (Beer 1979). The basis of effective project planning and control is a programme that defines the following: a. What is to be done (the activities to be carried out): activities are specified in an hierarchical form for control purposes. This is called a work breakdown structure (it will be defined later). b. Who is involved (the project organisational structure): specified by the organisation breakdown structure (to be defined later), which shows the authority relationships between people/organisational groups; normally some of these are defined by formal contracts. c. Who is to do what (the accountabilities): specified by a matrix of accountabilities (a combination of a and b above); this concept will be defined later in the paper. d. The sequencing of the activities: specified by an activity network. e. The ‘activity’ relationships between people and organisational groups (i.e. how people relate to each other due to activity interdependence): specified by a resourced activity network (a combination of c and d above). A resourced activity network is a network that has had resources assigned to its activities. f. The rate of work (expected progress): specified by ‘S’ curves. g. The resources allocated to each activity: there are six main classes of resource to be considered - time, money, personnel, materials and components, equipment and information. h. The relative importance of activities: two main criteria are used time and cost. Relative importance is defined by ‘float’ for the time criterion and by relative cost and financial contingency for the cost criterion. i. The communication of information: specified by an activity network, project procedures and contractual obligations. A resourced activity network is the key element of the programme. It defines the activities and their interdependencies, tags resources to activities, and relates the activities and their interdependencies to the project organisational structure via a matrix of accountabilities. It can be used in two ways: (1) for planning and control of work-in-progress (System 3), and (2) for simulation of future activities to develop the best possible original programme and, later on, recovery programmes (System 4). Simulation is a feature which has been made possible by computer technology and replaces the traditional methods of using “standard forecasting curves”. In our view much of the misunderstanding over the use of computerised network planning arises because managers and planners do not recognise the simulation mode or confuse it with control of activities-in-progress. We will now discusss in detail how three major processes in Systems 3 and 4 are carried out and how they interact. The processes are scope-change control-system, project planning for future activities and project planning and control of activities-in- progress. These sub-systems and their interrelationships are shown in Figure 2. 2. PROJECT PLANNING FOR FUTURE ACTIVITIES (SYSTEM 4): FIGURE 3 Britton/Parker 3 A carelessly planned project takes 3 times longer to complete than expected; a carefully planned project takes only twice as long. Augustine’s Law Ill: “Ninety percent of the time things will turn out worse than you expect. The other ten percent of the time you had no right to expect so much.” The “Project Planning for Future Activities” sub-system is the part of System 4 that transforms the budget into resourced activity networks, allocates work for execution, and simulates the effect of scope and project programme changes. The starting point for project planning is an estimate that becomes a budget once it has been approved by the client and the project is given the go-ahead to proceed. This budget has to be adjusted for project control purposes. Full details of how to do this are given in Fleming (1988). Initial planning identifies the activities necessary to complete the project, sequences these activities logically, allocates resources to activities, and specifies how the activities are to be allocated to people/organisations. Vitally important issues to be considered at the planning stage are: defining and communicating the project objectives and their relative priority; defining the work breakdown structure; determining the contracting and purchasing policies; defining and communicating the project operating procedures; and establishing the project planning and control system. 2.1 Network Development Development of resourced activity networks is a two stage process as shown. Firstly unresourced networks are developed. Secondly, these networks are resourced, and activity durations modified where they are governed by resource availability, It is possible to do this as a one stage process, but care must be taken not to introduce false logic links based on resource restrictions. The activities are then resource levelled within the available float to take account of the anticipated availability of resources, and in particular the build-up rate. If the budget format is markedly different from the activity network format, it will be difficult to allocate resources to activities. It will also cause difficulties later when updating the network. It may be necessary to define a translation from the budget format to the network format, but preferably planning personnel should be involved early in the project, even at the feasibility study stage, to ensure a workable budget format. Depending on the size of the project, more than one level of network plan may be required. Figure 3 shows three levels of plans, which would be required for large projects. The plans become more detailed moving from Level 1 to Level 3 (each plan is used at a different level of recursion). The networks are the recurring form at System 4 at the different levels of recursion. The development of such networks takes time and they may be too late to plan key work early in the project. Interim networks should be produced to cover early work. They do not need to be resourced but should identify critical and near critical activities as well as they can be determined. 2.2 Budget/Network Resource Correlation Matrix Resources allocated in the budget must be properly distributed in the resourced activity networks. To check this a budget/network resource correlation matrix can be used. A specified amount of resource is identified with a budget item AND a network activity. Resources are totalled horizontally for checking against the budgeted amounts and vertically Britton/Parker 4 for checking against the network amounts. Four major resources should be checked: time, man-hours, money and possibly material quantities (if applicable). 2.3 Work Breakdown Structure The networks can be viewed as an hierarchical aggregation of elemental units of activity (called ‘work packages’). Such a view is called the work breakdown structure (WBS) (Harrison 1985). It shows how the total project is divided into broadly defined activities, how these are divided into sub-activities, how the sub-activities are divided into sub-sub-activities, and so on down to the work packages. The WBS is used for allocating work and is the basis for determining the number of levels of management required to effectively manage the project. Simply put, the networks are used for coordination - controlling the horizontal work relationships in the project organisation, whilst the WBS is used for integration - controlling the vertical work relationships in the project organisation. The WBS can be used to assist network development and vice versa. Figure 4 shows two examples of Work Breakdown Structures for software development. The first is the traditional approach where all system definition is performed first, then design, followed by development (coding and testing), and assurance. The second is the modular approach in which definition, design, development and assurance proceed concurrently. One difficulty associated with using a WBS is the effective communication of the coding structure so that people working on the project can allocate their hours and other resources to the correct class of activities. MINENCO Pty. Ltd., an Australian project management and engineering design company, have developed a coding structure for estimating project costs that correlates with distinct physical boundaries of the actual facility to be built. Diagrams show people quite clearly how the code relates to these physical boundaries. An example is shown in Figure 5. When the coding structure can be used as the WBS then these diagrams can be used to help ensure accurate coding for planning purposes as well. 2.4 Matrix of Accountabilities The matrix of accountabilities defines who is to do what. The “what” comes from the WBS. The matrix tags people and organisations to activities in the networks for control purposes. It also forms the basis of a multidimensional resource matrix. Each work package at the base of the resource matrix, can have the following resources associated with it: personnel, materials and components, equipment, information, time and money. These resourced packages are commonly referred to as Cost Accounts because costs are normally used to monitor performance of the package. The resource matrix enables progress curves and resource histograms to be derived directly from the networks, and is commonly printed out as a list or lists. Contracting and purchasing policies constrain the form of the matrix of accountabilities and the resourced activity networks. Figure 3 illustrates how vertical and horizontal contracts are represented in the matrix. These policies also determine in part the form of the Organisational Breakdown Structure (OBS). 2.5 Organ isational Breakdown Structure The organisational breakdown structure (OBS) shows the authority relationships between people/organisations allocated work packages and defines the numbers of levels of management required to manage the project. It, in turn, may be largely defined by the WBS and the project strategy. The levels of management required to manage a project derive from the complexity of the activities and their interrelationships and by the way the activities are allocated to people or organisations for execution. For instance, in one case approximately Britton/Parker 5 80% of the work of a project was contracted out to one company; thus the project manager was easily able to manage the project on his own. This did not get rid of the activity complexity, it simply passed control of it to the contractor. The assignment of work packages to people achieves two results. Firstly it maps the WBS onto the OBS. This is essential for proper accountability. Secondly, it allocates resources to the work packages, and therefore to the people responsible to facilitate execution of the work. Once again a difficulty occurs with communicating the OBS coding structure so that people can correctly code their hours and other resources. A tree diagram of the OBS should be produced and promulgated to the relevant people to assist the coding process. Such a diagram also provides people with an overview of the authority structure for the project. Figure 6 shows a commonly used OBS. Another problem associated with coding is that each work package has to be small enough to be coded (classified) two ways without being split: by WBS code and by OBS code. This is essential to permit efficient assignment of resources at the planning stage and when resources are actually spent. 2.6 Interaction Between WBS, OBS, & Matrix of Accountabilities The advantages of the WBS and matrix of accountabilities concepts are that: (1) they open up different possibilities for defining the OBS, (2) the alternatives in (1) can be chosen to reduce the complexity, and hence difficulty, of project management, and (3) the matrix links the OBS to the networks for reporting and control purposes. The resources associated with each work package can be aggregated according to the WBS, the OBS or the activity networks for project control at different levels of management (recursion). Figure 3 shows a partial matrix of accountabilities, that excludes project management and administrative activities, and the corresponding OBS for a simple project organisation consisting of two different companies (the OBS excludes the project management company, which would be shown with authority over Companies A & B). Figure 3 was deliberately drawn this way to emphasize a point about project management authority. In a project organisation involving contractors project managerial authority is very limited. The project manager is a customer of the participating companies and his/her authority is defined by the contract. For lump sum contracts this can be very limited. Consequently, the major influence a project manager has on a project occurs at the design and planning stage rather than at the construction stage. Therefore it is always essential to focus on control of design. 2.7 Planning of Indirect (Non-output) Activities Management, administrative, project control and support functions may or may not be included in the programme and the networks. Although they do not directly affect the project duration, these activities do need to be identified, properly allocated to someone for execution, and the resources required to execute them do need to be budgeted for, scheduled and controlled. If they are not included in the networks then they have to be monitored separately, either manually or by using another computer system e.g. spreadsheets. It is possible to include these activities in the programme and networks as non critical separate activities. Their timing is set by the main activities with which they are associated. The advantages of doing this are that the matrix of accountabilities is not split between two or more computer systems, and resource histograms and resource levelling can performed using the time-scaled networks (these are similar to Gantt charts but also include all the interdependencies between activities). An unfortunate limitation of most of the computer Britton/Parker 6 programs is that they do not allow non linear resourcing, which is desirable for proper representation of indirect activities. 2.8 Organisational Design for a Project Specialised project management companies have organisational structures designed for project work. Commonly they use either a project or matrix organisational structure. Table I lists the frequently cited advantages and disadvantages of these two structures. Our discussion will deal with how the structures relate to the informational requirements, the WBS, as this largely determines the effectiveness of project planning and control. The project OBS corresponds directly with the WBS at the top levels because each person is allocated to one project only. Thus at the top level the people in an OBS grouping are the same people assigned to a WBS grouping. That is, a project team is formed and all the people in the team perform all the activities needed to complete the project. If the one-to-one assignment continues all the way down to individual work packages then there is no need for two coding structures: one will do. However, this is unlikely to occur in practice, except for small projects. In general the OBS will be structured according to functional disciplines at lower levels and the discipline groupings will not be assigned to one unique WBS grouping: the OBS and WBS will be different. The advantages and disadvantages of the project organisational structure derive from the fact that the OBS is directly matched to the WBS at the top level, and perhaps at lower levels. The matrix structure attempts to provide an effective integration between the OBS and the WBS when these are different. In practice the OBS and WBS are designed independently and then a matrix is used to connect them for control purposes and to facilitate efficient use of resources. The major disadvantages of this arrangement are that two command structures are superimposed on each other (Ackoff 1981; Halal 1986; Davis & Lawrence 1977), and no attempt is made to design the OBS and WBS jointly so as to give more effective integration. In this respect manufacturing companies lead project management companies. Techniques have been developed to jointly design the technology (WBS) and the organisational structure (OBS). Two major ones in general use are group technology and socio-technical theory. Suitably modified these techniques are, in our opinion, appropriate for project management companies. For example, in one company three separate groups - estimators, cost engineers & planners - were redesigned to form one multi-functional, partially multi-skilled group: a project controls group. Another example is the use of multi-disciplinary design teams rather than traditional, discipline-based groups. Recently organisational theorists and practitioners have been advocating an organisational structure which they claim is appropriate for most organisations. It is called a multidimensional organisationa! structure (Ackoff, 1981) or a market network (HalaI, 1986). Basically the multidimensional organisational structure (MOS) uses multiple criteria for allocating work at each level of management. The familiar hierarchical pyramid occurs because only 1 criterion is used at each level. The matrix results when 2 criteria are used. However it is possible to use 3 or even 4 criteria at each level. The organisational units in the MOS interact on a market basis, Ideally they should be performance centres, but in practice profit and cost centres are most commonly used. The “internal” market interaction changes organisational accountability. A person who would have 2 bosses in a matrix structure would have 1 boss and a customer/client in a 2D MOS. The client relationship is defined by a contract (Wearne 1985). The MOS is very flexible, can adapt quickly to changing priorities and does not have the disadvantages of the conventional Britton/Parker 7 matrix organisation. We believe the MOS concept offers new possibilities for effective project management. The points we wish to emphasise on organisational design are that the WBS and OBS should be jointly designed to give effective performance and that many different types of OBS are possible. Each organisation needs to develop that combination of WBS and OBS that is best suited to it. Note that the WBS, OBS and matrix of accountabilities provide focus for the Systems 4 at different levels of recursion. 2.9 Progressive Planning Initially the budget, networks, WBS, matrix of accountabilities and OBS are partially defined. As the project progresses they become more and more detailed until at the end of the project they are completely defined. 3. PROJECT PLANNING AND CONTROL OF ACTIVITIES-IN- PROGRESS (SYSTEM 3): FIGURE 7 Petronius Arbiter (66 A.D.): “We tried very hard, but every time we were beginning to form up into teams, we would be reorganised. I was to learn late in life that we tend to meet any new situation by reorganising; and a wonderful method it can be for creating the illusion of progress whilst producing confusion, inefficiency and demoralisation.” Augustine’s Law XIII: “If a sufficient number of management layers are superimposed on top of each other, it can be assured that disaster is not left to chance.” The “Project Planning and Control of Activities-in-Progress” sub-system (System 3) carries out the detail planning of activities-in-progress and controls these activities to ensure they are performed efficiently. Two points should be noted. Firstly, Figure 3 shows that planning is normally a top down process, from master schedule to work packages. On the other hand, control information flow is a bottom-up process. Work-package control-information is aggregated up for checking against the detailed networks and the master schedule. As Beer (1979) has noted the most important aspect of planning and control is the dynamics of the process. Planning and control information are going up and down simultaneously and must be properly coordinated and integrated. Secondly, note again that the resourced activity networks are used for two purposes: control of activities-in-progress and simulation. The simulation facility available with computer technology means that forecast progress curves SHOULD NEVER be produced by direct extrapolation. They should be explicitly derived from the forecast network information. This is a significant difference from the trend projections traditionally used by project managers. 3.1 Performance Measurement “Traditional” progress curves are always ineffective because they are not based on activity networks and therefore do not account for activity interdependence, particularly when there are resource constraints; and they cannot account for changes e.g. changes in productivity and delivery dates. The modern method of project control overcomes both these problems. It is based on the concept of “earned work” illustrated in Figures 8-10 and discussed below. Britton/Parker 8 Three measures of capacity are used in modern project management. The actual cost of work performed (ACWP) which is a measure of actual costs. The budgeted cost of work scheduled (BOWS) which is a measure of potentiality. The earned value of work - the budgeted cost of work actually performed (BOWP) - which is a measure of capability. It is important to be clear what “progress” means. A project progresses if activities needed to complete the project are themselves completed. Hence progress must be measured by the amount of physical completion of activities. Sometimes the only data available is actual expenditure, and progress is equated to this, which is quite incorrect and misleading. Progress must be measured in terms of earned budget. Earned budget man-hours (when applicable) is preferable to dollars as a unit of measurement, as a man-hour is an “atomic” value. Progress in terms of earned dollars is complicated by the potential for change in the $/hr rate, and requires that dollar progress be earned using a baserate $/hr. On the other hand forecasts must use the current or forecast rates. Notwithstanding the above comments, the only common factor between the design, manufacturing, construction and commissioning phases is dollars. If an overall project progress figure is to be used then dollars must be employed as the unit of measure of earned value. A “progress ‘S’ curve” based on actual costs may deviate from the “originally scheduled progress curve” because: a. work progress is different from that originally anticipated (slower or faster); b. resource usage is different from that originally forecast (more or less); c. there has been a schedule change, i.e. work has been carried out in a different sequence to that scheduled. To determine which of these has occurred requires monitoring actual completion of activities and comparing this to the scheduled completion, and comparing the actual resource usage to the budgeted amounts. Figure 8 shows the cumulative scheduled cost curve (BOWS) for a hypothetical project. The cumulative actual costs expended up to the updating date are given by the solid ACWP curve. The actual cost at the updating date is given by the point where the curve crosses the timeline. Also shown is a BCWP curve, which is the budgeted cost for the work that has actually been performed: the cost at the updating date is given where the curve cuts the time-line. Comparison of the BCWP point with the BOWS point, at the updating date, shows whether work content has progressed as expected. A BCWP point above the BOWS point indicates that progress is more rapid (ahead of schedule) and/or that work has been performed in a different sequence to that originally scheduled. A BCWP point below the BOWS point indicates that progress is behind schedule and/or that work has been performed in a different sequence to that originally scheduled. Only a proper network analysis can distinguish these two cases but a good guide is provided by assessing the resource usage. In our example there is an indicated schedule overrun or negative Schedule Variance. Comparison of the ACWP and BCWP points at the updating date shows whether the rate of resource usage is as originally budgeted; that is whether the productivity is as originally estimated. If the ACWP point is above the BCWP point then more resources have been used than budgeted (lower productivity); if it is below then less resources have been used (higher productivity). The resource difference is determined as shown in the figure. In our example the ACWP point is above the BOWS point indicating that a budget overrun, or negative Cost Variance, is likely. Britton/Parker 9 The indicated budget overrun and schedule overrun in Figure 8 taken together mean that it is going to be difficult and expensive to remedy the delay. The “S” curves use aggregated data and are only indicative of potential trouble. It is possible for the curves to show all is well when the critical path (and hence project) is late. Only a proper network analysis can provide all the information needed, but as this is normally time consuming and expensive the “S” curves are used to provide early warning of potential trouble. Figure 9 shows all possible combinations of graphs and their interpretation. We recommend the use of the graphical technique rather than tabulated performance analysis because it is easier to picture what is happening, and it is possible to identify trends earlier if a manual method of identification is used. Costs can deviate because productivity is different to that originally forecast, material costs have changed and/or labour costs have changed. Material and labour cost deviations can be distinguished by monitoring them separately. To determine whether labour productivity is different from the originally forecast, curves similar to the cost curves can be drawn but using man-hours instead of costs: see Figure 10. Performance indices should be derived from the above comparisons and used to produce a revised forecast completion date and total resource estimate (costs and perhaps man-hours) for early warning of deviations to the plan. Should these deviations be unacceptable then a proper forecast should be made using a resourced activity network, and a recovery programme developed if necessary. There may be more than one BOWS curve during the life of a project. For a number of reasons the programme and therefore the BCWS curve may become untenable, and a revised programme may need to be produced. The change will generate a new BCWS curve. Work progress is then compared to the revised curve. The BOWS curve must never be modified except to reflect an approved revision of the programme. This is a brief discussion of a complex topic. For a good introduction to the concept of “earned work” and the associated performance analysis refer to Harrison (1985) and Fleming (1988). A wide variety of techniques for measuring and monitoring resource usage are detailed in Bent (1 982). We conclude this section by critiquing current practices in performance measurement in the light of our VSM analysis. 1. The BOWS curve, and therefore the BCWP curve, are based on what is feasible and not on the best possible performance. Therefore there is little incentive to perform better than scheduled performance. 2. The warning limits (variance thresholds) for the graphs are arbitrarily set independently of the network. They should be based on the network taking into account all resource constraints. 3. In general point estimates are used. When statistical estimates are used they apply to time only and are not integrated with costs and resource usage. 3.2 Resource Interdependency Often the resources associated with the work packages are monitored and controlled inde by separate systems e.g. money might be controlled by an accounting system, personnel by a personnel planning system, and time by a CPM planning system. The resource forecasts Britton/Parker 10 produced by these systems will be incompatible and false because different assumptions about the real-world resource interdependencies will have been made by each system. The resource interdependencies WITHIN a work package are defined by the work scope, the expected rate of work progress and the method used to execute the work. More precisely we can say: work package time duration = f(personnel, materials, equipment, information) work package cost = g(personnel, materials, equipment, information) where ,the functions f and g are defined by the work scope, the expected rate of work progress and the method of execution. The resource interdependencies BETWEEN work packages are defined by the networks. The importance of the matrix of accountabilities can now be better appreciated. Through it, resource forecasts can be integrated because the matrix is based on work packages and linked to the activity networks. That is, the people involved in calculating cost and time are using the same basic data, the same assumptions about the activities to be performed and their sequence, and the same assumptions about the allocation of resources to activities and the interrelationship between time and cost for each activity. 4. INTERACTION BETWEEN PLANNING FOR FUTURE ACTIVITIES AND PLANNING AND CONTROL OF ACTIVITIES-IN-PROGRESS: FIGURE 11 How does a project get behind schedule? One day at a time! Augustine’s Law XXV: “The only thing more costly than stretching the schedule of an established development program is accelerating it, which itself is the most costly action known to man.” Once a resourced activity network has been developed the network information can be sent to those people controlling the actual design, manufacturing and construction activities. Typically the information will be in the form of Gantt charts and resource histograms. Timescaled networks should be used in preference to Gantt charts because they display activity interdependence. Figure 11 shows how the information is transferred from “Project Planning for Future Activities” to the different levels of management controlling activities-in-progress. Figure 11 also shows five feedback loops from “Project Planning and Control of Activitiesin-progress” to “Project Planning for Future Activities”. The three upper loops (labelled A) are feedback on the performance of activities-in-progress used in simulations to forecast the amount of deviation from the scheduled programme and for developing recovery programmes. The fourth loop (B) is engineering feedback to revise the forecast because of changes for work within scope. These may be design changes and/or changes in the estimates of the amount of resources budgeted for, The information feedback via this loop should not only revise the forecast but also the networks. The fifth loop (C) is engineering information, e.g. designs and specifications, that is used to progressively detail the budget, the WBS and the networks, and to allocate work. Feedback delays must be kept within acceptable bounds if the networks are to be the primary source of planning and control. Undue delays mean the networks no longer reflect what is currently happening and consequently decision-making performance suffers. Problems should not (but sometimes do) occur with the fifth loop because engineering information Britton/Parker 11 should be explicitly included in the networks as work packages (but sometimes is not). The other loops are not explicitly part of the networks but can and should be specified in the project operating procedures. A major limitation of most existing computer software prevents effective interaction between “Project Planning and Control of Activities-in-progress” to “Project Planning for Future Activities”. Planning should be carried out in detail in order to obtain accurate estimates for resources and activity completion times. But monitoring and control should be carried out in less detail to reduce the amount of data that has to be collected (Beer 1979). Unfortunately most existing computer software does not allow activities to be defined in detail and actual usage of resources to be entered in at a higher level. The actuals have to collected and entered at the detail level, they are then automatically summed up at the higher level. 5. SCOPE-CHANGE CONTROL-SYSTEM (SYSTEMS 3, 4 & 5): FIGURE 12 Augustine’s Law XVIII: “There are three kinds of pro grams which suffer incessant budget tampering: those which are behind schedule, those which are on schedule, and those which used to be on schedule.” The “Scope-change Control-system” detects scope changes (changes in specification) due to activities-in-progress, ensures scope changes are properly approved by the client, and incorporates client initiated changes in the planning and control system. It controls the interrelationships shown by the solid arrows in Figure 12. Scope-change control is a process involving Systems 3, 4 & 5. Scope changes are shown as a lightning strike in Figure 12 because they generally disrupt project planning and control, although they need not. Scope changes may be client initiated (or by the project manager in conjunction with the client) or may arise from activities-inprogress. Client initiated changes start at arrow 2 in Figure 12. Activities-in-progress scope changes (arrows 1 in Figure 12) can occur in two ways. Firstly, a scope change may be proposed by engineering or someone else and forwarded to the client for permission to proceed with a feasibility study. If the client approves the study the proposal will go to engineering for detailing and resource estimation. The detailed change with resource estimate is used to produce a provisional revised budget estimate. The network(s) should also be provisionally revised to evaluate the effect of the change on the schedule and the project resource requirements. The complete results are forwarded to the client for approval. If the client approves the scope change then the provisional revisions to the budget and network(s) are confirmed and become the new budget and network(s) against which progress will be monitored. The second way activities-in-progress scope changes can occur is that work is completed before it is realised that a scope change has occurred. If this happens whoever has done the work will forward details of the additional work and resource usage to the client for approval. The client will generally forward the details to engineering to check that the quoted figures are reasonable. The budget should also be provisionally revised to evaluate the effect of the change. If the client doesn’t approve the change obviously whoever did it will not be paid for the work associated with it, and the provisional revised budget will not be confirmed. The change will not be included in the networks but the project may be delayed because resources have been spent on work not planned for. If the change is approved then the provisional revisions to the budget are confirmed. The scope-change control-system should be designed to detect activities-in-progress scope changes, to ensure scope changes are properly approved by the client, and to effectively incorporate client initiated changes in the planning and control system. Unfortunately in Britton/Parker 12 many cases this is not carried out. A provisional revised budget is produced for client approval and that is all. It is implicitly or explicitly assumed that the additional resources required by the change will be available when they are required, and therefore that the project schedule will not be affected. In general this will not be so. Another disadvantage of not simulating a scope change is that there can be substantial delay in getting the scope change details to the planners to update the networks and so they no longer accurately reflect the scheduled work. Progress monitoring based on the networks will not be effective. The scope-change control-system is mainly a System 4 activity. But it also involves System 5 which approves scope changes, and System 3 which monitors and controls scope changes resulting from work that has been completed and approves some changes under delegated authority from System 5. In addition System 3 interacts with System 4 in planning and evaluating the effects of changes. Scope changes are promulgated via the command axis, but there will also be planning links between Systems 4 at different levels of recursion as they revise the networks to take the changes into account. 6. THE AROUSAL FUNCTION The arousal function analyses command axis information in different ways to detect patterns in the data that are indicative of instability. For a project instability is normally defined as a cost overrun, schedule delay and/or inadequate quality. In practice three techniques are used to perform the arousal function with respect to cost and schedule overruns. Firstly, there is an informal method in which the project manager or engineer wanders around the work site and senses something is amiss. The second method is performance analysis using “earned value of work”. A full performance analysis is performed at regular intervals for all relevant activities. Trend analysis of costs and man-hours can provide early warning of probable cost or schedule overruns of critical activities and thus enables corrective action to be taken early before they exceed the scheduled limits. Thirdly, for non-critical activities, the rate at which float is being used on the non critical paths is monitored against milestones and forecasts are made to determine whether all the float is likely to be used before the milestones are reached. Thus there is early warning of paths that are likely to become critical enabling corrective action to be taken before the paths do become critical. This kind of analysis is known as float management. 7. IMPROVING THE PROJECT PLANNING AND CONTROL SYSTEM (SYSTEMS 3* AND 4): FIGURE 13 Augustine’s Law XLI: “The more time you spend talking about what you have been doing the less time you have to do anything. Eventually, you spend more and more time talking about less and less until finally you spend 100 percent of your time talking about nothing.” The planning and control system described above provides early warning of deviations from schedule and budget and gives effective control. For projects lasting less than 6 months it will not be possible to improve the performance of the feedback loops of the control system because of the short time duration. However on longer projects the performance of the feedback loops can and should improve over time, thus improving control. But more needs to be done if an organisation carries out project work frequently. The procedures producing undesirable results should be changed so that they no longer produce them. In addition they should be developed to reflect the changing demands of the organisation and its environment. Hence all the procedures and feedback loops shown in Figures 3, 7, 11 and 12 need to be reviewed and improved: see Figure 13. Britton/Parker 13 7.1 Improving Procedures During a Project In practice the higher order learning (improving procedures) is carried out in two main ways: dunng projects and between projects. Procedures can be improved during a project if it has a long time duration e.g. 1 year or more. To do this a review procedure must be included in the project procedures. 7.2 Improving Procedures Between Projects Procedures can be improved between projects by pooling and analysing the experiences gained from individual projects and using this as the basis for improvement. The experiences can be recorded in a project “close-out report” which should be standardised so that the experiences can be easily compared and analysed. The close-out report should summarise how the project was managed and identify procedural problems and successes. The following information should be recorded for the important and highlighted procedures: a. A description of how the procedure was designed and who participated in designing it. b. The expected effects of the procedure. c. The assumptions on which the expectations were based. d. A summary of the actual information input to the procedure and the actual results. e. A comparison between the actual and expected results. (Note: the close-out report should also include other information to assist in the design and planning of future projects). 8. LINKING THE PROJECT MANAGEMENT SYSTEM WITH THE CORPORATE MANAGEMENT SYSTEM: FIGURE 14 Russell Ackoff: “A large number of management in formation systems in operation have failed to meet the expectations of the managers they are supposed to serie. For this reason reference to them as MISs seems particularly appropriate.” This section is relevant to organisations undertaking project work on a repetitive basis. It explains how to integrate two levels of recursion: the management of individual projects and the corporate management system needed to run an organisation as a successful business. Each project undertaken by an organisation will be controlled by a project manager according to a programme. The programme should detail the resources required to achieve it in a timephased schedule. Some of these resources will be “owned” by the organisation and hence are corporate resources. The total of all corporate resources for all projects (currently being undertaken) is the resource aggregate committed to clients which corporate management is monitoring and controlling. Thus whilst project management is management of a project, corporate management is, in part, projects management. Projects management is internal control (System 3) at the corporate level; see Figure 14. Corporate management also encompasses other activities, some of which are listed below: * definition and promulgation of corporate values * corporate policy-making * technical development (development of services, computerisation, etc) Britton/Parker 14 * organisational development (development of organisational structure, value system, information and control systems, human resources, and incentive schemes) * business development (search for tenders and prepare bids for proposed projects, competitor analysis, development of new markets for existing services, development of markets for modified services, development of markets for new services) * resource planning (planning to make available resources required to meet current project requirements and future corporate developments) * corporate accounting to meet taxation and other corporate requirements Projects management needs to be interfaced to these other requirements. In principle this can be done as follows. Information about the availability of the corporate resources, the amounts required to complete current projects, the actual resource usage, etc. is required by both project management and corporate management. If this basic data is captured electronically and appropriately coded, then it is a straightforward operation to summarise the data for project managers on a project by project basis (using the WBS and/or project OBS), and for corporate managers according to the corporate organisational structure (using a corporate OBS or a corporate financial classification system). The project-management, computerised information-systems can be used for both purposes. Each project is treated as sub-project of a portfolio of projects. The portfolio is managed by corporate management and each project by a project manager. “System 1 people and equipment” not assigned to a client project can be treated either as overhead or assigned to an in-house development project. In-house development projects can be included in the projects portfolio. Other people at the corporate level not directly involved in projects can be organised as overhead, tax, cost, profit or performance centres and the costs and profits of their activities appropriately distributed to the various projects. Although the principle behind the integration is simple, in practice it may be hard to achieve because: a. an organisation may be using different computer hardware and operating systems that are incompatible; b. different classification and coding systems may be used by different parts of the organisation; c. different procedures (some of which may be computerised) may be used by different parts of the organisation. The first difficulty is largely solved by the modern generation of relational database systems. For example, ORACLE relational database system runs on approx. 80% of the major hardware platforms and operating systems currently available. The second problem can be resolved by using either mutually compatible classification and coding systems or one standard system across the whole organisation. In practice, the requirements of the corporate accounting system are totally different to those of a project Britton/Parker 15 management system and so most companies operate two accounting systems: a corporate system and a project system. But the two systems do have to be interfaced. An example is the Cost/Schedule Systems Criteria of the US Defence Department which specify a minimum level of interface to ensure proper allocation of overheads (Fleming 1988). The third problem is the most difficult. In principle it requires establishing mutually compatible procedures or a standard set of procedures across the whole company. In practice there is no body of knowledge to guide us how to do this, but we believe cybernetics provides some guidance at the theoretical level. 9. CONCLUSION We have described and explained a detailed application of the VSM for project management. The model can be used effectively in two ways. Firstly it provides a powerful means for analysing deficiencies in the management of a project. Secondly it can be used as a guide to design new systems. The model details the essential requirements for viability. These requirements can be executed in practice by specifying procedures, and the organisational structure and equipment needed to implement them. The model can be used as a guide to write the procedures, design the organisational structure, and specify the equipment. The authors have used the model to design and implement project management systems for two organisations. We have also applied it to the management of software development projects and shown how it can be used to unify information management in the construction industry in Singapore (Britton and Parker 1 989). It should be noted that our model is incomplete. Clearly we have not covered all aspects of Systems 3 & 4. More importantly though, we have not specified in detail how System 5 works. System 5 is all the people affected by the project and project organisation. Those people outside the project organisation can be considered the CLIENT. This is the proper interpretation of “client” in our diagrams. We conclude by remarking on an interesting feature of the model. We have previously noted that the activity networks are used by both Systems 3 & 4 (this is to be interpreted as including System 2 also). But in addition to this, a simplified version of the networks is the technological model describing System 1. Functionally the networks are holographic. If this feature is matched by an organisational structure in which many people perform multiple roles in Systems 1, 2, 3 and 4 then the result is a holographic organisation structure (Trist 1980, Morgan & Ramirez 1983). Everyone “knows” the networks that represent (most) of the whole: the whole is contained in the parts. 10. REFERENCES Ackoff, R.L. (1981). Creating the Corporate Future. John Wiley, New York. Beer, S. (1966). Decision and Control. John Wiley, London. Beer, S. (1979). The Heart of Enterprise. John Wiley, New York. Bent, J.A. (1982). Applied Cost and Schedule Control. Marcel Dekker, New York. Britton, G.A., and Parker, J. (1989). Using a Project Management System to Unify Information Management in the Construction Industry. Paper presented at the First Institution of Engineers Singapore Information Technology Conference, 25-27 May, Singapore. Britton/Parker 16 Davis, S.M., and Lawrence, P.R. (1977). Matrix. Addison-Wesley, Massachusetts. Fleming, Q.W. (1988). Cost/Schedule Control Systems Criteria: The Management Guide to C/SCSC. Probus, Chicago. Halal, W.E. (1986). The New Capitalism. John Wiley, New York. Harrison, F.L. (1985). Advanced Project Management. Gower, Aldershot. Morgan G. and Ramirez R. (1983). Action Learning: a Holographic Metaphor for Guiding Social Change. Human Relations, Vol 37, No. 1, pp 1-28. Trist, E.L. (1980). The Environment and System-Response Capability. Futures, April, pp 113-127. Wearne, S.H. (1985). Matrix management or internal contracts? International Journal of Project Management, Vol 3, No. 1, pp 55-56. TABLE I: ADVANTAGES AND DISADVANTAGES OF PROJECT AND MATRIX ORGAN ISATIONAL STRUCTURES PROJECT ORGAN ISATIONAL STRUCTURE Advantages: * oriented towards client and work output * easy to achieve effective planning and control * give good integration of project personnel * cost accounting is relatively simple Disadvantages: * results in inefficient use of resources * staff career development relatively poor * co-ordination problems occur if there are a number of projects being simultaneously executed that interact due to activity or resource interdependence * relatively inflexible: new projects are undertaken by breaking up existing project teams and reorganising new ones MATRIX ORGANISATIONAL STRUCTURE Advantages: * gives efficient use of resources and effective control of projects * flexible to a considerable degree: priorities between input and output structures can be easily changed by altering the resource balance between them * provides good training of middle managers to be general managers Disadvantages: Britton/Parker 17 * if both command structures are bureaucratised then poor performance will result through power struggles and their slowness of response * a high level of management competence is required to effectively operate a matrix * there can confusion/ambiguity between the two set of priorities (input & output) * managers may spend so much time and energy operating the matrix that they neglect the business environment Britton/Parker 18 Britton/Parker 19 Britton/Parker 20 Britton/Parker 21 Britton/Parker 22 Britton/Parker 23 Britton/Parker 24 Britton/Parker 25 Britton/Parker 26 Britton/Parker 27 Britton/Parker 28 Britton/Parker 29 Britton/Parker 30 Britton/Parker 31 Britton/Parker 32 Britton/Parker 33