Export Resources without Cost Data

The purpose of exporting Primavera P6 files in “XER” format is to transmit all of the project data to another database. In many cases we are not looking to exclude any data. So how do we avoid sharing sensitive cost data with other parties? Contractors may not want owners, subcontractors and other parties to have access to this proprietary information.

There are two options for not sharing cost data. One option is to delete resource assignments altogether. We do this by copying the schedule inside Primavera P6 and un-checking the “Resource & Role Assignments box, as seen below:

While this option works perfectly well, the recipient will see no resources or roles in the schedule. What if we want the recipient of this file to be able to see the resource units but not the unit prices? This requires a different approach. Option 2 involves creating a new user and associated user profile who is not allowed to view cost data. When this user exports the file the resource rates will disappear but the resource assignments and units will remain intact.

First, we create a new user and label that person in such a way that we remember why this user was created in the first place. Go to Admin → Users. Below, I have added a new user with the name “Export User”:

Note that I have given this new user access to every project in my database by assigning this user to the highest level in the Organization Breakdown Structure (OBS). This is not absolutely necessary but it does make it easier to export any project without cost data.

Second, we need to assign the new user a Project Profile that excludes the ability to “View Project Costs/Financials”. Go to Admin → Security Profiles and select Project Profiles. In the screenshot below I have added a new Project Profile, “No Costs Exported”:

Also, I gave this new user no ability to modify schedules because the only purpose of this user is to export projects sans cost data. As soon as the project has been exported I will log back in using my normal user name.

Now we are ready to export a project with cost data. Keep in mind that you will need to log in as the new user first!

From Bill Peppon

Percent Complete Type

The activity percent complete type is one of "Duration", "Units", or "Physical". The percent complete type controls whether the Activity % Complete is tied to the Duration % Complete, the Units % Complete, or the Physical % Complete for the activity. Set the percent complete type to "Duration" for activities which are duration driven, for example, administration tasks and training classes. Set the percent complete type to "Physical" for activities which are work-product driven, for example, creating a document or a product. Set the percent complete type to "Units" for activities which are work effort driven, for example, providing a consulting service.

Activity Percent Complete Fields

Physical % Complete

The activity physical percent complete. The physical percent complete reflects the actual progress made on the activity's work products so far. Physical percent complete can be manually entered by people familiar with the status of the activity's work products or it can be based on the completion of assigned Steps. Always in the range 0 to 100.

Duration % Complete

The percent complete of the activity duration. Computed as ((Planned Duration - Remain Duration) / Planned Duration) * 100. Always in the range 0 to 100. The planned duration is taken from the current plan, not from the current baseline.

Duration % of Planned

The activity actual duration percent of planned. Computed as (Actual Duration / BL Duration) * 100. The value can exceed 100. The BL Duration is the activity's at complete duration from the current baseline.

Activity % Complete

The activity percent complete. This value is tied to the activity Duration % Complete, Units % Complete, or Physical % Complete, depending on the setting for the activity's Percent Complete Type, which is one of "Duration", "Units", or "Physical". Always in the range 0 to 100.

Schedule % Complete

The Schedule % Complete specifies how much of the activity's baseline duration has been completed so far. Computed based on where the current data date falls between the activity' s baseline start and finish dates. If the data date is earlier than the BL Start, the Schedule % Complete is 0. If the data date is later than the BL Finish, the Schedule % Complete is 100. The Schedule % Complete indicates how much of the activity duration should be currently completed, relative to the selected baseline.

Note: Summary Schedule percent complete when displayed on an organize band, will ALWAYS be calculated as (BCWS* 100) / BAC, regardless of what earned value technique i. s selected for the activity's WBS.

Performance % Complete

Performance percent complete is used to compute earned value and may be based on the Activity % Complete, on the 0/100 rule, on the 50/50 rule, etc., depending on the technique for computing earned-value percent complete for the activity's WBS. The Performance % Complete specifies what percentage of the activity's planned worth has been earned so far.

Note: Summary Performance percent complete when displayed on an organize band, will ALWAYS be calculated as (BCWP * 100) / BAC, regardless of what earned value technique is selected for the activity's WBS.

The Longest Path

By Tensix Consulting

Oracle Primavera P6 offers two ways to define a critical activity in a project schedule. These are:

• Total Float less than or equal to [0.0h]
• Longest Path

Which one you use depends on three things. 1. the setting you choose in the Project view’s Settings tab: 2. the setting you choose in the Schedule Options dialog, and 3. that you understand the difference between the two options.  Primavera P6 defaults to the Total Float method.

This article is mostly about item three – what is the difference between Total Float criticality and the Longest Path? There’s some confusion about this in the industry because unfortunately the term “Critical Path” and “Longest Path” often get used interchangeably. In reality they are two distinct methods of calculating critical path and P6 can do either.

First, let’s take a look at the location of the settings for these two options in Primavera P6 Professional.

Critical Activity Definitions

