Schedule Reliability and Buffers

Project schedules tend toward tardiness, but what can be done to make schedules more reliably on time? Schedule buffer similar to a cost contingency helps projects become more reliable.

Project plans are generally more optimistic than reality. Reasons for this disconnect are that project plans do not consider: inefficiencies in the handover of tasks between resources, workplace congestion, coordination among contributors, and the multitasking of critical resources. One would think that not accounting for these delay effects would be counter balanced by contributors padding their estimates. But this is not the case. Once a duration is entered in the project plan (whether conservative or optimistic) it becomes subject to all the drag effects of Parkinson’s Law and procrastination.

Read the Post on Ten Six

Spending Plan

“Spending Plan” is the least used option in Primavera, but it is especially helpful when you want to track your Actual Costs against the Budget allocated to your project. You can track Actual Cost vs. Budget across WBS and rolling up to your Project and ultimately to your EPS. While using Spending Plan we need to keep one this in mind that this method uses a Top Down approach i.e. You have a total budget on the top node (Project) and you distribute it to the respective EPS/WBS underneath it.

Note – Spending plan dates start from PS-3 Months and finishes by after 4 yrs.

The following fields are used in Spending Plan;

1) Spending Plan – This is a user entered field where you enter the allocated Budget for the WBS/Project/EPS.

2) Spending Plan Tally – is a summary and it rolls up from the child nodes. If you are using it for a project then it will rolls up one level up from the child WBS and the same for EPS nodes.

WBS		Spending Plan		Spending Plan Tally
WBS 1		200		200	Rolls up from WBS 1.1 + 1.2
WBS 1.1		100		0	No Spending Plan Tally cause no child node
WBS 1.2		50		0	No Spending Plan Tally cause no child node
WBS 2		50		10	Rolls up from WBS 2.1
WBS 2.1	10		0		No Spending Plan Tally cause no child node

3) Undistributed Current Variance – (Spending Plan – Spending Plan Tally) – Follows a Top Down logic, it shows whether you have distributed your budget to the child nodes (WBS/EPS) or not.

WBS	Spending Plan	Spending Plan Tally	Undistributed Current Variance
WBS 1	200	200	0
WBS 1.1	100	0	100
WBS 1.2	50	0	50
WBS 2	50	10	40
WBS 2.1	10	0	10

4) Benefit Plan – Benefit plan follows the same logic as spending plan but indicates the benefits that you stand to gain every month. This is also a user entered field and data has to be manually entered

5) Benefit Plan Tally – Same idea as Spending Plan Tally but only for Benefits.

6) Benefit Variance – (Benefit Plan Tally value – Benefit Plan value) – Follows the same logic as Undistributed Current Variance

Assigning Fixed Price Costs to Activities in Primavera P6

Primavera P6 has a standard process for creating and assigning labor, material, and equipment resources to compute activity cost. What if the activity is performed at a fixed price? Yes, there is a way to specify a fixed price activity cost in Primavera P6 Professional.

A popular procurement contract type is the fixed price contract. In this type of agreement the subcontractor agrees to perform an activity at a fixed price, regardless, of the actual labor, material, and/or equipment costs. In this way your company procurement department transfers the risk of exceeding the budget onto the subcontractor. Any unforeseen activity expenses must be paid by the subcontractor. Great! Well, how do we specify a fixed price activity cost in Primavera P6?

From Tensix Read the post

What is a Project Plan?

In large enterprises with hundreds or thousands of capital projects, it is important to create standards to which all projects must adhere. This provides the organization the ability to roll up and assess overall project performance across the organization as well as look at resource capacity and other key performance indicators.

Read the post on Ten Six

Is Retained Logic the best Scheduling Option in Primavera?

Written by Amit Parmar

Primavera has three Scheduling Options to choose from when you are scheduling your project. Retained Logic is the default scheduling option. When you are building a Baseline, the default option works fine. But things change when you start updating your project, activities start getting delayed and do not get executed as planned.  You then have to make a decision on whether you want to continue using Retained logic or choose Progress Override or Actual Dates as your Scheduling Option. A lot has been discussed over the internet forums on which option is the best for a project and Retained Logic has won with an overwhelming majority. But I have a different opinion.

