Technical Board Spotlight – Source

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.

Programming Model for Capital and Maintenance Project Portfolio Planning

admin — Mon, 03 May 2021 14:26:16 +0000

Programming Model for Capital and Maintenance Project Portfolio Planning

by Jeffery Borowicz CCP PSP CEP FAACE

The portfolio planning process is a strategic process for any organization or enterprise, in any industry that strives to construct major or minor projects, and capital and maintenance projects. A portfolio of projects can consist of any grouping of individual projects or programs. These projects or programs can also consist of multiple project types within multiple business units or business sectors within a company.

This programing model can be practiced in many industries, such as, manufacturing, utility, software development, real estate development, healthcare delivery, hydrocarbon processing, and government.

The planning process usually consists of a multiple year planning cycle, depending on the size of the organization and the funding available. Many corporations track the capital and O&M expenditures required to maintain their operation or production and plan for future expansion.

Figure 1–Organizational Chart

Many organizations plan the capital and maintenance work in a fiscal year or cycle, at least in the year previous to when the spending will occur. The organization develops a strategy for the long-term production plan for the goods and services they will offer in their respective competitive markets. The planning process can include the company’s long-term outlook of new technologies required for maintaining or developing business, or of maintaining or developing business with existing technologies.

The different business units within the company compete for capital resources by producing business plans and economic studies to show that their project(s) warrant being approved in the upcoming business planning cycle. All projects under consideration need to be placed into an annual model that shows capital expenditure outlay (Figure 2-Time Phased Monetary Plan) in order of most viable, in the earlier years, to less viable in later years for prioritization. All organizations plan fiscal spending cycles that correspond to company business financial spending years.

Figure 2–Portfolio Cash Flow (Time Phased Monetary Plan)

As illustrated in Figure 2, all projects in consideration need to be placed into an annual spending plan over time. Once the annual plan is developed, the total capital spending by fiscal spend year, represents the sum of all the individual spending in all years. Once the annual spending is totaled, the corporate governance needs to approve the actual annual spending budget. If the spending plan shows the annual expenditure totals exceed the capital and O&M budgets approved for those years, the plan forecast needs to be adjusted annually to reflect the approved spending targets.

This is the simplistic explanation for how capital spending is forecasted by typical corporations.

During the execution of the asset management strategy or portfolio plan there is a group assigned to facilitate the execution of the portfolio projects within the plan. Management of the projects typically use a group of company officers and management of skilled technical resources or a program management office (PMO), to facilitate monthly updates of the project status. Tactically, the services provided by the PMO may consist of planning, engineering, project management, finance and accounting, project controls, cost estimating, project scheduling, risk management, benchmarking and quality control and assurance. Depending on the size of the company, and the services required, other services discipline tasks may be required.

Many PMO’s use a stage gate process format to develop and track the progress of the portfolio projects. A stage gate process could utilize the following stages: asset identification, pre-planning, scenario selection, business case development, planning and preliminary engineering, final engineering, execution or construction phase, start-up, testing and commissioning, and final asset in place.

Energy and Utility Sector Process

Figure 3A–Gate Review Process (Energy and Utility Sector – sample)

Oil and Gas Industry Process

Figure 3B–Gate Review Process (courtesy of TCM-3503 and Lance Stephenson, CCP FAACE)

Projects may be managed differently depending on size or approval limits by management. Project categories may be described as: enterprise projects, major projects, portfolio projects, strategic projects, corporate projects, or any project type specified by the business.

For the life cycle of an asset, the stage gate process may be implemented through the following phases: ideation, creation or new construction, operations, maintenance of asset and final useful life of asset in demolition or termination phase.

From an owner’s perspective, the capital project portfolio planning process starts with a dedicated team that consists of the following recommended areas of expertise: asset planning and engineering, project management, project controls, cost estimating, construction management, health and safety, project scheduling, risk management, value management, document control, supply chain, procurement or legal, finance and accounting, human resources, as well as, quality assurance and quality control.

Many organizations may not be able to support, or fund all these PMO processes, but if staffed appropriately, traditionally, the resources (opportunity costs) pay for themselves over the lifecycle of the portfolio planning process. If the organization has a year over year portfolio of projects to administer, a consistent team will make all the difference getting better annually and continuously improving the processes and improving the assets return on investment (ROI).

Implementing continuous improvement measures during the lifecycle of a project also improves the ROI over its years of service, such as: (1) documenting the PMO work processes, (2) managing the operations of the work processes, (3) conducting problem solving sessions to improve processes and procedures, as well as, (4) display visual metrics and capture countermeasures for improvement. This also reinforces the continuous improvement process: plan, do, check, act, or PDCA process. These methodologies can continually achieve various milestones or deliverables at each phase of the project delivery life cycle.

Capital and Maintenance Project Gate Review Planning Cycle

Note: The following gate review planning cycle documentation deliverables list is a representation of a SAMPLE and does not depict any business but could be similar.

Figure 4A–Gate Review Cycles and Business Activities (Energy and Utility Sector – sample)

Figure 4B–Gate Review Cycles and Business Activities (Oil and Gas Sector – sample)

As the gates are established, deliverables should be produced through each gate activity and used to properly document the project requirements. The deliverables should be completed prior to moving onto the next gate. The project schedule typically has milestone check-in dates prior to moving from one gate to another. The PMO manages these meetings and has a rigorous agenda that covers all elements of each gates required documentation needed for discussion with all stakeholders.

Documentation, for each gate, is best practice, that identifies all areas of work within the program office procedure and protocols for document delivery prior to the meetings should be in place.

Each gate could have a definition and purpose statement for the documents to be reviewed and standards for passing the gate review should be established.

Gates could have work associated with safety, communications, team members, scope, schedule, cost, procurement, engineering, construction, compliance, quality, risk and close-out activities.

In conclusion, a documented capital and operations and maintenance project planning process will add structure and consistency to assist stakeholders in understanding their project progress. The process for the programming model will ensure that all conversations, action items, concerns and changes to the plan are discussed in a disciplined systematic way so project stakeholders are kept informed and can then either recommend going forward with the plan or execute changes, as necessary, to complete projects in a timely, consistent manner, or not.

All Figure Detailed View

Technical Board Spotlight – Source

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?

Programming Model for Capital and Maintenance Project Portfolio Planning

Programming Model for Capital and Maintenance Project Portfolio Planning

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

Part 1 – Six Elements of Project Controls;
The Basics