Project Management | Adroit Consultants, LLC

Pricing Change Orders

Posted on May 26, 2018August 7, 2018 by Adroit

Maryam Mirhadi, Ph.D, PMP

Owners typically have the contractual right to make changes to the scope of work outlined in contracts. Since these changes impact contracts’ scope of work and they potentially have time, cost, and productivity implications, it is important to give proper consideration to pricing change orders.

Pricing is either backward or forward. Backward pricing is used when the pricing is partly or wholly based on the actual cost of a work performed. Forward pricing, however, is based on the estimated cost of work that is yet to be performed.

If the forward pricing approach is used to price change orders or change order requests, the estimated cost of work is prepared based on the projected cost of materials, systems, products and permanent equipment needed to execute the work plus the costs of resources that need to be acquired in implementing the scope of work. The first category of costs is associated with those items that remain as part of the facility or the system being implemented whereas the second category of costs referenced above is associated with project resources (including workforce, temporary equipment, tools, and machinery) that do not remain in the project but are necessary to accomplish project activities. It is recommended that practitioners differentiate between these two categories of costs to ensure the cost of project deliverables can be differentiated from the resource costs.

It is important to account for projected levels of productivity in pricing change orders because the resource usage rate needed to perform a changed work may differ from the resource usage rates required to implement a work under normal circumstances in which no change is introduced. For example, if changing a scope of work adversely impacts labor productivity, the estimated usage rate of workforce originally used to estimate the unimpacted work does not necessarily suffice to complete a changed (i.e., impacted) scope of work. As such, in pricing change orders, the effects of change on the original scope of work need to be assessed to adjust the estimates.

One of the techniques that can be effective in assessing the impact of a changed work is assessing the project cost flow. Cost flow and cash flow are often used interchangeably. It is important, however, to identify the purpose each of these tools intends to serve. A cost flow diagram shows the budgeted amount of money that is needed over time to make progress as planned. A cash flow diagram, on the other hand, provides the estimated sums of money to which a contractor has access over time. Assessing the project cost flow can help analyze excessive costs and overruns by comparing the budgeted (i.e., time-phased estimates) cost of performing the changed work with the sums of money originally needed to make progress as planned. This assessment can help identify the adverse effect of the change on the resource costs needed over time.

This assessment can be insightful only if the cost flow and estimates are prepared at a sufficiently detailed level. Otherwise, they cannot provide an insight into the impact of change because of the lack of granularity of the pricing data available. Properly documenting the basis of estimates and using proper cost breakdown structures are two other important considerations in budget and cost flow documentation. Detailed budgets or cost flows are prepared by relying on certain assumptions and information available at the time of preparing these estimates. These assumptions and information should properly be documented in a document, entitled “basis of estimate”, for future references.

Per the Federal Acquisition Regulation (FAR), cost estimates used in government contracts have to be reasonable, allocable, and allowable. Moreover, pricing data must be current, accurate and complete. The following excerpts from the FAR define reasonableness, allocability, and allowability of costs:

In defining the reasonableness of costs, Provision 31.201-3 of FAR states:

A cost is reasonable if, in its nature and amount, it does not exceed that which would be incurred by a prudent person in the conduct of a competitive business.

In defining the allocability of costs, Provision 31.201-4 of FAR states:

A cost is allocable if it is assignable or chargeable to one or more cost objectives on the basis of relative benefits received or other equitable relationship.

Per the FAR, a cost is allocable only if it:

(a) is incurred specifically for the contract; (b) benefits both the contract and other work, and can be distributed to them in reasonable proportion to the benefits received; or (c) is necessary to the overall operation of the business, although a direct relationship to any particular cost objective cannot be shown.

Per the FAR, the factors that need to be considered in determining whether a cost is allowable include the following:

Reasonableness
Allocability
Standards promulgated by the CAS Board, if applicable; otherwise generally accepted accounting principles and practices appropriate to the particular circumstances.
Terms of the contract
Any limitations set forth in this subpart