Go to the Projects view of you Primavera P6 Professional application, select a project and then click on the Settings tab in the bottom layout.

You’ll see the default setting for defining critical activities in the area imaginatively named “Define Critical Activities”, in the lower area of the Settings tab.

This is the default behavior that will be offered to the scheduler when running the Schedule function.

However, this can be overridden at any time in the Schedule Options dialog, accessible from the Schedule dialog (accessed by clicking the F9 key or selecting Schedule from the Tools menu).

In here you select the Total Float less than or equal to [value in hours] or go with Longest Path.

Total Float vs. Longest Path

The difference between Total Float and Longest Path can be summed up in the following way. Total Float calculations look at the Total Float for each activity in the network. If its Total Float value is zero, then it will be flagged as a critical activity. However that doesn’t necessarily mean the activity is on the longest path; it just tells us that the activity is critical, and it may be so due to other factors.

The following example shows how the critical path appears when the Total Float method is used to calculate the Critical Path. Activity A1050 has a ‘Finish On or Before’ constraint that is equal to its planned finish date, so it and its predecessors are showing critical. If they slip, they probably won’t impact the end date of the project, but they will overrun their constraint date; which is why they are showing as critical from a ‘Total Float <= 0’ perspective.

However,  if the method of calculation is used these same activities will not appear as critical because there is a constraint somewhere along that path.  They will not in this case affect the end date of the project, so they are not on the longest path.

In this next example you can see the identical project schedule when it is calculated using the Longest Path method.

Previously critical activities are now showing as non-critical. Interestingly, they still have zero days Total Float, but P6 is ignoring them because they are not part of the longest path through the network.

The Longest Path through the schedule network will only consider activities as critical if they are on a contagious path from the start of the project to the end. Typically this is a single path upon which any activity that slips will impact the end date of the project.

Usage

Schedulers often use the Longest Path method when first developing the schedule. This gives them a clear idea of the activities that are driving the scheduled finish date for the overall project, without concerning themselves with complicating factors such as constraints, resource leveling, path divergence and convergence and other items that come into play when working a large and complex schedule.

Primavera P6 even has a “Longest Path” Boolean field that allows you to create a filter to see only activities on the longest path.

The Critical column and the Longest Path column will hold different values once a calculation of each type has been performed on the schedule at least one time.

With Primavera P6, you’re not committed to one method or another. At any time during the project lifecycle you can switch from Total Float to Longest Path depending on what you need to see. And at any time you can report on one or the other methods by using the Critical and Longest Path column values.0

5 Things You Should Know About Primavera P6 Calendars

Primavera P6 has a pretty smart scheduling engine built-in, but it’s not quite smart enough to know what time to tell the electricians to start in the morning and when to have lunch.

That’s where Primavera P6 Calendars come in. You can’t build a schedule in Primavera P6 without at least one calendar. So to help you master P6′s Calendaring features and understand how Calendars work with the scheduling engine, here are some essentials you’ll want to learn.

1 – Calendars are assigned to activities, not projects

That’s right. In Primavera, since a calendar is assigned to an activity, you have a extreme flexibility to use many different calendars within a single project. So perhaps the engineering work is scheduled with a 8 hr / day, Mon-Fri calendar. That won’t affect the construction activities which can have their own 12 hr / day, Mon to Sat calendar. It’s very common to use many different calendars on more complex projects with lots of trades who might have their own unique calendars.

But what if you need the entire project to use the same calendar? No problem, use the Fill-Down feature to copy the same calendar to all activities in your project.

2 – Calendars boss around the P6 Scheduler

If you create a calendar where Mondays are non-working days and assign that calendar to your project – you shouldn’t be surprised that Primavera P6 will NEVER schedule activity work on a Monday. The work and non-work rules you set in a calendar is adhered to strictly by Primavera P6′s scheduling engine. I never liked Mondays anyway!

3 – Calendars have 3 different time levels to work with

By time levels, I’m referring to:

• Hours of the Day
• Days of the Week
• Days of the Month / Year

When you create a Primavera P6 calendar, you can set these rules at each time level:

• Define what Hours in a day are workable and non-workable, eg: Start work at 7 am, end work at 7 pm.
• Set what Days of the week are workable and non-workable, eg: work from Monday to Saturday, Sunday are off.
• Pick what Days of the Month / Year are workable or non-workable, eg: July 1st is a corporate holiday.

4 – Primavera P6 Calendars come in 2 flavours – Activity and Resource

Activity Calendars are the most common and most of what we’re discussing here has Activity Calendars in mind. P6 Resource Calendars are used less often but essentially work the same way, in special situations.

For example, say you had a BullDozer that required a maintenance cycle every 2nd Friday for 2 hours. You could build a Resource Calendar in Primavera P6 specifically for that BullDozer, and captured the maintenance cycle. You could then tell Primavera to schedule work around the BullDozer’s maintenance periods. To do this, you would have to use a special Activity Type called “Resource Dependent”. There’s still a bit more tweaking and manual work to get the scheduling set properly which is why I think schedulers don’t bother going to such detail and avoid using Resource Calendars for scheduling.

