Linked tasks - LOST LEVELS!!!

[John]

I'm a big believer in the right person to do the job and the Project Manager
is the one responsible for the organization of the project work. He
certainly does the scheduling in conjunction with the functional managers.
He doesn't try to micro-manage but the bottom line is since it's his neck on
the line to bring the projects in on time and in budget, he has to have the
final say - the buck stops with him. As such, he or she or his delegate is
the ONLY one that should ever update the plan itself except for posting
actual progress.

Steve,
Ok, how about the philosophy that says the Program Manager's delegates
are the cost account managers (CAM) responsible for the detail work? In
my view of the world that is called shared responsibility AND
accountability. I find many people don't embrace accountability and in
my opinion they shouldn't participate in the rewards at the end. When
everybody has a say in the plan there is a much greater chance of
buy-in. Everybody wins and the plan has a much greater chance of success.

How many times have you had one of the performers say, "that's not my
plan, that's your plan". I've heard it too many times. Obviously, in
those cases the validity of that part of the plan worked by that person
is questionable.

In a "shared pain, shared gain" method of working a plan, each CAM has
their own file and they update their own files (sometimes
simultaneously). Through the linked master file and regular reviews
(timephased appropriately for the statusing period), the Program Manager
has oversight (and more importantly insight). The Schedule Manager has
responsibility for ensuring CAMs follow the rules (company and Project)
for laying out and maintaining their plans. And yes, sometimes a CAM
might update their plan only to find out that a driving task in another
CAMs file changes things. There is just no substitute for verbal
communication between team members.

The bottom line - a shared approach does work and I believe it is better
- for the employees (at all levels), for the company and for the
customer.

John

 

[Steve House [MVP]]

Steve,
Ok, how about the philosophy that says the Program Manager's delegates
are the cost account managers (CAM) responsible for the detail work? In
my view of the world that is called shared responsibility AND
accountability. I find many people don't embrace accountability and in
my opinion they shouldn't participate in the rewards at the end. When
everybody has a say in the plan there is a much greater chance of
buy-in. Everybody wins and the plan has a much greater chance of success.

How many times have you had one of the performers say, "that's not my
plan, that's your plan". I've heard it too many times. Obviously, in
those cases the validity of that part of the plan worked by that person
is questionable.

In a "shared pain, shared gain" method of working a plan, each CAM has
their own file and they update their own files (sometimes
simultaneously). Through the linked master file and regular reviews
(timephased appropriately for the statusing period), the Program Manager
has oversight (and more importantly insight). The Schedule Manager has
responsibility for ensuring CAMs follow the rules (company and Project)
for laying out and maintaining their plans. And yes, sometimes a CAM
might update their plan only to find out that a driving task in another
CAMs file changes things. There is just no substitute for verbal
communication between team members.

The bottom line - a shared approach does work and I believe it is better
- for the employees (at all levels), for the company and for the
customer.

John

There's a difference between a leader getting buy-in from the participants
through shared approaches and a leader who abdicates his roll as leader and
allows the others to make arbitrary changes in a vacuum.

 

[John]

There's a difference between a leader getting buy-in from the participants
through shared approaches and a leader who abdicates his roll as leader and
allows the others to make arbitrary changes in a vacuum.

Steve,
No argument there. And the approach I was espousing was not the latter.

John

 

[hsn]

Steve,

I can certainly understand where you're coming from. It drastically
simplifies management. It has clear lines of where the buck stops.

However, I believe that John's concept is closer to MORE real world
situations THESE DAYS. John's scenario certainly describes our
organization (and I would think most if not all SMALL companies).

I believe that John's scenario has a greater chance of success because
more people are more invested in the sucess, albeit much more difficult
to manage - at least with present versions of project.

So maybe what it comes down to is that project is the wrong tool for
de-centralized project management.

Ned.

 

[hsn]

Haris,

TX for jumping in!

I agree with your assessment of the dialog & links in question.

My question is now relating to the "copy/paste+link" form of links.
These too are links between projects, but they are NOT
predecessor/sucessor links. I would describe them as "commentary" or
"perspective" links; that you might use to put a sub-project into
perspective.

It seems clear from my discussions with John & Steve, that this is
really not a good thing to do.

So my [curiosity] question becomes - What IS the "copy/paste+link"
function appropriate to use for?

I'm beginning to think it really has no (good) purpose.

tia - Ned.

PS: tx=thanks; tia= tx in advance

 

[Steve House [MVP - MS Project]]

If the project is so decentralized that everybody inputs their own planned
schedule without the need to first get signoff from the project manager,
then it's not really being managed at all. And if the PM has to sign off on
any proposed plan of action or change to the existing plan anyway, then his
office might as well be the one to maintain the files in Project in the
first place. I suggest that Project should be used by the PM to establish
effective controls on the project and it is not just a tool to document what
everyone says they're planning on doing and tracking whether they did it.
Change management is always a part of effective project management and one
of the keynotes of an effective change control plan is to insure that once
the plan has been finalized, approved, and baselined, any change made that
impacts the performance of the plan must go through a formal approval
process involving at the very least the PM, and if the change impacts the
budget or scope it should involve the project sponsor and appropriate
stakeholders as well, perhaps even to the extent of requiring the
preparation of a formal business case justifying the change to senior
management. Scope creep is one of the big killers of project success and
letting all the resources have the ability to modify the plan without
requiring a formal signoff process is an open invitation to that creepy
gremlin.

