Technical Board Spotlight – Source

Part 5 – Six Elements of Project Controls – Proof of Value

admin — Thu, 29 Aug 2024 14:27:38 +0000

Part 5 – Six Elements of Project Controls –Proof of Value

By Lance Stephenson, CCP FAACE Hon. Life

Lance Stephenson, CCP FAACE Hon. Life, is a contributing member of AACE’s Technical Board and is a Certified Cost Professional. Lance has provided direction in the areas of organizational design, process improvements, auditing, maturity assessments, and the development and implementation for improved capital portfolio and project effectiveness. He is a senior leader and manager with over 35 years of experience in the operational, capital portfolio, and project delivery environment and is currently the Director of Operations for AECOM.

Links to parts 1 thru 4:

Part 1 – Six Elements of Project Controls – The Basics

Part 2 – Six Elements of Project Controls – Quality

Part 3 – Six Elements of Project Controls – Maturity

Part 4 – Six Elements of Project Controls – Competency and Level of Effort

This article continues the series on the Six Elements of Project Controls. Past articles included the basics of the six elements of project controls, the effect of quality, the maturity required, defined competencies, and the level of effort. Today’s article discusses the value of introducing and managing the six elements of project controls within your organization. The six elements include the following:

The six elements of project controls are the operational steps for managing functional project control requirements within a project. As discussed in earlier articles, knowing about these elements is not enough; it is essential to know why they need to be applied to fully comprehend the value these efforts provide. The following case study provides the required context for further comprehending their criticality.

Case Study – Interconnecting Piping System Project

A project was required to improve the throughput of an interconnecting piping system to an existing pipeline facility.

The project’s total installed cost (TIC) was estimated at $27.97 MM.
Contingency was set at $3.17 MM.
The TIC for the project included all front-end loading (FEL), execution, and commissioning/startup costs.
The Front-End Loading (FEL) phases were estimated to take eight months to
Detailed engineering (six months).
Construction (ten months).

The project had an aggressive finish date as it had to align with the shipper’s shutdown date (to connect to their oil refining facility); a one-month schedule buffer was added to the overall duration to ensure that the in-service date would be met. The project was highly complex, with numerous significant risks identified due to the large number of underground work and connection points. Much above-groundwork was also required, so coordination efforts were critical for success. Due to the complexity and aggressive finish date, it was determined that time and material (T&M) contracts would be required, and the owner would carry most of the project and financial risks. The construction portion of the project was competitively bid, where a target estimate was determined.

Because of these requirements and subsequent concerns, it was decided that a more experienced project controls team would be required to provide the proper governance and oversight to manage the risks and, subsequently, the execution of the project. The total owner project controls budget was then set at $559.5 K (2% of TIC) of which $111.9 K was allocated to manage the FEL phases and $447.6 K was used to manage the execution portion of the project (detail engineering, procurement, and construction). The contractor was required to assign dedicated, experienced project control personnel funded within their respective contract. Table 1 illustrates the budget elements for the project per phase, including a breakdown of the owner project controls budget.

Table 1 – Project Controls Budget for the Interconnect Piping System Project

The project progressed smoothly through the FEL phases with no substantial cost increase or delay in meeting the required in-service date. The detail-design portion of the execution phase also experienced minimal issues; the design intent was maintained. With everything going according to schedule and budget, the project manager (and his senior manager) cut the budget for the owner’s field project control staff as they didn’t see the value of having a field project control presence. The owner project controls budget for field activities was estimated at $342.4 K. This budget was required to provide governance, oversight, and risk management for contractor activities while providing overall project administrative/controls duties for the owner project manager and team. Even though eliminating the owner project controls effort was highly contested, the decision was not overturned. Because of this budget cut, the project controls manager requested that his team validate the schedule, resource requirements, and progress measurement (earning rules) to ensure a robust plan was in place. This request was also denied.

Construction activities started on time as planned, and as the construction activities progressed, the contractor provided construction reports on the work activities. The contractor did assign a project coordinator to complete the project controls deliverables as outlined in the contract; however, minimal reporting was introduced, and only a three-week look-ahead schedule was used. It was later determined that the project coordinator did not have the project controls skill set as defined in the contract, nor did the contractor comply with the requirements.

At the end of the sixth month of the 10-month construction schedule, it became apparent that the contractor and its subcontractors were experiencing performance and delay issues, which impacted both the costs and schedule of the construction activities. The senior manager, who enforced the decision not to have owner project controls oversight, asked for a team of project controls specialists to be assigned to complete an investigation and provide triage support as necessary. The triage efforts introduced allowed the project team to recover one month of the seven-month schedule delay and identify some improvements for a small reduction in the forecasted cost overrun.

Findings from the Investigation – The Dissection of Impacts

Upon project completion, a post-mortem[i] was completed. Table 2 represents the activities that contributed to the project cost impacts on the owner and constructor’s costs. The list provides the cost increases for owner costs as well as the construction costs. The most significant cost increase for the owner was due to the schedule extension. The extension to the schedule also contributed to increased construction costs; labor performance also contributed to the increase.

Table 2 – Post-mortem of Project Costs

The contractor costs grew from an original budget of $18.20 MM to $26.67 MM, while the owner costs grew from $3.20 MM to $7.00 MM, as illustrated in Table 3. The owner project controls cost to complete the investigation and support the triage effort was $702,720, over twice the amount of the original budget of $342,390. With 100% of the contingency funds used to pay for some additional costs, the total project overrun came to $9.27 MM. The overrun was paid for out of the portfolio funds[ii] allocated for the fiscal period.

Table 3 – Variance of Project Costs by Participant

The more significant issue was the owner’s revenue and profit loss. Table 4 illustrates that the outage and schedule delays contributed to $8.48 MM in lost profits. The business cost[iii] overrun, including profit/loss, was $17.75 MM, 97.5% of the original construction costs ($18.2 MM).

Table 4 – Total Cost Impact

While the cost and schedule impacts on the project were quite evident, there was a negative ripple effect on the organization. The project’s estimated return on investment (ROI) was 28%, with a hurdle rate of 13.5%. The investment was expected to yield returns exceeding the minimum rate of 12% required to justify the risks and costs of spending capital dollars on the project. Unfortunately, once the project was completed, the post-mortem assessment determined the expected yield at 10.5%, which would have resulted in the project’s rejection.

Owner organizations need to be acutely aware of the mismanagement of costs and schedule durations, given it has a negative impact on the project’s return on investment (ROI) and internal rate of return (IRR). These cost impacts affect the organization’s bottom line. For instance, it may result in the cancelation of downstream projects as other funding streams (portfolio funding, OPEX, etc.) are being expended to correct struggling project(s). Unfortunately, owner project teams may not realize their contributions to the total impact of their project(s) and the impact they may have on the residual costs the organization is required to absorb. This lack of realization, as illustrated in this case study, can have an even more significant impact on the organization’s competitive advantage. Because of the cost impact, the owner company may have to increase its rate structure for moving products to absorb the losses of the project. This approach to increasing the rate structure is known as the death spiral[iv]. Increasing the rate structure could change the competitive landscape in which they operate and put their market share at risk (further enhancing the downward spiral).

While the focus of the case study has been on cost impacts and schedule delays, other critical issues were also identified. Due to the lack of planning efforts, a significant safety event occurred in which two laborers were injured. The contractor was required to install a concrete pony wall and elevated pump foundations in one of the work areas. Unfortunately, the installation of the pony wall restricted access to the area where tanks needed to be installed. This, along with the elevated pump foundations, further restricted the team from moving any construction equipment (backhoe with hydraulic breaker) into the work area. Therefore, laborers had to demolish the pony wall using jackhammers and hand tools. While jackhammering, a portion of the wall collapsed on the two laborers. One individual suffered a sprained wrist, while another individual broke his leg. This individual was caught between the fallen pony wall and the elevated pump foundation. This issue restricted the ability to evacuate the laborer to receive medical care, which could have potentially turned this into a catastrophic event had the injuries been much worse. If a proper schedule had been developed and validated, the project team would have been made aware of the sequencing required to install the tanks, build the pony wall, and construct the elevated pump foundations. While this event did not have a direct monetary impact on the contractor, it did, however, change their safety rating, disqualifying them from bidding on any future work.

Another impact that occurred was the erosion of team morale. The lack of accountability and responsibility to execute the work destroyed any trust among the team members. This created a silo mentality, which instituted the blame game. This further hindered collaboration, eliminating the ability to collectively solve any problems that occurred. While it is difficult to determine the cost impact of team morale, this did have a causal effect on quality, safety, and productivity.

The case study provided demonstrates a myriad of lessons learned opportunities. Based on the post-mortem assessment, many contributing factors were identified which resulted in cost overruns and schedule delays. A summary of contributing factors include:

The contractor demonstrated competency in project controls during the pre-qualification phase but did not implement the processes/systems as contractually required, i.e., bait and switch!
The contractor had identified that two on-site project controls specialists were assigned in their proposal but chose not to fill these positions. The contractor had delegated the project coordinator (having minimal training) to complete the project controls efforts. His lack of focus on project controls efforts compounded site issues, which included:
1. Actual costs/hours were not collected correctly (missing information).
2. No progress measurement or earned value management was implemented; therefore, performance assessments were not carried out.
3. Developed 3-week look-ahead schedules in Excel (without logic) instead of CPM Schedules (with logic). CPM schedules provide a structured, logical, and analytical approach with the capability to depict dependencies, progress tracking, float, delays, and resource allocation.
There was a lack of change management controls (the contractor did not identify changes to the scope of work until the last few weeks of the project). A claim of $350,000 was submitted after the contractor left the site. This limited the ability to forecast potential outcomes. The lack of change management controls resulted in the inability to accurately identify additional risks as well.
There was a lack of risk management controls, where the risk register was not kept up to date. This eliminated the ability to administer and identify mitigation strategies and use contingency funding properly, further reducing the ability to forecast potential outcomes.
The contractor never applied the required resourcing levels to maintain the execution of the scheduled activities. Without proper reporting, the project team could not identify the impact of the lack of full-time-equivalent (FTEs) craft resources required to complete the construction activities. A resource-loaded CPM schedule would have provided this foresight.
A proper schedule would have identified access/egress issues; the contractor had excavated numerous areas to install underground pipe. The numerous open areas restricted teams from working in a systematic and efficient manner, creating performance, productivity, and safety issues.
Construction delays also caused compounding performance issues and introduced additional undue risks to the project including:

1. Overtime and work week extensions resulted in fatigue and morale issues (diminished productivity and performance).
2. Parallel work zones created congestion and interface issues between craft crews.
3. Quality and craftsmanship of the installation were reduced due to fatigue and rework.
4. Fatigue, team morale, congestion, rework, and performance issues all contributed to an unsafe work environment. The contractor’s safety rating doubled.

Most of the attention of this case study demonstrates cost and schedule impacts absorbed by the owner, as a T&M contract was put in place. The T&M contract structure shifted liability to the owner, requiring them to provide increased contractor oversight; however, if a firm-price contract were chosen, the contractor would have been liable. The contractor would have absorbed most of the cost impact because of their lack of compliance and due diligence in executing the work.

Degree of Application

Some would state that the project provided in the case study was destined to fail because of the impact of upstream events, which affected the construction activities. However, the investigation determined that this statement would be untrue. The scope of work was well-defined prior to starting construction activities. This was substantiated by the fact that minimal scope changes were introduced during the FEL and detail-design phases of the project. The contractor did accuse the owner of having a terrible target estimate[v]. This claim was refuted as a third-party assessment concluded project costs were in the mid-to-high point range of historical and benchmarked data of similar projects. In fact, the production rates used to validate the estimate were higher than the contractor’s original bid estimate and their supporting historical data. The owner also applied $3.17 MM (11.3% of the TIC) for contingency based on a P70 ranking (70% probability of achieving the estimated costs).