Has your project ever followed the exact logic that you planned in your baseline?

If your project has followed the exact logic as planned in your baseline then you are an awesome planner and you don’t need to read this blog post any further. But in my experience, on most of the projects activities don’t get executed exactly as planned in the baseline. Some start earlier than planned, some start later than planned and some might get delayed during execution. This is where Scheduling Options in Primavera play an important part. Choosing different scheduling options changes the way Primavera’s scheduling engine executes its calculations for Forward Pass and Backward Pass. This then changes the way dates are calculated for the activities in your project and it has an impact on your completion date.

The three scheduling options available in Primavera are:

• Retained Logic

• Progress Override

• Actual Dates

For this post let us assume 3 activities with names; Activity A, Activity B, Activity C. They are connected by a Finish to Start (FS) relationship. We will update them out-of-sequence and schedule our project with all the three scheduling options and see what impact does it have on our project.

1) Retained Logic – assumes that you wish to Retain Logic of your relationships when you are scheduling your project. This means that the remaining duration of an in-progress activity is not scheduled until all predecessors are complete.

Retained Logic- Retains the logic of your relationships while scheduling the project

Let’s take a look at an example and see how this works. We have updated our activities out-of-sequence on the following dates:

You can see above that Activity B has been updated out-of-sequence but Activity A is still in progress. We then choose Retained Logic as our scheduling option and schedule our project.  Due to Retained Logic, Primavera assumes that we are retaining the logic of relationships between our activities even though the activities are being updated out-of-sequence. This means that Primavera calculates the Remaining Start of Activity C as per Finish-to-Start logic with Activity A (and not Activity B).  This makes Activity C non-working between the period of 1-Feb-15 to 5-Feb-15. The non-working period can be seen in the Gantt chart below:

Lets review the calculations for this example; the Data Date for our project is 1-Feb-15. The scheduling engine calculates that for Activity A Remaining Early Finish is 06-Feb-15, due to this the Remaining Early Start for Activity C is calculated to 6-Feb-15. The scheduling engine is told to retain logic for the relationships and picks the Remaining Early Start for Activity C after Remaining Early Finish of activity A because Activity B is already complete.

The non-working period calculated due to Retained Logic can be misunderstood as, no work will be performed on Activity C between the time period of 1st Feb-15 and 05-Feb-15. This non-working period also adds an extra 5 days to the completion of the project. Now, the purists can make an argument that in such cases we should change the logic of the activity because the logic has actually changed. But if your contractual obligations do not allow you to make changes to your current project without approval of the client then it might force you to keep your relationships fixed and decrease the Remaining Duration on the activity to adjust the non-working period.

2) Progress Override – this scheduling option assumes that network logic can be ignored in case of out-of-sequence activities and the remaining duration of the activity can be scheduled without delay. This means that Primavera’s scheduling engine will ignore the relationship logic between the activities and schedule the activities without any non-working periods.

Progress Override – Assumes that relationship logic can be ignored for out-of-sequence activities

For our example this means that, Activity C will not have a non-working period and the remaining duration of the activity will be scheduled from the data date of the project as seen in the screenshot below.

Lets review the calculations for this example: The Date Date for the project is 1-Feb-15. The scheduling engine calculates that for Activity A Remaining Early finish is 6-Feb-15 and Activity B is completely finished. Due to this the Remaining Duration of  Activity C is scheduled from 1-Feb-15 and the relationship logic from Activity A is ignored. Since there is no non-working period in Activity C, it finishes on 19-Feb-15.

It is clear from the above example that Progress Override reduces the project duration by 5 days by not adding the non-working period. This seems logical according to the work that is being done on the project as you might be working on Activity C continuously and unlike Retained Logic there will be no non-working period.

3) Actual Dates – this scheduling option uses the Actual Dates for Forward Pass and Backward Pass calculations.

 Actual Dates – Uses the Actual Dates of the activity for Forward Pass and Backward Pass calculations