John's concept may very be closer to the way projects are often managed
today and therein lies the rub. Organizations such as the Gartner Group
have found that well in excess of 50% of all projects undertaken end in
failure (some estimates place it as high as 80%), failure being defined as
either being abandoned before completion, failing to meet budget and
schedule performance requirements, or failing to meet the required quality
standards for the deliverables. The forces engaged in a tank battle all
have a very high degree of involvement and are very invested in the
engagement's success but unless they are tightly coordinated by the
commanding officer they're going to lose anyway.

 

[John]

"Steve House [MVP - MS Project]"

If the project is so decentralized that everybody inputs their own planned
schedule without the need to first get signoff from the project manager,
then it's not really being managed at all. And if the PM has to sign off on
any proposed plan of action or change to the existing plan anyway, then his
office might as well be the one to maintain the files in Project in the
first place. I suggest that Project should be used by the PM to establish
effective controls on the project and it is not just a tool to document what
everyone says they're planning on doing and tracking whether they did it.
Change management is always a part of effective project management and one
of the keynotes of an effective change control plan is to insure that once
the plan has been finalized, approved, and baselined, any change made that
impacts the performance of the plan must go through a formal approval
process involving at the very least the PM, and if the change impacts the
budget or scope it should involve the project sponsor and appropriate
stakeholders as well, perhaps even to the extent of requiring the
preparation of a formal business case justifying the change to senior
management. Scope creep is one of the big killers of project success and
letting all the resources have the ability to modify the plan without
requiring a formal signoff process is an open invitation to that creepy
gremlin.

John's concept may very be closer to the way projects are often managed
today and therein lies the rub. Organizations such as the Gartner Group
have found that well in excess of 50% of all projects undertaken end in
failure (some estimates place it as high as 80%), failure being defined as
either being abandoned before completion, failing to meet budget and
schedule performance requirements, or failing to meet the required quality
standards for the deliverables. The forces engaged in a tank battle all
have a very high degree of involvement and are very invested in the
engagement's success but unless they are tightly coordinated by the
commanding officer they're going to lose anyway.