From the investigation, it was determined that the contributing factor was the means and methods of execution, compounded by the lack of project controls (oversight), resulting in inhibited and diminished performance. Unfortunately, by not assigning the personnel as budgeted by both the owner and contractor, the project teams introduced layers of systemic risks[vi] to the project. The budget of the project controls personnel was the countermeasure to mitigate any cost and schedule impacts and assist in implementing corrective actions via re-planning efforts. If the project team had introduced the assigned resources, appropriate governance, oversight, control, and analysis would have been provided to determine the project’s health. This would have identified issues in advance where mitigation measures could have been introduced. While not all costs or delays would have been eliminated, the team would have been aware of them and instituted corrective actions to minimize their impact[vii].

Numerous studies have been conducted indicating the application of project controls efforts can positively influence the project’s outcome. Organizations can establish the application of project controls by introducing both development costs/efforts and monitoring and controlling costs/efforts to drastically reduce project failure costs, as illustrated in Figure 1.

Figure 1 – Application of Project Controls Costs/Efforts

To understand the relationship between effort and reduction of failure costs, one must understand the individual efforts and their contributions. Each effort is driven by the same components: people, process, and technology, known as the PPT framework. Without the full complement of the PPT framework, the maturity of the efforts would not be realized, resulting in an increase in failure costs. The following further elaborates on this philosophy:

Development effort is expended to prevent or avoid execution problems and enhance and optimize project delivery. The effort and subsequent costs are associated with designing and implementing the performance measurement baselines, which become the surveillance envelope. These deliverables are planned and incurred before the actual execution of the project or parts of the project.
Monitor and control effort is associated with measuring and monitoring activities related to the project teams’ execution efforts. This is where surveillance begins and continues until the project closeout.
Failure costs are incurred based on the influence of deliverable defects and lack of monitoring and control. These costs occur when the results of work fail to reach quality standards.

It must be noted that both development and monitoring/controlling efforts complement the best practical approach for instituting project controls. These efforts cannot be completed separately or in part. For instance, completing development efforts without monitoring and controlling the project does not ensure a favorable outcome. It’s equivalent to instituting laws without police officers or a judicial system to administer (monitor) and enforce (govern) them. On the flip side, you have nothing to monitor and control if you do not have the required deliverables developed. Worse yet, if you don’t have the skills (competency and capacity), you don’t know what or how to monitor and control the project. With this said, there is no opportunity to complete variance analysis to determine the impacts and institute course correction. Development efforts, complemented by monitoring and control efforts, go hand in hand. These efforts are effective barriers[viii] and act as an early warning system, eliminating factors causing project failure.

If the suggested efforts identified in this series of project control articles are implemented, organizations can significantly increase their chances for project success and minimize financial losses. On the other hand, if these efforts are not implemented, organizations will continue to introduce chaos and go down the path of failure. Your project control actions determine your success.

Proof of Value

The Value of Project Controls, as defined by the author, is the methodology that allows organizations to determine how much their resources are used for activities that enhance project delivery. This value is provided through the quality, maturity, competency, and level of effort of the organizations’ project control services. Project controls should never be considered a cost to a project; rather, they should be a value that contributes to positive outcomes, as demonstrated in the case study provided. Because the project team considered the project control effort as a cost (as illustrated in the case study), issues arose that contributed to the failure of this project. The decision to eliminate the field portion of the owner project controls team and the contractor’s lack of project controls compliance and skills impacted both parties. Both organizations experienced monetary, strategic, and reputational damage from this outcome. The contractor lost out on future work with the owner company because of their inability to provide the required personnel, and the owner project team was moved out of the organization due to their lack of judgment. Ultimately, this eroded trust and accountability, eliminating both organizations’ focus on value.

Figure 2 illustrates the association of the six elements in relation to the quality, maturity, competency, and level of effort components. These components can be further enhanced using credible, industry-based practices and standards, like AACE International’s TCM Framework, recommended practices (RPs), and skills and knowledge (S&K) study guides. Using these industry-recognized resources further increases organizations’ quality, maturity, and competency levels.

Figure 2 – Value of Project Controls

From earlier articles, it’s been discussed that an organization’s success is greatly enhanced if quality, maturity, and competency measures are implemented. Based on the case study provided, it is equally important to comply with these requirements. Proof of value is difficult to justify if these measures are not applied. The contractor and owner teams blatantly chose to ignore the requirements, resulting in costly (tangible and non-tangible) losses. The existing attitude towards compliance was problematic, to the tune of $17.57 MM to the owner company. While the project team knew what needed to be done (based on the original baseline), their refusal to introduce the defined measures obstructed management from knowing the complete scope of work. This, in turn, affected how the performance measurement baselines were assessed and how change was managed, resulting in the minimization of the team’s ability to know what had been done. Having used the assigned project controls personnel, the project teams would have known how actual performance compared to the baseline and checked the results of the corrective actions. This ripple effect impeded the teams’ ability to effectively compare the project’s performance to their respective baselines. The ability to know what work remained to be completed was, therefore, misleading. This inhibited the teams’ ability to identify and implement corrective actions to align performance with expectations. The cumulative effect of the lack of project control efforts and mismanagement contributed to project failure.

Defining and demonstrating project controls’ value may be difficult for some organizations. It is incumbent on the organization to recognize the requirements and minimize these difficulties. The following statements assist an organization in establishing the value that project controls can provide:

If you can’t define the value, how do you know its worth? Make sure you define the value.
If people can’t understand the value, why should they care? Make sure you communicate the value.
If you don’t know where you’re going, how will you get there? Make sure you deliver the value.
If you can’t prove what you’ve delivered, why should people trust you again? Make sure you measure the value.

In closing, imagine the following: You own a $65,000 vehicle but do not have any insurance on it. Imagine getting in an accident where you are at fault. Imagine having to replace both vehicles, plus pay for a civil lawsuit for personal damages. Imagine if a fatality had occurred. Now imagine if you had bought insurance, where a small investment of $200 a month would have saved you millions of dollars and potential jail time. In terms of the case study, imagine if both development costs/effort and monitoring and controlling costs/effort for both the owner and constructor were applied. Imagine that the organizations introduced effective barriers to minimize project failure. Imagine!

Footnotes:

[i] The post-mortem assessment included an event tree analysis and systems dynamic modeling. System dynamics modeling, introduced in Part 2 of this series of articles (Six Elements of Project Controls— Quality), is a continuous simulation model using hypothesized relations across activities and processes. It can describe ways to assess the degree of the formal process needed to deliver the system (i.e., project controls) with the required level of quality.

[ii] Most, if not all owners, irrespective of their portfolio size, set an upset limit (spend ceiling) for Capex funds to be utilized annually. These limits play a pivotal role in financial management, allowing organizations to regulate their portfolio’s financial debt.

[iii] Business cost overruns go beyond project cost overruns; they define the tangible costs instigated by the cause-and-effect relationships that projects have with the overall organization. Business costs do not include intangible costs, which may include costs to repair the organization’s reputation, strategic endeavors, competition risks, etc.

[iv] A death spiral occurs when an owner organization tries to re-balance its costs (who pays for what). Death spirals are caused by a decrease in revenue and an increase in costs. To offset this, in terms of pipeline providers, rate hikes are introduced. In most circumstances, both the shipper and end customer will pay for this increase. Death spirals can also be caused by the downward demand of products.

[v] A target estimate was established based on the submittal of the competitive bids from five contractors. The target estimate provided a fair and equitable approach to managing the project.

[vi] Systemic risks are uncertainties (threats or opportunities) that are an artifact of an industry, company or project system, culture, strategy, complexity, technology, or similar over-arching characteristics. AACE 10S-90 Cost Engineering Terminology.

[vii] For further understanding of project failure, it is recommended that you read the article TCM.3933 The Project Life Cycle: Preventing Change and Project Failure, AACE Transactions, 2022, H. Lance Stephenson, CCP FAACE.

[viii] Established barriers are key components for defining preventative actions for instituting the Swiss cheese model. The Swiss cheese model is used in risk analysis and risk management as the principle behind layered security. It likens human systems to multiple slices of Swiss cheese, stacked side by side, in which the risk of a threat becoming a reality is mitigated by the differing layers and types of defenses that are “layered” behind each other. In theory, lapses and weaknesses in one defense do not allow a risk to materialize since other defenses also exist to prevent a single point of failure. It is sometimes called the cumulative act effect (Wikipedia).

Review this Series

Part 1 – Six Elements of Project Controls – The Basics

Part 2 – Six Elements of Project Controls – Quality

Part 3 – Six Elements of Project Controls – Maturity

Part 4 – Six Elements of Project Controls – Competency and Level of Effort

admin — Mon, 22 Jan 2024 20:14:09 +0000

Part 4 – Six Elements of Project Controls –
Competency and Level of Effort

By Lance Stephenson, CCP FAACE

Lance Stephenson, CCP FAACE, is a contributing member of AACE’s Technical Board and is a Certified Cost Professional. Lance has provided direction in the areas of organizational design, process improvements, auditing, maturity assessments, and the development and implementation for improved capital portfolio and project effectiveness. He is a senior leader and manager with over 35 years of experience in the operational, capital portfolio, and project delivery environment and is currently the Director of Operations for AECOM.

Links to parts 1 thru 3:

Part 1 – Six Elements of Project Controls – The Basics
Part 2 – Six Elements of Project Controls – Quality
Part 3 – Six Elements of Project Controls – Maturity

This article is the fourth in the series on the Six Elements of Project Controls. Past articles included the basics of the six elements of project controls, the effect of quality, and the maturity required. Today’s article discusses the competency and level of effort required to manage these elements of project controls. As discussed in the earlier articles, the six elements of project controls are considered the operational steps for managing the functional project controls requirements within a project. The six elements include the following:

It is not enough for a project organization to just know about these elements, their expected quality, and maturity requirements to make their project successful. Two other ingredients to apply for success are competency and level of effort. Competency is the possession of sufficient knowledge or skill, while the level of effort is the amount of work needed to execute the project’s activities. For an organization, competencies are core masteries that define what, who, and how the organization will deploy its employees to accomplish its overall goals. The level of effort defines the intensity (scale) and when deliverables need to be completed. Based on these expectations, the organization and its employees must provide the necessary competency and effort to complete the defined work.

Before developing competency models for enhanced project delivery, the organization must recognize its core strengths and understand the requirements needed to succeed in its business endeavors. This includes understanding the complexities and risks associated with the projects they deliver. While most executives focus on the final installed costs to determine if the project should be executed, other factors should be considered. For instance, is the organization experienced in designing or constructing the project (i.e., qualified resources)? Does the organization have the understanding and ability to perform different project delivery strategies (design-bid-build, design-build, etc.) and contract types (time and material, firm price, etc.)? Is the project introducing any new technology the organization has not executed before? Is the delivery of the project urgent and a priority? Is the project critical (and vital) for the organization to meet its business objectives? Does the project need to be delivered in a compressed time frame? Are there major contractor interfaces and logistical coordination requirements? Finally, are there any significant uncertainties and constraints?

Understanding these factors allows the organization to determine the required competencies and scale its operations accordingly. For more complex and riskier projects, you will require advanced technical skills, knowledge, and experience to administer the project to a favorable outcome. For projects with minimal complexity and risks, the organization may choose to reduce its oversight (administration) and surveillance (observation).

