Re: Linked tasks - LOST LEVELS!!!

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.

.

Loading