What is a Project Plan?

by Ten Six

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.

We recently worked with an organization that deployed Primavera P6 and needed to define these standards. They started with answering the basic question of what a project plan looked like to them.

The Basics Of A Project Plan

All projects are described within a document that defines the project’s objectives and scope. The project plan is mandated and is prepared in Primavera P6. The plan provides a structured statement of how and when the project’s objectives are to be achieved by showing the products to be delivered, activities to be completed and resources required. It is used to define the cost of the project over time. This provides the basis for the project budget through integration of the Primavera P6 plan with Oracle Projects (the project accounting tool).

A project plan is the:

• Structure
  • Enterprise Planning Structure (EPS)
  • Work breakdown structure (WBS)
  • Work packages
• Sequence of events necessary to deliver the project’s objectives
  • Activities and milestones
  • Logic and time schedule
  • Includes risk treatment
• Vehicle for planning the resources required and the cost of delivery
  • All chargeable resources and other scarce/critical resources
  • Contract spend
  • Time-phased cost profile
• Baseline against which performance is measured
• Mechanism for determining progress, costs and forecasts
  • Internal and contractor cost of work done
  • Schedule and cost performance (Earned Value)
  • Anticipated final cost
• Means by which the business can assess and analyze a collective view across all its projects

The plan covers the full scope of the project and can extend over several years. A baseline of the plan and its associated cost profile is authorized in Oracle Projects by stages according to the organization’s project life-cycle and the requirements of the relevant funding authority. The baseline provides an agreed reference for schedule and cost against which performance can be measured. Forecasts of the project schedule and cost provide visibility of the anticipated outcome.

Summary

While most of this seems pretty rudimentary, it is surprising how many organizations have significant gaps in their project management processes, particularly at the more detailed level. While defining what a project should contain and how it is planned may be an obvious place to start, organizations often miss other processes in the project life-cycle. These gaps can allow well-intentioned users to diverge from company standards. This can cause many problems including hampering the efforts to provide accurate consolidated views across the organizations portfolio of projects.

4 Easy Ways to Show the Critical Path in P6

1. Check the Gantt Chart

By default, the P6 Gantt chart will show your project’s Critical Path activities in bright red. This makes it easy to have a quick glance at the Gantt Chart et voila!, your Critical Path stands-out like a safety vest.

Hey! It’s not working! I don’t see any red Critical Path activities on my project. What gives?

Glad you asked.   Maybe your Gantt chart looks like this instead.

Primavera P6, by default, uses Total Float to decide if an Activity is Critical or not. Activities with a Total Float value of 0 (or less) usually show red on the Gantt. If you have no red Activities, you may have a Must Finish By date set on your project. If your project is finishing earlier than the Must Finish By deadline, then you may not have any activities with 0 or less Float values which means there are no Critical activities.

If that’s the case, tell P6 to show Critical Path by the Longest Path rather than by Total Float.

1. Press F9, and then click the Options button.

2. Find the setting “Define Critical Activities as”. Choose Longest Path.

3. Reschedule your Project.

4. Notice the Gantt chart now. You should see a red Critical Path now.

You can always read more about the Critical Path vs Longest Path.

2. Use the Critical Path / Longest Path Columns

Edit your columns and go digging for one called “Critcal” and another called “Longest Path”. Add one or both of these nifty columns to your Activity Layout to show clearly which activities are Critical.

3. Turn On a Filter

Using a Filter can also be a quick and effective way to manifest your Critical Path. Click the Filters button to turn on the Critical Path filter. This will show only the Critical Activities. There’s also a filter for the Longest Path.

4. Check the Schedule Log

Lastly, you can always check the P6 Schedule Log.  The Schedule Log is a log file that gets updated every time your project is scheduled. Press F9 and make sure the box labeled “Log to File” is checked on. Then, click the “View Log”button to open the Schedule Log.

Once you have the log file open in Notepad, you’ll have to scroll down to the section labeled “Exceptions”. But you should see in the log a list of your project’s Critical Activities.

See in Plannertuts.

Scheduling Best Practice Conundrums

by TheCobraGuy

The following are top tips from professional schedulers that will help keep your project on track:

There are some common mistakes made during the creation of project schedules, particularly by folks who are new to the art. In this article I’ll be pointing out a few of the most frequent scheduling faux pas that we encounter out in the field, and talk about common best practice guidelines and the dilemmas that these can throw at schedulers working in the real world.

I’m focusing on following guidelines that are common to many publications including Unified Facilities Guide Specifications (UFGS) and the PMI’s Project Management Body of knowledge (PMBOK).

1. Avoid Open-ended Logic.

2. Use as few constraints as possible.

3. Keep activity durations below 45 days unless they are Level of Effort (LOE) type tasks.

One problem I’m always wrestling with when it comes to using best practice guideline, is that they often seem to be contradictory. Following one guideline seems to cause you to have to ignore another. The following is an example of a best practice guideline that will get you into a dilemma.

Open-ended Logic

Various guidelines say to avoid open-ended logic activities that have no successors. This seems to be the most common issue I see in schedules, whereby an activity that has no successor and is just left dangling at the end of a chain of predecessors. If I ask the scheduler about it, the answer is invariably the same: “There are no other activities dependent on that activity, so there’s no successor”. In real-world terms, that actually makes a lot of sense; if there’s nothing dependent upon its completion, then there’s no dependency to illustrate.

However, best practice is to not have such dangling activities in the network. Doing so drops the activity out of the critical path and generates an unusually large Total Float value. Arguably you could say that if it’s in the scope of the project, at some point it’s going to impact the completion of the project, so if nothing else, make the project finish milestone its successor.

However on longer projects, this could really push the boundaries of acceptable Total Float limits; especially if the activity is early in the project life-cycle. And here’s where we start running into some guideline conundrums. The obvious solution is to add a constraint date to the end of the dangling activity. However, this can appear to be in conflict with the following general guideline:

Limit the use of Activity Constraints

Generally speaking the term “Constraint” doesn’t necessarily refer to the special Start or Finish date attributes that can be added to activities in most scheduling software tools. The term “constraint” can mean a relationship between two activities, the constraint being physical: i.e. the roof cannot be built until the walls are completed. It can also refer to a condition in a contract where a crucial delivery date is specified. This is referred to as an external constraint. However for our purposes, I am referring to constraints that can be added as special date attributes to activities in a software tool; dates that will influence the calculation of the critical path.

Many of the published guidelines recommend very limited use of activity constraints in a project schedule, that is: hard dates that are added to activities that will lock down the early and/or late dates.

If the dangling activity (or chain of dangling activities) delivers a major contract milestone, then the use of a hard constraint date is appropriate. This will reduce the overall float of the dangling activity. For greater schedule clarity, a Milestone should be added as a successor to the dangling activity and the constraint applied to it. Depending on how close the constraint date is to the current scheduled dates, this option will reduce or remove the Total Float for the open-ended chain. And if the scheduled date is already later than the constraint date, negative Float will be calculated indicating that you already can’t meet that contractual date and changes to the plan are required.

In the following example, we’ve added a contract deliverable milestone to the back of activity “G’ and then applied a hard Finish On constraint date. The constraint date is 3 days past the scheduled finish date for the activity, so we have 3 days of Total Float, rather than the 21 days we had before introducing the constraint.  We could still link the Contract Complete Milestone date to the Finish milestone, but if I slipped that badly as to push out the project end date, we’re in trouble anyway.  We could add a long lag between the new milestone and Finish milestone, but some guidelines also discourage the use of long lags and leads.  What you finally do will be a judgment call in the end, based upon the particulars of the actual work being modeled.

The guidelines that discourage the use of constraints are sound because too many constraints will mask the true critical path. It makes it harder to differentiate between activities on the critical path and constrained activities. I’ve seen schedules littered with constraints and it was nearly impossible to see the true critical path. Also it can potentially create bucket-loads of negative float, never a good thing. If the customer is schedule savvy, they will think that the dates cannot be met and constraints have been used to artificially paint a happy, but horribly unrealistic picture of workflow; underpinned by an inability to meet the goals of the project.

In short, only use constraints when you have a very good reason to do so. And even then use constraint types such as Start on or After or Finish On or Before type (soft constraints), that will still allow the schedule to shift in at least one direction if needs be.