For owner organizations, it has been identified that approximately 1 to 3 percent of the TIC costs of the project are dedicated toward the project control efforts. Projects with more complexity and significant risks may require more experience and oversight (3%), while simple projects may require less (1%). Please note that while the top-down estimating approach provides the basis for determining budgets and resources, the project team should support the development of the Class 3 estimate with a bottom-up, deliverable-based estimate as defined by the project controls scope of work and requirements.

Competency

Once the organization has defined the type of project work that it wants to engage in, as a first step, it can now define the desired enterprise capabilities, as illustrated in Figure 1. This diagram itemizes the primary elements required to support the implementation of the overall competency models for management, which further supports their employees and their development. Without these attributes, introducing practical competencies will be challenging.

Figure 1 – Enterprise Capabilities

Organizational Competency:

With the enterprise capabilities defined, the organization can begin establishing the taxonomy of the organizational competency. When defining organizational competency, it must identify the corporate and functional project mandates that support the overall business strategy. The organization should also define its vision and mission statements, executive directives, and key performance indicators (KPI). Subsequently, the organization must establish its required project management and project controls standard practices, processes, templates, and tools to provide the appropriate monitoring levels, controls, and project reporting. These standard practices must be functionally adequate and assessed against approved standards, preferably best practices known to produce favorable outcomes. Figure 2 provides an example of the hierarchy of deliverables that define and support organizational competency. The introduction and adherence to this hierarchy will provide the appropriate level of awareness of the health of the project and organization.

Figure 2 – Project Controls Taxonomy

When establishing the business norms for operating a project delivery model, the organization will be required to provide the appropriate context and governance for applying any policies, procedures, and processes. An organization cannot be successful if it does not ensure compliance with these requirements. The policies, procedures, and processes are written to improve the efficiency and effectiveness of the organization, as well as improve the timeliness of decision-making and problem-solving. Finally, by ensuring compliance, the organization can identify and mitigate enterprise, portfolio, and project risks. Policies, procedures, and processes are written to protect the organization’s interests, not to obstruct the membership of the organization nor the delivery of the project. Organizations may want to reference AACE’s Total Cost Management Framework and associated recommended practices to develop organizational competencies.

Employee Competency:

Another failing aspect of some organizations is the lack of defined roles, responsibilities, and expectations. This, in turn, affects the required competencies of the organization’s employees. If they do not know what to do, don’t expect them to do it. Worse yet, expect them to do the wrong thing. The organization must define clear and concise competencies for each of its roles within the project controls environment. These competencies should be observable abilities, skills, and knowledge of specific areas of the project controls domain. This also includes the motivations, traits, and behaviors needed to perform the job successfully. For the organization to further develop the competencies of its employees, a competency development program should be introduced. Organizations will need to consider the following:

The scope of work for each core service or targeted area is based on the pre-defined organization competencies.
Identify the needs for each specific discipline within the category, including:
- Level of effort for each discipline (risk vs. reward).
- Interfaces between disciplines and coordination activities (integration).
Define the level of skill required for each assigned task and assign the appropriate skill category.
- Assign entry-level staff to less technical tasks.
- Assign a more experienced resource mix for highly technical /risky /complex scopes of work.
Once these items have been defined, determine the gaps where enhancements can be introduced.
- Introduce appropriate training seminars/events.
- Promote team members to participate in practice groups or academic societies that improve competencies.
- Introduce train-the-trainer as well as mentorship programs.
- Introduce an apprenticeship program that advances staff through organized education.
If staff is unavailable, the organization will need to partner (contract) with a 3^rd party organization to provide the required services.

Another suggestion for employees to improve their competencies is to achieve professional certifications from reputable organizations. These certifications promote a level of professionalism, expertise, and credibility. The following list identifies specific industry-relevant certifications education institutions offer within the project delivery domain.

Certified Cost Professional (CCP) – AACE International
Planning Scheduling Professional (PSP) – AACE International
Earned Value Professional (EVP) – AACE International
Certified Estimating Professional (CEP) – AACE International
Decision and Risk Management Professional (DRMP) – AACE International
Project Risk Management Professional (PRMP) – AACE International
Certified Forensic Claims Consultant (CFCC) – AACE International
Certified Supply Chain Professional (CSCP) – The Association for Supply Chain Management or Supply Chain Management Professional (SCMP) – Supply Chain Canada
Certified Value Specialist (CVS) – SAVE International
Project Management Professional (PMP) – Project Management Institute

For a project team member to be effective in their role, the organization needs to ensure these individuals have the capability and availability (for the role’s complexity), aptitude, skills and knowledge, and commitment to, and value of, the work required of this role. Organizations may want to introduce scalability (levels) to their defined roles, i.e., junior, intermediate, senior scheduler, estimator, etc. Organizations may also want to reference AACE’s recommended practice, RP 11R-88, Required Skills and Knowledge of Cost Engineering. AACE offers other skills and knowledge RPs for other functions under the cost engineering domain.

Level of Effort Based on Assigned Deliverables and Phase Gates:

As discussed earlier, knowing the required level of effort and when an organization is required to unleash these competencies is equally important. No one wants to attend the dance late (or even too early). To methodically complete the execution of deliverables, organizations should introduce a phase-gate process. This approach promotes the timely release of required documents so that information is available to support effective problem-solving, decision-making, approval(s), and advancement.

A phase-gate process is a project life cycle technique in which an initiative or project (e.g., new product development, software development, process improvement, business change) is divided into distinct phases or stages, separated by assessment and decision points (control gates). For some users, especially owner companies, the phase-gating process is considered a go, no-go decision-making model where the continuation of the project is decided by managers, steering committees, or governance boards (at each control gate). It also enforces that the project teams will apply the required quality when developing the deliverables as well as ensure the maturing of the scope of work as it passes through the gates (deliverables are assigned to each phase, which are either completed in the phase or are further developed as the project moves through the phases). Figure 3 illustrates the typical phase gate for the process industry that an owner company may use. In this example, the phase gate is separated into two sections: front-end loading (FEL) and execution. Conceptual and semi-detailed engineering occurs during the FEL phases. Once FEL is complete, the project team usually receives full funding to move the project forward. Once funding has been approved, execution of the project occurs, where detailed design (engineering), procurement, and construction activities ensue.

Figure 3 – Typical Phase Gating Arrow – Process Industry

As stated earlier, project controls deliverables are assigned to each phase to ensure that the expectations are being met when required, as illustrated in Table 1. The table identifies the element in which the deliverable is assigned and the required maturity (level of completeness) of the deliverable (preliminary (P), detailed (D), or updated (U)). For a comprehensive list of project controls deliverables, please reference AACE’s RP 60R-10, Developing the Project Controls Plan.

Table 1 – Phase Gate Assignment of the Deliverables for the Six Elements of Project Controls

Completing the work during the designated timeframe is crucial to project success and ensures that the desired competencies and expectations are met without redundancy, overlap, or gaps. This also promotes healthy behaviors in developing and managing project expectations. If completed appropriately, the project team can then understand the level and distribution of these efforts, as illustrated in Figure 4. This further allows project teams to plan resources accordingly and properly administer the work to be completed.

Figure 4 – Level of Effort and Distribution – Proposed State

Figure 4 illustrates the level of effort. Element 1, knowing what has to be done, consumes approximately 20% of the total project and controls overall effort. Element 2, knowing what has been done, consumes approximately 10%, etc. The timing of effort graph illustrates the distribution of the effort for each element over the project life cycle. As illustrated, most of Element 1’s efforts (15% of the 20%) are concentrated in the planning (FEL) phase, while the remaining efforts for Element 1 (5% of the 20%) are being performed during the execution phase. This portion of effort for Element 1 allows the project controls team to update and re-plan (if necessary) the project based on the performance of delivery, changes to the project, the re-assessment of risks, and forecasting the final outcome. The remaining elements (2 through 6) are performed entirely during the execution phase. The level of effort and distribution over time allows organizations to estimate the costs of the project controls team.

To demonstrate the calculation for determining the costs of the project controls efforts, the following example is provided. A company was required to install an interconnecting piping system to an existing facility. The total installed cost (TIC) of the project was estimated at $11.810 MM. This new interconnect piping system would allow a different feedstock to be introduced into the facility. The FEL phases would take four months to execute, while the detailed engineering and construction period was expected to take eight months. For this project, it was determined that it was highly complex and had significant risks, and therefore, it was identified that 3 percent of the TIC costs should be dedicated towards the project controls efforts. With this said, the project controls budget was set at $354,300, of which 15% ($53,145) was allocated to manage the FEL phases. The remaining funds of $301,155 were used to manage the execution portion of the project (home office engineering and field construction). Table 2 illustrates the budget components of the project, the percentage of TIC, estimated hours, and full-time equivalents (FTEs) of required personnel. The organization now has a budget that supports the required competency and level of effort at which to perform the project controls duties.

Table 2 – Project Controls Budget for the Interconnect Piping System Project

Figure 5 illustrates the cash flow projection for project controls for the example project. It displays both the cash flow and FTE requirements for the project life cycle.

Figure 5 – Project Controls Cash Flow

Going through the motions and simulating project controls efforts will only create negativity and minimize the functionality and value this profession brings to project delivery. Compound this issue with ill timing, and the results could be disastrous. Therefore, applying the correct competencies for the organization and its employees is essential. The success of using these competencies is also predicated on the level of effort and the timing of these efforts. The Six Elements of Project Controls, complemented with these competencies, further provide the organization with an objective approach to ensure project success.

Review this Series

Part 1 – Six Elements of Project Controls – The Basics
Part 2 – Six Elements of Project Controls – Quality
Part 3 – Six Elements of Project Controls – Maturity

Part 3 – Six Elements of Project Controls; Maturity

admin — Wed, 24 May 2023 19:54:09 +0000

Part 3 – Six Elements of Project Controls – Maturity

By Lance Stephenson, CCP FAACE

Links to parts 1 and 2:

Part 1 – Six Elements of Project Controls – The Basics
Part 2 – Six Elements of Project Controls – Quality

Last year, I provided two short articles for our readership: one on the six elements of project controls and the other on their required quality features. These articles provided an understanding of the operational steps and the expected quality for managing the functional project control requirements within a project. The operational steps of the six elements of project controls include the following:

Introducing the six elements and improved quality provides an organization with the basic requirements for developing and executing project control deliverables. While it is extremely valuable for organizations to use these elements and comprehensively evaluate the quality of the deliverables, it is equally important that the organization instills the required maturity to support effective and successful project delivery.

The six elements can be considered the stepping-stones to achieving the appropriate level of maturity, as illustrated in Figure 1. These stepping-stones provide the necessary focus on the specific tasks that each element requires. Subsequently, the state and maturity of one element and its deliverables are dependent on the previous element(s). For instance, if the organization does not know what has to be done, how could they know what has been done, nor what remains to be done? Furthermore, how can an organization introduce corrective actions if they do not know how the actual performance is compared to its project baselines? The greater the maturity of each individual element increases the overall maturity, increasing the surveillance envelop and therefore, opportunity for success.

Figure 1 – Six Elements of Project Controls, The Stepping-Stones to Increased Maturity

Completing a project controls maturity assessment for each element within each project promotes a healthy approach to project delivery and will minimize errors and rework. To complete this maturity assessment, organizations should look at all the components that make up project controls, which include the following:

Design of procedures, processes, and templates/forms, where the procedures, etc., are designed to fit both client and team needs for optimized performance. This maturity would include ensuring that the appropriate content, documentation, and interfaces are also provided.
Performers of the work content, where their skills, knowledge, and behavior support industry recommended practices and how their work affects project and organizational performance.
Owner of the work content, where they promote leadership and culture while applying the appropriate operational and organizational expertise and governance. These aspects would define the behaviors and actions of the executive leadership.
Systems Infrastructure, where the modular architectures adhere to industry standards so that the defined processes, procedures, and templates/forms could support decision-making, inter-enterprise communication, and project reporting.

