Category: Project Management

Variation and Variation Orders: Important Considerations

Variation and Variation Orders: Important Considerations

Posted on by Adroit

Introduction

A variety of reasons may increase or decrease the amount of work required by a contract. These increases or decreases are either directed or constructive. This article briefly describes each of these main categories of variation. It also outlines the potential implications of variations and variation orders from the time and cost management perspectives.

In general, owners have the contractual right to make changes to the work outlined in the original contract. The terms variations, modification, and changes are often used interchangeably.

Variation types

Since variations not only impact contract scope of work but also they potentially have time and cost implications, it is important to identify various types of variations and recognize potential effect of each type of variation on contracts. Examples of the most common variations include:

  • Changes in means and methods or material to be installed
  • Differing or unforeseen 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 work elements
  • Changes in plans and specifications
  • Corrections made due to errors or omissions
  • Modifications as a result of the actions or inactions of third-parties

Directed variations

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

Constructive variations

Constructive variations, on the other hand, occur as a result of non-owner-directed events that implicitly necessitate a variation. Unlike directed variations, the owner does not specifically direct the contractor to make a change in case of a constructive variation. Instead, as a result of non-owner-directed events or actions or inactions of the owner, the contractor is forced to modify the scope specified in the contract or incur additional costs. Typically, constructive variations are not easy to recognize because they generally occur due to non-owner-directed events or circumstances. In addition, in case of a constructive variation, the owner does not typically have an explicit acknowledgment of a variation to the original scope of work set forth in the contract. Examples of the most common types of constructive variations 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

Implications

Although deductive variations exist, variations typically increase contract prices. This increase is due to increases to direct material, labor, and equipment prices. Nevertheless, the impacts of variations are often not limited to direct costs. Variations often result in the loss of efficiency and as such, the adverse effects of variations need to closely be examined to ensure their consequences are fully evaluated.

Conclusion

It is important to identify variations in a timely manner, especially in case of constructive variations whose effects are not explicit and readily recognizable. The reasons for each variation need to properly be identified and documented in proper tracking logs. Moreover, the effects and implications of each variation need to properly be documented to ensure sufficient documentation and historical records are readily accessible to substantiate contractual entitlements.

Author: Dr. Maryam Mirhadi, PMP, PSP | CEO and Principal Consultant

 If your project has been affected by multiple variations or variation order 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 variation orders, Adroit will be able to assist in assessing these impacts. For more information, please contact us.

Evaluating Activity Logic Relationships: A New Perspective

Evaluating Activity Logic Relationships: A New Perspective

Posted on by Adroit

Project schedules are among the key project artifacts that are used as a basis for project control. They are one of the most effective ways that a project team can use to coordinate their activities. Project schedules play a key role in making such coordination and to facilitate achieving a project’s time objectives. However, project schedules can play this role only if they are prepared in a reasonable manner. The reasonableness of project schedules can be evaluated from various perspectives including consistency, clarity, completeness, and feasibility of construction plans.

The following are some of the main considerations that need to be given to developing project schedules to ensure they are reasonable:

  • The schedule is complete and entails all the activities that are needed to successfully implement the scope of work
  • Proper logical relationships (including finish-to-start, start-to-start-, start-to-finish, or finish-to-finish relationships along with proper lag and lead values) are used in creating the project network
  • An appropriate combination and choosing of activity relationships (including mandatory, preferential, and scenario-based relationships) are created to define activity dependencies
  • The schedule accounts for the technical, physical, and technological constraints of performing the work
  • The schedule meets proper contractual milestones, identifies all interim and ultimate contractual deliverables, and satisfies time and resource constraints outlined in the contract
  • The schedule is clear, reasonable, and complete
  • Different sections of the schedule are consistent in terms of the timeline, work priorities, and work sequence

As noted above, activity dependencies are among the key main considerations in developing well-prepared schedules. A project network not only contains project activities but also defines activity dependencies (also known as activity ties or activity relationships). A variety of activity dependencies exists, and activity relationships are categorized in different ways.

Activity dependencies can be categorized based on the nature of dependencies that exist between project activities. From this perspective, activity dependencies are often categorized into the following two types of dependencies:

  • Mandatory dependency (also known as hard logic): This relationship represents a dependency that is necessary or inherent in the nature of the work.
  • Discretionary dependency (also known as soft, preferred, or preferential logic): This type of dependency represents preferential logic that is used to establish a desired sequence of work despite alternative sequences that are acceptable.

It is important to note, however, that mandatory and discretionary relationships are not the only activity relationships that are used in project schedules. To better identify activity dependencies, it is suggested that activity dependencies are further categorized as shown in Figure 1.

Figure 1. Activity relationship types

As this figure shows, mandatary relationships can further be broken down into the following three types:

  • Imposed relationships: Imposed relationships are those relationships that need to be built into a project schedule to satisfy legal, regulatory or contractual requirements. An example includes a contractually-imposed requirement that mandates using a phased approach (where a portion of work has to be implemented after another portion) in completing certain elements of work.
  • Physical relationships: This relationship represents a dependency that has to be established between two or more activities due to the nature of the work. An example of dependencies that are inherent in the nature of the work is the need to place a foundation first before erecting a column atop the foundation.
  • Safety relationships: This relationship represents a dependency that has to be established between two or more activities to ensure safety considerations are accounted for in sequencing project activities. An example of a safety relationship is the need to avoid concurrent logic in scheduling two activities that cannot be undertaken simultaneously because of safety concerns (e.g., a crew that cannot work on the second floor of a building because of the ongoing work on the first floor).

