Consolidation process - checking file formatting beforehand

[Roger]

HI,
I've got 25 project files that require consolidation to a master file
(MS Proj 2000).
There is a mixture of formats being used by various Proj Mngrs, and
some files have been baselined whereas others have not.
Existing formatting varies across all the projects i.e. the tracking
gantt displays are different in bar shading, colors, shapes for
milestones etc.
Little or no use is made of text or other columns.

With the styles of use varying as much as there are PM's, what are the
key essentials I need to be aware of in working towards a consolidated
file?

Roger

 

[Rod Gill]

What are your business needs for the consolidated file?

--

Rod Gill
Project MVP

Project VBA Book, for details visit:
http://www.projectvbabook.com

NEW!! Web based VBA training course delivered by me. For details visit:
http://projectservertraining.com/learning/index.aspx

 

[John]

HI,
I've got 25 project files that require consolidation to a master file
(MS Proj 2000).
There is a mixture of formats being used by various Proj Mngrs, and
some files have been baselined whereas others have not.
Existing formatting varies across all the projects i.e. the tracking
gantt displays are different in bar shading, colors, shapes for
milestones etc.
Little or no use is made of text or other columns.

With the styles of use varying as much as there are PM's, what are the
key essentials I need to be aware of in working towards a consolidated
file?

Roger

Roger,
In addition to Rod's comment let me add the following. In a dynamically
consolidated master, the subprojects are not actually part of the master
file. The master only contains pointers to the actual subproject files.
That means that the formatting of the subprojects is NOT carried forward
to the master. For example, if one PM uses green bars for normal tasks,
that green bar formatting will not appear in the master. The master can
be formatted independently of the inserted subproject.

John
Project MVP

 

[Roger]

What are your business needs for the consolidated file?

--

Rod Gill
Project MVP

Project VBA Book, for details visit:
http://www.projectvbabook.com

NEW!! Web based VBA training course delivered by me. For details visit:
http://projectservertraining.com/learning/index.aspx

Business needs for consolidating these files are for
1. Team Leaders (2 of) keeping across dependencies, both project and
programme milestones, slippage in time or cost, resource management.
2. Reporting purposes to the Programme manager (team leaders report
to Prog Mngr) who then reports to Exec providing a thumbnail overview
off the programme, the achievements accomplished through the reporting
cycle, existing issues and general 'stuff'.

There is no 'resource pool' managed by either the PM's nor by the
Programme controller as such. Resources are managed on a negotiated
basis with another Operations team, and conflicts can arise with
overbooking of key personnel.

 

[Roger]

Roger,
In addition to Rod's comment let me add the following. In a dynamically
consolidated master, the subprojects are not actually part of the master
file. The master only contains pointers to the actual subproject files.
That means that the formatting of the subprojects is NOT carried forward
to the master. For example, if one PM uses green bars for normal tasks,
that green bar formatting will not appear in the master. The master can
be formatted independently of the inserted subproject.

John
Project MVP

John thanks for clarifying that point.
If dependencies are then setup in the master, are they then reflected
back into the subproject files via the dynamically linking?
I've chatted with some of the PM's and they are simply not keen on
having changes made to their projects done by 'Software'...they'd
rather do this verbally and then update their own projects to show
these dependencies.

Regards
Roger

 

[Rod Gill]

I recommend creating consolidations weekly by inserting each project into a
new file with the Link option (in Insert, Project) turned OFF. This copies
all tasks and creates a snapshot. It also consolidates all resource
information so showing resource needs across all projects.

You need to use the same flag (EG Flag1) in all projects to flag project
and program milestones.

Make sure all business deliverables for each project are included (and
flagged with another Flagn field) and also flag key tasks Execs are
interested in. Then you can create Views for each report in Project and use
the organizer (Tools menu) to copy them to the Global.Mpt file. Your Views
etc will now be available in the new master project for you to print with
etc.

--

Rod Gill
Project MVP

Project VBA Book, for details visit:
http://www.projectvbabook.com

NEW!! Web based VBA training course delivered by me. For details visit:
http://projectservertraining.com/learning/index.aspx

 

[John]

John thanks for clarifying that point.
If dependencies are then setup in the master, are they then reflected
back into the subproject files via the dynamically linking?
I've chatted with some of the PM's and they are simply not keen on
having changes made to their projects done by 'Software'...they'd
rather do this verbally and then update their own projects to show
these dependencies.

Regards
Roger

Roger,
If the master is dynamic, then data changes, (not format changes), are
reflected in the subprojects, and vice versa. This includes dependencies
between tasks. However there are two types of dependencies - those
between tasks within a given project and those that go between projects.
That latter are called external predecessors/successors. For external
dependencies between subprojects, it is actually easier to create them
in the master since each subproject involved must be visible and active.