Each component, as described, provides a crucial and supporting role, which complements the other components and the organization’s overall maturity. For instance, the team’s performance may falter without the robust design of procedures and processes. In some circumstances, strong performers can operate in an ad-hoc environment where they can use their wits and do what is necessary to try to make the project successful, but this can come at a cost. The success of a project should not hinge on one person and their experience but the overall maturity of the system.

For each component, a subset of specifications, deliverables, and expectations are required. It is through this subset of requirements that maturity is assessed. This assessment is completed by assigning objective levels to each specification and deliverable. These levels include the following:

Non-existent – No evidence suggests that a specific requirement is being met or where actual or present occurrence has happened. This exposes the business to undesirable financial, operational, or compliance-related consequences. Remediation will require addressing specific points of failure.
Inconsistent – The quality and/or use of a specific requirement is occasionally being met. This includes specific elements that are opposed to or do not match the defined requirements. There is evidence that failures occur in either understanding, execution, or the design of specific requirements. Remediation will require addressing general point(s) of failure and/or addressing requirements.
Consistent – The quality and/or use of a specific requirement is frequently being met, as defined by the minimum conditions of satisfaction, with few exceptions. Any exceptions are isolated, unlikely to reoccur, and do not expose the business to significant consequences.
Extensive – The quality and/or use of a specific requirement is extended to cover a complete and wide range of details. The requirements are comprehensive, understood by the users, and adhered to, with no exceptions.

To provide a deeper understanding for assessing maturity, organizations should first recognize industry best and recommended practices. For example, AACE’s Total Cost Management Framework provides the basis for establishing the functional requirements of cost engineering and project controls. AACE also provides a recommended practice, RP 11R-88, Required Skills and Knowledge of Cost Engineering, which can be used to define and assess the performers that provide the work content. Finally, AACE provides a recommended practice, RP 60R-10, Developing the Project Controls Plan. This RP can be used to assess the project controls readiness and preparedness prior to executing the work activities.

The following table provides an example of the sources required to support the elements within project controls. Furthermore, deliverables are also assigned to each element. While the list is not exhaustive and may be different for other organizations (i.e., owner organizations versus architectural/engineering firms versus constructors), it provides the basis and starting point for assessing the maturity of the deliverables. For instance, what is the maturity level of the project controls plan with the project within the organization? Is the deliverable non-existent or inconsistent? Maybe it’s consistently or extensively developed and used.

Table 1 – Deliverables for the Six Elements of Project Controls

The first step in achieving maturity is for the organization to develop and implement the recommended procedures and subsequent processes and templates/forms to ensure that the appropriate deliverables are being provided. The processes, along with authority/approval guidelines and user preferences, provide the basis for the modular architectures of the functional requirements that support the development and execution of the system infrastructure. The procedures also provide the foundation for establishing project control practitioners’ required skills and knowledge. The following list of procedures supports the development and implementation of the six elements of project controls[1]. This list of procedures will support the use and implementation of project control deliverables, i.e., templates/forms and work instructions. These procedures include:

Team development procedure
WBS development procedure
Project controls account development procedure
Estimate and budget development procedure
Schedule development and management procedure
Cost management procedure
Change management procedure
Progress measurement procedure
Performance assessment procedure
Forecasting procedure
Purchasing/contract administration procedure
Glossary of terms, acronyms, and formulas

Risk management procedure
Value improving practices (VIP) procedure
Accounting and invoicing procedure
Financial stewardship procedure
Contingency, escalation procedures
Claims and dispute resolution procedure
Project closeout procedure
Data collection and benchmarking procedure
Communication procedure
Systems integration procedure
Audit/compliance procedure

Now that the foundation is set, the organization can complete the maturity assessment to identify gaps and areas of improvement, as illustrated in Figure 2. This assessment can be completed against the functional areas within the six elements of project controls. Items like scheduling, estimating, risk etc. are considered functional areas.

Figure 2 – The Project Controls Process Map, AACE TCM Framework, 2^nd Edition, Page 53

The project controls process map is not inclusive of all the required deliverables. However, for illustration purposes, the process map does provide a visual understanding of where corrective actions can be introduced to assist in the refinement or development of particular deliverables that support the six elements of project controls. More discrete and measurable prerequisites will be required so that the organization can complete a detailed assessment for each process box within the project controls process map. Similar to the process map, the findings of the maturity of the discrete and measurable prerequisites can then be summarized and displayed in different ways to identify other areas where improvement is needed, as illustrated in Figure 3.

Figure 3 – Maturity Assessment Findings

Once the project controls elements have been developed, instituted, and communicated by the organization, project teams, once trained, can then begin to implement the deliverables for their respective projects. Audits on the completeness of the deliverables can then be completed to determine readiness to start the execution of the project. Consider this audit and readiness assessment as a pre-flight checklist. Pilots assess their specific requirements to ensure everything is in order prior to leaving for their pre-determined destination. The expectation is the project team completes this assessment prior to executing the project to ensure that their specific requirements are in order.

Once the project has started and is in the execution phase, the organization can attest to the compliance of whether the defined requirements for each element are being completed. This further allows the organization to ensure that the appropriate behaviors and performance are being administered. Figure 4 illustrates the compliance behavior of the elements identified in the project controls process map against the defined requirements. For instance, the project team seems to be struggling to complete the forecasting and change management requirements. This could jeopardize compliance in other areas, such updating the schedule and budget performance measurement baselines (PMBs).

Figure 4 – Compliance Behavior

The project team should investigate the non-compliances further and determine the reasons why the deliverables’ desired actions were not achieved. The following reasons have been provided as an example. Organizations may want to include more or different reasons why compliance is not being met.

SD = system or process has a structural/design issue
IR = insufficient resources to perform the activity as required
TK = lack resource training and/or knowledge
D = lack of discipline

Once the reasons for non-compliance have been identified, the project team can begin to introduce corrective actions to eliminate the possibility of any impacts that may occur. The project team may also want to assign a priority ranking to assist in expediting critical issues so that disruption to the project is minimal.

The six elements of project controls, complemented with a practical approach for determining project controls maturity, provides the organization an objective approach for assessing the completeness and readiness of the project controls deliverables. This also provides another step forward in effectively and efficiently managing the requirements and deliverables identified for advancing project controls.

A Primer for Claims and Disputes (Claims 101)

admin — Wed, 24 Aug 2022 15:18:20 +0000

A Primer for Claims and Disputes (Claims 101)

By John Ciccarelli, PE, CCP PSP FAACE

Introduction

The AACE International Claims & Dispute Resolution Subcommittee (“CDR Subcommittee”) is a group of professionals and experts actively involved in the preparation, analysis, management, mitigation, and resolution of claims and disputes on projects. The general purpose of the CDR Subcommittee is to provide a neutral, professional forum where professionals involved in the claims and dispute process can meet, discuss, and develop technical content about issues of common interest. These claims-related issues are typically focused on the analyses of schedule delay, disruption, and damages quantification, which also include assessments of entitlement and responsibility.

While the CDR Subcommittee is dedicated to claims and disputes, many of the other AACE International technical functional areas become a component of the various claims analyses. For example, some of the AACE technical subjects that are frequently addressed during a claims analysis include:

Contract Management
Cost Estimating
Decision and Risk Management
Earned Value
Planning and Scheduling
Project and Cost Control
Value Management

As such, it would be useful for practitioners in these subject areas to be more familiar with claims and disputes and how their work product could influence the analyses typically performed in claims on which experts often rely. The balance of this article serves as an introduction to and primer for claims and dispute resolution for professionals interested in this practice area.

Background

Claims and disputes are different albeit related issues. The definition for each term represents that a dispute is a general disagreement, while a claim involves a more formal process, including written demands. [1]

Dispute – A disagreement between the owner and the contractor as to a question of fact or contract interpretation which cannot be resolved through negotiations to the mutual satisfaction of the parties.
Claim – A demand or assertion of rights by one party against another for damages sustained under the terms of a legally binding contract. Damages might include money, time, and/or other compensation to make the claimant whole. Claims can also request relief from contract requirements (i.e., liquidated damages).

While the above definitions suggest the dispute or claim is between an owner and contractor, disputes often involve other parties, including designers, subconsultants, construction managers, subcontractors, insurers, and funding partners, among others. The nature and involvement of parties will be determined by the project delivery method and form of contract agreement. Examples of project delivery methods include design-bid-build, EPC, and design-build). Examples of contracts include variations of cost-plus fee and fixed price (i.e., guaranteed maximum price and lump sum).

An important document referenced in each of the above definitions is the contract, or the legal agreement between the parties. The contract typically includes the following types of documents: the agreement and addenda; general, special, and supplemental conditions; technical specifications, plans, and drawings; contractor’s proposal and bid; and other documents specifically referenced in the agreement. In a typical design-bid-build model for construction, the owner hires a designer to prepare the contract documents in accordance with industry standards. The owner then procures a contractor to construct the project as described in contract documents. Contractors bid on the project based on their planned project execution means and methods with the expectation that the design documents are complete and any material variations will be paid via change orders.

With respect to claims and disputes, there are key clauses, concepts, and requirements that the contract should address, and which project participants must read, understand, and follow. The clauses for these key subjects are usually found in the general conditions and include:

Changes/Claims – Understand the process for managing change orders and time extensions and the requirements for initiating the dispute or claim process, as well as escalating the decision. [2]
Time/Schedule Requirements – Understand the project milestones, applicable liquidated damages, “time is of the essence” or “no damage for delay” clauses, time extension analysis methodology, and the scheduling technical aspects, including requirements for critical path method (CPM) scheduling, baseline schedule, level of detail, relationships, float, activity coding, report preparation and formatting, and recovery scheduling.
Notice – Follow the contract requirements for notification when a potential change or event has occurred and any follow up actions. If a notification deadline is missed, a claim is at risk of being denied.
Force Majeure – Unanticipated events that impact the work and over which neither party has control, (i.e., acts of war, weather, strikes, and other events specified in the contract).

Disputes and claims typically arise when a change is encountered within the context of the contract and the parties cannot come to an agreement on the issues being negotiated.

Causes of Claims and Disputes

Disputes and claims can be caused by numerous reasons, including but not limited to:

Scope/Unresolved Changes
Differing Site Condition
Restricted Site Access
Design Errors and Omissions
Revised Regulations
Incomplete or Late Design
Ambiguous Documents (Spearin Doctrine)
Unusually Severe Weather
Added Work by Owner
Delays in Owner Procured Items
Low Productivity/Cumulative Impact
Owner/Inspector Interference
Work Suspension
Acceleration (Constructive)
Interference by Other Trades or Contractors
Third party (Utility) Interference
Shortage of Skilled Labor
Contractor Performance (Workmanship, Quality)

As a result of one or more of the above-listed causal events, a contractor might believe that it is entitled to additional compensation and/or time. The contractor requests a change order, variation order, or a request for equitable adjustment (“REA”). On the other hand, the owner does not believe the contractor is entitled to the change and denies the request or makes a counteroffer. At this point, the contractor can then file a claim and proceed with the matter through the dispute resolution process detailed in the contract

Typical Claim and Dispute Resolution Process

Most contracts provide a process for initiating and resolving disputes including the venue, jurisdiction, and forum for conducting proceedings. In general, the processes include a decision maker and can be categorized into a self-decided group or adjudication.