It is also important to differentiate between direct and indirect costs in pricing change orders and determine which types of direct or indirect costs have to be included to accurately prepare cost estimates. Typical direct costs of executing construction activities include direct labor and workforce, equipment, material, and services provided to each project activity. Direct costs can be assigned to specific project activities whereas indirect costs are intended to cover overhead expenses that are needed to manage, administer and support the work. Indirect costs are not typically assignable to particular project activities. General conditions costs support various aspects of the work and they are typically assigned at the project level, not at the activity level. Therefore, they are typically considered among the indirect costs unless a different definition of indirect costs is adopted.

Based on what was discussed above, it is important to give proper consideration to pricing change orders. The proper use of pricing approaches including backward or forward pricing is the first step towards properly pricing change orders. The other considerations is to identify the time, cost, and productivity impacts of changes on the original scope of work. Cost flow diagrams can assist in better identifying the impact of change on a project cost, schedule, and productivity. It is also important to ensure proper pricing and estimating practices are used to ensure estimates are reasonable, allocable, and allowable. An effective use of cost engineering techniques throughout the process plays an important role to ensure the estimates prepared for change orders are current, accurate and complete.

—

Our posts to the Insights page share fresh insights and seasoned advice about many project and construction management topics. To have the Insights monthly newsletter delivered automatically to your email inbox, please subscribe here.

Common mistakes concerning project risks

Posted on April 25, 2018November 3, 2018 by Adroit

Maryam Mirhadi, Ph.D., PMP, PSP

Project risks are uncertain events or conditions that may impact a project if they occur. It is important to note that this impact may be negative or positive. As such, project risk response strategies have to be used to deal with each of the project risks. Different risk response strategies may be used depending on whether the risk is negative or positive. Negative risks pose a threat; however, positive risks are to be treated as opportunities.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) –Sixth Edition, identifies the following as the five risk response strategies that can be used for managing negative project risks: avoidance, transference, mitigation, escalation, and acceptance strategies (PMI, 2017). The following table provides a short description and example for each of these risk response strategies:

Table 1. Risk-response strategies for managing negative risks

The PMBOK® Guide identifies the following as the five risk response strategies that can be used for managing positive project risks: exploiting, sharing, enhancing, escalation, and acceptance strategies (PMI, 2017). The following table provides a short description and example for each of these risk response strategies:

Table 2. Risk-response strategies for managing positive risks

Some of the common mistakes concerning project risks and risk response strategies include the following:

1- Risks are always negative: In fact, not all risks are negative. Although the word risk may have a negative connotation in conversations, risks are not always negative in project management. Risk is “any uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives” (PMI, 2017, p. 720). As such, risks may be negative (i.e., threats) or positive (i.e., opportunities).

2- All risks need to be mitigated: In fact, not all risks need to be mitigated. First, it is important to note that mitigating is a risks response strategy only for treating negative risks. This risk response strategy is not applicable to positive risks or opportunities. In addition, although risk mitigation is one of the main risk response strategies for treating negative risks, mitigation is not the only risk response strategy that can be used for treating negative risks. As shown in Table 1– Risk-response strategies for managing negative risks– aside from mitigation, four other risk response strategies also exist that may be used in response to negative risks.

3- Risks can be certain events or conditions: In fact, certain events or conditions for which no doubt or uncertainty exists should not be treated as risks. Definite, certain events are facts, not risks. For example, in case of “having inadequate time to complete the project”, if it is known that the time needed to complete the project is inadequate, this is not a project risk, instead, it is a fact. If uncertainty is not associated with an event or condition, it cannot be considered a risk anymore. To differentiate project risks from facts and to properly name project risks, it is recommended that project management practitioners always use the cause-risk- effect format to define risks. This format can be used as follows: [uncertain event or condition] may occur due to [the cause] which may result in [the effect]. Here is an example: The contractor may incur damages due to unforeseen site conditions which may result in project delays or disputes.