Steve,
I take issue (don't I always ) with the idea that the "team" approach
I suggested is doomed to failure. It just ain't so Ollie. There are many
ways to run a company and I don't buy into the idea that a militaristic
approach (follow orders, the General knows the most and is always
right). That just doesn't guarantee success.

I do agree however that a formal appropriate change control plan is
required. Not everybody on the team is budget minded. Too many people
can't control their own finances much less control their allocated
budget at their place of business. I think I mentioned that coordination
and negotiation are the backbone of a shared responsibility approach.
That coordination applies not only laterally (between CAMs) but also
between CAMs and Program Management. Didn't I mention the idea of
periodic reviews (and I'm not referring to the sometimes political PDR,
CDR, etc.)? I mean working reviews that step back and take a look at the
whole plan. If work needs to be cut or budget needs to be increased,
yes, the Program Manager (and customer) have the final say but certainly
not from a "I'm the boss, we'll do it this way" approach. To me that is
failure.

John

 

[John]

Steve,

I can certainly understand where you're coming from. It drastically
simplifies management. It has clear lines of where the buck stops.

However, I believe that John's concept is closer to MORE real world
situations THESE DAYS. John's scenario certainly describes our
organization (and I would think most if not all SMALL companies).

I believe that John's scenario has a greater chance of success because
more people are more invested in the sucess, albeit much more difficult
to manage - at least with present versions of project.

So maybe what it comes down to is that project is the wrong tool for
de-centralized project management.

Ned.

Ned,
It seems we have had a rousing discussion on your subject. Steve has his
favored approach and I well, see things a little differently. You seem
to like the approach I have been suggesting but to be honest I don't
really know if either of us have helped you solve your problem(s). If we
have, that's great. That's what we are here for. If we have not, maybe
you should re-state the remain that remain in a new post.

John

 

[Steve House [MVP - MS Project]]

Don't get me wrong, I'm totally in favour of a team approach and do not
approve at all of a dictatorial style. A true leader communicates his
vision and builds consensus within the team. But there still has to be
someone in charge who has the vision of the big picture and has the final
"yea" or "nay" decision authority when the team doesn't reach consensus.
The PM is the channel between Senior Management who is deciding the
strategic goals for the organization and the resource and functional units
that carry out the work that realizes those goals. Whether s/he has the
position authority of managing the functional managers and team members or
not, they have the responsibility of translating those strategic goals into
operational tactics. If you wish you can view the organization as an
hourglass and the PM sits right in the narrowest part, the conduit between
through which the goals of the strategic planners viz-a-viz the project and
its place in the organization's long-term strategy are communicated.

Even in fully team struture with a strong censensus, team members might
suggest tactics and since they are the SMEs in their particular area the
smart manager listens very closely to what they suggest but they should
never unilaterally decide tactics when the results of their decision impact
the project as a whole (and Joe Resource deciding when to schedule a task he
is assigned to that has successors does exactly that).
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

"Steve House [MVP - MS Project]"

If the project is so decentralized that everybody inputs their own
planned
schedule without the need to first get signoff from the project manager,
then it's not really being managed at all. And if the PM has to sign off
on
any proposed plan of action or change to the existing plan anyway, then
his
office might as well be the one to maintain the files in Project in the
first place. I suggest that Project should be used by the PM to
establish
effective controls on the project and it is not just a tool to document
what
everyone says they're planning on doing and tracking whether they did it.
Change management is always a part of effective project management and
one
of the keynotes of an effective change control plan is to insure that
once
the plan has been finalized, approved, and baselined, any change made
that
impacts the performance of the plan must go through a formal approval
process involving at the very least the PM, and if the change impacts the
budget or scope it should involve the project sponsor and appropriate
stakeholders as well, perhaps even to the extent of requiring the
preparation of a formal business case justifying the change to senior
management. Scope creep is one of the big killers of project success and
letting all the resources have the ability to modify the plan without
requiring a formal signoff process is an open invitation to that creepy
gremlin.

John's concept may very be closer to the way projects are often managed
today and therein lies the rub. Organizations such as the Gartner Group
have found that well in excess of 50% of all projects undertaken end in
failure (some estimates place it as high as 80%), failure being defined
as
either being abandoned before completion, failing to meet budget and
schedule performance requirements, or failing to meet the required
quality
standards for the deliverables. The forces engaged in a tank battle all
have a very high degree of involvement and are very invested in the
engagement's success but unless they are tightly coordinated by the
commanding officer they're going to lose anyway.

Steve,
I take issue (don't I always ) with the idea that the "team" approach
I suggested is doomed to failure. It just ain't so Ollie. There are many
ways to run a company and I don't buy into the idea that a militaristic
approach (follow orders, the General knows the most and is always
right). That just doesn't guarantee success.

I do agree however that a formal appropriate change control plan is
required. Not everybody on the team is budget minded. Too many people
can't control their own finances much less control their allocated
budget at their place of business. I think I mentioned that coordination
and negotiation are the backbone of a shared responsibility approach.
That coordination applies not only laterally (between CAMs) but also
between CAMs and Program Management. Didn't I mention the idea of
periodic reviews (and I'm not referring to the sometimes political PDR,
CDR, etc.)? I mean working reviews that step back and take a look at the
whole plan. If work needs to be cut or budget needs to be increased,
yes, the Program Manager (and customer) have the final say but certainly
not from a "I'm the boss, we'll do it this way" approach. To me that is
failure.

John

 

[Steve House [MVP - MS Project]]

Each CAM creating their own plan? On the micro level, fine. But not on the
macro level - that should be developed in close consultation with the PM but
all the while the PM retains the final say in if or how the CAMs ideas will
be implemented. Nothing should ever be entered into the plan or changed
once there without signoff by the PM. But in terms of CAMs tracking their
own progress though, absolutely - that's not changing the plan, that's
reporting actual performance against plan!
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

"Steve House [MVP - MS Project]"

Don't get me wrong, I'm totally in favour of a team approach and do not
approve at all of a dictatorial style. A true leader communicates his
vision and builds consensus within the team. But there still has to be
someone in charge who has the vision of the big picture and has the final
"yea" or "nay" decision authority when the team doesn't reach consensus.
The PM is the channel between Senior Management who is deciding the
strategic goals for the organization and the resource and functional
units
that carry out the work that realizes those goals. Whether s/he has the
position authority of managing the functional managers and team members
or
not, they have the responsibility of translating those strategic goals
into
operational tactics. If you wish you can view the organization as an
hourglass and the PM sits right in the narrowest part, the conduit
between
through which the goals of the strategic planners viz-a-viz the project
and
its place in the organization's long-term strategy are communicated.

Even in fully team struture with a strong censensus, team members might
suggest tactics and since they are the SMEs in their particular area the
smart manager listens very closely to what they suggest but they should
never unilaterally decide tactics when the results of their decision
impact
the project as a whole (and Joe Resource deciding when to schedule a task
he
is assigned to that has successors does exactly that).
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

"Steve House [MVP - MS Project]"

If the project is so decentralized that everybody inputs their own
planned
schedule without the need to first get signoff from the project
manager,
then it's not really being managed at all. And if the PM has to sign
off
on
any proposed plan of action or change to the existing plan anyway,
then
his
office might as well be the one to maintain the files in Project in
the
first place. I suggest that Project should be used by the PM to
establish
effective controls on the project and it is not just a tool to
document
what
everyone says they're planning on doing and tracking whether they did
it.
Change management is always a part of effective project management and
one
of the keynotes of an effective change control plan is to insure that
once
the plan has been finalized, approved, and baselined, any change made
that
impacts the performance of the plan must go through a formal approval
process involving at the very least the PM, and if the change impacts
the
budget or scope it should involve the project sponsor and appropriate
stakeholders as well, perhaps even to the extent of requiring the
preparation of a formal business case justifying the change to senior
management. Scope creep is one of the big killers of project success
and
letting all the resources have the ability to modify the plan without
requiring a formal signoff process is an open invitation to that
creepy
gremlin.

John's concept may very be closer to the way projects are often
managed
today and therein lies the rub. Organizations such as the Gartner
Group
have found that well in excess of 50% of all projects undertaken end
in
failure (some estimates place it as high as 80%), failure being
defined
as
either being abandoned before completion, failing to meet budget and
schedule performance requirements, or failing to meet the required
quality
standards for the deliverables. The forces engaged in a tank battle
all
have a very high degree of involvement and are very invested in the
engagement's success but unless they are tightly coordinated by the
commanding officer they're going to lose anyway.

Steve,
Well, it sounds like we ARE on the same page. I guess I'm missing the
part where we differ unless its the idea of each CAM creating and
tracking their own Project plan. But just to be clear, they cannot do
that without training (Project "rules" and company "rules") and they
cannot do that in a vacuum (i.e checks and balances).

John

 

[John]

"Steve House [MVP - MS Project]"

Don't get me wrong, I'm totally in favour of a team approach and do not
approve at all of a dictatorial style. A true leader communicates his
vision and builds consensus within the team. But there still has to be
someone in charge who has the vision of the big picture and has the final
"yea" or "nay" decision authority when the team doesn't reach consensus.
The PM is the channel between Senior Management who is deciding the
strategic goals for the organization and the resource and functional units
that carry out the work that realizes those goals. Whether s/he has the
position authority of managing the functional managers and team members or
not, they have the responsibility of translating those strategic goals into
operational tactics. If you wish you can view the organization as an
hourglass and the PM sits right in the narrowest part, the conduit between
through which the goals of the strategic planners viz-a-viz the project and
its place in the organization's long-term strategy are communicated.

Even in fully team struture with a strong censensus, team members might
suggest tactics and since they are the SMEs in their particular area the
smart manager listens very closely to what they suggest but they should
never unilaterally decide tactics when the results of their decision impact
the project as a whole (and Joe Resource deciding when to schedule a task he
is assigned to that has successors does exactly that).
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

"Steve House [MVP - MS Project]"

If the project is so decentralized that everybody inputs their own
planned
schedule without the need to first get signoff from the project manager,
then it's not really being managed at all. And if the PM has to sign off
on
any proposed plan of action or change to the existing plan anyway, then
his
office might as well be the one to maintain the files in Project in the
first place. I suggest that Project should be used by the PM to
establish
effective controls on the project and it is not just a tool to document
what
everyone says they're planning on doing and tracking whether they did it.
Change management is always a part of effective project management and
one
of the keynotes of an effective change control plan is to insure that
once
the plan has been finalized, approved, and baselined, any change made
that
impacts the performance of the plan must go through a formal approval
process involving at the very least the PM, and if the change impacts the
budget or scope it should involve the project sponsor and appropriate
stakeholders as well, perhaps even to the extent of requiring the
preparation of a formal business case justifying the change to senior
management. Scope creep is one of the big killers of project success and
letting all the resources have the ability to modify the plan without
requiring a formal signoff process is an open invitation to that creepy
gremlin.

John's concept may very be closer to the way projects are often managed
today and therein lies the rub. Organizations such as the Gartner Group
have found that well in excess of 50% of all projects undertaken end in
failure (some estimates place it as high as 80%), failure being defined
as
either being abandoned before completion, failing to meet budget and
schedule performance requirements, or failing to meet the required
quality
standards for the deliverables. The forces engaged in a tank battle all
have a very high degree of involvement and are very invested in the
engagement's success but unless they are tightly coordinated by the
commanding officer they're going to lose anyway.

Steve,
Well, it sounds like we ARE on the same page. I guess I'm missing the
part where we differ unless its the idea of each CAM creating and
tracking their own Project plan. But just to be clear, they cannot do
that without training (Project "rules" and company "rules") and they
cannot do that in a vacuum (i.e checks and balances).

John

 

[John]

"Steve House [MVP - MS Project]"

Each CAM creating their own plan? On the micro level, fine. But not on the
macro level - that should be developed in close consultation with the PM but
all the while the PM retains the final say in if or how the CAMs ideas will
be implemented. Nothing should ever be entered into the plan or changed
once there without signoff by the PM. But in terms of CAMs tracking their
own progress though, absolutely - that's not changing the plan, that's
reporting actual performance against plan!

hn

Steve,
Gee, I think I've said it several times, but here it is just once more
for the record. CAMs generate their own plans BASED on the contract
requirements. They do NOT work in a vacuum. Their budget is reviewed and
negotiated with Program Management and the customer. Their plans are
baselined and thereafter are under FORMAL change control.

Hopefully that clarifies my position (i.e. standing firm). Enough
already, we're on the same page.

John

 

[hsn]

John / Steve;

Actually this discussion has been very enlightening. It's given me a
couple of perspectives, and done an excellent job of painting the "big
picture".

With regard to MY specific problem(s); the conclusion I've come to is
[simply] this:
1) Each of the project managers creates their own "sub-project",
completely free of constraints. They spell out their portion of the
project as they see it. This is NOTHING more than a list of tasks in
outline organization, with NO dependancies. They do, however, assign
resources, and fill in durations/est. durations.

2) Each sub-project is then consolidated into the "master" project by
COPYING the tasks - no linking, no copy/link, just a raw consolidation
of the tasks. During this process the "master project manager" (which
in our case is more than 1 person), will organize a "full project"
outline, and place & consolidate tasks appropriately.