The decision maker concept typically involves the designer as an initial decision maker on a submitted change order or disputed issue on the project.
The self-decided group of dispute resolution processes are typically resolved at the project level in which the parties have a say in the decision. These options include:
- Avoidance – most, if not all avoided disputes become bigger problems and do not self-resolve.
- Negotiation – between the parties and involves only the parties. Negotiations at the project level can be casual — conducted through conversations, emails, texts, and phone calls, or can be formal with meetings, documentation, and presentations.
- Mediation – parties voluntarily bring in a respected, neutral, uninvolved third-party to facilitate reaching a mutually acceptable resolution. Mediators do not decide or rule on the matter, but instead work with the parties to facilitate an agreement.
- Dispute Review Board (DRB) – typically a process defined in the contract, with three neutral members on a panel who decide on disputed project issues in a timely manner. The DRB members conduct regular site visits and hearings as needed.
The adjudication group of dispute resolution processes are those in which someone else decides the fate of the matter. The adjudication options include:
- Arbitration – the submission of a dispute to one or more impartial persons (typically familiar with the construction industry) for a final binding (sometimes non-binding) decision on the case, known as an “award.” The awards are usually made in writing.
- Litigation – the claim is brought before a federal or state agency in the form of a lawsuit and is adjudicated in a courtroom with a judge and/or jury decision in a trial. This process can be long and slow, with exposure to appeals.

Regardless of the dispute resolution process method used, the practices to manage, document, demonstrate entitlement, analyze, and quantify claims are similar. As discussed earlier in this article, the contract should identify required information to be submitted with a change order or claim, including a time impact analysis and detailed cost records. Failing to follow the process can result in losing the opportunity for recovery.

Elements of a Claim

Generally, it is the claimant’s responsibility to prove a claim. AACE International Recommended Practice (“RP”) 120R-21, Demonstrating Entitlement for Contract Change Orders or Claims – As Applied in Engineering, Procurement, and Construction, is a primary technical resource that addresses necessary elements to determine technical entitlement and provides guidelines concerning the various elements to be considered for use in developing a change order or claim. As such, a change order, variation, claim, or REA submittal package should include and address the following elements:

Establish Entitlement – Entitlement has two perspectives: legal and technical.
- From a legal perspective, first and foremost, counsel should be consulted to frame the challenges and requirements for establishing entitlement to reimbursement for the disputed issue. Claims practitioners should understand and consider a disputed issue in the context of the contract, applicable laws, regulations, notice provisions, and the dispute resolution process.
- The technical perspective of a disputed issue considers the contract scope of work to confirm the issue was out of scope or was a change order. Most contracts identify the required technical material and analyses to accompany a claim submission and calculate additional time and costs (i.e., supporting analyses, cost support, and documentation).
Demonstrate Causation and Responsibility – this element should be the most technically focused effort to develop various cause and effect analyses to establish the causal linkage (nexus) between facts and events and the impacts in dispute. These analyses can include forensic schedule delay, loss of productivity (resulting from disruption), damages quantification, and other technical demonstrative analyses.
- Forensic Schedule Delay – disputes often include an element of delay, or an event or issue that “cause the work or some portion of the work to start or be completed later than planned or later than scheduled.” [1] A claim would be asserted for impacts that resulted in additional time that could increase the project duration, usually resulting in additional costs to both parties.

AACE International RP 29R-03, Forensic Schedule Analysis, is a primary technical resource that addresses the delay element of a claim and provides guidelines to the industry for the application of CPM scheduling in forensic schedule analysis to measure delay (including disruption and acceleration) and identify effected activities to focus on causation. The protocols detailed in RP29R-03 consider numerous factors, including:

As-Planned Baseline Schedule
Contemporaneous Schedule Progress Updates and Re-Baselined Schedules
Nine Method Implementation Protocols for Analysis
Concurrent Delay
Critical Path and Float
As-Built Data
Factors for Choosing a Method

Overall, a forensic schedule delay analysis will determine whether a delay was excusable or non-excusable, and then if excusable, whether the delay is compensable or non-compensable.

Loss of Productivity – another element of disputes and claims, tied to both delay and damages, is an assertion for impacts resulting from loss of productivity (“LoP”). Claims for LoP can be contentious, and the effect on cost and schedule difficult to identify and quantify. Often, LoP occurs as the result of a disruptive event or series of events. Disruption is defined as “[…] an interference (action or event) with the orderly progress of a project or activity(ies) […] the effect of change on unchanged work and manifests itself primarily as adverse labor productivity impacts […].” [1]

AACE International RP 25R-03: Estimating Lost Labor Productivity in Construction Claims is a primary technical resource that addresses the LoP element of a claim and provides guidelines to the industry for the application of analyses related to capturing the effect of LoP on cost and schedule. The methods detailed in RP25R-03 consider numerous factors, including:

Industry definitions of productivity (i.e., rate of production; output per unit of input) and LoP (actual productivity is less than that which could have been achieved under as-planned normal working conditions).
Common causes of LoP.
The project control records that are available, specifically for labor and quantities installed, to facilitate selecting an estimating method; and
The various analysis methods employed, including project specific analyses (i.e., measured mile, earned value analysis, direct observation), specific industry studies (i.e., acceleration, overtime, cumulative impact, and weather), and general studies (i.e., MCAA, Construction Industry Institute, Leonard Study), and cost-based methods.

There are other technical demonstrative analyses that are used to establish causation of events to delay, disruption, and damage impacts. Depending on the type of data available in the project file, the following are example topics can be analyzed to support a claim:
- Change Orders – the timing, frequency, and magnitude of approved and rejected change orders.
- Shop drawings – the timing and approval turn-around, design revisions or scope creep, and recycle of submittals.
- Requests for Information (“RFIs”) – timing, frequency, disposition, and response time for RFIs and other design revisions.
- Quality – tracking workmanship and rework of scope (i.e., welding).

These analyses are often conveyed in tables, charts, graphics, and other illustrations to communicate the findings and demonstrate the causal nexus to the impact events in dispute.

Quantify Damages – the culminating element in a claim is the quantification of damages that represent the additional costs incurred by the claimant resulting from the impact event. The claimed amounts to be considered as damages for reimbursement can include:
- Remaining unpaid contract balance and change orders (approved and un-approved), which may be comprised of direct project costs for labor, material, equipment, subcontractors, and consultants.
- Time-related indirect project costs for general conditions (i.e., field supervision, field office, trash, utilities, etc.).
- Home office overhead costs for home office staff, expenses, travel, legal, depreciation, and other corporate costs that were not directly allocated to the project.
- Interest, insurance, bond. And,
- Markup for profit.

The choice of a damage quantification methodology can be influenced by the available project records and data. Triers of fact have generally established that discrete approaches are more accurate and effective than the other cost-based methods. The damage quantification methodologies to be considered include:

- Discrete, project specific approaches, which can involve and rely on preparation of specific estimates for changes or extra work, a LoP analysis (i.e., measured mile analysis), “should have” cost estimates, earned value analysis, and industry standards (factors) and handbooks.
- The cost-based methods, while typically less accepted because of certain flaws, include the total cost method, modified total cost method, and quantum meruit approach.

Documentation – the last, but definitely not least, underlying element to any dispute and claim is documentation. Supporting documentation is vital to each of the aforementioned elements and to developing a comprehensive and unimpeachable change order or claim submission. When a problem event emerges, it is a best practice to immediately document the issues, events, and facts through written notification while also collecting (or continuing to collect) relevant data. A dedicated file should be built, and cost account assigned for the issue and impacts inserted into the schedule as applicable.

Preparing the Claim

When a dispute transitions into a formal claim, there are additional parts of the process to understand while preparing to submit the claim. The process for finalizing and submitting a formal claim should consider:

Understanding and adhering to contract claim requirements and deadlines. This includes preparing a timeline for development and filing the claim.
Understanding the audience and venue for the dispute resolution proceedings.
Drafting a narrative to articulate claim; confirm entitlement; demonstrate causation through forensic schedule, loss or productivity, and other technical analyses; and quantify damages.
Engaging or consulting with counsel and an expert claims consultant experienced with construction disputes.
Collecting, assembling, and preparing support documentation for the discovery and production process, including electronically stored information (“ESI”).

Conclusion

This article introduces the general concepts associated with claims and dispute resolution, the subject matter in which the CDR Subcommittee specializes. The goal is to provide various other AACE technical subject practitioners perspective into the claim process so they can better understand the influence that their work product could have on the various analyses typically performed in a claim and on which experts often rely. If you have interest in any of topics addressed herein, please reach out to CDR Subcommittee members or check the AACE Resource Library for technical papers and recommended practices published under the CDR Subcommittee banner.

REFERENCES

AACE International, Recommended Practice 10S-90, Cost Engineering Terminology, AACE International, Morgantown, WV.
AACE International Recommended Practice 100R-19, Contract Change Management – As Applied in Engineering, Procurement, and Construction, AACE International, Morgantown, WV.

Life Cycle Costs for Environmental Projects

admin — Thu, 23 Jun 2022 04:05:00 +0000

Life Cycle Costs for Environmental Projects

By Dan Melamed, CCP EVP FAACE
Member AACE Technical Board
National Capital Section Director

The cleanup of contaminated sites involves removing hazards to human health, safety, or the environment from specific building(s) and/or a parcel(s) of land that includes contamination that may have spread to surface and/or groundwater. The nature of this is fundamentally different from most other capital asset projects in many aspects. For capital asset projects, project teams analyze the capital costs of facility planning, design, and construction through start-up of an asset combined with the costs to operate, maintain, and eventually dispose of the asset to give the total cost of ownership of the asset. This analysis is called the life cycle cost analysis (LCCA). However, the analogous LCCA of environmental restoration projects operates from fundamentally different perspective from capital assets (discussed below)

The environmental cleanup is not generating an asset but eliminating a liability;
The understanding of the site’s scope, compared to other industries, has a high degree of uncertainty.