Keep activity durations below ‘n’ days

I’ve seen this guideline in various publications with differing duration limits depending on the types of projects being scheduled. Of course such ongoing activities as Management, Safety, Security and so on may run the entire length of the project, but these are normally created as some kind of hammock: that is a task whose duration is dependent on activities to which it is linked.

Above: activity A1005 is a Level of Effort activity

Any activity that doesn’t create a deliverable can be of virtually any length; however discrete work packages that describe a particular package of work should be kept to a reasonable length. A common maximum length is to keep activity durations below three months. When the activity is longer than this, it suggests it’s functioning as more of a summary activity, and it probably represents many operations that could be broken down to smaller packets of work.

Figuring out the right level at which to break out the work and estimating the durations for activities can be a conundrum all of its own. There are various guidelines that discuss formal methods for doing this, such as Expert Judgment, Analogous Estimating and Parametric Estimating. Nevertheless, because the work can always be performed in more than one way, getting the activities at just the right level and duration for your particular project is always a challenge.

When creating your activity list, one tip is to keep in mind how the work’s status will be recorded. If the activity’s description covers more than one discrete step of the work, it will be difficult to track and apply status. For example you may have an activity named “Build Foundations”. For a small project, this makes sense as a single task because the entire operation may only take a couple of days. However if this is a larger building where the foundation takes a few weeks to complete, then it will need to be broken out into more discrete packages, such as “Dig footings”, “Wire Rebar”, “Build and Set Forms”, “Pour Concrete” and so on. With each of the activities being a few days long, status will be more discrete. The footings have been dug so that task is 100% done. If the activity was just called “Build Foundation”, and was 5 weeks long, what percentage of the activity is complete when the footings are done? So think about the need for accurate updating of status when you are considering the level of detail at which to create the activity as this often helps in estimating the durations too.

Summary

In the end, all guidelines are designed to give you the optimum way of achieving a viable schedule. They are guidelines and not hard and fast rules precisely because every schedule has unique challenges to overcome. As schedulers, dealing with the day-to-day challenges of putting together a viable schedule, being given guidelines can be a prickly subject, particularly when you know you’ll have to ignore some of them in order to make the schedule reflect the reality it is attempting to model. When challenged about scheduling guidelines I simply say this; “if you can defend it, and there was no better way to do it, then just do it”, even if you’ve had to ignore a guideline or two to make it happen.

Primavera P6: Critical, or not so Critical?

by TenSix

Many scheduling guidelines including the PMI’s PMBOK (Project Management Body of Knowledge) use the term “near critical’ to describe activities in a schedule that are within a few days of joining the critical path; that is to say they only have a few days of Total Float.

Because Primavera P6 Professional has such a flexible method for defining how activity bars appear in a Gantt chart, you can create extra bars whose appearance can be controlled by the amount of Total Float they have. This allows you to easily see near critical activities in a Gantt chart.

This blog shows you how to create activity bars that appear different to standard red, blue and green bars when the activity is near critical.

The process of creating a near critical bar starts with the creation of a Filter. This filter is then used by an additional bar that you define in the Bars dialog of Primavera P6 Professional.

Create a Near Critical Filter

Open the Filters dialog and click on the New button.

Create the following filter:

This will show any activity whose Total Float falls within 0.1 days and up to 10.0 days. You should test this filter on your schedule before proceeding to the next step.

Create a Near Critical Activity Bar

The next step is to create a new activity bar style in using the Bars dialog.

Right-click in the Gantt chart area of the Activities view to open the Bars dialog.

In the Bars dialog, scroll down to and select the current Critical Remaining bar in the table area. This will cause a new bar to appear below the selected bar when you click the Add button.

Upon clicking the New button, a new default bar appears on below the selected row. You then need to name this new Bar in the Name column; we suggest “Near Critical”.

In the Timescale column, set the value to “Remain Bar”, and then set the Filter column by selecting both the Normal and Near Critical filters.

Finally set the Bar Style colors and patterns that you want for your near critical bar. In the following example we’ve simply set the bar to an orange color.

Once you apply the new bar to your layout, you can see any near critical activities showing as orange in the Gantt chart.