Sometimes, project scheduling professionals use scenario-based relationships to define dependencies between project activities. The current article uses the term scenario-based to characterize these relationships because depending on the implementation strategy chosen to execute a project, scenario-based relationships may or may not be used in defining work sequences. Resource relationships are examples of scenario-based relationships. Resource relationships are often added to the project schedule due to resource management concerns (e.g., resource constraints).

For example, if a contractor needs to implement two non-causally-related activities, each of which requiring a crane, the contractor may decide to add a finish-to-start relationship between the two activities if the contractor has only one crane in its possession. In this example, the two activities are not causally related; however, based on the scenario described, the contractor has established a relationship between these two activities to satisfy its resource constraint. If the contractor had two cranes in its possession, defining a dependency between the two activities was unnecessary because as noted above, the activities are presumably not causally linked. Therefore, it is reasonable to recognize the above-referenced activity relationship as a scenario-based relationship because these relationships may or may not be used depending on the implementation scenario or strategy used.

Not all scenario-based relationships are resource relationships; therefore, in Figure 1, scenario-based relationships are broken down into the two main types of resource relationships and others. An example of other scenario based dependencies includes a dependency that is established between two activities based on an assumed what-if scenario to manage a likely change in the project scope of work. This relationship may or may not be required to be established depending on whether the change occurs or not.

The last category of activity relationships is improper relationships that consist of redundant, incorrect logic, and logic loops. Incorrect logic relationships can further be categorized into errors, missing logic, out-of-sequence, and improper use of lags and leads. These relationships will be described in greater depth in a future article.

Planning and scheduling professionals need to make informed decisions in selecting and using the right relationship type. In general, it is suggested that only mandatory relationships are used in developing project schedules unless the use of discretionary or scenario-based relationships is justified. Similarly, the use of preferential relationships may not be appropriate in demonstrating that a schedule follows a reasonable logic. It is recommended that, instead of resource constraints, planning and scheduling professionals use resource leveling techniques to ensure the schedule is not bounded by too many dependencies that could have otherwise been accounted for.

Assessing activity relationships is critical in preparing or investigating time extension requests or delay assessments because a proper delay analysis has to be based on a reasonable schedule. A delay analysis based on a project schedule that contains questionable activity relationships is defective. Project planning and scheduling, forensic scheduling experts, and claim management professionals need to ensure project schedules are free of improper relationships. Otherwise, the schedule will not be reliable or reasonable and it may not serve its purpose.

Author: Dr. Amin Terouhid, PE, PMP, PSP | Principal Consultant

If you are interested to find out more about the main considerations in developing or evaluating project schedules, please contact us. Adroit’s consultants have demonstrated their expertise in developing, updating, constructability review, and forensic evaluation of project schedules and will be able to assist. You may also be interested to read the following articles:

Schedule constructability review, what does it entail?

Schedule constructability review, what does it entail?
Mandatory, Discretionary, Scenario-based, and Improper Activity Relationships: Theoretical and Practical Considerations

Mandatory, Discretionary, Scenario-based, and Improper Activity Relationships: Theoretical and Practical Considerations

Posted on by Adroit

Project networks play important roles in carrying out construction activities in a timely manner, and they are among the key means of communication that project teams use to coordinate their efforts throughout the process of construction. Project networks are also among the key project artifacts that are used for preparing or investigating time-related claims and for determining entitlements to time extensions and/or delay damages. Therefore, it is important to have a more in-depth knowledge of activity dependencies and their types.

Activity dependencies are among the key characteristics and building blocks of project schedules. A project network not only contains project activities but also defines activity dependencies (also known as activity ties or activity relationships). A variety of activity dependencies exists, and activity relationships are categorized in different ways.

The four main types of activity dependencies include Finish-to-Start (FS), Start-to-Start (SS), Start-to-Finish (SF), and Finish-to-Finish (FF). The following briefly describes these relationship types:

  • Finish-to-Start (FS): The successor activity cannot start unless the predecessor activity finishes.
  • Start-to-Start (SS): The successor activity cannot start unless the predecessor activity starts.
  • Start-to-Finish (SF): The successor activity cannot finish unless the predecessor activity starts.
  • Finish-to-Finish (FF): The successor activity cannot finish unless the predecessor activity finishes.

Activity dependencies can also be categorized based on the nature of dependencies that exist between project activities. From this perspective, activity dependencies are often categorized into the following two types of dependencies:

  • Mandatory dependency (also known as hard logic): This relationship represents a dependency that is necessary or inherent in the nature of the work.
  • Discretionary dependency (also known as soft, preferred, or preferential logic): This type of dependency represents preferential logic that is used to establish a desired sequence of work despite alternative sequences that are acceptable.

To better identify activity dependencies, it is suggested that activity dependencies are categorized as shown in Figure 1.

Figure 1. Activity relationship types

As this figure shows, mandatary relationships can further be broken down into the following three types:

  • Imposed relationships: Imposed relationships are those relationships that need to be built into a project schedule to satisfy legal, regulatory or contractual requirements. An example includes a contractually-imposed requirement that mandates using a phased approach (where a portion of work has to be implemented after another portion) in completing certain elements of work.
  • Physical relationships: This relationship represents a dependency that has to be established between two or more activities due to the nature of the work. An example of dependencies that are inherent in the nature of the work is the need to place a foundation first before erecting a column atop the foundation.
  • Safety relationships: This relationship represents a dependency that has to be established between two or more activities to ensure safety considerations are accounted for in sequencing project activities. An example of a safety relationship is the need to avoid concurrent logic in scheduling two activities that cannot be undertaken simultaneously because of safety concerns (e.g., a crew that cannot work on the second floor of a building because of the ongoing work on the first floor).