3) Dependancies are now linked, and if one manager wants to "keep
tabs" on a task or group of tasks that they have little or nothing to
do with - they assign themselves as a "1%" resource. This allows
managers to filter the [full] project and see ONLY the things that they
own, or have interest in.

4) This unfortunately means that only 1 manager can be editting the
project at a time, and it also means the project file can ONLY be
worked on IN THE OFFICE. (Many of our people spend time working from
home; so they wanted to take their "sub-project" home to work on).

Interested in hearing both of your opinions.... although I'm assuming
Steve in particular will take issue with #1. You strike me as more a
"lay out the structure first, and fill it in with the actions to fit
that structure" type of guy. I'm more a let the actions dictate the
structure type of guy. Both approaches have merit, but I think mine is
more common, and works better in small companies. I think the
structure-first approach is far better suited to large companies, where
way too many cooks get involved (and would make my approach a
nightmare).

I'm VERY interested in both of your comments re: #'s 3 & 4. Curious if
you have a better idea.

While I now believe this to be the best solution for our problem - I
must point out, it's the best solution AVAILABLE TODAY. I still believe
that project isn't the right tool in our situation, and I'm sure many
others (short of any significant upgrades). (I'm really complaining
about #'s 3 & 4 here - so maybe 1 of you will tell me I'm full of it -
which would make me very happy!)