When you choose Actual dates option, the scheduling engine does the forward pass and backward pass based on the actual dates. This means that you can update an activity with an Actual Start and Actual Finish after the Data Date and Primavera will schedule the successor activities based on the actual dates of the activity. For this example we will finish Activity B after the data date of the project.

In the above screenshot we can see that the Data Date (Blue line) is 1-Feb-15 which is before the start of Activity A but Activity B has finished on 14-Feb-15, after the Data Date. Activity C is then scheduled after finish of Activity B and starts on 14-Feb-15.

Lets review the calculations for this example: The data date for the project is 1-Feb-15. Activity B has finished on 14-Feb-15 but both Activity A and Activity C are not progressed. When we schedule our project on 1-Feb-15, the scheduling engine schedules Activity A from 01-Feb-15 (data date) as the activity has no predecessor but Activity C is scheduled from 14-Feb-15 because Activity B has an actual finish on 14-Feb-15. This method eliminates the out-of-sequence logic from the project.

Actual Dates option can be used to fix dates for activities which you know will happen in future for sure.  It can be used in situations when we know that an activity will for sure finish on fixed dates and we want to schedule the successor activities after that actual date. While this sort of thing doesn’t usually happen on projects, we can use this option to prepare some what-if scenarios.

After looking at the above examples, we now know that Retained Logic and Progress Override are the two main options that we can use to schedule our projects. I prefer using Progress Override over Retained Logic for scheduling on my projects because I know it represents the actual scenario. It doesn’t add non-working periods to projects and potentially extending their duration. I know a lot of my readers will think otherwise, please comment below if you don’t agree with my justification.

Why Project Calendars Are Preferable to Global Calendars

One criteria on the scheduling review checklist used by a government naval command agency looks to confirm that calendars are defined at the project level. Why? Let’s explore this issue.

The Naval Facilities Engineering Command (NAVFAC) scheduling review checklist specifies that schedule calendars should be project-specific data and not global. Obviously, if you are submitting your schedule to NAVFAC then you have a compelling reason to use project calendars instead of global calendars. There are other sound reasons, however, that make project calendars preferable to global calendars. And these reasons may be the driving force behind the NAVFAC project level calendar criteria.

This article explores the reasons that Primavera P6 Professional project calendars are preferable to P6 global calendars.

The great thing about global calendars is that they are available to all users in the Primavera P6 Professional database, so all users have access to your defined global calendar. This is a double edged sword, however. Other users may not only use your global calendar; they may have the ability to actually change your global calendar. The implications are that their calendar changes are applied to any project schedule using that global calendar. Not good!

Another reason not to use global calendars is that exported global calendars clutter the recipient’s database. When you export a schedule assigned global calendars, those global calendars wind up in the global calendars list of the recipient importing your project. It’s amazing how quickly ones database becomes cluttered with rarely used global calendar definitions.

There is another reason not to export global calendars. Imported global calendars having the same name as global calendars already in the system are not renamed. They, however, inherit the properties of the global calendar currently in the system. So your global calendars of the same name, but in two different databases may not have the same global calendar definition.

Summary

Yes, it’s nice for your calendar to be available to all your projects and all your database users. Global calendars appear to be the way to go when creating a new calendar definition. But there are sound reasons for defining a calendar limited or restricted to a specific project.

Global calendars do not have the same security that project calendars have: other users can change your global calendar, and the respective schedules it’s assigned to. This alone compels schedulers to define project specific calendars. You may also clutter yours or your recipient’s global calendar list with rarely used calendars. There are also some export/import issues that may result in two global calendars of the same name, but with different date properties.

Primavera P6 Professional seems to favor global calendars as it makes it easy to convert project specific calendars into global calendars, but not vice versa. Despite this it is best practice to define calendars as project specific. 

reproduced from Tensix

Conscientious use of constrains

Generally, constraints affect the dates, violates the network logic and one of the reasons for negative floats or irrationality on the schedule. But again this is based on your project requirements and these constraints could help you to provide a complete control of a project however no more than 10% of a project’s activity should be constrained. 