Sometimes, project scheduling professionals use scenario-based relationships to define dependencies between project activities. The current article uses the term scenario-based to characterize these relationships because depending on the implementation strategy chosen to execute a project, scenario-based relationships may or may not be used in defining work sequences. Resource relationships are examples of scenario-based relationships. Resource relationships are often added to the project schedule due to resource management concerns (e.g., resource constraints).

For example, if a contractor needs to implement two non-causally-related activities, each of which requiring a crane, the contractor may decide to add a finish-to-start relationship between the two activities if the contractor has only one crane in its possession. In this example, the two activities are not causally related; however, based on the scenario described, the contractor has established a relationship between these two activities to satisfy its resource constraint. If the contractor had two cranes in its possession, defining a dependency between the two activities was unnecessary because as noted above, the activities are presumably not causally linked. Therefore, it is reasonable to recognize the above-referenced activity relationship as a scenario-based relationship because these relationships may or may not be used depending on the implementation scenario or strategy used.

Not all scenario-based relationships are resource relationships; therefore, in Figure 1, scenario-based relationships are broken down into the two main types of resource relationships and others. An example of other scenario based dependencies includes a dependency that is established between two activities based on an assumed what-if scenario to manage a likely change in the project scope of work. This relationship may or may not be required to be established depending on whether the change occurs or not.

The last category of activity relationships is improper relationships that consist of redundant, incorrect logic, and logic loops. Incorrect logic relationships can further be categorized into errors, missing logic, out-of-sequence, and improper use of lags and leads. These relationships will be described in greater depth in a future article.

Planning and scheduling professionals need to make informed decisions in selecting and using the right relationship type. In general, it is suggested that only mandatory relationships are used in developing project schedules unless the use of discretionary or scenario-based relationships is justified. Similarly, the use of preferential relationships may not be appropriate in demonstrating that a schedule follows a reasonable logic. It is recommended that, instead of resource constraints, planning and scheduling professionals use resource leveling techniques to ensure the schedule is not bounded by too many dependencies that could have otherwise been accounted for.

Assessing activity relationships is critical in preparing or investigating time extension requests or delay assessments because a proper delay analysis has to be based on a reasonable schedule. A delay analysis based on a project schedule that contains questionable activity relationships is defective. Project planning and scheduling, forensic scheduling experts, and claim management professionals need to ensure project schedules are free of improper relationships (i.e., redundant, incorrect logic, and logic loops). Otherwise, the schedule will not be reliable or reasonable and it may not serve its purpose.

Author: Dr. Amin Terouhid, PE, PMP, PSP | Principal Consultant

 

Note:

If you are interested to find out more about the main considerations in developing or evaluating project schedules, please contact us. Adroit’s consultants have demonstrated their expertise in developing, updating, constructability review, and forensic evaluation of project schedules and will be able to assist. You may also be interested to read the following articles:

Adverse effects of schedule deficiencies on claim administration

Schedule constructability review, what does it entail?

The Key Issues with Dangling Activities

Schedule constructability review, what does it entail?

Schedule constructability review, what does it entail?

Posted on by Adroit

Dr. Maryam Mirhadi, PMP, PSP

Project schedules play important roles in coordinating the efforts of project team members and identifying the priorities in performing the work. A project work is decomposed into smaller, more manageable pieces of work once work breakdown structures are prepared. The project schedule is then developed to ensure all responsible parties and team members take each and every step that is needed to achieve time, cost, and scope objectives. But an important question that needs to be answered once a project schedule is prepared is how a project team can ensure the schedule is prepared in an appropriate manner? How can project teams make sure the project schedule is reasonable and contains all necessary elements and logical relationships that the project team needs to successfully implement the project? Schedule constructability reviews are expected to answer such questions. Such reviews aim to build confidence in the project schedule by evaluating it and creating a basis for further improvements. This article aims to define what purposes schedule constructability review intends to serve and how a schedule constructability review is performed.

A schedule constructability review verifies that the schedule under investigation meets and/or exceeds the minimum requirements of preparing project schedules. It aims to assess project schedules to ensure they properly represent the steps that need to be taken in implementing the project and verify the feasibility of the construction plan. Schedule constructability reviews aim to closely examine project schedules and determine if they satisfy the requirements outlined in the project scope of work, and confirm that they meet the needs and expectations of project stakeholders, and satisfy technical and contractual requirements of performing the work.

The Construction Industry Institute (CII) defines constructability as “the optimum use of construction knowledge and experience in planning, design/engineering, procurement, and field operations to achieve overall project objectives.” (Construction Industry Institute, 1986) In a similar way, AACE International defines constructability as a “system (process) for achieving optimum integration of construction knowledge in the construction process, balancing various project and environmental constraints to achieve maximization of project goals and performance.” (AACE International, 2017, p. 23) These definitions can be adopted and be used in the context of assessing project schedules to determine the types of evaluations that need to be performed when a schedule is assessed for constructability.  Based on these definitions, it is expected that a schedule constructability review identifies schedule deficiencies such as poor logic, improper duration estimates, omissions, inconsistencies, and conflicts to ensure the schedule is reasonable and sound.