The only other thing I would like to add to the ongoing discussion, is
that you can't always run changes thru "management" for approval. Many
times, the changes are simply a matter of fact, and it's their NET
EFFECT on the project as a whole that the management needs to address.
So I would argue that the managers will and should make whatever
changes they see fit (without approval - but within the scope of their
power), and their effect on the whole project (as evidenced by the "new
timeline") would be addressed in group meetings.

Also curious to hear your take on this thought!

Again - many thanks to both of you, I've really been enjoying the
banter.

Ned.

 

[hsn]

This can be ignored - althought I've been thru the help file numerous
times, I could have sworn this applied to tasks.

It's clear now that this ONLY applies to REAL external stuff, like word
docs, excel sheets, etc...

I'm not sure this "feature" should really exist at all - it adds
confusion, and it seems the benefit is small.

my $.02 ....

TX again, Haris

 

[John]

This can be ignored - althought I've been thru the help file numerous
times, I could have sworn this applied to tasks.

It's clear now that this ONLY applies to REAL external stuff, like word
docs, excel sheets, etc...

I'm not sure this "feature" should really exist at all - it adds
confusion, and it seems the benefit is small.

my $.02 ....

TX again, Haris

Haris,
I can't speak for Steve of course, but I have no idea what you are
talking about in this post. It's kinda like it just appeared out of the
blue.

John

 

[John]

Ned,
I'm proud of you actually. You were able to sift through our suggestions
and philosophies and come up with an approach, that as you understand
it, will meet your needs. I may not agree with your chosen approach but
then, I'm not the one in your situation. My comments are shown below.

With regard to MY specific problem(s); the conclusion I've come to is
[simply] this:
1) Each of the project managers creates their own "sub-project",
completely free of constraints. They spell out their portion of the
project as they see it. This is NOTHING more than a list of tasks in
outline organization, with NO dependancies. They do, however, assign
resources, and fill in durations/est. durations.

We actually had a similar, I guess I'll call it fear, with the CAMs at
our company. I always told the cost account managers (CAMs) to work on
their "live file", (the actual project file that was used to create and
track the plan), but I found some of them were just uncomfortable or
scared and wanted to work on their plan off on their local hard drive
(our "live files" were on a shared server). I tried to tell them that
there was nothing they could do that couldn't be fixed and sure enough
we did have some "incidents". Well, that's more of a story than a
constructive comment so here's my take on what your are doing. Although
it would probably be (or have been?) easier for your CAMs to develop the
task list in Excel, it certainly can be done in Project. Many people do
a plan in Excel and then transfer it to Project. Excel is just a lot
easier to work with for most people.

2) Each sub-project is then consolidated into the "master" project by
COPYING the tasks - no linking, no copy/link, just a raw consolidation
of the tasks. During this process the "master project manager" (which
in our case is more than 1 person), will organize a "full project"
outline, and place & consolidate tasks appropriately.

You do NOT have to use copy/paste to create a master from the separate
files. As a matter of fact that is a very inefficient method. Rather, if
you do NOT want the original individual files to remain active after
they are initially uploaded to the master (i.e. statically consolidated
master), then go to Insert/Project and in the Insert window that appears
uncheck the "Link to project" option at the bottom of the window. Then
select all the subprojects and "Insert". Basically, it will create a
single file of all the subprojects at that point in time. That master
can then be manipulated (e.g. eliminate duplicate tasks, link dependent
tasks, etc.).

