Most construction scheduling specifications include provisions dealing with the request for an extension of contract time. Many of these provisions require that the contractor perform a “time impact analysis” (TIA). While not always specified by name, contracts can point generally toward requirements that a TIA is to be submitted in a prospective manner (i.e., in advance of a change or delaying event) to establish entitlement for a contract time extension. However, what happens when a time extension is not agreed to contemporaneously and the contract does not specify how to deal with impacts in a retrospective manner (i.e., after the occurrence of a change or delaying event)? Should a schedule delay analyst utilize the contractually-mandated TIA provision when submitting a claim or expert report? Should a retrospective TIA be prepared? How does delay mitigation play into the establishment and analysis of a TIA? This article examines the answers to these questions, discusses the weaknesses of a prospective TIA with regard to determining compensability for delays, and provides a case study regarding how an expert could respond to or rebut a prospective TIA analysis submitted “after-the-fact.”
Introduction: What is a TIA?
A time impact analysis (TIA) is a modeled method of analysis to aid in supporting a request for an extension of contract time. As defined by AACE RP 52R-06, TIME IMPACT ANALYSIS – AS APPLIED IN CONSTRUCTION, “[t]he TIA is a ‘forward-looking,’ prospective schedule analysis technique that adds a modeled delay to an accepted contract schedule to determine the possible impact of that delay to project completion.” [1]
On the other hand, AACE RP 29R-03, FORENSIC SCHEDULE ANALYSIS-2011 (29R-03), which endeavors to classify and describe retrospective analyses, indicates that some methods of “Observational” analysis (method implementation protocols, or “MIP” 3.3, 3.4, 3.5) are occasionally called “time impact analysis”. However, most analysts consider TIA a “Modeled” analysis (MIP 3.6, 3.7) [See Figure 1]. [2] Under the description of MIP 3.6, commonly known as “Impacted As-Planned,” RP 29R-03 states: “MIP 3.6 can be used prospectively or retrospectively.”
In this regard, what is truly clear about the TIA methodology is that distinguishing between the prospective and retrospective applications of a TIA is not clearly defined amongst AACE’s Recommended practices. When TIA is specified in a contract, what is a contractor, owner, or schedule analyst supposed to do? Is it appropriate to use in a retrospective situation? The answer generally lies in how it is specified in the contract. Taking a step back, let’s explore the definition of “prospective” and “retrospective” and explain the procedure necessary to perform a TIA. Later paragraphs discuss scheduling specifications and the applicability of using a TIA as a retrospective analysis.
Prospective Analysis
The word “prospective” is defined by Merriam-Webster Dictionary as “likely to come about: expected to happen.” [3] Accordingly, a prospective analysis is one prepared in advance of delaying events or change work, to model what is likely to happen as a result of the subject event(s). RP 29R-03 defines prospective analyses as follows:
“Prospective analyses are performed in real-time prior to the delay event or in real-time, contemporaneous with the delay event. In all cases prospective analysis consists of the analyst’s best estimate of future events. Prospective analysis occurs while the project is still underway and may not evolve into a forensic context …” [4]
Generally, there are five major steps in the procedure for performing a prospective TIA:
- The analyst must first identify that there is a change or potential change in the work (g., change order, construction bulletin, request for proposal) or a foreseeable, potentially delaying event for which there may be entitlement to a time extension (i.e., a delaying event that might be critical and which may extend the projected date of project completion)
- The contractor should identify the most recent, approved/accepted schedule update, which we call the “unimpacted” or “original” as-planned schedule. [5] The contractor should identify the activities in the schedule that may be affected and the project completion date (or other milestone) to which delay is being measured
- The contractor should create a fragnet (or fragmentary network of activities) to represent the delaying event or change work in question. The fragnet should be the analyst’s best projection of the work activities required to complete the change work, or the best representation to model a potential delay issue. It is noted that these fragnet activities are “projections” of work to be completed or impacts that may be encountered
- Determine how the developed fragnet “fits into” or is logically tied to the current schedule. The analyst should input the fragnet activities into a copy of the “unimpacted” schedule, ensuring the fragnet’s first and/or last activities are tied to other activities in that schedule. The result of this step is the “impacted schedule”
- Reschedule the impacted schedule as of the same data date as the “unimpacted schedule,” and determine the difference in project completion (or other milestone to which a delay may be measured) between the “unimpacted” and the “impacted” schedule
The TIA should be submitted timely in accordance with the contract requirements, presumably with a written narrative explaining the issue in question, a listing and explanation of the activity(ies), durations, and logic used to develop the fragnet, the reasoning of the logical relationships tying this work into the unimpacted schedule, and a calculation of the impact (the difference between the completion date of the unimpacted schedule vs. the impacted schedule.) This narrative may also include, if required, a discussion of the contractor’s resources in support of the activity durations to accomplish the change or impacted work, and any potential mitigation of delay it might have considered.
With regard to delay mitigation, the contractor should ensure that the proposed fragnet takes into consideration alternate ways to perform its work. In other words, it should look at the schedule logic to determine whether the subject logic ties are mandatory or preferential, and to the extent any relationships are preferential, consider if there is a way to more efficiently perform the work.
In this regard, it is noted that usually the function of a prospective TIA is to model a projection of an impact for purposes of negotiation of a time extension. In general, negotiations tend to be more successful if the model is realistic and sufficient consideration is provided with regard to potential contractor delay mitigation.
It is also noted that separate from this TIA submission should be a negotiation regarding direct cost issues and/or relief from liquidated damages. As will be discussed further below, a prospective TIA does not generally deal with delay concurrency, and thus is a poor tool to definitively determine delay compensability. Rather, because this is a negotiation tool, both parties may agree to treat the delays as either excusable non-compensable or excusable compensable, depending on the outcome of the negotiations.
The determination of delay concurrency is a necessary prerequisite to providing guidance as to whether a delay is compensable or non-compensable. In this regard, while the TIA process may be able to model various simultaneous impacts or delays, the TIA process does not explicitly deal with concurrent delay issues.
To the extent the change work or delay event cannot fully estimate delay as of the issuance of the TIA (due to unknowns, complexities, or other issues), the contractor’s best strategy is to provide notice to the owner of the issues it is experiencing.
Furthermore, if delay issues are not settled contemporaneously and the project ends up in a claim situation (be it a request for equitable adjustment (REA), or a claim in court or arbitration), a retrospective analysis may need to be performed to establish entitlement to a contract time extension, delay damages, relief from liquidated damages, or other impact costs.
Retrospective Analysis
Retrospective is defined by Merriam-Webster Dictionary as “of or relating to the past or something that happened in the past.” [6] Thus, a retrospective analysis is one prepared after the delaying event(s) or change work has been performed, such that the actual sequence, timing, and resources of the work related to the subject event(s) is known.
RP 29R-03 defines retrospective analyses as: [7]
“Retrospective analyses are performed after the delay event has occurred and the impacts are known. The timing may be soon after the delay event but prior to the completion of the overall project, or after the completion of the entire project… In other words, even forward-looking analysis methods implemented retrospectively have the full benefit of hindsight at the option of the analyst.” [Emphasis added]
The key, as emphasized in the RP 29R-03 definition above, is that a retrospective analysis is performed with the “full benefit of hindsight.” A retrospective TIA, in general terms, is a method of analysis in which, after the delaying event has occurred, an “as-built” fragnet is inserted into a planned schedule. [8] This is a similar procedure, and has similar flaws, to the hypothetical “impacted as-planned” analysis that courts and boards of contract appeal have rejected as an inappropriate forensic schedule methodology. [9]
There is some evidence from court and board decisions, to conclude that a retrospective TIA should generally not be used in a forensic evaluation and that an observational method of analysis to determine what actually occurred on the project’s as built critical path, should be utilized. [10] [11] [12]
The importance of “hindsight” in this regard is that the contractor or schedule analyst should be able to analyze the true nature of project impacts on the project’s as-built critical path and should not have to perform a modeled analysis. A windows analysis (or an as-planned vs. as-built) can be a more reliable forensic delay analysis tool, as it deals with the critical and near-critical path activities without the need to model individual delay events, of which there are many on a typical project. Furthermore, a windows or as-planned vs. as-built analysis “allows the analyst to determine which delay impacts are concurrent, which are staggered, and which are near critical versus precisely critical with less subjectivity than if only projected dates were used.” [13]
So, what happens if a prospective TIA is required by contract to deal with time extensions, negotiations of time extensions during the course of a project fail, and an after-the-fact delay-related claim or REA needs to be submitted for arbitration or trial?
Outside of recommendations regarding proper documentation and notice, and adhering to the requirements of the contract in this regard as discussed above, the author recommends that when choosing which type of analysis to perform in a retrospective situation, the first place to go is the contract. Does the contract offer any guidance as to what type of analysis is required in a forensic environment? The analyst should also consult with Section 5 of AACE RP29R-03 that has an extensive discussion of how to choose a methodology.
Scheduling Specification Example
Let’s look at a sample contract provision specifying a TIA to see if any guidance may be provided.
Figure 2. Sample TIA Specification [14]
1.1 Time Impact Analysis
Should the Contractor believe it is entitled to an extension of the contract time, or if the Contracting Officer requests a change for which a time extension may be required, the Contractor shall prepare and submit within 10 days of the identification of a delaying event, change in the work, or RFP from the Government, a prospective time impact analysis for approval by the contracting officer. The Contractor shall utilize a copy of the last accepted schedule prior to the first day of the impact for the time impact schedule and the first day of impact is too great, the contractor shall prepare an interim updated schedule to perform the time impact analysis.
The Contractor shall prepare a proposed fragnet for its time impact analysis which shall consist of a sequence of new activities that are proposed to be added to project milestones. The Contractor shall clearly identify how the proposed fragnet is to be tied into the project schedule including all predecessors and successors to the fragnet activities. The proposed fragnet shall be approved by the Government prior to incorporation into the project schedule.
Unless approved by the Contracting Officer, no other changes will be incorporated into the schedule being used to justify the time impact.
In the example specification, above, there are some key statements that provide guidance that this prospective TIA process should be utilized during the course of the project to resolve time extension requests. Specifically, the specification indicates that the analysis should be “prepare[d] and submit[ted] within 10 days of the identification of a delaying event …” Furthermore, the specification indicates specifically that the TIA should be “prospective” in nature.
To clarify and better define the specification that the TIA methodology should be utilized only during the project in a prospective manner, language similar to the following could be added to this specification:
“The fragnet should not include as-built data, as the time impact analysis is to be solely prospective in nature. This TIA methodology identified above shall be utilized only during the course of the project to request time extensions, and not retrospectively in a forensic environment to determine entitlement to a time extension or delay damages.”
Conversely, the specification could require that the prospective TIA methodology be utilized during and after the project is over, or a could require a retrospective TIA for forensic use. [15]
Even if the contract requires a prospective TIA, it could generally aid a schedule analyst to explore the use of an observational analysis approach. The reason for this is the determination of delay compensability. During the project, a contractor is generally looking for an extension of time, as a negotiation. In an after-the-fact situation, an analyst should rely on the best information available, which is generally as-built data from daily, weekly, and monthly reports, meeting minutes, pay applications, etc., rather than projections of hypothetical events. Without a retrospective, observational analysis taking into consideration what actually happened on the project, what the as-built critical path of the project is, and what competing or concurrent delays may have occurred, the analysis may not provide the trier of fact with a proper understanding of the actual impacts on the project. [16]
In summary, the scheduling specifications should be clear as to when and how a TIA is to be prepared and submitted, what is required in the submission, and should specifically state that the TIA is to be prospective and/or retrospective in nature. While there is dispute as to whether a retrospective TIA is the most appropriate and proper analysis to perform a delay analysis, the scheduling specification should be clear as to whether the analysis methodology should govern the after-the-fact resolution of time-related disputes.
In this regard, the following case study is presented based on competed litigation regarding the construction of a hospital with which the author of this paper was involved. The author of this paper’s firm was retained by the owner to prepare a schedule delay analysis regarding delays on the project and to respond to the contractor’s schedule delay expert’s submission. The contractor’s schedule delay expert submitted prospective TIAs (slightly modified from those submitted contemporaneously by its client) as its expert time-based analysis, justifying its analysis methodology choice by referring to the TIA requirements in the contract. The case study below discusses the subject scheduling specification, the contractor’s expert’s TIA submission, and how the author analyzed and responded to the contractor’s expert’s forensically submitted TIA submissions.
Case Study Example
During the construction of a design-bid-build hospital project, a bulletin was issued by the designer, modifying the mechanical design for a portion of the building. The government issued an RFP (request for proposal) to the contractor to address any direct cost and time extension it felt it may have been entitled to. The scheduling specification provided the following with regard to the required TIA procedure:
Figure 3. Sample TIA Specification
1.1 Time Impact Analysis
Should the Contractor believe it is entitled to an extension of the contract time, or if the Contracting Officer requests a change for which a time extension may be required, the Contractor shall prepare and submit within 10 days of the identification of a delaying event, change in the work, or RFP from the Government, a prospective time impact analysis for approval by the contracting officer. The Contractor shall utilize a copy of the last accepted schedule prior to the first day of the impact for the time impact schedule and the first day of impact is too great, the contractor shall prepare an interim updated schedule to perform the time impact analysis.
The Contractor shall prepare a proposed fragnet for its time impact analysis which shall consist of a sequence of new activities that are proposed to be added to project milestones. The Contractor shall clearly identify how the proposed fragnet is to be tied into the project schedule including all predecessors and successors to the fragnet activities. The proposed fragnet shall be approved by the Government prior to incorporation into the project schedule.
Unless approved by the Contracting Officer, no other changes will be incorporated into the schedule being used to justify the time impact.
The contractor submitted a proposal for direct cost, extended general conditions and overhead, along with a prospective TIA submission requesting additional time. The government accepted the direct cost component of the proposal but denied the request for an extension of time and delay damages. The contractor provided notice that it disagreed with the government’s rejection of the extension of time but continued to perform the change work. Several additional bulletins and RFIs were issued during the performance of the Work on the project for which the contractor requested additional contract time, each of which were rejected by the government.
After the contractor achieved substantial completion significantly late, the contractor submitted an REA, requesting delay and impact damages along with a time extension request in order to release its withheld liquidated damages. This REA was rejected by the contracting officer, and the contractor elected to certify its claim and enter into litigation as contemplated under the Disputes clause of the contract. The contractor hired a schedule delay expert to analyze the project and submit an expert report regarding its findings and conclusions. The contractor’s expert, pointing to the TIA provision of the contract in Figure 3 above, which is the only guidance provided by the contract as to how to handle requests for extensions of time, submitted an analysis based on prospective TIA, which was slightly modified from those submitted contemporaneously by the contractor.
As our firm was engaged as the government’s schedule delay analysis expert, I was tasked to review, analyze, and respond to the contractor’s delay analysis expert’s report. My initial commentary was regarding the specification to which the contractor’s expert pointed. There was no language in the specification that required the analyst to submit prospective analyses for “all time-related disputes, both during and after the project,” nor did the specification direct the analyst to perform any specific type of analysis in a forensic arena.
This matter was in litigation and it was ultimately up to the trier of fact to determine what type of analysis is required or helpful in considering the facts of the case and the contract requirements. As discussed previously, the author of this paper recommends an observational method of analysis be performed in retrospective situations. An observational retrospective analysis such as a windows analysis (AACE RP29R-03 MIP 3.3 or 3.4) or as-planned vs. as-built (AACE RP29R-03 MIP 3.1 or 3.2) has the significant advantage of determining what work was on the actual as-built critical path of the project and can help determine delay compensability.
In this regard, for my affirmative analysis, I performed a windows analysis, also known as a “contemporaneous period analysis” (AACE RP29R-03 MIP 3.3). This is a chronological and cumulative approach to analysis that marches through time and endeavors to determine the as-built critical path on the project and to apportion the source, magnitude, causation, and responsibility of the associated critical delays to the responsible parties.
However, because the trier of fact would ultimately decide what type of analysis may or may not be required by contract, we felt it necessary to review the individual prospective TIAs submitted by the contractor’s expert on their face to determine if the issues in question delayed the project and if prospective TIAs established any delay to the project.
In this regard, for purposes of this case study, we will look at the TIA prepared for Bulletin 1. The figure below depicts a summary of the original “unimpacted” schedule with a data date of 03-Sep-12:
As can be seen, the critical path runs through the main building area (framing and electrical rough-in 1st floor, and electrical rough-in and drywall 2nd floor) with the ancillary building on a near critical path of 18 workdays.
The Contractor created and inserted a four-activity fragnet (Activities F1000, F1010, F1020, and F1030), tied to the commencement of Activity A2440 “Ancillary 1st Flr Install Electrical Equipment” into this schedule representing the contractor’s contemporaneous forecast (using “foresight” durations) for the additional generator work required in the ancillary building area.
The insertion of the Bulletin 1 fragnet used up the available float in the ancillary building area, causing this area to become critical. Furthermore, this TIA had the effect of pushing the projected date of substantial completion from 11-Dec-12, to 30-Jan-13, a projected delay of 50 calendar days for which the contractor (and contractor’s expert) requested a 50-calendar day compensable time extension.
It is noted that a prospective TIA should generally be submitted in advance of a delaying event or change for purposes of negotiating a time extension. In this case, a prospective TIA was submitted after the fact, leading me to review several aspects of the submission. Most importantly, it is necessary to look at how the change/delay work was actually performed, what was driving the as-built critical path to project completion during this period of time, what was the true delay on the project during the impacted period, and what was actually causing this delay on the project.
In this regard, in order to evaluate this and each of the other prospective TIAs that were submitted after the fact, the author first looked at daily reports and actual dates included in subsequent schedule updates to determine the as-built durations and sequencing of the change work. This helped us determine if the original fragnet durations and logical relationships were reasonable and realistic, if the contractor followed the plan indicated in the TIA submission or if the contractor was able to work out of sequence to mitigate some potential delay.
Comparing the as-planned fragnet to the as-built of the schedule revealed several important things. First, it appears that the contractor worked significantly out of sequence compared to the projection from the TIA. The contractor did not wait until the Bulletin 1 change work was performed to commence the original contract work in the Ancillary building area. As a result, the contractor did not experience delay in this area as it projected in its TIA.
Second, a review of the original contract electrical rough-in work revealed that it was significantly delayed during this period of time. As a result, the project’s critical path continued to run through the main building area, and the ancillary building area has 42 workdays of float.
It is noted that contemporaneously, the contractor may not have had any idea of the impending electrical delays on the project. The submitted prospective mechanical Bulletin 1 TIA would not have captured any potential electrical delays if they were not known as of the submission date, to no fault of the contractor. If the contractor and government were able to negotiate a resolution to the requested time extension, the project would move on and the contractor would be entitled to what was agreed to between the parties. However, once the work is completed and as-built data is available, the actual delays and sequence of work should be analyzed and the party that actually caused critical delay on the project should be held responsible.
I also performed a windows analysis for the project to determine what work was on the as-built critical path to project completion during this period of time. In this regard, consistent with the analysis of the fragnet above, the electrical rough-in work in the main building area was driving and critically delaying the as-built critical path of work during the Bulletin 1 “impact period.”
Furthermore, I looked at the schedule updates during this period of time to see what work was on the projected longest paths for each update and if the contractor was truly delayed to the extent it claims in its prospective TIA. Consistent with the windows analysis and determination of the as-built critical path, the schedule updates indicated that, although the project appeared to be delayed during the Bulletin 1 “impacted period,” the electrical rough-in work in the main building area was critical and that work was actually delaying the Project during that time, and not the activities identified in the contractor’s prospective TIA. I also reviewed the available project information (e.g., daily reports, correspondence, meeting minutes) and determined there were no assertions made by the contractor or other evidence of the Contractor “pacing” its work because of this change.
Analyzing and presenting the relevant data thoroughly and succinctly to a trier of fact will help to establish entitlement to a requested extension of time and/or delay damages. It is noted that while the contractor may have experienced other impact damages (i.e., acceleration costs or loss of productivity) related to Bulletin 1, the analysis indicates Bulletin 1 did not cause a critical path delay and the contractor should not be entitled to a time extension or delay-related damages as a result.
Conclusion
In conclusion, a prospective TIA can have significant value during a project to contemporaneously deal with the negotiation of a request for an extension of contract time, particularly if performed in conformance with AACE RP 52R-06, TIME IMPACT ANALYSIS – AS APPLIED IN CONSTRUCTION. However, a prospective TIA only deals with an estimate of what might happen on a project in advance of the delays actually unfolding and does not generally take into consideration concurrent delays and compensability matters. In a retrospective situation, an analyst should deal with the best information available, as-built data, and prepare an observational analysis to establish the as-built critical path to project completion and to apportion the source, magnitude, causation and responsibility of the associated critical delays to the responsible parties. An exception to this may be when a contract requires the use of a particular type of analysis in a retrospective or forensic situation. In such cases, it is advisable to perform both the prospective TIA and a more appropriate retrospective analysis. [17]
It is important for a schedule delay analysis to take into consideration delay mitigation. In a prospective analysis, potential mitigation should be accounted for in the development of a fragnet and addressed during negotiations. Retrospectively, contractor mitigation should be analyzed to determine the true effect of any delays in question.
While the author does not generally consider a TIA (either prospective or retrospective) to be the most appropriate and proper analysis to perform in a retrospective, forensic delay analysis, a scheduling specification should be clear if contract requires a TIA methodology to govern the after-the-fact resolution of time-related disputes.
To the extent, as a delay analyst, that you encounter prospective TIAs submitted retrospectively, the main course of action should be to determine:
- Whether the subject impacts truly delayed the as-built critical path to project completion.
- Whether the TIA fragnet activities were reasonable in sequencing and duration to the as-built record of that work.
- Whether there were any concurrent or competing delays that may offset the compensability of delays.
- Whether the submission meets the contractual requirements regarding the request for an extension of time.
As a contractor or contractor’s analyst planning to submit a TIA in a retrospective or forensic situation, if required or otherwise desired, these same guidelines should be followed in order to provide the reviewer or trier of fact the most reasonable and accurate presentation of impacts on the project.
Finally, as in any schedule delay analysis, the main consideration should be to determine cause and effect — with causation necessary to establish entitlement, and, if available, an analysis to demonstrate the actual effect on the work.
[1] Calvey, Timothy T., and Winter, Ronald M. TIME IMPACT ANALYSIS – AS APPLIED IN CONSTRUCTION, AACE International Recommended Practice, No. 52R-06 (2006), AACE International, Morgantown, W.V.
[2] Hoshino, Kenji P., Livengood, John C., and Carson, Christopher W. FORENSIC SCHEDULE ANALYSIS, AACE International Recommended Practice No. 29R-03 (2011), AACE International, Morgantown, W.V.
[3] Merriam-Webster, n.d. Web. 28 June 2016.
[4] RP 29R-03 (2011), p, 13.
[5] To the extent the contractor’s schedule updates are not accepted, the contractor should follow the contractually required procedures for requesting a time extension, but may need to work with the owner (or the party to which the schedules are submitted) to establish an accepted as-planned schedule for purposes of the TIA submission. To the extent there is not a schedule proximate to the delaying event, a prudent analyst may (or may be required by the scheduling specification to) create an “interim” schedule closer to the delaying event or change work in question.
[6] Merriam-Webster, n.d. Web. 28 June 2016.
[7] RP 29R-03 (2011), page 13.
[8] Barba, Evans M. Prospective and Retrospective Time Impact Analysis, July 2005 Construction Briefings, Thompson/West, Eagan, Minn.
[9] Robust Construction, LLC, ASBCA No. 54056, 2005-2 BCA 33019; Appeal of Ealahan Elect. Co., Inc., 90-3 BCA (CCH) ¶ 23177, D.O.T. Cont. Adj. Bd. 1990.; Titan Pacific Const. Corp., ASBCA No. 24616, 87-1 BCA 19,626, 17 Cl.Ct. 630, 89 F.2d 1227 (Fed. Cir. 1990).; and Gulf Contracting, Inc., ASBCA No. 30195 89-2 BCA 22814 (1989).
[10] It is possible, however, that a “Retrospective TIA” could be required by contract to resolve all time-related disputes.
[11] Lifschitz, Judah, et al., A Critical Review of the AACEI Recommended Practice (2009).
[12] Petrov, Maria, and Vara, Carlos Manuel, CDR.S03—Retrospective or Prospective Delay Analysis in My REA – Should I Be Concerned About It?, 2008 AACE International Transactions, AACE International, Morgantown, W.V.
[13] Livengood, John C., CDR.08—Retrospective TIAs: Time to Lay Them to Rest, 2007 AACE international Transactions, AACE International, Morgantown, W.V.
[14] Specification example adapted from referenced sample project.
[15] Barba, Evans M. Prospective and Retrospective Time Impact Analysis, (2005).
[16] Lifschitz, Judah, et al. A Critical Review of the AACEI Recommended Practice (2009).
[17] RP29R-03 (2001) includes a detailed section on how to choose the best methodology for the situation
© Copyright 2019. The views expressed herein are those of the author(s) and not necessarily the views of Ankura Consulting Group, LLC., its management, its subsidiaries, its affiliates, or its other professionals.
Ankura is not a law firm and cannot provide legal advice.
