Root Causes… How to define and use
Many developers do not employ any type of root cause process, but invariably when projects go overbudget or are significantly behind schedule, questions arise as to how actual performance has deviated so far from expectations. When senior leadership then starts to investigate what happened, team members both internal and external will often begin finger pointing. These types of investigations also create an atmosphere of sudden, unforeseen scrutiny which applies unneeded stress on team members trying to justify their own positive contributions and save their jobs. An investigation might even trigger good employees to start looking for positions elsewhere resulting in an unwanted exodus of talent. In our experience, it is far less painful for unanticipated issues to be identified and addressed as early as possible. Creating a culture of rapid communication and transparency is key to ensuring senior leadership receives an accurate picture of what occurred and why without the need for periodic Spanish Inquisitions far after anything can be done to course correct.
Culture of Transparency
It is recommended that the developer create a process and workflow for the approval of changes far in advance of a project starting construction. Once a budget and schedule are locked in place, typically at our just prior to closing, this process should then be employed (In fact, it is advised that developers employ a similar process in pre-construction if they truly wish to understand the changes which may occur between initial and final approval for a project). It should be reinforced with the team (including the general contractor) that any deviation from budget or schedule requires going through this process. While the developer cannot directly control this process by the general contractor, it is likely that they already employ a similar system for review and approval of potential change orders. They may or may not have an internal process for schedule changes. They are also unlikely to assign root causes. However, working on the process together can be highly beneficial for both parties. How?
Let’s run through a typical scenario. At the OAC meeting, the general contractor presents a prime contract change order to the owner’s representative for a $200K budget overage and 25-day schedule extension for underground utility work. At this point in the process, the building has just topped out and work on the interiors has started. The project’s contingency has been exhausted and was already close to going overbudget. A change of this magnitude runs the risk of triggering a capital call to the investors. Naturally, the owner’s representative feels blind-sided, and is reluctant to present this to senior leadership until they conduct a thorough review. They may even drag their feet while trying to find a way to frame the issue in a less negative light, fearing a reprimand. After a couple months of arguing, which has put the general contractor in a challenging position with their subcontractor, the owner’s rep successfully negotiates the change order down to $175K and a 20-day extension. When this is finally communicated to senior leadership, the hailstorm of questions invariably begins. How could this have happened? Who screwed up? The owner’s representative consults their old meeting minutes trying desperately to recall. They find some cryptic entry that they vaguely remember about the underground utility subcontractor facing some challenges, but it was dismissed at the time as something which might resolve itself. Everyone in this situation is left with unsatisfactory answers and feeling under pressure to approve a massive spend that no one wishes to pay. Senior leadership is likely questioning whether or not to continue the owner’s representative’s employment and may even be considering severing their relationship with that particular general contractor. NOTE: One of our theories on why those in the construction industry are so often viewed negatively by the development side is that errors in the development process (entitlement issues, permit miscalculations, etc.) lead to changes in the tens of thousands of dollars, but mistakes or oversights in the construction side often result in issues that are in the hundreds of thousands. Even though both mistakes may be equivalent, those in construction often generate 10X the ire.
How might this have gone differently with a transparent change order process in place? First, what does the complete workflow look like?
What the typical workflow shows is that there are two layers of oversight for any potential change, one by the general contractor and one by the owner’s representative, designed to ensure that a given change to budget or schedule is justified. In addition, a truly transparent system will show the developer not just the potential risk in the project (e.g. potential change orders submitted but not yet rejected) but also provide a better understanding as to how effective is each screening layer. Example: when comparing two general contractors working on two concurrent projects in the same market using several of the same subcontractors, which is likely a better strategic partner for the developer 1. the general contractor who passes along 90% of potential change orders received or 2. the general contractor who passes along only 50% of potential change order receives, and on average, they have been reduced by 20% from what was originally submitted?
In addition to the workflow above, any worthwhile change process should include the following:
Quantity of the Change: in dollars or days, if a schedule change. NOTE: A dollar related change may also be considered an accounting variance. Variance reporting is often more commonly used but may lack the other components described below.
Root Cause: A simple word or short phrase which assigns the change to a pre-defined set of buckets. More on this below.
Affected Cost Code(s): Which cost code(s) are impacted by the change. NOTE: See our article on construction accounting structure.
Delegated Authority Signature: Approval signatures based on a responsibility matrix which defines who within the organizations may sign off on various types of changes.
The standard AIA contract does a good job of ensuring the PCCO part of the process is relatively standard, but identifying root causes is not required by contract. Additionally, the AIA contract typically identifies a single person often the owner’s representative or potentially a department head, as the sole approver for PCCOs. However, the larger the organization, the more important to define delegated authority to reduce decision bottlenecks. First, let’s discuss root causes.
Common Root Cause Definitions
Outlined below are several common root cause sources. This is not necessarily a comprehensive list, and the list may vary depending on the developer’s own internal processes, product type, etc. However, these root causes should provide a useful starting point for the development of one’s own root cause list. It is recommended that the process confines root causes to a set list of clearly identifiable causes, rather than allowing team members to “fill in the blank.”
Allowance Use – No cost to Owner – This Root Cause merely identifies that available funds identified in the budget by an allowance are being allocated to a subcontractor / vendor not in their original contract scope.
Allowance Overage – Cost to Owner – In the event that an allowance is insufficient, this Root Cause identifies that additional funds were required in order to complete the work.
Backcharge – No cost to Owner – If a Change Order is the result of corrective work by one subcontractor / vendor as a direct result of damage by another, this Root Cause is applicable. Any Backcharge Change Order must be mirrored with both an add to the subcontractor performing the corrective work and a deduct to the subcontractor responsible for the damage. NOTE: The Project Manager must discuss with subcontractor impacted by the deduct prior to issuance (this root cause has been included here for developers with internal general contractors, third party general contractors likely employ backcharges, though they may be unseen by the developer as they do not impact the pay application).
Owner Directed Change – Cost to Owner – Often an Owner may direct a change during the course of construction. This may be a result of field conditions not satisfying their original vision, or if they see an opportunity to enhance the project in some way which was not previously identified. If so, this Root Cause should be used. NOTE: Developers often tend to want to spend buyout or other contingencies on project enhancements. While this is not recommended, if it cannot be avoided, it should be tracked so if the project ensures other non-elective change orders for which the contingency should have been used, there is no question as to why the project has gone overbudget.
Civil Design Miss – Cost to Owner – If the Civil Design Construction Documents fail to identify an added cost to the project prior to the For Permit set, this Root Cause may be used. This signals that had the Construction Documents been complete at the time of the Permit Set, the cost would have been included in the prime contract cost of work.
Vertical Design Miss – Cost to Owner - If the Architectural, Structural, Mechanical, Electrical, Plumbing or other vertical Construction Documents fail to identify an added cost to the project prior to the For Permit set, this Root Cause may be used. This signals that had the Construction Documents been complete at the time of the Permit Set, the cost would have been included in the prime contract cost of work.
Cost Escalation Increase – If operating under a GMP prime contract, No Cost to Owner. If operating under a Cost-Plus prime contract, Cost to Owner – Generally, it is the responsibility of the general contractor to ensure prices are locked in at the time of notice to proceed. However, extenuating circumstances may lead to subcontractors/vendors being unable to hold their price. A Project Manager should endeavor not to use this Root Cause unless necessary.
Existing Conditions – Cost to Owner – This Root Cause is used to acknowledge conditions discovered during construction which were unknown at the time of notice to proceed.
Necessary Code Changes - If operating under a GMP prime contract, No Cost to Owner. If operating under a Cost-Plus prime contract, Cost to Owner – This Root Cause includes changes driven in the field by municipal inspectors (who often have their own interpretation of what is required, even if the building department did not highlight during their review of the Permit Set).
Scope/Buyout Miss – No Cost to Owner – This Root Cause should be used to add to a subcontractor/vendor’s contract if added scope was not part of their original contract and is generally an error by the general contractor during buyout.
Development Related Issues – This category of Root Causes should be developed in cooperation with the developer’s team members responsible for moving a project through the entitlement process and based on the developer’s internal requirements for closing. For instance, some developers elect to close without having all permits in hand, expecting that the permit for vertical work will be approved prior to the start of vertical construction. There are tradeoffs to proceeding with construction without all approvals in hand. While this may be necessary for certain external practical reasons, such as a project running out of time given the terms of the Purchase Agreement, this is not recommended. That said, having a process by which the root causes for these costs and schedule overruns can be properly identifies is part of having the needed transparency to ensure corrective action may occur on those process constraints. Keep in mind that once a project closes and groundbreaking occurs, the construction process is akin to a runaway train and it should be the priority of the entire project team to remove any obstacles which might be in the way. If team members involved in the entitlement process are not aware or held to account for inadequate support, this will result in negativity between team members and impact company morale. Again, while not ideal, should a developer determine they prefer to run risks associated with not having all approvals in place they may, but should do so with eyes wide open as to the risks and that the source of cost or schedule overruns may have little to do with the construction team.
Delegated Authority
There are two things which may rank as the top ways to engender ill will by one’s subcontractors, 1. being directed to go back into areas where they had thought their work was complete and 2. holding up payment for work they believed legitimate (especially when it turns out that the work is, in fact, legitimate). This is one compelling reason to establish a clear line of delegated authority for the authorization of change work. As stated above, the AIA contract requires designation of one individual to approval all Prime Contract Change Orders. However, as organizations scale, this is often impractical or will place too much authority in the hands of a single individual who may or may not be qualified to make those decisions. Implementing an internal process of delegated authority ensures that decisions can be made quickly, and by the individual for whom that decision is most qualified. A typical delegated authority tree might look something like this in a development organization with an owner’s representative department reporting up to a Vice President:
Up to $10,000 - Project Manager (owner’s rep who typically attends the monthly OAC meetings)
Up to $100,000 - Senior Project Manager (the PM’s direct superior)
Up to $500,000 - Vice President of Construction (the head of developer’s owner’s representative department)
Over $500,000 - President or CEO approval
This ensures that the VP or CEO is not bogged down with every minor change order under $10K nor that the less experienced Project Manager approves a contract change for several hundred thousand dollars without review by his superiors. Also, even though the VP may have a considerable amount of trust from senior leadership, it is unlikely that any President or CEO would not want to be made directly aware of a change over $500K. NOTE: One could also designate schedule changes using this same authority tree. See our prior article on equating time to money.
Signoff by Others
It is also recommended that other designated individuals be included in the authority chain based on their relevance to the issue resulting in the change. While this can add additional steps to the process, doing so ensures that other responsible team members are both informed of the change and. by signing off, have some stake in its approval. For instance, one could have one’s head of the design team (whether internal or external) be required to sign off on changes which have a root cause of Vertical Design Miss. If the civil design is overseen by team members involved in entitlement (as can often be the case), they may be required to sign off on change orders designated as Civil Design Miss. It is important that senior leadership explain to team members that this is not about assigning blame but is designed to both track and to learn from mistakes so that those mistakes can be corrected on future projects. If team members remain blissfully unaware of issues experienced by the construction team, they will continue to employ the same practices and will be doomed to repeat costly errors.
Root Cause Analysis
This table is an example of how one might summarize change order costs and their respective root causes for multiple projects. This kind of reporting can, of course, be visualized in a pareto or other chart should one want dashboard type reporting. The important takeaway is to review preventable change orders such as owner directed “Design Driven” costs to see if improved processes can prevent their occurence. One may also analyze Allowance overages to see if there may be ways to improve their projection.
What is the End Goal?
While we recognize not all of our development clients are interested in a systematic model, repeating and scaling a specific type of product, for those who do this is all part and parcel to a production-oriented model. Where a developer has committed to a prototypical design, continues to utilize the same internal team, external consultants and third party or internal general contractor, one can envision iterating to a point where nearly no change orders are necessary. Doing so can reduce construction risk further and further for one’s investors, allow for reduced contingencies and enable more and more deals to pencil.
