Opinions Wanted (2)

[James Dixon]

(Second part of Opinions Wanted (1) post).

==========================================
2. Using "ID only" and cutting and pasting tasks to level

So, using this structure:

Milestone 1 V----------------V
Art Staff V----------V
Fred V-------V
Task 1 xxx
Task 2 xxx
Task 3 xxx
Joe V----------V
Task 4 xxxx
Task 5 xx
Task 6 xxxxxx
Tech Staff V----------------V
Jane V----V
Task 7 xx
Task 8 xx
Task 9 xx
Ed V----------------V
Task 10 xxxxxxx
Task 11 xxxx
Task 12 xxxxxxx

we can have full control of what order the work is carried out, simply by
moving the tasks of a person around (cut&paste or drag&drop). E.g. If it
turns out that I want Fred to do Task 3 before Task 1, then I simply drag it
above, and relevel. Again, this would seem to totally negate any concept of
using a WBS?

The reason behind this is to deal with preferential rather than enforced
work order. We still want to use links just for enforced dependencies, but
sometimes we would rather work happens in a certain order, for milestone
delivery purposes, even if there is strictly no need.

Eg, say we're designing a web site.

Website Project
Page 1
Task 1 (design)
Task 4 (script)
Task 9 (artwork)
Task 11 (testing)
Page 2
Task 2 (design)
Task 5 (script)
...

Milestone 1 is Page 1
Milestone 2 is Page 2
Strict dependencies would be:

p1 design -> p1 art
p1 design -> p1 script
p1 script -> p1 test
p1 art -> p1 test

(and the same for page 2).