If you really want to use static master, (I still think a dynamic master
is a better approach), then the Program Manager needs to designate ONE
person to be the "curator" of the master file. Otherwise the "too many
cooks" rule will apply. Now, there's nothing wrong with a big "come to
grips" meeting to get everybody's input when the master is built and
tweaked to be the working file, but in the end, only one person can be
the user of the master file.

3) Dependancies are now linked, and if one manager wants to "keep
tabs" on a task or group of tasks that they have little or nothing to
do with - they assign themselves as a "1%" resource. This allows
managers to filter the [full] project and see ONLY the things that they
own, or have interest in.

This is an unnecessary complication and does not reflect what you
intend. Do NOT keep tabs on unrelated tasks by artificially assigning a
resource. Bad idea. A much better and simpler approach is to assign each
CAM a spare flag field, (or a coded spare number field could also be
used), and then set the flag for all those tasks that are of interest to
the CAM. A simple filter can be used to show just those tasks.

4) This unfortunately means that only 1 manager can be editting the
project at a time, and it also means the project file can ONLY be
worked on IN THE OFFICE. (Many of our people spend time working from
home; so they wanted to take their "sub-project" home to work on).

That's right, by using a static master, you have now limited yourselves
to effectively having one person responsible. The exact opposite of what
I was suggesting originally. In this regard a dynamic master works much
better because CAMs can indeed work on their own file and do it remotely
(i.e. home, remote server, etc.), but those files are still subject to
review.

Interested in hearing both of your opinions.... although I'm assuming
Steve in particular will take issue with #1. You strike me as more a
"lay out the structure first, and fill it in with the actions to fit
that structure" type of guy. I'm more a let the actions dictate the
structure type of guy. Both approaches have merit, but I think mine is
more common, and works better in small companies. I think the
structure-first approach is far better suited to large companies, where
way too many cooks get involved (and would make my approach a
nightmare).

I'm VERY interested in both of your comments re: #'s 3 & 4. Curious if
you have a better idea.

While I now believe this to be the best solution for our problem - I
must point out, it's the best solution AVAILABLE TODAY. I still believe
that project isn't the right tool in our situation, and I'm sure many
others (short of any significant upgrades). (I'm really complaining
about #'s 3 & 4 here - so maybe 1 of you will tell me I'm full of it -
which would make me very happy!)

Wrong. Project is designed for creating, tracking and managing schedule
plans - big or small. No upgrades are needed for what you need, its
already there and has been since Project was first introduced years ago.
What did you have for breakfast? That's the only thing you are full of
Just because you are having a difficult time getting your arms
around Project and the best way to use it in you situation, doesn't mean
you are off base. Far from it. Rather, you are just another user who is
struggling to learn a not-so-user-friendly tool. In my opinion learning
to use Project effectively is a long term (i.e. years) proposition. Oh
sure, you can take a crash course or be taught by "experts" but
comprehension and effectiveness takes hands on experience and a lot of
it. Most of the MVPs have been using Project for years and at least for
this MVP, I'm still learning.

The only other thing I would like to add to the ongoing discussion, is
that you can't always run changes thru "management" for approval. Many
times, the changes are simply a matter of fact, and it's their NET
EFFECT on the project as a whole that the management needs to address.
So I would argue that the managers will and should make whatever
changes they see fit (without approval - but within the scope of their
power), and their effect on the whole project (as evidenced by the "new
timeline") would be addressed in group meetings.

Many changes to the project plan (e.g. format, views, even some
structural changes) do not need review and approval from the Program
Manager. However, any changes that materially affect the plan cost or
timeline need some type of formal review for a check and balance
approach. I already talked about my belief in regular communication
amongst CAMs and with Program Management in periodic formal reviews. If
appropriate, the customer should be involved in major decisions also
(boy can that be a scary thought sometimes).


John

 

[Steve House [MVP - MS Project]]

The reason I'd take issue with number 1 is that IMO a fully-developed
project plan is sort of like an engineering document that defines in detail
every step that must be taken in order to achieve a clearly defined,
concrete objective. There is no such thing as their "portion of the project
as they see it" that can be scheduled independently of the rest of the
project because their portion is just one part of the overall scope of the
project and the whole thing must fit together in the end. Defining those
parameters is one of the jobs of the Project Manager. The scope and whether
the manager's ideas are in scope or out of scope are defined by the
spcifications of the end deliverable and those in turn are defined by the PM
as the best way to implement the strategic objectives of the organization as
a whole. Whatever the functional managers do must fit into that context and
contribute to fulfilling a strategic objective that they may not even be
aware exists. It is the PM's, not the functional manager's, responsibility
to decide what work is in and what work is out of scope. If you're in
Chicago and the project is to get to Los Angeles, your scenario allows for
someone to take a diversion though Miami when it's their turn to drive the
bus because he doesn't feel the urgency to get to LA and besides Disney
World Orlando is more fun than Disney World Anaheim and so he decides to
take everyone there instead <grin>. The functional managers certainly
should be involved with the PM in advising him or her on what needs to be
done as the PM isn't likely to be a subject matter expert on every detail in
the project, and once the project has been defined in many cases they can
and should decide on their own how those things within their area of
responsibility will be done and who does them, but it's well above their
paygrade to be deciding what work is to be done and when it's needed.

It's not so much layout the structure and fit in the actions or lay out the
actions and let them define the structure. It's what is needed to insure
that a group of people with individual ideas and perceptions and diverse
personal objectives will work together as a cohesive team, a single unified
body, to achieve the strategic objectives of the organization that gave rise
to the existence of the project in the first place and do it in the most
efficient and cost effective manner possible.

That is why your last comment about changes being a matter of fact worries
me. Yes, change is a constant and objectives can change. The scope of a
project can certainly change between when it is conceived and when it is
executed. But a properly detailed plan is based on the work known to be
required to meet a specific set of objectives, ie, fulfill a specific scope.
Any change, regardless of where it is initiated once the plan has been
determined is by definition changing the scope of the project, since it
changes the outcome of the work. That is absolutely not within the
responsibility of the functional manager. You don't let the manager of the
programming department decide on his own initiative whether the next product
to be written by your software company is an accounting package or a word
processor. You might go to him and say "We're targetting this word
processor at medical transcriptions so pick someone who knows some medical
terminology to lead your programming group." but that's a whole different
from letting him unilaterally decide changes to the plan. HOW the details
are executed is his job but deciding WHAT work is executed is the Project
Manager's.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

John / Steve;

Actually this discussion has been very enlightening. It's given me a
couple of perspectives, and done an excellent job of painting the "big
picture".

With regard to MY specific problem(s); the conclusion I've come to is
[simply] this:
1) Each of the project managers creates their own "sub-project",
completely free of constraints. They spell out their portion of the
project as they see it. This is NOTHING more than a list of tasks in
outline organization, with NO dependancies. They do, however, assign
resources, and fill in durations/est. durations.

