Mike,

I’ve had mixed results in conversions - sometimes all goes spot on, other times there are differences, hence that little nagging doubt - it all looks ok, but is there something I’ve missed?????

In the earlier days of automated conversions the results were sometimes way out!

It would be interesting to know if changing/rescheduling P3 and P6 with larger programmes, (say 1000+ activites), gives the same result.

If it does then maybe we do have one conversion we can do in delay analysis that wouldn’t fall foul of the arguments posted earlier.

Similarly, I have never tested to see if there would be differences using the same software but different versions of it - say PowerProject V8 and V10. I know one planner who still uses V5!!!!!!!!!!

You would think it is safe to convert between different versions of the same manufactures software. P3 and later versions being the obvious odd one out due to the changes in operating systems. Would be nice to prove though that this is also safe.

Totally agree, I don’t trust the conversion process farther than I could throw the rack server that it is located on. Dual screen monitors with P3 on one and P6 on the other is how I check my schedules.

What I have found is that the softwares tend to calculate the future activities the same and the already statused activities are locked in. (Destatusing may reveal changes, have never tested it) The in progress activities and milestones are where most of the problems occur. I dont think there would be any differences in the two schedules.

Primavera produced a document that explains P3 to P6 conversions. I have it hosted on our website if you want to download it. (3.33 mb)

OnTrack P3 to P6

Not sure if its considered a no-no to share Primavera material. If it is I apologize and will take it down.

Mike

Toby,

I know what I’d prefer to do, transfer it.

But, if faced with software I am not familiar with I believe I have three options:

1. Decline the appointment - I guess you have to ask are you the right "expert" to do the job if you can’t use the software under consideration?
2. Find someone who is familiar with the software and oversee the analysis.
3. Transfer the programme and hope the other side isn’t clued up on the differences.

If it was adjudication, still in negotiations or similar I might risk 3. Litigation, arbitration or expert determination I would opt for 1. or 2.

Hi Andrew

The reason why I prefer PowerProject over p3 is the ability to produce summary chart prints to embed in a word document.

The PowerProject graphics in summary format are clear and precise.

I would not attempt an analysis in Microsoft Project because it is not up to the task.

I would put up a good reasons for switching in the narrative - I believe it would give my case an advantage in a tribunal.

Best regards

Mike Testro

Hi Mike,

Have never tried to do a whole analysis to compare but in the past I have certainly done planning on two sets of software - the agreed contract software, (MSP), and PowerProject or P3 as I had little faith in what MSP was telling me. Hence kept my own private programme using software I trusted - NOT a target and contract programme scenario but both were the contract programme, ie should be the same.

The results were often different and on many occassions I manually changed the MSP programme before submitting it so that it tied in with the results of my other programme.

Now that would be confusing in a delay case!!!!!!! (I’m not advocating others do the same either, I didn’t know then what I know now)

All,

The curse of being alone in a hotel, far too much time to think about work related issues! But some further thoughts for discussion:

In all construction contracts, hopefully some person, (CA), will be charged with administering and hence assessing the EoT due under the contract.

The CA can only do one of two things with regard to any EoT entitlement:

1. Precisely nothing, ie. make no decision at all, (not common but not unknown).

2. Make a determination on the EoT due, (most common).

In 1. the contractor is not challenging the decision of the CA as there is no decision to challenge! The contractor is therefore merely trying to prove his entitlement under the contract and in these circumstances he is generally free to prove that entitlement by any means he wants. The contract has not been performed by the CA as he has not carried out his obligation to assess the EoT due. Therefore I would suggest the argument that the CA could not have reached the same decision because different software was used does not apply in this case. The job of the judge or tribunal in this case is merely to ascertain the contractor’s entitlement.

But, there’s always a but, there may be other constraints that do raise valid arguments against the use of other software: see further below.

In 2. the CA has performed the contract and therefore the contractor in not now merely trying to prove his entitlement under the contract, but any dispute amounts to a challenge to the decision of the CA. The job of the judge or tribunal is now "to step into the shoes of the CA and review his decision". The key word being "review" and obviously a different role from 1. above. Therefore I would suggest the argument that the CA could not have reached the same decision because different software was used in this case does apply and you should therefore have prepared a very good answer as to why you haven’t used the same software!!!!!!!