I understand the reluctance of your PMs (i.e "don't mess with my file!")
but I think they need to be more open minded. Verbal exchange is one
approach but it is prone to human error, doesn't really integrate the
overall project, and it doesn't let the application do the work (i.e.
pull everything together). My recommendation is to let the application
do what it is designed to do and then have regular communication among
the PMs and with program management to coordinate the schedule dynamics.

I see Rod recommended a weekly static consolidation and that might be a
good approach for your situation, but be advised that if external
dependencies are used, they will NOT survive a static consolidation. In
other words, if external links exist between subprojects, they will not
be retained in a static master. I ran in to this problem years ago and
wrote a VBA macro that does maintain external dependencies when a
dynamic master is converted to a static master. The macro I have is NOT
freeware, but if you are interested, let me know.

John
Project MVP

 

[Roger]

Roger,
If the master is dynamic, then data changes, (not format changes), are
reflected in the subprojects, and vice versa. This includes dependencies
between tasks. However there are two types of dependencies - those
between tasks within a given project and those that go between projects.
That latter are called external predecessors/successors. For external
dependencies between subprojects, it is actually easier to create them
in the master since each subproject involved must be visible and active.

I understand the reluctance of your PMs (i.e "don't mess with my file!")
but I think they need to be more open minded. Verbal exchange is one
approach but it is prone to human error, doesn't really integrate the
overall project, and it doesn't let the application do the work (i.e.
pull everything together). My recommendation is to let the application
do what it is designed to do and then have regular communication among
the PMs and with program management to coordinate the schedule dynamics.

I see Rod recommended a weekly static consolidation and that might be a
good approach for your situation, but be advised that if external
dependencies are used, they will NOT survive a static consolidation. In
other words, if external links exist between subprojects, they will not
be retained in a static master. I ran in to this problem years ago and
wrote a VBA macro that does maintain external dependencies when a
dynamic master is converted to a static master. The macro I have is NOT
freeware, but if you are interested, let me know.

John
Project MVP

John hi,
Excellent comment and very helpful.
Can I clarify the terminology here please?
The wording used and differences or understanding in the wider PS
Project community relating to "dependencies" and "predecessors/
successors". I know you have qualified this with the word 'external'
but in general are they not talking about the same thing?
Dependencies used locally here mean both internal to the project and
across many projects.
With our risk assessment process, we use the term dependency to mean
internal and external to the project. Are we out of step with the
wider community here?
Regards
Roger

 

[John]

John hi,
Excellent comment and very helpful.
Can I clarify the terminology here please?
The wording used and differences or understanding in the wider PS
Project community relating to "dependencies" and "predecessors/
successors". I know you have qualified this with the word 'external'
but in general are they not talking about the same thing?
Dependencies used locally here mean both internal to the project and
across many projects.
With our risk assessment process, we use the term dependency to mean
internal and external to the project. Are we out of step with the
wider community here?
Regards
Roger

Roger,
You are relating the dependency to who is doing the work - within your
company (internal) or outside your company (external).

However, for Project, (the application), internal dependencies (i.e.
predecessors/successors) are defined as links between tasks in the same
project file, regardless of who owns the file or who is doing the work.
External dependencies are links between tasks in different project
files, regardless of who owns the files or who is doing the work.

I wouldn't necessarily say you are "out of step" with the wider
community but your definition of dependencies is not consistent with the
Project application itself.

John

 

[Roger]

Since the various inconsistent formats in the various files have just grown
up like topsy according to the whim of the various people who made them, you
should consider scrapping them all and coming up with a consistent set of
formatting rules, documenting them and agreeing on them.

You don't actually have to scrap them entirely, but you do need to get back
all of the original formatting and all of the original Views (which is where
the formatting is) as it was in the global.mpt file. Most likely, all of
your PMs have just exercised their artistic formatting license on the
original Views rather than created new Views with distinctive names (names
should start with something like "AAA..." so that they stand out from the
originals and appear at the top of the lists.

This poor housekeeping (just changing the formatting in
existing/built-in/original Views) was a mistake from the start because this
is exactly the kind of problem that it creates.
But it is fairly easy to clean up if you are ruthless.

They can still save their precious formatting by re-naming the Views and
recovering the originals from the global.mpt with the organiser.

Formatting is only the appearance of the Views and is not the data or the
project modeling or the project tracking, so it could be scrapped without
much loss.
You are lucky that different people have not used all of the spare Flag,
Date, Duration, Text etc fields in different ways, since this would be
harder to clean up.
On the other hand, why haven't these been used? Don't the PMs know how?
I would be a bit concerned about PMs who seem to have plenty of time to fool
around with the formatting in an ad-hoc way and then get precious about it,
but don't seem to have cottoned on to the many productive uses of the MSP
spare fields.

Trevor hi and thanks for the response.
Nail on the head stuff there.
The position that I'm in ends up being political at the end of the day
- I'm being asked to provide data from a collaborative approach, but
I'm not allowed to make the collation of this data easier by linking,
or impacting the individual project files. The wording previously
used in this post was 'precious'....aptly put I think.

Regards
Roger