Constraints other than contractual ones are generally not used since they impose specific start and or finish dates and in some instances completely OVERRIDE the logic that is contained in the schedule. The idea is to let the logic determine the dates as opposed to using constraints to do this.

Early constraints (e.g. Must Start/Finish On or After) are a typically a shortcut to represent the outcome of related work that the scheduler is excluding from the schedule logic. This is justified only for interfacing work that - in total, including its initiation - is clearly outside the scope of the project scheduled (e.g. contractual access restrictions, customer-furnished info/eqpt/permits.) Using early constraints for in-scope work (or for external work that depends on in-scope work) removes that work from logical schedule analysis, overrides the logically-derived scheduled (early) dates of the constrained activities and their successors, and jeopardizes the validity of the entire logical model of the project including float calculations.

 Late constraints (e.g. Must Start/Finish On or Before) are typically imposed to represent external obligations or commitments – aka “deadlines.” Such commitments can be imposed by contract (e.g. completion milestones) or by some other governing document (e.g. Project Charter, Board Instruction, Executive Tantrum, etc.) Late constraints can override the logically-derived (late) dates for the constrained activities and their predecessors, thereby complicating the interpretation of Total Float and identification of the “Critical Path.” Where multiple late constraints are applied in a network of related activities, Total Float becomes unreliable as an indicator of driving logic; then other methods of logical analysis must be used.

Other constraint types (Start/Finish On, or Mandatory Start/Finish) are even more restrictive with respect to driving logic flow – they are rarely if ever justified.

It is true that ALL constraints affect total float computations but so do the calendars being used, the remaining durations, the logic, the lags, the TIMES etc. So I would re-iterate that this clause was included in the scheduling specifications because constraints impose specific start and or finish dates and in some instances completely OVERRIDE the logic that is contained in the schedule.

The Case Against “Must Finish By”

When setting up a new project, the user will be faced with the “Must Finish By” option. Our advice is to leave it blank. Yes, every project has a finish date. Otherwise, it does not meet the definition of a project. That is to say, a project must be: (1) unique, (2) have a specified time frame, and (3) a defined scope of work. Unfortunately, projects often end up with a longer time frame and increased scope, but that is a subject for another day.

To review, the “Must Finish By” constraint is presented... 

Read the article on...

Creating a Believable Schedule

Defining activities is an important part of scheduling. Part of the complexity of the project is determined by the number of activities required to complete that project. When it comes to the size and/or placement of the activities, several control factors should be considered. Once the project has been broken down into unique definable elements of work, the duration of these elements must be accurately estimated. Accurate definition of activities and their durations creates all the elements necessary for a believable schedule.

Read the article on Ten Six

Process Control & Schedule Hierarchy

A Schedule Hierarchy defines the schedule control system and several interrelated levels of schedules at various levels. Schedule hierarchy provides a framework for project schedule development.

Primarily, there are following 4 level of schedules being applied on medium to large size projects to identify the scope and division and as well as contractual/project milestones.

Level I: Milestone Summary Schedule

Depicts overall time frame of project, covers total project scope and highlights contractual and Project milestones. This schedule is used by Management to highlight major and significant events as well as to communicate overall scope and status of project. This level schedule can also be used for decision making.

Level II: Summary Schedule

Level II Schedule is summarized by facility, discipline and areas for Engineering, highlighting long lead items, critical items for Procurement, and summarized by work package for Construction. Level II schedule establish requirements at the facility level, phase or work phase. It depicts the relationship between facilities/phases and establish facility criticality.

Level III: Detailed Engineering, Procurement and Construction Schedule

Integrated EPC Schedule where Engineering is sorted by discipline, grouped by systems/area depicting system requirement. Procurement identifies demand by facility/area or systems and as well identify the major equipment delivery. Construction/startup is grouped by system/area depicting interrelationships and timeframes. Level III Schedules establish the basis for staff requirements Task deliverables, material and subcontract requirements and bull release and installation rates. Level III schedule establish construction equipment requirements and integrates facility/area breakdown into system turnover packages. Level III schedules are maintained at regular basis and used for What-if analysis.