You can take this a lot further than just near critical. Using the same techniques, you could create filters for ‘Potential Critical’ whereby the activity has between 10 and 30 days total float, or perhaps even super-critical where there is negative float making a darker red bar appear. Of course the different bars we can create based upon some condition are only limited by our imaginations. One of our customers uses different bar colors to indicate a particular activity code setting, to give just one example. Perhaps you have already made use of this capability? If so, drop us a line – we’d love to hear about it.

Variance Reporting in Primavera P6 Professional

Variance Overview

Variance reporting in Primavera P6 requires that the project has a baseline and it is assigned as either a Project Baseline or a Primary Baseline.

Before attempting variance reporting, you should check the baseline being used for the project. To do this take a look at the information bar at the bottom of the Primavera P6 window.

Baselines are assigned using the Project | Assign Baselines… menu option. The resulting dialog allows existing baselines to be assigned as a Project Baseline or Primary, Secondary or Tertiary baseline.

With a baseline in place it is possible to report any activity that has moved away from its baseline date in the current project schedule.

Variance Reports are typically created using filters that look for values other than zero in the Variance fields available in P6.

You can see the available variance fields using the Columns dialog in P6 as shown in the following figure:

Variance Fields Prefix Explanation

Fields prefixed with Variance – BL Project contain variance values based upon the baseline project assigned as a Project Baseline.

Fields prefixed with Variance – BL1 contain variance values based upon the baseline assigned as the Primary Project.

Fields prefixed with Variance – BL2 and Variance – BL3 contain values based upon the secondary and tertiary baseline assignments for the project respectively.

Therefore, if you want to find out how the current project is performing compared to the Project Baseline, you would look for non-zero values in the Variance – BL Project fields.

Common Variance Filter Options

To find out which activities are no longer scheduled to start or finish on their original baseline dates according to the baseline assigned as Project Baseline, you would create the following filter using the Filter dialog:

If an activity has slipped from its baseline start or baseline finish date, the Variance – BL Project Start Date and Variance – BL Project Finish Datefields will contain a value other than zero and the activity will be displayed in the Gantt chart.

If the Bars dialog is configured to show the Project Baseline bars, you will see the slippage visually on the schedule. You can also display the Variance – BL Project fields you’re filtering on in the activity table to see by what amount the activities vary from the baseline.

More Variance Filter Examples

Exclude Completed Activities

The following filter will show all activities that have a variance and do not have an Activity Status of Completed.

Only Show Activities Starting Late

In this example the filter has been changed to only show values of less than zero variance. In other words, the variance is negative which will only show activities that will start late. If the activity is starting earlier than the baseline, it will not appear in the Gantt chart using this filter.

Once the Gantt chart is displaying the required fields and activity data, the File | Print Preview menu option can be used to run a variance report.

Note: Filters can be saved with the named layout and will be activated whenever the layout is opened.

From Ten Six

Primavera P6: Time Distributed Reporting and Microsoft Excel

by TheP6Pro

It’s common practice to use Primavera P6 Professional’s Time Distributed reports feature to create time-phased tables of data that are then exported to Microsoft Excel. However, if you’ve ever done this you may have noticed that in many cases the Subtotals row can be one column too far to the left.

This misalignment invariably requires you to go through the entire spreadsheet deleing cells to bring the data back into alignment.

However there’s a better way to permanently solve this problem and good old Ten Six Consulting will show you how right now.

In the Reports view, right-click on your Time Distributed report and choose the Modify button.

When you see the following prompt, click the Yes button.

Clicking Yes will open the Report editor as seen below. This is the underlying canvas that gets created by the wizard when you initially build a report. While it is possible to build a report from scratch using this feature, we do not recommend it as it can be a little time consuming: rather you should always create your reports first using the Report Wizard.

The Report editor allows you to add or remove fields used in the population of the final report output in P6. In this case we’re going to add a field to the sub-total row in order to solve our issue with the misaligned spreadsheet data. The Subtotal field is spanning the space of the Activity ID and Activity Description fields in the data row above. Therefore the subtotals get written on a row that has one less column.

Adding a new field to the Report

First we need to make some room for a new field, so we click on the right-hand end of the Subtotals field and drag it right to about half its original size.

