Compare Project Versions Utility

[Jim Aksel]

I have a program with a master file and some subproject files. We link
between the subproject files. Data is submitted from a subcontractor monthly.
So, we have folders for each month end of data. That is, the Master.mpp and
its subprojects are all stored in a monthly folder... J08, F08, etc.

We can detect if our subcontractor is slipping a software capability by
examing the successors for tasks. If the succesor is linked to "June
Release" one month and then "Auguest Release" when they next submit the file,
we can find it. This exposes a contractor who is staying on time with his
software release by putting less and less capability into it.

Using the Compare Project Versions Utility seems to be a good method to
locate this quickly (we have to run the utility anyway). Specifically, if I
run the utility on the Predecessors/successor fields, I'd like to be able to
catch the change.

However, external dependencies on the files produce different path names to
to the predecessor/successor fields. This is becuase I am essentially
comparing C:\March2008\Master.mpp against C:\April2008\Master.mpp. As you
can see, the external links will contain different text.

Any suggestions on the file compare? My initial thought was insert a Text1
field into the comparison project and hit it with a formula. For example,
most of the file path is going to be the same, excpet for one folder name
\\server\folder1\subfolder1\Master.mpp vs subfodler2\Master.mpp I figured
maybe all I care about is the last couplde of characters. However, that
gets burdensome if there is an inserted line in either file.

Perhaps compare on UniqueID predecessor/successor? Again, the path name is
going to be different.

What saeth the crew?

 

[Jim Aksel]

And now for the twist.... There can be multiple predecessors or successors
per line. Now I am thinking fish for ".mpp\" and then work around that with
the unique ID some how.

 

[John]

And now for the twist.... There can be multiple predecessors or successors
per line. Now I am thinking fish for ".mpp\" and then work around that with
the unique ID some how.

Jim,
I'm surprised you are using the Compare Projects utility on a master
file because as far as I know, it doesn't work with master files since
the indexing used by the underlying code is based on the Unique ID
field. Also, from user posts over the last year, that particular utility
seems to be less stable - it generates failures on apparently innocuous
files. I'm told the code for the utility is being upgraded for the next
release of Project - whenever that is.

You should however be able to run the utility on each individual
subproject, as long as the Unique ID structure remains intact (i.e. the
file wasn't rebuilt for any reason) and you don't get runtime failures.

Assuming you are running the compare on just the subproject, I guess you
could try creating a custom field with a formula to break down the
predecessor text string. I've used a similar method before in one of my
macros. It's a matter of searching for each ".mpp" and backing off to
find the linked unique ID value. Once the string is broken down into the
relevant information, the compare should be able to highlight changes.

The above approach might get a little messy with just a formula. I
suggest you create a macro to populate the spare field with the decoded
data and then run the utility.

John
Project MVP

 

[Jim Aksel]

Thanks John, this is useful. We do not have too much trouble with File
Compare even on Master Projects believe it or not. Yes, it occassionally
locks up for no good reason .... only when we are in a hurry. That said, the
benefits outweigh the frustrations.

We kicked this around some more this morning and realized there is no way
around the path name string on the predecessors/successors.. For others
reading this, what this implies is the only way to really do this is to write
some code (not a formula) that will address the Unique ID of the
predescssors/Successors and strip the path information off as John and I
described.

It is necessary to use UniqueID becuase the project files may have deleted
or added other tasks which will shift the task ID. So, best to approach this
in code and hit the Dependencies Collection. Iteratete through that.

All things considered, we are going to use a different approach. Certainly
learning that successors have changed in a file is valuable informatiion. We
are going to look at Finish dates instead.... In this case, we want to
discover if a software capability is slipping release dates. The best
approach is searching for changes to successors of when items transfer from
development to integration.

In this specific case, we can derive the information "forensically" by
examining Finish Dates. A creeping finish date is going to be a tell tale
sign. Fortunately, Jimmy can get this field in the Compare Utility very
easily....

--
If this post was helpful, please consider rating it.

Jim

Visit http://project.mvps.org/ for FAQs and more information
about Microsoft Project

 

[John]

Thanks John, this is useful. We do not have too much trouble with File
Compare even on Master Projects believe it or not. Yes, it occassionally
locks up for no good reason .... only when we are in a hurry. That said, the
benefits outweigh the frustrations.

We kicked this around some more this morning and realized there is no way
around the path name string on the predecessors/successors.. For others
reading this, what this implies is the only way to really do this is to write
some code (not a formula) that will address the Unique ID of the
predescssors/Successors and strip the path information off as John and I
described.

It is necessary to use UniqueID becuase the project files may have deleted
or added other tasks which will shift the task ID. So, best to approach this
in code and hit the Dependencies Collection. Iteratete through that.

All things considered, we are going to use a different approach. Certainly
learning that successors have changed in a file is valuable informatiion. We
are going to look at Finish dates instead.... In this case, we want to
discover if a software capability is slipping release dates. The best
approach is searching for changes to successors of when items transfer from
development to integration.

In this specific case, we can derive the information "forensically" by
examining Finish Dates. A creeping finish date is going to be a tell tale
sign. Fortunately, Jimmy can get this field in the Compare Utility very
easily....

Jim,
You're welcome and thanks for the feedback. The idea of using just the
finish date is a whole lot easier. Once you find a difference, then you
can go back and find out why.

John
Project MVP