Level IV: Identification of detailed work plan, log list

 Level IV schedule is broken down at work activity level i.e., drawings, specs, data sheets etc. It depicts construction by work package/area/facility/craft/crew and establish construction sequence. Level IV schedule provides basis for detail construction work planning and rolling schedules and its a working document that is continually updated and revised to reflect project needs and circumstances.

Schedule Baseline Process

Schedule must be baselined to map it to current schedule to avoid slipages and to get early warnings. This also assists in developing planned S Curves and histograms to keep the current schedule on track.

Creating a WBS for Success

Projects can be overwhelming; no matter their size, the task of completing a project is daunting. That is why a Work Breakdown Structure (WBS) can be used to break down a project into manageable sections and help the project flow through execution to success. Creating a WBS requires project managers to strategically decide how they will lay out their deliverables, or work packages, in order to fulfill the project scope.

Read the rest on CPM Solutions

“How Do You Know When to Use a Constraint or Lag?”

QUESTION

“P6 lets me add constraints and lags to activity relationships. How do you know when to use a constraint or lag on an activity and which one is best for each situation?”

ANSWER

This question seems to be a favourite in our P6 training courses. Not all relationships are the same when it comes to project planning. External and internal factors can impose challenges that project managers have to deal with ASAP! There is no specific rule that says when to use a constraint or lag on an activity, but based on what each does we can make an educated assumption.

First, let’s talk about constraints.

CONSTRAINTS

Constraints are set in P6 to specify a date or a point in time when an activity can begin or end. Constraints can also be imposed on the entire project. Constraints can be thought of as “rules” – they are concrete in the schedule. Constraints are imposed by external forces, like a delay in delivery of materials or a date a stakeholder requires the project to be finished. Constraints are best used on milestones but can also be used on individual activities. A rule of thumb is that the less constraints you use the better.

You can assign two constraints to an activity if it can only be completed in a specific time frame. For example, if a site is only available from Feb 1 to Feb 14 for a 5 day activity, you could assign a “Start On or After” constraint to Feb 1 and a “Finish On or Before” constraint to Feb 14 to have the activity completed between these dates.

Constraints can ignore network logic, if needed, to meet the requirements you set. In this way, constraints can affect your project schedule negatively if you do not complete predecessor activities on-time.

Overview of Constraints:

• Constraints are used to set dates in the schedule that must be met.
• Constraints directly affect the activity they are set to, and then indirectly affect the predecessor and successor activities.
• Use constraints on milestone activities to meet deadlines.
• Constraints Lare “rules” that cannot be changed.
• Do not assign too many constraints, or network logic can be ignored.

Lags, on the other hand, do not set specific dates. Instead, you can set a delay or a lead time for a predecessor or successor activity. If you enter a positive number, you will delay the successor activity by the number of days specified. In contrast, if you enter a negative number (lead), you will reduce the length of time between the activity and its predecessor.

Lags are usually imposed by internal forces. For example, a lag could be due to drying time required for concrete laid. These are forces that are due to the nature of the activity, not by an external force. In this example, you could add a 10 day lag to wait for the paint or concrete to dry completely and to begin the next activity. The date of the next activity will change depending on when the predecessor activity is finished.

Overview of Lags:

• Lags are used to set delays or lead time between two activities.
• Lags affect the relationship between two activities (predecessor and successor).
• Apply lags to any activity type, but usually task dependent or resource dependent.
• Lags are calculated using the predecessor’s calendar.
• Lags are used when an internal force causes an activity to be delayed.
• Lags are more “controllable” within the schedule.

CONCLUSION

Both lags and constraints should be applied with caution because of the effect that it can have on the schedule. The main difference is that constraints should be used when there is an external force, whereas lags should be used when there is an internal force affecting the activity. As a best practice, always add a note in the activity Notebook tab to indicate why you are adding the constraint or lag to an activity so that other P6 users do not change anything without prior knowledge.