Similar to the way constructability reviews are performed to evaluate construction documents for consistency, clarity, completeness, reasonableness, and feasibility of construction plans, schedule constructability reviews are performed to ensure that a schedule meets the following requirements:

  • Project work packages and activities are properly identified
  • The schedule is complete and entails all the activities that are needed to successfully implement the scope of work
  • Proper logical relationships (including finish-to-start, start-to-start-, start-to-finish, or finish-to-finish relationships along with proper lag and lead values) are used in creating the project network
  • An appropriate combination and choosing of activity relationships (including physical, preferential, resource, and safety relationships) have been created to define activity dependencies
  • The schedule accounts for the technical and technological constraints of performing the work
  • The schedule accounts for site restrictions and physical and space constraints
  • The schedule meets proper contractual milestones, identifies all interim and ultimate contractual deliverables, and satisfies time and resource constraints outlined in the contract
  • The schedule is clear, reasonable, and complete
  • Different sections of the schedule are consistent in terms of the timeline, work priorities, and work sequence
  • The schedule accounts for preparation times, material and equipment lead times, and preparatory steps that need to be taken or prerequisite work that needs to be completed prior to the succeeding work elements

Since project schedules are prepared at different levels of detail in different stages of progress, schedule reviews need to be performed periodically to ensure project schedules meet the minimum requirements over the course of a project. Project schedules are progressively elaborated over the project lifecycle. In other words, as new information is obtained and scope is further developed, project schedules evolve into more detailed schedules that reflect an appropriate level of detail for that specific planning cycle. Therefore, project teams need to perform schedule constructability reviews periodically to ensure the schedule remains a reliable tool that is reasonable, well-thought-out, and compliant with the technical and contractual requirements.

References:

AACE International® (2018). Recommended Practice No. 10S-90 Cost Engineering Terminology. Morgantown, WV: AACE International. Retrieved from http://library.aacei.org/terminology/

Construction Industry Institute (CII). Constructability; A Primer, Publication RS3-1 (July), CM, Austin, Texas, 1986.

 

Note: Our competent experts have been the primary authors of two industry guidelines, entitled AACE International Recommended Practice 91R-16 Schedule Development and 89R-16 Management Summary Schedule. These industry guidelines are two of the key references used by cost engineers and project management professionals. If your firm is looking for experts who can assist in developing project schedules or performing schedule constructability reviews; and would like your schedules to be prepared using the best practices of project planning and scheduling, please contact us for a free consultation session.

The Key Issues with Dangling Activities

The Key Issues with Dangling Activities

Posted on by Adroit

Dr.  Amin Terouhid, PE, PMP

Dangling activities (also known as dangles) are loosely-tied activities in project schedules. They are activities with either open start dates or open end dates. All activities, except the first activity of a network, need to have a predecessor; otherwise, they will have open start dates. Similarly, all activities, except the last activity of a network, need to have a successor; otherwise, they will have open end dates (also known as open-ended or open-end activities).

As noted above, every project activity and milestone except the first and last ones must have at least one predecessor and one successor. An example of the first activity of a network is the notice to proceed milestone and an example of the last activity of a network is the milestone that represents the project completion date. It is recommended that any project schedule starts with a start milestone and finishes with a finish milestone to ensure proper logical ties can be built into the network.

A project schedule that contains dangling activities has deficiencies because its logic is incomplete. This flaw makes the schedule unreliable and inaccurate because the schedule has not fully developed and some activity dependencies (i.e., logical ties) have not been properly identified. The four main types of activity ties include finish-to-finish (FF), finish-to-start (FS), start-to-start (SS) and start-to-finish (SF).

Here are the main issues with dangling activities:

In the event that a schedule contains a dangling activity, one cannot ensure that the projected start or finish dates accurately represent the planned dates because one or more logical ties are missing. For example, an activity with no predecessor (assuming that the activity is not the first activity of the network) has either been forced to be started or completed on particular dates using activity constraints or has been left fully unrestrained. The downside of the former is that instead of a logical tie, one or more constraints have been added to the schedule preventing the schedule from being flexible due to the use of activity constraints in place of activity ties. Schedules need to remain dynamic to ensure the time impact of a delay or a change to an activity’s duration can properly be transmitted to the rest of the project schedule. The disadvantage of the latter is that leaving the activity fully unrestrained allows the activity to move freely every time that the schedule’s as of date (i.e., data date) is changed.

Similarly, an activity with no successor (assuming that the activity is not the last activity of the network) makes the schedule unreliable because one cannot have confidence in the accuracy of the projected start and finish dates (e.g., the finish date of the network). This shortcoming is present because, in the event of a delay that adversely affects the dangling activity, the impact of this delay does not properly transmit to the rest of the schedule and as such, no activity in the network will be delayed as a result because the dangling activity has presumably no successor. In other words, the schedule will not properly be indicative of the impact of a delayed dangling activity because the network’s logic is incomplete. The same issue may become the case when an activity duration is changed because the time impact of a change to an activity’s duration is not properly transmitted to the rest of the project schedule due to the missing ties. A well-prepared project schedule must provide a full network that projects how the project schedule changes in case of a change to activity durations or in the event of delays.

Another issue with dangling activities may surface when delay claims arise. If a dangling activity is negatively affected by one or more delays, the adverse effect of these delays cannot properly be shown by the schedule. In other words, a schedule with an incomplete logic may not be a reliable tool to show the time impact of delays because the schedule logic is flawed. This deficiency results in underestimating the impact of delays. It is generally accepted that networks are reliable when they are fully developed because in this case, the activity ties define the dependencies between activities and accurately determine the projected start and finish dates.