An environmental cleanup follows a distinct sequence of phases (shown in figure 1, which show the life cycle of an environmental project through six phases. (1)

Figure 1–The Six Phases Required to Complete an Environmental Project combining to provide a life cycle cost.

In many (if not most) cases the environmental cleanup is driven by a legal and regulatory framework. It is worth noting that as an example the Comprehensive Environmental Response, Compensation, and Liability Act (CERCLA) requires a life cycle cost analysis in order to compare remediation alternatives. Although this is a formal requirement for CERCLA, its general utility for general best practices is directly aligned with best practices for general project and program management. The driver for the environmental legal and regulatory framework is protection of human health and the environment. Therefore, there must be a balance between cost effectiveness with protecting both human health and the environment throughout the life cycle of environmental remediation. Also, as stated above, there are significant uncertainties to environmental cleanup projects. The specific extent and nature of the contamination is almost always uncertain. The dispersion and transport of these contaminants through the environment (even after initial characterization) which can be defined but are difficult to accurately predict quantitatively.

Despite the fundamental differences between the constructing, operating and the eventual disposal of a capital asset and an environmental cleanup, the methods for developing a life cycle cost analysis are the same. Both evaluate a series of approaches to either develop an approach to develop a capital asset or (as discussed in this paper) develop a technological approach for cleanup. The methodology is to account for the time value of money, that is, the variation in the cost of an expenditure due to its timing and the specific nature of the expenditure. This well-established methodology to convert future lump sum values, a uniform series of future values, or an incremental series of future values to a present value. Ultimately one should use the same general methodologies which apply to all industries. (2) These steps are listed below with some considerations for projects in the environmental remediation industry:

Define the cleanup project requiring LCCA. This step involves characterizing the contaminated site. Identify the potential time periods to be considered in the analysis. Identify the appropriate financial or other criteria upon which to base a necessary course of action. This includes necessary actions (including possible short term removal actions) to contain the further spread of contamination.
Develop potential alternatives/solutions to consider in the analysis. For this step past experience determines viable technology approaches for the cleanup work. These should be built upon available past experience(s) of previous cleanup activities for similar sites that best address both the nature of the contamination (e.g., radioactive and/or toxic metals) as well as the medium (e.g., concrete for a building, versus clay and/or sandy soils) as well as whether the contamination has migrated (e.g., whether the contamination had traveled to adjacent properties, etc.
Develop/use an appropriate cost breakdown to support the analysis. The cost breakdown structure for this analysis needs to be based on the environmental industry’s unique requirements including acquisition costs (e.g., planning, procurement, construction) and sustaining costs (e.g., operating costs, utility costs, maintenance costs, repair costs, etc.). A good example of a cost breakdown structure for environmental projects is the Environmental Cost Element Structure (ECES) a comprehensive, hierarchical list of cost elements (tasks, items, or products) that may be required to complete an environmental project. (3)
Collect data and information to support the required cost and benefit values for each alternative information to determine reasonable estimates for all stages of the remediation.
Prepare the cost profiles for each alternative
Analyze results. Analyze the results for the top four to six alternatives, including the preferred alternative, in a formal document(s). Continuing with the example (discussed above) in a CERCLA project this step is entitled the Remedial Investigation/Feasibility Study. (RI/FS).
Communicate results and determine the course of action. In the case of a CERCLA project, the RI/FS report is distributed with stakeholders (including regulators). Based their review of these documents (including stakeholder input documented at public meetings) a selected remedy is summarized in the record of decision.

The following is an example of a detailed discussion showing a comparison of alternatives on a life-cycle cost basis. [4] There are two possible remedies for the treatment of buried waste:

Contain the contamination on- site and leave it in place; versus
The complete removal and disposal of the contamination off-site

Containing the contamination and leaving it in place may have a lower initial cost compared to excavating, characterizing, transporting and disposing of the waste. However, the first remedy requires an engineered cap to prevent migration as well as continued monitoring of groundwater for an extensive period to detect any migration of contamination or changes in contaminant concentrations. Therefore, life-cycle costing can accurately compare these cleanup alternatives.

Another challenge in a LCCA for an environmental project involves calculating long term surveillance and long-term maintenance (SLTM) (also referred to as long term surveillance or long-term stewardship), shown as Phase 6 of Figure 1. These activities may last for many years. Although these costs are often accurately estimated. However, very often there is uncertainty as to how many years these activities will need to be performed, creating uncertainty in the estimated costs for this phase.

A life cycle cost analysis is a critically important requirement for the selection of a remedial alternative and development of an environmental remediation project. Very often the conduct of the LCCA process can help the project team to provide a full understanding of the engineering and technological challenges faced by environmental cleanup projects.

Disclaimer: The content provided by the author of this article is his own and does not necessarily reflect that of their employers, unless otherwise stated.

References:

AACE International, Recommended Practice No. 107R-19: Cost Estimate Classification System – As Applied in Engineering, Procurement, and Construction for the Environmental Remediation Industries, Morgantown, WV: AACE International, Latest revision. Pages 4-7.
Larry Dysert. Life Cycle Cost Analysis Source, No. 06, AACE International, Morgantown, WV, December 2018. Pages 6-7.
ASTM E2150-17, Standard Classification for Life-Cycle Environmental Work Elements-Environmental Cost Element Structure, ASTM International, West Conshohocken, PA, 2017, www.astm.org (with Adjunct E-2150A, which provides Environmental Cost Element Structure at Levels 3, 4, and 5 with Definitions).
A Discussion of the Cost Estimate Classification System: As applied in the Engineering, Procurement, Construction and Operations for the Environmental Remediation Industries, Dan Melamed, CCP EVP; Bryan A. Skokan, PE CCP; Gregory Mah-Hing, PE; Rodney Lehman; Jake Lefman, 2020 AACE International Transactions, EST-3542, AACE International, Morgantown, WV, 2020. Page 8.

Why is a Basis of Estimate Necessary?

admin — Tue, 12 Apr 2022 07:41:00 +0000

Why is a Basis of Estimate Necessary?

By Larry Dysert CCP CEP DRMP

Cost estimates are prepared to support decisions. At an early stage of project development, the decision may be to decide which potential alternative (or alternatives) should be selected to advance to the next stage of development; and eventually the decision may be to authorize full funding of a project based on the economic analysis and business case that has been prepared based on a project estimate.

Most, but not all projects, are approved based on economic evaluations. Organizations attempt to maximize the value of their capital investments, seeking to fund from their limited capital budgets those projects that provide the highest rates of return. The cost estimate is critical to the economic evaluations determining rate of return and other financial metrics upon which a decision will be made.

A decision can be made using a reasoned or intuitive process, and most often a combination of the two. Reasoned decisions are those established on objective assessments of all of the available facts and information. Intuitive decisions, on the other hand, are often based on past experience, and the personal perceptions and values of the decision-maker.

In making capital investment decisions, organizations want to make reasoned decisions that are founded on comprehensive, clearly understood data and information. The estimate is an important component of that information, but if the estimate is presented as just a page of numbers then it provides no context to support its evaluation, and the subsequent decision to be made. A page of numbers or a bottom-line estimate value by itself cannot support reasoned decision-making.

The Basis of Estimate (BOE) is the document that provides the contextual framework for using the estimate to support reasoned decision-making. AACE International Recommend Practice 10S-90 defines a basis document as, “written documentation that describes how an estimate, schedule, or other plan component was developed and defines the information used in support of development. A basis document commonly includes, but is not limited to, a description of the scope included, methodologies used, references and defining deliverables used, assumptions and exclusions made, clarifications, adjustments, and some indication of the level of uncertainty.”^[1]

AACE International Recommended Practice 34R-05 states that when prepared correctly “any person with capital project experience can use the BOE to understand and assess the estimate, independent of any other supporting documentation. A well-written BOE achieves those goals by clearly and concisely stating the purpose of the estimate, (i.e., cost study, project options, funding, etc.), the project scope, pricing basis, allowances, assumptions, exclusions, cost risks and opportunities, and any deviations from standard practices”_[2]

Todd Pickett, in Preparing a Basis of Estimate, identifies that the “basis of estimate is the instrument used to convey to the owner and other members of the project team that the estimator understand the problem, the proposed solution, and how much the proposed solution is going to cost.”^[3]

It is important to understand that an estimate is a prediction of the probable costs for a given scope of work to be completed in the future. An estimate by nature is uncertain, and although some of the information supporting the estimate is objective and factually based, much of the estimate is based on uncertainties that includes potential variations in scope quantification, pricing, required resources, execution strategies, etc. Every estimate is based on an extensive level of assumptions upon which the estimator must make an objective assessment to prepare a cost estimate that is comprehensive, reasonable, and sufficiently accurate to support the purpose and decision for which it is being prepared. Whether it meets these goals cannot be determined from the numerical presentation of the estimate.

The Basis of Estimate provides context to the methods, practices, adequacy of the information and assumptions utilized in the development of the estimate. It provides thorough and reliable information to support effective estimate review and validation; and once approved can then be used to support sound business decisions for capital investment decisions. An important part of estimate validation and subsequent support for the investment decision is to understand the explicit or inherent cost strategy (cost effectiveness versus predictability) that may impact the eventual achievability of the estimate.^[4]

The BOE is equally important for effective project controls, from establishing initial work packaging and contract management to supporting performance assessment and change management. It supports effective project schedule development and control. It provides the needed framework to understand the combination of identified scope and costs included in the estimate. AACE International’s Total Cost Management Framework identifies the Basis of Estimate as a required component of every cost estimate.^[5]

To summarize, the main purpose of cost estimates is to support decisions to maximize the value of an organization’s capital investments. Without a Basis of Estimate, the decision maker must rely on an intuitive approach to decision-making. A well-written Basis of Estimate allows decision-makers to make reasoned and informed decisions, reducing the level of intuitiveness, to maximize cost investment performance for their organizations.

REFERENCES

AACE International, “RP 10S-90,” AACE International Recommended Practices, October 10, 2019.
AACE International, “RP 34R-05: Basis of Estimate,” AACE International Recommended Practices, May 2, 2014.
Pickett, Todd, “Preparing a Basis of Estimate,” 2005 AACE International Transactions, EST.10, 2005.
Hollmann, John K., “Estimate Validation and Bias Assessment: Ratio to Driver Method,” 2019 AACE International Transactions, EST.3184, 2019.
Stephenson, H. Lance, Editor, “Total Cost Management Framework,” 2nd Edition, 2015.

Apathy is the Enemy of Excellence

admin — Tue, 15 Feb 2022 18:41:43 +0000

Apathy is the Enemy of Excellence

By Richard Plumery

My group recently conducted a survey on some topics and received some very pointed comments from several of those who were surveyed. We knew we had some gaps in the areas they brought forward but leadership still felt a bit taken back by the harshness of some of their comments. My response to them was “Apathy is the enemy of excellence”. If we want to raise up to the desired level of excellence in those areas, we should be happy to hear that our employees are so passionate and so engaged and so comfortable providing that type of feedback. I worry more when I hear that employees are just numb to change or issues that make their work more difficult because you never know their true level of engagement in their work products. I often make the statement “you can’t check quality into the work.” The individual(s) executing the work products must have the right aptitude and attitude (engagement) to produce the desired results. Many things in our industry make it tough to accomplish the desired level of engagement from our workforce.

First, we have an ever-widening experience gap as our aging demographic continues to pull more and more talent over the retirement cliff. Those retirees had a different perspective, experience and work ethic in their earlier years than most of our incoming employees. The newer employees by and large, have a healthier and more sustainable balanced approach to their desired work/personal life ratio. They also have less tolerance for inefficiency and are happy to voice their opinion. They are used to super speed apps on their latest model mobile phone and are disappointed when anything takes longer than 30 seconds to load. They have high expectations which is great for improving things. Apathy sets in when they are bored with the inefficiencies.

Second, we don’t offer the right career and growth paths for the changing demographic. We often stifle the newer employees with artificial ceilings based on old business rules. “you can’t be this until you have had this many years doing this and this” which turns them right to being apathetic as they wait their time out in an industry that is not nearly as sexy as many other industries their peers are getting into elsewhere. This also may explain why we have such a dip in STEM kids. That only appeals to certain kids and that pool is shrinking.

Lastly, we tend to put too much bureaucracy in place with endless policies, procedures, etc. to attempt to corral everyone into what we desire based on our current knowledge and preference for doing things. That often suffocates innovators and problem solvers by putting a fence around everything until they become apathetic. Nobody wants to be like everyone else. Everyone wants recognition but not necessarily for conforming but more likely for taking things to new levels.

This is not an easy fix for our industry. We tend to continue to do the same things again and again no matter the outcomes. We can’t say we are taking great leaps in areas like earned value or sanctioning project estimates because we see them fail time and time again due to known gaps. We need to begin an era of enabling and empowering our employees to allow them to take their incredible knowledge and innovate and build upon the strong foundations that have existed but have not been perfected.

To do this we must enable them with the abilities to learn quicker and in different environments such as simulations, since I also say “you can’t train experience” and as the aging experienced workforce retires they must be prepared to take the reins. Mentoring can be an effective tool as well. Having experienced people walk alongside less experienced people can yield better results if the mentor is willing to encourage the mentees and not lead them to ways of the past that have not been effective.

We must also enable and encourage innovation. Innovation is exciting and can lead to much better engagement with the new generations of project controls professionals. Innovating is what really began my re-engagement with this industry after several years away being involved in entrepreneurial ventures because it allowed me to bring something new to the industry. I dove into fixing the numerous gaps in earned value approaches. I looked at gaps such as performing out of sequence work or meaningless work to get enough credit to mask work delays or inefficiencies. That had troubled me for years and I was so excited when I figured out the corrective measures and changes needed. That fueled my fire and pushed me to write my first technical paper. It was not great writing but a very well-respected reviewer from the AACE Technical Board who was known to be very tough on paper reviews provided me a great deal of encouragement about my new approach. His words engaged me and made me want to do better. Then another AACE legend read my published paper and provided me with even more encouragement which spurred me on to join the technical board. Later as we implemented my approach on more and more projects I continued to modify and add to the original innovation.

This experience rejuvenated me to deploy more of my ideas into how I managed and led my staff. I became passionate about improving how we lead our staff and project teams. I became a servant leader who now enables, encourages and empowers. I provide my teams the resources, systems and tools to do their work more effectively. I work at this every day passionately in order to improve everyone’s experience at work while still having enough guiderails installed to protect the business. We have such a large and diverse business that leading and improving is a constant demand. I am lucky to have leadership above me that has allowed me to implement my approach across our project delivery business. They now hear and see the results and that fuels my fire even more. I want to rid the business and our industry of our common enemy “apathy” and move us all towards excellence. Having an enabling, encouraging and empowering leadership approach is key to realizing that goal.

Part 2 – Six Elements of Project Controls; Quality

admin — Wed, 08 Dec 2021 17:22:56 +0000

Part 2 – Six Elements of Project Controls; Quality

By Lance Stephenson, CCP FAACE

In August 2021, I provided a short article on the six elements of project controls. The previous article provided a summary overview of the elements required for successful project delivery. In today’s article, I will briefly discuss the quality measures required to further support the value that the six elements of project controls bring to an organization. This article also discusses the impact that errors have on impeding project success, and that errors in project controls can cause a cumulative effect with respect to the downstream problems that can occur if not adequately and timely identified and addressed.

To briefly recap, the six elements of project controls can be considered the operational steps for managing the functional project controls requirements within a project. These six elements also relate to the project controls processes within AACE International’s Total Cost Management Framework. The six elements of project controls are represented in Figure 1. The bubbles in the diagram represent the six elements while the information provided above and below the arrows represent the key deliverables and measurements.

Figure 1 – Six Elements of Project Controls

Quality is simply defined as the degree of excellence; a grade; albeit a subjective grade as defined by Webster’s Dictionary, https://www.merriam-webster.com/dictionary/quality. In this particular case, I will be discussing the quality of project controls work required to properly execute a project, and not the end-quality of the physical elements of a project. With this said, work quality is considered the value of work delivered by an individual, team, or organization. This includes achieving the following features for any tasks or deliverables.

Fit for purpose – where the task or deliverable meets its defined purpose, function, and standard as defined by industry best practices, contracts, policies, and procedures. This includes attaining the required level of detail and thoroughness that meets the complexity, criticality, and urgency of the project. Establishing “fit for purpose” for project controls deliverables can be the most difficult and ambiguous characteristic to determine, as organizations and people within the food chain of project delivery will interpret requirements differently (a client may require a level 2, cost loaded schedule while the contractor may require a level 3, resource loaded schedule).
Conformance to requirements – where the criteria of the required specifications are met.
Correctness and completeness – where the task or deliverable are considered error-free and there are no missing parts.
Consistent, accurate, and timely – where the task or deliverable is completed in a consistent (standard approach), accurate (validated), and timely matter (desired frequency).

In a perfect world, we would expect that the highest quality should be achieved. However, we don’t live in such a world. While it is good business to strive for attaining the highest level of quality, there is a cost in doing so. Equally so, there is a cost when poor quality is ignored, and errors occur. These two quality factors, good and poor, are identified as the cost of quality. The cost of good quality is comprised of both prevention costs (costs incurred specifically designed to prevent poor quality) and appraisal costs (costs incurred to maintain quality levels, i.e., measure, inspect, evaluate, and audit). The cost of poor quality is comprised of both internal failures (re-work, improper use of processes, ineffective training, and poor productivity) and external failures (costs associated with defects).

The cost of quality is represented in Figure 2. By properly injecting costs to increase measures that prevent errors, the cost of failures and appraisals are greatly reduced. The total cost of quality is displayed similar to the bathtub curve, which does not depict the costs of a single item but represents the relative costs of both good and poor quality.

Figure 2 – Cost of Quality Concept (AACE International’s TCM Framework, 2^nd Edition, page 125)

The purpose for achieving a higher level of quality, specifically around project controls, is to improve the decisions made as the project progresses from planning to execution. To assist in understanding the effect quality has on project, the stock and flow diagram within a systems dynamic model is used as an example. For the purpose of this article, a simple illustration of a stock and flow structure of the systems dynamic model is provided to demonstrate the cause and effect of quality, errors, and rework that can contribute to chaos and unpredictability within the project controls domain. This influence of the systems dynamic model is not presented.

System dynamics models are continuous simulation models using hypothesized relations across activities and processes. For instance, the lack of skills and knowledge of project controls, scope of work ambiguity, or even workload can affect the quality of the deliverables. These models can also validate that the processes will meet the expectations of functionality and maintainability while addressing all the key risk areas. Figure 3 represents an example of the typical project stock and flow structure of a system dynamics model. As presented in Figure 3, the traditional sequence of a project is to identify the work to be completed, the work in progress (execute the work), and identify the work that has been completed.

Figure 3 – Project Stock and Flow Structure of a System Dynamics Model

It is expected that the work accomplished will be completed error-free. If the tasks are done incorrectly, errors are generated, creating rework loops. This concept is illustrated in Figure 4. Once an error has been discovered, rework is allocated, assigned, corrected, and completed.

Figure 4 – The Rework Cycle (See Applying Earned Value Management to Design-Bid-Build Projects to Assess Productivity Disruption, Dr. Stephen P. Warhoe, Page 187)

If an error is identified within one or more of the six elements of project controls, the rework cycle is activated. Figure 5 illustrates the rework cycle that is nested between the elements know what has to be done and know what has been done.

Figure 5 – Rework Cycles within the Six Elements of Project Controls

As depicted in the figure, an error in the estimate was identified, triggering the rework cycle. The estimate is considered one of the key deliverables for developing the performance measurement baselines (PMB’s) of the first element, know what has to be done. If this deliverable is incomplete or done incorrectly, there is a compounding effect to the overall quality. For instance, for the schedule to be correct and complete, the estimate needs to be correct and complete. These two deliverables (among the other planning deliverables identified in the project controls process map of the TCM Framework) are simultaneously involved in an iterative, concurrent process. If the estimate is incorrect, then the resources required to complete the work would be incorrect. Incorrect resource assignments would affect the activity durations and the subsequent timing of the starts and finishes of activities within the schedule. This in turn would misrepresent the need for when work is to be executed and procured items to be delivered, etc.

Other considerations are when errors are not identified in a timely fashion, or not found at all (i.e., undiscovered rework. Undiscovered rework is considered unidentified information. Such information will exist and would be relevant to the project team, however, the specifics of the rework are completely outside of their scope of awareness). These situations could reduce the credibility, integrity, and trust of both the individual and data. As a result, the decision makers may start collecting their own data (in an effort to reduce misinformation), which could be more disastrous to the outcome of the project. This outcome would also add unwanted conflict and disfunction amongst project team members and possibly, the client.

Ultimately, if any information is incorrect, incomplete, and not identified in a timely fashion, a cascading or ripple effect to other activities will occur. This is because almost every task or deliverable within each of the six elements of project controls has a causal relationship between the other elements, which can directly or indirectly affect downstream activities. A causal relationship exists when one variable in a data set has a direct influence on another variable. This creates a more pressing issue as decisions are based on the perception that the information is timely and correct. If the basis for one decision is incorrect, based on these causal relationships, the basis for a subsequent decision will most likely be incorrect. If not identified and corrected, one error can lead to another, bigger error, which can lead to a compounding effect of errors. When this situation occurs, organizations struggle with the ability to identify, prioritize, and focus on corrective actions. This further introduces the dangers of doing too many things at once, paralyzing their efforts. Chaos ensues. What was once a simple project has now turned into a complicated or overly complex one. In some cases, the project has failed before it has even started.

In order to prevent quality issues within the project controls domain, the causal relationships between the six elements are identified in the following diagram, Figure 6. This diagram is considered a static design structure matrix, which provides a simple representation of the complex system of project controls. The matrix is a two-dimensional matrix that identifies the primary variables (i.e., six elements) along the left side and top of the matrix (e.g., know what has to be done = 1, etc.). Reading across the element row and then scanning down the column based on the arrows identifies the relationship to the other elements. For instance, the quality of element 2, know what has been done, is dependent on the quality of element 1, know what has to be done. Subsequently, the quality of element 3 is dependent on the quality of both elements 1 and 2.

Figure 6 – Matrix Relationships of the Six Elements of Project Controls

Understanding causal relationships via the static matrix as illustrated can have a profound effect on the decision-making process, and ultimately, the success of the project. Decisions that are made without consideration of these causal relationships will only compound and exacerbate the situation. These wrongful decisions can have a major influence on the project’s remaining work, creating further obstacles that would limit success. As an example, a project team received information that identified the rebar installers were performing at a favorable rate in one specific work area. A decision was therefore made to move some of these installers to another work area that was trending behind with respect to productivity and schedule expectations. Unfortunately, the information received by the decision makers was in fact incorrect, and the installers that were thought to outperforming expectations were actually underperforming in the first specific work area. As a result of removing some of the workers from the first area, it was placed in further jeopardy of being completed on time. As a result of the decision that was made, and in an effort to regain lost time, the management group decided to increase resource labor (more installers) and extend workday hours (overtime). These decisions introduced fatigue, congestion, and safety issues, which lowered productivity rates even more, and increased risks and costs. These decisions negatively impacted downstream activities.

So, what can we do to minimize errors that may occur during the planning and execution of a project? First, organizations need to comprehensively evaluate the quality of the deliverables to determine where these errors may occur. The following table is an example of a quality audit that was performed on element 1, know what has to be done. Areas of improvement are identified so that the project team can introduce corrective actions. For instance, the schedule met the expected standard for fit for purpose (the schedule was developed at the appropriate level). However, improvement was needed to ensure that the schedule was in conformance to requirements (the schedule was technically sound but not resource loaded) and consistent, accurate, and timely (the schedule was not validated). Finally, the schedule was deemed unsatisfactory as it was not correct and complete (where it was identified that there was missing scope and subcontractor work, which put the critical path into question). Completing a project controls attestation at the beginning and during the execution (for each element within each project) promotes a healthy approach to project delivery and will minimize errors and rework.

Table 1 – Example of Quality Assessment Table

Second, the organization should identify any systemic issues that are prevalent within their respective project delivery systems. Systemic issues are flaws that are inherently due to the background conditions in the overall system itself. A change to the structure, organization, or policies could alleviate the systemic issue(s). The following are high level systemic issues that have caused errors and rework that have plagued many organizations.

Management Issues – looks at project controls as a cost rather than a value, undermines the ability to introduce effective and efficient personnel, processes, and systems; lack of proper and functionally accountable management and supervision, poor coordination or unclear instructions to team members.
Personnel-Related Factors – lack of experience and knowledge of the project controls process, lack of proper involvement in the project, inadequate briefing and communication with project team; lack of funding to provide the appropriate surveillance and governance (not part of the project estimate).
System-Related Errors – lack of a mature project controls ecosystem that provides timely information; diminishes the project controls efforts to data collection and reporting, creating an inability to analyze the information; outdated or poorly working tools such as software and hardware.
Process Related Errors – inferior workflows, role assignment, and approvals, which hinder the decision-making process. Improper project set-up, from defining the WBS to onboarding personnel and contractors.

While the list provided are just a few of the main areas where systemic issues occur, organizations should complete a deeper investigation to determine the specific root causes that inhibit their successes in project delivery.

The function of project controls is simple but complex, yet essential for project success. The function of project controls is basically a large math exercise comprised of equations and algorithms, probabilities and what-if’s, complemented with relationships and interdependencies. How we manage this exercise within the six elements of project controls will determine the number of errors and rework that may occur.

Part 1 – Six Elements of Project Controls; The Basics

admin — Tue, 31 Aug 2021 16:44:54 +0000

Part 1 – Six Elements of Project Controls;
The Basics

By Lance Stephenson, CCP FAACE

In February 2021, I provided a short article on recommended practice (RP) 60R-10, Developing the Project Controls Plan. When I first authored the RP in 2010, I wanted to describe the project controls planning elements based on the Total Cost Management (TCM) Framework. I also briefly touched on the operational aspects of the six elements of project controls within the RP. These six elements of project controls include:

Know what has to be done

Know what has been done

Know how actual performance compares with the baseline

Know what remains to be done

Identify and implement corrective actions to bring performance in line with expectations

Check results of corrective actions

The six elements of project controls were first introduced to me through a training event in 1996 with Esso Canada. What was presented to me at the time was actually the six elements of project management. From that point on, my goal was to further expand these elements into the project controls domain and the Total Cost Management Framework.

To recognize the relationship with the TCM Framework, I overlayed the six elements of project controls onto the process steps of the project controls process map, as illustrated in Figure 1. The project controls process map identifies the required inputs and outputs for each process step for organizational success, promoting operational and business efficiency.

Click on the figure below for a more detailed view

Figure 1 – The Project Control Process Map, AACE TCM Framework, 2nd Edition, Page 53

As represented in Figure 1, the process map associates each TCM process step with one (or more) of the six elements of project controls via a color-coding system. This overlay allows the audience to visually identify and correlate the activities and relationships of the operational requirements to the functional requirements. A summary outline of each of the six elements of project controls is provided below.

1. Know what has to be done – What is the plan?

Estimate and schedule accuracy (for any project) depends on the maturity and definition of the scope of work and execution strategy. The more mature and defined the project scope is, the more mature and defined the downstream deliverables will be. These deliverables include detailed budgets, schedules, and tracking profiles for schedule and cost control and performance baseline measurement. This also establishes the planned burn rates, productivity rates, and cash flow that identifies incremental spend per period. Knowing what must be done also includes understanding any resource requirements and procured components. Finally, introducing value engineering and risk management activities completes the development of knowing what to do. The plan will also be updated (revised) to include any approved changes to the project to provide a current performance measurement baseline (once execution has started). The final output is the project controls plan.

2. Know what has been done – What happened?

Once the performance measurement baselines have been established, the project team can begin collecting and assessing the effort spent and the work accomplished on a project. This effort is completed by collecting hours and costs through timesheets, contracts, purchase orders, etc. Other sources for performance measurement and to identify work accomplished include progress tables and schedule updates. This information should also be reliable and verifiable, providing comparability and consistency from one period to another. In addition, reporting assists the project team in identifying problems to determine corrective actions.

3. Know how actual performance compares with the baseline – Why did it happen?

An analysis is the starting point for control. Reporting alone is not control, and reporting results is not enough. To determine why an event has happened, or why there is a schedule delay, etc., project teams are required to perform the appropriate analysis. This analysis includes comparing actual hours, costs, dates, etc., with expected performance and outcomes. The project team should understand where deviations, variances, and impacts exist and determine why they exist. Once these findings are understood, a comparison of the project’s actual expected performance should be identified. These efforts allow the project team the opportunity to explore corrective actions as necessary.

4. Know what remains to be done – What will happen next?

Based on the performance comparison of what actually happened, the project teams can forecast the likely results. This forecast includes a prediction of the final project cost/schedule at completions based on demonstrated performance-to-date and a re-estimate of remaining work (of the current scope of work). Re-assessing risks is also a crucial step in forecasting. This re-assessment allows for the proper stewardship, treatment, and closure of existing risks. Remember, forecasting is an iterative process where adverse trends may be identified. Forecast overruns should initiate corrective action, while forecast underruns should be tested to ensure these values are valid.

5. Identify and implement corrective actions to bring performance in line with expectations – What should we do about it?

Once a variance, impact, risk, or opportunity of a budget or schedule element has been identified, the project team can introduce recovery planning measures and corrective/enhancement actions. This includes managing these variances, impacts, risks, or opportunities by utilizing the change management process, the risk management process, or through advanced forecasting techniques and approaches. These variances etc., may affect one or all the process steps within the project controls process map.

Project scope/execution strategies and planning aspects (i.e., schedule planning and development, cost estimating and budgeting, resource planning, etc.) will be required to be updated as performance measurement baselines may have changed. In some cases, introducing recovery planning or corrective actions may not bring performance back in line; however, it does provide awareness of any potential impact. The project controls plan should be updated due to the changes and the implementation of corrective actions.

6. Check results of corrective action

Once any changes or corrective / enhancement actions have been instituted and the project controls plan and baselines re-established, the project team can follow up to assess the results once they become available. This assessment also allows the project team to re-establish the control elements, specifically, knowing what needs to be done, knowing what has been done, knowing how actual performance compares to the performance norms and corrective actions, and knowing what remains to be done. The cycle continues.

Project controls is simple but yet complex. There are many moving parts and interdependencies. However, once one understands the relationships and the inputs and outputs of project controls, its complexity diminishes. While technology is constantly advancing, the basics and fundamentals of project controls will always remain the same.

How Reliable is Float Consumption as a Metric?

admin — Tue, 22 Jun 2021 13:56:33 +0000

How Reliable is Float Consumption as a Metric?

By Rich Plumery, EVP

I think the concept of float consumption is an interesting topic with a lot of variables to consider. This includes understanding the basics, such as the difference between free and total float, the different causes of consumption or changes over time, or what causes the float to grow. I know several schedulers who like to tout this metric as a key schedule risk measurement. I do fear that with all the variables at play that it can be misunderstood or misleading. To better improve this understanding and ensure that the float consumption metric is reliable, the schedule should first be mechanically sound (i.e., built using scheduling best practices). Let’s start with the basics. What is the difference between free float and total float?

Free Float – The maximum amount of time by which an activity can be delayed beyond its early date without delaying any successor activity beyond its early date.

Total Float – The maximum amount of time by which an activity can be delayed without delaying project completion or another mandatory milestone.

Float is determined by completing a forward and backward calculation of the activities early start and late start dates, which are the basics for developing a CPM schedule. Many things can affect the calculation and the amount of float. First, every planner/scheduler builds their schedules a bit differently, whether it is how they build their logic or how (i.e., use of relationships), if they resource load their schedules, and how they determine activity durations, etc. Therefore, if three different planner/schedulers were given the task of building the same schedule you are likely to come up with three different float calculations. Similarly, they may have different critical paths and near critical paths. Many planners may think to complete a forward pass in greater detail for near term activities and delay the detailing of downstream activities to a later date, especially activities like commissioning and startup for later in the project. Another scheduler may decide to expand the commissioning and startup activities, providing greater detail to ensure they have a clearer critical path. This could create a difference in activity end dates by days, weeks or even months, which could greatly affect the total float.

Project schedulers may also use schedule reserve to create a buffer between the project finish date and the internal target date. Some projects may add weeks or even months. This is similar to how we use contingency money to mitigate cost risks. This could effectively hide some amount of total float depending on how the schedule reserve was deployed. When it is deployed as a named reserve activity and therefore is clearly visible to the analysts, it is much easier to complete the analysis of float. When it is buried into actual activities by adding a percentage or much worse, an irregular amount to activity durations, it becomes difficult to analyze the project’s true schedule performance as it was budgeted and determine the true critical path. Analysis becomes even more difficult when a new planner scheduler takes over the planning/scheduling responsibilities from a departing one.

Since project schedules are most often managed through their critical and near critical paths, when looking at float density alone, it is common to observe project float compression. Float commonly experiences some degradation through delays and changes in activity relationships, which is often added after a baseline is established to account for overlooked prerequisite tasks. Some tasks are not initially added as predecessors because they weren’t deemed likely to be driving activities when the baseline was established. Therefore, it is also important to understand how both delays and schedule quality contribute to both float degradation and increased float density when doing schedule performance analysis.

On design projects, I always say that solid interdisciplinary handoffs are the key to success. Those should be the focal points because of ramifications of poor quality, poor communications or late handoffs. Knowing this along with the fact that the ability to start and complete an activity according to plan is also determined by the available resources (especially unique, critical, or scarce resources) and available information makes it a high-risk milestone. Inefficient execution can often be attributed to the dearth of resources and information.

Consider an interdisciplinary handoff with 0 days free float and 20 days total float, a delay of 5 days may not be alarming if you simply look at the float degradation. However, the receiving discipline could experience an efficiency impact during the 5-day delay since the lack of the prerequisite design information reduces the number of work fronts available to them. Additionally, the receiving discipline may also be impacted by moving 5 days of work to a later time and not having the right resources available to meet the new forecast, therefore reducing total float on the same or other path(s). Considering this, it might be a prudent decision to delay another task with less float if it doesn’t present the same challenges to another discipline that isn’t as constrained with resource issues.

Construction projects face similar challenges as design projects. Work front availability is determined by prerequisite activities. Interfaces between crafts should be considered the same as inter-discipline interfaces in design projects because they may present the same resource challenges when experiencing quality or communications issues or delays. Equipment delivery and setting planning presents an additional challenge as projects balance potential delays with having planned equipment available, versus substituting other equipment which may impact productivity and sometimes the critical path when it is determined by long lead equipment.

Float paths often benefit from segmentation into portions of similar resources. A single discipline or craft can easily determine its own priorities. It’s important to understand that a delay to an interface milestone is likely to create additional delays and collateral impacts. Projects should consider both total float and free float relative to interface points of each float path to more effectively manage project priorities. This should just be one analytics tool in your “metrics” toolbox but it can be a helpful one if used properly.

Technical Board Spotlight – Source

Part 5 – Six Elements of Project Controls – Proof of Value

Part 5 – Six Elements of Project Controls –Proof of Value

Part 4 – Six Elements of Project Controls – Competency and Level of Effort

Part 4 – Six Elements of Project Controls –Competency and Level of Effort

Part 3 – Six Elements of Project Controls; Maturity

Part 3 – Six Elements of Project Controls – Maturity

A Primer for Claims and Disputes (Claims 101)

A Primer for Claims and Disputes (Claims 101)

Life Cycle Costs for Environmental Projects

Life Cycle Costs for Environmental Projects

Why is a Basis of Estimate Necessary?

Why is a Basis of Estimate Necessary?

Apathy is the Enemy of Excellence

Apathy is the Enemy of Excellence

Part 2 – Six Elements of Project Controls; Quality

Part 2 – Six Elements of Project Controls; Quality

Part 1 – Six Elements of Project Controls; The Basics

Part 1 – Six Elements of Project Controls;The Basics

How Reliable is Float Consumption as a Metric?

How Reliable is Float Consumption as a Metric?

Part 4 – Six Elements of Project Controls –
Competency and Level of Effort

Part 1 – Six Elements of Project Controls;
The Basics