Now here’s the but: In either case if the software to be used has been stated in the contract or subsequently agreed, (possibly even verbally), which probably covers 99% of contracts, this in effect means that the contracting parties have expressly agreed what software will be used to plan, manage and importantly, administer the project. By implication or otherwise they have therefore also agreed what software will be used to determine entitlement to any EoT due under the contract.

Fact: A delay analysis must be in accordance with the contract. Therefore in the circumstances of the last paragraph it would suggest that the same software should be used as doing otherwise would not be in accordance with the parties agreement or the contract. Changing software would amount to changing the parties agreement and or contract.

So:

If the circumstances of 1. apply, you might have a good argument not to use the same software.

If the circumstances of 2. apply, you should have a good answer prepared if you don’t use the same software.

If the "but" applies, you should have an extremely good answer prepared if you don’t use the same software.

If 2. and the "but" applies, just be worried, you’re in for a very hard time if the question of software comes up!

Just my thoughts, non of them have been tested in court as far as I am aware so all comments welcome. Hopefully some good arguments in the opposing direction.

How about, "Barrsiter X, i do indeed challenge the analysis of the EoT by the Engineer. In my defence, he used MSP, which is pants."

Hi Toby

I have never been in the box to be cross examined but I do recall the Laing v Great Eastern case where Gary France was able to show his barrister that the Laing baseline - using the old Hornet software - had been tampered with when a key link from scaffolding to weathertight had been deleted during construction.

If the barrister is well briefed by his expert he will know what to ask - based on the reliable maxim "Don’t ask a question unless you know the answer".

Best regards

Mike Testro

Michael,

Thanks for that. Having had a few wierd results when converting from different softwares I have trouble having 100% faith in the automated processes. Even when I’ve checked everything and all looks ok, there’s still that nagging doubt!!!!!

That said, do you know if you had identical programmes in P3 and P6 and you introduced identical changes into both, say you updated progress, added a few activites and changed a few links - would the two then reschedule to give indentical results? (Assuming the same settings were used in both of course)

Toby
Transfer from one to another software package always must be carefully observed. The German translation of "interface" ("Schnittstelle") has the same meaning as "cut"; it hurts.
Each software has a basis of design of its own. Any transfer will delete information. So you need a lot of experience with both packages to avoid losses of essential data.
First I check the project in the source package and modify if required before import into P6. As I’m experienced with MSP, P3, and P6, I would do transfers between them but not to/from e.g. Spider which I don’t know. This transfer would be once during the start phase of a project e.g. for the plans of subs. In general I don’t agree to regular transfers. As a solution we grant partners (limited) access to our database.
This is my humble opinion. I would like to hear from other solutions. Thanks Toby for this thread.

Regards
Dieter

I have preformed a hundred or so conversions between P3, P6, SureTrak and MSP. Most of them are "upgrades" to P6. None of them have been at the level of scrutiny of a claims case but I have a pretty good grasp on what errors to expect.

The number one issue is with the relationships of milestones to their predecessors and successors. In P6 a start milestone will be off if it is linked FS instead of SS. Incorrect ties on milestones will also translate to "edge conditions" where you schedule is off by one minute. This can lead to your entire schedule being off by one day.

P6 also treats "bad" logic ties differently. By "bad" I mean tying a 10 day activity SS +50 or tying a 5 day activity FS -10.

There are also issues with calendars and coding if they already exist in the database you are using. I assume most people would convert to a clean database though.

MSP allows duplicate resource names which I have had to delete before a conversion to P6.

My prime example would be taking a approx 8000 activity schedule from P3 to P6. The dates on all activities were off by some weird number (47 minutes i believe). I had to follow the logic back and correct any mistakes.

I have also done numerous conversions where the dates and resources match perfectly. I work with fairly simple schedule though, rarely using resources for more than just man hour calcs.

I think the question here is Why?

Why do you feel the need to transfer from one system to another?

If it is to simplify the programme, so that the effect of the event is clearer (without distortion) then use what you feel is better, but always have the original network stapled to the back to prove that all you have done is made the picture clearer, without changing any logic or programme information.

If it is because there is a problem with the system, or you cannot operate the original system, or you are an expert in another system and you feel that your case can be argued more succinctly, then do it, but again have the original network there at hand, as evidence that you have not altered the structure or form of the network/programme.

On a major project in Dubai, we used P3 to determine the effect of the event, but used MS Excel to reflect the ’simple picture’, this worked because within the claim, the ’simple picture’ was used in the Summary and explanatory notes, but the P3 print-outs were included in the detail.

In my opinion, a good way of doing it.

David.