2) Each sub-project is then consolidated into the "master" project by
COPYING the tasks - no linking, no copy/link, just a raw consolidation
of the tasks. During this process the "master project manager" (which
in our case is more than 1 person), will organize a "full project"
outline, and place & consolidate tasks appropriately.

3) Dependancies are now linked, and if one manager wants to "keep
tabs" on a task or group of tasks that they have little or nothing to
do with - they assign themselves as a "1%" resource. This allows
managers to filter the [full] project and see ONLY the things that they
own, or have interest in.

4) This unfortunately means that only 1 manager can be editting the
project at a time, and it also means the project file can ONLY be
worked on IN THE OFFICE. (Many of our people spend time working from
home; so they wanted to take their "sub-project" home to work on).

Interested in hearing both of your opinions.... although I'm assuming
Steve in particular will take issue with #1. You strike me as more a
"lay out the structure first, and fill it in with the actions to fit
that structure" type of guy. I'm more a let the actions dictate the
structure type of guy. Both approaches have merit, but I think mine is
more common, and works better in small companies. I think the
structure-first approach is far better suited to large companies, where
way too many cooks get involved (and would make my approach a
nightmare).

I'm VERY interested in both of your comments re: #'s 3 & 4. Curious if
you have a better idea.

While I now believe this to be the best solution for our problem - I
must point out, it's the best solution AVAILABLE TODAY. I still believe
that project isn't the right tool in our situation, and I'm sure many
others (short of any significant upgrades). (I'm really complaining
about #'s 3 & 4 here - so maybe 1 of you will tell me I'm full of it -
which would make me very happy!)


The only other thing I would like to add to the ongoing discussion, is
that you can't always run changes thru "management" for approval. Many
times, the changes are simply a matter of fact, and it's their NET
EFFECT on the project as a whole that the management needs to address.
So I would argue that the managers will and should make whatever
changes they see fit (without approval - but within the scope of their
power), and their effect on the whole project (as evidenced by the "new
timeline") would be addressed in group meetings.

Also curious to hear your take on this thought!

Again - many thanks to both of you, I've really been enjoying the
banter.

Ned.

 

[hsn]

Hi John;

sorry for the delay, things got a little hairry here....
I've responded to select portions of your reply:

(e-mail address removed) wrote: [snip]

2) Each sub-project is then consolidated into the "master" project by
COPYING the tasks - no linking, no copy/link, just a raw consolidation
of the tasks. During this process the "master project manager" (which
in our case is more than 1 person), will organize a "full project"
outline, and place & consolidate tasks appropriately.

You do NOT have to use copy/paste to create a master from the separate
files. As a matter of fact that is a very inefficient method. Rather, if
you do NOT want the original individual files to remain active after
they are initially uploaded to the master (i.e. statically consolidated
master), then go to Insert/Project and in the Insert window that appears
uncheck the "Link to project" option at the bottom of the window. Then
select all the subprojects and "Insert". Basically, it will create a
single file of all the subprojects at that point in time. That master

can then be manipulated (e.g. eliminate duplicate tasks, link dependent
tasks, etc.).