In sum, every project activity and milestone except the first and last ones must have at least one predecessor and one successor. It is recommended that any project schedule starts with a start milestone and finishes with a finish milestone to ensure proper logical ties can be built into the network. The schedule model must identify all logical relationships to generate a full network. Schedules need to remain dynamic to ensure the time impact of a delay or a change to an activity’s duration can properly be transmitted to the rest of the project schedule. Loosely-tied activities are examples of schedule deficiencies that prevent schedules from properly showing the impact of delays or changes to the schedule on the rest of the network.

If you are in need of schedule development services or would like to monitor and control your schedules in an effective manner, Adroit will be able to assist. For more information, please contact us.

Differences between cash and cost flow diagrams

Differences between cash and cost flow diagrams

Posted on by Adroit

Dr. Maryam Mirhadi, PMP, PSP

Introduction

The terms cost flow and cash flow are often used interchangeably. It is important, however, to identify the purposes that each of these tools intends to serve. These diagrams are among the important elements of financial analysis prior to the commencement of and over the course of a project. Well-prepared cost and cash flow diagrams should be evaluated before making financial decisions concerning a project.

Definitions

A cost flow diagram is a graph that shows expenditures over time. This diagram shows the budgeted amount of money that is needed over time to make progress as planned. Cash flow, however, provides a pictorial representation of income over time. This diagram illustrates how much income the project is going to earn or how much fund will be allocated to the project over the course of a project. A cash flow diagram provides the estimated sums of money to which a project or a project party has access over time. 

In its definition of cash flow, AACE International combines the two aforementioned diagrams. Per the AACE International’s Cost Engineering Terminology (Recommended Practice No. 10S-90), cash flow is a “time-based record of income and expenditures, often presented graphically”, and it shows “inflow and outflow of funds within a project”. A combined view of cash and cost flow illustrates the amount and timing of cash inflows and outflow.

Each of the diagrams discussed above can be prepared from the perspective of different project parties involved in implementing a project. For example, a project cash flow that is prepared from the perspective of an owner may represent how the project is funded from the perspective of an owner but a cash flow prepared from the perspective of a contractor may represent a time-based record of income that the contractor is expected to receive for its particular scope of work.

Benefits

The diagrams discussed above are among the important elements of financial analysis that can be performed prior to the commencement of and over the course of a project. Well-prepared cost and cash flow diagrams should be evaluated before making financial decisions concerning a project.

Prior to the commencement of a project, cost and cash flow diagrams are used to assess the financial justifiability of a project. Once candidate projects are identified, decision makers use cash and cost flow diagrams to decide whether or not a project should be pursued. In project-based organizations that implement a portfolio of projects, these decisions are made to determine if a project can be added to the organization’s portfolio of projects. Capital budgeting methods such as net present value (NPV), payback period, and internal rate of return (IRR) are used to make such decisions.

Over the course of a project, cash and cost flow diagrams can be used to adjust project schedules. If a project team determines that adequate monetary resources are not available to make progress according to the plans, it may decide to postpone some activities to ensure enough funds will be available to be spent when needed. Conversely, if higher-than-expected monetary resources become available during specific periods of time, a project team may decide to ramp up its efforts to benefit from the flexibility that higher-than-expected levels of monetary resources have afforded. For example, if a project-based organization determines that funds will not be available to be allocated to a project, the organization may decide to remove some resources from the project and postpone some activities.

Making a comparison between the cumulative cash and cost flows can also be insightful to identify if adequate monetary resources will be available to fund the project based on its needs. The following figure shows an example of a comparative analysis of cash and cost flow diagram. As this figure indicates, the cumulative cash flow diagram should always represent greater values than the values represented by a cumulative cost flow diagram. A cumulative cash flow diagram that takes values less than the values represented by a cost flow diagram represents insufficiency of funds during certain time periods identifiable by the visual inspection of the diagram.

 

Assessing the project cost flow can also have other benefits. This analysis 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 according to the plans. 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.

Conclusion

As noted above, the cost flow diagram and cash flow diagram are among the important elements of financial analysis prior to the commencement of and over the course of a project. The terms cost flow and cash flow are often used interchangeably; however, it is important to identify the purposes that each of these tools intends to serve. A cost flow diagram is a graph that shows expenditures over time. This diagram shows the budgeted amount of money that is needed over time to make progress in accordance with the plans. Cash flow, however, provides a pictorial representation of income over time or the amount and timing of funds that are expected to be allocated to the project.

If you need to prepare cost and cash flow diagram or assess these diagrams to perform financial analysis and make informed decisions, Adroit will be able to assist. For more information, please contact us.

References:

AACE International® (2018). Recommended Practice No. 10S-90 Cost Engineering Terminology. Morgantown, WV: AACE International. Retrieved from http://library.aacei.org/terminology/

Activity Duration Types in Primavera P6

Activity Duration Types in Primavera P6

Posted on by Adroit

In preparing project time schedules in Oracle’s Primavera P6, project planning and scheduling professionals need to properly select duration types. Primavera P6 uses the following two formulae to determine units of work:

Resource Units = Resource Units per Time Unit * Duration

Remaining Resource Units = Resource Units per Time Unit * Remaining Duration