4- Other mistakes: The above-mentioned mistakes were some of the key mistakes made in defining risks or risk response strategies. However, other mistakes may also be made. Some examples include not accounting for contingency reserves or devising contingency plans as part of risk response plans, not assigning role and responsibilities in managing project risks, and not treating risk management as an ongoing process that needs to be performed throughout the project lifecycle.

In sum, many mistakes are made in defining project risks and identifying risk response strategies; however, the main ones include treating all project risks as negative events or conditions with an adverse effect on the project, treating mitigation as the only risk response strategy that can be imagined, and treating definite events or conditions as risks. A proper understanding of project risks and the strategies that can be used to manage project risks is necessary to ensure risks can successfully be managed. If project risks are left unmanaged, they have the potential to force the project to deviate from its plans or fail to reach its objectives.

Reference:

Project Management Institute [PMI]. (2017). A Guide to the Project Management Body of Knowledge (PMBOK ® Guide) (6th ed.). Newton Square, PA: PMI Publications.

—

Types of Change in Projects

Posted on October 24, 2017November 3, 2018 by Adroit

A variety of reasons may cause an increase or decrease in the amount of work from the scope of work specified in the original contract. These reasons result in either directed changes or constructive changes to the project’s scope of work. This article briefly describes each of these main categories of changes. It also outlines the potential implications of changes to a contract scope of work from the time, cost, and productivity perspectives.

In general, owners have the contractual right to make changes to the scope of work outlined in the original contract. Since owner changes impact contract scope of work and they potentially have time, cost, and productivity implications, it is important to identify various types of change in project scope of work and recognize potential effect of each type of change on project contracts. Examples of the most common changes include:

Changes in means and methods or material to be installed
Differing site conditions not envisioned in the original contract price
Modifications that change the planned work sequence as originally envisioned
Changes to the scope of work due to constructability issues or conflicts between systems
Changes in construction, prescriptive, proprietary, or performance specifications
Corrections made due to errors or omissions
Modifications as a result of the actions or inactions of third-parties

A directed change is issued when the owner specifically directs the contractor to make a change. This type of change may or may not affect the contract price. A directed change that influences only the schedule is an example of a directed change with no effect on the contract price. As another example, a directed change that impacts a project’s configuration, work sequence, or space requirements may adversely influence labor and equipment productivity on-site. A directed change with cost impact may reduce or add the contract price. Directed changes are typically not complicated because the owner specifically directs the contractor to make a change and as such, directed changes are easier to recognize.

Constructive changes, on the other hand, occur as a result of non-owner-directed events that implicitly necessitate modifying the scope of work. Unlike directed changes, the owner does not specifically direct the contractor to make a change in case of a constructive change. Instead, as a result of non-owner-directed events or actions or inactions of the owner, the contractor is forced to modify the scope set forth in the contract. Typically, constructive changes are not easy to recognize because they generally occur due to non-owner-directed events or circumstances. In addition, in case of a constructive change, the owner does not typically have explicit acknowledgment of a change to the original scope of work set forth in the contract. Examples of the most common types of constructive changes include:

Verbal communications that implicitly necessitate making changes
Deficient drawings or specifications
Ambiguity in architect-provided responses to information requests
Differing site conditions
Over-inspection

It is important to identify changes in a timely manner, especially in case of constructive changes whose effects are not explicit and readily recognizable. The reasons for each change need to properly be identified and documented in proper change management logs. Moreover, the effects and implications of each change need to properly be documented to ensure sufficient documentation and historical records are readily accessible to substantiate contractual entitlements. If your project has been affected by multiple change orders and they have adversely affected labor or equipment productivity on-site, or if you are interested to investigate the extent of time and cost impacts due to change orders, Adroit will be able to assist in assessing these impacts. For more information, please contact us.

—

The Two Main Types of Project Work Breakdown Structures (WBS)

