Cost is one of the three pillars supporting project success or failure, the other two being Time and performance. Projects that go significantly "over budget" are often terminated without achieving the construction project goals because stakeholders simply run out of money or perceive additional expenditures as "throwing good money after bad." Projects that stay within budget are the exception, not the rule. A construction project manager who can control costs while achieving performance and schedule goals should be viewed as somewhat of a hero, especially when we consider that cost, performance, and schedule are closely interrelated.
The level of effort and expertise needed to perform good cost management are seldom appreciated. Too often, there is the pressure to come up with estimates within too short a period of time. When this happens, there is not enough time to gather adequate historical data, select appropriate estimating methods, consider alternatives, or carefully apply proper methods. The result is estimates that lean heavily toward guesswork. The problem is exacerbated by the fact that estimates are often not viewed as estimates but more as actual measurements made by some time traveller from the future. Estimates, once stated, have a tendency to be considered facts. Project managers must remember that estimates are the best guesses by estimators under various forms of pressure and with personal biases. They must also be aware of how others perceive these estimates.
It requires an understanding of costs far beyond the concepts of money and numbers. Cost of itself can be only measured, not controlled. Costs are one-dimensional representations of three-dimensional objects travelling through a fourth dimension, time. The real-world things that cost represents are people, materials, equipment, facilities, transportation, etc. Cost is used to monitor performance or use of real things but it must be remembered that management of those real things determines cost, and not vice versa.
Cost management is the process of planning, estimating, coordination, control and reporting of all cost-related aspects from project initiation to operation and maintenance and ultimately disposal. It involves identifying all the costs associated with the investment, making informed choices about the options that will deliver best value for money and managing those costs throughout the life of the project, including disposal. Techniques such as value management help to improve value and reduce costs. Open book accounting, when shared across the whole project team, helps everyone to see the actual costs of the project.
The first three cost management processes are completed, with the exception of updates, during the project planning phase. The final process, controlling costs, is ongoing throughout the remainder of the project. Each of these processes is summarized below.
Cost management is begun by planning the resources that will be used to execute the project. Figure 6-2 shows the inputs, tools, and product of this process. All the tasks needed to achieve the project goals are identified by analyzing the deliverables described in the Work Breakdown Structure (WBS). The planners use this along with historical information from previous similar projects, available resources, and activity duration estimates to develop resource requirements. It is important to get experienced people involved with this activity, as noted by the "expert judgment" listed under Tools. They will know what works and what doesn't work.
In trying to match up resources with tasks and keep costs in line, the planners will need to look at alternatives in timing and choosing resources. They will need to refer back to project scope and organizational policies to ensure plans meet with these two guidelines.
Except for very small projects, trying to plan without good project management software is tedious and subject to errors, both in forgetting to cover all tasks and in resource and cost calculations.
The output of this process is a description of the resources needed, when they are needed, and for how long. This will include all types of resources, people, facilities, equipment, and materials. Once there is a resource plan, the process of estimating begins.
Estimating is the process of determining the expected costs of the project. It is a broad science with many branches and several popular, and sometimes disparate, methods. There are overall strategies to determining the cost of the overall project, as well as individual methods of estimating costs of specific types of activity. Several of these can be found in the resources listed at the end of the chapter. In most software development projects the majority of the cost pertains to staffing. In this case, knowledge of the pay rates (including overhead) of the people working on the project, and being able to accurately estimate the number of people needed and the time necessary to complete their work will produce a fairly accurate project cost estimate. Unfortunately, this is not as simple as it sounds. Most project estimates are derived by summing the estimates for individual project elements. Several general approaches to estimating costs for project elements are presented here.  Your choice of approach will depend on the time, resources, and historical project data available to you. The cost estimating process elements are shown in Figure.
Figure 6-3 Cost Estimating Elements
Cost estimating uses the resource requirements, resource cost rates, and the activity duration estimates to calculate cost estimates for each activity. Estimating publications, historical information, and risk information are used to help determine which strategies and methods would yield the most accurate estimates. A chart of accounts may be needed to assign costs to different accounting categories. A final, but very important, input to the estimating process is the WBS. Carefully comparing activity estimates to the activities listed in the WBS will serve as a reality check and discover tasks that may have been overlooked or forgotten.
The tools used to perform the actual estimating can be one or more of several types. The major estimating approaches shown in Figure 6-3 are discussed here. While other approaches are used, they can usually be classed as variations of these. One caution that applies to all estimating approaches: If the assumptions used in developing the estimates are not correct, any conclusions based on the assumptions will not be correct either.
Bottom-up estimating consists of examining each individual work package or activity and estimating its costs for labour, materials, facilities, equipment, etc. This method is usually time consuming and laborious but usually results in accurate estimates if well prepared, detailed input documents are used.
Analogous estimating, also known as top-down estimating, uses historical cost data from a similar project or activities to estimate the overall project cost. It is often used where information about the project is limited, especially in the early phases. Analogous estimating is less costly than other methods but it requires expert judgment and true similarity between the current and previous projects to obtain acceptable accuracy.
Parametric estimating uses mathematical models, rules of thumb, or Cost Estimating Relationships (CERs) to estimate project element costs. CERs are relationships between cost and measurements of work, such as the cost per line of code.  Parametric estimating is usually faster and easier to perform than bottom-up methods but it is only accurate if the correct model or CER is used in the appropriate manner.
Design-to-cost methods are based on cost unit goals as an input to the estimating process. Tradeoffs are made in performance and other systems design parameters to achieve lower overall system costs. A variation of this method is
cost-as-the-independent-variable, where the estimators start with a fixed system-level budget and work backwards, prioritizing and selecting requirements to bring the project scope within budget constraints.
Computer tools are used extensively to assist in cost estimation. These range from spreadsheets and project management software to specialized simulation and estimating tools. Computer tools reduce the incidence of calculation errors, speed up the estimation process, and allow consideration of multiple costing alternatives. One of the more widely used computer tools for estimating software development costs is the Constructive Cost Model (COCOMO). The software and user's manual are available for download without cost (see COCOMO in the Resources.) However, please note that most computer tools for developing estimates for software development use either lines of code or function points as input data. If the number of lines of code or function points cannot be accurately estimated, the output of the tools will not be accurate. The best use of tools is to derive ranges of estimates and gain understanding of the sensitivities of those ranges to changes in various input parameters.
The outputs of the estimating process include the project cost estimates, along with the details used to derive those estimates. The details usually define the tasks by references to the WBS. They also include a description of how the cost was derived, any assumptions made, and a range for estimate (e.g. $20,000 +/- $2000.) Another output of the estimating process is the Cost Management Plan. This plan describes how cost variances will be managed, and may be formal or informal. The following information may be considered for inclusion in the plan:
• Cost and cost-related data to be collected and analyzed.
• Frequency of data collection and analysis.
• Sources of cost-related data.
• Methods of analysis.
• Individuals and organizations involved in the process, along with their responsibilities and duties.
• Limits of acceptable variance between actual costs and the baseline.
• The authority and interaction of the cost control process with the change control process.
• Procedures and responsibilities for dealing with unacceptable cost variances.
Once the costs have been estimated for each WBS task, and all these put together for an overall project cost, a project budget or cost baseline must be constructed. The budget is a spending plan, detailing how and at what rate the project funding will be spent. The budgeting process elements are shown in Figure 6-4. All project activities are not performed at once, resources are finite, and funding will probably be spread out over time. Cost estimates, WBS tasks, resource availability, and expected funding must all be integrated with the project schedule in a plan to apply funds to resources and tasks. Budgeting is a balancing act to ensure the rate of spending closely parallels the resource availability and funding, while not exceeding either. At the same time, task performance schedules must be followed so that all tasks are funded and completed before or by the end of the project schedule.
The spending plan forms the cost baseline, which will be one of the primary measures of project health and performance. Deviations from this cost baseline are major warning signs requiring management intervention to bring the project back on track.
Various tools and techniques are available to assist in the budgeting process. Most of these are implemented in some form of computer software. Budgeting is usually a major part of project management software.
Cost control is the final step of the cost management process but it continues through the end of the project. It is a major element of project success and consists of efforts to track spending and ensure it stays within the limits of the cost baseline. The following activities make up the cost control process:
• Monitor project spending to ensure it stays within the baseline plan for spending rates and totals.
• When spending varies from the plan determine the cause of variance, remembering that the variance may be a result of incorrect assumptions made when the original cost estimate was developed.
• Change the execution of the project to bring the spending back in line within acceptable limits, or recognize that the original estimate was incorrect, and either obtain additional funding or reduce the scope of the project.
• Prevent unapproved changes to the project and cost baseline.
When it is not possible to maintain the current cost baseline, the cost control process expands to include these activities:
• Manage the process to change the baseline to allow for the new realities of the project (or incorrectly estimated original realities.)
• Accurately record authorized changes in the cost baseline.
• Inform stakeholders of changes.
The cost control process compares cost performance reports with the cost baseline to detect variances. Guidance on what constitutes unacceptable variance and how to deal with variance can be found in the cost management plan, developed during the estimation activities. Few projects are completed without changes being suggested or requested. All change requests should run the gauntlet of cost control to weigh their advantages against their impact to project costs.
Cost control tools include performance measurement techniques, a working cost change control system, and computer based tools. A powerful technique used with considerable success in projects is
Earned Value Management, if used appropriately. It requires a fully defined project up front and bottom-up cost estimates, but it can provide accurate and reliable indication of cost performance as early as 15% into the project.
The outputs of cost control include products which are ongoing throughout the life of the project: revised cost estimates, budget updates, corrective actions, and estimates of what the total project cost will be at completion. Corrective actions can involve anything that incurs cost, or even updating the cost baseline to realign with project realities or changes in scope. Cost data necessary to project closeout are also collected throughout the life of the project and summarized at the end. A final product, extremely important to future efforts, is a compilation of lessons learned during the execution of the project.
Tools for analyzing/evaluating Cost Management
Some construction insurance projects don't only exceed their budget because they turn out to be bigger than originally estimated. They often blow the budget because the estimates were badly managed. As a result, the profitability analyses are not well quantified because the estimates of future return were not accurate.
Accurate estimates turn to be really important, as they are frequently required for three principal reasons:
1. The first is to well-define the costs/budget of the project.
2. The second is to justify the project. It enables the cost to be compared with the anticipated benefits.
3. The third is to evaluate and control the actual costs vs. estimated and take corrective actions when needed to make the project succeed.
Applying Activity-Based Costing (ABC) to construction projects can help insurance companies to better understand their costs and maximize construction resources. Combined with the Earned Value Management, construction projects can be tracked and controlled effectively in terms of time and budget.
Activity-Based Costing (ABC)
Activity Based Costing (ABC) is a method for developing cost estimates in which the project is subdivided into discrete, quantifiable activities or a work unit. The activity must be definable where productivity can be measured in units (e.g., number of samples versus man hours). After the project is broken into its activities, a cost estimate is prepared for each activity. These individual cost estimates will contain all labour, materials, equipment, and subcontracting costs, including overhead, for each activity. Each complete individual estimate is added to the others to obtain an overall estimate. Contingency and escalation can be calculated for each activity or after all the activities have been summed. ABC is a powerful tool, but it is not appropriate for all cost estimates. This chapter outlines the ABC method and discusses applicable uses of ABC.
ABC methodology is used when a project can be divided into defined activities. These activities are at the lowest function level of a project at which costs are tracked and performance is evaluated. Depending on the project organization, the activity may coincide with an element of the work breakdown structure (WBS) or may combine one or more elements of the WBS. However, the activities must be defined so there is no overlap between them. After the activity is defined, the unit of work is established. All costs for the activity are estimated using the unit of work.
The estimates for the units of work can be done by performing detailed estimates, using cost estimating relationships, obtaining outside quotes for equipment, etc. All costs including overhead, profit, and markups should be included in the activity cost.
Earned Value Management (EVM)
An interesting phenomenon exists in the construction industry. The industry probably uses parts of Earned Value management about as well as any industry. But, what makes it interesting is that in construction work, practitioners rarely use the term "Earned Value."
The Earned Value Management (EVM) technique is a valuable tool to measure a project's progress, forecast its completion date and final cost, and provide schedule and budget variances along the way.
Earned Value management is a technique that can be applied, at least in part, to the management of all capital projects, in any industry, while employing any contracting approach. The employment of Earned Value requires a three-dimensional measurement of project performance, ideally from as early as possible—perhaps as early as 15 percent complete, up to 100 percent final completion. However, two of the three dimensions of Earned Value—the baseline plan and the physical performance measurement—will apply to all capital projects, in any industry, using any contracting method.
Using Earned Value metrics, any project can accurately monitor and measure the performance of projects against a firm baseline. Using the three dimensions of Earned Value, the project management teams can at all times monitor both the cost and the schedule performance status of their projects.
The Earned Value Management (EVM) technique is a valuable tool to measure a project's progress, forecast its completion date and final cost, and provide schedule and budget variances along the way. EVM provides consistent indicators to evaluate and compare projects and give an objective measurement of how much work has been accomplished. It lets the project manager combine schedule performance and cost performance to answer the question: "What did we get for the money we spent?"
Using EVM process, management can easily compare the planned amount of work with what has actually been completed, to determine if cost, schedule, and work accomplished are progressing as planned. It forces the project manager to plan, budget and schedule the work in a time-phased plan. The principles of ABC and EVM techniques provide innovative cost and performance measurement systems, allowing productivity improvements, and therefore can enhance the project's profitability and performance.
Quality Management (QM)
The process of planning, organizing, implementing, monitoring, and documenting a system of management practices that coordinate and direct relevant project resources and activities to achieve quality in an efficient, reliable, and consistent manner.
Quality Management Plan (QMP)
A project-specific, written plan prepared for certain projects which reflects the general methodology to be implemented by the Construction Manager during the course of the project to enhance the owner's control of quality through a process-oriented approach to the various management tasks for the program. The Quality Management Plan complements the Construction Management Plan (CMP) and forms a basis of understanding as to how the project team will interrelate in a manner that promotes quality in all aspects of the program, from the pre-design phase through completion of construction. Its purpose is to emphasize the quality goals of the project team in all issues associated with the work. This pertains not only to the traditional QA/QC of constructing elements of the work, but also addresses the quality needs of management tasks such as performing constructability reviews during design, checking estimates, making appropriate decisions, updating schedules, guiding the selection of subcontractors and vendors from a quality-oriented basis, to dealing with the public when applicable.
Owners, for certain projects, require that a separate Quality Management Plan be prepared by the Construction Manager. In these cases, the QMP is a project-specific plan which reflects the approach of the CM towards achieving quality in the constructed project. It is developed with heavy reliance on many of the sections included in these Guidelines, and fully supports the Construction Management Plan (CMP). When a separate QMP is prepared, most of the quality-oriented issues and discussion of processes, check lists, audits, etc., are contained in the QMP rather than the CMP. The CMP then addresses the day-to-day performance of the various functions and outlines the methods by which the Construction Manager's forces will perform their services.
The QMP typically will include some of the following:
• Overall project organization
• Project QA/QC organization
• QA/QC representatives of design team and contractors
• Management decision flow chart
• Formats for various elements of the CM services (i.e., formats for job meeting minutes, progress payment applications, field observation reports, shop drawing logs, notice of proposal change order, etc.)
• Detailed check lists or audit plans to provide for quality in the practice of CM functions (i.e., check lists for approving contractor's schedules, approving revisions to schedules, reviewing change order costs, obtaining approval within the owner organization for changes, approval to start foundation construction, approval to start concrete pour, approval to start steel erection, preliminary and final acceptance, etc.).
• Project Quality Audit forms
The CM will prepare quality management narratives for the use of his staff for each of the check lists and quality procedures contained in the QMP to provide for an acceptable level of quality at all levels of CM practice.
Inputs to Quality Planning.
Quality policy. Quality is "the overall intentions and direction of a construction organization with regard to quality, as formally expressed by top management". The quality policy of the performing organization can often be adopted "as is" for use by the project. However, if the performing organization lacks a formal quality policy, or if the project involves multiple performing organizations (as with a joint venture), then the project management team will need to develop a quality policy for the project. Regardless of the origin of the quality policy, the project management team is responsible for ensuring that the project clients are fully aware of it.
The scope statement is a key input to quality planning since it documents major project deliverables, as well as the project objectives that serve to define important client requirements.
Although objectives of the project description may be embodied in the scope statement, the project description will often contain details of technical issues and other concerns that may affect quality planning.
Standards and regulations.
The project management team must consider any application area-specific standards or regulations that may affect the project.
Other process outputs.
In addition to the scope statement and project description, processes in other knowledge areas may produce outputs that should be considered as part of quality planning. For example, procurement planning may identify contractor quality requirements that should be reflected in the overall quality management plan.
Tools and Techniques for Quality Planning.
The quality planning process must consider benefit/cost tradeoffs. The primary benefit of meeting quality requirements is less rework, which means higher quality, lower costs, and increased client satisfaction. The primary cost of meeting quality requirements is the expense associated with project management activities. It is axiomatic of the quality management discipline that the benefits outweigh the costs.
Benchmarking involves comparing actual or planned project practices to those of other projects to generate ideas for improvement and to provide a standard by which to measure performance. The other projects may be within the performing organization or outside of it, and may be within the same application area or in another.
A flow chart is any diagram that shows various elements of a system relate. Flowcharting techniques commonly used in quality management include:
A cause-and-effect diagram is an analysis tool that provides a systematic way of looking at effects and the causes that create or contribute to those effects. It was develop by Dr. Kaoru Ishikawa of Japan in 1943 and is sometimes referred to as an Ishikawa Diagram or a Fishbone Diagram because of its shape. Cause-and-effect diagrams, also called Ishikawa diagrams or fishbone diagrams, which illustrate how various factors might be linked to potential problems or effects.
A Cause-and-Effect Diagram is a tool that helps identify, sort, and display possible causes of a specific problem or quality characteristic. It graphically illustrates the relationship between a given outcome and all the factors that influence the outcome. A Cause-and-Effect Diagram is a tool that is useful for identifying and organizing the known or possible causes of quality, or the lack of it. The structure provided by the diagram helps team members think in a very systematic way.
At the head of the Fishbone is the defect or effect, stated in the form of a question.
The major bones are the capstones, or main groupings of causes.
The minor bones are detailed items under each capstone.
Applying cause-and-effect diagram
A cause-and-effect diagram is a tool that is useful for identifying and organizing the known or possible causes of quality, or the lack of it. The structure provided by the diagram helps team members think in a very systematic way. Some of the benefits of constructing a cause-and-effect diagram are that it:
helps determine the root causes of a problem or quality characteristic using a structured approach;
encourages group participation and utilizes group knowledge of the process;
uses an orderly, easy-to-read format to diagram cause-and-effect relationships;
indicates possible causes of variation in a process;
increases knowledge of the process by helping everyone to learn more about the factors at work and how they relate; and
identifies areas where data should be collected for further study.
System or process flow charts, which show how various elements of a system, interrelate.
Flow chart is used to provide a diagrammatic picture using a set of symbols. They are used to
show all the steps or stages in a process project or sequence of events. A flowchart assists in documenting and describing a process so that it can be examined and improved. Analyzing the data collected on a flowchart can help to uncover irregularities and potential problem points.
Flowcharts, or Process Maps, visually represent relationships among the activities and tasks that make up a process. They
are typically used at the beginning of a process improvement event; you describe process events, timing, and frequencies at the highest level and work downward. At high levels, process maps help you understand process complexity. At lower levels, they help you analyze and improve the process
A Pareto Chart is "a series of bars whose heights reflect the frequency or impact of problems. The bars are arranged in descending order of height from left to right. This means the categories represented by the tall bars on the left are relatively more significant than those on the right". The chart gets its name from the Pareto Principle, which postulates that 80 percent of the trouble comes from 20 percent of the problems.
It is a technique employed to prioritize the problems so that attention is initially focused on those, having the greatest effect. It was discovered by an Italian economist, named Vilfredo Pareto, who observed how the vast majority of wealth (80%) was owned by relatively few of the population (20%). As a generalized rule for considering solutions to problems, Pareto analysis aims to identify the critical 20% of causes and to solve them as a priority.
The use Pareto Charts
You can think of the benefits of using Pareto Charts in economic terms. A Pareto Chart:
breaks big problem into smaller pieces;
identifies most significant factors; and
helps us get the most improvement with the resources available by showing where to focus efforts in order to maximize achievements.
The Pareto Principle states that a small number of causes accounts for most of the problems. Focusing efforts on the "vital few" causes is usually a better use of valuable resources.
Applying Pareto Chart
A Pareto Chart is a good tool to use when the process you are investigating produces data that are broken down into categories and you can count the number of times each category occurs.
No matter where you are in your process improvement efforts, Pareto Charts can be helpful, ".early on to identify which problem should be studied, later to narrow down which causes of the problem to address first. Since they draw everyone's attention to the "vital few" important factors where the payback is likely to be greatest, (they) can be used to build consensus. In general, teams should focus their attention first on the biggest problems-those with the highest bars".
Making problem-solving decisions isn't the only use of the Pareto Principle. Since Pareto Charts convey information in a way that enables you to see clearly the choices that should be made, they can be used to set priorities for many practical applications in your command. Some examples are:
process improvement efforts for increased unit readiness;
skills you want your division to have;
To construct a Pareto Chart, you need to start with a meaningful data which you have collected and categorized. You may want to turn to the Data Collection module at this point to review the process of collecting and categorizing data that you can chart.
Construction of Pareto Chart
Construction of Pareto Chart is simple. There are five steps:
Determine the method of classifying data: by problem, cause, non-conformity, and so forth.
Decide if Money, frequency, or both are to be used to rank the characteristics.
Collect data for an appropriate time interval or use historical data.
Summarize the data and rank order categories from largest to smallest.
Construct the diagram and find vital few.
A scatter diagram shows the relationship between two variables (for example: speed and gas consumption, hours worked and production output). It provides an easy way to analyze data.
Applying a scatter diagram
We can use a scatter diagram when we want to:
examine how strong a relationship is between two variables (e.g., the relationship between advertising costs and sales, years of experience and employee performance, etc.);
confirm "hunches" about a direct cause-and-effect relationship between types of variables; and
determine the type of relationship (positive, negative, etc.).
Scatter diagrams are easy to use, and the results are easy to understand. This tool can be adapted for use in many types of situations.
Constructing a scatter diagram
The scatter diagram consists of four major steps:
Draw the horizontal and vertical axes
Plot the data on the diagram
Interpret the scatter diagram
A control chart is a statistical tool used to distinguish between variation in a process resulting from common causes and variation resulting from special causes. It presents a graphic display of process stability over time.
Trend analysis: the process of using mathematical techniques to predict future outcomes based on past results is performed using run charts. It is often used to monitor:
Technical performance: How many mistakes or defects have been uncovered and how many remain undetected?
Cost and schedule performance: How many activities per period were done with significant variances?
Applying a control chart
A stable process is one that is consistent over time with respect to the center and the spread of the data. Control charts help you monitor the behaviour of your process to determine whether it is stable. Like run charts, they display data in the time sequence in which they occurred. However, control charts are more efficient than run charts in assessing and achieving process stability.
monitor process variation over time;
differentiate between special cause and common cause variation;
assess the effectiveness of changes to improve a process; and
communicate how a process performed during a specific period.
Developing a control chart
Developing a control chart consists of four major steps:
Step 1: Determine what to measure
Step 2: Collect the data
Step 3: Plot the data
Step 4: Calculate the control limits
Creating a control chart consists of four major steps:
Step 1: Determine what to measure
Step 2: Collect the data
Step 3: Plot the data
Step 4: Calculate the control limits
A histogram is a basic graphing tool that displays the relative frequency or occurrence of continuous data values showing which values occur most and least frequently. It illustrates the shape, centering, and spread of data distribution and indicates whether there are any outliers.
Applying a histogram
When you are unsure what to do with a large set of measurements presented in a table, you can use a histogram to organize and display the data in a more user-friendly format. A histogram will make it easy to see where the majority of values fall in a measurement scale, and how much variation there is. It is helpful to construct a histogram when you want to do the following:
Summarize large data sets graphically. We can make it much easier to understand by summarizing data on a tally sheet and organizing it into a histogram.
Compare process results with specification limits.If we add the process specification limits to the histogram, we can determine quickly whether the current process was able to produce "good" products. Specification limits may take the form of length, weight, density, quantity of materials to be delivered, or whatever is important to produce the required results of a given process.
Communicate information graphically.We can easily see the values which occur most frequently. When you use a histogram to summarize large data sets, or to compare measurements to specification limits, you are employing a powerful tool for communicating information.
Use a tool to assist in decision-making.As we move along, you will see that the shapes, sizes, and the spread of data have meanings that can help us in investigating problems and making decisions. However, always bear in mind that if the data we have in hand are not the
most recent, or we do not know the manner how the data were collected, it is a waste of time trying to chart them. Measurements cannot be used for making decisions or predictions when they were produced by a process that is different from the current one, or were collected under unknown conditions.
Parts of a histogram
A histogram is made up of five (5) parts:
Title:The title briefly describes the information that is contained in the histogram.
Horizontal or X-axis:The horizontal or X-axis shows the scale of values into which the measurements fit. These measurements are generally grouped into intervals to help you summarize large data sets. Individual data points are not displayed.
Bars:The bars have two important characteristics -- height and width. The height represents the number of times the values within an interval occurred. The width represents the length of the interval covered by the bar. It is the same for all bars.
Vertical or Y-axis:The vertical or Y-axis is the scale that shows the number of times the values within an interval occurred. The number of times is also referred to as "frequency."
Legend:The legend provides additional information that documents where the data came from and how the measurements were gathered.
A clear, easy to use form used in the collection of data, and in the observation of how often certain events happen. A check sheet can be constructed in whatever shape, size and format, as appropriate for the data collection task at hand because check sheets are used in collecting and recording data unique to a specific process.
Applying check sheet
We should use a check sheet as a data gathering and interpretation tool when you want to:
distinguish between opinion and fact;
gather data about how often a problem is occurring; and
gather data about the type of problem occurring.
Types of check sheets
No matter which type you are using, make sure that it is clear, complete, and user-friendly. The three (3) types of check sheets are described below:
tally sheet" is easy for you and your team to use when you simply want to count how often something happens or to record a measurement. Depending on the type of data required, the data collector simply makes a checkmark in a column to indicate the presence of a characteristic, or records a measurement, such as temperature in degrees centigrade, weight in pounds, diameter in inches, or time in seconds.
Location Format. A location check sheet allows you to mark a diagram showing the exact physical location of a defect or characteristic. An insurance adjuster's pictorial claim form detailing your latest bumper bruise is an example of a location check sheet.
Graphic Format. Another way of collecting data is by using a graphic form of check sheet. It is specifically designed so that the data can be recorded and displayed at the same time. Using this check sheet format, you can record raw data by plotting them directly onto a graph-like chart.
Flowcharting can help the project team anticipate what and where quality problems might occur, and thus can help develop approaches for dealing with them.
Design of experiments
Design of experiments is a statistical method that helps identify which factors might influence specific variables. The technique is applied most frequently to the product of the project (e.g., automotive designers might wish to determine which combination of suspension and tires will produce the most desirable ride characteristics at a reasonable cost).
However, it can also be applied to project management issues, such as cost and schedule tradeoffs. For example, senior engineers will cost more than junior engineers, but can also be expected to complete the assigned work in less time. An appropriately designed "experiment" (in this case, computing project costs and durations for various combinations of senior and junior engineers) will often allow determination of an optimal solution from a relatively limited number of cases.
Cost of quality.
Cost of quality refers to the total cost of all efforts to achieve product/service quality, and includes all work to ensure conformance to requirements, as well as all work resulting from non-conformance to requirements. There are three types of costs that are incurred: prevention costs, appraisal costs, and failure costs, where the latter is broken down into internal and external costs.
Outputs from Quality Planning
Quality management plan
The quality management plan should describe how the project management team will implement its quality policy. In ISO 9000 terminology, it should describe the project quality system: "the organizational structure, responsibilities, procedures, processes, and resources needed to implement quality management".
The quality management plan provides input to the overall project plan, and must address quality control, quality assurance, and quality improvement for the project.
The quality management plan may be formal or informal, highly detailed, or broadly framed, based on the requirements of the project.
An operational definition describes, in very specific terms what something is and how it is measured by the quality control process. For example, it is not enough to say that meeting the planned schedule dates is a measure of management quality; the project management team must also indicate whether every activity must start on time or only finish on time; whether individual activates will be measured, or only certain deliverables, and if so, which ones. Operational definitions are also called metrics in some application areas.
A checklist is a structured tool, usually item specific, used to verify that a set of required steps has been performed. Checklists may be simple or complex. They are usually phrased as imperatives ("Do this!") or interrogatories ("Have you done this?"). Many organizations have standardized checklists available to ensure consistency in frequently performed tasks. In some application areas, checklists are also available from professional associations or commercial services providers.
Quality metrics describe the specific attributes of the project work that will be measured to determine whether the work meets quality standards. Quality metrics are used in the Perform Quality Assurance and the Perform Quality Control processes.
Project managers use quality metrics information on cost, rework, and cycle time to improve the quality of the project deliverables and work processes. Examples of quality metrics include defect density, failure rate, availability, reliability, and test coverage.
By using proven quality processes when planning and carrying out a project, project managers can ensure that both the project and its deliverables achieve the desired quality standards.
Project Time Management includes the processes required to accomplish timely completion of the project. The Project Time Management processes include the following:
The Activity Definition process will identify the deliverables at the lowest level in the work breakdown structure (WBS), which is called the work package. Project work packages are planned (decomposed) into smaller components called schedule activities to provide a basis for estimating, scheduling, executing, and monitoring and controlling the project work. Implicit in this process is defining and planning the schedule activities such that the project objectives will be met.
Activity sequencing involves identifying and documenting the logical relationships among schedule activities. Schedule activities can be logically sequenced with proper precedence relationships, as well as leads and lags to support later development of a realistic and achievable project schedule.
Activity Resource Estimating
Estimating schedule activity resources involves determining what resources (persons, equipment, or materiel) and what quantities of each resource will be used, and when each resource will be available to perform project activities.
Activity Duration Estimating
The Activity Duration Estimating process requires that the amount of work effort required to complete the schedule activity is estimated, the assumed amount of resources to be applied to complete the schedule activity is estimated, and the number of work periods needed to complete the schedule activity is determined. All data and assumptions that support duration estimating are documented for each activity duration estimate.
Project schedule development, an iterative process, determines planned start and finish dates for project activities. Schedule development can require that duration estimates and resource estimates are reviewed and revised to create an approved project schedule that can serve as a baseline against which progress can be tracked.
Schedule control is concerned with Determining the current status of the project schedule, influencing the factors that create schedule changes, determining that the project schedule has changed, managing the actual changes as they occur.
TOOLS AND TECHNIQUES
The technique of decomposition, as it is applied to activity definition, involves subdividing the project work packages into smaller, more manageable components called schedule activities. The Activity Definition process defines the final outputs as schedule activities rather than as deliverables.
Project team members or other experts who are experienced and skilled in developing detailed project scope statements, WBSs, and project schedules can provide expertise in defining activities.
Rolling Wave Planning
The WBS and WBS dictionary reflect the project scope evolution as it becomes more detailed until the work package level is reached. Rolling wave planning is a form of progressive elaboration planning where the work to be accomplished in the near term is planned in detail at a low level of the WBS, while work far in the future is planned for WBS components that are at a relatively high level of the WBS. The work to be performed within another one or two reporting periods in the near future is planned in detail as work is being completed during the current period. Therefore, schedule activities can exist at various levels of detail in the project's life cycle. During early strategic planning, when information is less defined, activities might be kept at the milestone level.
A standard activity list or a portion of an activity list from a previous project is often usable as a template for a new project. The related activity attributes information in the templates can also contain a list of resource skills and their required hours of effort, identification of risks, expected deliverables, and other descriptive information. Templates can also be used to identify typical schedule milestones.
When insufficient definition of the project scope is available to decompose a branch of the WBS down to the work package level, the last component in that branch of the WBS can be used to develop a high-level project schedule for that component. These planning components are selected and used by the project team to plan and schedule future work at various higher levels within the WBS. The schedule activities used for these planning components may be summary activities that are not enough to support detailed estimating, scheduling, executing, monitoring, or controlling of the project work.
Precedence Diagramming Method (PDM)
PDM is a method of constructing a project schedule network diagram that uses boxes or rectangles, referred to as nodes, to represent activities and connects them with arrows that show the dependencies. This technique is also called activity on-node (AON), and is the method used by most project management software packages.
PDM includes four types of dependencies or precedence relationships:
Finish-to-Start. The initiation of the successor activity depends upon the completion of the predecessor activity.
Finish-to-Finish. The completion of the successor activity depends upon the completion of the predecessor activity.
Start-to-Start. The initiation of the successor activity depends upon the initiation of the predecessor activity.
Start-to-Finish. The completion of the successor activity depends upon the initiation of the predecessor activity.
Arrow Diagramming Method (ADM)
ADM is a method of constructing a project schedule network diagram that uses arrows to represent activities and connects them at nodes to show their dependencies. This technique is also called activity-on-arrow (AOA) and, although less prevalent than PDM, it is still used in teaching schedule network theory and in some application areas.
ADM uses only finish-to-start dependencies and can require the use of "dummy" relationships called dummy activities, which are shown as dashed lines, to define all logical relationships correctly. Since dummy activities are not actual schedule activities (they have no work content), they are given zero value duration for schedule network analysis purposes.
Three types of dependencies are used to define the sequence among the activities.
Mandatory dependencies. The project management team determines which dependencies are mandatory during the process of establishing the sequence of activities. Mandatory dependencies are those that are inherent in the nature of the work being done. Mandatory dependencies often involve physical limitations, such as on a construction project, where it is impossible to erect the superstructure until after the foundation has been built, or on an electronics project, where a prototype must be built before it can be tested. Mandatory dependencies are also sometimes referred to as hard logic.
Discretionary dependencies. The project management team determines which dependencies are discretionary during the process of establishing the sequence of activities. Discretionary dependencies are fully documented since they can create arbitrary total float values and can limit later scheduling options. Discretionary dependencies are sometimes referred to as preferred logic, preferential logic or soft logic. Discretionary dependencies are usually established based on knowledge of best practices within a particular application area or some unusual aspect of the project where a specific sequence is desired, even though there are other acceptable sequences. Some discretionary dependencies include preferred schedule activity sequences based upon previous experience on a successful project performing the same type of work.
External dependencies. The project management team identifies external dependencies during the process of establishing the sequence of activities. External dependencies are those that involve a relationship between project activities and non-project activities. For example, the testing schedule activity in a software project can be dependent on delivery of hardware from an external source, or governmental environmental hearings may need to be held before site preparation can begin on a construction project.
Schedule Network Templates
Standardized project schedule network diagram templates can be used to expedite the preparation of networks of project schedule activities. They can include an entire project or only a portion of it. Portions of a project schedule network diagram are often referred to as a subnetwork or a fragment network. Subnetwork templates are especially useful when a project includes several identical or nearly identical deliverables.
Applying Leads and Lags
The project management team determines the dependencies that may require a lead or a lag to accurately define the logical relationship. The use of leads and lags and their related assumptions are documented.
A lead allows an acceleration of the successor activity. For example, a technical writing team can begin writing the second draft of a large document (the successor activity) fifteen days before they finish writing the entire first draft (the predecessor activity). This could be accomplished by a finish-to-start relationship with a fifteen-day lead time.
A lag directs a delay in the successor activity. For example, to account for a ten-day curing period for concrete, a ten-day lag on a finish-to-start relationship could be used, which means the successor activity cannot start until ten days after the predecessor is completed.
ACTIVITY RESOURCE ESTIMATING
Project Management Software
Project management software has the capability to help plan, organize, and manage resource pools and develop resource estimates. Depending upon the sophistication of the software, resource breakdown structures, resource availabilities, and resource rates can be defined, as well as various resource calendars.
Expert judgment is often required to assess the resource-related inputs to this process. Any group or person with specialized knowledge in resource planning and estimating can provide such expertise.
Many schedule activities have alternative methods of accomplishment. They include using various levels of resource capability or skills, different size or type of machines, different tools (hand versus automated), and make-or-buy decisions regarding the resource
Published Estimating Data
Several companies routinely publish updated production rates and unit costs of resources for an extensive array of labour trades, materiel, and equipment for different countries and geographical locations within countries.
When a schedule activity cannot be estimated with a reasonable degree of confidence, the work within the schedule activity is decomposed into more detail. The resource needs of each lower, more detailed piece of work are estimated, and these estimates are then aggregated into a total quantity for each of the schedule activity's resources. Schedule activities may or may not have dependencies between them that can affect the application and use of resources. If there are dependencies, this pattern of resource usage is reflected in the estimated requirements of the schedule activity and is documented.
ACTIVITY DURATION ESTIMATING
The accuracy of the activity duration estimate can be improved by considering the amount of risk in the original estimate. Three-point estimates are based on determining three types of estimates:
Most likely: The duration of the schedule activity, given the resources likely to be assigned, their productivity, realistic expectations of availability for the schedule activity, dependencies on other participants, and interruptions.
Optimistic: The activity duration is based on a best-case scenario of what is described in the most likely estimate.
Pessimistic: The activity duration is based on a worst-case scenario of what is described in the most likely estimate.
Task Duration = (O + 4M + P) / 6
Standard Deviation = (P - O) /6
Activity durations are often difficult to estimate because of the number of factors that can influence them, such as resource levels or resource productivity. Expert judgment, guided by historical information, can be used whenever possible. The individual project team members may also provide duration estimate information or recommended maximum activity durations from prior similar projects. If such expertise is not available, the duration estimates are more uncertain and risky.
Analogous duration estimating means using the actual duration of a previous, similar schedule activity as the basis for estimating the duration of a future schedule activity. It is frequently used to estimate project duration when there is a limited amount of detailed information about the project for example, in the early phases of a project. Analogous estimating uses historical information and expert judgment.
Estimating the basis for activity durations can be quantitatively determined by multiplying the quantity of work to be performed by the productivity rate. The total resource quantities are multiplied by the labour hours per work period or the production capability per work period, and divided by the number of those resources being applied to determine activity duration in work periods.
Reserve Analysis Project teams can choose to incorporate additional time referred to as contingency reserves, time reserves or buffers, into the overall project schedule as recognition of schedule risk. The contingency reserve can be a percentage of the estimated activity duration, a fixed number of work periods, or developed by quantitative schedule risk analysis. Contingency reserve can be used completely or partially, or can later be reduced or eliminated, as more precise information about the project becomes available.
What-If Scenario Analysis
This is an analysis of the question "What if the situation represented by scenario 'X' happens?" A schedule network analysis is performed using the schedule model to compute the different scenarios, such as delaying a major component delivery, extending specific engineering durations, or introducing external factors.
Critical Path Method
The critical path methods calculates the theoretical early start and finish dates and late start and finish dates, for all schedule activities without regard for any resource limitations, by performing a forward pass analysis and a backward pass analysis through the project schedule network paths. The resulting early and late start and finish dates are not necessarily the project schedule; rather, they indicate the time periods within which the schedule activity should be scheduled, given activity durations, logical relationships, leads, lags, and other known constraints.
Free Float: The amount of time that a schedule activity can be delayed without delaying the early start of any immediately following schedule activities.
Total Float : The total amount of time that a schedule activity may be delayed from its early start date without delaying the project finish date, calculated by LS-ES or LF - EF
Critical paths have a zero or negative total float
Schedule compression shortens the project schedule without changing the project scope, to meet schedule constraints, imposed dates, or other schedule objectives. Schedule compression techniques include:
Crashing. Schedule compression technique in which cost and schedule tradeoffs are analyzed to determine how to obtain the greatest amount of compression for the least incremental cost. Crashing does not always produce a viable alternative and can result in increased cost.
Fast tracking. A schedule compression technique in which phases or activities that normally would be done in sequence are performed in parallel.
Resource levelling is a schedule network analysis technique applied to a schedule model that has already been analyzed by the critical path method. Resource levelling is used to address schedule activities that need to be performed to meet specified delivery dates, to address the situation where shared or critical required resources are only available at certain times or are only available in limited quantities, or to keep selected resource usage at a constant level during specific time periods of the project work. This resource usage levelling approach can cause the original critical path to change. Critical Chain Method Critical chain is another schedule network analysis technique that modifies the project schedule to account for limited resources. The critical chain method adds duration buffers that are non-work schedule activities to maintain focus on the planned activity durations. Once the buffer schedule activities are determined, the planned activities are scheduled to their latest possible planned start and finish dates.
Project Management Software
Adjusting Leads and Lags
Schedule Comparison Bar Charts
To facilitate analysis of schedule progress, it is convenient to use a comparison bar chart, which displays two bars for each schedule activity. One bar shows the current actual status and the other shows the status of the approved project schedule baseline. This shows graphically where the schedule has progressed as planned or where slippage has occurred.
The progress reporting and current schedule status includes information such as actual start and finish dates, and the remaining durations for unfinished schedule activities.
Schedule Change Control System
The schedule change control system defines the procedures by which the project schedule can be changed. It includes the paperwork, tracking systems, and approval levels necessary for authorizing changes.
Performance measurement techniques produce the Schedule Variance (SV) and Schedule Performance Index (SPI) which are used to assess the magnitude of any project schedule variations that do occur. An important part of schedule control is to decide if the schedule variation requires corrective action.
Project Management Software Project management software for scheduling provides the ability to track planned dates versus actual dates, and to forecast the effects of project schedule changes, real or potential.
9.0 Schedule Status
Schedules will be updated on a periodic basis to measure performance and to provide management pertinent information. This involves ascertaining the amount of progress for all inprogress activities and determining whether or not an activity or milestone has been started and/or completed. The actual status is recorded and graphically depicted on appropriate schedules. Schedules used for performance measurement and reporting are updated on a monthly basis, concurrent with cost accumulation and reporting.
Current schedule progress will be analyzed in relation to the baseline schedule. This is accomplished by setting the baseline schedule as the target in the current schedule. The Total Float Variance is determined by measuring the Early Start/Finish of the Target Schedule against the Early Start/Finish of the Current Schedule. This comparison will be implemented in all project phases throughout the project's life.
Total float for those activities which affect milestone dates or cross control accounts will be controlled by the Project Manager; otherwise it will be managed by the responsible organization.
Schedule status is reported in Project Team meetings on a weekly basis utilizing the Working Level Schedule (Level IV). While Project Review Meetings report schedule status monthly utilizing the Project Summary Schedule (Level II). For project's supporting daily meetings (i.e.Operations Plan of the Day – POD), the working level schedule is the document utilized and manually updated. However, the scheduling database is routinely progressed and published on a weekly basis.
A. Updating Terms and Definitions
1) Data date -The date used as the starting point for schedule calculations. Change the data date to the reporting date when you record progress.
2) Actual dates-The dates you record for an activity that identifies when it actually started and finished. Actual start and finish dates should be recorded for all activities that have been started and/or completed by the data date before you calculate a schedule. Actual dates replace early and late dates in all reports.
3) Early dates - The earliest dates an activity can begin after its predecessors have completed, and can finish based on the completion of its predecessors in a conventional relationship. For a newly added activity, the early dates appear only when the schedule is calculated. To impose an early start or finish date, assign an early start or early finish constraint to the activity.
4) Percent complete - The proportion of an activity that has been completed.
5) Remaining duration - The number of work periods required to complete an activity. Duration is measured in the project's planning unit, such as months, weeks, days, hours.
B. Updating Steps
There are 3 types of activities to be reviewed for updating; they are Completed Activities, In-Progress Activities, and Not Started Activities.
1) Determine the Data Date and the set the data date to the new reporting periods (as
of report date)
2) Status Completed activities
a) Set the actual finish date, percent complete of 100% and the remaining duration to zero
b) Status the next activity in the chain (if the activity has started)
3) Status In-progress activities
a) Set the actual start date
b) Status the percent complete and remaining duration. The Percent Complete and the Remaining Duration are not linked (See Autocost Rule section). Both must be updated appropriately.
c) If the activity was due to complete before the current reporting period – assess the impact by evaluating the total float.
During the updating process, Project Controls will be in constant communication with the appropriate individuals to validate and inform them of any early indication of schedule impacts or potential problems. Early resolutions are incorporated into the schedule immediately, if appropriate, with verbal authorization from the responsible person(s).
10.0 Schedule Analysis
The Critical Path Method (CPM) analysis technique is used to determine the criticality of an activity or milestone based upon the amount of time that activity/milestone can slip without impacting the project completion. The number of working days which an activity can slip without impacting the project completion is total float. The Project Controls group is responsible for performing this analysis with input provided by the Control Account Manager (CAM).
The Baseline schedule reflects all authorized scope and schedule changes. The Current Schedule reflects the baseline plus actual progress to-date and forecast progress from that date forward. A comparison between the Current Schedule and the Baseline Schedule, a review of the resultant changes in total float for each activity will indicate the criticality of the activity/sequence of activities in the timely completion of the milestone to which they are related. Late activities with a total float of twenty working days or less should be placed on a Critical Items List. It is important to remember that schedule analysis should be performed in conjunction with schedule performance measurement analysis. Only through schedule analysis (CPM analysis) can one determine if work is progressing on the critical path. In other words, the SV, SV% and SPI may indicate a positive schedule performance, while the CPM analysis may indicate that work was not performed on the critical path activities indicating negative float. The positive schedule performance occurs when activities are completed ahead of schedule while the critical path activities are not worked. This can lead the project into a false-sense of security.
The review and approval process follows after the analytical process has been completed. More than one alternative work around plan (different logic scenarios) and associated schedule impact may be identified, as impacts to the next higher schedule level are identified. This could require higher level management involvement. Any impacts as a result of the CPM analysis will be reported on the Critical Items List Report and addressed in the Project Review Meeting for resolution. In addition, after the Project Controls Lead's evaluation he may recommend to the Project Manager (PM) to issue an Early Warning, if he deems necessary.
A. Analysis Techniques
1) Compare Project Completion date – the current schedule early finish date to the baseline early finish date.
2) Focus on critical path activities – for complex projects the first 3 critical paths should be analyzed and evaluated.
3) Gather relevant data:
a) Detailed activity data – validate the current activities and activity sequencing reflects the intended steps for the responsible group to meet their commitment.
b) Network logic – validate that the internal and external requirements portrayed by the logic ties are still the current strategy for completing the task(s).
c) Resource availability – validate that the resource requirements are available to support the completion of the tasks as scheduled.
B. Critical Items List Report (CAIR)
The Critical Items List is used to focus project team and management attention on problem activities that may have significant impact on the project schedule. It should be the subject of the Project Team Meetings to discuss corrective actions or alternatives to eliminate or alleviate the schedule impact.
Only critical activities that are affecting the schedule or have the potential to do so should appear on the list. Two categories of activities will be reflected, critical activities and potential critical activities.
Those late activities with a total float of ten working days or less which may directly or indirectly impact a project milestone should be categorized as a critical activity. Those late activities with a total float of eleven to twenty working days should be categorized as a potential critical activity.
Unless the trend of schedule slippage is reversed, a potential critical activity may become critical.
11.0 Schedule Revisions and Changes
Revisions to the schedule emanate from three sources:
When progress reflects a schedule slip which may potentially impact project completion, appropriate analysis is required to develop an acceptable recovery plan.
Revisions necessitated by the limitation of planning insight into the future. This usually involves assimilation of more details into the lower level schedules and may involve logic and duration changes to reflect a current work plan.
Revisions resulting from customer or project management redirection or change.
12.0 Methods of shortening the schedule
Focus on critical activities
Add resources to reduce durations
Use relationships to overlap activities
Break down long activities
Change calendar assignments
Put critical activities on a longer workweek
Add exceptions to non-worktime
13.0 Duration Compression
Duration compressions uses ways to shorten the project schedule without changing the project scope (e.g., to meet imposed dates or other schedule objectives). The techniques for using duration compression are: Crashing and Fast Tracking.
Technique 1 – Crashing or Crunching (Duration Reduction) In which cost and schedule tradeoffs are analyzed to determine how, if at all, to obtain the greatest amount of compression for the least incremental cost. Crashing does not always produce a viable alternative and often results in increased costs.
Technique 2 – Fast TrackingDoing activities in parallel that would normally be done in sequence (e.g., starting to write code on a software project before the design is complete, or starting to build the foundation for a petroleum processing plant before the 25 percent engineering point is reached). Fast tracking often results in rework and usually increases risk.
14.0 Trending and Change Control
The schedule baseline is approved through the change control process, which sets schedule dates for major tasks and commitments. The Project Milestone Schedule is attached to the original BCP; which sets the cost and schedule baseline.
A. Project performance is measured against the schedule baseline.
B. Corrective action plans are developed to ensure project commitments are met.
C. Approved change control is utilized authorizing schedule baseline changes.
The schedule baseline should be evaluated periodically to ensure that current project strategies, current project internal and external commitments are incorporated.
The Project Manager executes the change control process as is written in the Project Execution Plan. The Project Manager determines which level of the change control process is appropriated by reviewing and evaluating each project change. The Trend Process is administered and coincides in the total process.
15.0 Resource Scheduling and Leveling
A. Resource Loading
Resources are people (manhours/FTEs), equipment, costs, space, material bulks, etc. It is recommended that direct hours, subcontract hours and equipment costs be utilized for resource loading. The manhours/mandays are further subdivided by the resource types; Design Engineering, Quality Assurance, Project Controls, Project Management, Construction Crafts (Boilermakers, Pipefitters, Carpenters, etc), Engineering, Operations, etc. Project Controls works closely with the Estimator during the process of developing an estimate. Once the schedule is resource leveled and approved by the Project Team, Project Controls provides the manhours by resource type and by month/year to the Estimator. The Estimator computes the Direct Labor and Subcontract dollars, along with the indirect costs for Outyear Wage Adjustments, ESS and G&A dollars.
B. Resource Scheduling
Good resource scheduling is the basis for maximizing the productivity of people and equipment while minimizing their cost. It defines which resources should be utilized on specific tasks, between which dates.
1) Resource definition
2) The advantages of Resource Scheduling are:
a) Analytically manage and use schedule float
b) Analyze staffing requirements
c) Evaluate effects of limited staffing
d) Avoid wide fluctuations in daily need for various resources (leveling)
C. Resource Leveling
Scheduling without resource consideration often produces preliminary early-start schedule that requires more resources during certain time periods than are available, or requires changes in resource levels that are not manageable.
Resource leveling often results in a project duration that is longer than the preliminary schedule. This technique is sometimes called the resource-based method, especially when implemented with computerized optimization.
a) Optimizes resource use
b) Helps maximize utilization of resources
c) Produces realistic start/finish dates
d) Avoids peaks and valleys in staff
2) Resource Over-Allocation
Resource Over-Allocation occurs when activities/tasks are competing for the same resource at the same time. There are several means which can be used together or independently to eliminate and/or reduce the over-allocation of a resource. Resource reallocation from non- critical to critical activities is a common way to bring the schedule back, or as close as possible, to its originally intended overall duration. Other methods should also be considered in order to reduce duration of critical activities, such as; the utilization of extended hours, weekends, or multiple shifts and the Use of different technologies and/or machinery (i.e., automatic welding, electrical pipe cutters, etc.) are other methods used to shorten durations that have extended the preliminary schedule. Incorporation of the later method, will increase productivity and have a compounded improvement of the activity's duration.
a) The steps to resolve over-allocation are:
(1) Increase the resource's workweek
(2) Increase the resource's workday.
(3) Increase the resource amount by assigning additional resources to the activity.
(a) Switch or replace the over allocated resource with an available resource.
3) Resource Scheduling Techniques
a) Fast Tracking, if feasible is another way to reduce the overall project duration.
b) Some project may have a finite and critical project resource, requiring that the resource be scheduled in reverse from the project ending date; this is known as reverse resource allocation scheduling - Backward Resource Leveling.
c) Critical chain is a technique that modifies the project schedule to account for limited resources.
4) Resource Smoothing Techniques
The automatic approach to resource leveling is accomplished by scheduling each activity when all resource requirements can be met for the entire, continuous duration of the activity. If this condition cannot be met, the entire activity is delayed until the condition can be met. The splitting, stretching or crunching technique can be specified as a leveling technique.
The nature of some activities dictates that the work, once it begins, must continue every working day until it completes. Work on other activities, however, can occur during any work-periods when sufficient resources are available, even if the workperiods are not contiguous on the activity or resource calendar.
This technique schedules a task to begin when the required resources are available, suspends work if the resource supply becomes too low, and resumes work when sufficient resources are available again.
b) Resource Stretching
Natures of some activities require a constant supply of resources for their entire duration. Others tolerate a reduced supply, allowing them to continue working through periods of low resource availability.
This technique, stretching, increases the duration of the activity by increasing the duration of the resources.
Some activities cannot speed the completion by increasing their resource supply; these activities are not crunchable.
Crunchable activities can complete in less time if the resource supply is increased. The duration of a crunchable activity is decreased by taking advantage of additional available resources.
16.0 Schedule Risk Assessment and Contingency
"The application of contingency shall be considered in all scope, schedule, and cost baselines as being both prudent and necessary. Contingency is most often derived through a risk analysis of scope, cost, schedule, and technical, risks, underscoring the uncertainties existing in each element".
A. Risk Management
Uncertainty and risk are intrinsic aspects of every project. These risks are often dealt with by allocating extra resources – time, labor, materials, and/or funds – to cover performance uncertainty. This type of contingency planning is adequate for some activities; however, it usually ignores important information.
As a rule your confidence level increases when you carefully examine the range of possibilities from "pessimistic" to "optimistic".
Simulation involves calculating multiple project durations with different sets of activity assumptions. The most common technique is Monte Carlo Analysis, in which a distribution of probable results is defined for each activity and used to calculate a distribution of probable results for the total project. In addition, what-if analyses can be made using the logic network to simulate different scenarios. The outcome of the what-if simulations can be used to asses the feasibility of the schedule under adverse conditions, and in preparing contingency/response plans to overcome or mitigate the impact of unexpected situations.
1) Schedule Risk Analysis is a structured process of identifying and quantifying potential/possible impacts to a schedule and combining that information to determine the probability of schedule success.
2) Schedule Contingency is a duration of time-based on the schedule risk analysis – added to or subtracted from selected schedule events to achieve the desired probability of completing those events on or before the date scheduled.
3) Risk Management Techniques:
a) Experience judgment
b) Monte Carlo analysis
c) Combination of judgment and Monte Carlo analysis – this is the preferred method
d) Targets 80% probability of meeting customer-commitment milestones.
B. Range of Possible Times
Rather than accept a single-point estimate of the amount of time required to perform a particular task, you want to consider the range of possible durations-each activity in the project has its own rand and pattern of duration possibilities.
Using a single value cost estimate of time, you can identify which activities are critical to the project completion schedule.
However, running a simulation of the range estimates, you can identify the activities that appear on the critical path in nearly every instance, and those that appear on the critical path less often. This information can help you focus on "criticality"-the likelihood that an activity will be critical to project completion.
1) Optimistic – the shortest reasonable time for performing the activity.
2) Most likely – the most reasonable time for performing the activity.
3) Pessimistic - the longest reasonable time for performing the activity.
This information enables you to predict, with a high degree of confidence, that the project will be finished by a certain date.
C. Incorporation of schedule contingency
1) Schedule risk/contingency will typically be evaluated for the risks "Included in Risk Assessment". DOE will add their requirements (if any) for risks not typically included. It will be applied only to customer-commitment milestones and not to the schedule detail.
2) Authorized schedule contingency is to be shown as the difference between the customer-approved target milestone date(s) and the Project Team's target milestone date(s) for the same event
3) An activity, called "Schedule Contingency", may be added between these two milestones (recommended)
4) Any baseline budget spread "BCWS" for schedule contingency activities would normally be limited to the cost increase caused by the schedule contingency duration
5) Schedule contingency is "used" by changing the current/forecast schedule contingency duration and/or milestone completion. No BCP required to do perform a schedule risk analysis; however it should be incorporated into the estimate for any re baseline effort. The Project Team should perform a schedule risk analysis, for each "bottoms-up" EAC preparation, at a minimum.
Performance indicator for construction time
In this study the Time Performance Index (TPI) was used as an indicator to assess the level of construction time performance level where TPI is a ratio of actual contract duration to original contract duration. A significant number of earlier studies used the similar indicator but with different terms. For instance, Georgy et al. (2000) called it schedule performance index, Dissanayaka and Kumaraswamy (1999a, b) referred to it as time index, Kaka and Price (1991) named it as duration performance while McKim et al. (2000) addressed it as schedule performance factor. In this study, time performance index (TPI) was calculated for every project using the following equation:
TPI = Actual contract duration
Original contract duration
where. TPI>1, project exceeded original contract duration;
TPI<1, project completed before original duration;
TPI = 1, completion exactly on time.
Actual contract duration is the period from date of possession of site to actual completion date while the original contract duration is a period from date of possession of site to completion date originally specified under the contract.
Gantt charts are a project planning tool that can be used to represent the timing of tasks required to complete a project. Because Gantt charts are simple to understand and easy to construct, they are used by most project managers for all but the most complex projects. In a Gantt chart, each task takes up one row. Dates run along the top in increments of days, weeks or months, depending on the total length of the project. The expected time for each task is represented by a horizontal bar whose left end marks the expected beginning of the task and whose right end marks the expected completion date. Tasks may run sequentially, in parallel or overlapping.
Basic Gantt chart example
As the project progresses, the chart is updated by filling in the bars to a length proportional to the fraction of work that has been accomplished on the task. This way, one can get a quick reading of project progress by drawing a vertical line through the chart at the current date. Completed tasks lie to the left of the line and are completely filled in. Current tasks cross the line and are behind schedule if their filled-in section is to the left of the line and ahead of schedule if the filled-in section stops to the right of the line. Future tasks lie completely to the right of the line.
In constructing a Gantt chart, keep the tasks to a manageable number (no more than 15 or 20) so that the chart fits on a single page. More complex projects may require subordinate charts which detail the timing of all the subtasks which make up one of the main tasks. For team projects, it often helps to have an additional column containing numbers or initials which identify that on the team is responsible for the task.
Often the project has important events which you would like to appear on the project timeline, but which are not tasks. For example, you may wish to highlight when a prototype is complete or the date of a design review. You enter these on a Gantt chart as "milestone" events and mark them with a special symbol, often an upside-down triangle.
4.2.1. Groups of success factors overview
To the project-related category Chan et al. (2004) ascribe mostly project scope and type of project, however, another factors are also generalized by this category by many authors. For example, Yu et al. (2006) ascribe clear objectives and realistic budget to this group. They stress (as well as Fortune and White, 2006) that clear articulation of goals and priorities would help to overcome ambiguity of project successfully. Although this research is focused on construction project briefing, findings refer to the factors valid for other stages of project as well. Another study in construction projects developed by Chan and Kumaraswamy (2002) declares project scope as one of the main components affecting construction duration and therefore project completion in time.
Procurement as a success factor (or group of success factors) seems not to be broadly
recognized among other authors. Under this cluster Chan et al. (2004) put selection of
organization for the design and construction of the project and procedures adopted for the
selection of the project team generally and main contractor particularly. Apart of this,
CEEC's and KPMG's (2008) research on Ukrainian construction industry claims
procurement as the second priority in a list of investment areas for 2008-2009, disclosed by construction companies. It stresses procurement processes' significance especially for construction projects. Although these factors were mostly investigated in 90s, publications dated as 2000s address them to other groups. For instance, Fortune and White (2006) refer procurement and contractor performance to a resource group; and at the same time Chan and Kumaraswamy (2002) state that selection of project team relates to 'management attributes' category.
Project management aspect according to Chan et al. (2004) combines planning and control, organizational structure, overall managerial actions, implementation of effective quality assurance and safety programs. Chan and Kumaraswamy (2002) also categorize similar factors in one group accentuating communication and human resources management. Yu et al. (2006) add under the similar category control of processes naming this group as 'process-related factors'. Also as managerial factors they mention decision-making abilities and communication.
'Project participants' group seems to be the broadest one since it combines different aspects
of project key players and stakeholders management. One decade before human factor
already received a huge attention from researchers. Several categories, as client, contractor,
project champion and others were discussed and findings of those studies initiated a new
cluster related to project participants. Thus, Chan et al. (2004) in his classification define
client and project team leader dimensions for specific characteristics to be assigned
accordingly. Particularly, they focus attention on client's experience, nature and size, client's expectations in terms of project costs, quality and duration and client's managerial abilities. Project team leader category attracts authors' attention in sense of managerial skills (planning, organization, motivation and control), leaders' commitments and support to project. Moreover, Müller and Turner (2008) specify leadership style of Project Manger from all other competences correlated to overall project success.
Chan and Kumaraswamy (2002) also identified project manager's capabilities and client's attributes as the most relevant success factors. Furthermore, Yu et al. (2006) distinguish between success factors related to client and those refer to end user. Other project participants in their study are united in a group of 'stakeholder management'. In contrast, Fortune and White (2006) following Formal System Model components point user and client involvement, competence of project manager, qualified team and good performance of suppliers and contractors as success factors but allocate them into different model's aspects. They also specify project sponsor/ champion role separately.
Environmental factors are referred again as it was in 90s. Chan et al. (2004) single out
economic, social, political, physical, technological factors as well as industrial relations in
this category. Surprisingly, Chan and Kumaraswamy (2002) point identical set of project
success factors related to external environment. Moreover, Fortune and White (2006) find
learning from past experience and organizational adaptation/ culture as success factors
belonging to environment. Although these factors seem to benefit more to overall
management like procedures, politics and personnel skills which become more efficient
from project to project, it is also possible that authors' focus lies in internal environment
analysis. In spite of growing interest to environmental success factors in projects some
authors still do not consider this aspect as important one (Yu et al., 2006)
Project management control processes
The project management control processes should be applied to the project delivery process and each of the regulatory and enabling processes to ensure each has a successful outcome. The project management control processes are:
a) management responsibility;
b) resource management;
c) scope-related processes;
d) time-related processes;
e) cost-related processes including value management;
f) communication-related processes;
g) risk-related processes;
h) procurement-related processes;
i) project and process closure; and
j) measurement, analysis and improvement.
Figure 23 illustrates the project management control processes and how they are applied to the product delivery process and regulatory and enabling processes.
The commitment and active involvement of the management of the client, consulting and contracting organizations involved in the project is essential for developing and maintaining an effective and efficient management system.
Management of each of these organizations should:
a) provide input into the design of project processes;
b) create a culture for safety, sustainability and quality;
c) actively create a culture that motivates the project team toward achieving the project objectives; and
d) provide a commitment to team development.
A desired result is achieved more efficiently when activities and related resources are managed as a process. The project should be managed using a number of integrated processes and sub-processes. The project processes should be documented in the project management plan. Individual processes may be designed specifically for the project, or may be drawn from the client organization, from consultants or contractors. They should demonstrate good practice in the relevant area and may be a combination of processes from existing sources, drawing the best from pre-existing processes. The individual processes should be integrated. In selecting processes, the familiarity of the team with each process should be taken into account, as well as the efficiency of the process. The client organization should communicate the experience gained in developing and using its own processes, or those from its other projects, to the project team. The project team should take account of this experience when establishing the project's processes, but it might also need to establish processes that are unique to the project. Processes should be kept as simple as possible to achieve the required result. Process effectiveness and efficiency may be accessed through internal or external review.
System approach to management
Identifying, understanding and managing inter-related processes as a system contributes to an organization's effectiveness and efficiency in achieving its objectives, and the project management system and organization should be designed with this in mind.
Application of quality management principles through the project process
Planning for the establishment, implementation and maintenance of a quality management system based on the application of quality management principles is a strategic, direction-setting process. In this planning, it is necessary to focus on the quality of both processes and the product to meet the project objectives.
Organizations depend for their future on their customers. They should understand current and future customer needs, should meet customer requirements and strive to exceed customer expectations.
Achievement of the client's requirements, and those of other identified stakeholders, is necessary for the success of the project. These requirements should be identified and clearly understood to ensure that all project processes focus on, and are capable of, meeting them.
The project objectives should include the product specification and its functional requirements. They should take into account the needs and expectations of:
• the customer - the direct project client, perhaps a developer (or a contractor in the case of a subcontract project);
• the eventual owner, occupier or operator of the product; and
• other interested stakeholders.
The project objectives should be documented in the project management plan and should detail what is to be accomplished (expressed in terms of product specification and quality, time for delivery, and cost budget).
The objectives should also set out what is to be measured. Measurement is necessary to allow proper monitoring to take place and hence controls to be applied to ensure that requirements are met. The objectives may be refined or amended during the course of the project. When this occurs it should be through an appropriate change control process.
When it is necessary to determine the balance between time, cost or product quality, the potential impacts on the project's product should be evaluated, taking into consideration the client's and other stakeholders' requirements.
Appropriate lines of communication should be established in the form of a communication plan with all the interested parties to facilitate the exchange of information relating to the project requirements. Any conflicts between the requirements of the various interested parties should be resolved at the earliest opportunity. Normally, when conflicts arise between the requirements of the client and other interested parties, the client's requirements will take precedence, except in the case of statutory or regulatory requirements. Throughout the project, attention will need to be paid to changes in the requirements of stakeholders, including additional requirements from new stakeholders that join the project after it has commenced.
Continual improvement of the project team's overall performance should be a permanent objective of the project. The cycle of continual improvements should be based on the Plan-Do-Check-Act (PDCA) concept.
Provision should be made, as appropriate, for self-assessments, internal audits and, where required, external audits to identify opportunities to improve the project processes. Arrangement should take account of the time and resources needed, balanced against benefit to be gained.
Mutually beneficial supplier relationship
An organization and its suppliers are interdependent and a mutually beneficial relationship enhances the ability of both to create value.
The client and project team should work with its suppliers when defining its strategies for obtaining products and services. Contractors and works contractors should be involved early in the project if they can contribute beneficially to planning and design.
Risk sharing with suppliers should be considered. The benefits to be gained from a number of projects using a common supplier should be investigated where this is relevant.
Management reviews and progress evaluation
The project manager should review the project management plan, including its quality management system, at planned intervals, to ensure its continuing suitability, adequacy, effectiveness and efficiency.
Progress evaluations are regular reviews of project progress with a major review immediately ahead of control points between phases. The following specific recommendations should be met.
a) Progress evaluations should be used:
1) to assess the adequacy of the project management plan and how the work performed conforms to it;
2) to assess whether the project processes are running to plan, to identify any variances and the reasons for these variances, and to facilitate the planning of any necessary corrective action;
3) to evaluate how well the project processes are synchronized and interlinked;
4) to identify and evaluate activities and results that could adversely or favourably affect the achievement of the project objectives;
5) to obtain inputs for planning the remaining work in the project;
6) to facilitate communication; and
7) to drive process improvement in the project, by identifying deviations and changes in risks.
b) Progress evaluations should be planned. The planning should include:
1) the preparation of a schedule of regular progress evaluations (for inclusion in the project management plan);
2) the assignment of responsibility for the management of individual progress evaluations;
3) the specification of the purpose, assessment requirements, processes and outputs for each progress evaluation;
4) the assignment of personnel to participate in the evaluation (e.g. the individuals responsible for the project processes and other interested parties);
5) ensuring that appropriate personnel from the project processes being evaluated are available to provide information for the review or to answer questions; and
6) ensuring that relevant information is prepared and is available for the evaluation (e.g. the project management plan).
c) Those performing the evaluations should:
1) understand the purpose of the processes being evaluated, and their effect on the project quality management system;
2) examine relevant process inputs and outputs;
3) review the monitoring and measuring criteria being applied to the processes;
4) determine whether the processes are effective; and
5) look for potential improvements in process efficiencies. d) Once a progress evaluation has been performed:
1) the outputs of the evaluation should be assessed against the project's objectives, to determine whether the performance of the project against the planned objectives is acceptable; and
2) responsibility should be assigned for actions resulting from the progress evaluation.
Resources include labour, plant, equipment and materials and also facilities, finance, information, materials, computer software, services and space. Resource-related processes aim to plan and control resources.
There should be a clear responsibility and authority for the project's processes divided between the project team and other relevant interested parties (including the client organization). This division should be agreed and recorded.
All resources needed for the project should be identified. Resource plans should state what resources will be needed by the project, and when they will be required according to the project schedule. The plans should indicate how, and from where, resources will be obtained and allocated. The plans should be suitable for resource control.
Resource plans, including estimates, allocations and constraints, together with assumptions made, should be documented and included in the project management plan.
Regular reviews should be performed to ensure that resources are available, and will continue to be available, to meet the project requirements. Deviations from the resource plans should be identified, analysed, acted upon and recorded.
Decisions on actions to be taken should only be made after considering the implications for other project processes and objectives. Changes that affect the project objectives should be agreed with the client and relevant stakeholders before implementation. Procedures should provide for changes in resource plans to be authorized by the manager responsible, as appropriate.
Revisions of forecasts of resource requirements should be coordinated with other project processes when developing the plans for the remaining work.
Root causes for shortages or excesses in resources should be identified, recorded and used as input for continual improvement.
The quality and success of a project will depend on the participating personnel. The personnel-related processes aim to create an environment in which personnel can contribute effectively and efficiently to the project.
A project manager should be appointed to the project as early as possible. Leaders establish unity of purpose and direction for an organization, including a project organization. They should create and maintain the internal project environment such that people can become fully involved in achieving the organization's objectives.
Involvement of people
People at all levels are the essence of any organization, including a project organization. Obtaining their full involvement enables their abilities to be used for the organization's benefit.
Competent personnel should be assigned to the project. Appropriate tools, techniques and methods should be provided to the personnel to enable them to monitor and control the project processes.
In the case of multinational and multicultural projects, joint ventures, international projects, etc., the implications of cross-cultural management should be addressed.
Personnel in the project team should have well-defined responsibilities and authority for their participation in the project. The authority delegated to the project participants should correspond to their assigned responsibility.
Allocation of personnel
Management of the organizations comprising the project team should, together with the project manager, see that appropriate personnel are allocated to the project by the organizations.
The time-related processes relate to project scheduling. They aim to determine the duration of activities and dependencies between activities, and thus allow the duration of the entire project to be established. The processes also relate to monitoring progress, assessing the impact of delay or prolongation, and to planning actions to ensure timely completion of the project.
Planning of activity dependencies
The project scope should be broken down into a work breakdown structure, and individual activities should be defined. The interdependencies among the activities in the project should be identified, documented and reviewed for consistency. Where interdependency involves a lag (i.e. there is a period of time that has to elapse before the follow on activity can take place), or where the follow-on activity can commence before the preceding activity is complete, this should be identified and the appropriate duration should be identified.
Estimation of durations
Duration estimates based on experience should be verified for accuracy and applicability to present project conditions. These estimates should be documented and traceable to their origins. When compiling duration estimates, the associated resource estimates should also be obtained for reference and as an input to resource planning. If the duration estimate is incompatible with the overall project time objectives, then a review of the network logic or ultimately resourcing might need to be carried out to meet the duration estimate.
Statistical techniques should be used as necessary to evaluate the magnitude of any contingency time allowance
Duration estimates from which the schedule will be developed should be compiled and checked for conformity to specific project conditions. An activity network should be prepared linking the various activities on the basis of their dependencies. Activity durations should be applied to the network. The network should be used to prepare the project schedule, or schedules. Depending on the scale of the project, the number of tasks in the network and its complexity, the schedule should be prepared either manually or using a scheduling tool.
Whenever possible, during development of the project plan, standard or proven project network diagrams should be used to take advantage of experience. Their appropriateness to the project should be verified.
The relationships of duration estimates to activity dependencies should be checked for consistency. Any inconsistencies found should be resolved before schedules are finalized and issued.
The schedules should identify critical and near-critical activities, and a critical path. The published schedule should identify events that require specific inputs or decisions, or ones at which major outputs are planned. These are sometimes referred to as key events or milestones. Control points and progress review points should be included in the schedule. Standardized schedule formats, suitable for the different user needs, should be produced for particular uses or audiences. In the construction industry it is traditional to present schedules as a bar chart, although other formats are possible. The client and project manager will be interested in a high-level view of the overall schedule for the project, but a works contractor, for example, might only wish to see activities over the next month, but in far greater detail.
Progress against the project schedule should be reviewed regularly. The frequency of these reviews should be appropriate to the project and defined in the project management plan. Responsibility for reviewing progress and reporting should be defined in the project management plan.
Root causes for variances from schedule, both favourable and unfavourable, should be identified. Action should be taken to ensure that unfavourable variances do not affect project objectives. Causes of both favourable and unfavourable variances should be used to provide data as a basis for continual improvement.
Project progress should be analysed in order to identify trends that could cause possible departures from planned progress on future work.
Where progress departs significantly from the schedule, the schedule should be updated. This should be done to ensure that activities are again properly coordinated. Activity durations should be amended based on known rates of progress, or to reflect the impact of actions being taken to address the variance from the base line schedule. Dependencies should be adjusted as necessary.
The possible impacts of schedule changes on the budget and resources of the project, and on the quality of the product, should be determined after taking into account their implications for other project processes and objectives. Changes that affect the project objectives should be agreed with the client and relevant interested parties before implementation.
The cost-related processes aim to assist in the forecast and management of the project costs. This is intended to ensure as far as possible that the project is completed within budget constraints, and that accurate cost information can be provided to the client and project team throughout the project.
Responsibility for cost estimating should be defined and documented in the project management plan.
When cost estimation involves significant uncertainties, or where the risk processes have identified specific risks which can have a cost effect, these uncertainties should be identified, evaluated, documented and acted upon. Allowance for remaining uncertainties, sometimes called contingencies, should be incorporated in the estimates. Appropriate techniques should be used as necessary to evaluate appropriate levels for contingencies. Wherever possible, contingencies should be specifically related to particular risks so that they can be managed. Lump sum contingencies to cover all eventualities should be avoided.
The cost estimate should be developed to provide a cash flow projection, identifying anticipated expenditure and income over time. The cost estimates should be in a form that enables budgets to be established and developed in accordance with approved accounting procedures as well as project organization needs.
The client should formally agree and accept the budget and cash flow. The budget should be consistent with the project objectives, the brief and the risk assessment. It should be broken down with allowances against specific project phases or activities, or both. Contingency allowances should be identified against particular risks and these should be documented. The budget should be accompanied by a project cash flow projection.
Prior to any expenditure, responsibility for cost management should be defined and documented. The cost control system should be based on the work breakdown structure and be closely integrated with the procurement processes. Cost should be monitored and controlled against particular activities or contracts. The timing of cost reviews and the frequency of data collection, forecasts and reports should be established, agreed with the client and set out in the project management plan.
Root causes for variances to budget, both favourable and unfavourable, should be identified. Action should be taken to ensure that unfavourable variances do not affect project objectives. Causes of both favourable and unfavourable variances should be used to provide data as a basis for continual improvement.
At each review, the project organization should verify whether the remaining work can be carried out to completion within the remaining budget. Any deviation from the budget should be identified and, if exceeding defined limits, the variance should be analysed and appropriate action should be taken. As far as possible, particular activities should be managed such that costs are controlled within the particular work package budget. Any necessary expenditure of contingency should be carefully considered, approved and documented. Where it is not possible to contain over-expenditure within a particular work package, then confirmed under-expenditure against another activity should be used to fund the over-expenditure, avoiding having to increase the overall budget.
Earned value analysis
If it becomes apparent that increased costs will result in the approved budget being exceeded, the client should be notified immediately. An appropriate revision to the budget should be proposed, approved and authorized prior to further expenditure being incurred. Alternatively, an amendment to the product scope should be proposed, approved and authorized to contain costs within the budget. Revisions of the budget forecast should be coordinated with other project processes when developing the plan for remaining work.
The project cash flow should be regularly updated as the project progresses. The project organization should carry out regular reviews of the project costs, as defined in the project management plan, and take into account any other financial reviews (e.g. external reviews by relevant interested parties).
Cost management processes should be designed to provide the level of control and suitability required by internal and external auditors.
Project cost trends should be analysed. The plan for the remaining work should be reviewed on the basis of the conclusions from the analysis.
Earned value analysis can be used for monitoring and analysing costs, efficiency and progress, which are most clearly shown on the curves developed through the application of this technique. Those curves which are the end product of the analysis not only show the relationship between planned, actual and useful work done but can also be augmented by showing percentage complete and efficiency.
The communication-related processes aim to facilitate the exchange of information necessary for the proper management of the project. They ensure timely and appropriate generation, collection, dissemination, storage and ultimate disposition of project information.
Appropriate communication processes should be established for the project, so that communication takes place regarding all necessary aspects of the project, including the effectiveness and efficiency of the project management plan and quality management system. The format, language and structure of project documents and records should be planned to ensure compatibility. The communication plan should define the information management system, identify who will send and receive information, and reference the relevant document control, record control and security procedures.
The management of project risks deals with uncertainties throughout the project. This requires a structured approach that should be documented in a risk management plan. The risk-related processes aim to minimize the impact of potential negative events and to take full advantage of opportunities for improvement.
Risk identification should be performed at the initiation of the project, in advance of key decisions at project decision gateways and on other occasions when significant decisions are to be made.
The results from the risk identification exercise should be collated together with historical data from previous projects. The output of this process should be recorded in a risk management plan.
Risk identification should consider not only risks in cost, time and scope, but also, for example:
a) risk associated with the regulatory processes;
b) risks resulting from any proposed use of new technologies;
c) risks due to a failure of the project processes; and
d) risk associated with internal and external politics.
The interactions between different risks should be taken into account.
Risk assessment is the process of analysing a risk and evaluating both its likelihood of occurring and its impact if it does occur.
Levels of risk acceptable for the project, and the means to determine when agreed-to levels of risk are exceeded, should be identified and documented in the risk management plan.
The results of all analysis and evaluations should be recorded and communicated to the relevant personnel and organizations.
Solutions to eliminate, mitigate, transfer, share or accept risks, and plans to take advantage of opportunities, should preferably be based on known technologies or data from experience to avoid introducing further risk.
When a solution to an identified risk is proposed, it should be verified that there will be no undesirable effects or new risks introduced by its implementation. Any resulting residual risk should also be taken into account. The proposed action should be documented and communicated. Consciously accepted risks should be identified and the reasons for accepting them recorded.
Where contingency allowances are used to manage risk and are included in the time schedule or in the budget, they should be identified against the relevant risk headings and should be maintained and managed separately. All-embracing contingency allowances against risk should be avoided.
Throughout the project, risks should be monitored and controlled by an iterative process of risk identification, risk assessment and risk treatment. An owner should be identified to be responsible for each risk requiring treatment.
The procurement-related processes deal with obtaining resources, services and products for the project. These processes are relevant to all levels of procurement within the project. The purpose of the procurement is to procure resources to carry out the project, to procure components for the product, and to properly allocate risk.
A procurement plan should be prepared in which the products (including services) to be obtained are identified and scheduled. The plan should take due consideration of the project brief, the proposed project organization structure and the product delivery process in identifying the products to be purchased. This plan is often referred to as the procurement strategy for the project.
The plan should identify:
• the products to be purchased;
• a specification for those products;
• method of procurement;
• the form of contract to be used;
• a list of proposed suppliers; and
• budgets and key dates in the procurement process.
All products and services that are used in the project should be subjected to similar controls, regardless of whether they are obtained from external suppliers or from the client organization (i.e. in-house). To provide adequate procurement control, the project team should carry out regular reviews of procurement progress, which should be compared to the procurement plan. Action should be taken if needed. The results of the reviews should be input into progress evaluations.