5 – Changing an Activity’s Calendar can sometimes mess up your Durations

Occasionally, you will have to assign a new calendar to an activity. And occasionally, making such a change can cause the activity’s Original Duration to change. This can happen when the new calendar has more Hours / Day than the original. Now no one wants to their duration estimates to change randomly, so don’t worry, I’ve got your covered with an explanation and solution to potential calendar mayhem already.

From Planner Tuts

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.

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.

New Release 8.3 of Primavera Professional

The exciting news this week is that the long-awaited Primavera P6 R8.3 update is now available. This release includes updates for the Primavera P6 Professional client.

Starting with Primavera P6 Professional, very little about the client has changed from a visual perspective; always a good thing for existing users. What has been introduced is a new tool called the Primavera P6 Professional Visualizer: an attractive interface tool that brings together the original TimeScale Logic Diagram (TSLD) functions and a basic Gantt chart viewing tool. The Visualizer is an additional desktop application that can be launched from the P6 Professional Tools menu or from your Windows Start menu. Because it connects to the database directly you don’t have to have P6 Professional running to use it.

See here tutorial from Tensix in video.

Another new item is a Discussion tab in the Activity Details. This allows users to communicate via the software by posting comments against particular activities in the project.

Other features include XML import/export improvements addressing one-to-one matching of data items exported in XML formats to those of the original XER formats. Users can now exchange XML project files with users of earlier version of Primavera P6 going back to P6 R6.2 SP4.

The IPMR Data Item Description (DID), number DI-MGMT-81861 went into effect on July 1st, 2012 and part of this calls for a specific UN/CEFACT (XML) software-neutral export format for the IMPR Format 7.

For government contractors, this format is now available to Primavera P6 R8.3 users via the Export Format dialog as shown above.

Further items of note are the options to load or not load the project summary data upon startup of Primavera P6 and the option to use either online help or local help.

WBS product oriented or the return to WBS

We come back to the creation of the WBS as a master concept and tool large project. This return is motivated by a recent work experience where its development was based on a process control of extension achievement rather than focus on what is really important the products built.

The hierarchical nature of the WBS ensures that the entire statement of work accounts for the detailed technical activities and, when completed, facilitates communication between the customer and supplier on cost, schedule, resource requirements, technical information, and the progress of the work.

It is important that the WBS is comprehensive enough to represent the entire program to a level of detail sufficient to manage the size, complexity, and risk associated with the program. There should be only one WBS for each program, and it should match the WBS used for the cost estimate and schedule so that actual costs can be fed back into the estimate with a correlation between the cost estimate and schedule. A well-developed WBS is essential to the success of all acquisition programs.

Establishing a product oriented WBS is a best practice because it allows a program to track cost and schedule by defined deliverables, such as a hardware or software component. This allows a program manager to more precisely identify which components are causing cost or schedule overruns and to more effectively mitigate the root cause of the overruns.

A WBS breaks down product-oriented elements into a hierarchical structure that shows how elements relate to one another as well as to the overall end product. A 100 percent rule is followed that states that “the next level of decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element.”

This is considered a best practice by many experts in cost estimating, because a product-oriented WBS following the 100 percent rule ensures that all costs for all deliverables are identified. Failing to include all work for all deliverables can lead to schedule delays and subsequent cost increases. It can also result in confusion among team members.

Since best practice is for the WBS prime mission elements to be product-oriented, the WBS should not be structured or organized at a second or third level according to any element not a product or not being in or itself a deliverable.

While functional activities are necessary for supporting a product’s development, the WBS should not be organized around them. Only products should drive the WBS, not common support activities. Moreover, the WBS dictionary should state where the functional elements fall within the products and how the statement of work elements come together to make specific products.

A WBS should be developed early to provide for a conceptual idea of program size and scope. As the program matures, so should the WBS. Like the technical baseline, the WBS should be considered a living document. Therefore, as the technical baseline becomes further defined with time, the WBS will also reflect more detail.

Standardizing the WBS is considered a best practice because it enables an organization to collect and share data among programs. Standardizing work breakdown structures results in more consistent cost estimates, allows data to be shared across organizations, and leads to more efficient program execution. WBS standardization also facilitates cost estimating relationship development and allows for common cost measures across multiple contractors and programs. Not standardizing WBSs causes extreme difficulty in comparing costs from one contractor or program to another, resulting in substantial expense to government estimating agencies when collecting and reconciling contractor cost and technical data in consistent format.

Note:

1 - GAO Cost Estimating and Assessment Guide - Best Practices for Developing and Managing Capital Program Costs, 2009 - GAO-09-3SP

2 - GAO Schedule Assessment Guide - Best Practices for project schedules, 2012 - GAO-12-12OG