Based on these two formulae, the user is able to make one or two element(s) of the equation fixed, and input or change the other element(s). That way, Primavera P6 will calculate the remaining elements of the equation. To determine which element(s) of the formula to solidify, the users need to take the nature of the work or information at-hand into account and make an informed decision concerning the elements that need to be solidified. This decision then helps the user to choose among the four main types of activity duration types.

Four types of activity duration types can be defined in Primavera P6. They include 1) Fixed Duration & Units, 2) Fixed Duration & Units/Time, 3) Fixed Units, and 4) Fixed Units/Time. The following discusses each of these activity duration types in more depth:

1- Fixed Duration & Units: This types of activity duration is used in Primavera P6 when the duration and the amount of the resources are known and supposed to remain fixed in the schedule. It is recommended that project planning and scheduling professionals use this duration type for time- and budget- constrained projects prior to making schedule updates. The two possibilities include the following:

  • Option 1: Duration does not change when resources are added or removed, or if the user changes Units/Time.
  • Option 2: A change to the Duration will change the Units/Time; however, Units remains unchanged.

2- Fixed Duration & Units/Time: This type of activity duration is used in Primavera P6 when the duration and resource performance are known and are supposed to remain fixed (i.e., unchanged) in the schedule. In other words, activity durations remains unchanged in the schedule; however, the remaining units change. If an activity is supposed to be completed within a certain, fixed time frame irrespective of the number or amount of resources being assigned to the activity, this activity duration type is the right choice that needs to be used for that activity. This activity duration type is most often used if the user uses task dependent activities (not resource dependent activities). The two possibilities include the following:

  • Option 1: Duration does not change when resources are added or removed, or when Units/Time changes.
  • Option 2: A change to the Duration will change the Units; however, Units/Time remains unchanged.

The use of this activity duration type locks the duration, and the default Units/Time (productivity) values for each resource added. Nevertheless, this activity duration types allows the overall Unit cost to increase when resources are assigned to the activity. It is recommended that project planning and scheduling professionals use this duration type during the planning phase because doing so will force Primavera P6 to honor activity duration estimates and increase the work (Units) and, therefore, the budget, based on additional quantities of work performed (Units/Time).

It is important to note that this duration type disables the User Preferences, Calculations tab option Recalculate the Units, Duration, and Units/Time for existing assignments based on the activity types.

3- Fixed Units: Primavera P6 users need to use this type of activity duration if the amount of work needed to complete an activity (e.g., 8,000 bricks to be laid) is fixed. If this type of activity duration is used, decreasing units per time causes the activity duration to increase; however, if the user updates the duration or units per time, the Units remain unchanged. Increasing the resources allocated to an activity whose duration types is Fixed Unit, decreases the activity duration. It is best to use this activity duration type where the duration is “resource dependent” (and not “task dependent”). If in a project, the budget is set and it is difficult to get additional cost increases approved, the Fixed Units activity duration type is the right choice assuming the other above-mentioned requirements are also satisfied.

4- Fixed Units/Time: Primavera P6 users need to use this type of activity duration if the activity has fixed productivity output per time period (regardless of activity duration). In other words, this duration type is supposed to be used when the user would like the resource units per time to remain unchanged while the activity duration or units change. For example, if a piece of equipment requires two workers to operate, the Fixed Units/Time duration type might be the right choice. When the duration of an activity whose duration type is Fixed Units/Time increases, the amount of budgeted labor units also increases while resource Units/Time remains unchanged. This activity duration type is most often used if the user uses resource-dependent activities.

In addition, users have the choice to choose to preserve “the Units, Duration, and Units/Time for existing assignments” or recalculate “the Units, Duration, and Units/Time for existing assignments” in the User Preferences, Calculations tab of Primavera P6. This choice, as well as the choice of activity duration types, determines what element(s) remain(s) unchanged and what element(s) change(s). These scenarios are outlined in the following two tables:

The User Preferences, Calculations tab option “Preserve the Units, Duration, and Units/Time for existing assignments” is chosen when the user adds or removes multiple resource assignments on activities but would like Units, Units/Time, and Durations to remain unchanged when additional resources are assigned to an activity. When the User Preferences, Calculations tab option “Preserve the Units, Duration, and Units/Time for existing assignments” is selected, here are the various scenarios that are encountered:

The User Preferences, Calculations tab option “Recalculate the Units, Duration, and Units/Time for existing assignments” is chosen when the user adds or removes multiple resource assignments on activities and would like to determine a resource assignment’s remaining values based on the activity’s duration type. When the User Preferences, Calculations tab option “Recalculate the Units, Duration, and Units/Time for existing assignments” is selected, here are the various scenarios that are encountered:

As discussed, four types of activity duration types can be defined in Primavera P6. They include 1) Fixed Duration & Units, 2) Fixed Duration & Units/Time, 3) Fixed Units, and 4) Fixed Units/Time. It is important to pay attention to the nature of work that is being performed to select the right type of activity duration types. This article defined each of this activity duration types and explained where each option needs to be used and what the implications of using these duration types are from the scheduling perspective.

References:

Harris, Paul E (2017). Planning and Control Using Oracle Primavera P6 Versions 8 to 17 PPM Professional. Eastwood Harris Pty Ltd.

Oracle (2018). Primavera P6 Professional User Guide Version 17. Available online at: https://docs.oracle.com/cd/E80668_01/English/User_Guides/p6_pro_user/helpmain.htm?toc.htm?62789.htm

 

The project scope has changed, now what?

The project scope has changed, now what?

Posted on by Adroit