No dependencies exist between pages 1 and 2, but we want M1 to be before M2,
thus we would want the designer to design Page 1 before Page 2 (let's
pretend it's the same resource, that therefore needs levelling). This is
obviously *extremely* simplified.
Traditionally I have done this by jigging priorities and using the
"Priority, Standard" level order. Is this the right way of doing things?

How else could I ensure that MS Project levels for M1 to be before M2
without resorting to ID levelling?

Thanks again,
James Dixon.

 

[Steve House]

Two ways to do this:

The first is to use dependency links between the summary tasks to link Pages
1 & 2 FS, making page 1 the predecessor and page 2 the successor. I'm not
too happy with that one since in general one should avoid links that don't
represent process logic but in this case it's not too bad a deviation from
formal CPM/PERT principles.

The other is that you make the first page you want worked on to a higher
priority than the other - not the individual tasks, leave them as is, but
set it so the priority of page 1 to something higher than that of page 2 and
level, *NOT* in ID order but rather the use the Priority/Standard order.
Think of "priority" as meaning "the more important it is to get done ASAP."

One reason I prefer the latter is that imagine you suddenly get a second
designer on board and you can put her on page 2 while the first guy works of
page 1. Now all you have to do is replace Designer 1 with Designer 2 on Page
2 and relevel - you don't have to tamper with the network logic or rearrange
the task in the task list.

By the way - your use of the term "milestone" is technically incorrect. You
have shown it with a duration - milestones don't have duration, they are
single point locations within the project that have zero duration marking
the establishment of a certain desired state such at the creation of a
particular deliverable. What you are calling a milestone is, in fact, a
summary task. The milestone is a state condition that occurs at the end of
it. In your web design project the preferred way would be:

("-" indicates duration units)

1 Page 1 V--------------------------------------V
1.1 Design V-------V
1.2 Text V----------V
1.3 Art V----------------V
1.4 Test V-----------V
1.5 Page Done O

Links 1.1->1.2 1.1->1,3 1.2->1.4 1.3->1.4 1.4->1.5
Task 1.5 is the milestone whose entry condition is the completion of the
testing of the finished page. It's done and can be filed in the code
archives until you're ready to incorporate it into the web site itself.

 

[Dave W]

You are misusing the term "milestone". A milestone by definition is a point
in time with a 0 duration and 0 resources assigned.

 

[Jan De Messemaeker]

Hi,

Well, I don't know where it comes from but a lot of people with my customers
use the term Milestones where we mean summary tasks. It is fairly common to
hear them talk about the cost of a milestone, f.i.

Greetz,

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620

 

[James Dixon]

You are absolutely right, of course.
I meant to put "Work for Milestone 1". The actual milestone 1 is indeed a 0
duration task linked from this summary task.

J

 

[James Dixon]

While we're on milestones -

Is it generally better to make a milestone ASAP and give it a deadline (so
you get a nice visual milestone late marker when it's slipping), or use a
"Must Finish On" constraint?
If the latter, what's the best way to highlight when a milestone is
overrunning?

Cheers,
James.

 

[James Dixon]

Two ways to do this:

The first is to use dependency links between the summary tasks to link Pages
1 & 2 FS, making page 1 the predecessor and page 2 the successor. I'm not
too happy with that one since in general one should avoid links that don't
represent process logic but in this case it's not too bad a deviation from
formal CPM/PERT principles.

I agree. This is horrible, as it wouldn't allow the designer to get on with
designing Page 2 before the Tester had tested Page 1. Clearly this leads to
extremely stretched out shecdules.

The other is that you make the first page you want worked on to a higher
priority than the other - not the individual tasks, leave them as is, but
set it so the priority of page 1 to something higher than that of page 2 and
level, *NOT* in ID order but rather the use the Priority/Standard order.
Think of "priority" as meaning "the more important it is to get done

ASAP."

This is indeed what I've traditionally done, but it has seemed like rather a
juggling act (tweak priorities, hit level now, examine task orders, decide
if it's what you want, go to step 1), and I was simply wondered if this was
the accepted way of doing things, or if I was missing something

 

[Steve House]

This has been debated hotly between several of us MVP's <grin> but IMHO a
constraint always should be a scheduling condition imposed on the project
from outside and never a reflection of the goals and objectives of the
project. I feel so strongly about this that I think the addition of the
deadline field in Project 2000 was all by itself sufficient business
justification for the cost of the upgrade from 98 to 2K because constraints
were the only way you could reflect a deadline in Proj 98 or earlier.

Your contract calls for completion by the first of the year - that's not a
constraint, it's the objective, and you're building the project plan to try
to figure out what you need to do in order to meet it. Unless MSP can
freely calculate the completion date, for better or worse, you can never
accurately model the consequences of the application of the management
controls you have at your disposal. A constraint in MSP limits its ability
to freely move things back and forth and so limits the plan's usefullness as
a modeling tool.

OTOH, if part of your plan requires you to do some work at a certain
location and that location is not available prior to a certain date, then a
"Must Start No Earlier Than" constraint on that task is certainly
appropriate.

The counter argument is that "Our contract dates are fixed in granite and we
have no choice but to hit them so they should be fixed in the plan." Well
of course they're fixed in granite but that's not the point. To me that is
a false argument because it implies an identity relationship between the
*planning model* of the work as reflected in the plan and the actual work
itself. The events of the plan will happen on certain dates given the
resources and network logic whether you like it or not and *WHETHER THE PLAN
DOCUMENT REFLECTS IT OR NOT! The act of writing down of a date on paper and
publishing it to your team does not magically make things happen that way.
If those dates are unacceptable, you have to change the network or the
resources or both. Simply declaring that something will happen on a certain
date is not going to make it happen - managment is the act of analysis and
application of controls to meet an objective, not simply an exercise in
assertiveness and will-power. Of course the dates you have to meet are fixed
and failing to meet them is an extremely career limiting move. But the job
of the project planning process is not just to list off those dates, it's to
see if it is possible to meet them under a certain set of conditions and
availability of resources. If it turns out it is, great. If it's not I
need to change the network or the resources and I want the planning software
to tell me so in no uncertain or ambiguous terms while I'm still planning so
that I can fix it early while it's still relatively cheap and easy to do so,
or to renegotiate the contracts while we can so they better reflect
realistic goals. If I've locked the finish milestone on the required finish
date with a Must Finish On milestone and run a report on the milestones,
it'll happily show me finishing on time regardless of whether it's even
possible to meet that deadline or not with the plan structured the way it
is. Yes, I can get some of that information by looking at slack times and
*if* I haven't disabled some of the scheduling messages I might get a
warning under certain circumstances but I personally would rather see the
milestone sitting on the date we actually are likely to achieve given the
current plan and if it is showing missing my contracted-for deadline, to see
that big red diamond indicator there by the task warning me either to update
the plan or update my resume.

Of course the best long-term solution is to push your organization more
towards the "fully projectized" organizational model so that the project
manager is involved with the process even before the negotiation phase with
the customer and at least a preliminary plan would have been created for
estimating purposes before you ever even considered bidding on the contract.
That way the milestone dates have already been feasibility tested and are
known to be do-able with a reasonable level of certainty within the defined
project scope and with the resources that are likely to be available, all
the while keeping it within a reasonable level of variation and contingency
planning. Then the plan can serve as a guide for the contract negotiation
team and the contract becomes something more than an arbitrary wishlist that
may or may not be possible to fulfill.

Just one opinion.

 

[Steve House]

The prioritzing seems a lengthy and painful process but I think that's the
right way to do it. Depending on the nature of the project, the planning
phase can consume up to as much as 30 percent or so of the entire project
schedule and budget. For any except the most trivial projects it simply not
something one bangs out in a couple of days.

 

[Ed Trotter]

Oh No!! Not the Milestone debate again!!

Suffice it to say that Project allows several ways of handling milestones
and analyzing the Plan in order to meet them. Some like to see the
Milestones float in time so you know how far behind you are, some like the
Milestones fixed and to look at float (slack). Both allow Project to
"freely calculate" the appropriate dates. Its all in how you want to use
the tool.

ET

 

[Steve House]

Just as an FYI - using the deadline method gives you the same slack time
calculations that you get using a MFNLT or MFO constraint, so using
deadlines instead of constraints doesn't preclude doing anything you usually
do with those slack time figures. You can see the same position of the
milestones when using constraint that you have with deadlines if you turn
off the "Tasks always obey their constraint dates" option, but unfortunately
that is a global setting and causes all tasks to ignore their contraints.
Using deadlines allows you to be more selective, retaining the effect to the
plan of constraints of the sort that I consider legitimate such as the
example of not being allowed onto a property to start work until after a
certain date while not seeing fictitious dates for the other tasks where the
constraints indicate a deadline.

--
Steve House
MS Project MVP
Visit http://www.mvps.org/project/faqs.htm for the FAQs

..

 

[Jack D.]

My vote: Deadlines

They are sufficient in letting you know what is going on without unduly
constraining your schedule.

The second alternative - a baseline and a bar which shows deviation from
such.
Hard constraints should only be used very sparingly.

Remember, you can easily add and remove constraints if you want. So if you
need one to perform some analysis, go ahead and do it. Just remember to
remove it afterward.

--
Please try to keep replies in this group. I do check e-mail, but only
infrequently. For Macros and other things check http://masamiki.com/project

-Jack Dahlgren, Project MVP
email: J -at- eM Vee Pee S dot COM


+++++++++++++++++++