To Shorten The Critical Path

Project Managers are typically under great pressure to complete the project in as little time as possible. It is therefore imperative that project managers become familiar with the basic techniques to shorten the critical path and the many different ways to do this.

Read the post on Ten Six

The Negatives of Negative Lag

Are you looking for ways to fast track your schedule? Fast tracking or “crashing the schedule” can employ various methods, but typically takes activities that are scheduled in series and performs all or some of their duration in parallel to shorten the project’s planned or remaining lifecycle.

If you want to shorten your schedule by fast tracking then you most likely are considering the use of lags or negative lags, the latter otherwise known as ‘leads’.

Read the rest on Tensix Blog

Using Physical and Duration Percent Complete Types In Primavera P6

If you are looking for a quick way to update the progress of work on your Primavera P6 schedule or you want to describe the progress of work that has a non-uniform production rate, then you should become familiar with the different Percent Complete Types offered in Oracle Primavera P6.

Here we will start with the situation where you already have a schedule and associated baseline. There is demand for accurate, weekly updates on your project and you need an efficient and accurate way of modeling activity progress. This is where the different Percent Complete Types in Primavera P6 come in rather handy.…

See the article on the Tensix Consulting blog site.

A useful exercise would be to take the example schedule used in this article and provide weekly updates to it, comparing your results to those in this article.

Tracking Costs in Primavera P6

Do you know how to track schedule costs in Primavera P6? Most of us are familiar with the process of updating and tracking schedule activity progress from a time standpoint, but what about the cost of those activities? Well, Primavera P6 has features available for keeping track of the cost of labor, equipment, and material resources. It is also possible to track the cost of project specific expenses.

This article describes the process of tracking the cost of labor resources on a project. It considers a schedule where all activities are on the critical path, so a delay in any activity will result both an increased activity cost and project management cost.

See the rest of the post in Tensix Blog here

Using Level of Effort (LOE) Activities in Primavera P6

Level of Effort (LOE) activities are typically used to define effort that in and of itself doesn’t generate a deliverable, but does incur labor/costs to the project. Items such as management, security or safety are ongoing and require resources but are not on the critical path. These overhead costs are usually not immaterial. Overhead efforts can span part of the project, or the entire life-cycle. They are also associated with other activities in the project.

Modeling these efforts and cost individually by assigning resources to every activity is prohibitive. So how does one easily define the effort of these tasks throughout the life-cycle of the project? Well, Primavera P6 has a Level of Effort activity type to help you model this type of work in a low-maintenance way, and one that does not interfere with the critical path.
Read More in TenSix

Applying Hard Constraints to a Schedule in Primavera P6

When do you apply hard or soft constraints in Primavera P6? This is a question I had recently while working with a client and while there are no hard and fast rules as project specific circumstances can differ, here are some guidelines that may help. Many times the project schedule is influenced by certain constraints on the project. These constraints can be contractual, external, or internal.

Read More on Ten Six

BIM Implementation and Project Controls

As current regulations require BIM implementation for every public sector construction and infrastructure project from 2016 onwards[1]designers, contractors and supply chains in the industry wil l need to move on fast from their current ways of working and adapt to achieve compliance with the upcoming legislation. The policy is however, not a punitive one for the industry. It is a progressive plan to significantly improve industry efficiency, from the project management stage in design and construction to the subsequent operational management of the asset during its lifetime.

What is BIM?

Read more on  http://www.planningplanet.com/

Level of Effort Activities

I’m including three tutorials over the use of Level of Effort Activities on Primavera P6.

Setting Up LOEs and Resource Loading Them
Use of Level of Effort (LOE) activities to resource load a schedule.

Level of Effort and Percent Complete
Used primarily to resource-load an ongoing support activity in Primavera P6 schedule.

Use A Level Of Effort To Add Work Stoppage Info To A Project and Still Track To Your Primavera Baseline
When we develop a schedule we assume that an activity can be finished uninterrupted once it has commenced. But, sometime events occur which force the work on the activity to stop.

Be proactive.