Project teams need to use effective strategies to minimize changes to the project scope of work; however, change is inevitable and it arises due to a variety of reasons. Examples include the change in an owner’s needs or expectations, design errors and/or omission, differing site conditions not envisioned in the original contract price, changes to the project scope of work due to constructability issues or conflicts between systems, and modifications due to actions or inactions of third-parties. From a contractor’s perspective, the change may arise due to reasons outside the contractor’s control; therefore, it is important for contractors to know what actions they need to take if a change in the project scope of work arises.

In case of a change to the project scope of work, one of the first actions that a contractor needs to take is to provide a proper change notice to the project owner. It is important to note, however, that owners may not be the contracting party or the only contracting party that needs to be notified in case of a scope change. For example, if a scope change modifies a subcontractor’s scope of work, the subcontractor may need to notify the prime contractor first. Typically, contracts contain provisions that define the requirements for timely issuance of change notices.

Most contracts require contractors to issue proper change notices prior to proceeding with the work. They also require contractors to submit proper supporting documentation in a timely manner for reimbursement. Most contracts require that contractors provide a descriptive narrative, an adequately-detailed supplemental information to specify the changed work, and reasons for the change to ensure the changed scope of work is defined with adequate specificity and it is justified and properly documented. They also require that contractors specify the potential impacts of the change on cost, time, and productivity.

The changes to the project scope of work are categorized into the two main classes of directed and constructive changes. The differences between these two types of change are described in Table 1. The need for proper documentation of the change is more evident when a constructive change arises because, in the case of a constructive change, the owner does not specifically direct the contractor to make a change. Instead, the change arises as a result of non-owner-directed events that implicitly necessitate modifying the scope.

Table 1. The differences between directed and constructive changes

AttributeDirected ChangeConstructive Change
The role of ownersIt is issued when the owner specifically directs the contractor to make a change.This change is not a result of owner-directed changes.
Reason for changeThe change occurs because the owner’s needs or expectations have changed.The change occurs as a result of non-owner-directed events that implicitly necessitate modifying the scope.
Owners’ awareness towards the changeThe owner is fully aware of the change because the owner specifically directs the contractor to make a change.The owner does not typically have explicit acknowledgment of the change and/or need for change.
The role of contractors Contracts typically require contractors to make changes as the owner wishes.The contractor is forced to make the change and/or accept its implications.
Ease of recognizing the change It is easier to recognize. It is not easy to recognize.
Degree of complexityIt is typically not complicated because the owner specifically directs the contractor to make a change.It is typically complicated because the owner does not typically have explicit acknowledgment of the change and/or need for the change; and thus, may dispute the change.
Effect on the contractThis change may or may not affect the contract price or timeline.This change typically affects the contract price and/or timeline.
Type of effect on the contractThis change may reduce or add the contract price and/or elongate the expected project duration.This change typically increases the contract price and/or elongates the expected project duration.

Not all contracts allow for proceeding with the work prior to the signing of the change order. Also, some contracts do not contain provisions for constructive changes. Therefore, it is of utmost importance for contractors to know what the contract requirements are for documenting the change and what supporting documentation the owner expect to receive. It is recommended that contractors take the following steps if the owner has directed them to proceed with the work prior to the signing of the change order:

  1. Fully comply with the change notice requirements and give notices in a fashion promulgated by the contract
  2. After reviewing the contract documents and making sure that the scope has changed, submit a change order request, provide proper justification for the change, describe the scope of change, and provide estimates of the potential impacts of the change on time, cost and productivity.
  3. If an adequate information does not exist to prepare accurate estimates of the potential impacts of the change on time, cost and productivity, consider the need for formally reserving the rights to ensure entitlements are not unintentionally waived.
  4. If the contracting parties are not in agreement on the change or its impact, follow the steps outlined in dispute resolution procedures, and give a notice of intent (NOI) to file a claim,  if warranted.
  5. To the extent practically feasible, keep separate tracks of the costs of change using a cost coding that differs from the cost coding used for the base contract to ensure the cost impact of change can be segregated from the cost of performing the original scope of work.

Taking the aforementioned steps are important to facilitate the resolution of any modification to the project scope of work with the owner and to minimize disputes to the extent possible.

Schedule Activity Density Analysis

Schedule Activity Density Analysis

Posted on by Adroit

Dr. Maryam Mirhadi, PMP, PSP | Principal Consultant

One of the tools that can be used to assess the time-phased projected number of activities scheduled over the course of a project is the schedule activity density analysis. A schedule activity density histogram represents the cumulative number of activities that are, partly or wholly, scheduled to be performed within each time unit over the course of the project. The schedule activity density can alternatively be measured by activity-workdays scheduled per time analysis period (if activity durations are defined in days).

For instance, if a 10 and a 20 working-day activities are supposed to start and complete in a particular month, the activity-workdays for that particular month will be 30 (i.e., 10+20). If a 10 working-day activity, a 20 working-day activity, and half of an 8 working-day activity are supposed to start and complete in a particular month, the activity-workdays for that particular month will be 34 (i.e., 10+20+8/2).

As such, if a schedule activity density is high within a particular time analysis period, it can be concluded that a high number of activities are in-progress within that particular time analysis period. Therefore, it is expected that delays influence schedule activity density histograms as well because delays change the number of activities that are scheduled to be undertaken within certain time frames. Delayed work typically results in the overlapping of planned future work; therefore, delays are expected to increase the schedule’s activity density during the time frames in which planned future work will be scheduled.