If you really want to use static master, (I still think a dynamic master
is a better approach), then the Program Manager needs to designate ONE
person to be the "curator" of the master file. Otherwise the "too many
cooks" rule will apply. Now, there's nothing wrong with a big "come to
grips" meeting to get everybody's input when the master is built and
tweaked to be the working file, but in the end, only one person can be
the user of the master file.

Very good point - I often overlook those small, but important
checkbox's "hidden" (only from my rush thru the screen) "down below".

My first preference is still to have a dynamic master. So I guess I
would like to have you elaborate on what that is and how to do it.
Here's my experience and why I went static:

I'm assuming a dynamic master would use linked, inserted sub-projects.
When I tried doing this, we setup dependancies using the
{sub-project_name}\task# convention in the dependancy box.

When people took home their sub-projects, and returned; needless to say
all the dependancies were completely out-to-lunch.

Is there a way around this, or am I using the wrong approach?

3) Dependancies are now linked, and if one manager wants to "keep
tabs" on a task or group of tasks that they have little or nothing to
do with - they assign themselves as a "1%" resource. This allows
managers to filter the [full] project and see ONLY the things that they
own, or have interest in.

This is an unnecessary complication and does not reflect what you
intend. Do NOT keep tabs on unrelated tasks by artificially assigning a
resource. Bad idea. A much better and simpler approach is to assign each
CAM a spare flag field, (or a coded spare number field could also be
used), and then set the flag for all those tasks that are of interest to
the CAM. A simple filter can be used to show just those tasks.

A VERY obvious solution I overlooked!!! TX

[snip]

Wrong. Project is designed for creating, tracking and managing schedule
plans - big or small. No upgrades are needed for what you need, its
already there and has been since Project was first introduced years ago.
What did you have for breakfast? That's the only thing you are full of

OK - no argument from me!

Just because you are having a difficult time getting your arms
around Project and the best way to use it in you situation, doesn't mean
you are off base. Far from it. Rather, you are just another user who is
struggling to learn a not-so-user-friendly tool. In my opinion learning
to use Project effectively is a long term (i.e. years) proposition. Oh
sure, you can take a crash course or be taught by "experts" but
comprehension and effectiveness takes hands on experience and a lot of
it. Most of the MVPs have been using Project for years and at least for
this MVP, I'm still learning.

Here, my intention was not to speak with authority, but to expose my
perspective. I was hoping to be proved wrong, and was really looking
for that to happen. I'm the first to admit I'm not a project guru... As
I reread my reply I can see how I missed getting that across...

[snip]

The excluded portions of your reply, I'm in much more agreement than
not.

Again, as always, appreciative for your time and interest!
Ned.

 

[hsn]

Thanks, Steve!

I got both the reaction I expected and hoped for. Since our views are
further apart, I'm hoping for alot of food for thought to re-assess my
thinking; as well as get a different perspective on where I'm at
presently.

I generally agree with your position. I absolutely agree with it in the
big business setting. However, in our very small company, where there
is often not a single-person resource in many areas - and management
itself comes from an entreprenurial mentality (where the climate is
much more "throw your knowledge on the table, and let's organize it
together"). In this setting, I'm thinking my previously mentioned
tactic is better.

Now, I'm not saying it should be a complete and utter free-for-all, but
if someone wants to get to LA from Chicago via Miami, our management
wants to hear some reasoning before telling them that's way out of
line. In short, management tends to look at many more "paths";
management re-evaluates its own knowledge, and reserves the right to be
wrong. There are (almost) no ego's here ;-).

Basically, I guess what I'm saying is that we do a "free-form"
brainstorming session, then some structure/ruleset is applied.

Ned

 

[John]

Ned,
My comments below.

Very good point - I often overlook those small, but important
checkbox's "hidden" (only from my rush thru the screen) "down below".

My first preference is still to have a dynamic master. So I guess I
would like to have you elaborate on what that is and how to do it.
Here's my experience and why I went static:

I'm assuming a dynamic master would use linked, inserted sub-projects.
When I tried doing this, we setup dependancies using the
{sub-project_name}\task# convention in the dependancy box.

When people took home their sub-projects, and returned; needless to say
all the dependancies were completely out-to-lunch.

Is there a way around this, or am I using the wrong approach?

Out-to-lunch huh? So now you're saying the Project files are "full of
it". Well what did they have for breakfast

The problem lies in people taking their subprojects home. The ideal
approach is to set things up so that the users can work on their files
at home if desired but to have the files themselves reside on a remotely
accessible server. The problem comes when the subprojects are moved
around. This is really a much bigger problem when using individual Paste
Links but it can also be a problem with OLE links for the whole file. If
the remote server (i.e. company server accessible by employees working
at home) is not an option other techniques, (that require more
discipline), can probably be used successfully. As long as the users do
not change task lines with external links and as long as they do not
change the file name, the users should be able to replace (overwrite)
the "live file" at work with the home modified version and not adversely
affect the links. I haven't used this method for a long time and I don't
remember if there are other constraints but this method will work - but
discipline is required. If this approach scares you or you just don't
think it will work in your company structure, there are other approaches
(VBA comes to mind) but they are more complex.


How we doin' so far?

John
Project MVP