8 Change Management
Cost-schedule management, also known as integrated change management, is the process used during project execution to minimize the cost of the project while maintaining acceptable levels for its duration, quality, and scope of the deliverables. Project information that would form the basis of a progress monitoring and cost-schedule management system include detailed descriptions of client objectives, project requirements, project charter, quality expectations, resource constraints, funding structure, acceptance test details, administrative milestones, and the anticipated delivery date.
The cost-schedule management process should not be treated as separate from the estimating, scheduling, and budgeting processes. Rather, it should be treated as the integrated principal component of a process that is composed of the revolving phases of developing the estimate for cost and duration, establishing the budget, managing the inevitable changes to the project, and making modifications to the estimate and schedule.
If the final, definitive budget is established from an early inaccurate estimate, the project stakeholders must be sensitive to the precision limitations of those estimates. In other words, the project estimate should be treated as a living document and updated as frequently as possible. Therefore, it is reasonable to expect that the estimate of the total cost of the project might vary with every estimate update, although a change in estimate will not necessarily trigger a change in budget.
Even if the estimate of costs were reasonably accurate based on the detailed information available at the time of the early estimates, it is very likely that implementation costs will not match the planned costs due to unexpected changes in client requirements, design philosophy, scope, and project environment. Thus, the data collected during the progress monitoring process will be used to quantify the impact of the project changes on the general direction of the project’s overall performance.
The cost-schedule management process is most effective when it is formalized and integrated with the organization’s project management policies and procedures. A formalized cost-schedule management process will ensure that all project personnel, in all projects, will follow a specific set of established procedures. A formal management structure will have the added advantage of keeping all the project stakeholders involved in, or at least informed of, the project’s performance status, thereby contributing to team spirit and good morale.
It bears repeating that the most effective cost management system is one that ensures consultation with the stakeholders in all triple-constraint tradeoff decisions, and one that facilitates a full and prompt dissemination of the subsequent disposition of each change request to project personnel.
The objectives of the cost-schedule management process are to track progress, compare actual values to planned values, analyze the impact of variances, and make adjustments in light of these variances. Additionally, determination of the variances between planned and actual values should not narrowly focus on the total project; rather, it should span all individual elements of the WBS.
The current value or variance of individual component resource expenditure and costs, as well as those for the total project, should always be at the disposal of the project stake-holders. Interpretation of the progress data from the current project will be performed in light of historical data from previous projects or benchmarking data from other projects within the same industry. These interpretations must be repeated or refreshed on a regular basis and as part of the inevitable scope changes throughout the life of the project.
The impact of each change must be evaluated in terms of scope, cost, schedule, and resource demand. It would be unrealistic to expect good planning to eliminate all unexpected events. On the other hand, when the project is carefully planned, it is logical to expect a reduction of the magnitude and impact of project changes brought on by unexpected events.
Whereas a project with casually evolving plans will contain many unexpected changes, a well-planned project should have significantly fewer unexpected events, and the consequences will be less dramatic. It is therefore essential that the project manager conduct careful early planning to minimize the frequency and impact of project changes.
The next step in change management, which includes both cost and schedule management, is to determine whether or not the performance variances and trends are significant. If variances are significant, an adjustment of the triple constraints must be considered. This adjustment could be simply a change to the budget value alone. Alternately, in response to these new developments in project environment, the adjustment could involve a change to the values of all triple constraints.
The basic administrative structure of a typical cost management system will include a change management board, a configuration management board, a change request form, and a change log. The change management board and configuration management board review the changes from a project management viewpoint and from a technological standpoint, respectively.
The change management board normally is composed of the project manger, the client liaison, client technical personnel, project personnel, and a contract officer if the project is an external project. The change management board is charged with defining and handling project change requests. Then, during the implementation phase, the board ensures compliance with these established processes and procedures. The primary focus of this board is to assess the impact of change on the triple constraints of the project.
The configuration management board normally is composed of all the technical specialties represented in the project deliverable, the client representative, and project management personnel. This board is charged with monitoring and documenting the functional and physical characteristics of the components of the deliverable, as defined in the original project documents. The configuration management board is further charged with managing the changes to these characteristics, optimizing the effects of changes, and verifying conformance of the attributes of the deliverable with the client’s evolving specifications.
As an example, the configuration board would be concerned with the impact of these changes on the input/output structure of other modules, processing speed, maintenance complications, database duplication, and system complexity. On the other hand, the change management board would review, in light of the client’s current expectations, the impact that a change in a software module might have on the delivery date and on the total cost of the project.
Procedural consistency in data collection and reporting will encourage the stakeholder to review changes, thus preventing ad-hoc implementation of changes. Figures 8-1 and 8-2 show a sample change request form and a typical format for the change management log, respectively. The change request form is the prescribed mechanism for requesting, approving, and announcing project changes. The change log is a historical account of the evolutionary history for scope, configuration, cost, and schedule.
Essential in the cost-schedule management process is maintaining the delicate balance between providing a timely and complete flow of information to those who need a lot of information, while not overwhelming those who do not need to receive all the information. As each report is designed, defined, and distributed, special attention must be paid to the rationale used to determine which particular report is being sent to a particular individual. The expected response from the recipient of that report should also be defined in detail.
Figure 8-2
Change Management Log
The cost-schedule management process need not be elaborate if the project is very small or if it involves only three or four people, although the project cost-schedule management system needs to be formalized nonetheless.
The necessary data and the essential tools of cost-schedule management activities include the current and updated work breakdown structure, cash flow constraints, details of current estimates of time and duration, budgets, timely progress reports, and accurate change reports. Additionally, it would be exceptionally helpful if the change management system were assisted by project management software that is responsive to the specific needs of that particular project.
Project management should never allow the shortcomings and constraints of the project management software package to handicap the change management process. Common solutions for overcoming shortcomings of the standard packages include opting for an add-on to the package or augmenting the software with accounting software such as a spreadsheet or a database package. Of course, selecting a different software package should always be an option.
Experienced project managers are fully aware that treating the budget as an immovable object does not prevent project cost and schedule variations; it simply discourages good record keeping and makes unavailable the data that might have isolated and explained the very likely future cost overruns. When the variance between the current and forecasted cost and duration values exceed the threshold set by the project manager, the project manger should request that the budget be adjusted to the then-current value of the estimate.
Understandably, some project environments preclude this process. In such organizations, project managers tend to add contingency buffers to the early estimates to mitigate the impact of future changes. In very rare cases, project managers do not explicitly show these buffers as such; they simply report the buffer-modified estimate as the definitive estimate. This practice is not recommended because it distorts the historical data collection that is necessary for improving future estimates.
During the project’s implementation phase, the project manager will be placed in situations in which he or she must make tradeoffs among the triple constraints of the project. The process of making tradeoffs will be consistent if the project manager, in concert with the stakeholders, has determined the ranking of the triple constraints.
Making such a ranking is very difficult for the stakeholders because they often hold all of the triple constraints as important and somewhat unchangeable. However, it is imperative to determine priorities when faced with choices between, for example, cost and schedule. Put another way, at least one of the triple constraints should be modifiable and forgiving.
CAUSES OF CHANGE
The mission of a change management system is not to control the costs and schedule at the original estimate level, which may or may not have been accurate. The change management process should be designed to manage the inevitable changes to the project with the least combined impact on the triple constraints of cost, schedule, and scope.
Innumerable circumstances can change the project environment or its constraints. However, the circumstances causing change, or the sources of project changes, can be grouped under the major categories shown in Figure 8-3.
Figure 8-3
Reasons for Change
The first category of changes includes those generated by the client. The client may not have articulated the project objectives correctly or accurately at the inception of the project, and thus midway into its completion, the client may sharpen or modify the focus on the objectives. Such restatements of the project objectives can be implemented without any appreciable effects on project plans, although usually they do affect the baseline plan and cause delivery disruptions.
Client revisions to the requirements can be technical in nature, or they might restate the time, cost, or resource constraints of the project. In turn, time and resource constraints might set new delivery dates, new cash flow patterns, or modified restrictions on overall project expenditures.
Unexpected and unplanned project conditions include items such as changes in operating system, hardware characteristics, environmental platforms, environmental conditions, and occurrences such as strikes, tornados, snow storms, etc. It goes without saying that unexpected events never can be prevented, and their impact cannot be totally eliminated. However, the impact of unexpected events will be minimized in projects that include a comprehensive risk management plan that is fully integrated with the planning process for cost, schedule, and scope. Optimistic project managers hold the belief that a certain number of welcomed and positive unplanned events also are possible.
The occurrence of major evolutions of design philosophy is somewhat frequent in projects that depend on new technology. In projects that are highly dependent on cutting-edge innovations, the design team often will suggest a new design for the deliverables midstream into the project and in light of the current developments in that discipline.
As much as these innovations are welcome in the deliverable, their introduction into the project plan sometimes will have a negative effect on the cost and schedule of the project. Normally, the cost of remedial actions necessary to deal with the changes in circumstances can easily be attributable to the client and will become part of the new budget for the project.
A variation of the change in design philosophy can also occur when the project design team discovers a flaw in the basic design of the project. Depending on the character of this design flaw, corrective measures and product restructuring will affect the cost and schedule of the project. The cost of recovery for this category of events is borne by the contractor if the contractor was responsible for the design, and by the owner if the design was performed by the client or by a third-party designer.
In most projects, there is an ongoing debate as to whether a design change was the result of an infusion of new technology or simply a bug-fixer. This kind of debate does not occur for internal projects—at least not in the same intensity—primarily because the client is responsible for cost overruns regardless of how they happen. Notwithstanding, the separation of the cause of overruns can be used as a mechanism for judging the internal project manager’s performance.
Finally, the cost of a project and the delivery schedule may have to be modified to account for implementation errors, such as substandard equipment, low quality components, or excessive error rate for a software component. In the case of external projects, if the client participates in developing the project implementation activities, then the cost of recovery must be shared between the client and the contractor.
If the contract is of the cost-plus type, determining the allocation of these additional costs might become very delicate and complex depending on the extent to which the client orchestrated the contractor’s activities. However, if the project is an external fixed-price project, the contractor may need to absorb the cost of recovery from implementation errors. By contrast, if the project is internal, the client will absorb the cost increase for this last category of items as a matter of sponsorship.
Because of the complicated backdrop of contractual issues, when a change is observed in the performance or the objective of an external project, the first issue to be resolved between the client and contractor is to which one of the above categories the new change will rightly belong. The answer will determine who will absorb the resulting cost variances. This debate forms the basis for much client-contractor litigation.
FEED FORWARD
There is no question that some of the data that are collected by the cost-schedule management system will benefit future projects by establishing trends, baselines, and benchmarks. However, detailed cost reporting data also offer substantial benefits for the performance of the current project. These benefits are observed primarily during the status meetings that deal with project change deliberations; detailed progress data will facilitate a more informed decision-making atmosphere. Additionally, in larger projects, data from earlier stages can be used to assist with managing the later stages of the project.
Having a formalized change management process in place makes it possible to fine-tune the estimates of components that will be developed during the later stages of the project on the basis of the performance of earlier components. Figure 8-4 shows the reported progress for one element of the WBS along with the assumptions for that element. Figure 8-5 shows the forecast values for a similar component that will be implemented during the second half of the project.
Figure 8-4
Simple Schedule Network Forecasting (assumptions)
The benefits of the availability of detailed project data might extend even further. With a sophisticated cost monitoring and management system in place, and using the feed-forward technique, a seasoned project manager would be able to adjust the estimated progress rate of the second half of a component based on the performance of the first half of the same component.
Literature shows that, in most projects, the trends established during the first 15 percent of the project life are expected to continue through the life of the project unless major redirection is applied (Anonymous2 1999). Of course, if the project has not implemented a sophisticated progress monitoring system, these trends will largely go undetected.
IMPACT OF SCHEDULE ON COST
During the project’s early planning stages, the cost estimate is predicated on certain assumptions about the pace of the project and about the scope and quality of characteristics of the deliverables. Accordingly, because cost is directly affected by changes in duration and scope, managing the cost always will have to be in concert with managing the scope and schedule. Even when the baseline project scope remains unchanged, changes to the project schedule will result in corresponding changes in the resource expenditure and cost of the project. The midstream project changes may affect the scope, effort, resources, materials, cost, and time.
The traditional and simplest form of conducting projects is sequentially and in phases. This form of project execution minimizes the errors that can be introduced into the project deliverable due to rapid implementation, hasty communication, and workplace congestion. Figure 8-6 shows the traditional project sequencing, which produces the lowest cost of all options, although it takes the longest of all the sequencing options to complete the project.
A typical construction, industrial, or process project will have the following generic phases: preliminary design, detailed design, prototype development, construction, acceptance testing, and turnover. A typical software system development project generally is composed of the following phases: requirement statement, requirement analysis, system design, implementation, unit testing, integration, system testing, and delivery.
Since projects are intended to develop deliverables that must ultimately satisfy a specific business need, there is always a certain amount of pressure on the project manager to finish the project sooner. It is therefore important to be aware of the implications of compressing the project’s duration.
Figure 8-6
Project Stages
Experience in construction and industrial projects has shown that there is a threshold beyond which project duration cannot be compressed—normally about 50 percent of the optimum duration. This threshold is commonly referred to as the “crash point.” The goal in compressing projects is to compress project duration only to those durations that lie above the crash point.
There are two ways of achieving a shorter duration for the project: by modifying the project scheduling network through sequencing of the various activities and phases, or by shortening the duration of the individual critical path activities of the project.
The network modification is performed after carefully reviewing the network logic and by segmenting bigger activities into smaller ones to achieve a tighter network. If the project duration is compressed by fine-tuning the sequence of the phases, the nature and composition of these components must be changed to accommodate an overlapping execution sequence for the components. Thus, the shorter duration for the project is achieved by breaking the project into as many phases as possible, and starting each phase as soon as possible and not necessarily after the full complement of the logical predecessor phase is completed (see Figure 8-7). This technique is called “fast tracking” in construction projects, “concurrent engineering” in industrial and process projects, and “rapid application development” in software system development projects.
An example of this technique in the construction industry would be to release the design documents in small increments so that construction of the facility can start well before the entire facility is fully designed, rather than wait until all components are designed before beginning the construction (see Figure 8-8). Thus, the constructor will pour the concrete for the foundation while the steel building frame is being designed.
Figure 8-8
Typical Project Phases
An example of this technique in the software industry is to begin developing individual components as soon as a discrete portion of the requirements is defined. Another example in the software industry is testing individual modules as they are developed, rather than waiting to test all components together when the software development is fully complete. It bears highlighting that testing individual modules one at a time may not be as cost-effective as testing all the modules at the same time, while testing the integrated product. Further, there is an inherent drawback in overlapping phases that are logically serial.
When such phases overlap, the resource intensity impact, cost impact, and even schedule impact of recovery from errors and reworks are somewhat drastic; this cost increase is commonly referred to as the “cost of errors.” Notwithstanding, the incentive to use the method of overlapping phases is that if the project is implemented smoothly, the delivery date is far more attractive. This expectation does not always materialize.
The second means of reducing the project duration will involve compressing the critical path—not by reducing the number of activities in the chain, but rather by compressing selected activities of the critical path. Compressing individual critical path activities would involve adding more shifts or a larger crew size to a given activity to reduce its duration, and hence that of the project.
Activities are selected by prioritizing critical path activities based on the costs associated with compressing an activity, by ranking them according to the risk associated with each activity compression, and by prioritizing these elements based on their impact on schedule. Needless to say, critical path elements will not be considered for compression if the associated costs are prohibitive, risk is too high, or schedule impact is minimal.
Remedial actions can be applied only to those elements and activities that have not yet started, and possibly to some that are underway. If the activity or element whose scope has been changed has been completed before the scope increase, the remedial action is reflected as a new activity. If there is a reduction is scope of an activity that has already been completed, there may not be any change in cost if rework is not necessary.
Decrease of scope should, in general, be applied to tasks that are incomplete or not yet started. The strategies for dealing with midstream project changes might include:
• Accept cost change, no schedule change, no quality change
• Perform incomplete tasks by employing personnel with lower rates, if possible
• Reduce duration for incomplete tasks by altering resources, if possible
• Increase productivity by using experts from within the firm
• Increase productivity by using experts from outside the firm
• Reduce scope, if feasible
• Utilize contingency fund of the project
• Conduct a value engineering review
• Change task assignment to take advantage of the schedule float
• Add people to the project
• Outsource the entire project or a significant portion of it
• Compress the schedule
• Work overtime.
Experience in construction, process, and industrial projects has shown that there is a minimum cost for each task and that this minimum cost will occur when the optimum crew size and optimum shift duration are implemented. Therefore, the original project cost baseline should be derived from the original elemental cost baseline, which in turn was developed using optimum crew size for those tasks.
By extension, the baseline duration should be the optimum duration because this is the pristine baseline. The same holds true for the cost. Then, if performance duration other than the optimum duration is chosen midstream for the project, the effects of such duration compression or expansion on cost can be determined methodically and consistently using a formulation similar to the normalized curve depicted in Figure 8-9. This cost-duration relationship can be applied equally well to individual tasks and the project as a whole.
As the estimate of resources and cost for each element and module of the project is refined with new and updated information, the optimum duration and minimum cost of the project are in turn refined and enhanced. Figure 8-9 shows a generic depiction of the relationship between the effort required for the task, hence the cost, and the duration of implementation of that task.
As a rule of thumb, if the duration of the element is halved, the total effort for the activity will double. In other words, there is always a cost penalty for reducing the elemental duration from what is considered to be the optimum. Reducing the duration of the element by 50 percent from its optimum is somewhat drastic. Normally, clients ask for a 10 percent or 20 percent reduction in duration, assuming that the original duration was optimum.
Figure 8-9
Cost-Duration Relationship
Ironically, sometimes it comes as a surprise to the project managers—and to the clients—that when the crew size for an activity is increased to speed the pace of progress, the increased pace is accompanied by a reduction in efficiency. This reduction in efficiency is due to hasty implementation, physical congestion, introduction of new unfamiliar team members to a task that is very time-sensitive, and dramatic increases in communication errors.
Once the number of team members is increased to speed up the project, the lines of communications increase dramatically, along with the probability of miscommunications, duplication of work, and implementation errors. In construction projects, increasing the number of workers will cause physical congestion, which will cause slowdowns and potential safety hazards. In software projects, the detrimental effects of a larger crew are subtler and less visible, but present nonetheless. Notwithstanding these considerations, if the client wishes the project duration to be compressed, that is how the project manager will proceed, although everyone needs to be aware of the fact that schedule compression will carry a cost penalty.
At the other end of the spectrum, if there are resource shortages or cash flow constraints, then the project must be implemented with a smaller size and less-than-optimum crew, in which case it will take longer to finish the project. This deviation from optimum also will increase the total effort of the project, although not to the extent compression would.
If the duration is doubled, the total cost and effort also will double. The reduction in efficiency, which is caused by an increase in duration, is due to penalties involved in more-than-normal start-stop sequences of the processes, reduced team interaction, and deterioration in organizational and individual memory regarding work details and learning curves.
To illustrate the concept of optimum duration, consider an activity that requires five programmers for six days to develop the code for a particular database. If the duration is forced to four days, nine programmers might be required to finish this project. To extend this illustration to an extreme, forcing the duration to three days would require 20 programmers for the same task (see Figure 8-10).
The literature contains extensive historical data regarding the cost penalty for compressing or expanding the schedule network for construction, industrial, and process projects. Therefore, the cost variances for changing project schedules in those industries can be computed reasonably accurately, based on industry-specific data and not necessarily based on generic rates of increase, as shown in Figures 8-9 and 8-10.
If the project is for software and system development and in the absence of satisfactory historical data, the generic ratios stated in these figures can be used as a good first approximation for this relationship. With detailed historical data, discipline-specific mathematical or graphic models can be developed for the optimum duration of the software and system development projects. These models would depict the lowest cost for a specific project conducted in a specific environment.
Some project managers, particularly in software and system development projects, anticipate and react to the possibility of network compression requests by embedding buffers in the original schedule logic. These embedded buffers are created during the planning stages by the inclusion of a lot of sequential activities, to be performed with an understaffed team and using very few parallel activities. Then, once the client makes the expected request for duration compression, the project manager announces that some of the serial activities can now be done in parallel. Such a change in plan accommodates the client’s wishes, using the proper number of personnel and at minimal additional cost.
Figure 8-10
Activity Compression (illustrative example)
This tactic, although proactive and often effective, can be highly explosive. If and when the client becomes aware that the original schedule (and the subsequent compression) was arbitrary, the project manager will lose all credibility and effectiveness in explaining future project variances to the client.
The best policy is to develop a pristine baseline for cost and schedule based on optimum crew size, cost, and duration. Then, as project circumstances such as resource skill, resource availability, and client business needs present themselves, the budget and schedule will be changed, and the client will be apprised accordingly. Notwithstanding, changing durations from optimum value will result in increasing effort and cost, whereas changing the logical relationships of a schedule will not necessarily result in decreasing effort or cost.
PROJECT LIFE-CYCLE COSTS
Enlightened clients tend to keep an eye toward the operational, maintenance, repair, and disposal costs of the project’s deliverable. Life-cycle cost analysis and value analysis are two techniques that are used to develop approximations of the total cost of the project. There is some overlap between the life-cycle cost analysis and value analysis.
The purpose of value analysis is to develop a product design strategy that will result in the lowest cost for that particular function or product. The value analysis process, also known as value engineering, will depend on a detailed understanding of the client’s needs and desires in terms of the functionality of the deliverable. Then, on the basis of the detailed definition of the desired functions of the product, the value analysis process will produce the specifications for the appropriate hardware or software. A value analysis process might recommend traditional components for the function, or develop a new design to reduce the cost while being responsive to the needs of the client.
Many organizations insist on a value analysis and a life-cycle cost analysis as part of the original cost-estimating phase. In the same fashion that the estimate and the planning data should be treated as living documents, the life-cycle cost analysis and value analysis should be updated frequently during the life of the project. At the very least, life-cycle cost analyses should be revised when the triple constraints go through significant changes or when more details about life-cycle cost issues become available.
The project management life-cycle cost analysis process will incorporate not only the cost of delivering the project, but also the cost of enhancing, maintaining, and ultimately decommissioning it. Operating, decommissioning, and disposal costs must be part of the owner’s considerations in cost evaluations during the planning and project selection phases. However, these issues are not always part of the design considerations for the contractor/vendor organizations, unless they are explicitly listed as objectives of the project at hand.
The advantage of using a life-cycle cost analysis is that it puts the overall cost of the deliverable into focus. Sometimes, a product that has the lowest delivery cost may not be the best choice if the overall life-cycle cost of that deliverable is higher than that of other products that are designed for the same set of objectives.
An example of a balance between implementation costs and life-cycle costs is whether to install a pump that is smaller and less expensive than the one originally envisioned. The motivation for this change might be that the smaller pump can be installed faster. However, this change must be made with the full recognition that the operating and repair cost of this pump will be much higher than the one originally designed. Therefore, for comparison purposes, not just the installation costs, but also the sum of the purchase cost and the lifetime operating cost for these two pumps, will need to be compared.
Finally, the project cannot be delivered early without making sacrifices in cost, quality, and scope. A balance is needed between the overall impact of the financial benefits of early delivery of the deliverable and the long-term penalties of a slightly impure deliverable.
An example of such balance in a software project is when the software will lack some of the desired features and may even include some unresolved errors just so that it can be delivered to the client sooner. This expediency might even involve additional costs for more detailed training for operational personnel, debugging the system, and maintaining the system. Accordingly, the cost comparison should be made between the sum of the developmental cost and the lifetime cost for debugging, training, and maintenance.
IMPACT OF PROJECT RISK
For every project, there are possible occurrences that might impact the scope, quality, cost, and schedule. A risk assessment must be conducted as part of the initial planning to determine the possible impact of these occurrences. Once the impact of these occurrences is determined, the project manager will be able to make a decision as to how to deal with such probabilities.
The basic form of risk management is to consider only those risk events that are totally out of the project team’s control, such as strikes, floods, tornadoes, and other acts of God. A modified view of risk management would include risks of undesirable occurrences from all sources. This expanded view of risk would include consideration of the impacts of and remedies for cost overrun, schedule delay, physical defects in the deliverable, and performance shortcomings of the deliverable. It is an important point that the latter sets of project attributes are, or should be, under the project team’s control.
In developing a risk management plan, the project manager must identify risks in ways that are consistent with corporate policy and with good project management practices. Even more importantly, the same risk identification structure should be used consistently in all projects.
Before and during the occurrence of the risk, the project manager may choose to accept the risk or put provisions in place for dealing with the occurrence of the risk. These provisions could include assigning project personnel to monitor and handle this issue on a contingency basis, or simply developing contingency funds for if and when the risk event materializes. The important issue here is that the project must have a proactive and comprehensive risk management plan in place to mitigate the impact of unexpected events.
One of the means of recognizing the financial impact of, and planning for, risk events is to determine a statistical monetary value for the risk and then somehow incorporate those risk-related expenses into the project estimate. Implementing this simple solution would begin with determining the probability and cost impact of occurrence for each risk event. The product of these two values would be the funds representing the statistical impact of that particular risk.
Once this calculation is conducted for all risk events, the total funds representing the statistical cost impact of all risk events can either be incorporated into the project budget or placed in a separate contingency fund specifically earmarked for dealing with results of risk events (see Figure 8-11). Alternately, depending on the funding structure of the project, risk-related funds might become either part of client reserve or part of project contingency funds.
Figure 8-11
Risk Contingency Funds (simple example)