Figure 1 provides an example schedule activity density histogram in which the schedule activity density is shown by the number of activity-workdays scheduled per time analysis period (i.e., monthly periods).

Figure 1. An example schedule activity density histogram

A review of Figure 1 indicates that the schedule activity density is the highest about September 2017 in which the number of activity-workdays is at the highest point whereas, in a time analysis period such as December 2017, the number of activity-workdays is at the lowest point. This indication suggests that in or about September 2017, the highest number of in-progress activities are scheduled whereas in or about December 2017, the lowest number of in-progress activities are scheduled.

Figure 2 provides an example cumulative schedule activity density histogram in which the cumulative schedule activity density is shown by calculating the cumulative number of activity-workdays scheduled per time analysis period (i.e., monthly periods).

Figure 2. An example cumulative schedule activity density histogram

Two cumulative schedule activity histograms are provided in this figure. The blue histogram represents the schedule activity density for the case where the constraint type of all project activities is set to “As Soon As Possible” whereas the red histogram illustrates the schedule activity density for the case where the constraint type of all project activities is set to “As Late As Possible”. A comparison between these two histograms indicates that the cumulative number of activity-workdays scheduled per time analysis period (i.e., monthly periods) for the late chart is always less than or equal to this cumulative number for the early chart over the course of the project because setting the constraint type of all project activities to “As Late As Possible” prevents the non-critical activities from starting on their early start date and being completed on their early finish dates. This change reduces the cumulative number of activity-workdays scheduled per time analysis period (i.e., monthly periods) for the late chart and the activity density chart shifts to the right of the X-axis suggesting that more activities are being scheduled to be performed later than their original early start and finish dates.

Delayed work typically results in the overlapping of planned future work; therefore, delays are expected to increase the schedule’s activity density during the time frames in which planned future work will be scheduled. Analyzing a schedule activity density histogram is helpful in identifying the likely causes that adversely impact project schedules. For example, delaying events that prevent a set of activities from starting or finishing on-time reduce the schedule’s activity density during the time frames in which planned work cannot be performed in a timely manner but increase the schedule’s activity density during the time frames in which planned future work is supposed to be implemented. Schedule activity density histogram provides an effective way to visualize the density of schedules and obtain a better understanding of the effect of delays on the scheduled workload. 

—

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.

Shortening the project longest path

Shortening the project longest path

Posted on by Adroit

The critical path represents a project’s longest continuous sequence of activities in the project schedule. This path determines the earliest time that the project can be completed. To complete a project earlier than its originally-planned completion date, the project longest path is typically shortened. Shortening a project schedule may be costly and result in unintended consequences. For example, schedule compression may cause stacking of trades and ultimately result in loss of labor and equipment productivity. Nevertheless, project teams may choose to shorten a project schedule due to a variety of reasons such as catching up to achieve the planned dates that are affected by delays or due to a need to achieve some milestone dates earlier than expected.

Due to the potential impacts of schedule compression on the project, the project teams should use proper strategies to shorten the project longest path. In accelerating project activities, priority needs to be given to the critical activities because these activities drive the expected project completion date in the schedule. If a number of options exist, priority is typically given to those critical activities whose crashing is less costly. Improper implementation of acceleration plans may result in less than expected time savings, unexpectedly high costs of crashing, quality or safety issues, and loss of labor or equipment productivity. It is important to note, however, that acceleration is not the only option for shortening the longest path.

Depending on the type of the project and its scope of work, project teams may have a number of options to compress project schedules. The following table outlines some of the example methods in each of the main phases of engineering, contracting and procurement, and implementation:

PhaseMethodMethod Description
EngineeringConstructability review and analysisThe review of designs to ensure designs can practically be implemented with cost-effective means and methods.
Incorporate modular components in designThe incorporation of modular components in design to ensure less time is needed to be spent on the jobsite to implement these components.
Reuse designs and plansThe reuse of previously-used design elements may result in saving design time and efforts.
Incorporate standard or typical components in the designThe use of standard or typical designs may help the design team save time and efforts in implementing designs.
Incorporate pre-engineered or on-the-shelf components in the designThe incorporation of pre-engineered or on-the-shelf components may reduce the need for designing new elements.
Contracting and procurementFast-trackingThe creation of an overlap between design and procurement or an overlap between procurement and implementation activities may result in time savings.
OutsourcingThe assignment of work to outside entities instead of implementing all activities in-house may help to use in-house resources in more effective ways.
Find alternative or equivalent modular products or systemsThe use of alternative or equivalent products or systems may help to save time that would have otherwise been used to fabricate or supply items.
Implementation Improve work sequenceThe improvements to the work sequence or betterment of the work schedule may help project teams identify time saving opportunities.
Shiftwork and overtimeWorking overtime or working in periods other than daytime hours may help project teams make more progress in the same or shorter amounts of time.
Expend more resources in the same or shorter time periodsThe use of higher resource usage rates and spending more resources in the same or shorter time periods may help project teams increase progress achievements.
Incentivized working schemesThe use of incentivized schemes may encourage project teams to complete activities in a shorter amount of time or work in a more effective manner.

Because of the potential impacts of schedule compression techniques on the project, the project teams should use proper strategies to shorten the project longest path. Acceleration is not the only option to shorten the longest path. If a project team is intended to shorten the project longest path, it is recommended that the team chooses the most appropriate strategies in each of the main phases of engineering, contracting and procurement, and implementation to ensure the schedule can properly be compressed using a cost-effective manner that fits the project needs.

—

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.