Now we right-click on the row behind the Subtotal field and from the menu choose Add Text Cell.

This places a text cell on the same row, at the far right end and opens the cell’s Properties dialog.

In the Cell type field, select Custom Text and then close the properties dialog using the small x button at the top right.

The next step is to drag the new cell over to the left of the row. This will add a column to the CSV file that is opened by Excel in the final stage of this process.

Without further modification this cell placement won’t look very pretty in the report preview; however as it’s primarily for creating spreadsheets that doesn’t matter.

Finally click the OK button to close the report editor and then run the report, saving it to an ASCII text file using the example settings below.

In the final spreadsheet, you can see that the addition of a new text field has caused the data to come out correctly in line with the headers.

Thanks Ten Six.

Earned Value Management (EVM) – To Do or Not To Do

by Ten Six

Why should we do Earned Value Management (EVM)? For those of us who implement Earned Value Management Systems (EVMS) regularly within many different organizations, we hear plenty of reasons why an organization shouldn’t do EVM. At the end of the day, most organizations implement an EVMS because they need to comply with a government contract.

Why We Shouldn’t?

Here are some of the most common reasons why organizations don’t want to implement an EVMS:

· Too bureaucratic.

· Too expensive to implement.

· Too many people are required to administer an EVMS.

· Special IT tool-sets are required.

· The Baseline cannot be established early…development programs have too much uncertainty, let’s wait and see.

· “This program is too small to need such an intrusive tool.”

· “We’re only a small company and can’t afford this.”

· “This program is too big…Earned Value is meaningless to us.”

Those are some of the quoted reasons and more often than not, there are other hidden issues that are not shared so readily. These include:

· The objectivity an EVMS provides leaves nowhere to hide.

· We’ll have to do detail planning ahead of the game and are not willing to make that much effort.

· EVM will reveal more details about actual costs than we want Internal or Customer Management to know.

· We don’t want to undergo a Customer based Integrated Baseline Review (IBR) to prove our baseline is valid.

Number 4 above is amusing as it implies that they have a choice whether or not to conduct an Integrated Baseline Review with their customer.

Why We Should?

It won’t be a surprise to anyone that the number one reason to implement a robust EVMS is because it’s a contractual requirement. In fact, the government and agencies have different contract Dollar thresholds where EVM must be a contractual requirement. You can see some examples of these in the table chart here.

Here are some reasons why you should not only implement an EVMS but also embrace it for all programs:

· The Government requires EVM to see cost and schedule variances in order to mitigate issues before they are too large.

· Non-compliance with the Government could be very costly and they do have deep pockets to pursue you.

· The 32 Guidelines reflected in ANSI/EIA-748 represent sound project management principles. Of these Guideline groupings, which do you think should not be reflected in your company’s processes to effectively set up and manage your programs?

• Organizing: Defining the work and assigning responsibility/accountability for its performance?
• Planning & Budgeting: Developing a definitive plan to monitor how you’re going to get there and the costs required?
• Accounting: Establishing cost charge numbers to accrue direct & indirect costs by major element. This will help in comparing actual to planned costs?
• Analysis: Routine review of cost & schedule performance to date to see where you’ve gone off target, understand how it’s going to get fixed and what it’ll ultimately cost?
• Revisions: Maintaining a track record of changes made to the contract with the impact to the cost and schedule baselines to use for the next similar program?

It’s true that implementing and executing an ANSI-748 EVM compliant project management plan does require effort by both the project team and senior management. The alternative of not establishing a solid plan to manage a contract’s scope, schedule, budgetary and risks could result in project failure and a financial pressure on your organization. Is it worth the risk to not do EVM?

What about Firm Fixed Price?

Firm Fixed Price (FFP) contracts often do not require EVM as all the risk is on the contractor. But it does beg one question. Why would a company that’s taking on a FFP contract that has them bearing all the cost and schedule risks not do EVM? They are effectively in a position to not know their potential cost and schedule exposure risks. Are you willing to bet your company that everything will work out OK?

Summary

Earned Value Management is essentially best practice project management. Getting bad news on project performance early enough to take action is a lot less painful than the consequences of project failure and contractual non-compliance.

In complement to this post read this.