Posted on April 22, 2017November 3, 2018 by Adroit

A Work Breakdown Structure (WBS) provides a hierarchical or a breakdown structure that decomposes the project scope into more discrete and manageable work components [1]. The process of breaking down the scope into a WBS should continue until the entire project scope is decomposed in adequate details matching the level of control that the project team wants to exercise.

WBS breaks down the entire project scope into meaningful components. WBS is a key project artifact that provides a basis for project planning, performance measurement, and project control. It also creates common language among the project team members and stakeholders to ensure everyone is using the same terms in referring to specific parts of the project scope.

Contrary to the popular belief that only one WBS should be developed for each project, it is suggested that two WBSs be produced to define a project scope: a deliverable-oriented WBS and a process-oriented WBS [2,3]. These two work breakdown structures are different but they are not produced independently of each other. Developing and using these two key types of WBS has certain benefits that justify the efforts to produce these two artifacts and use them in tandem.

A deliverable-oriented WBS (also known as product-oriented WBS) decomposes the project scope into smaller and more manageable deliverables. Deliverable are tangible components that need to be delivered to complete the project. They are typically a physical component or an item that needs to be produced, obtained, or supplied as a result of executing project activities. These deliverables are either interim or ultimate deliverables that are delivered to satisfy project requirements. In construction projects, preliminary plans and specifications, bid documents, and pre-construction mockups are example interim project deliverables. Example of ultimate project deliverables in a construction project may include concrete structures, structural steels, building facade, and a building’s mechanical system.

WBS elements in a deliverable-oriented WBS are typically in the form of a noun because WBS elements identify tangible components that are typically a physical item that needs to be produced, obtained, or supplied. A verity of breakdown criteria can be used to develop a deliverable-oriented WBS to meets the specific needs of projects. For example, a construction contractor may breakdown its scope of work based primarily on physical locations of different project components; whereas, a mechanical contractor may use a system-wise approach to identify systems, sub-systems, and lower level components in each subsystem to decomposes its scope of work. The following figure provides an example deliverable-oriented WBS for a residential project.

An Example Deliverable-Oriented Work Breakdown Structure (WBS) for a Residential Project

A process-oriented WBS, on the other hand, defines the project scope of work in terms of process steps (i.e., work phases, or functions)^[5]. A process-oriented WBS defines what process steps need to be taken to deliver each of the project deliverables. WBS elements in a process-oriented WBS are typically in the form of a verb. They may also identify different work disciplines that are involved to work on various project deliverables. Example WBS elements in a process-oriented WBS include engineering, detailed design, procure, install, and construct. These WBS elements are provided in a hierarchical structure to breakdown the project scope into different functions or process steps. For example, a WBS element such as install may need to be broken down into mechanical and electrical installation depending on a particular project’s scope of work and the scope of responsibilities of the party that is developing the WBS. The following figure provides an example process-oriented WBS for a piping project.

An Example Process-Oriented Work Breakdown Structure (WBS) for a Piping Project

It is important to properly develop project work breakdown structures by choosing proper breakdown criteria, selecting meaningful WBS elements, and using proper level of breakdown to ensure a) project deliverables are properly identified and organized in a hierarchical structure b) work processes are identified in an appropriate fashion to ensure project team members have the same understanding of what needs to be done from a work process or functional perspective to deliver each project deliverable. Developing both deliverable-oriented and a process-oriented WBSs also helps project teams to better identify project activities.

To learn more about project work breakdown structures and the way project management professionals can use the full potential of work breakdown structures, please contact us.

References:

[1]. Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, PA: Project Management Institute. ISBN: 9781935589679

[2]. Golpayegani, S. A. H., & Emamizadeh, B. (2007). Designing work breakdown structures using modular neural networks. Decision Support Systems, 44(1), 202-222.

[3]. AACE International®. RP 33R-15 Developing the Project Work Breakdown Structure, AACE International®, Morgantown, WV, USA

—